XenDesktop / XenAppの可用性を最大化するポッドアーキテクチャとは

XenDesktop / XenAppの可用性を最大化する
ポッドアーキテクチャとは
営業推進本部プロダクトソリューション推進部
プロダクトソリューション推進マネージャー
橋本洋
V-3

2 © 2015 Citrix.
本セッションの内容
•XenDesktop、XenAppの運用上のリスク
•XenDesktop、XenAppの概念的アーキテクチャ
•ポッドアーキテクチャ概要
•ポッドビルディングブロックの考慮点

XenDesktop、XenAppの運用上の
リスク

4 © 2015 Citrix.
XenDesktop、XenAppの運用上のリスク
利用可能なPVS vDiskが無い
VDAの DDCリストが正しくない
PVS リバランスによる負荷
PVS Stream サービスがハングした
自動メンテナンスモード不適切な監視
デスクトップ数の不足デスクトップ設定に関する問題

5 © 2015 Citrix.
スケーラビリティの懸念
•XenDesktop, XenAppは多くのサブコンポネントにより構成される。
•スケーラビリティの上限はコンポネントによって異なる。
– ホストあたりのVM数、LUNあたりのVM数、クラスタあたりのホスト数、vCenterあたりのホ
ストまたはクラスタ数、PVSあたりのターゲットデバイス数など…
•サイジングの上限値に達すると。。
– コンソールのレスポンスが低下
– ハイパーバイザのタスク処理に時間がかかる
– サービスのハングやクラッシュ
リスクを最小限に抑えながら大規模な構成を最適な形で構築する方法を検討する必
要がある

XenDesktop, XenAppの概念的
アーキテクチャ
https://www.citrix.com/content/dam/citrix/en_us/documents/products-
solutions/xendesktop-deployment-blueprint.pdf#search='citrix+xendesktop+7.6+blueprint
参考資料：Citrix XenDesktop 7.6 Feature Pack 2 Blueprint :

7 © 2015 Citrix.
概念的アーキテクチャ

8 © 2015 Citrix.
標準的な仮想デスクトップソリューションの概念レベルの設計は、標準化された
5レイヤモデルによって設計上のすべての重要な決定事項を検討する
概念レベルの設計は５レイヤモデルで考える

10 © 2015 Citrix.
ユーザーレイヤ
～ユーザーグループ、エンドポイント、場所を定義～

12 © 2015 Citrix.
アクセスレイヤ
～リソースへのアクセス方法を定義～
• StoreFront
• NetScaler Gateway
• ロードバランサー

13 © 2015 Citrix.
～アクセス経路により認証、セキュリティポリシーを使い分ける～

15 © 2015 Citrix.
リソースレイヤ
～各ユーザーグループに提供される仮想デスクトップ、アプリケーション、データを定義～

16 © 2015 Citrix.
リソースレイヤ～イメージ～
～ユーザーグループ毎に定義されたイメージの構成例～
• デスクトップタイプ
• オペレーティングシステム
• 仮想インスタンスのサイズ
• デリバリー方法
 Machine Creation Services (MCS)
 Provisioning Services (PVS)

17 © 2015 Citrix.
仮想サーバーのサイジング例
リソースタイプ OS vCPU RAM
イメージ
サイズ
キャッシュ
サイズ
VMあたりの
ユーザー数
サーバあたり
のVM数
パーソナルまたは
プールされた
デスクトップ
Windows 7 2 vCPU 2 GB 35 GB 5 GB 1 140-200
Windows 8 2 vCPU 2 GB 35 GB 5 GB 1 135-190
Windows 8.1 2 vCPU 2 GB 35 GB 5 GB 1 135-190
ホステッド
アプリケーション
または
共有デスクトップ
Windows 2008R2 4 vCPU 12 GB 60 GB 15 GB 20-30 8
Windows 2012 8 vCPU 24 GB 60 GB 30 GB 48-68 4
Windows 2012R2 8 vCPU 24 GB 60 GB 30 GB 48-68 4
※ 業務アプリは通常のワークロードを想定
※ Xeon E5-2690 2.9GHz デュアルプロセッサ（16コア）上でHyper-V3を実行した場合に基づく
※ RAM容量は「仮想マシンの予想台数ｘ各仮想マシンで必要となるメモリ容量」

