設計上の決定:ディザスタリカバリ計画

概要

このガイドは、ビジネス継続性(BC)とディザスタリカバリ(DR)のアーキテクチャ計画と、Citrix Virtual Apps and Desktopsのオンプレミスとクラウドの両方の展開に関する考慮事項を支援します。DRは、幅広い範囲において、それ自体が重要なトピックです。Citrix は、このドキュメントは、全体的なDR戦略の包括的なガイドではないことを認識しています。DR のすべての側面を考慮しているわけではなく、さまざまな DR の概念について、より素人的な見方をする場合もあります。

このガイドは、組織のCitrix アーキテクチャに大きな影響を与える次の考慮事項に対処し、それらに関連するアーキテクチャガイダンスを提供することを目的としています。

  • ビジネス要件
  • ディザスタリカバリと高可用性
  • ディザスタリカバリ層の分類
  • ディザスタリカバリオプション
  • クラウドでのディザスタリカバリ
  • 操作に関する考慮事項

ビジネス要件

Citrix設計手法の「ビジネス・レイヤー」に合わせて、明確なビジネス要件とサービスのリカバリに関する既知の制約を収集します。これらの項目の文書化は、Citrixのリカバリプランの作成の開始点となります。このステップにより、範囲が明確になり、ビジネス要件と機能要件、制約を満たすのに最適なDR戦略の方向性が提供されます。

以下に、議論に役立つ質問の例をいくつか挙げます。これらの質問は、Citrix DR設計にどのように影響するかという観点から、「 ディザスタリカバリオプション 」セクションで詳しく説明されています。

  • バックアップ戦略とRTO(目標復旧時間)現在、サーバに使用しているバックアップ戦略は何ですか。バックアップ頻度?保存期間?オフサイトストレージ?テスト済みですか? Citrix プラットフォームは、災害発生時や特定の期間内にオンライン状態にする必要がありますか。(ディザスタリカバリ階層の分類を参照)。Citrixがホストするアプリケーションが接続するアプリケーションバックエンドをディスカッションに含めると、期待を一致させることができます。
  • 目標復旧時点 (RPO) RPO(目標復旧時点)では、DRで許容できるデータ損失の程度はどれくらいですか。その内容は、インフラストラクチャ・コンポーネントまたはデータのクラス分けによって異なります。サービスのために復元されたデータはどれくらい古いのですか?0分?一時間?一ヶ月? Citrixインフラストラクチャでは、この考慮事項は、データベースの変更とユーザーデータ(プロファイル、フォルダーリダイレクトなど)にのみ適用されます。RTO と同様に、Citrix でホストされるアプリケーションのバックエンドについても検討する価値があります。
  • リカバリの範囲。この考慮事項には、Citrixインフラストラクチャだけは含まれませんが、Citrixがホストするアプリケーションクライアントがインターフェイスするユーザーデータまたは主要なアプリケーションサーバーを含めることができます。Citrixプラットフォームをリカバリする時間とCitrixでホストされているアプリケーションをリカバリする時間の間に差異があるかどうかを識別することが重要です。この時間デルタは、ソリューションの一部のみがオンラインであるため、システム停止を延長できます。
  • ユースケース。Citrixプラットフォームは、多くの場合、ビジネスの重要度レベルが異なる多数のユースケースに対応しています。リカバリはすべてのCitrix のユースケースに対応していますか? または、ビジネスの運営上の成功が完全に依存する主要なユースケース。この回答は、インフラストラクチャのスコープと容量の予測に大きな影響を与えます。Citrix 環境の新たな機能である場合は、DRの有効化を区分化するために、ユースケースのセグメント化と優先順位付けを推奨します。
  • 機能。DRに含める必要のない、コストを削減できる主要な機能はありますか?この機能の一例として、永続デスクトップと非永続的なデスクトップの使用例があります。ホストされた共有デスクトップまたは特定のアプリケーションソロによって提供されるVDIの使用例もあります。お客様には、DRではコンポーネントの冗長性(ADC、コントローラ、StoreFront、SQLなど)は必要ないと認識されている場合がありました。このような決定は、生産の長期停止がある場合のリスクとみなすことができます。
  • 既存の DR. 他のCitrix環境やその他のインフラストラクチャサービスに対して、既存のDR戦略または計画が存在していますか。新しいルーティング可能なサブネットにリカバリするか、または「バブル」ミラーリング本番ネットワークにリカバリしますか。この回答は、現在のDRアプローチ、ツール、または優先順位を可視化するのに役立ちます。
  • テクノロジー機能。この考慮事項は、Citrixの最終的なリカバリ戦略を決定することはできませんが、次の点を理解することが重要です。
    • 回復: 組織内で利用できるストレージレプリケーションテクノロジ、VM 回復テクノロジ (VMware SRM、Veeam、Zerto、Azure サイト回復 (ASR) など) は何ですか? Citrix依存関係と一部のCitrixコンポーネントはそれらを使用できます。
    • Citrix: イメージ管理とアクセスにどのCitrix テクノロジーが使用されていますか? コンポーネントによっては、特定のリカバリ戦略にうまく活用できないものもあります。MCSまたはPVSによって管理される非永続的な環境は、ストレージやネットワークとの緊密な統合により、VMレプリケーションテクノロジの候補が不十分になります。
  • データの重要度。ユーザープロファイルまたはユーザーデータはリカバリに重要であると見なされますか。永続的な VDI?DRの起動時にこのデータが使用できない場合、生産性に重大な影響を与えますか。または、非永続プロファイルまたはVDIを一時的なソリューションとして使用できますか?この決定は、コストとソリューションの複雑さを増大させます。
  • 災害の種類。この決定はかなり重要ですが、企業の BC または DR プランを通じて事前に確立することもできます。この要件は、多くの場合、リカバリ場所を決定しています。この戦略は、アプリケーション・レベルでのみサービス・リカバリに対応することを意図していますか。ハードウェアラック間?メトロロケーション内?2つの地域の間?2カ国? クラウドプロバイダーリージョン内か、クラウドプロバイダーのインフラストラクチャ全体 (マルチリージョン) ですか?
  • クライアントユーザー。本番環境でサービスにアクセスするユーザーはどこにありますか?この決定は、DRイベント中に手動で変更する必要がある企業のネットワーク接続など、サービスのリストア先に影響する可能性があります。さらに、この回答では、アクセス層の考慮事項が決まります。
  • ネットワーク帯域幅。各ユーザーセッションの平均消費トラフィック(ICA、アプリケーション、ファイルサービス)はどれくらいですか?この決定は、クラウドとオンプレミスの両方のリカバリに適用されます。
  • フォールバック(またはフェイルバック)。DRの状況が解決された後、本番環境でのサービス復帰方法について、組織には既存の計画がありますか。組織はどのように通常の状態に回復するのですか? DRで作成された新しいデータは、本番環境とどのようにリコンサイルされ、統合されますか。

