低コストでも集約化を目指すには

9月10月とXX連勤で徹夜2~3日という不思議な勤務状況が続いているため
更新の余裕がなかなかありませんでした。

VDIでは有能なベンダが付くか、ハイスペックな環境を用意できるかしないと
トラブルを回避、というより切り分けが出来ずに頭を抱えるケースが多いです。
ではそうならないように初めて導入する場合にどうしたら良いか?ですが
まずは『フルクローンVDI』を展開予定数の3割程度ユーザに展開してみましょう。
そうすると『ここが使いにくい』『あそこがどうたら』と文句が出てきますので
それをVDIテンプレートに修正として盛り込んでいきある程度ステーブルだと
判断出来るようになったら次のステップとしてComposerと移動プロファイル環境を導入し、まずはディスクを集約化し次にCPUとメモリの集約化に挑むほうが良いと思います。

カスタマイズ仕様マネージャのデプロイスクリプト

デプロイスクリプトですが、使い勝手の良い面と悪い面があります。

1.sysprepによりOS破損させてしまうアプリケーションがサイレントインストール
  可能であればを標準展開する場合にsysprep後に実行されるデプロイスクリプト
  展開可能。(良い点)
2.デプロイスクリプトはPCのLocal Administatorで実行されるため
  後付けでドメインに関する権限を処理したい場合などや共有フォルダにある
  インストーラを実行させることは難しい。
  ※出来ないとは言いません。local Administratorのパスワードが一致してれば、とか
   共有フォルダへコマンドで認証を通して、とか頑張ればWindows 7以降でもいけますが
   正直私は頑張りませんでした

なお、デプロイスクリプトがどのアカウントで実行されているかは
デプロイスクリプトにwho am i コマンドの結果を出力するように仕込めば
確認できます。

VDIテンプレートについて

流石に3日で2連徹夜での作業があったため準備で時間が空いてしまいました。
ブログ続ける人ってすごいですね、3日坊主体質なので息切れしそうです。

VDIテンプレートについてですが、正直なところ仮想サーバ以上に『会社による』と言ってよいでしょう。
どのように違うかというと会社の方針としては
 『単に事務処理が出来ればいい』
 『Acessなどを利用する』
 『3DCADを始めとするVDI環境にグラフィックボードを導入した環境』
 『既存PCをそのままP2Vで移行もしくはそれに準じた環境』
 『予算については気にしなくていいから既存環境並み以上のスペックを』
といったところでしょうか?

また、この問題以外に
 『予算がないから限界まで機器投資を縮小したい』
 『技術がないからあまり難しいことはできない』
といった問題がVDIテンプレート作成には関係してきます。

また、作業分界点の関係上発注したベンダはVDIテンプレート作成については、断ってきますのでそのつもりで臨む必要があります。

View6.2.3以降のゲストOS関して

先日View6.2.3にアップデートした後にVDIに関して気になっていることがあります。
それは『アップデートしてからやけにメモリ使用率が高い(約120-30MBほど)』ことです。

気になってサービスを確認しましたところ、View5系と6系ではサービスの構成が変わっており、ThinPrintはなくなっていますし、BlastとvRealizeが追加(V4Vから変更ですが)になっているようです。6.2.3だとLinuxサポート用としてBlastが入ってきたという認識ですし、私は『View5系でv4vは使い勝手が悪いため不要』という結論を出しています。また、6.2.3へアップデートする際に増設もしているのですが、その際にvRealizeはライセンス自体も打ち切ってそれぞれのvアプライアンスは削除してしまっています。

本題に戻りますが、上記2サービスのうち特にBlastは利用していなくてもメモリを120-130MB程勝手に使用してしまうため、念のためサポートセンタには問い合わせをしていますが、上記2サービスをサービス無効化する予定です。

☆2016/10/11
サポセンからも『Blast / Realizeは利用しない場合は停止可』との回答がありました。
(当然といえば当然ですが、これが原因でサポートしません、と言わせるわけにはいきませんので)

仮想化のサイジングに良いですね

ちょっと時間が空いてしまいましたが、いくつか連投したいと思います。