18 © 2015 Citrix.
リソースレイヤ～アプリケーション～
• インストール型
 ユーザーの75％以上が使用するアプリの場合に最適
 マスターの数は多くなるが、従来のノウハウを活かせる。
• ホステッド型
 ユーザーの過半数が使用する基幹業務アプリの場合に最適
• ストリーミング型
 マスターの数はもっとも少ないが、追加の製品、インフラが必要。
• ユーザーベース型
 IT部門による管理を受けない、ユーザー固有のアプリケーション。
 Personal vDiskの利用。仮想デスクトップから各自の物理エンドポイントにアクセス

19 © 2015 Citrix.
リソースレイヤ～パーソナライズ～
～ユーザーが各自のワークスペースをどの程度までカスタマイズできるかを定義～
• リモートアクセスポリシー
 WAN越しのアクセス時に、リソースを適切に保護するための設定。
 NetScalerを通じてすべてのセッションに適用
• ローカルアクセスポリシー
 高品位のユーザーエクスペリエンスを実現
• モバイルデバイス
 モバイルデバイスのフォームファクターに合わせて、ユーザーエクスペリエンスを改善

21 © 2015 Citrix.
コントロールレイヤ
～リソースへのアクセスをサポートするために必要となるインフラストラクチャーを定義～
コンポーネントベストプラクティス
デリバリーコントローラ • 冗長性を考慮し、最低２台で構成
• サイト規模の機能停止による影響を最小化するため、複数の
XenDesktopサイトの利用を推奨
• 1ポッドあたり１XenDesktopサイト
• ログオフ時の自動リブートは設定しない
 ブートストームおよび多数の同時ログオフによる性能への影響を回
避するため。
• VDAとコントローラ間の時刻同期
• アクティブセッションの最大数、1分毎の新規アクション最大数
はハイパーバイザープールの能力に依存。
• Directorの同時ユーザー数が50を超える場合は専用サーバー上に
配備する。負荷分散アプライアンスによるDirectorサーバーの
負荷分散も検討。

22 © 2015 Citrix.
ライセンスサーバー • ライセンスサーバー停止時は30日間機能を続行できる猶予期間
が与えられるため、追加の冗長性は必須ではない。
• データセンター毎に１セット

23 © 2015 Citrix.
SQLデータベース・３ノードのミラー構成を推奨。フェールオーバーの自動化
ノード1 ：プライマリーミラー（SQL Std）
ノード2 ：セカンダリーミラー（SQL Std）
ノード3 ： Witnessサーバー（SQL Express）
・SQLトランザクションログのサイズを縮小するため、
バックアップを定期的にとる。

25 © 2015 Citrix.
ハードウェアレイヤ
～ソリューション全体の物理的な実装を定義～
• リソースレイヤのホスティング
 物理、仮想およびクラウドホステッド型のデスクトップ、アプリケーション、Amazon
AWS, CloudPlatformとの統合も可能
• アクセス、コントロールレイヤのホスティング
 物理、仮想サーバー上に実装
定義事項：
• ストレージ
• サーバーのフットプリント
• サーバーのサイジング

26 © 2015 Citrix.
～ストレージ～
• ストレージはユーザーエクスペリエンス、ソリューションコストおよびサーバのフットプリン
トにも影響するため、ハードウェアレイヤ設計の第一ステップで検討する。
ストレージタイプメリット懸案事項サーバータイプ
ローカルストレージ • 安価
• 配備が簡単
• 物理サーバーがオフラインに
なると仮想マシンにアクセス
できない。
• ディスクスピンドル数が制限
される。
ラックサーバー
ダイレクトアタッチ
ストレージ
• 中程度の価格 • DASアレイが故障すると複数
の物理サーバーが影響を受け
る
ラックサーバー
共有ストレージ • 複数の物理サーバ間で
マスターイメージを共有。
• 拡張が容易。
• 重複排除、データ圧縮など
の先進機能
• 高価
• ストレージ層に特化した管理、
運用スキル
ブレードサーバー

