読者です 読者をやめる 読者になる 読者になる

FlexPodが厳しいです。

昨年9月から(といっても納品の関係で構築開始は10月だったのですが)構築を開始したゲストOS領域としてNFSを利用したFlexPodですが、状況が芳しくありません。
なお、現職の環境はSIerのN社と下請けとしてU社系が仮想環境を構築してきたのですが少々前から参入したC社がノウハウあります!やります!ということでU社に代わり下請けに入り構築が始まりました。

10月末に基礎構築が終わりVDIを展開した時点で、デプロイ時のVMDKファイルのコピーに既存のSAN環境と比較し1.5倍の掛かっており、当初はNFSアクセスだからこんなものなのだろうか?と思っていました。しかし、実際にログインして利用してみると異常に操作感が悪く、とりあえず使い慣れたCristalDiskMarkを利用し、I/O測定をするとVDIとしての利用感に一番影響の大きいランダムリードが異常に悪い結果が出ました。

スクリーンショット類はまだ整理中ですが、既存SAN環境がランダムリード200程度出る(IOPS18k程度)のに対し、当初30前後か下手すると一桁が出るときもありました。明らかに異常だと判断しましたが、生憎DWH2セットのハードリプレースがあり、これに伴うフルクローンVDI1000台にインストールされたODBCソフトウェアセット3本を入れ替える作業込みで一人で行う必要があったため、ひとまず担当SEに任せざるを得ませんでしたので、状況からESX再インストールを検討するように支持をしました。この時点で担当SEのCisco/VMwareによるリリースバージョン認可が下りておらずサポートが受けられないという板ばさみがあり、構築が進みませんでした。※それ以外にもISOイメージに最新のドライバが組み込まれていなかった等、あまり考えられない問題ばかりが発生しました。

次の課題は、C社が弊社からのRFPや今後の展望を記載した資料を渡していたにもかかわらず要求事項(従来のSANと異なりNFSになるので差分を吸収できるSEの協力が必要)を理解していない事とそれが出来るSEがいないことが判明しで、私の手が空く1月まで放置になってしまいました。

詳細な情報についてはこれからまとめますが、FlexPodのパフォーマンスチューニングでここまで行った内容と抱えているトラブルに関してまとめます。

まず、BIOS関係についてですが、HPやLenovoDellのサーバであればBIOS設定でPower Managementの項目でハイパフォーマンスにすれば完了なのですが、UCSの場合は自作PC並みにCPUやメモリの項目が存在します。分かりやすいところでいけばHyper-Threadなどですね。これらの項目をひとつずつ精査する必要があります。また、NFSアクセスではVMware社のセールスSEも仰っていましたが、ストレージメーカの推奨値とVMwarenの推奨値があり。基本はストレージメーカの推奨値を優先するとの事。ここでいう値は、vSphere Clientで設定可能な各ESXの詳細パラメータになります。これとMTU1500から9000への変更がメインとなります。

上記の対応により、ランダムリードが20-30程度から140-150程度まで上げることは出来たものの観測した中での最大値の190を常時キープできるところまでは調整できていないため、調査を継続している状況です。このIOPSが伸びない状況ですが、測定中にCPU使用率が50%程度と低い場合に190近い値が測定され、100%近い場合は非常に低い値で出るという症状とESXの再起動を実施するたびに状況が変わる(ただしいい結果が出る確率は20%程度)ということからESXに何がしかの問題があると判断し調査を進めています。

実際、UCSのサーバではsyslog.logで以下のログ等の異常なものがかなりの頻度で生成していることも確認されていますので、VMのサポセンに問い合わせはしているものの最終的には再インストを視野に入れざるを得なかろうと個人的には判断しています。

2017-01-16T23:03:32Z sfcb-CIMXML-Processor[127805]: pam_succeed_if(sfcb:auth): error retrieving information about user 52ce06d9-5323-b432-cd03-9a4e550cee43 •ESX/ESXi 4.1 および ESXi 5.0 ドメイン メンバーとユーザー認証による ESX Admins AD グループの使用 (2074017) https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1025569

PowerCLIをもう少し使いこなしたい

明けましておめでとうございます。

