みなさん、こんにちは。新卒 2 年目に突入した氏田 ( Ujita ) です。第 6 回の仮想デスクトップ Blog では、仮想デスクトップを大規模に展開する方法についてお伝えします。
～ はじめに ～
過去のエントリ ( 第 2 回と第 3 回 ) で、仮想デスクトップはマスタイメージを元に Pool 単位で展開されることをお伝えしました。しかし、仮想デスクトップを大規模に展開したい場合、単純に Pool の数を増やすだけでは対応できなくなってきます。なぜなら、各コンポーネントの上限値や仮想デスクトップのパフォーマンスを考慮する必要が出てくるからです。また、管理性や耐障害性の担保といった基盤側の対応も重要です。そこで、今回のブログでは、VMware Horizon 6 のスケールアウト方法だけでなく、仮想デスクトップ環境の管理性やパフォーマンスを担保する仕組みについてもご紹介します。
図 1 . 規模が拡大した場合の考慮事項
§ 1 . Horizon 6 のスケールアウト
§ 1 . 1 仮想デスクトップの管理単位
Horizon 6 には、階層構造の管理単位があり、小さい順から Pool 、Block 、Pod 、Cloud Pod と呼ばれます。図 2 に、各管理単位の仮想デスクトップ数と包含関係をまとめました。
図 2 . Horizon 6 の管理単位と包含関係
Pool や Block といった単位で設計・構築がしっかりできていれば、大規模な環境を構築する場合でも、同じものをスケールアウトさせるだけなので、規模の拡大が容易になります。
それでは、各管理単位について、実際の構成と共に紹介していきます。まずは、小規模な環境からです。
§ 1 . 2 Pool : 500 台程度の小規模な環境
過去のエントリ ( 第 3 回 ) でご紹介したとおり、仮想デスクトップは元となるマスタイメージから Pool 単位で展開されます。仮想デスクトップの管理の最小単位は、この Pool になりますが、500 台程度の規模であれば単一の Pool 、それよりも規模が大きくなる場合は Pool のスケールアウトで対応します。実際には、1 つのプールに最大 2,000 台の仮想デスクトップを展開できますが、再構成時の負荷や処理完了までの時間を考慮しなければならないため、約 500 台 / Pool を上限とすることが多いです。
通常 1 台の ESXi サーバあたりに 100 台程度の仮想デスクトップを動作させます。また、VMware vSphere HA ( 後述 ) 発動時のリソースを確保するために、サーバは N + 1 構成にされる事がほとんどです。従って、500 台程度の規模であれば、サーバ台数は 5 ～ 8 台程度となります ( 図 3 ) 。
図 3 . Pool の構成イメージ ( ～ 500 台 )
§ 1 . 3 Block : 2,000 台程度の中規模な環境
1 つの vCenter Server 配下で管理される仮想デスクトップのまとまりを Block と呼びます。1 つの vCenter Server で管理可能なデスクトップの数は 10,000 台ですが、障害範囲の限定や処理の分散の観点から、vCenter Server あたり 2,000 台程度として導入することが多いです ( ※ vCenter Server が停止した場合、仮想デスクトップの電源や再構成の処理ができなくなりますが、仮想デスクトップ環境が利用できなくなるわけではありません )。
Block は通常、複数の ESXi サーバクラスタから構成されます ( 図 4 ) 。
図 4 . Block の構成イメージ ( 500 ～ 2,000 台 )
なお、ユーザと仮想デスクトップの紐付けを管理する Connection Server は、規模に応じてスケールアウトすることが可能になっています。Connection Server あたりの最大同時接続数は 2,000 台なので、負荷分散や耐障害性を考慮し、Block の規模では Connection Server を 2 ～ 3 台程度導入します。
§ 1 . 4 Pod : 10,000 台までの大規模な環境
大規模な環境には、先ほどの Block をスケールアウトすることで対応します。複数の Block からなる仮想デスクトップ環境を Pod と呼びます。Pod の上限値が 10,000 台となっているのは、セキュリティサーバのクラスタ ( 最大 7 台 = 5 ( Active ) + 2 ( Standby ) ) で対応できる最大同時接続数が 10,000 台だからです。
図 5 . Pod の構成イメージ ( 2,000 ～ 10,000 台 )
Pod の規模になると、仮想デスクトップ環境は複数の Connection Server で構成されることになりますが、図 5 のようにロードバランサを挟むことで、ユーザは接続先の Connection Server を意識せずに仮想デスクトップを利用できます。
§ 1 . 5 Cloud Pod : 20,000 台までの大規模かつグローバルな環境
Horizon 6 より、Cloud Pod Architecture という機能が追加され、最大で 4 つの Pod を連携させ、20,000 台の仮想デスクトップにユーザをマッピングすることが可能になりました。Pod の連携は 2 拠点のデータセンターにまたがって構成できるため、ユーザとデスクトップのグローバルでのマッピングやデータセンターの災害対策にも対応できます ( 図 6 ) 。
図 6 . Cloud Pod ( 10,000 ～ 20,000 台、拠点間連携 )
図 6 のように、ユーザは接続先のデータセンターを意識することなく、他サイトの仮想デスクトップを利用できます。
§ 1 . 6 スケールアウトまとめ
仮想デスクトップの管理単位と上限台数を下記にまとめます。
• Pool ( ～ 500 台 )
– 単一のマスタイメージから展開される仮想デスクトップ数の推奨上限
• Block ( ～ 2,000 台 )
– vCenter Server あたりの仮想デスクトップ数の推奨上限
• Pod ( ～ 10,000 台 )
– Connection Server クラスタ ( 最大 7 台 ) の最大同時接続数
• Cloud Pod ( ～ 20,000 台 )
– 最大仮想デスクトップ数 : 20,000 台
– 最大 4 Pod 、2 拠点間の仮想デスクトップ環境を連携可能
仮想デスクトップ環境を拡大させていく際には、これらの上限値を意識し、管理単位毎にスケールアウトさせていくことが重要です。
§ 2 . 管理性、パフォーマンスの担保
仮想デスクトップ環境では、多くの仮想マシンを同時に管理しなければならないため、管理性やパフォーマンスを担保する仕組みが必要です。ただ、この辺りの仕組みは、長年仮想基盤を提供してきた VMware が一番得意とするところです。そのうえ、Horizon のライセンスには、仮想基盤を提供する vSphere の最上位ライセンス ( Enterprise Plus ) が含まれるため、vSphere 基盤の機能をフルに活用できます。ここでは、これら vSphere の機能を使い、管理性、パフォーマンスをどのように担保していくかについてお伝えします。
§ 2 . 1 vSphere HA ( High Availability ) ～ 障害時に仮想マシンを自動で再起動 ～
vSphere HA は、ESXi サーバが突然停止してしまった際に、そのサーバ上で動作していた仮想マシンを他のサーバで自動的に再起動してくれる機能です ( 詳しくはこちら )。仮想デスクトップ環境用に ESXi サーバクラスタを組む際は、HA を有効にし、サーバが 1 台落ちても他のサーバで仮想マシンを再起動できるようリソースに余力を持たせた設計にします。
図 7 . vSphere HA
§ 2 . 2 DRS ( Distributed Resource Scheduler ) ～ 仮想マシンを自動で最適配置 ～
DRS は、ESXi サーバクラスタのリソース ( CPU 、メモリ ) をプール化し、各サーバの負荷を自動的に分散してくれる機能です ( 詳しくはこちら )。仮想マシンの配置もリソースプールに対して行えるので、どの ESXi サーバに何台の仮想デスクトップを展開するか悩む必要もありません。また、クラスタのリソースを 1 つにまとめて管理できるため、リソースの残り容量が把握しやすいという利点もあります。
§ 2 . 3 分散仮想スイッチ vDS ( vSphere Distributed Switch ) ～ ネットワーク設定を一元管理 ～
リソースプール ( DRS を有効にしたクラスタ ) に対して仮想デスクトップを展開した場合は、負荷分散のため仮想マシンがサーバ間を自由に行き来できる状態になるので、各サーバのネットワーク設定を統一しておく必要があります。クラスタ内のサーバ台数が多い場合、この設定作業には手間がかかりますが、vDS を利用すると、仮想スイッチの設定が各 ESXi サーバへ自動的に配信されるので、設定の手間やミスを削減することができます ( 詳しくはこちら )。特に、業務部門毎に仮想デスクトップのネットワーク設定が異なる場合など、設定が煩雑になる際に有効です。
§ 2 . 4 Storage DRS ～ ストレージの負荷を自動で分散 ～
Storage DRS は、いわば DRS のストレージ版であり、特定のストレージに負荷が集中している場合、仮想マシンのファイル ( .vmdk ) を他のストレージに自動で移すことで、ストレージの負荷を分散してくれる機能です ( 図 8 ) 。Storage DRS は、管理者が指定したデータストアクラスタ内で有効になります。ちょうど、DRS がサーバクラスタ内で負荷分散するのと同じイメージです ( 詳しくはこちら )。
図 8 . Storage DRS
ちなみに、VMFS 形式の LUN あたりに展開すべきデスクトップの推奨台数は、最大で 128 台 ( VAAI 利用時は 140 台 ) なので、仮想デスクトップの数がこれ以上になる場合は、Storage DRS を有効にしたデータストアクラスタに展開することをお勧めします。
§ 2 . 5 View Storage Accelerator ～ マスタイメージの読み取り負荷を低減 ～
リンククローン ( 第 3 回 ) の場合、仮想デスクトップ Pool のマスタイメージは、同時に多くのユーザから読み込まれるため、ストレージの負荷が高くなってしまうという問題がありました。View Storage Accelerator を利用すると、マスタイメージのデータを各 ESXi サーバにキャッシュすることができるので、ストレージの負荷が低減し、仮想デスクトップの起動時間を短縮させることができます。企業で仮想デスクトップを利用している場合、始業時間に仮想デスクトップの起動が集中し、起動時間が遅くなることがあるため、View Storage Accelerator を有効にしておくことをお勧めします。
§ 2 . 6 vSphere機能のまとめ
Horizon の仮想デスクトップ環境では、上記でご説明した vSphere の上位機能が使い放題です。また、今回は説明を省かせていただきましたが、仮想マシン毎にサービスレベルを設定できる機能も利用可能です。Horizon では、これら基盤の機能を積極的に活用することで、管理性を一切損なうことなく仮想デスクトップ環境をスケールさせることができます。
図 9 . vSphere 機能のまとめ
～ おわりに ～
今回のブログ「スケールアウト対応」でお伝えしたかったことは、下記の 2 点です。
① 仮想デスクトップ環境は、管理単位 ( Pool 、 Block 、 Pod 、 Cloud Pod ) を意識することでスムーズに拡張できる
② vSphere の上位機能を活用することで、大規模環境でも管理性が損なわれない
仮想デスクトップ環境をスケールアウトさせる際には、考慮すべき事項が多く、少し難しく感じるかも知れませんが、上記の 2 点をしっかりと押さえることで柔軟な拡張が可能になります ( 実際、仮想デスクトップを 1 万台以上導入されているお客様はたくさんいらっしゃいます！)。
このブログをきっかけとして、一社でも多くのお客様に仮想デスクトップの導入を検討いただけたらと思います。
次回はいよいよ最終回となります。最終回では、川崎さんが Horizon 6 の魅力はまだまだこんなもんじゃないっ！というところをビシッ!!と示してくれる予定です。次回もお楽しみに！
VMware SE 氏田裕次
新卒2年目社員が贈る 仮想デスクトップのキソ！
第１回 仮想デスクトップと Horizon 6 ( with View)
第２回 仮想デスクトップの基本構成
第３回 プール作成と割り当て
第3.5回 View Composer の仕組み
第４回 接続方法と接続元端末
第５回 公開アプリケーションのキソ
第5.5回 ThinAppによるアプリケーション仮想化のキソ
第６回 スケールアウト対応
第７回 完結編、仮想デスクトップと関連ソリューション総まとめ
第 8.1 回 App Volumes を使ってみよう その１
第 8.2 回 App Volumes を使ってみよう その２