制約は、BC/DR 設計オプションまたはその構成を制限します。彼らは多くの形で来ますが、次のものを含めることができます:

  • 規制または企業ポリシー。この決定により、レプリケーションまたはリカバリに使用できるテクノロジーと使用できないテクノロジー、それらの使用方法、RTO、施設間の最小距離が決定されます。
  • インフラストラクチャ。使用するハードウェアの種類や利用可能なネットワーク帯域幅などに関するディレクティブはありますか?これらの考慮事項は、RPO(目標復旧時点)に関する考慮事項に影響を与えることもあれば、リスクたとえば、DR 内のファイアウォールやネットワークパイプのサイズが小さすぎる場合、ネットワークの依存関係では DR ワークロードを処理できないため、最終的にシステム停止につながる可能性があります。または、コンピューティングの場合、ハイパーバイザーホストのサイズが小さいのか、異なるハイパーバイザーの使用がオプションに影響を与える可能性があります。ネットワーキングに関して、WAN のサービス時に、リカバリサイトのネットワークスループット機能が実稼働環境よりも制約を受けている場合。クラウド環境、特に数千席に拡張する場合、仮想ファイアウォール、VPN ゲートウェイ、クラウドツーWAN アップリンク(AWS Direct Connect、Azure ExpressRoute、Google クラウドインターコネクトなど)などのコンポーネントサービスの制限により、この潜在的なリスクが急速にボトルネックになる可能性があります。オン)。
  • 予算。DR ソリューションには、プロジェクトの予算と競合する可能性があるコストがかかります。多くの場合、RTO が短いほど、コストは高くなります。
  • 地理。指定された DR ファシリティが特定された場合は、DR に接続するユーザーに加えて、本番環境から DR 施設へのレイテンシーなどの考慮事項についても理解する必要があります。
  • データの常駐またはデータのクラス分けこの決定により、ロケールとテクノロジー、または回復方法の面でオプションが制限されます。
  • クラウドリカバリ。クラウドとオンプレミスの施設でインフラストラクチャをリカバリする義務はありますか?
  • アプリケーションの準備状況。バックエンドの依存関係を持つCitrix でホストされているアプリケーションには、BC/DRプランがありますか。また、RTOはCitrixの目標RTOにどのように対応していますか。Citrixは高速リカバリ用に設計できますが、コアアプリケーションにリカバリプランがない場合、またはRTO(目標復旧時間)が拡張されたリカバリプランがない場合、このリスクはDRにおけるCitrixプラットフォームの有用性に影響を与える可能性があります。
  • ネットワークセキュリティ。組織には、転送中に暗号化が必要なトラフィックセグメントを指示するセキュリティポリシーがありますか。この考慮事項は、通過するネットワークリンクによって異なります。DR のネットワークフローが本番環境と異なる場合は、DR シナリオでは、SSL VDA、ICA プロキシ、GRE、または IPSec VPN の ICA トラフィックカプセル化の使用が必要になることがあります。

ディザスタリカバリ(DR)設計に関する誤解

Citrix DR設計で最もよくある誤解の1つは、2つのデータセンターにまたがる単一のコントロールプレーンがDRを構成するという概念です。それはそうではありません。データセンターにまたがる単一のCitrixサイトまたはPVSファーム(近くにあるものも含む)は、高可用性設計を構成しますが、DR設計ではありません。お客様によっては、このパスを、DR機能に対する管理の簡素化を重視するビジネス上の意思決定として選択しているお客様もいます。StoreFrontサーバーグループのスパンは、適切に接続された(低レイテンシー) データセンター間でのみサポートされます 。同様に、は、 CTX220651で概説されているように、データセンターにまたがって導入する際に考慮すべきレイテンシの最大値を文書化しています。

次の図は、前述の根拠のために DR プラットフォームではないマルチデータセンターの HA Citrix アーキテクチャの例です。このリファレンスアーキテクチャは、物理的に分離された 2 つのデータセンター施設が互いに近接しており、低レイテンシー、広帯域幅の相互接続性により、1 つの論理データセンターとして扱うお客様が使用します。このアーキテクチャでは、DRまたはHAのニーズを満たすことはほとんどないため、DR 計画とCitrixの環境も推奨されます。

障害回復

上記の HA 概念リファレンスに加えて、ゾーンに基づく HA アーキテクチャは、地理的にまたがる冗長性を提供したいが、プラットフォームが完全に復旧可能である必要がないお客様にも利用できます。従来のIMAアーキテクチャ(XenApp 6.5以下)のゾーン概念は、FMA用に再設計され、XenDesktop 7.7で再導入され、7.11での大きな機能強化により、サイト内のさまざまな冗長性機能が提供され、複数ロケーション展開における課題を解決できます。

ゾーン設定 (7.11以降)機能を使用するサイトアーキテクチャでは、同一のCitrix リソースが複数のゾーンに展開され、1つのデリバリーグループに集約されます。ゾーンの優先度 (特定のリソースに対して他のゾーンにフェイルバックする機能) は、アプリケーション、ユーザーのホームゾーン、またはユーザーの場所に基づいて制御できます。この件に関する詳細は、「 ゾーンプリファレンス内部 」を参照してください。 VDA登録の自動更新機能 (XenDesktop 7.6で導入)を使用すると、VDAはサイト内のすべてのControllerの最新リストをローカルにキャッシュして維持できます。この機能を使用すると、ローカルDelivery ControllerまたはCloud Connectorがローカルゾーンで使用できなくなった場合に、サテライトゾーン内のVDAをプライマリゾーンにVDAに登録できます。StoreFront サーバーグループは、各ゾーンの場所に存在します。これは、ユーザーがプライマリゾーンが使用できない場合でも、ローカルアクセス層からリソースにアクセスし続けることを推奨します。

障害回復

これらのサポートされる HA オプションとは対照的に、次の図は、地理的に離れたデータセンターまたはクラウドリージョンにまたがる、サポートされていない、または推奨されていないコンポーネントアーキテクチャを示しています。これらの図は、コンポーネント間の距離とレイテンシーにより、有効な HA と DR を提供しません。プラットフォーム安定性の問題は、このような展開におけるレイテンシーの問題によっても発生する可能性があります。さらに、サイト間の管理境界の拡大は、DR プリンシパルには一致しません。私たちは、過去に顧客によって同様の概念設計を見てきました。

障害回復

もう 1 つのよくある誤解は、Citrix DRソリューションに含めることができる考慮の深さです。中核となるCitrix Virtual Apps and Desktops は、主にプレゼンテーションと配信プラットフォームです。Citrixコントロールプレーンは、独自の可用性とリカバリ設計がCitrixプラットフォームのDR要件を満たしている他のコンポーネント(ネットワーク、SQL、Active Directory、DNS、RDS CAL、DHCPなど)に依存します。Citrixが依存しているテクノロジの共有管理ドメインは、Citrix DRソリューションの有効性に影響を与える可能性があります。

ファイルサービス(共有上のユーザーデータやビジネスデータなど)と、Citrixがホストするアプリケーションおよびデスクトップのインターフェイスを使用するアプリケーションバックエンドに関するリカバリに関する考慮事項は、同様の重要性があり、お客様が完全に考慮されない場合もあります。アプリケーションの準備状況に関する以前のポイントを参照して、Citrix DRプラットフォームは、短いタイムスパンでリカバリするように設計できます。ただし、これらのコアユースケースの依存関係に、Citrixに似たRTO(目標復旧時間)のリカバリプランがない場合、またはリカバリプランがまったくない場合、このプランは、想定したとおりにDR でのフェイルオーバーに成功しても、これらの依存関係が使用できないためにユーザーがジョブ機能を実行できなくなる可能性があります。たとえば、Citrix でコアEMRアプリケーションをホストする病院を取ります。DRイベントが発生し、CitrixがDR内の「常時オン」のCitrixプラットフォームにフェイルオーバーし、ユーザーは接続中ですが、EMRアプリケーションは手動によるリカバリにより完了までに数時間または数日かかることがあります。この間、臨床スタッフはオフラインプロセス(ペンと紙)の使用を余儀なくされる可能性が高いでしょう。このような結果は、リカバリ時間やユーザー・エクスペリエンスに対するビジネス全体の期待と一致するものではありません。

次のセクションでは、DR vs. より詳細に HA。

ディザスタリカバリ (DR) と高可用性(HA)

高可用性とDRは、組織のニーズに対応し、リカバリ目標を満たすために不可欠です。HA は DR と同義ではありませんが、DR は HA を使用できます。このガイドでは、HA と DR を次のように解釈します。

  • HA は、サービスのフォールトトレランスを提供すると見なされます。サービスは、ユーザーの中断を最小限に抑えて、別のシステムにフェイルオーバーできます。このソリューションは、クラスタ化または負荷分散されたアプリケーションと同じくらいシンプルで、本番構成を反映し、常に利用可能な、より複雑なアクティブまたはスタンバイの「ホット」または「常時オン」のインフラストラクチャに実行できます。これらの構成では、フェイルオーバーは自動化される傾向があり、「地理冗長」配置と呼ばれることもできます。
  • DRは、主に代替データセンター(またはクラウドプラットフォーム)へのサービスのリカバリ(アプリケーションレベルの重大な障害またはデータセンターの致命的な物理的障害による)に関係しています。DRには、自動または手動のリカバリ・プロセスが必要となる傾向があります。リカバリを調整するための手順と手順が文書化されています。サービスの冗長性やフォールトトレランスは関係せず、一般的に、複数のタイプの障害に耐えるより広範な戦略です。