まずはサイジング関係ですが、これまでベンダにどの程度で見積依頼する際に
必要台数に対する構築規模が見えず提示された金額と構成が妥当なのか判りにくいという問題が仮想サーバ環境以上にVDIにはありました。

その理由としては、VDIの集約性とユーザの利用状況によるということがあげられます。
Networldさんではそれらの計算を行いやすいように計算サイトを作成頂いてまして、その見積を依頼することもできるようになっているようです。

concierge.networld.co.jp

私も試しに既存環境について計算してみましたが、スペックデータを見る限りCPUやメモリについては、私の実稼働から感じる感触と同じ規模感、IOPSについてはチューニングの違いか実環境では18000IOPSに対して、30000IOPSとなっていましたのでかなり実環境に近い数字が出せていると感じています。

 

view 6以降へのアップデートメリットの追記

一つメリットが漏れていました。VMware社のKBでESX5からアップデートすることでIPMIによるアラートが無くなるそうですのでこれが頻発してESXが止まるような環境ではメリットがアルといえます。

個人的にはSSHを有効にしておいてPCから定期的にteraterm マクロを実行して対処させるのでも充分な気がしますが。

Horizon View5.xからView6.2.3もしくは7に上げる理由を探す

どうでもいいといわれると思いますが、プロフの画像をVMUG同様に
NetworldさんのFlexPodのサイトのシス子から拝借。正直グッズがあるなら欲しいぐらいです。

www.networld.co.jp

素直にNetWorldさんから買えばよかった!と思いつつ、宣伝兼ねてリンクをペタペタ。うちの仕事場では第三世代のVDIは(第一は前任者、第二はSAN構成のView)FlexPodにしました。こちらについてはそのうち話をします。


そろそろ本題に入りますが、正直View5系からのアップデートに関しては非常に難しいです。安定稼働している環境程説明が難しいと思います。(実際、私がそうでした)
ちなみに私が構築した環境は、SSOのパスワード期限切れで再インストした以外はES自体も一番長いもので900日以上ノンストップで稼働しており、3年目に入って1Uサーバだったこともあり、サーバ内部のファンが故障で交換せざるを得なくなりメンテで止めはしましたが、ESXのパープルスクリーンもしくは再起動は13+2台のESXで1回しか発生しなかったせいで猶更説明が付けられませんでした。

一度、アップデートについてまとめてみましょう。
 ①サポート期限切れ<デメリット対応>
 ②vSAN / NSX対応<メリット対応、ただしAdvanced限定>
 ③BUG Fix(Connection ServerのUI及びServletパッケージのメモリ問題)
 ④趣味(やってみたかっただけ)
大体こんなところでしょうか?
私の場合は、①と③にVDIを追加することを理由にしましたが、、、
ちなみに③のConnection Serverのバグですが、View5系ではServletのヒープ問題以外に、管理WebサイトのUIでメモリ異常で『VDIを削除』を選んでいるのに『プールを削除』が次の画面で出てきて3-400台のフルプロビジョニングな個人PCを消してしまって始末書を書いていますので、その点考慮すればアップデートの価値はあると思います。
実際、6.2.3では画面上でのLDAP検索もVDIの検索もかなり早く処理されるようになっていますので。

アップデートで気を付けたい点としてはvShiledを利用していて、NSX対応直前のバージョンまで上げていない状態で2段階アップするとアップデートの途中で結構結構大変な目に遭います。私はシーケンスを追跡してリバースエンジニアリングと言って良いレベルで解析しているので、トラブルの殆どをその場で解析&対処できますので1~2,3時間程度のトラブルで対応完了するか、対処できない場合でも2-3日中には目途が付けられるので大事にはなりませんでしたが、vShiledからNSXに変わったことで対処できなければかなり大きなトラブルになってしまう内容が発生します。
この観点から、StandardライセンスのView5系で安定しているならば6.2.3以降に無理矢理アップデートしなくてもよいのでは?と考えており、またユーザ会でもそのように報告しています。

vShiledのトラブルについてはそのうち書きます。