Home > Blogs > VMware Japan End-User Computing Blog > 月別アーカイブ: 2015年7月

月別アーカイブ: 2015年7月

新卒 2 年目 SE が贈る 仮想デスクトップのキソ!・ 第 6 回 ~ スケールアウト対応 ~

みなさん、こんにちは。新卒 2 年目に突入した氏田 ( Ujita ) です。第 6 回の仮想デスクトップ Blog では、仮想デスクトップを大規模に展開する方法についてお伝えします。

~ はじめに ~

過去のエントリ ( 第 2 回第 3 回 ) で、仮想デスクトップはマスタイメージを元に Pool 単位で展開されることをお伝えしました。しかし、仮想デスクトップを大規模に展開したい場合、単純に Pool の数を増やすだけでは対応できなくなってきます。なぜなら、各コンポーネントの上限値や仮想デスクトップのパフォーマンスを考慮する必要が出てくるからです。また、管理性や耐障害性の担保といった基盤側の対応も重要です。そこで、今回のブログでは、VMware Horizon 6 のスケールアウト方法だけでなく、仮想デスクトップ環境の管理性やパフォーマンスを担保する仕組みについてもご紹介します。

 

Horizon_Blog06_yujita_01

図 1 . 規模が拡大した場合の考慮事項

 

§ 1 . Horizon 6 のスケールアウト

§ 1 . 1 仮想デスクトップの管理単位

Horizon 6 には、階層構造の管理単位があり、小さい順から Pool 、Block 、Pod 、Cloud Pod と呼ばれます。図 2 に、各管理単位の仮想デスクトップ数と包含関係をまとめました。

 

Horizon_Blog06_yujita_02

図 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 ) 。

 

Horizon_Blog06_yujita_03

図 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 ) 。

 

Horizon_Blog06_yujita_04

図 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 台だからです。

 

Horizon_Blog06_yujita_05

図 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 ) 。

 

Horizon_Blog06_yujita_06

図 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 台落ちても他のサーバで仮想マシンを再起動できるようリソースに余力を持たせた設計にします。

 

Horizon_Blog06_yujita_07

図 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 がサーバクラスタ内で負荷分散するのと同じイメージです ( 詳しくはこちら )。

 

Horizon_Blog06_yujita_08

図 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 では、これら基盤の機能を積極的に活用することで、管理性を一切損なうことなく仮想デスクトップ環境をスケールさせることができます。

 

Horizon_Blog06_yujita_09

図 9 . vSphere 機能のまとめ

 

~ おわりに ~

今回のブログ「スケールアウト対応」でお伝えしたかったことは、下記の 2 点です。
① 仮想デスクトップ環境は、管理単位 ( Pool 、 Block 、 Pod 、 Cloud Pod ) を意識することでスムーズに拡張できる
② vSphere の上位機能を活用することで、大規模環境でも管理性が損なわれない

仮想デスクトップ環境をスケールアウトさせる際には、考慮すべき事項が多く、少し難しく感じるかも知れませんが、上記の 2 点をしっかりと押さえることで柔軟な拡張が可能になります ( 実際、仮想デスクトップを 1 万台以上導入されているお客様はたくさんいらっしゃいます!)。
このブログをきっかけとして、一社でも多くのお客様に仮想デスクトップの導入を検討いただけたらと思います。

次回はいよいよ最終回となります。最終回では、川崎さんが Horizon 6 の魅力はまだまだこんなもんじゃないっ!というところをビシッ!!と示してくれる予定です。次回もお楽しみに!

VMware SE 氏田裕次

 

新卒2年目社員が贈る 仮想デスクトップのキソ!
第1回 仮想デスクトップと Horizon 6 ( with View)
第2回 仮想デスクトップの基本構成
第3回 プール作成と割り当て
第3.5回 View Composer の仕組み
第4回 接続方法と接続元端末
第5回 公開アプリケーションのキソ
第5.5回 ThinAppによるアプリケーション仮想化のキソ
第6回 スケールアウト対応
第7回 完結編、仮想デスクトップと関連ソリューション総まとめ
第 8.1 回 App Volumes を使ってみよう その1
第 8.2 回 App Volumes を使ってみよう その2

新卒 2 年目 SE が贈る 仮想デスクトップのキソ!・ 第 5回 ~Horizon からアプリケーションを起動!? “公開アプリケーションのキソ” ~

こんにちは。 前回に引き続き、新卒 2 年目の椨木(たぶき)です。

今回の新卒ブログ、“VMware Horizon 6 (with View)” (以下 “Horizon” とします)についてのキソをご紹介するものですが、第1回目から第3回目の記事では、デスクトップ環境を『まるまる』仮想化する方法についてお話してきました。この方式(VDI方式と呼びます)を使用すると、ユーザ一人ひとりに仮想デスクトップ環境(仮想マシン)を割り当てる事になるため、一つのデスクトップ内で複数のアプリケーションを起動し、使用する事ができます。しかし、一方で

『Web アプリケーションを使用したいだけなのでブラウザが使えれば問題ない!』

など、特定のアプリケーションのみを使用させたい・使用したい場合があるかと思います。
ここでは、そういった際に有用となるHorizon の機能の一つ、『Remote Desktop Service (RDS) を用いたアプリケーション配信(公開アプリケーション)』をご紹介します。

§1. Horizon Client からアプリケーションを起動する! ~公開アプリケーション~

Remote Desktop Service を用いたアプリケーション配信を使用すると、ユーザはHorizon Client から「デスクトップ環境」ではなく「アプリケーション」を使用できる様になります。
Horizon Client に表示されたアプリケーションのアイコンをクリックすると、目の前にアプリケーションが現れますが、このアプリケーションは仮想サーバ(Microsoft Windows Server)内で展開されたアプリケーションの画面情報のみがネットワークを通じて手元の端末で表示されている状態です。
図1はHorizon Client からアイコンをクリックしてMSペイントを表示させたものです。

 

