データセンタやマシンルームの選び方
前回のゼータセンタの熱による障害事象に関してお話しさせて頂きましたが
データセンタはどのように選んでいらっしゃいますか？
耐震機能、セキュリティ、ミサイルを撃ち込まれても大丈夫な建屋色々あると思います。
実は私も10年ほど前には某企業がラック単位ではなくスペース単位で借りていたデータセンタのファシリティ管理業務も4年ほどネットワークやサーバ案件と並行で対応していました。このため今でもデータセンタの床下LAN配線を一人でやろうと思えば問題なくできます。
この観点で私はデータセンタで作業中に稀に見る見学会にいらっしゃる他企業の方が、ラックの配置状況だけを見て帰られる方をよく見かけ、そのたびに『あぁ、この方々は何を見ておくべきなのか把握されずに来館されたんだな』と残念に思います。
もちろん、費用対効果も考慮すべきですので安かろう悪かろうであっても、大規模災害時にデータ通信は出来なくとも災害の影響でシステムが完全停止してしまいデータロストを防ぐというレベルでの検討の場合もあるので一概高いデータセンタがいいとは言えないでしょうが見るポイントが分かるだけでも随分違うでしょう。
仮想化による集約が進んだ今、データセンタを見る際にどのような点に気を付ければよいでしょうか？いくつかのポイントがあると思います。
その前に一つURLを紹介させてください。
HP ProLiant White Paper 高密度コンピューティングのためのデータセンターの最適化：冷却装置の効果の最適化 | HPE 日本
※以下画像に関しては流用させていただきます
①ラック間距離
築年数のあるデータセンタではラックのコンソール側が90cm、背面側が60-80cm程度の場合が多いと思いますが、最近のブレードサーバを利用した集約化を考慮すると
120cmでは足りない場合も多々あります。
特に某H社のブレードサーバはデータセンタではかなりの厄介者で異常なまでの排気量とその排気音で周囲に設置された機器のシステム管理者を機器故障で悩ませる原因となります。伊達に機器名に音に関する名前がついているわけではないな、と個人的に感じています。
なぜ、音と排気音なのか、ですが音については大音量の回転音がしていれば、ハードウェアアラートを巡回時に見落としてしまい故障の影響を大きくする原因につながります。また、排気量が大きいと背面側の対面のラックの廃棄を阻害してしまい、廃熱が出来なくなってしまい機器故障を連発することもあります。実際に私もこれを経験しておりその際には私が管理しているサーバが数年前から設置されていた事と設置したSIerがデータセンタの管理者だったため、冷却対応をかなり行って頂いたものの排気量の差があまりに酷く、ラック内にファンを増設したりサーキュレータの設置もして頂きましたが、思ったほどの効果が得られない程にH社の廃棄はとんでもないレベルだということです。
このように集約化による機器の大排気量化が進んでいる中であまり距離が近いとこのようなトラブルを招くことになるので注意が必要となります。
次にデータセンタ内のエアコンのエアフローですが、HPさんのサイトでは横にはフロアの壁に吸気用のCRACが描かれていますが、この構造では『床下からの冷気とサーバ背面からの熱気がサーバラックの壁を伝って混じり合った物を吸気して屋外に廃棄する』ことになり、この場合は高い冷却効率を望むことは難しくなります。このため新しいデータセンタでは、ラックの列の間に扉を付けて冷気と熱気を分けるいわゆる『コールドアイルとホットアイルの分割』が行われています。もちろん古いデータセンタでも扉を設置するだけのコストが掛けられなくともテーブルクロスとして利用するビニールを暖簾のように下げることでこの対応を行っている場合もあります。私はデータセンタにこの概念を担当者に説明して設備部門へ私の管理するラックにしてもらったところ、いつの間にか設置範囲が一気に広まったことがあります。
このように熱の横移動を阻害する仕組みがされている事とそれらを吸い上げて熱気を帯びた空気が降りてこないようにするための天井(天井に吸気構が付いていることが望ましい)構造になっているとなお良いといえます。
②電源、LAN、ファイバ類の敷設経路と敷設方法
古いデータセンタでは特に上記の配線が全て床下で且つ電源ケーブルがラックのフロント側を通っている事が多いと思います。これは床下を通る冷風を乱流にする原因になりやすいため、選択から外したほうが良い可能性が高いです。
また、HPさんのサイトで『図5.フリーアクセスフロア下の未整理のケーブル (左) と整理されたケーブル (右)』という二つの写真がありますが、左は床下が浅く、右は床下が60cmになっていることが分かります。当然ながら床下配線が綺麗で床が深いほうが冷却効率が上がりやすいでしょう。エアコンの出力が弱かったら話になりませんが。
上記を考慮すると、データセンタ見学では、ラックの背面側の床下と通路部の配線状況を見せてもらうとよいでしょう。
③ブランクパネル
数年前の集約化が進む前はそこまで意識する必要がない場合が多かったですが、集約化することでCPUの利用率が上がり、ラック内自体の排気量もかなり増えています。ここで利用するのが目隠し板とも呼ばれるブランクパネルです。ブランクパネルの主用途は熱気の循環を防ぐことです。このため設置されているラックにブランクパネルが設置が徹底されているかどうかこれも焦点になると思います。
正直なところ、ブランクパネルはデータセンタ利用者が用意するつもりでいるほうが望ましいですが、データセンタが例えお手製のプラ板のブランクパネルであっても提供してもらえるのであれば、借りることで冷却効率が上がるため結果として故障率を下げることにつながります。
④耐震構造
建物には耐震構造と免震構造があります。免震構造の場合はラックが固定査定ることが一般的で耐震構造の場合は、ISOベースと呼ばれるものが導入されていることが必要です。ない場合は選定基準から外してもよいレベルといえます。
⑤電気系統
発電所2か所以上からの給電が必須です。また、ブレーカがUPSを兼ねている事と建屋に発電施設があることを確認しましょう。
⑥機器設置のガイドラインがあるかどうか
④であげた耐震構造ですが、ラックと床には耐荷重と引き抜き強度と呼ばれる床が引っ張られることに対する強度があります。重量があるものをラックの上段に設置すれば、横揺れが発生した際にその上段の重量で床下のコンクリートが破損し、ラックが点灯することもあります。
また、ISOベースの場合は床とラックの間にボールベアリングが設置されているため直接的には引き抜き強度を考慮する必要はないと思いますが、それでも横揺れ時を想定して重量バランスが上に来ないように機器を設置することが重要となること、廃熱を考慮しケーブリングについてどのようにすべきかサンプル写真がある事。それ以外ではラック単位での熱量および積載制限がある事と高集約システムでは200Vの電源提供が基本であることなどが挙げられていることが望ましいといえます。
なお、200Vが、ということに関してですがこれはデータセンタ利用者にとって200Vでメリットが得られる話ではありません。電気量の計算はV×A＝Wであり発熱量もWをベースに計算するため100Vも200Vも大差ありませんが、ラック内の電気配線数を減らす事でケーブルが整理しやすくなることと廃棄効率がよくなることが挙げられます。また、データセンタには大きなメリットがあります。それは電気工事では100V15A（NEMA15と呼ばれるいわゆる平行２ピンアース付き)か200V20A、もしくは30Aでの手配が一般的で、100V15Aでは1500W、200V20Aでは4000Wとなりますのでラックに供給する電力量が100Vでは不足しがちになる＝無駄にブレーカを消費することにつながりコスト回収がしづらくなってしまいます。その観点では『200Vは追加料金が掛かる』というデータセンタは施設投資に関する考えが足りているとは感じないため、ラックに関するハードウェア的なトラブルがあった場合にサーキュレータ設置等の対応が期待できないだろうと思いますので選択からは除外すると思います。
⑦機器設置エリアについて
どのような理由があろうと、サーバラックを追加した際にまったく関係のないエリアに設置させられるようなことがない、いわゆるエリアマネージメントを行っている事は確認しましょう。
その場合のLANもしくはファイバ敷設工事に関して費用請求されないことは確認したほうが良いでしょう。私も実際にそのような業者にあったことがあり、本数が多いとは言えどファイバ敷設で500万近い見積もりを提示されたことがあり突っ返しました。
VDI環境のActive Directory
Horizon環境ではActive Directoryが必須であることは皆さんご存知だと思います。
DNS、認証、DHCP、MAKライセンス、自家証明書を利用する場合はCAと大活躍します。
立てるだけでOKなものについては、専門的に解説されているサイトを見て頂くとして
今回はフォーカスの当たりにくい『Active Directoryサイトとサービス』です。
ドメインコントローラを立てたばかりだったり規模が非常に小さい場合は
正直この『Active Directoryサイトとサービス』の設定も必要ありません。
ですが、数百台規模になったあたりでドメインコントローラを増設し
2台から3台、4台と増やしていくことになるでしょう。
そのようなシチュエーションでこの『Active Directoryサイトとサービス』は利用します。
『Active Directoryサイトとサービス』は例えば本店(192.168.0.0/22)、データセンタ(172.18.0.0/18)、店舗(10.0.0.0/16)といった環境でこれらのサイトとサブネットを
紐づけを行い、どのドメインコントローラをメインに利用させるかをある程度
コントロールし、ドメインコントローラの負荷が集中しないようにするのに利用します。
上記の例を使いますが、各サイト用のドメインコントローラを設置した場合を
説明します。
◆サイトとサービスに作成したサイトとドメコンの配置
※サイト名の初めのA,B,Cは説明のため意図的に付けました。
『A本店サイト(ドメコン：DC01、DC02)』----192.168.0.0/22
『Bデータセンタサイト(DC03,04)』 ----172.18.0.0/18
『C店舗サイト(DC06,07)』 ----10.0.0.0/16
データセンタ内のドメインメンバPC/サーバは初めにDC03に認証リクエストを送信します。DC03のレスポンスが悪い場合はDC04に行きます。DC04も負荷が高い場合は次にサイト名順でアクセスを試みますので、本店サイトにあるDC01、DC02へと順にリクエストを送信するようになります。
この動作順を把握していれば、遠距離のサイトやNWやドメコンの負荷が高い拠点の順番を下に持ってくることでデータセンタ内から無駄な認証リクエストを送信してしまい
ファイルサーバのファイルを開くのも遅い人がいるといった余計なトラブルを抑制できるようになります。
ちなみにどのドメコンを利用しているかについては、systeminfoのコマンドで確認できるので、ユーザからの問い合わせからどのドメコンの再起動を計画すればよいか判別できるようになります。
データセンタの熱に関して
本日VMUGデスクトップ仮想部会でした。（と、いうわけで酔ってます)
その中で興味深い話が1つ。
参加企業の方でN社さんでGPUをHPのC7000に番号通りに搭載しGPUとして
nVidiaを搭載しCADを実行しているが、よくブルースクリーンで落ちる＆
交換すると治るとのこと。しかもシャーシ中央のブレードで頻繁に発生し
毎月交換しているとのことでした。
症状から、『GPUが熱で壊れている可能性』を指摘させていただき
色々と話をしていくと私の会社が利用しているデータセンタと建屋違いだが
同じ会社だとのこと。更にデータセンタ移転時のプロジェクトに
自社の担当が参加していた模様で、時期的に不在時が多かった時期が重なるので
担当者が同じだろうという結論になりました。
他社のことに口出しするのもあれですが
このデータセンタには私がコールドアイル／ホットアイルの区分けを作る方法や
ラック自体の冷却方法に関する対応策についてはSuggestしているしていることもあり
明日ちょっと担当者の方に連絡してみたいと思います。
データセンタのラックの冷却設計については別スレにさせていただきます
bginfo
今日は今月の疲労が抜けていないので簡単な内容にさせてください。
先日紹介したbginfoですが、WMIやスクリプトに対応しています。
Ipv4を優先してもIPv6が残っていたり、NICのレジストリが残っていることで
(none)となる場合もありますが、WMIやIPv6表記を出さないようにすることも可能です。
blogs.technet.microsoft.com
上記TechNetにあるように『select ipaddress from win32_networkadapterconfiguration where ipenabled=true 』で(none)と表記されるインターフェースを表示させないようにできますが、IPv4のみを表示したい場合はこれでは回避できません。
そこでVBScriptでわかりやすいようにbginfo.exeと同じパスに保存し
bginfoの『custom』ボタンから開くウィンドウで『vbscript』で保存したスクリプトを
参照させることでそれらの項目を追加することができます。
各種情報をピックアップするためのサンプルスクリプトとして
sysinternalのフォーラムでトピックに上がっていますのでそちらを参照してください。
なお、IPv4のみを表記するスクリプトもこちらで記載されています。
VDIを早くするには『ネットワーク編』
。Windows7では社内LANで利用するのであればネットワーク関係も出来るだけ調整したほうが良いでしょう。
１．vNICでVMXNET3を選択している事。
E1000はESX5.1Up2で切断状態が発生するトラブルの報告だけでなくvExpert取得者のRickard Norbel氏のブログでの報告ではスループットがVMXNET3を利用時の半分程度しか出ないという報告もあります。
E1000/E1000E vNIC を使用する仮想マシンのあるホストを ESXi 5.1 U2 にアップグレードすると
ネットワークの問題が発生する(2073735)
http://kb.vmware.com/kb/2073735
Network performance with VMware paravirtualized VMXNET3 compared to the emulated E1000E and E1000.
http://rickardnobel.se/vmxnet3-vs-e1000e-and-e1000-part-2
１．NICの電源管理(デプロイやイメージコピーでのナンバリングずれ対応必須）
※既に紹介したので割愛
２．IPv6 / v4の優先順位変更
コマンドで行うか、パッチを適用します。通信の際にIPv4で初めから通信してもらいたいので適用しています。これはvNICに対してではなくOSに対して掛かります。
netsh interface ipv6 set prefixpolicy ::ffff:0:0/96 50 0
netsh interface ipv6 set prefixpolicy ::1/128 40 1
netsh interface ipv6 set prefixpolicy ::/0 30 2
netsh interface ipv6 set prefixpolicy 2002::/16 20 3
netsh interface ipv6 set prefixpolicy ::/96 10 4
世界 IPv6 が (2012 年 6 月 6 日) を起動した後はインターネット接続の問題を解決します。
https://support.microsoft.com/ja-jp/kb/2533454
３．SNPの無効化
Windows 7のSNPの影響で通信が安定しない面があるだけでなく、処理をNICで実行することから、通常のサーバでSNPが有効になっていてもvNICに振られるだけなのでメリットがあるとは思えません、ので無効化しています。
netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled
netsh int tcp set global netdma=disabled
予期せぬ挙動が!? 新機能 Scalable Networking Pack をご存知ですか?
http://blogs.technet.com/b/jpntsblog/archive/2010/03/23/scalable-networking-pack.aspx
Windows 仮想マシンのネットワーク パフォーマンスが悪い、または待ち時間が長い (2097316)
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2097316
４．NICのオフロードの無効化
『詳細設定』タブのXXのオフロードと記載されている項目をオフにしています
以下のCiscoのURLは昨年知ったのですが、こちらにかなり詳細が記載されています。
UCSではWindows7以外のWindowsOSに対してオフロード機能のサポートがあるため
仮想化ではDisabled推奨の設定についても説明されているものと思われます。
VDIを早くするには『メモリ編』
Windows 7 Pro 32bitの使用する起動直後のメモリ使用率は特に何もチューニングを行わないと700-800MB程度は使用してしまいます。これを無駄なサービスと画面表示をさせないようにすると580MB程度まで減少させることができます。
これは結果的に無駄なCPUリソースの消費を抑えることになります。
この詳細は別途とさせてください
VDIを早くするには『HDD編』
いま利用しているパソコンを早くするにはどうしたらいいでしょうか？
もちろんハードウェアを更新するのが非常に効果的ですが、お金を掛けられないもしくはパソコン自体がパーツ増設や交換が出来ない場合にどうしますか？
VDIにおいても同じです。最低限のCPUとメモリとHDDのVDIを出来る限り1台のESXに集約することが重要であることを考慮すると、Windows 7 のパソコンでCPUとしてatom、メモリ：2GB、HDD：SATAの5000rpm程度のマシンをチューニングするイメージで構築するという意識が重要です。
では、上記のようなロースペックのPCを何とか利用できるレベルにするどうすれば良いでしょうか？これにはインストールから気を付けて行うことが重要となります。
まずWindowsをインストールした後に自社の環境に合わせて最大限パッチを適用します。この時点でディスクのクリーンナップを行い、デフラグをそのまま3回、再起動して1-2回実行します。その後、更新頻度の低いソフトから順にインストールし、クリーンナップとデフラグを実行します。更にOfficeを入れてパッチを適用しクリーンナップとデフラグを行います。
SSD環境ではデフラグは推奨出来ませんが、このような形でテンプレートを作成するとRaidで分散されてもデータの連続性がある程度担保されます。
