ここ数年、コンサルティングのプロジェクトで仮想デスクトップの要件をお伺いする際に、データセンターを冗長化しての災害対策(DR: Disaster Recovery)が要件の中に含まれることが多くなってきました。単純な Active / Standby の構成のみならず、複数のデータセンターを Active / Active の構成として使用する要件も多くあります。

こういった構成は、ストレージによるサイト間でのレプリケーション機能が身近なものとなってきていることと、NetScaler などのGSLB機能のように、データセンター間でのネットワークロードバランシング技術も普及してきたために、簡単に導入できる段階になってきています。このエントリでは下図に示す、仮想デスクトップの構成要素のレイヤーごとに、導入を成功させるための重要な検討のポイントを整理したいと思います。

災害対策全体アーキテクチャー図
仮想デスクトップの災害対策全体アーキテクチャー

 

アクセスレイヤー

アクセスレイヤーの Active / Active 化は実はそれほど難しくありません。ここでの主な検討のポイントはアクセスポイントを単一化するか否かです。

ポイント1:アクセスポイントの単一化

  • 単一アクセスポイント
  • DC ごとのアクセスポイント

アクセスポイントを単一化する場合、ユーザーはどのデータセンターにアクセスするかを意識しません。たとえばそれが、https://desktop.citrix.com のような URL だとすると、desktop.citrix.com を名前解決する際に、GSLB の機能などを用いてユーザーからネットワーク的に近いデータセンターのアクセスポイントのIPを返し、アクセスさせることができます。

そこまではいらない、という場合はデータセンターごとにアクセスポイントを用意することになります。たとえば、接続元端末に東京と大阪のアクセスポイントへのショートカットを用意しておき、ユーザーに使い分けてもらう、といった方法です。

参考:Active/Active GSLB for XenDesktop – A Practical Approach (Part1)

 

コントロールレイヤー

コントロールレイヤーではユーザーのデスクトップがどこに存在するかを探し、ラウンチする役割を持ちますが、アクセスレイヤーの設計によってその構成がほぼ決まります。 つまり、アクセスポイントが単一であれば、アクセスポイントから複数のデータセンターの XenDesktop / XenApp コントローラーに接続する構成となり、データセンターごとに持つのであれば、必ずしもその必要はありません。

ポイント2:コントローラーの指定

  • 単一の StoreFront から両方のデータセンターの XenDesktop / XenApp コントローラーを指定
  • 単一の StoreFront から所属データセンターの XenDesktop / XenApp コントローラーのみ指定

両方のデータセンターを登録する場合、アクセスポイントがどちらであっても、デスクトップが存在するデータセンターに接続できます。たとえば、大阪のアクセスポイントに接続したユーザーが東京に使用可能なデスクトップがあるのであれば、そちらが返ってきます。

この場合、該当ユーザーが使えるリソースとして、同じリソース(仮想デスクトップや公開アプリなど)が返って来る構成にすることもできます。その際に StoreFront 側の制御で、ユーザーグループ単位でどのデータセンターのリソースを使うかどうかの制御が可能です。どちらも使ってもよい、という場合はランダムにアクセスさせることもできます。たとえば、下図のような構成の場合を想定した場合、

ユーザー1が所属するグループの権限に応じ、データセンターAの XenDesktop / XenApp Controller からはデスクトップとアプリケーションとして Excel、SAP が返ってきて、BからはExcel、SAP が返ってきます。その際、Excel と SAP はどちらのデータセンターのものも使えることになりますので、その制御方法を設定することができます。たとえば、Excel はどちらを使ってもよい(ランダム)、SAP はプライマリとしてデータセンターAでダメならBを使う、という指定ができます。

参考:Building modular XenDesktop infrastructures by means of StoreFront Multi-Site Configurations

もう一個の考え方としては、東京に所属するユーザーは東京の XenDesktop サイトにしかデスクトップを持たない状態にしておき、DR発動後に大阪に登録する、というものです。この構成では不意な切り替えを避けることができます。

 

デスクトップレイヤー

デスクトップレイヤーでは、該当の仮想デスクトップのマスター管理が主な検討ポイントです。

ポイント3:マスター管理方法

  • プールの場合
  • 占有型の場合