rdshapp図1: Horizon を利用したRDS方式アプリケーション配信

 

この『Remote Desktop Service を用いたアプリケーション配信』機能は一般には『公開アプリケーション』方式と呼ばれており、技術的にはMicrosoft の Remote Desktop 方式を利用して、アプリケーションを配信します。この方式はVDIとは異なり、複数のユーザが共有して一つの仮想マシン (Windows Server) にインストールされたアプリケーションを使用する事ができます。

 

usecase図2: VDI 方式と更改アプリケーション方式の違い

 

ここからは、『Remote Desktop Service を用いたアプリケーション配信』機能を『公開アプリケーション』と呼んでご紹介します。

 

§2. 公開アプリケーションの特徴

「アプリケーションだけを配信する」公開アプリケーション、その大きな特徴2点をご紹介します。

 ■ライセンス料金の削減に寄与

これは第1回目の記事のサーバVDI と同様の理由なのですが、Windows 7 やWindows 8.1のようなクライアントOSを使用したVDIを使用するためには、「VDA」と呼ばれる買い切りできないライセンスが必要になります。
この買い切りできないライセンスが、VDIを使用すると大変高価になってしまう印象を持たれる一因となっていました。
公開アプリケーションはWindows Server OSを利用するので、VDAライセンスではなく、 RDS Device/User CAL /Windows CAL を使用すればよくなるため、導入時のコストを抑える事ができます。

また、複数のユーザで一つの仮想マシンを共有する様になるので、ユーザに対する仮想マシンの台数がVDI使用時より大幅に削減され、結果として仮想マシンを載せるためのESXi ホストの台数やホストを動作させるための電気代を削減する事が可能です。

 

■ 簡単に使用したいアプリケーションにアクセス

ユーザに使用させたいアプリケーションが非常に限定されている場合、デスクトップから毎回アプリケーションを選択するVDI方式よりも、アプリケーションの画面をいきなり見ることの出来る公開アプリケーションの方が簡単にアプリケーションを使用する事ができます。
公開アプリケーションは、

  1. 閉じられたネットワーク内のデスクトップPCからVDIのネットワークを通してWebブラウザ「だけ」使用したい
  2.  外出中、出張中に出先から社内アプリ「だけ」を使用できる様にしたい

など、特定のアプリケーションを使用できる環境を作成したいお客様に多くご採用いただいています。

 

§3. デスクトップ仮想化方式の使い分け

Horizon は、VDIはもちろん、公開デスクトップや公開アプリケーションにも対応したデスクトップ環境仮想化製品ですので、「どういった時にどのような方式を取れば良いのか解らない!」という方も居るのではないでしょうか。ここでは、様々なデスクトップ仮想化方式の使い分けの基準をご紹介します。

まずクライアントOSでしか動作しないアプリケーションを使用するユーザ「のみ」にクライアントOS VDIを割り当て、それ以外のユーザにはサーバOSを用いる方式を採用することで、VDAライセンスを最小限に抑えます。
次に、「サーバ VDI」と「公開アプリケーション」の使い分けですが、「VDI」は一つのデスクトップ環境を一人のユーザが専有する方式、「公開アプリケーション」は一つの仮想マシンを複数のユーザで共有する方式です。したがって、「公開アプリケーション」を使用すると、一つの Windows Server が落ちてしまった場合の影響範囲が「VDI」よりも大きくなる傾向があります。
よって、ユーザ単位で性能を保証したい場合や OS(仮想マシン) の停止に伴う影響範囲を小さくしたい場合には「サーバVDI」、それ以外の場合には「公開アプリケーション」を使用する事が望ましいです。

また、マルチセッション(複数のユーザが同一アプリケーションを使用する方式)に対応していないアプリケーションを使用する場合は「VDI」方式を採用する必要があります。

このように、ユーザの使用用途に合わせて正しく割り当てる仮想デスクトップ方式を決める事で、ライセンスコストはもちろん、サーバ台数の削減も行う事ができます。

 

vdiAndRdsh2図3: VDIと公開アプリケーションの使い分け

§4. まとめ

今回は「公開アプリケーション」についてご説明いたしました。
ユーザが使用したい、あるいは管理者がユーザに使用させたいアプリケーションが限定的である場合に、非常に有効な機能である事がお解かりいただけたかと思います。
この「公開アプリケーション」方式、これまでにご紹介してきた仮想デスクトップのコンポーネントにRDSホストを追加するだけで実現できます。
詳しい環境の構築方法については、2014年10月1日の記事をご覧ください。

 

manage図4: vSphere + Horizon で多様なデスクトップ環境を実現

 

「VDI」や「公開アプリケーション」、様々な方法を駆使して、ユーザのニーズにあったコストパフォーマンスの良い仮想デスクトップ環境を作りましょう!

新卒2年目社員が贈る 仮想デスクトップのキソ!
第1回 仮想デスクトップと Horizon 6 ( with View)
第2回 仮想デスクトップの基本構成
第3回 プール作成と割り当て
第3.5回 View Composer の仕組み
第4回 接続方法と接続元端末
第5回 公開アプリケーションのキソ
第5.5回 ThinAppによるアプリケーション仮想化のキソ
第6回 スケールアウト対応
第7回 完結編、仮想デスクトップと関連ソリューション総まとめ

第 8.1 回 App Volumes を使ってみよう その1
第 8.2 回 App Volumes を使ってみよう その2