VDIテンプレートの設定はADのグループポリシで
やるのは推奨できません。甘い期待を持つのはやめましょう。
※2016/12/19追記 時間をおいて読み直した結果、修正コメントを追記することに致しました。申し訳ありません。
ADでの設定は必要ですが、念には念を入れて出来るだけローカルポリシやレジストリを編集した状態で、必要であればADのGPOを適用しましょう。という意味です。
一方でSIの方が、ADのGPOで設定すればOKですというのは鵜呑みにしないようにと警告することを目的としていました。
システムインテグレータの方達が『VDIの設定はADのグループポリシで』と言っていたとしても鵜呑みにしてはいけません、なぜなら彼らは『構築の仕方は知っていても運用は知らないから』です。
ゼロから作ったクリーンな環境で正しく構築されていれば、誰がやっても正常に動きますが、実際にはドメコンのメモリ不足等々で正常に動かなかったり、PCを強制電源OFFなどでOS破損していて適用されない等は当たり前にあります。我々が想定しなければならない環境は、『クリーンで正しい環境』ではなく、『必ずしも正常稼働するとは限らない環境で、必ず同じ結果を出す』事です。.そうすることで一人社内インフラエンジニアの私は自分の作った環境で発生するトラブルで眠れない日々を眠れる日々に変えています。
自身の常識になっている事が世の中的にそうではない事を実感する事が多いのでこのような書き出しにしました。
前職のまだXP全盛時代に金融機関のActive Directory管理をしていたなかで、PCに当てる予定のポリシが当たらないというエスカレーションを受けて、温厚なチームメイトがコンチクショイ！と言いながら対応していた情景がまだ脳裏に残っています。つまり、PCが調子悪かろうとドメコンが調子悪かろうとそれらの通信が調子悪かろうと適用されない時は適用されない、それがActive Directoryのグループポリシだと思っています。
View5.x系環境でWindows 7をリリースした後に、想定よりも早く共有PCのプロファイルが溜まりすぎてVDIのCドライブが一杯になり、利用できなくなるケースがありました。一方で個人利用のPCでは休職や長期出張でPCを利用しない人が稀にいるため、GPOのWMIフィルタで分別してもよかったのですが、面倒だったので急きょ共有PCの一台にローカルポリシーでプロファイルを一週間で消すように追加設定を入れて、ローカルポリシーのファイルをPSEXECでコピー配布して対応したことがありますが、これも必ずしも適用されない場合があります。
こういった事を経験しているとVDIで必須となるポリシーだけでなく、既存で利用しているポリシがあればVDIテンプレートに組み込んでおくほうがスタートラインをそろえることが出来るので環境としては望ましいと言えるでしょう。
ローカルポリシはグループポリシで上書き出来ますので、変更が必要な場合はグループポリシで上書きするようにするほうが負担軽減となるでしょう。
vSphere上で起動直後に画面が真っ黒のままで開けない#2
前回はVMwareのKBに従いポリシーをいじる操作を行って、起動時・再起動時のコンソール画面が真っ黒で最悪通信エラーが表示されることに対する対応をしましたがもう一手対応しました。KBを見ると『WSUSサーバとの疎通が…』とありますのでWSUSサーバのセッションリセット等を考慮しサーバの再起動を実施したところポリシーを変更せずともコンソール画面の状態が改善するようになりました。
っ[とりあえず再起動]
vSphere上で起動直後に画面が真っ黒のままで開けない
いまさらですが、ここを参考にして設定したけどうまくいかんわー！とか2次災害起こしたやんけー！とかそういうのは受け付けません。あくまで自己責任でお願いします。
さて本題の『vSphere上で起動直後に画面が真っ黒のままで開けない』ですが、環境によってはvSphere上でゲストOSを再起動したり、電源をONした直後に画面が真っ黒のまま繋がらない状態になって開きなおさなければ表示されない症状が出るかと思います。私もISOイメージマウントしたいのに操作できんやんけー！とイライラすることがままありました。
この症状は以下のKBで改善する場合がありますので試してみてください。
仮想マシンのリモート コンソール画面の表示に最大 1 分かかる (2058959)
見落としていました。。。。
View5.xでもvSphere Web Clientの操作性が悪いのでvSphere Clientを利用していてあげたあともそのままだったツケを払わさせられました。とはいえ、9月に設置以降にDWHシステムのリプレースが二件あり、どちらも担当SEが(以下省略)で片方はデータ移行方式すらこちらから詳細な指示を出す羽目になったのですが、これらのせいでViewの異常対応は構築を頼んだ業者に任せっきりになって解決になかなか至りませんでした。先に言っておきますが、社内SEの本業はトラブルを楽しんだりプログラムを解析して改造することだとは思っていません、あくまで会社の要望に従い導入し管理運用することで自分に何かあってもシステム運用を誰であっても継続できるようにすることだと思っています。ですのでBCP的に影響のない、もしくは少ない増築作業のトラブルは優先度を下げているだけです。
話を戻しますが、何が起きていたかというとView6.2.3にアップデート後に新規クラスタを作りESXを追加したのですが、DRSのプロセスでsdrsinjector.34と言うものがあるのですがこれが数分置きにCPU利用率3200％(コア数32だから)wwwもう笑うしかありませんでした。これではユーザに提供出来ないので、まずはSAS回りを疑いVMのサポセンに問い合わせたところVMのサイトからISOを落としたものだったらしいのですがサポート対象外のバージョンですと言われCisco問い合わせて登録に関する調整をしてもらいつつ調査をしたところ新しいドライバーが含まれていないISOだったらしく更新を頼んだのですが治らず( ノД`)…
やっとVMのサポセンが対応してくれるようになったところで『vSphere Clientで表示されないパラメータの(データストアの「I/O統計収集の無効化」)』と分かりとりあえず無効にしました。無駄に負荷を上げるプロセスを勝手に有効にしないで欲しいです、VMさん。正直今回の件はVMのセールスSEの方にも動いていただきましたがCisco社のVMware社への登録漏れやその程度でサポートしないと言い切られるのはユーザとしては非常に困りものです。
サーバラッキングなんか考える必要あるの？
データセンタの選び方に続きラッキングに関して考察します。とは言えあくまで経験則でやってますので『ノークレーム』でお願いします。とりあえず『あなたの常識を吹っ飛ばす‼』そんなつもりです。
この下にラック図が2つ掲載していますが、これらは実在のラックです。これらは同じ列のほぼ向かい合った位置にあり、上は私が管理するラック、下はどこかの業者さんのラックです。なぜ比較したかというと、同じ並びでコンソール側もビニールフィルムで一空間として等しく区切られた中にあり最大消費電力ではサーバがある方が排熱量は多い筈のラックよりネットワーク機器とストレージだけのラックのほうが熱かったからです。なお、測定はラックの空気孔に差して放置可能なタニタの温度計(新品とはいえ料理用)で温度が安定するまでを基準にしています。
①サーバの多いラック
図の左から順にラックフロント(コンソール側)、側面、背面となっています。
温度は常識通り下の方が低く、上が暑いです。フロント側は基本的に目隠し板を張ってあります。また、最上部にはスイッチ、FCスイッチが穴空きケーブルマネージメントが間に挟んでマウントされています。なぜ穴空きマネージメントなのでしょうか？
穴空きマネージメントサンプル
http://www.koshow.jp/shop/html/products/detail.php?product_id=101201505
それは当然排気の通気孔としてです。
ラック図は左から順にフロント、中、背面rです。ラックを下方からみますと一番下は開けて二番目にPDUを配置しています。これも実は意味があり、サーバを一番下に配置して床下に置かれた敷設済LANケーブルを取るときや余ったケーブルを床上のスペースに逃がしたいのにサーバが邪魔で手が入らない、入ったけど手を抜くときにサーバの電源が抜けた‼といったトラブルを回避することが出来ます。どうしても利用したければ一番下のユニットのフロントに軽量棚板やデータセンタが許すのであれば、金属引き出しを着けるのもありです。サーバのゴールドディスク(刺せば使えるHDDでのバックアップ)やUSBDVDドライブ等を格納するのも良いでしょう。
上記ラックでは①22.6℃、②37℃、③23.1℃、④23.3℃、⑤33.7℃、⑥35.1℃となっていました。②の温度が37℃だったのは下に設置されている8台分のサーバの廃棄がフロント側にブランクパネルが付けられていないせいで、熱が滞留しフロントに回ってきている状態です。最上部の温度がフロントから順に④＜⑤＜⑥となっていることからブランクパネルで滞留を遮断し、背面側に通気口となる空ユニット及び穴開きマネージメントを利用することで背面方向へのエアフローが正常にコントロールされ、少々温度は高めではあるものの、背面側に正常に排気されていることが確認できます。
一方でネットワーク機器とストレージばかりの以下のようなラックであれば、一般的には温度上昇しないイメージがあると思います。では実際はどうでしょうか？
①22℃、②24℃、③23.6℃、④29.2℃、⑤25.3℃、⑥34.5℃となっています。ブランクパネルのないこのラックでは④でストレージの熱がフロントに回ってきている事がよくわかります。最後に⑦ですがフロント側は36.1℃、背面は35.9℃でした。『ネットワーク機器のファンの向きを考えてフロントマウント』をした結果、ネットワーク機器をフロントマウントした場合に1Uのネットワーク機器の内蔵ファンではラックの残り半分の長さを換気することはできない事が分かります。また、上記の例ではストレージの熱がフロント側に回ってきている事、ネットワーク機器の間に穴開きケーブルマネージメントを設置しないことで冷気がフロントから流れ込むところがない事、この点により最上部⑦の41-43Uでは熱が滞留する状態になっているといえます。解決するには20-27Uにブランクパネルの設置をすることと、41-43U付近の背面扉にファンを設置することで対処可能です。
グラフィックカードは難しいようですね。
これは私が体験した話ではありませんが、VDI会に参加されている他社環境においてHP C7000にWS460を4本搭載した環境でグラフィックボードの障害が多発するという話がありました。
WS460は2スロットを利用するそうなのですが、上の段に4本差していることで中央2本が特に故障が多いという話からエアフロー不足の可能性がありました。
私も上記のエアフロー動画はこの話題があってから検索して見つけましたが発生している症状から見ても、両サイドが比較的冷却効率が良く故障率が低いという内容と合致しているため、このことは報告された他社担当者の方に報告しています。
さらに、WS460の構成を他社担当者の方に確認したところGPUが6個、CPU2個ということからK2が3枚なのでしょうか？そうであれば1GPUコアあたり113Wで計算すると
140W(CPU)×2+113×6= 958W
となります。CPUコア数で計算すると約6.84コア相当に該当します。通常のブレードサーバ2スロット分では4コアですので、スロット当たりのCPU集約率が1.7倍という計算になります。
このことからもCPU集約率が高すぎる事で熱だまりが出来てしまい熱暴走によるフリーズや熱によるGPU故障が発生していることが想像できます。
対策がなく、GPU搭載のVDIを導入することは無理なのか？と言われるとそういう事ではないと思います。ユーザが出来る対策としては、『1スロット単位での最大消費電力を下げる＝1スロット空きを作る。』、『データセンタ設置であれば、床冷却エアコンの近くを利用させてもらう』、『C7000の背面側扉の1U上あたりにファンを設置する』でしょうか。なお、『ラックに沢山ファンつければ冷やせるでしょ』という観点でラックのフロント側にファンつける人がいると思いますが、流体力学でいうところの乱流が起きるだけで冷えないでしょうからお勧めしません。このあたりのラックの配置に関する誤った認識の修正に関しては、書きかけの記事がありますのでそちらでフォローアップさせてください。
【個人的な意見】
このような問題に関しては、メーカ側で新しいファームとドライバを提供してもらう事も重要だと思いますが、VDIではハイパフォーマンスモードで稼働させないとレスポンスが悪いことを考慮するとこれらを更新したとしても、この問題は解決しないと思っています。私自身、Celeron300AというCPUを利用したクロックアップが流行った20年前に、CPU回路の短絡による供給電力アップやクロックアップしたCPUを冷やすために水冷やペルチェ素子を利用した冷却等でかなり遊んできています。爆熱Pentium4をどう冷やして利用するか？などもやった体験やグラフィックボードの熱対策なども自作PCで経験しているため、正直ファームアップ等をしてもスペックと引き換えに安定させることしか出来ないという結論になるだけだろうと推測します。そういった中で安定させるのであれば、上記の『ブレードシャーシ内での分散配置』やデータセンタ内環境の改善を行うしか方法はないと思います。
仮想サーバの通信トラブルについて
VDIではないのですが、同じ仮想の環境という事でたまにはサーバのお話を。
ESX6up2の環境でWindowsのFTPサーバを立てているのですが、このサーバが月に数回の頻度でLinuxのFATサーバからのFTPがAuthが通って伝送が始まったところで中断してしまいjobがコケる症状が発生しました。パケットキャプチャも仕掛けましたが原因がわからず、また他のプロジェクトの対応で手が離せなかったので2－3か月経過してしまっていたところで調査を開始しました。
ネットワーク周りですが、これまでの経験からFTPがそもそも繋がらないことがあるというのはFTPのACTIVE/PASVモードの影響で見たことがありましたが、キャプチャ結果から伝送中に、という事は今までありませんでしたし経路上でセッションコントロールしているものはなかったのでネットワークの可能性は95％以上ないとみなし切り捨てました。
その上で『仮想だから』という観点で調べる事にし、結果的に以下のURLにあるLROに疑いを向けたところドンピシャだったという話です。
(引用、緑字)ESXi で LRO の設定を無効にする
ESXi リリース 4.1 または 5.0 では、ファイル転送プロトコル（SFTP）やファイル転送プロトコル（FTP）を使用した転送などの大きなファイルの転送で問題が見つかっています。 これらの問題を解決するには、Large Receive Offload（LRO）オプションを無効にします。 ホストの [Configuration] タブ > [Advanced Settings] > [Net] に移動します。
このページには、複数の LRO 設定があります。 仮想マシン（VM）がクローンされていて静的な MAC アドレスを使用している場合は、ネットワークに重複する MAC アドレスがないことを確認します。 詳細については、『LRO の無効化』と『Unified Communications VMware の要件』を参照してください。
気が付いたかと思いますが、問題のあったFTPサーバはESX6の上で稼働しています。
ESX6なので関係ないと思いたいと思いつつ、あえてVMwareのサポセンに本障害とこのLROの項目の関連性を問い合わせを行いました。なんと性格が悪いのでしょう！サポセンの方もゲンナリしたと思います。
まず、サポセンからはvNICがE1000系かVMXNET3かを聞かれました。
Windows 2012 virtual machines using E1000/E1000e driver experience loss of network connectivity (2109922)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2109922
以前も書いた通り、E1000はVMXNET3の3割の速度しか出ないので使ってない事を回答し、Ciscoのサイトでは『ESX4系、5.0ではLRO無効化』について記載があったため
Net.LRODefBackoffPeriod 設定値： 8 (default)
Net.LRODefMaxLength 設定値: 65535 (default & MAX値)
Net.LRODefThreshold 設定値: 4000
Net.LRODefUseRatioDenom 設定値: 3
上記について関連性があるかサポセンに確認を依頼しました。
サポセンから次の回答として『ESXi 6.0 + vmxnet3 をご利用で LRO が有効の場合、環境によってはネットワーク遅延が発生する恐れがあります。対処は3パターン』とのこと。
Windowsコマンドプロンプト(管理者権限で実行)にて下記を実施
netsh int tcp set global rsc=disabled
◆方法B)ESXiホストでLRO無効
ESXiにコンソールかSSHログインして下記を実施
esxcli system settings advanced set -o /Net/Vmxnet3SwLRO -i 0
esxcli system settings advanced set -o /Net/Vmxnet3HwLRO -i 0
◆方法C) vSphere Web Client あるいは vSphere ClientでLRO無効
http://pubs.vmware.com/vsphere-60/topic/com.vmware.vsphere.networking.do
c/GUID-DAE02196-FAA5-48F6-A5FF-8E5068A6370A.html
Web Client の場合、 ESXiを選択して [管理] タブ＞[設定] ＞ [システム] ＞
[システムの詳細設定]
Net.Vmxnet3SwLRO と Net.Vmxnet3SwLRO のパラメータを0に変更する。
vSphere Clientの場合、 ESXiを選択して構成タブ->詳細設定->
左側"net" を選択して Vmxnet3SwLRO と Vmxnet3SwLRO を0に変更する。
実際症状が治まっていますので効果はあるようです。
