障害回復
アクティブ/パッシブフェイルオーバー戦略を使用して複数サイトの障害回復を含めたXenMobile展開環境を構築し、構成できます。
この記事で説明する推奨障害回復戦略は次のとおりです:
- 地理的に1つの場所のデータセンターにある単一のアクティブなXenMobileサイト。すべての企業ユーザーにグローバルに提供され、プライマリサイトと呼ばれます。
- 第2の地理的な場所のデータセンターにある第2のXenMobileサイト。障害回復サイトと呼ばれます。この障害回復サイトは、プライマリサイトでサイト全体のデータセンターの障害が発生した場合にアクティブ/パッシブサイトフェールオーバーを提供します。プライマリサイトには、XenMobile、SQLデータベース、Citrix ADCインフラストラクチャが含まれており、フェールオーバーを容易にし、プライマリサイトへの接続に失敗した場合にXenMobileへのアクセスをユーザーに提供します。
障害回復サイトのXenMobileサーバーは、通常の運用中はオフラインのままで、プライマリサイトから障害回復サイトへの完全なサイトフェールオーバーが必要な障害回復シナリオのみでオンラインになります。障害回復サイトのSQL Serverは、アクティブで、障害回復サイトでXenMobileサーバーを起動する前に接続を処理する準備ができている必要があります。
この障害回復戦略は、停止時にMDMおよびMAM接続を障害回復サイトにルーティングするためのDNS変更によるCitrix ADCアクセス層の手動フェールオーバーに依存しています。
注:
このアーキテクチャを使用するには、データベースの非同期バックアップとSQLインフラストラクチャの高可用性を確保するためのプロセスが必要です。
障害回復フェールオーバープロセス
- 障害回復フェールオーバープロセスをテストする場合は、プライマリサイトのXenMobileサーバーをシャットダウンしてサイトの障害をシミュレートします。
- 障害回復サイトの外部IPアドレスを参照するように、XenMobileサーバーの公開DNSレコードを変更します。
- 障害回復サイトのSQL Server IPアドレスを参照するように、SQL Serverの内部DNSレコードを変更します。
- 障害回復サイトでXenMobile SQLデータベースをオンラインにします。SQL Serverとデータベースがアクティブで、サイトのローカルXenMobileサーバーからの接続を処理できる状態になっていることを確認します。
- 障害回復サイトのXenMobileサーバーの電源を入れます。
XenMobileサーバー更新プロセス
プライマリサーバーと障害回復サーバーのコードを統一するために、XenMobileをパッチおよびリリースで更新するたびに、次の手順を実行します。
- プライマリサイトのXenMobileサーバーがパッチ適用またはアップグレードされていることを確認します。
- SQL ServerのDNSレコードがプライマリサイトのアクティブなSQL Serverデータベースに解決されていることを確認します。
- 障害回復サイトのXenMobileサーバーをオンラインにします。サーバーは、アップグレード処理時にのみWANを介してプライマリサイトのデータベースに接続します。
- すべての障害回復サイトのXenMobileサーバーに必要なパッチおよびアップデートを適用します。
- XenMobileサーバーを再起動し、パッチまたはアップグレードが成功したことを確認します。
障害回復リファレンスアーキテクチャの図
次の図は、XenMobileの障害回復環境のハイレベルアーキテクチャを示しています。
障害回復のGSLB
このアーキテクチャの重要な要素は、GSLB(Global Server Load Balancing)を使用してトラフィックを正しいデータセンターに誘導することです。
デフォルトでは、Citrix ADC for XenMobileウィザードは、障害回復にGSLBを使用できないようにCitrix Gatewayを設定します。したがって、追加の手順を実行する必要があります。
GSLBのしくみ
GSLBはDNSの中核部にあります。参加するCitrix ADCアプライアンスは権限のあるDNSサーバーとして機能し、DNSレコードを正しいIPアドレス(通常はトラフィックを受信するはずのVIP)に解決します。Citrix ADCアプライアンスは、そのシステムへのトラフィックを誘導するDNSクエリに応答する前に、システムの健全性をチェックします。
レコードが解決されると、トラフィックを解決するGSLBの役割は完了です。クライアントは、ターゲット仮想IP(VIP)アドレスと直接通信します。DNSクライアントの動作は、レコードがいつどのように期限切れになるかに重要な役割を果たします。これは大部分がCitrix ADCシステムの範囲外です。そのため、GSLBにはDNS名前解決と同じ制限があります。クライアントは応答をキャッシュします。したがって、このような負荷分散には、従来の負荷分散ほどのリアルタイム性はありません。
サイト、サービス、およびモニターなど、Citrix ADCのGSLB設定は、正しいDNS名前解決を提供するために存在します。
サーバーを公開するための実際の設定(このシナリオでは、Citrix ADC for XenMobileウィザードが作成する設定)は、GSLBの影響を受けません。GSLBはCitrix ADC上の別個のサービスです。
GSLBをXenMobileで使用する場合のドメイン委任の課題
Citrix的ADC XenMobileウィザードでは、Citrix Gateway for XenMobileを設定します。このウィザードは、3つの負荷分散仮想サーバーとCitrix Gateway仮想サーバーを生成します。
負荷分散仮想サーバーのうち2つは、ポート443と8443でMDMトラフィックを処理します。Citrix Gatewayはポート8443でMAMトラフィックを受信し、第3のサーバーであるMAM負荷分散仮想サーバーに転送します。MAM負荷分散仮想サーバーへのトラフィックはすべてCitrix Gatewayを通過します。
MAM負荷分散仮想サーバーにはXenMobileサーバーと同じSSL証明書が必要で、デバイスの登録に使用されたものと同じFQDNが使用されます。MAM負荷分散サーバーは、MDM負荷分散サーバーの1つと同じポート(8443)も使用します。トラフィックを解決するには、Citrix ADC for XenMobileウィザードを使用して、Citrix GatewayにローカルDNSレコードを作成します。DNSレコードは、デバイスの登録に使用されたFQDNと一致します。
この設定は、XenMobileサーバーのURLがGSLBドメインサーバーのURLでない場合に有効です。障害回復にはGSLBドメインのURLをXenMobileサーバーのURLとして使用することが必要ですが、その場合、ローカルDNSレコードが、Citrix GatewayによるMDM負荷分散サーバーへのトラフィック解決を妨げます。
GSLB障害回復でのCNAMEメソッドの使用
Citrix的ADC XenMobileウィザードで作成されたデフォルト設定の問題を解決するには、親ドメイン(company.com
)にXenMobileサーバーのFQDNに対応するCNAMEレコードを作成し、Citrix ADCが認証されている委任済みサブゾーン(gslb.company.com
)のレコードを参照します。 これにより、トラフィックを解決するために必要なMAM負荷分散VIPアドレス用の静的DNS Aレコードを作成できます。
外部DNSで、Citrix ADC GSLB上のGSLBドメインFQDNを参照するXenMobileサーバーFQDNのCNAMEを作成します。 次の2つのGSLBドメインが必要です:1つはMDMトラフィック用、もう1つはMAM(Citrix Gateway)トラフィック用です。
例:
CNAME = xms.company.com IN CNAME xms.gslb.comany.com
各サイトのCitrix Gatewayインスタンスで、CNAMEレコードが参照するFQDNを持つGSLB仮想サーバーを作成します。
例:
bind gslb vserver xms-gslb -domainName xms.gslb.company.com
Citrix的ADC XenMobileウィザードを使用してCitrix Gatewayを展開する場合は、MAM負荷分散サーバーを設定するときにXenMobileサーバーのURLを使用します。これにより、XenMobileサーバーのURLに対応する静的DNS Aレコードが作成されます。
XenMobileサーバーURL(
xms.company.com
)を使用して、Secure Hubに登録しているクライアントでテストします。この例では、次のFQDNを使用します:
xms.company.com
はMDMトラフィックによって使用されるURLで、登録されているデバイスで使用されます。この例では、Citrix ADC for XenMobileウィザードを使用して設定されています。xms.gslb.company.com
はXenMobileサーバーのGSLBドメインFQDNです。