【第4回】シンクライアントの構築・運用フェーズに検討すべきこと
〜仮想PC型（VDI）シンクライアント『Horizon View』編〜

Horizon View 6にも、Standard / Advanced / Enterpriseの3つのエディションが存在する。

Horizon View Standardがあれば、VDIを実行するためのほぼすべての機能を実現できるが、Advancedを利用すると、ホスト型のアプリケーション配信（RDSH）、つまり、Citrix社のXenAppとほぼ同様の機能を使えるようになる。また、分散型ストレージのVSANが利用できるため、共有ディスクレスで高可用性を確保したインフラも構成可能だ。

最上位のEntepriseでは、VMware社のキャパシティ管理・パフォーマンス分析ツール（vCenter Operations）の拡張機能であるvCenter Operations for View（V4V）やワークフローツールも利用できる。

Standardは基本機能、AdvancedはVDIにプラスアルファをもたらす機能拡張、Enterpriseは大規模運用のための機能が付加されていると考えれば良いだろう。

実は、Horizon ViewでVDIを構築するためには、コネクションブローカーと管理サーバーを兼ねるView接続サーバーだけあれば十分だ。接続先となるデスクトップは、View Agentが導入できるものであれば、物理PCでも仮想マシンでも問題ない。ただし、Horizon Viewの機能をフル活用するためには、VMware社の仮想化基盤であるvSphereとその管理サーバーであるvCenterサーバーが必要だ。

また、View Composerのコンポーネントは、vCenterサーバーに実装することも可能だが、大規模な環境の場合には、負荷を考慮して単独サーバーとして実装したほうがよい。

View関連のログは、管理向上のために、データベースに格納される仕組みになっている。管理画面（View Administartor）からログを管理するためには、SQL Serverが必要だ。データベースが必要なvCenterやView Composerで利用するSQL Serverを流用するのが効率的である。

リンククローンデスクトップの管理・運用には、作成と削除以外に3つの主なオペレーションがある。ここでは、各オペレーションの利用用途について解説しよう。

まず1つ目が、Refeshだ。Refreshは、稼働する上で発生する差分情報が格納されるデルタディスクを初期化し、リンククローンデスクトップを展開時の状態に戻す作業である。

2つ目は、ベースイメージを更新するためのRecomposeだ。VDIでは、数千台規模のデスクトップを管理する場合、パッチ当てやアプリケーション更新などを一台一台実施していくのは非現実的である。Recomposeは、更新したマスタイメージをベースに、レプリカVMを再展開し、リンククローンデスクトップのOSイメージを新しく切り替えることができる。これにより、より効率的なデスクトップ管理が可能になる。

3つ目は、Rebalanceだ。リンククローンデスクトップを展開したデータストアの容量が想定以上に足りなくってしまった場合や、パフォーマンスの観点から同データストア内のリンククローンデスクトップの数を減らして、別のデータストアへ移したい場合に、リンククローンデスクトップを別のデータストアに再配置することができる。

※ vSphereには、Storage vMotionと呼ばれるオンラインで仮想マシンのデータストアを変更する機能があるが、リンククローンデスクトップに対してStorage vMotionを実施した場合に、すべて実体になってしまうため、Storage vMotionは利用できない。

Horizon Viewでリンククローンデスクトップを利用する場合、ReComposeもしくはRefreshは、ほとんどのケースで必要なオペレーションだ。どちらのオペレーションも、仮想デスクトップの停止を伴うため、ユーザーはシステムを利用できなくなる。

流動プールで構成している場合は、接続できるデスクトップを最低限準備しておくことでシステム停止を防ぐことができるが、専用プールの場合は、対象のデスクトップが処理されている間、ユーザーは接続できないことになる。Recomposeは、再展開と同等のオペレーションとなるため、高速プロビジョニングと言えども、それなりの時間はかかる。ユーザーの作業に支障がでない時間帯にメンテナンスを実施できるよう、週次や月次でのメンテナンス時間を運用前に定義しておくことをオススメする。