高可用性は、設計仕様とソリューションの展開に組み込まれる傾向がありますが、DRは、サービスのリカバリを実行するためのスタッフとインフラストラクチャリソースのオーケストレーション計画に大きく関係しています。

高可用性にはDRを含めることはできますか?はい。企業のミッションクリティカルな IT サービスでは、この概念は一般的です。たとえば、上記の HA の説明の 2 番目の例は、ソリューションに関連する他の非Citrixコンポーネントの適切なリカバリと組み合わせて、サービス(Citrix)が反対側のデータセンターにフェイルオーバーする高可用性DRソリューションとみなします。この特定のアーキテクチャは、アクティブ-パッシブまたはアクティブ-アクティブとして、すべてのユーザーに対してアクティブ-パッシブ、別のデータセンターよりも優先するユーザーのアクティブ-アクティブ、または 2 つのデータセンター間で負荷分散を行うアクティブ-アクティブ (アクティブ-アクティブ) など、さまざまなマルチサイト反復で実装できます。このようなソリューションの設計時には、スタンバイ容量を考慮し、考慮し、負荷を継続的に監視し、必要に応じてDRに対応できる容量を確保する必要があります。

また、ソリューションの整合性を維持するために、DRコンポーネントを本番環境でも最新の状態に保つことも不可欠です。このアクティビティは、最適な意図でこのようなソリューションを設計および導入し、本番環境においてより多くのプラットフォーム・リソースを消費し始め、ソリューションの DR 整合性を維持するために利用可能な容量を増やすことを忘れるお客様には見落とされることがよくあります。

Citrix のコンテキストでは、 公開されたガイダンスに従って 、2つの地理的にローカライズされた施設など、2つのデータセンター間のCitrix管理ドメイン(Citrixサイト、PVSファームなど)にまたがる場合、DRおよびStoreFrontサーバーグループなどの一部のコンポーネントでは構成されません。同様に、 公開されているガイダンスによるPVSのデータベース遅延制限により、そのような展開もサポートされない可能性があります。 公開されているガイダンスに従って、サテライトコントローラーとデータベース間の最大遅延が原因で、地域間のサポート性の制約がCitrix サイトとゾーンの設計にも及ぶ場合があります。

多くのCitrixコンポーネントはデータベースなどの依存関係を共有しているため、2つのデータセンター間に管理境界を延長しても、いくつかの主要な障害シナリオから保護されません。データベースが破損した場合、障害ドメインは両方のファシリティのアプリケーションサービスに影響を与えます。HA Citrix ソリューションを DR に十分であると見なすには、第 2 のファシリティでは主要な依存関係や管理境界を共有しないことをお勧めします。たとえば、ソリューション内のデータセンターごとに個別のサイト、ファーム、およびサーバーグループを作成します。リカバリ・プラットフォームを可能な限り独立させることにより、コンポーネント・レベルの障害による本番環境と災害復旧環境の両方への影響を軽減します。この考慮事項はCitrixにとどまらず、本番環境とDR環境間で異なるサービスアカウント、ファイルサービス、DNS、NTP、ハイパーバイザ管理、認証サービス(AD、RADIUSなど)を使用することも推奨され、単一障害点を軽減することもできます。

ディザスタリカバリ層の分類

DRの階層分類は、アプリケーションまたはサービスの重要度を明確にするため、組織のDR戦略の重要な側面です。これは、RTO(およびそのレベルのリカバリを達成するためのコスト)を決定するためです。一般的に、RTO が短いほど、DR ソリューションのコストは高くなります。ビジネスの重要度およびRTO(目標復旧時点)に基づいて、さまざまな相互依存を異なる分類に分解できるため、コスト重視の災害復旧ケースを最適化できます。

以下は、Citrix上でホストされているCitrixインフラストラクチャサービス、その依存関係、および重要なアプリケーションまたはユースケース(およびVDAに関連付けられている)を評価する際の参考となるDR層分類の例です。DR 階層は、優先順位またはリカバリの優先順位で概説され、0 が最も重要になります。組織では、各自のリカバリ目標とクラス分けのニーズに合わせて、DR階層のクラス分けを適用または開発することが推奨されます。

災害復旧階層 0

階層0:リカバリ目標(例)

目標復旧時間:0

目標復旧時点:0

階層 0-分類の例

コアITインフラストラクチャ

  • ネットワークとセキュリティインフラストラクチャ
  • ネットワークリンク
  • ハイパーバイザーと依存関係 (コンピューティング、ストレージ)

コアITサービス

  • Active Directory
  • DNS
  • DHCP
  • ファイルサービス
  • RDS ライセンス
  • 重要なエンドユーザーサービス(Citrix)

階層 0-メモ

この分類は、主にコアインフラストラクチャコンポーネントを対象としています。これらのコンポーネントは、分離されたネットワークセグメントではなく、他の階層の依存関係であるので、DR ロケーションで常に使用できます。これらのマシンは、本番環境と同等のものと一緒にプロビジョニングおよび保守する必要があります。Citrix が重要なアプリケーションをホストしている場合、Tier 0プラットフォームと見なされる可能性があります。このようなシナリオでは、CitrixインフラストラクチャはDRに「ホット」展開されます。

ディザスタリカバリ階層 1

階層1:リカバリ目標(例)

目標復旧時間:4 時間

RPO(目標復旧時点): 15分

階層 1-分類例

重要なアプリケーション

  • ウェブサイトとウェブアプリ
  • ERPおよびCRMアプリケーション
  • 基幹業務アプリケーション

Citrix ユースケース

  • 管理
  • カスタマーサービスまたはセールス
  • ITエンジニアリングとサポート

階層 1-メモ

ビジネスが中核的なビジネスアクティビティを実行するアプリケーションまたは仮想デスクトップは、通常、この階層に含まれます。また、階層0と同様の「ホット・スタンバイ」DRアーキテクチャを採用するか、自動レプリケーション/フェイルオーバー・ソリューションのメリットを享受できます。クラウドにプロビジョニングする場合、RTO目標に影響を与える可能性があるため、 後で説明する考慮事項を考慮する必要があります

ディザスタリカバリ階層 2

階層2:リカバリ目標(例)

目標復旧時間:48時間

RPO(目標復旧時点): 1時間

階層 2-分類の例

重要でないアプリケーション重要でないCitrixでは、 階層1または階層0アプリケーションの機能に影響を与えないユーザーデータを使用します。

階層 2-メモ

ビジネス運用の鍵となるアプリケーションまたはユースケース。ただし、短期的に利用できない場合には、財務、評判、運用上の重大な影響を引き起こす可能性は低いアプリケーションまたはユースケース。これらのアプリケーションは、バックアップからリカバリされるか、自動リカバリ・ツールによって最も低い優先度でリカバリされます。

ディザスタリカバリ階層 3

階層3:リカバリ目標(例)

目標復旧時間:5 日間

目標復旧時点:8 時間

Tier 3-分類の例

使用頻度の低いアプリケーション

階層 3-メモ

停止の影響がごくわずかであるアプリケーションは、最大1週間まで利用できません。 これらのアプリケーションは、バックアップからリカバリされる可能性が高くなります。

ディザスタリカバリ階層 4

階層4:リカバリ目標(例)

目標復旧時間:30 日

RPO(目標復旧時点):24時間またはなし

階層 4-分類の例

非実稼働環境

階層 4-メモ