12月はDWHのストレージ入れ替えで担当業者の大手SIerのPL,PMを1ヶ月で2回もしかも部長込みでクビにせざるを得ない状況で対応していたため、月末は書く余裕がありませんでした。DWHの件はやっとハード構成が完了し今月データ移行テストが開始されました。

書く事が余りありませんが、共有VDIのプールでの問題でプール内のVDIがログインしたままになっているものも含めて使い切られている状態であることを利用部署の部門長等が確認出来る仕組みがあるほうが望ましいです。もちろん自力でVDIの再起動まで実施してくれれば何の問題もありませんが、そこまでしなくても最低限『誰々がこのVDIにつないだままにしているのを強制ログオフしてほしい』という形でリクエストしてもらえるだけでもシステム部門としては運用が楽になる事請け合いです。

Viewを導入する前にWindows XPのVDIをCitrix XenDesktop4とvCenter+RDPで利用していたのですが、その際に共有PCの利用状況をチェックし結果をHTML化するスクリプトを作成していました。その際にはPowerCLIなどといった便利ツールはありませんでしたので、管理サーバから共有PCのリストに対してPINGを実行して稼動確認を行ったうえで、起動している場合はpsexecでVDIに接続しqwinstaコマンドでRDP接続しているユーザの情報を取得する方法で実装していましたが、その際には100台程度で1周させるのに10分程度掛かっていました。

それを考慮するとConnectionServerでPowerCLIの以下のコマンドを実行することでシャットダウン以外のVDIのステータスを短時間で取得できます。
PowerCLIは経験値が足りないので、VBScriptと合わせれば以前作成したような各プールごとの利用状況を取得しつつ、ADに対してLDAPでログイン中のユーザIDの詳細情報と合わせた利用状況をリストアップするスクリプトを作成できるでしょう。残念ながら、今VcenterのDBから個人割り当てのVDIの情報と移動プロファイルとフォルダリダイレクト対象者を処理するスクリプトを優先して作成する必要があるため、このスクリプト作成は当面先になると思います。

> Get-RemoteSession -pool_id 『プール名』
session : 160
Username         : ドメインFQDN\ユーザID
pool_id          : tcv-pl013
startTime        : Thu Jan 05 08:36:43 JST 2017
session_id       : ドメインFQDN\ユーザID(cn=s-1-5-21-2620938040-1617289647-3374191743-4885,cn=foreignsecurityprincipals,dc=vdi,dc=vmware
                   ,dc=int)/1@cn=9b09f52d-7a3c-4f8a-abcf-c1176e1cbc10,ou=servers,dc=vdi,dc=vmware,dc=int.cn=tcv-pl013,ou=server g
                   roups,dc=vdi,dc=vmware,dc=int:PCOIP:0:DESKTOP
DNSName          : vishare-c001.hoge.Local
duration         : 23 minutes
lastSessionTicks : -4402145
state            : CONNECTED
protocol         : PCOIP

想定しないことをしてみた

これまでシックプロビジョニングな個人割り当てのVDIがメインだった環境にComposerと移動プロファイルとフォルダリダイレクトを導入するためにFlexPodをVDI環境として増設しました。さて、うちのユーザだけでなく、システムメンバに対しても想定しない事を想定しなければならないためComposerで利用するVDIのイメージに対してこんなことを実施してみました。

個人割り当てのVDIではsysprepしてからテンプレートに変換し、そのテンプレを使ってデプロイするという手順だったので、同じくテンプレとしてスナップショットを取るVDIにsysprepしてからスナップショットを取って、そのスナップショットを参照するようにプールに設定してみました。sysprepによるハード初期化時にエラーが出てWindowsが起動しませんでした。

手順書にスナップとる前にsysprepするなよ?!するなよ?!と書かねば。。。orz

シンプロビジョニングのVMDKファイルの圧縮

一言:NFSでは出来ません。
vmkfstools --punchzeroを打っても『Not a supported filesystem type』と帰ってきます。
諦めてOS領域のHDDにでもvMotionしましょう。

9月に入れたFlexPod(FAS8020)ですが、当初Cristal DiskMarkのランダムリードが全くと言って良いほどスペックが出ませんでした。今はキャッシュなしで140-190、初めは30-80程度でした。まだエラーパケットが出るので設定をもう少し詰めるつもりです。

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)

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2058959