MENU
シンクラ概論

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

2014/09/29

第3回目では、プレゼンテーション型シンクライアント製品の代表格であるXenAppの構築ポイントとその運用について解説した。今回は、仮想PC型シンクライアント(VDI)製品の代表である、VMware社のHorizon View 6の構築のポイントとその運用方法について解説する。

エディション設計

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 Standard Horizon Advanced Horizon Enterprise
仮想デスクトップインフラストラクチャ(View)
クラウドインフラストラクチャ
(vSphere Desktop/vCenter Desktop)
アプリケーション仮想化(ThinApp)
アプリケーション仮想化(RDSH)
仮想ストレージ(VSAN)
※vSphere5.5 Update1から利用可能
物理デスクトップのイメージ管理(Mirage)
仮想デスクトップのイメージ管理(View+Mirage)
キャパシティ管理(V4V)
ワークフローの設計と自動化
(vCenter Orchestrator+デスクトッププラグイン)

すべてのエディションに、vCenterやvSphereのフル機能を利用できる「for Desktop」のライセンスが同梱されるが、このライセンスで稼働しているvSphere上でサーバーを稼働させる場合には、Horizon Viewに関連するサーバーの稼働のみしか許可されていない点に注意が必要だ。

スクロールできます

全体構成設計

実は、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を流用するのが効率的である。
機能概要
vSphere ESXi 仮想デスクトップを稼働させるためのハイパーバイザー
vCenter サーバー vSphere仮想化基盤の統合管理サーバー
View接続サーバー ユーザーからのデスクトップへの接続要求を管理する、コネクションブローカーとViewの管理を行うView Administratorが実装される
Viewセキュリティサーバー VPNなどを利用せずに、外部からView環境へ接続する際にプロキシホストとして機能することで安全なアクセスを実現する
View Composer リンククローンテクノロジー用いて高度な仮想イメージ管理を行う
イベント構成データベース
(SQL Server)
View関連のイベントやログ情報を格納するデータベース

※★マークは必須コンポーネント

スクロールできます

構成イメージ

View Composer設計

View Composerによるリンククローンデスクトップは、ユーザー用に展開される仮想デスクトップはすべて、レプリカVMと呼ばれる仮想デスクトップの実体を参照しており、差分を各仮想デスクトップのVM内にデルタディスクに格納している。

高度かつ高速なデスクトップの展開とディスク容量の削減に効果的だ(※詳しくは、第2回参照)が、より効率的に使用するためのポイントを紹介する。

適切なディスク配置

パフォーマンス低下や、データの肥大化を回避するために、レプリカVMとデルタディスクの配置に注意を払う必要がある。

一斉に仮想デスクトップを起動する場合、レプリカVMのデータへのアクセスが集中するため、展開数が多いとパフォーマンスへの影響が懸念される。そこで、レプリカVMを配置するデータストアと、リンククローンデスクトップを展開するデータストアを明示的に分け、I/O要求がReadのみのレプリカVMのデータストアをSSDで構成することで、大幅なパフォーマンス改善できる。

また、デルタディスクに格納された差分情報は、ブロック単位で管理されるため、ページファイルやtempファイルなどは、大きな差分データになりやすく、デルタディスクを肥大化させる要因になりやすい。そこで、リンククローンデスクトップのページファイルやtempファイルを、OSディスクとは別のディスクにリダイレクトするディスポーザブルディスクと呼ばれる機能を使って肥大化を回避する。ディスク容量にあまり余裕がない状況では、この様な機能も率先的に利用するとよい。

※OSディスクとディスポーザブルディスクは、同一のデータストア内に配置される。

リンククローンに対するオペレーション

リンククローンデスクトップの管理・運用には、作成と削除以外に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つの方式がある。

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

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

Horizon Viewの冗長化設計

Horizon Viewの冗長化のポイントは3つある。


  1. 仮想デスクトップが稼働する仮想化基盤のvSphereの可用性

  2. 仮想化基盤を管理するvCenterサーバーの可用性

  3. ユーザーがデスクトップ環境を利用する際に接続するView接続サーバーの可用性


Horizon Viewは、Active Directoryと連携をするため、第3回のXenAppの冗長化構成でも解説した、Active Directoryの冗長化も必須となるが、今回は、この3つのポイントに絞って解説する。