また、リンククローンデスクトップへのオペレーションの同時実行数には制限があるため、数が膨大になると、メンテナンス時間に収まりきらないケースも発生してくる。同時実行数は、vCenterサーバーとView Composerに依存しているため、ある程度の規模になる場合には、vCenterサーバーとView Composerを複数配置して分散するなども検討しよう。

VDIでは、仮想デスクトップをプールと呼ばれる単位で管理するケースが多く、プールに対して、ユーザーとの紐づけや、接続設定、プロビジョニングなどのポリシーを適用していく。

ユーザーの紐づけという観点において、永続プールと非永続プールの2種類に分けられる。

永続プールでは、ユーザーと仮想デスクトップの紐づけが決定されると、そのユーザーは必ず紐づけられたデスクトップにログインすることになる。業務において、ユーザーが個別にアプリケーションを導入しなければならない場合に適している。

それに対して非永続プールでは、ユーザーと仮想デスクトップが紐づけられることはなく、ユーザーがログインした時に利用可能なデスクトップにログインするため、ログインするデスクトップは毎回異なる。定型業務のみの部門や、PC教室のような環境に適している。Hoziron Viewでは、プールを作成する際に、専用プール（永続プール）と流動プール（非永続プール）のどちらかを選択する必要がある。

ユーザーの紐づけのほかに、プロビジョニングポリシーをデスクトッププールごとに設定できる。Horizon Viewでは、手動プールと呼ばれる展開済みの仮想デスクトップや物理PCをプール化する方式と、条件に合わせて仮想デスクトップの台数を動的に変更する自動プールの2つの方式がある。

自動プールでは、常に指定の台数分の空きデスクトップを用意しておくなどの設定ができ、ユーザーがログインして空きデスクトップ数が指定台数を下回った場合には、自動的にデスクトップがプロビジョニングされ、ユーザーがログオフして空きデスクトップ数が指定台数を上回った場合には自動的に削除される。

リンククローンで構成する場合は、必然的に自動プールを選択することになる。フルクローンの場合でも、自動プールによるプロビジョニングは可能である。

VDIでは、適切なサイジングをしておかないと、パフォーマンス不足による性能低下に陥りやすい。特に、VDIのI/O要求は、ランダムアクセスに加え、Read/Write比も2:8などと言われており、ディスクに最も厳しい条件が揃っている。ストレージのサイジングや選定は非常に重要な項目だ。

今回は、ストレージ設計でもっとも重要なポイントである、1秒間にストレージが処理できるI/Oリクエストを数値化した「IOPS（Input Output Per Second）」と、データの整合性を担保するためのファイルシステムの排他制御とVDIの関係について解説する。

適切なストレージを選定するには、そのシステムにどれだけのIOPS要求が求められるのかを事前に把握しておく必要がある。例えば、Windows 7における1台あたりのIOPS指針は、通常ユーザーで10～15IOPS、パワーユーザーで15～25IOPS、ヘビーユーザーで25～50IOPS程度と言われている。たとえば、通常ユーザーが1,000名のVDI環境では、10,000～15,000IOPSが単純に必要になってくる。また、ストレージ装置ではディスクの冗長化のためにRAIDを組むが、書き込み要求はRAIDレベルによってペナルティ値が変わってくるため、考慮する必要がある。

FC-SANやiSCSIのように、ブロックデバイスで提供するストレージをvSphere ESXiが利用する場合、VMFSと呼ばれるファイルシステムが利用される。VMFSは、複数のホストから共有可能なファイルシステムで、排他制御には、「SCSI-2リザベーション」と呼ばれる技術を利用している。排他制御を行うには、仮想マシンの新規作成や、仮想マシンの起動といった、VMFSのメタデータの更新する操作が必要になる。

