見落としていました。。。。
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に変更する。
実際症状が治まっていますので効果はあるようです。
閑話休題
ふと思い出した程度のしょうもない話を。
vCenterでゲストOS作成するときにWindowsの場合にホスト名を16文字を超えるとActive Directoryへの登録時にホスト名の末端(16字目以降)が切れた状態で登録しようとするので例えば連番のVDI0123456789ABC(Cが16文字目)を登録するとVDI0123456789ABとして登録されてしまいます。さらにもう一台今度はVDI0123456789ABDとして登録するとこれもVDI0123456789ABとして登録しようとするのでエラーになります。
Horizon6.2.2以降へのアップデート
View5.xから6.2.2以降へのアップデートと注意しなければならない問題
Horizon5.xから6.2.3へのアップデートは以下の手順で実施します。
１．vCenterのアップデート
２．Composerのアップデート
３．ConnectionServerのアップデート
４．ESXのアップデート
５．VDIのvmtools のアップデート
６．VDIのView Agentのアンインストールと６.2.3対応のView Agentインストール
◆VDIのエージェントインストール手順について
VMtoolsとDeepSecurity Agentは問題ありませんが、View AgentをフルクローンVDIに展開する際はView Agentのサービスが実行状態の場合100台中5台程度の確率でView Administrator上でステータスが取れずログイン出来なくなります。このためView Agentはアンインストール／インストールするか、アップデートインストール後に対象PCをView Administrator上で確認し、ステータス異常が出ているかチェックする必要があります。
◆vShiled EndPointを利用している場合のVMTOOLSの新規インストール
NSX File Introspectionドライバのインストールが必要になります。
◆NSX Network Introspectionドライバ
NSXを利用するときのみ利用します。
◆vShiled EndPoint製品をNSXを利用せずに継続利用する場合
DeepSecurityの場合は以下の手順が追加になりました。
①DeepSecurity Relay /ManagerのアップデートをvCenterの後に実施
②各ESXのアップデートのタイミングでDeep Security バーチャルアプライアンスの再展開
DeepSecuirtyの詳細については別途とします。
最も注意が必要な点はHorizon6.2.2より実装されたTLS1.0無効です。シンクライアントだけでなくゼロクライアントでもConnection Serverに接続できなくなっている報告がありましたので必ず対応しましょう。
この設定はConnection ServerのレジストリとLocked.propertiesというファイルの変更とVDIのレジストリ変更が必要となります。
◆レジストリ
Connection Server /VDI共に共通です。
HKLM\software\teradici\SecurityGateway のキーにSSLProtocol REG_SZ 値としてtls1.2:tls1.1:tls1.0を作成します。
◆Locked.propertiesファイル
2016年9月時点でLocked.propertiesに関するKBを見つけられませんでしたので
海外のスレッドを参考にしたのですが、Hatenaにはリンクが貼れないドメインのようなので転載します。
◆以下、引用
#This file is for disabling and setting more secure cypher suites in View
#https://pubs.vmware.com/horizon-view-60/topic/com.vmware.ICbase/PDF/horizon-view-60-security.pdf
#The following list should be ordered with the latest protocol first:
secureProtocols.1=TLSv1.1
secureProtocols.2=TLSv1
secureProtocols.3=SSLv2Hello
secureProtocols.4=TLSv1.2
#This setting must be the latest protocol given in the list above:
preferredSecureProtocol=TLSv1.1
#The order of the following list is unimportant:
enabledCipherSuite.1=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
enabledCipherSuite.2=TLS_DHE_DSS_WITH_AES_128_CBC_SHA
enabledCipherSuite.3=TLS_DHE_RSA_WITH_AES_128_CBC_SHA
#enabledCipherSuite.4=TLS_RSA_WITH_AES_128_CBC_SHA
#enabledCipherSuite.5=SSL_RSA_WITH_RC4_128_SHA
PCoIPのトラブル対応
ご存知の通りPCoIPはUDP通信です。一応View Client /Agent間の通信は再送性があるということになっていますが、意外と色々な欠点があります。
PCoIPでの症状は大きく『VDIからの切断（繰り返しも含む）』、『画面がぼやける（遅延）』、『つながらない』、『固まる（マウスは動く）』です。
『固まる（マウスは動く）』については、ユーザの殆どはキー入力での動作確認ではなく、『マウスが動くか動かないか』で判別する人が殆どです。このため、『動いていますか？』というとマウスを動かしてカーソルが移動するので『動いてます（けど画面が更新されない）』という回答をする人が殆どです。
変わった症状では、シンクライアントに内蔵されているCMOS用のボタン電池切れが意外と怖い症状を起こします。電池のため、切れていても実害は出ませんが例えば『席移動』や停電があった次の日にPCを起動しようとすると給電がないため、マザーのシステム時間がずれてします。この状態でSSLの証明書を利用しているとシンクライアントの時間が大幅に戻るため、証明書の期間外となってHorizon ClientのログインIDとパスワードの画面まで進まない症状を発生させます。また、ドメインに参加していないシンクライアントは5分以上NTPとずれると自動同期されないため、手もしくは管理サーバから時間同期ジョブが配信されないとつながらない状態が継続します。
①シンクライアントハード故障による通信不安定化
シンクライアントはのハード故障はこれまで確認した中では、『NICの故障』、『OS記憶領域として利用される不揮発性メモリの故障』、『マザーの電源故障』、『ACアダプタの故障』がありますが、PCoIPを利用するようになってから顕著にユーザからの申告が増えたのは『NICの故障』です。これはVDIのデスクトップが表示されてからしばらくすると何度も切断されるようになります。
『NICの故障』、『ACアダプタの故障』はほぼすべての症状を発生させますが、『マザーの故障や『OS領域～のメモリ故障』は、朝出勤して起動したら起動しない状態となります。
②ハブ／LANケーブルの劣化
単なる爪折れを除き、ハブが5年程度経っている場合や古いLANケーブルが机や椅子の脚に下敷きになったりしているとまずは遅延が発生し、机などの移動で部分断線により通信が切断されるようになり、またいじると戻るという面倒な症状に繋がります。
③OAタップの劣化
これは私も1回しかありませんが、OAタップの劣化とたこ足で電源供給が不安定な状態が発生する事でNICが安定しなくなる事があります。このときはケーブルを差し替えて知事対処としました。
④回線
普通にBフレッツとかADSLという意味での回線です。ONUやルータの劣化でも発生します。現職の地方拠点でADSLを利用しているところがないので比較できていませんが、ネットワークの不安定さを考慮すると例えば8MのADSL回線でNTT基地局から遠く、回線速度が出ない場合等にほぼすべての症状が出る可能性があります。
⑤画面解像度が高すぎる
メモリの少ないシンクライアントで高解像度のVDIや複数VDIに接続すると、メモリ不足でタスクバーにメモリ不足のメッセージが表示されます（少なくともXP Embeddedではそうなりました)。メモリが足りないので再起動するまで繋がりません。
参考までに1GBメモリのシンクライアントで1024×768表示のVDI１つにつなぐのはOKでしたが、2つにつなぐと発生していました。
このことを考慮すると大画面でPhotoshopや3Dレンダリングソフトを利用するVDIへの接続では、グラフィックチップのある大容量メモリのクライアントかBIOSでグラフィックにメモリ割り当てを変更することをキッティング作業に盛り込む必要があると考えられます。
⑥ネットワークが不安定な環境
これに関しては非常に難しいです。社内のVPNもしくは経路上の一部のネットワーク機器が不安定な場合だけでなく、私が体験したものでは『WindowsUpdateの配信日』にPCoIPで切断されるという問題がありました。2015-2016年頃でもっとも発生したのは新潟で、VPN業者のほうでも他のユーザ企業で同様の問題が発生していましたが、こればかりは別の回線を利用する以外に対処がないという状態です。
※2016年11月には緩和されていますのでWindows10配信による影響が大きかったのでしょう
⑦ドメインコントローラの負荷が高すぎる
ユーザが100人いてVDIに変更する前は100台のPCを利用していたのが、VDIになったことでシンクライアント＋VDIで200台に増えますのでドメインコントローラの負荷は2倍に跳ね上がります。これによりドメインコントローラが処理できなくなり、共有PCのプールではAさんがログインしたことでVDI001が割り当てられてパワーオンしたのに、Bさんがログインした際に、Bさんに奪われる。Aさんのログイン先がなくなりエラーが出るのでもう一度ログインし直してVDI002が割り当てられパワーオンしたのにCさんに奪われるという事もあります。