27 © 2015 Citrix.
～ストレージ：IOPSアクティビティ～

28 © 2015 Citrix.
～ストレージ：IOPSアクティビティ～

29 © 2015 Citrix.
Dom0
インメモリ
リードキャッシュ
インメモリ・リードキャッシュおよびIntellicache
Intellicache
インメモリ・リードキャッシュもしくはIntellicache機能により
ゴールデンイメージをメモリもしくはローカルディスクから読み込むことで、
共有ストレージのIOをオフロードし、仮想マシンの起動時間も大幅に短縮
Read only Read and Write
XenServer 6.5
RAM
ローカル
ディスク
共有ストレージ
ゴールデン
イメージ

30 © 2015 Citrix.
～サーバーフットプリント～

31 © 2015 Citrix.
～サーバーサイジング : １物理サーバーあたりのユーザー数～
※ Xeon E5-2690 2.9GHz デュアルプロセッサ（16コア）上でHyper-V3を実行した場合に基づく
※ RAM容量は「仮想マシンの予想台数ｘ各仮想マシンで必要となるメモリ容量」で計算

32 © 2015 Citrix.
～サーバーサイジング：単一サーバーのユーザ密度の考慮点～
• アンチウィルス
 アンチウィルス機能をイメージに追加すると、ユーザ密度が10-20％低下する。
• Personal vDisk
 Windows 7, Windows 8の場合、Personal vDiskを使用するとユーザ密度が5-15％低下
する。
• Microsoft Office 2013
 Microsoft Office 2013 を使用するとユーザ密度が20％低下する。

ポッドアーキテクチャ概要
http://support.citrix.com/article/CTX139652
参考資料：XenDesktopのモジュール型リファレンスアーキテクチャ

34 © 2015 Citrix.
ポッドとは？
• XenDesktop, XenAppのサイト、ハイパーバイザ、PVSサイト、SQLサーバー
等の主要コンポネントで構成される複製が容易な自己完結型の論理構成。
• 大規模環境においては、大きなサイトを１つ構成するのでは無く、複数のポッ
ドで構成、拡張する事で障害発生時の影響範囲を最小限に留められる。
• AD/DNS/DHCP/ファイルサーバーなどシステム全体で共有するサービスはポッ
ドには含まれない
• 各ポッドはステートレス

35 © 2015 Citrix.
ポッドアーキテクチャ概要
35
NetScaler
リソースレイヤ
NetScaler StoreFront StoreFront
Director
ライセンス
サーバー
AD/DNS/DHCP
プロファイル
ホームドライブ
デリバリー
コントローラ
PVSファーム
デリバリー
コントローラ
PVSファーム
デリバリー
コントローラ
PVSファーム
ポッド１ポッド２ポッド３
SQL
サーバー
SQL
サーバー
SQL
サーバー
ハイパーバイザ
デスクトップ VM
サーバー VM
サーバー VM
サーバー VM

ビルディングブロックの考慮点

37 © 2015 Citrix.
ビルディングブロックの考慮点
モジュール名考慮点
XenDesktop とPVS
サイト
• ポッドごとにXenDesktop,PVSサイトを各１つづつ配置
• 各サイトはポッド内のSQLサーバーにのみアクセス
SQLサーバー • ポッドをまたがった、SQLインスタンスの共有はしない。
• ポッド単位でSQLサーバーを配置。
ポッド内の全コンポーネント（vCenter/SCVMM, PVS,
XenDesktop）が同じSQLインスタンスを共有。
ハイパーバイザー • 仮想デスクトップのクラスター、プールは複数のポッドにま
たがらない事。
• vCenter/SCVMMはポッド単位で構成
• 仮想デスクトップとエンタープライズサービス（AD,SQL等）
は同居させない。

38 © 2015 Citrix.
ビルディングブロックの考慮点 – 続き
vCenter, SCVMM,
XenServerプール
• ポッド内で複数のハイパーバイザインスタンスを構成するこ
とで可用性を高める。
• MCS使用時はvCenterあたり3000VDIが目安
• PVS使用時はvCenterあたり5000VDIが目安
• XenServerの場合はプールあたり1000VMが目安
• SCVMMとvCenterのスケーラビリティはほぼ同等
その他 • NetScaler, StoreFront, Director, License Serverは全ポッド
共有のコンポネントのため、ポッドには含めない。