SCSI-2リザベーションは、LUN単位でロックを行うため、同一のデータストアに多くの仮想マシンが存在する場合は影響を受けやすい。特に、VDIではサーバーの仮想化に比べて多数の仮想マシンによる電源の起動・停止を伴う処理が発生しやすいため、パフォーマンスに影響を及ぼす場合がある。これを改善するために、vSphere 4.1以降では、共有ストレージの機能とハイパーバイザーを連携させるVAAI（vStorage API for Array Integration）が実装されており、その中のATS（Atomic Test and Set）と呼ばれる機能により、LUN単位よりも粒度を下げた単位での排他制御が可能になった。これにより、より多くの仮想マシンをデータストアに格納してもパフォーマンスへの影響を最小限に抑えられるようになる。Horizon Viewのストレージには、VAAIに対応しているストレージを選定すべきだろう。

ただし、vSphereのデータストアには、FC-SANやiSCSIのブロックアクセス以外に、NFSによるファイルアクセスでの提供も可能である。その場合の排他制御は、ロックファイルを利用するため、SCSI2-リザベーションのような影響は受けない。NFSとVDIの相性は非常に良く、NFSストレージの選択も積極的に考えるとよい。

リンククローンデスクトップは、RefeshやRecomposeによる初期化で、ユーザーデータも消失してしまう。それを回避するために、プロファイルデータをオフロードする仕組みが必要だ。これは、第3回目のXenAppにおけるユーザーデータ設計で説明した、移動ユーザープロファイルとフォルダリダイレクトを組み合わせれば、ほぼ問題ない。

XenAppと同様に、移動ユーザープロファイルの場合は、ログイン時にすべてのプロファイルデータをファイルサーバーから読み込み、ログオフ時にはすべてのデータを書き込むため、ログイン・ログオフ時間が長時間化しやすい（※詳細は、第3回「XenAppの構築ポイント」を参照）。

Horizon Viewでは、移動ユーザープロファイルを補完するPersona Managementという機能があり、ログオン時に最低限のデータのみを持ってきて、ログオン完了後にバックグラウンドでデータの転送を継続させることができる。さらに、10分おきに差分をファイルサーバにアップロードすることで、ログオフ時の処理時間を短縮している。

管理面では、Persona Managementの管理用テンプレートが用意されており、フォルダリダイレクトの設定もここからできる。、グループポリシーを編集して行う標準機能よりも、実装の敷居が低い。エディション制限もないため、移動ユーザープロファイルとフォルダリダイレクトを利用する場合には、本機能を積極的に活用することをオススメする。

仮想デスクトップのバックアップは、専用プールで利用しているかどうかがポイントとなる。

流動プールは、ユーザー個別の設定がないことが前提となっているため、障害が発生した場合にはマスターから再度クローンで展開をすればよい。リンククローンもRefreshなどで初期化されるため、ックアップを取得する必要はない。マスターとなる仮想マシンのバックアップだけを取得すればよい。

一方、専用プールで利用している仮想デスクトップは、ユーザーの固有情報が格納されているため、バックアップの取得は必要だ。ただし、規模によっては通常のバックアップ方法では、1日で取得しきれないという問題が発生する可能性がある。その場合に有用な手段となるのが、共有ストレージのスナップショット機能だ。NetApp社のVSC（Virtual Storage Console）などは、vSphere基盤と連携し、仮想マシンの台数に関係なくバックアップを瞬時に完了できる。専用プール+フルクローンで利用する場合には、共有ストレージにVSCのような機能が備わっていることも確認し、機器選定を行うことをオススメする。

今回は、仮想PC型シンクライアント（VDI）の代表格である、VMware社のHorizon Viewでシンクライアントシステムを構築する際のポイントを解説してきた。規模や運用フェーズまで想定してシステムを設計することが必要だ。次回は、導入コストを最適化し、適切な環境を構築するためにはどうすればよいか、導入時のコスト削減を方法について紹介する。