仮想デスクトップが Provisioning Services 等を用いてプールの構成となっている場合、マスターイメージをデータセンター間で更新ごとに移送することで同じ構成とすることができます。マスターイメージのみなので、転送量がわずかで済みます。

プールではない場合については、仮想デスクトップの VM を丸ごとすべてデータセンター間で複製し、vCenter Site Recovery Manager(VMware の場合)等を使うことも可能ですが、 ライセンスなどの問題から10000台規模の環境ではあまり現実的ではないと考えられます。(SRM を使わずにストレージの機能やスクリプトなどを組み合わせた事例がありますが、 どうしても RTO は長くなってしまいます。)

コピー元となるテンプレートのみを複製しておくことが次善の策になりますが、テンプレートの更新を考慮すると、事前に展開しておくことも善し悪しなので、DR 発動後に展開することになりますが、その場合は復旧により時間がかかることになります。

 

データ、アプリケーション

最後がデータ、アプリケーションなどを含むレイヤーですが、ここが一番大きな検討ポイントとなります。しかし、あまり検討の余地がなく、一番の制約条件となります。

ポイント4:ユーザーデータ、プロファイルの複製

  • ユーザーデータ、プロファイルの複製を行う
  • ユーザーデータ、プロファイルの複製を行わない

一番の問題はユーザーデータの複製です。特にプロファイルの扱いです。簡単に言うと、Microsoft 社はプロファイルに Active / Active のアクセスを行う構成をサポートしていません。

参考:Microsoft’s Support Statement Around Replicated User Profile Data
DFS-R を DFS N の展開シナリオについてマイクロソフトのサポート ポリシーについての情報

この制約に当たるため、基本的には各ユーザーは「本拠地」を決めておき、Active / Standby のアクセスとする必要があります。つまり、東京のデスクトップにアクセスしているユーザーが大阪に出張した場合も、大阪から東京のデスクトップにアクセスする。DR の発動時は切り替え作業を行い、東京のユーザーが大阪にもアクセスできるようにする、というユースケースになります。

もし、プロファイルは複製される必要がない(固定プロファイルを使うなど)、ということであれば、話は簡単なのですが、デスクトップ用途ではプロファイルは保持する要件があることが通常ですので、これが一番のネックになります。

東京が本拠地のユーザーは東京のデータセンター、大阪が本拠地のユーザーは大阪のデータセンター、という分類を行うことでデータセンターとしては、Active / Active として使用することができます。しかし、その場合も、次の問題があります。

ポイント5:アプリケーションアクセス

  • アプリケーションをActive/Activeで配置し、デスクトップから近いアプリケーションを利用
  • アプリケーションをActive/Standbyで配置し、両方のデータセンターからアプリケーションを利用

単に Office が使えればよい、という要件であればともかく、通常の何かしらのカスタムの業務アプリケーションにアクセスする必要があります。その際、DB を持つようなアプリケーションなどは Active / Active の配置はできずに、どちらかのサイトのみに配置して災害時に切り替えるというやり方しかできない場合があります。

特に問題になるのがメールです。多くの通信が発生しますので、ユーザーのデスクトップと近い場所にメールボックスがあるべきです。これもやはり本拠地を決めてメールボックスの配置を検討する必要があります。もしくは、すでに動いているメールボックスを動かしたくない、という場合はそれに引っ張られて構成が決まってしまいます。

メールについては、Office365 や Gmail などの SaaS を利用することにしてしまうことも可能ですが、作り込みのアプリケーションなどはホストと接続するなど、構成が変更できないことも多く、それがネックとなってしまいます。

 

まとめ

長くなってしまいましたが、仮想デスクトップを用いて災害対策、というのは非常にキャッチーでわかりやすいのですが、実装するためにはいくつか考えないといけないことがあります。データセンターが Active / Active 化できても、仮想デスクトップの構成要素には Active / Active 化できないものがあるためです。

そのためには、事前にアセスメントを実施して、ユーザーのセグメンテーションやアプリケーションの把握をすることが重要になります。シトリックスコンサルティングでは、アセスメントのプロジェクトを多数実施していますので、製品と併せご活用いただけますと幸いです。