39 © 2015 Citrix.
1ポッドに複数のハイパーバイザを構成
XenDesktopサイト
9000 VM
vCenter 1 vCenter 2 vCenter 3
クラスタ１
1500 VM
クラスタ2
1500 VM
クラスタ１
1500 VM
クラスタ2
1500 VM
クラスタ１
1500 VM
クラスタ2
1500 VM

40 © 2015 Citrix.
ビルディングブロックの考慮点－続き
StoreFront • マルチサイトストア構成によりStoreFrontの分散展開環境を構
成し、ストアの可用性を高める。
• 異なるサイトのプールリソース（デスクトップグループ）に
同一名を付ける事で、分散展開環境のリソースが集約され、
１つのアイコンで表示される。
• 負荷分散モード
 loadBalanceMode属性をLoadBalancedに設定した場合、
ユーザーが接続する展開環境はランダムに選択され、これに
よりユーザーからの要求が展開環境に均等に分散される。
 loadBalanceMode属性をFailoverに設定した場合、ユー
ザーが接続する展開環境は常に指定された順序で選択される。
http://support.citrix.com/proddocs/topic/dws-storefront-
26/nl/ja/dws-configure-ha-example.html?locale=ja

41 © 2015 Citrix.
マルチサイト構成によりStoreFrontの可用性を高める
41
DC1
サイト1 : グループAユーザーの優先サイト
VDA1 VDA2
プール1
サイト2 : グループBユーザーの優先サイト
DC2
VDA1 VDA2
プール1
StoreFront
LoadBalanced/FailOver
<userFarmMapping name="UM_GroupA">
<groups>
<group name="ad1¥userA" sid="<userA の SID>" />
</groups>
<equivalentFarmSets>
<equivalentFarmSet name="GroupA" loadBalanceMode="LoadBalanced"
aggregationGroup="AG1">
<primaryFarmRefs>
<farm name="DC1" />
<farm name="DC2" />
</primaryFarmRefs>
</equivalentFarmSet>
</equivalentFarmSets>
</userFarmMapping>
<userFarmMapping name="UM_GroupB">
<groups>
<group name="ad1¥userB" sid="<userB の SID>" />
</groups>
<equivalentFarmSets>
<equivalentFarmSet name=“GroupB” loadBalanceMode=“FailOver"
aggregationGroup="AG1">
<primaryFarmRefs>
<farm name="DC2" />
<farm name="DC1" />
</primaryFarmRefs>
</equivalentFarmSet>
</equivalentFarmSets>
</userFarmMapping>
グループAのユーザーがログオンする都度、
DC1、DC2内の仮想PCをランダムに割り当て
る優先的に割り当てる。
グループBのユーザーがログオンした際はDC2
の仮想PCを優先的に割り当てる。
DC2の仮想PCが全て使用中（”接続済み”、”切
断済み”）か、メンテナンスモードで利用可能
な仮想PCが無いか、もしくはDC2が応答しな
い場合は DC1の仮想PCを割り当てる。

42 © 2015 Citrix.
まとめ
仮想デスクトップ、アプリケーションの設計は重要な決定事
項が必ず検討されるよう、５レイヤモデルで考える
大きなサイトを１つ構成するのでは無く、複数のポッドに小
分けにすることで、障害発生時の影響範囲を最小限に留める
ことができる。
ポッドアーキテクチャでは、各レイヤー毎の設計要素を論理
的に拡張できるので、設計が簡素化される。

XenDesktop / XenAppの可用性を最大化するポッドアーキテクチャとは

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to XenDesktop / XenAppの可用性を最大化するポッドアーキテクチャとは

Similar to XenDesktop / XenAppの可用性を最大化するポッドアーキテクチャとは (20)

More from Citrix Systems Japan

More from Citrix Systems Japan (20)

Recently uploaded

Recently uploaded (7)

XenDesktop / XenAppの可用性を最大化するポッドアーキテクチャとは