閑話休題
ふと思い出した程度のしょうもない話を。
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さんに奪われるという事もあります。
ゲストOSのCPUとメモリの節約をするには
どう考えるか？私は集約化もそうですがESXを安定化させるにはゲストOSのCPUとメモリの節約をすることとキャッシュを出来るだけ有効化することが重要と考えます。正直なところ、ブートストーム対策としては各種キャッシュ、Storage Accelaratorやストレージそのもののキャッシュが非常に有効です。
もう少ししたら今構築中のNetAppでのSSDをキャッシュとして利用する場合のスペック測定が出来ますので、そちらで触れさせて頂きます。正直なところオールフラッシュにしてしまえば関係ありませんが、日本HPがSSDの発注先をIntelだけにすることで低下価格化するという発表もされましたので、安価に構築する場合でも高スペックな環境が組みやすくなってきていることは間違いないと思います。
さて、本題ですが効率的にVDIのCPUとメモリリソースを削減するには、ですがそんな難しいことは行いません。利用者が意図しないプロセスが動かないようにするだけです。そのためには、例えば画面での無駄な処理としてガジェット（そもそもMSがサポート打ち切っている）、エアロ、フォントのスムージングなどを無くし、出来るだけWindowsXPライクに近づける事。次に、音声系ですが例えばログイン時のサウンドやエラー音などですが、事務作業中にそんなの必要ですか？必要ないですよね？ということはこれらもある意味不要。次にサービス関係、例えばWindows Defender、デフラグ、ブランチキャッシュ等々です。また、VDIですので常時ウィルススキャンは必須ですがVDI上で実行するとvCPU2にしてメモリ割り当ても32bitの場合でも2GBから3GBに増やす必要が出るでしょう。そういった観点からvShiled EndPoint（今はNSXに統合されたり機能制限されている）を利用するとユーザが利用する際にバックグラウンドで動作するプロセスによるもたつきやラグを抑えることが可能となります。
pc管理に便利なツール
VDI触れなさいよ、という意見が出る時期だと思いますが設定しているポリシーとか棚卸ししないといけないのでそれまでの閑話休題的なものと思ってください。
私がよく使うツールでpsexec pslist pskillがあります。
https://technet.microsoft.com/ja-jp/sysinternals/pxexec.aspx
どれもコマンドプロンプトで実行するツールですが、psexecは接続先にコマンドを発行させるツール、pslistは接続先の稼働中のプロセスをリストアップするツール、pskillは接続先のプロセスをプロセスID指定で終了させるツールです。
psexecは兎も角pslist /pskillが何故挙げられたかですが、office20xxを利用されていると良くあると思いますがExcelが特に応答なしになってタスクマネージャーでもプロセスが終了できないケースがあると思います。そういったときにpslistで対象アプリのプロセスIDを確認しpskillで終了させると即落ちます。
これらツールに関してですがWindowsfirewallが停止している場合でも以下の点に注意が必要です。
1: これらのツールを利用するときは接続先、接続元両方で管理者権限が必要
→要するに右クリックの別のアカウントで実行からdomain admin等でのコマンドプロンプトの実行するかDomain administratorでのログインが必要になります。
また、ドメイン参加しているPCからworkgroupのPCへ接続する場合はローカルAdministratorのパスワードを合わせてドメイン参加PCにローカルAdministratorアカウントで実行すれば接続可能です。
２．リモートプロシージャコールのサービスがデフォルトでは停止していると思いますが、サービスを起動するとpslist / pskillが利用できるようになります。
サーバで使うゴールドディスクって
何よ、それ？という人が多いと思います。これは私が外資系金融機関で勤務していた時に勤務先が採用していた方式でシステムをリリースする際にOS領域のバックアップを取るのにNorton Ghost等のソフトウェア方式では時間が掛かるため時間短縮のためにとっていた方式です。これでシステム飛びましたとか出来ないやんけーとかのクレームは冗談抜きで受け付けません、自己責任でお願いします。
ついでにいうとメーカーにこの話をしても良い顔されません。確実に苦虫潰した反応されます。理由は簡単で同じ容量のHDDでもメーカーが異なると容量が合わないというエラーになって出来ない場合があるからです。
(要するに体験したことがあるのです)
前提としてサーバに刺さっているHDDにOSを入れていることが前提ですがSSDもできるはずです。Raidは1か0+1のみで5や6、JBODは対象外です。また、更新されるデータが入っている場合はそのデータがバックアップから戻せることが前提です。OSについてはWindows/Linuxどちらもいけますが、Active DirectoryのドメインコントローラはサーバのSIDチェックがあるのでこの方式でバックアップしたものを差しても、他のドメコンから拒否されて隔離されますので出来ません。
やり方は簡単です。バックアップ時はOSを落とす、HDDを抜く、電源を上げる、HDD差してリビルドする、です。なお、順番を間違えて先にHDDを差して電源を入れた場合データは保証できません。
バックアップを戻すときは、電源を落とす、Raid1で2本+hotspareなら三本とも抜く(わからなくならないように注意)、バックアップをHDDを差す、電源入れて問題がなければ抜いたRaid1ディスク一本とホットスペアを差す、です。
なお、バックアップから戻したときにサーバのドメイン認証が出来ない場合があるのでその場合はドメイン再参加しましょう。
このバックアップの良いところはWindowsupdateでおかしな挙動を示すと困る場合にサーバのOS落としてディスクを抜いてバックアップ、電源入れてUpdateする、問題なければディスクを差すという対応が可能な一方で電源を落としたことでマザー故障で起動しない場合が希にあるので5年以上稼働するサーバではお薦めできません。またこのゴールドディスクを作成するタイミングを変更することで仮想OSのテンプレートのように使い回すことも可能です。
そういうことで金融機関では同じ型番の機種で統一することで、メモリやCPU追加、上記のような作業でマザー故障した場合に、同じ型番のサーバに交換して即時リカバリ出来るようにしていました。仮想が進んだ今、やってるかどうかは知りません。
VDIのvSphere Client(Web込)インベントリ削除は注意が必要
非常にお久しぶりな更新です。
View5.xから6.2.3にアップデート作業のひとつにvShield EndPoint製品のアップデートがありました。これをアップデートした瞬間に発生したトラブルのひとつにvDSの接続に関するテーブルのデータ不整合があります。
この症状により発生した症状として
①起動したままのVDIが接続できない。
→シャットダウンして電源ONで回復
②シャットダウンして電源ONで回復しなかったもの
→vNIC付け直し
③vSphere Clientで電源が入らなくなったVDI
→vSphere Clientのインベントリから削除
で、対応しています。が！『vSphere Clientのインベントリから削除』を行う際に
Connection serverのプールからVDI登録を削除せずに『インベントリから削除』を行うとConnection ServerのLDAPにもvCenterDBにもどこにも登録情報が見当たらない状態になります。(特にフルクローンの流動プール)
その場合VMXファイルの読み込みで戻した後にvmxファイルのmachine.idの値をNULL化->VDI起動->プールに登録という操作が必要になります。
なお、この件はvCenter4でサポート外のWindows2012を起動するためにUEFI BIOSファイルに関する記述を追加したことがある私もさすがに最後までこの値が原因と思っていなかったので最後までここに原因があると思っていませんでした。
6.2.3へのアップグレードに関しては別途報告します。