vSphere冗長化

実際にユーザーが接続して利用する仮想デスクトップは、vSphere上の仮想マシンとして稼働する。vSphere ESXiのホストが障害で停止すれば、ホスト上で稼働している仮想デスクトップも停止する。

流動プールの場合は、空いている仮想デスクトップが存在すれば、今まで接続していた仮想デスクトップが障害などで停止したとしても、再接続すればさほど影響ない。

しかし、専用プールの場合は、ユーザーと仮想デスクトップは1対1で紐づいているため、対象の仮想デスクトップが復旧するまで、ユーザーは再接続できなくなってしまう。Horizon Viewのライセンスでは、vCenterやvSphereの最上位エディションであるEnterprise Plusの冗長化機能であるvSphere HAも利用できるので、この機能で可用性を確保できる。しかしその場合、共有ストレージやVSANのようなそれに代わる仕組みは必要だ。

vCenterサーバー(View Composer)冗長化

Horizon View環境におけるvCenterサーバーの役割は、View Administratorでデスクトッププールを構成する際のインベントリ提供、ユーザー接続時の電源管理、リンククローンないしはフルクローンでのプロビジョニング時のvSphereレイヤーの管理だ。ユーザーのデスクトップ操作はもちろん、接続やログオフ時にvCenterサーバーが停止していても基本的には問題はない。では、どのような場合に問題になるか見ていこう。

View Composerによるリンククローン構成では、肥大化するデルタディスクを、Refreshによって定期的にメンテナンスする必要がある。Refreshは、時間や曜日を指定してスケジューリングすることや、ユーザーのログオフ時に自動的に実行するようにも設定できるが、vCenterサーバーとView Composerが起動している必要があるため、特に可用性を考慮しなければならない。

vCenerサーバーを仮想マシンとして構成し、vSphere HAの機能で最低限の可用性を確保するのが最も現実的だろう。(※以前は、vCenterサーバーとView Composerの冗長化にはVMware社が提供しているvCenter Heartbeatを利用することでクラスタ化することができたが、2014年6月2日をもって同製品は提供を終了している。)

View接続サーバー冗長化

View接続サーバーは、ユーザーからの接続要求を仮想デスクトップに振り分けるコネクションブローカーの役割を担う、Horizon Viewの軸となるコンポーネントである。当然、障害時にユーザーはシステムを利用できなくなるため、冗長化は必須となる。

View接続サーバーの構成情報は、WindowsサーバーのADAM(Active Directory Application Mode)を利用しており、Active Directoryと同様に複数のサーバーに複製することが可能である。そのため、View接続サーバーの冗長化は、2台目以降のインストール時にレプリカとしてインストールするだけでよく、ユーザーはどのサーバーに接続しても同じ情報が参照できる。ただし、障害時などはユーザーによって接続先を明示的に変更する必要があるため、外部ロードバランサーやMicrosoft NLBなどを利用して、障害時にユーザーが意識しなくてもよい構成を検討する必要がある。

Viewセキュリティサーバーの冗長化も、基本的には同じものを横並びにし、外部ロードバランサーを利用する構成になるが、Viewセキュリティサーバーは、必ずView接続サーバーと1対1のペアになる点に注意が必要だ。そのため、ViewセキュリティサーバーとペアのView接続サーバーに障害が発生した場合、そのセキュリティサーバーから別のView接続サーバーには接続ができないという事象が発生する。

障害(全断)時の影響度 冗長方式
Active Directory Active Directory標準機能
vSphere ESXi vSphere HA
vCenterサーバ vSphere HA
View接続サーバ View標準機能+負荷分散システム
スクロールできます

ストレージ設計

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

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

IOPSの把握

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

IOPS算出式

  1. 仮想デスクトップ数 x IOPS指針(*1) = ホストIOPS
  2. ホストIOPS x Read比 + ホストIOPS x Write比 x RAIDペナルティ係数(*2) = 必要IOPS
  • *1:【IOPS指針】
  • ノーマルユーザー = 10〜15
  • パワーユーザー = 15〜25
  • ヘビーユーザー = 25〜50
  • *2:【ペナルティ係数】
  • RAID5 = 4
  • RAID6 = 6
  • RAID10 = 2
スクロールできます