アプリケーション、インフラストラクチャ、VDIの停止によってビジネス・オペレーションへの影響もごくわずかになり、長期間にわたってリストアできます。 また、RPO(目標復旧時点)を拡張することも、性質によってはまったく使用しない場合もあります。これらのRPO(目標復旧時点)は、バックアップからリカバリすることも、DRで新規に構築することもでき、リカバリすべき最後の階層とみなされます。

Citrix DRプランニングで階層分類が重要なのはなぜですか?

階層の分類は、Citrix にとって次の理由で重要です。

  • Citrixインフラストラクチャはビジネス運用にどれくらい重要ですか?重要なのは、Citrixが重要であるとみなされ、ホストするアプリケーションが重要であると見なされた場合、Citrixインフラストラクチャはクリティカルに分類されます。
  • Citrixがホストするユースケースまたはコアビジネスアプリケーション。DR階層の分類は異なっていますか?

最初の質問では、多くのエンタープライズCitrix展開は、重要なアプリまたはデスクトップの配信により、階層0に分類される傾向があります。これは、ネットワーク、Active Directory、DNS、ハイパーバイザーインフラストラクチャなど「常にオン」の階層です。ただし、この状況は、すべてのCitrixの使用例で必ずしもそうではありません。すべてのCitrix ユースケースを階層1以上に該当する場合は、Tier 0として扱うと、DRプロセスの全体的なコストと複雑さに影響を与える可能性があります。

2番目の質問は、Citrix のユースケースによる分類を強調し、クラウド環境で最も重要になります。 これについては後で詳しく説明します。クラウドでは、「常時稼働する」アプリケーションまたはデスクトッププラットフォームに対応することと、ビジネス上の重要度が低いと考えられるアプリケーションやデスクトップに対して、コスト面で大きな考慮事項があります。このような考慮事項は、本番環境におけるアプリケーションやユースケースの分離(サイロ)にも影響し、DRプラットフォームでの導入の柔軟性を活用できます。

CitrixのDR設計を確立する場合、Citrix自体の範囲を超えて議論を行うことは、ビジネスユニットに期待値を設定するのに役立ちます。一例として、Citrix 環境は「常時稼働」サービスと見なされ、代替データセンターで高可用性が確保されますが、Citrixのホストアプリケーションが依存する重要なアプリケーションバックエンドは、リカバリが実行されるまで数時間使用できなくなります。このギャップにより、2つのプラットフォーム間でリカバリ時間の差異が生み出され、リカバリ中に誤解を招くユーザーエクスペリエンスを提供できます。Citrixはすぐに使用できますが、主要なアプリケーションは機能しません。当初期待値を設定すると、すべての関係者に対して、リカバリエクスペリエンスがどのように見えるかを適切に把握できます。状況によっては、Citrixを反対側の施設でホットスタンバイ(常にオン)に保ち、アクセス層のフェイルオーバーを手動で制御して、プラットフォームの可用性に関する誤解を避けることができます。

ディザスタリカバリオプション

このセクションでは、一般的なCitrixリカバリ戦略について、その長所と短所、主な考慮事項について説明します。Citrixの他のリカバリ機能または次のテーマのバリエーションも可能です。このセクションでは、最も一般的なものの一部に焦点を当てています。また、このセクションでは、初期の段階で示された主要な質問への回答が DR 設計にどのように影響するかについても説明します。

以前のDRの質問の相関関係が多すぎると、次の質問トピックでは、Citrix DRの設計上の意味が次のように表示されます。

  • バックアップ戦略とRTO(目標復旧時間)CitrixインフラストラクチャまたはCitrixから提供されるアプリケーションがミッションクリティカルと判断された場合、複数のデータセンターにホットスタンバイまたはアクティブ-アクティブのCitrixインフラストラクチャが存在する「常時オン」モデルを採用する必要があります。このアーキテクチャでは、各データセンター(個別のCitrixサイト、該当する場合はPVSファーム、StoreFront サーバーグループなど)に複数の独立したCitrixコントロールプレーンが作成されます。Citrixインフラストラクチャのコントロールプレーンにまたがっても、DR(データセンターにまたがるサイトやサテライトゾーンを使用するなど)はDRを構成しません。企業がCitrixのDRプラットフォームを予測している場合は、その義務に対処します。
  • リカバリの範囲。CitrixがDRのホットスタンバイ(常時オン)容量で展開され、コアビジネスアプリケーションのバックエンドがリカバリに8時間かかる場合、自動アクセス層フェイルオーバーを採用するのは意味がありません。アクセス層の手動フェイルオーバーをより適切に設定できます。
  • ユースケース。災害復旧シナリオで業務運用を維持するために、重要なワークロードまたはコアアプリケーションのみをCitrixで迅速にリカバリする必要がある場合は、このシナリオによって容量の観点からは災害復旧コストを削減できます。優先順位の異なる複数のユースケースでリカバリが必要な場合、 前述のリカバリ階層化戦略によるビジネスインパクトとは対照的に 、ユースケースごとの重要度の分類では、キャパシティコストを削減することはできませんが、ITスタッフはより焦点を絞ったリカバリの優先順位のセットを提供できます。
  • 機能。HDX Insight、Session Recordingなどの特定のコンポーネントがDRプラットフォームの運用にとって重要ではないと見なされた場合、DR環境でのそれらの省略により、複雑さとメンテナンスのオーバーヘッドがいくらか解消されます。同様に、災害復旧シナリオの多くのユースケースが、よりシンプルで汎用的なCitrix提供オプションをDRで維持できる場合、これにより複雑さとコストが軽減されます。たとえば、技術的に実現可能な場合は、プールされた VDI の代わりにホストされた共有デスクトップを使用するか、ビジネス運用に有害でない限り、複数のユースケースを 1 つに集約します。 障害回復
  • 既存の DR. たとえば、組織の既存のDR戦略が、データレプリケーションおよびオーケストレーションツールを使用してCitrixおよびその他のアプリケーションインフラストラクチャをリカバリする場合、ほとんどのCitrixコンポーネントがこのモデルに適しています。プラットフォームのサイズと単一イメージ管理テクノロジへの依存が本番プラットフォーム要件である場合、多くの場合、このようなテクノロジは適切ではありません。ホットスタンバイのCitrixプラットフォームのハイブリッドアプローチと、おそらくマスターイメージのレプリケーションがより適切である可能性があります。
  • データの重要度。DRでのリカバリにプロファイルが重要であると見なされる場合は、適切なレプリケーション・テクノロジーが必要となる場合があります。多くの組織では、DRシナリオのプロファイルにはあまり関心が無く、新規作成を受け入れています。この考慮事項は、Citrixでアクセスされるユーザーデータ(フォルダリダイレクト、マップされたドライブ)にも適用されます。このデータのRPO(目標復旧時点)とRTO(目標復旧時間)は、ビジネス上の判断となります。さらに、多くの永続的なVDIが、DRにそのまま保持できるほど重要であると見なされる場合(ユーザーがソフトウェアの再インストールなどを要求する場合など)、これらの仮想マシンをレプリケーション用に考慮する必要があります。このため、リカバリをサポートするために追加コストが発生する可能性があります。
  • 災害の種類。お客様が障害から保護したい範囲によって、さまざまなアーキテクチャの変更が左右されます。お客様がデータセンターまたはクラウドリージョン内のCitrixインフラストラクチャの高可用性のみを必要とする場合、このタイプの災害では、管理コンポーネントが冗長であり、反対側のインフラストラクチャで動作していることを確認するだけで済みます。たとえば、StoreFront サーバーペアの種類では、VMware 非アフィニティルールを使用して、クラスタ内の異なるホスト上で動作するか、データセンター内の異なるクラスタ上で動作するか、あるいは異なる可用性セットの一部として動作します。このような状況では、冗長コントロールプレーンを完全に作成する必要はほとんどありません(複数のCitrixサイトやStoreFront サーバーグループなど)。ただし、DR がリージョンに関係なく複数のデータセンターを対象とする場合は、各データセンター (AD、DNS、SQL、ハイパーバイザーなど) でローカル依存関係を使用する冗長コントロールプレーンの方が適しています。お客様がグローバルであり、複数のデータセンターを使用して、これらのデータセンターにローカルなアプリケーションバックエンドでCitrixサービスを提供する(または計画している)場合、地理的にローカライズされたアクティブ-アクティブ HA-DR アーキテクチャの方が適切である可能性が高くなります。このアーキテクチャでは、地理的にローカライズされたCitrixインフラストラクチャを使用して、必要に応じてセカンダリの優先順でバックアップデータセンターにフェイルオーバーできるため、可能な限り最適なユーザーエクスペリエンスをユーザーに提供します。
  • クライアントユーザー。上記のユーザー、アプリ、およびデータのローカリゼーションに関する考慮事項以外に、一部のクライアントユーザネットワークは、インターネットや WAN への発信通信を制限できるセキュリティデバイス (プロキシ、ファイアウォールなど) を使用して比較的ロックダウンできます。この状態がクライアントネットワークに適用されるかどうかを考慮し、Citrixサービスの新しいIP(StoreFront VIPおよびVDA IP、またはCitrix Gateway IPなど)をローカルセキュリティ構成で考慮して、ローカルLANセキュリティによるリカバリの遅延が発生しないようにすることが重要です。DR を起動するときの制限準備の観点からは、DRが発生した場合、クライアント・アクセスは何らかの方法で変化しますか。顧客の災害復旧シナリオによっては、WANが使用できず、すべてのユーザーがインターネット経由でCitrixリソースにアクセスする必要があると仮定できます。このような手順では、BCおよび準備計画に文書を作成し、サポートデスクへの負担をさらに軽減するために、エンドユーザー(サポートされているCitrixクライアントの詳細、企業またはBYODデバイスへのアクセスに関する前提条件)に関する前提条件(企業またはBYODデバイスへのアクセスに関する前提条件)を設定する必要があります。
  • ネットワーク帯域幅。VDAトラフィック(ICA、アプリケーション、ファイルサービス)に関するネットワーク帯域幅の使用量は、DR施設のネットワークサイジングとファイアウォールを考慮する必要があります。この考慮事項は、VPN ゲートウェイと仮想ファイアウォールの容量に制限があるクラウド環境で特に重要です。VDAからの本番トラフィックを監視して、サイジングの平均値を決定することは、ネットワークを効果的にサイズ設定するために重要です。ネットワークの制約がある場合、組織は呼び出された場合に、予測される DR トラフィックの負荷に対応するために、異なるネットワーク構成を使用する必要があります。Citrix SD-WANのWAN最適化テクノロジーは、トラフィック需要の削減に役立ちます。
  • フォールバック(またはフェイルバック)。DRで変更されたユーザー・データ、または災害復旧中にVDAイメージがある場合、組織はこれらの変更を本番環境に反映するためにフェイルバックを計画する必要があります。本番環境はリカバリ可能であることが証明されます。ユーザーデータの場合は、レプリケーションの順序を逆にしてリカバリするのと同じくらい簡単です。同様に、Citrixインフラストラクチャでは単一のイメージ管理テクノロジーを使用しない場合です。MCSまたはPVSを使用している場合は、マスターイメージまたはvDiskを本番環境に手動でレプリケートし、それに応じてVDAを更新できます。