VMFSと排他制御

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におけるユーザーデータ設計で説明した、移動ユーザープロファイルとフォルダリダイレクトを組み合わせれば、ほぼ問題ない。

移動ユーザープロファイルの補完機能「Persona Management」

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

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

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

バックアップ設計

Horizon Viewにおいても、システム復旧のためのバックアップは必要不可欠だ。構成や利用方法によって、コンポーネントに対する重要性や取得ポリシーが異なってくるため、ここでは各コンポーネントごとの基本的なバックアップ方法について紹介する。

View接続サーバーバックアップ

View接続サーバーは、ADAMに情報を格納しているが、その中で最もクリティカルなものは、専用プールでのユーザーとデスクトップの紐づけ情報だ。自動プールの場合は、プールを再作成後の初回接続時にランダムで割り振られるため、今までのデスクトップとは違うものが割り当てられる可能性が高く、かなり致命的な問題となる。

Horizon Viewでは、ADAMのバックアップ機能が標準で実装されており、指定した間隔(1時間/2時間/6時間/12時間/日次/2日おき/週次/隔週の中から選択可能)で自動バックアップされる。規模や構成にもよるが、最低、日次でバックアップしておきたい。

リストアは、View接続サーバーにvdmimportと呼ばれるADAMのバックアップからインポートするコマンドが用意されているので、こちらを利用すれば問題ない。

vCenterサーバーバックアップ

vCenterサーバーの情報には、クラスタ構成やパフォーマンスデータなどvCenterのデータベースにしか格納されないものと、仮想マシンやデータストアなど配下のESXiにも構成される情報の2種類に大きく分かれる。

後者は、vCenterサーバーにESXiを再登録するタイミングで、ESXiの情報を使ってvCenterサーバー側のデータベースに反映することができる。そのため、複雑なクラスタ設定やDRS、分散仮想スイッチなどを利用していない場合には、初期からの復元もさほど難しくもない。

vCenter情報のバックアップは、必須とまではいかないが、再構成の際の手間や設定ミスを回避するためにバックアップを取得しておく方が無難だ。バックアップ方法は、SQL Serverのバックアップに準拠する。

View Composerバックアップ

View Composerは、データベースに展開したリンククローンデスクトップの情報を格納している。レプリカVMとの紐づけや、リンククローンデスクトップのホスト名、配置しているデータストアなどが該当する。データが損失した場合、RefreshやRecompose作業も実行できなくなり、対処法としては強制的に削除後に再展開となってしまうため、バックアップの取得は非常に重要である。データは、SQL Serverに格納されているため、vCenterサーバーのバックアップに合わせて取得しておこう。

vSphere ESXiバックアップ

vSphereのESXiは、以前のESXに比べ、非常にサイズの小さいハイパーバイザーで、インストール時間も短縮されている。また、Horizon Viewで利用できるvSphere for Desktopでは、Enterprise Plusの機能にあるクラスタ単位で構成情報を取得して展開できるホストプロファイルも利用できる。そのため、vSphere ESXiは、一台一台システムバックアップを取得すのではなく、クラスタごとにホストプロファイルを取得し、有事の際にはESXiを再インストールしてホストプロファイルを適用する手順を利用することで、1~2時間程度での復旧が可能だ。

仮想デスクトップバックアップ

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

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

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

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

まとめ

  • 規模や機能面、運用フェーズを考慮して、必要なエディションを選択しよう
  • 設計フェーズで検討すべきは、以下の6つ
    • View Composer設計
      高度かつ高速なデスクトップ展開を効果的に実現する構成を検討しよう
    • デスクトッププール設計
      流動プールと専用プール、手動プールと自動プール。使用用途に応じて、プールの設定を決めよう
    • 冗長化設計
      一部のシステムが故障してもサービス停止を防げるように、規模と要件に合った冗長化構成を用意しよう
    • ストレージ設計
      パフォーマンスや性能を最大限に引き出すために、適切な機器選定やサイジングを実施しよう
    • ユーザーデータ設計
      どのサーバーに接続しても、ユーザーは同じ環境を提供されなければならない。ユーザーデータの一貫性を保持する仕組みが必要
    • バックアップ設計
      サービス停止時間を最小限に抑えるために、コンポーネントや影響度に合わせたバックアップの仕組みを用意しよう