Citrixの一般的な回復オプションの概要を次に示します。それぞれの適応はフィールドに存在しますが、比較のためにそれぞれの基本的なバージョンを概説しています。オプションは、最も単純な(多くの場合、RTO、低コスト)から、より高度なもの(RTO は低いがコストが高い)まで構成されています。特定の組織にとって理想的な選択肢は、利用可能なITスキル、予算、インフラストラクチャに加えて、ホストされたアプリケーションやユースケースのリカバリ時間を調整することです。さらに、多くのオプションは、実現可能ですが、ADCや単一イメージ管理テクノロジーなどのネットワークおよびストレージと統合されたCitrixテクノロジーは、「常にオン」のリカバリモデル以外の方法には適していないことを示しています。技術的に達成することは不可能というわけではありませんが、それらの達成に伴う複雑さのレベルによって、リカバリのリスクが高くなり、人為的なミスが生じやすくなります。

リカバリオプション-オフラインバックアップからのリカバリ

障害回復

長所と短所

長所:

  • レプリケーションまたはホットスタンバイソリューションに比べてメンテナンスコストの削減

短所:

  • ダウンタイムへの大きな影響
  • より大規模で詳細なリカバリプラン(DR オーケストレーション)ドキュメント
  • リカバリ時間の延長
  • バックアップの整合性と経過時間に依存する
  • 手動での再構成が必要な場合(ネットワークなど)、人的エラーの度合いが高くなる
  • プールされた高速クローン MCS または PVS には不適切
  • ネットワークが原因でCitrix VPX ADCには不向き( nsconfigディレクトリとns.confファイルのバックアップを使用して再構築する必要がある場合があります)

ユースケースと前提条件

成熟度の低いIT組織やIT運用予算が限られている組織にとって有用であり、コアビジネスサービスを回復するために長期にわたるシステム停止が発生する可能性があります。バックアップの復元の整合性を定期的にテストし、明確に文書化されたリカバリ・プロセスに従うことを前提としています。

リカバリオプション:レプリケーションによるリカバリ

障害回復

長所と短所

長所:

  • レプリケーションは自動化されている可能性が高く、RTO(目標復旧時点)とRPO(目標復旧時点
  • 自動リカバリ・ソリューションに比べて、あまり複雑でないテクノロジーを使用している可能性が高い

短所:

  • 管理介入に依存
  • より大規模で詳細なリカバリプラン(DR オーケストレーション)ドキュメント
  • 手動での再構成が必要な場合(ネットワークなど)、人的エラーの度合いが高くなる
  • プールされた高速クローン MCS または PVS には適していません。マシンカタログの再作成は、投影されたRTO に組み込まれます。ただし、DRにダミーマシンカタログを作成するか、またはDRでVDAインスタンスをスケールアウトし、複製されたマスターイメージを適用する「カタログの更新」アクションを実行すると、このRTO(目標復旧率)を短縮できます。
  • ネットワーキングのためCitrix VPX ADCには適していないため、ホットスタンバイADCの採用に適している

ユースケースと前提条件

成熟度が低いIT組織や、IT運用予算が限られている組織に役立ちます。このソリューションは、SAN ベンダーまたはハイパーバイザーベンダー(vSphere Replication など)のストレージレプリケーションテクノロジを使用して、WAN 経由で別の施設に VM をレプリケートします。

リカバリオプション:自動リカバリによるレプリケーション

障害回復

長所と短所

長所:

  • ホットスタンバイソリューションに比べてメンテナンスコストの削減
  • レプリケーションは自動化されている可能性が高く、RTO(目標復旧時点)とRPO(目標復旧時点
  • リカバリ・プランは自動化される傾向がある
  • 管理介入と人的ミスを少なくする

短所:

  • VMware SRM、Veeam、Zerto、ASRなどの先進的なテクノロジーに依拠し、リカバリを調整し、ネットワーク・パラメータを変更する
  • プールされた高速クローン MCS または PVS には適していません。マシンカタログの再作成は、投影されたRTO(目標復旧率)に組み込む必要があります。ただし、DRにダミーマシンカタログを作成するか、またはDRでVDAインスタンスをスケールアウトし、複製されたマスターイメージを適用する「カタログの更新」アクションを実行すると、このRTO(目標復旧率)を短縮できます。
  • ネットワーキングのためCitrix VPX ADCには適していないため、ホットスタンバイADCの採用に適している

ユースケースと前提条件

DR施設に適切なリソースと予算がある企業組織に適しています。 このソリューションは、前のオプションと同じストレージレプリケーションに依存しますが、特定の順序での仮想マシンのリカバリ、NIC構成の調整(必要な場合)などを行うDRオーケストレーション・テクノロジーが含まれています。

リカバリオプション:手動フェイルオーバーによるホットスタンバイ(アクティブ/パッシブ)

障害回復

長所と短所

長所:

  • プラットフォームが「常時オン」であるため、リカバリ時間が短い
  • VPX、MCS、PVSなどのストレージおよびネットワークに依存するコンポーネントをサポート
  • リカバリ計画(DR オーケストレーション)に関するドキュメントの削減

短所:

  • URLをフェイルオーバーしたり、ユーザーをバックアップURLに誘導したりするには、管理者による介入が必要
  • DRに「ホット」ハードウェアがスタンバイ状態になっているため、コストが高くなる
  • スタンバイプラットフォームの構成と更新を本番環境と同期させるため、管理オーバーヘッドが増大する

ユースケースと前提条件

DR施設に適切なリソースと予算がある企業組織に適しています。ホットスタンバイの「完全にスケーリング」プラットフォームまたは「オンデマンドスケーリング」プラットフォームを使用できます。後者は、運用コストを削減するためのクラウドリカバリにとって魅力的ですが、 注意が必要です

フェイルオーバー時に、管理者は、 **1つ以上のアクセスURLのDNSエントリーを更新して** 、Citrix GatewayおよびStoreFront の1つ以上のDR IPを指しています。または、ユーザーは「バックアップ」または「DR」URLを使用して開始するように正式な通信によって通知されます。

この手動オプションは、アプリケーションのバックエンドに長いリカバリ時間が必要になりますが、Citrixが完全に利用可能で、アプリケーションが利用可能でない場合、ユーザーの混乱を招くシナリオに役立ちます。

このモデルは、成熟した IT 組織と、フェイルオーバーをサポートするために十分な WAN と計算インフラストラクチャを使用できることを前提としています。

リカバリオプション:自動フェイルオーバー機能を備えたホットスタンバイ(アクティブ/パッシブ)

障害回復

長所と短所

長所:

  • プラットフォームが「常時オン」であるため、リカバリ時間が短い
  • VPX、MCS、PVSなどのストレージおよびネットワークに依存するコンポーネントをサポート
  • 最小限のリカバリプラン(DR オーケストレーション)ドキュメント
  • URLのフェイルオーバーとしてエンドユーザーが簡単に
  • Citrix Gateway でのEPAスキャンをサポート

短所:

  • DRに「ホット」ハードウェアがスタンバイ状態にあり、Citrix ADCライセンスに搭載されているため、コストが高くなります
  • アクセス階層の複雑さの向上
  • スタンバイプラットフォームの構成と更新を本番環境と同期させるため、管理オーバーヘッドが増大する

ユースケースと前提条件

企業のお客様と共通の構成で、Citrix ADC GSLB(ADC Advanced 以上が必要)を介してDRサイトへの自動フェイルオーバーを可能にします。 このモデルは、成熟した IT 組織と十分な WAN を想定し、フェイルオーバーをサポートするためのインフラストラクチャを計算します。また、このモデルでは、アプリケーションとユーザーデータの依存関係が、最新のアクティブサイトのバージョン/更新と整合しており、同様に自動化された方法でDR施設でリカバリ可能であることを前提としています。これにより、エンドユーザに対するサービスの長期間の影響や部分的なソリューション機能による混乱を軽減できます。

リカバリ・オプション:自動フェイルオーバー機能を備えたアクティブ/アクティブ

障害回復

長所と短所

長所:

  • プラットフォームが「常時オン」であるため、リカバリ時間が短い
  • VPX、MCS、PVSなどのストレージおよびネットワークに依存するコンポーネントをサポート
  • 最小限のリカバリプラン(DR オーケストレーション)ドキュメント
  • エンドユーザーにシームレスに

短所:

  • DRに「ホット」ハードウェアがスタンバイ状態にあり、Citrix ADCライセンスに搭載されているため、コストが高くなります
  • 最も高いアクセス階層の複雑さ
  • スタンバイプラットフォームの構成と更新を本番環境と同期させるため、管理オーバーヘッドが増大する
  • アクティブ/アクティブGSLBは現在、Citrix Gateway でのEPAスキャンをサポートしていません。Citrix Gateway URLのアクティブ/パッシブGSLB構成が推奨されます
  • 管理者は、すべてのデータセンターでリソースとハードウェアの容量を監視および調整し、プラットフォームが拡張しても DR 容量の整合性が影響を受けないことを確認

ユースケースと前提条件

企業のお客様にはより高度で一般的な構成で、アクセス層のURLをCitrix ADC GSLB経由でアクティブ-アクティブ動作させることができます(ADC Advanced以上が必要)。この機能は、ローカルデータセンターが互いに近接している環境、またはデータセンターをリモートにできるが、ユーザーをお好みのデータセンターにピン留めする手段を備えている場合(多くの場合、高度なStoreFront 構成とGSLBによって制御される程度は少ない)マルチサイトのシナリオで役立ちます。

このモデルは、成熟した IT 組織と十分な WAN を想定し、フェイルオーバーをサポートするためのインフラストラクチャを計算します。また、このモデルでは、アプリケーションとユーザー・データの依存関係が最新のサイトのバージョン/更新と一致し、同様に自動化された方法でDR施設でリカバリ可能であることを前提としています。これにより、エンドユーザに対するサービスの長期的な影響や部分的なソリューション機能による混乱を軽減できます。

パブリッククラウドでのディザスタリカバリ

オンプレミスからクラウドプラットフォームへのディザスタリカバリまたはクラウドからクラウドへの障害復旧には、オンプレミスのリカバリシナリオでは存在しない独自の課題や考慮事項があります。

DR 設計計画では、DR 計画時にクラウドインフラストラクチャを適用する DR プランが無効、コストがかかる、または目標容量を満たすことができない状態になる原因を回避するために、次の主な考慮事項に対処できます。

考慮事項 — ネットワークスループット

インパクトエリア

可用性 パフォーマンス コスト

詳細

お客様は、仮想ファイアウォール、VPN ゲートウェイ、および WAN アップリンク (AWS Direct Connect、Azure Express Route、GCP クラウドインターコネクトなど) を含むクラウドソリューション内のスループットジャンクションポイントを過小評価し、それゆえに小さくなる可能性があります。Citrix プラットフォームをクラウドに復旧し、わん 現在、Azure VPN Gatewayと AWS Transit Gatewayの上限は 1.25 Gbps です。この制限は、クラウドアーキテクチャにとって重要な場合、ゲートウェイをスケールアウトしたり、複数の VPC(AWS がある場合)を使用したりする必要があります。 多くの仮想ファイアウォールでは、処理できるスループットにライセンス制限があり、最大限でも最大限に達しています。この制約では、ファイアウォールの数をスケールアウトし、何らかの方法でそれらを負荷分散する必要があります。

推奨事項

スループットのサイジング計算を確立するときは、DR キャパシティの全負荷を想定します。同時ユーザーごとに次のデータをキャプチャします。

  • ICAセッションの推定帯域幅
  • セキュリティ境界を通過する場合の、セッションあたりのアプリケーション通信帯域幅の見積もり
  • セキュリティ境界を通過する場合の、セッションあたりのファイルサービスの推定帯域幅

上記のメトリックでは、本番環境のVDAとの間で送受信される現在のトラフィックパターンに関するデータを収集すると便利です。また、これらのネットワークパスを使用することが予想されるCitrixとは無関係な他のデータフローも考慮する必要があります。 Citrix DRの計画には、ネットワークチームとセキュリティチームと協力して、セキュリティゾーンおよびネットワークセグメントを通過する帯域幅の見積もりが理解され、対応できることを確認します。帯域幅が重視される場合、Citrix SD-WAN WAN最適化は、回線上でのセッションフットプリントの削減や、複数のネットワーク接続にわたる帯域幅の集約に役立ちます。

考慮事項 — Windows デスクトップOSライセンス

インパクトエリア

コスト

詳細

異なるクラウドプラットフォームで実行されている Microsoft Desktop OS インスタンスについては、ライセンスに関する考慮事項が複雑になる可能性があります。Microsoft は 2019 年 8 月にクラウドライセンス権を改訂しました 。これは、一部の展開シナリオで VDI のコストへの影響に影響を与える可能性があります。

推奨事項

ユースケースアーキテクチャを決定する際には、Microsoft の最新のガイダンスを参照してください。DR ソリューションで VDI に潜在的なコストの問題がある場合は、可能であれば、ホスト共有デスクトップ (RDS CAL の拡張が必要な場合があります) を補足することを検討してください。これは、より低い運用コストで高い柔軟性を実現できるからです。

考慮事項:VDAスケールアウトのタイミング(DRの前または実行中)

インパクトエリア

コストの可用性

詳細

お客様は、必要なときにのみ容量を支払うという魅力によって、クラウドに惹かれます。このソリューションでは、使用されているかどうかにかかわらず、予約済みインフラストラクチャに支払われないため、DR コストを大幅に削減できます。

しかし、大規模な場合、クラウドプロバイダーは一度に数百または数千の仮想マシンをパワーオンする SLA にコミットすることはできません。このソリューションは、DR用のVDAフットプリントが数百または数千のインスタンスに実行することが予想される場合、特に困難になります。クラウドプロバイダーは、手元にさまざまなインスタンスサイズの大容量を維持する傾向がありますが、このプロバイダーは瞬間によって異なる場合があります。地理的領域に影響を与える災害が発生した場合、オンデマンド容量を要求する他のテナントからの競合が発生する可能性があります。

決定に影響を与える可能性がある回答が必要な主な質問:

  • 常に 100% の災害復旧容量が必要ですか
  • クリティカルなワークロードのみ (つまり、本番環境のサブセットのみ) をホストする必要がありますか?
  • DRの時点でスケールアウトすることは可能ですか?その場合は、各ユースケースのさまざまなRTO(目標復旧時間)をよりよく理解するために、段階的な容量不足をサポートするために、DR 階層によってユースケースに優先順位を付けていますか。
  • アプリまたはホストされた共有デスクトップユースケースをサポートする OS インスタンスをスケールアップして、プロビジョニング時間を節約し、運用コストを節約するためにこれらのインスタンスをパワーオフすることはできますか?

推奨事項

Citrix では、まずクラウドプロバイダーと連携して、RTO期間内に予想されるキャパシティをパワーオンする可能性と、オンデマンドインスタンスで満たすことができるかどうかを判断することをお勧めします。 DRシナリオでVDAの容量可用性の制限を回避するには、できるだけ多くのアベイラビリティーゾーンでVDAをプロビジョニングすることをお勧めします。大規模では、さまざまなクラウドリージョンにまたがってプロビジョニングを行い、それに応じてアーキテクチャを調整する価値があります。一部のクラウドプロバイダーは、VM の消費をさらに軽減するために、さまざまなサイズの VM インスタンスタイプを採用することを提案しています。 可能であれば、VDAインスタンスを事前にプロビジョニングし、オフラインのままにしておき、定期的に更新することが賢明です。プロビジョニングはリソースと時間のかかるプロセスであり、事前プロビジョニングを行うことで、オンデマンドでVDAのDR容量をスケールアウトできます。 組織がキャパシティ可用性のリスクをほとんど求めていない場合は、リソースの可用性を保証するために、予約済みまたは専用のコンピューティングキャパシティを適用し、それに応じて予算を作成することが必要になる場合があります。 オンデマンドモデルと予約済み/専用モデルを組み合わせて、DRリカバリ層を参照できます。特定のユースケースでは、VDAをすぐに利用できるようにする必要がありますが、その使用例では、VDAの維持に重要度が低い場合は、数日または数週間という長いRTO(目標復旧時間)でリカバリできる柔軟性もあります。ビジネス。

考慮事項 — アプリケーションデータとユーザーデータ

インパクトエリア

コスト 可用性 パフォーマンス

詳細

ユーザーデータとアプリケーションバックエンドの場所は、Citrix DR環境のパフォーマンス、場合によっては可用性に顕著な影響を与える可能性があります。一部のお客様のシナリオでは、マルチデータセンターDRアプローチを採用しています。この場合、すべてのアプリケーションバックエンドやユーザーデータ(ホームドライブや部門ドライブなど)をCitrixと一緒にクラウドにリカバリすることはできません。このギャップにより、予期せぬ待ち時間が発生し、アプリケーションのパフォーマンスや機能に影響を与える可能性があります。スループットの観点から、このギャップは、利用可能なネットワークおよびセキュリティアプライアンスの帯域幅にさらに負担をかける可能性があります。

推奨事項

可能な場合は、アプリケーションデータとユーザーデータをDR内のCitrixプラットフォームに対してローカルに維持し、WAN全体のレイテンシーと帯域幅の要求を軽減することにより、パフォーマンスを可能な限り最適な状態に維持します。

Citrix Cloudのディザスタリカバリ計画

Citrix Virtual Apps and Desktops(CVAD)のオンプレミスまたは「従来の」展開と、災害復旧計画に関してCitrix Cloudによって提供されるCitrix DaaS:

  • Citrix は、パートナー/顧客のほとんどの制御コンポーネントを管理し、Citrixサイトとそのコンポーネントに関する重要なDR要件をその責任から排除します。
  • Citrixリソース用のDR環境を展開するには、お客様がリカバリの「リソースの場所」にCitrix Cloud Connectorを展開し、必要に応じてCitrix Gateway用のStoreFront およびCitrix ADCを展開する必要があります。
  • Citrix Cloud独自のサービスアーキテクチャは、設計上、地理的に冗長性があり、耐障害性があります。
  • Citrix WorkspaceおよびCitrix Gatewayサービスを使用している場合は、アクセス層のDRは必要ありません。

これらの主な相違点を超えて、以前のセクションのDRに関する考慮事項の多くは、引き続きパートナー/顧客の計画が必要です。これは、Citrix Gateway ServiceとCitrix WorkspaceサービスがCitrix Cloudから使用されない場合、Citrix VDA、ユーザーデータ、アプリケーションバックエンド、およびCitrix Access層に対する責任が維持されるからです。

このセクションでは、Citrix Cloudの適切なDR戦略を定義する際に役立つ重要なトピックについて説明します。

Citrix DaaS が災害復旧を簡素化

以下は、シトリックスが管理するコンポーネントとパートナー/顧客管理コンポーネントの責任の分離に加えて、Citrix DaaS Sの概念アーキテクチャの概要を示す典型的な概念図です。ここに示されていないのは、「シトリックスによって管理される」に該当するCitrix DaaSに関連する選択的なCitrix Cloud コンポーネントであるWEM、アナリティクス、およびCitrix Gatewayの「サービス」です。

障害回復

図に示すように、リカバリの決定を必要とする制御コンポーネントの大部分は、シトリックスの管理範囲に該当します。クラウドベースのサービスであるCitrix DaaSアーキテクチャは、 Citrix Cloud リージョン内で非常に回復力があります。これはCitrix Cloudの「秘密のソース」の一部であり、 Citrix CloudのSLA内で検討されています

サービス可用性の管理責任は次のとおりです。

  • Citrix コントロールプレーンを使用し、使用中の場合は「サービス」にアクセスします(ワークスペース、Citrix Gatewayサービス)。
  • お客様リソースの場所コンポーネント(Cloud Connector、VDA、アプリケーションバックエンド、インフラストラクチャの依存関係(AD、DNSなど)、およびアクセス層(StoreFront、Citrix ADC)などのCitrix Cloudアクセス層を使用していない場合。

お客様は、Citrix DaaS でのディザスタリカバリに関して次の利点を得ることができます。

  • 管理対象のコンポーネントの数が少なく、サイト間で複製および保守する独立した構成が少なくなるため、管理上の負担が軽減されます。
  • クラウド内の「Citrixサイト」の一元化された構成により、Citrix展開環境間で人為的なミスや構成の不一致が発生する可能性が軽減されました。
  • 構成および保守するCitrixサイトとコンポーネントの数が少なく、場所間で管理するアクセス層がない(オプション)、およびCitrixリソース用のディザスタリカバリロジックが複雑でないため、本番環境と障害復旧環境のリソース管理の簡素化により、運用が合理化されます。
  • 導入と保守に必要なサーバ・コンポーネントの数を減らし、運用コストを削減し、監視データベースの一元化により、導入環境全体の傾向を一元的に把握できます。

Citrix DaaS のディザスタリカバリに関する

リカバリ計画のための多くのコンポーネントはお客様の管理範囲から除外されますが、お客様は、DRの計画と管理、およびリソースの場所内にあるコンポーネントの高可用性 (オプション) について責任を負います。

可用性への対処方法における最も重要な違いは、リソースロケーションの解釈と構成方法にあります。Citrix DaaS自体では、 リソースの場所はゾーンとして表示されますZone Preferenceを使用すると 、指定したロジックに基づいてリソースロケーション間のフェイルオーバーを管理できます。従来導入された CVAD サイト内で Zone Preference を使用すると、高可用性設計と見なされますが、有効な DR 設計とは見なされません。Citrix Cloudでは、このオプションは有効なDRソリューションです。

前述のディザスタリカバリオプションのほとんどはCitrix DaaSに適用されるため、組織のリカバリ目標と予算に合わせた多数のオプションがあります。

Citrix CloudのCitrix DaaSサービスのDRを計画する際には、インフラストラクチャ計画の観点からいくつかの主要な指針となる原則を理解する必要があります。

  • リソースの場所。本番環境とDRの場所は、Citrix Cloudで独立したリソースの場所として設定されます。
  • Cloud Connector。各リソースの場所には、少なくとも 2 つのCloud Connectorを展開する必要があります。明確にするために、Cloud Connectorは、DRイベント中に手動または自動で「リカバリ」する必要があるコンポーネントではありません。これらは「ホットスタンバイ」コンポーネントとみなされ、各ロケーション内でオンライン状態に保たれる必要があります。
  • カスタマー管理型Access Controller(オプション)。お客様は、Citrix GatewayおよびStoreFront サーバー用に独自のCitrix ADCを展開し、Citrix WorkspaceまたはCitrix Gatewayサービスを使用しないことを選択できます。これには、次のものが含まれます。
    • カスタム認証フロー
    • ブランディング機能の向上
    • HDXトラフィックルーティングの柔軟性が向上
    • ICA接続の監査と SIEM プラットフォームへの統合
    • StoreFrontでCloud Connectorのローカルホストキャッシュ機能を使用して、Citrix Cloud へのCloud Connectorの接続が切断された場合でも動作を継続する機能

    Cloud Connectorと同様に、StoreFront およびCitrix Gatewayコンポーネントをリカバリ場所に「ホットスタンバイ」として展開し、DRイベント中はリカバリしないことをお勧めします。

操作に関する考慮事項

DR プラットフォームを維持することは、プラットフォームが必要なときに予期せぬ問題を回避するために、その整合性を維持するために不可欠です。DR Citrix環境の運用と保守については、次のガイドラインをお勧めします。

  • Citrix DRプラットフォームは非製品ではありません。「ホットスタンバイ」環境をお持ちのお客様は、コーナーをカットし、DRをテストプラットフォームとして扱うことができます。この処理は、溶液の完全性に悪影響を及ぼします。実際、DRは、非本番環境では展示されていない方法でメンテナンスが壊滅的に間違っている場合でも、そのユーティリティに影響を与えないように、変更を促進する最後のプラットフォームになる可能性があります。
  • パッチ適用とメンテナンス「ホットスタンバイ」Citrixプラットフォームを使用する場合、運用環境とのロックステップでの定期的なメンテナンスは、DRプラットフォームの機能を維持するために不可欠です。OS、Citrix 製品、アプリケーションパッチに関して、DRを実稼働環境と同期させることが重要です。リスクを軽減するために、本番環境のパッチ適用からDRへのパッチ適用までの間に数日から1週間かかることが推奨されます。
  • 定期的なテスト。DRに本番環境のリカバリ施設へのレプリケーションや「ホット・スタンバイ」環境の使用に関わらず、リカバリ・プロセスを熟知し、プラットフォームやワークフローに欠陥があることを確認するために、災害復旧計画を定期的にテスト(年2回以上が理想的)することが重要です。特定され、修正されました。
  • キャパシティ管理。アクティブ-パッシブとアクティブ-アクティブの「常にオン」のCitrix環境の両方で、本番環境における容量またはユースケースの変更もDRについても考慮する必要があります。特に Active-Active モデルを使用すると、リソース使用率が、各環境でリソースの定常状態使用率しきい値が 50% 増加するのは簡単です。これは、DR イベントが発生し、存続しているプラットフォームが過負荷になり、パフォーマンスの低下または障害が発生した場合に限られます。過負荷。容量は、毎月または四半期ごとにレビューできます。

概要

Citrixのディザスタリカバリに関する話題については、かなりの根拠を取り上げました。Citrixリカバリ戦略を計画する際に考慮すべきアーキテクトとお客様向けの、このガイドの主なメッセージと要点を以下に示します。

  • お客様の環境のビジネス要件と技術力を理解することは、Citrix に必要なディザスタリカバリ戦略に影響を与えます。選択したリカバリ戦略は、ビジネス目標に合わせて調整できます。
  • 高可用性は、ディザスタリカバリと同義ではありません。ただし、ディザスタリカバリには高可用性を含めることができます。
  • 物理的な場所間で管理上の境界を共有しても、ディザスタリカバリソリューションにはなりません。
  • 組織のテクノロジーポートフォリオのディザスタリカバリ階層化分類を作成すると、リカバリ戦略を策定する際に、可視性、柔軟性、および潜在的なコスト削減が可能になります。
  • CitrixインフラストラクチャまたはCitrix上でホストされているアプリケーションのRTO(目標復旧時間)要件は、ディザスタリカバリ設計が必要となる最も重要な影響要因です。RTO を短くすると、多くの場合、ソリューションコストが高くなります。
  • 「ホット」ディザスタリカバリプラットフォームを採用していないCitrixの災害復旧アーキテクチャでは、Citrix MCS、ADC、プロビジョニングなど、お客様が使用できるテクノロジに制限があります。
  • Citrixのディザスタリカバリ戦略では、ユーザーデータとアプリケーションバックエンドのリカバリ時間とリカバリ時間も考慮する必要があります。Citrixは迅速にリカバリできるように設計できますが、アプリケーションとデータの依存関係が同様の時間内に利用できないと、ユーザーは作業できなくなります。
  • クラウド環境でのディザスタリカバリには、オンプレミス環境には存在しない独自の考慮事項があります。組織では、クラウド環境でディザスタリカバリを呼び出すときに、予期しないボトルネックや運用上の影響を回避するために検討する必要があります。
  • プラットフォームの整合性を維持するために、災害復旧コンポーネントを本番環境の更新と構成に合わせて最新の状態に保つことが不可欠です。
  • サイト間でCitrixのアクティブ/アクティブ構成を使用するプラットフォームでは、障害が発生した場合に、1つ以上の正常な場所で予測される負荷をサポートするのに十分なリソースを確保するために、容量の監視に十分対応する必要があります。
  • お客様は、Citrixの障害復旧計画を定期的にテストして、その運用とコア目的に応える能力を検証する必要があります。
  • Citrix DaaSは、DRアーキテクチャの多くの側面を大幅に簡素化し、ゾーン設定構成を介してリソースの場所の冗長性を可能にします。

ソース

この記事の目的は、独自の実装計画を支援することです。この作業を簡単にするために、お客様のニーズに合わせて調整できるソース図を提供します。 ソース図です

設計上の決定:ディザスタリカバリ計画

この記事の概要