Citrix Virtual Apps and Desktops-ディザスタリカバリ計画

寄稿者

著者: Michael Shuster

謝辞:

Kevin Nardone Martin Zugec

概要

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

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

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

ビジネス要件

Citrix の設計方法論の「ビジネスレイヤー」に合わせて、明確なビジネス要件とサービスのリカバリに関する既知の制約を収集することは、Citrixのリカバリ計画策定における出発点となるはずです。これにより、対象範囲を明確にし、ビジネス要件と機能要件、および制約を満たすのに最も適した DR 戦略の方向性を提供できます。

回答したうえで役に立つ質問には、以下が含まれますが、これらに限定されません。これらの項目については、Citrix DR設計にどのような影響を与えるかという点で、ディザスタリカバリオプションセクションで詳しく説明します。

  • **バックアップ戦略とRTO(目標復旧時間) **現在サーバに使用されているバックアップ戦略はどれですか。バックアップ頻度? 保存期間オフサイト・ストレージテスト済みですか?災害が発生した場合や特定の期間内にオンライン状態になった場合、Citrix は直ちに利用可能にする必要がありますか。(「災害復旧階層の分類」を参照)。Citrixがホストするアプリケーションが接続するアプリケーションバックエンドをディスカッションに含めることは価値があります。
  • RPO(目標復旧時点)。 RPO(目標復旧時点)の場合、DRで許容できるデータ損失の程度はどれくらいですか。これは、インフラストラクチャ・コンポーネントまたはデータの分類によって異なります。サービスで復旧したデータの古さはどれくらいですか。 0分ですか?1時間?一ヶ月?Citrix インフラストラクチャのコンテキスト内では、データベースの変更とユーザーデータ(プロファイル、フォルダのリダイレクトなど)にのみ適用されます。 RTOと同様に、Citrixがホストするアプリケーションのバックエンドを議論に検討する価値があります。
  • リカバリの範囲。 これには、Citrix インフラストラクチャだけは含まれませんが、Citrixがホストするアプリケーションクライアントがインターフェースするユーザーデータまたは主要なアプリケーションサーバーを含めることができます。Citrixをリカバリする時間と、Citrix でホストされているアプリケーションをリカバリする時間との間に差異があるかどうかを識別することが重要です。これにより、ソリューションの一部だけがオンラインになるため、システム停止が長くなる可能性があります。
  • ユースケース。 Citrix プラットフォームは、多くの場合、ビジネスの重要度が異なる多数のユースケースに対応します。リカバリはすべてのCitrix のユースケースに対応していますか?または、ビジネスの運用の成功が完全に依存する重要なユースケースだけです。これは、インフラストラクチャのスコープとキャパシティ予測に大きな影響を与えます。使用事例のセグメンテーションと優先順位付けは、それがCitrix 環境の純新機能である場合、DRの有効化を区分化するために推奨されます。
  • 機能。 コストを削減できる DR に含める必要のない主要な機能はありますか。たとえば、永続的なデスクトップと非永続的なデスクトップの使用や、ホストされた共有デスクトップによって提供される一部の VDI ユースケースや、特定のアプリケーションのソロもあります。お客様は、コンポーネントの冗長性(ADC、コントローラ、StoreFront、SQLなど)がDRで必要ではないと判断されたことがあります。これは、本番環境の停止が長期間続く場合は、リスクと見なす必要があります。
  • 既存の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ワークロードを処理できないため、最終的に停止する可能性があります。また、コンピューティングの場合、ハイパーバイザーホストのサイズが小さすぎる場合や、異なるHypervisor の使用がオプションに完全に影響する可能性があります。ネットワークに関しては、リカバリサイトのネットワークスループット能力が、WANにサービスを提供する際に本番環境よりも制約が強くなった場合。クラウド環境では、特に数千のシートに拡張する場合、仮想ファイアウォール、VPN ゲートウェイ、クラウドから WAN へのアップリンク(AWS Direct Connect、Azure ExpressRoute、Google Cloud Interconnect など)などのコンポーネントサービスの制限により、この処理が急速に大きなボトルネックになる可能性があります。
  • 予算。 DR ソリューションには、プロジェクト予算と競合するコストが付属しています。多くの場合、RTOが短ければ短いほど、コストは高くなります。
  • 地理。 指定された DR ファシリティが特定された場合は、本番環境から DR ファシリティへの遅延や、DR に接続するユーザなどの考慮事項を理解する必要があります。
  • データの常駐またはデータのクラス分け。 これは、ロケールとテクノロジまたは回復方法の観点から、オプションが制限される場合があります。
  • クラウドリカバリ。 インフラストラクチャをクラウドとオンプレミスの施設でリカバリする義務はありますか。
  • アプリケーションの準備状況。 バックエンドに依存するCitrix 上でホストされているアプリケーションにはBC/DRプランがあり、RTOはCitrixのターゲットRTOにどのように対応していますか。Citrix は高速リカバリ用に設計できますが、コアアプリケーションにリカバリ計画がない場合や、RTOが拡張されていない場合は、DRのCitrix プラットフォームの有用性に影響を与える可能性があります。
  • ネットワークセキュリティ。 組織には、転送中に暗号化が必要なトラフィックセグメントを決定するセキュリティポリシーがありますか。これは、通過するネットワークリンクによって異なりますか。これは、DRのネットワークフローが本番環境と異なる場合、DRシナリオでICAトラフィックのSSL VDA、ICAプロキシ、GRE、またはIPsec VPNカプセル化を使用する必要がある場合があります。

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

Citrix DR 設計における最も一般的な誤解の 1 つは、この記事では、2 つのデータセンターにまたがる単一のコントロールプレーンが DR を構成しているという概念です。そうではありません。データセンターにまたがる単一のCitrix サイトまたはPVSファームは、近接しているデータセンターであっても、高可用性設計を構成しますが、DR設計ではありません。一部のお客様は、DR機能よりもシンプルな管理を重視するビジネス上の意思決定として、このパスを選択します。StoreFront サーバーグループをまたがるのは、正しく接続されたデータセンター間サポートされていますだけです。

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

障害回復

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

障害回復

別の一般的な誤解は、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を持つリカバリプランがない場合、またはリカバリプランがまったくない場合は、CitrixがDRで正常にフェイルオーバーする効果がありますが、これらの依存関係は使用できないままであるためユーザーはジョブ機能を実行できません。例えば、Citrix 上でコアEMRアプリケーションをホストする病院を例にしましょう。DRイベントが発生し、Citrix がDRの「常時オン」Citrixプラットフォームにフェイルオーバーし、ユーザーは接続していますが、EMRアプリケーションは、完了までに数時間または数日かかる場合があり、より手作業でリカバリされます。この間、臨床スタッフはオフラインプロセス(ペンと紙)の使用を余儀なくされるでしょう。これは、リカバリ時間やユーザーエクスペリエンスに対するビジネス全体の期待とは一致しない場合があります。

次のセクションでは、DR vs. HA について詳しく説明します。

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

HA vs. DRは、組織のニーズに合わせて、リカバリ目標を達成するために不可欠です。HA は DR と同義ではありませんが、DR は HA を活用できます。このマニュアルでは、HA と DR を次のように解釈します。

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

HA は設計仕様とソリューションの導入に組み込められる傾向がありますが、DR は、サービスのリカバリを開始するための人員とインフラストラクチャリソースのオーケストレーションプランニングに大きく関わっています。

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

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

Citrixのコンテキストでは、公開されたガイダンスのような2つの地理的ローカライズ施設などの2つのデータセンター間のようにCitrix管理ドメイン(Citrixサイト、PVSファームなど)にまたがる場合、DRを構成せず、StoreFront サーバーグループなどの一部のコンポーネントはサポートされません。コンポーネントはデータベースなどの依存関係を共有するため、いくつかの主要な障害シナリオから保護されません。データベースが破損すると、障害ドメインは両方の施設のアプリケーションサービスに影響を与えます。HA Citrix ソリューションを DR に十分であると考えるには、2 番目のファシリティが重要な依存関係や管理上の境界を共有しないことをお勧めします。たとえば、ソリューション内の各データセンターに対して、個別のサイト、ファーム、サーバーグループを作成します。

災害復旧階層の分類

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

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

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

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

目標リカバリ時間:0

目標復旧時点:0

階層 0-分類の例

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

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

コアITサービス

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

階層 0-メモ

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

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

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

目標復旧時間:4時間

目標復旧時点:15分

階層 1:分類の例

重要なアプリケーション

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

Citrix のユースケース

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

階層 1-ノート

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

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

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

目標復旧時間:48 時間

目標復旧時点:1 時間

階層 2:分類の例

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

階層 2-ノート

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

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

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

目標復旧時間:5 日間

目標復旧時点:8時間

階層3:クラス分けの例

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

階層 3-ノート

システム停止への影響はごくわずかですが、最大1週間は利用できない場合です。 これらのアプリケーションは、多くの場合、バックアップからリカバリされます。

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

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

目標復旧時間:30 日

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

階層4:クラス分けの例

非本番環境

階層4-ノート

停止しても業務にほとんど影響を及ぼさず、長期間にわたってリストアできるアプリケーション、インフラストラクチャ、VDI。 また、RPO(目標復旧時点)が拡張されている場合もあれば、その性質によってはまったく拡張されていない場合もあります。これらは、バックアップからリカバリすることも、DRで新たに構築することもでき、リカバリされる最後の階層とみなされます。

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

Citrix では、階層分類が重要な理由は次のとおりです。

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

最初の質問は、ミッションクリティカルなアプリケーションやデスクトップの提供により、多くの企業Citrix 展開は階層0に分類される傾向があります。これは、ネットワーク、Active Directory、DNS、およびHypervisor インフラストラクチャとは異なり、「常時オン」の階層です。ただし、すべてのCitrix のユースケースでは必ずしもそうとは限りません。一部のCitrixユースケースがTier 1以上に該当する場合、すべてのCitrixユースケースを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を構成することはありません(データセンターにまたがるサイトやサテライトゾーンを使用するなど)。ビジネスがCitrixのDRプラットフォームを予想している場合には、その義務に反します。
  • リカバリの範囲。 Citrix がDRのホットスタンバイ(常時オン)の容量で導入されているが、コアビジネスアプリケーションのバックエンドがリカバリに8時間かかる場合、自動アクセス階層フェイルオーバーを採用するのは意味がありません。アクセス層の手動フェイルオーバーの方が適切な場合があります。
  • ユースケース。 ミッションクリティカルなワークロードまたはコアアプリケーションのみをCitrix で迅速にリカバリし、DRシナリオで業務運用を維持する必要がある場合、容量の観点からDRコストを削減できる可能性があります。優先順位が異なる複数のユースケースでリカバリが必要な場合、ユースケースごとの重要性の分類は、リカバリ階層化戦略先ほど説明したごとのビジネスへの影響とは対照的に、容量コストを削減することはできませんが、は、ITスタッフに、より集中したリカバリ優先順位の順序を提供します。
  • 機能。 HDX Insight、Session Recordingなどの特定のコンポーネントがDRプラットフォームの操作に重要ではないと判断された場合、DR環境でこれらのコンポーネントを省略すると、複雑さとメンテナンスのオーバーヘッドが軽減されます。同様に、DRシナリオの多くのユースケースがDRのよりシンプルで汎用的なCitrix 配信オプションに当てはまる場合、複雑さとコストも軽減されます。たとえば、技術的に実現可能な場合は、プールされた VDI の代わりにホストされた共有デスクトップを使用したり、ビジネス運営に悪影響を及ぼさない限り、より多くのユースケースを 1 つに集約したりします。
  • 既存のDR。たとえば、組織の既存のDR戦略が、データレプリケーションおよびオーケストレーションツールを使用してCitrix やその他のアプリケーションインフラストラクチャを回復する場合、ほとんどのCitrixコンポーネントがこのモデルに適している可能性があります。ただし、プラットフォームのサイズと単一イメージ管理テクノロジーへの依存が本番プラットフォームの要件である場合、多くの場合、このようなテクノロジーは適切ではない可能性があります。ホットスタンバイCitrix プラットフォームのハイブリッドアプローチと、マスターイメージのレプリケーションの方が適切です。
  • データの重要度。 DRでのリカバリにプロファイルが重要であると判断された場合は、適切なレプリケーション・テクノロジーが必要になることがあります。多くの組織は、DR シナリオのプロファイルにはあまり関心がなく、新しいプロファイルを作成することを認めています。この考慮事項は、Citrix でアクセスされるユーザーデータ(フォルダーリダイレクト、マップされたドライブ)にも適用されます。このデータのRPOおよびRTOは、ビジネス上の決定である可能性があります。さらに、多くの永続的なVDiがDRにそのまま保持できるほど重要であると判断された場合(ユーザーがソフトウェアを再インストールする必要がある場合など)、これらのVMをレプリケーション用に検討する必要があり、リカバリをサポートするために余分なコストが発生する可能性があります。
  • 災害の種類。 お客様がどの程度障害に対する保護を希望しているかによって、アーキテクチャ上のさまざまな変更が生じる可能性があります。お客様がデータセンターまたはクラウドリージョン内のCitrix インフラストラクチャのHAのみを希望する場合、管理コンポーネントが冗長であり、反対側のインフラストラクチャで動作していることを確認するだけで済みます。たとえば、StoreFront サーバーペアは、VMwareの非アフィニティルールを利用して、クラスタ内の異なるホスト、またはデータセンター内の異なるクラスタ上、または異なる可用性セットの一部として動作します。この場合、冗長なコントロールプレーン(複数のCitrix サイトやStoreFront サーバーグループなど)を作成する必要はほとんどありません。ただし、DRが地域に関係なく複数のデータセンターを対象としている場合は、各データセンター(AD、DNS、SQL、Hypervisor など)のローカル依存関係を活用した冗長制御プレーンが適しています。お客様がグローバルで、Citrix にサービスを提供するために複数のデータセンターを雇用している(または計画している)場合、各アプリケーションバックエンドがこれらのデータセンターに対してローカルに展開されている Active-Active HA-DR アーキテクチャの方が適切である可能性が高くなります。これにより、地理的にローカライズされたCitrix インフラストラクチャを使用することにより、可能な限り最適なユーザーエクスペリエンスをユーザーに提供します。このインフラストラクチャは、必要に応じてセカンダリ優先順位でバックアップデータセンターにフェイルオーバーできます。
  • クライアントユーザー。 上記のユーザー、アプリ、データのローカリゼーションに関する考慮事項の他に、一部のクライアントユーザーネットワークは、インターネットやWANへの送信通信を制限するセキュリティデバイス(プロキシ、ファイアウォールなど)で比較的ロックダウンされることがあります。これがクライアントネットワークに適用されるかどうかを考慮し、ローカルLANのセキュリティ制限によるリカバリの遅延がさらに発生しないように、Citrixサービスの新しいIP(StoreFront VIPおよびVDA IP、Citrix Gateway IPなど)をローカルセキュリティ構成で考慮することが重要です。DRの呼び出し時。準備の観点から、DRが発生した場合、クライアントのアクセスは何らかの方法で変更する必要がありますか。DRシナリオによっては、WANが使用できなくなり、すべてのユーザーがインターネット経由でCitrix リソースにアクセスする必要があると想定している場合があります。このような手順では、BCおよび準備計画に文書化する必要があります。また、エンドユーザー向けの前提条件(サポートされるCitrix クライアントの詳細情報、企業またはBYODデバイスへのアクセスに関する前提条件)が設けられ、ユーザーがサービスに戻る際の障壁を取り除き、サポートデスクの負担をさらに軽減します。
  • ネットワーク帯域幅。 VDAトラフィック(ICA、アプリケーション、ファイルサービス)で使用されるネットワーク帯域幅は、DR施設のネットワークサイジングとファイアウォールを考慮する必要があります。これは、VPN ゲートウェイと仮想ファイアウォールの容量に制限があるクラウド環境で特に重要です。VDAからの本番トラフィックを監視してサイジングの平均値を決定することは、ネットワーキングを効果的にサイジングするために重要です。ネットワークの制約が存在する場合、組織は起動時に予想される DR トラフィック負荷に対応するために、異なるネットワーク構成を使用する必要がある場合があります。Citrix SD-WANのWAN最適化テクノロジーは、トラフィックの需要を軽減するのに役立ちます。
  • フォールバック(またはフェイルバック)。 DRでユーザーデータが変更された場合、または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を考慮する必要があります。
  • ネットワークが原因でCitrix VPX ADCには一般的に適さないため、ホットスタンバイADCの採用に適しています

ユースケースと前提条件

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

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

障害回復

長所と短所

長所:

  • ホット・スタンバイ・ソリューションと比較してメンテナンス・コストを削減
  • レプリケーションは自動化され、RTOとRPO(目標復旧時点)に合わせて調整
  • リカバリ計画は自動化される傾向がある
  • 管理上の介入と人為的ミスの低減

短所:

  • VMware SRM、Veeam、Zerto、ASRなどの高度なテクノロジーを使用して、リカバリを調整し、ネットワーク・パラメータを変更します。
  • 通常、MCSまたはPVSには適していません。マシンカタログの再作成は、予測されるRTOを考慮する必要があります。
  • ネットワークが原因でCitrix VPX ADCには一般的に適さないため、ホットスタンバイADCの採用に適しています

ユースケースと前提条件

DR 施設に適切なリソースと予算がある企業組織に便利です。 このソリューションは、以前のオプションと同じストレージレプリケーションに依存していますが、特定の順序でVMをリカバリしたり、必要に応じてNIC構成を調整したりするDRオーケストレーションテクノロジーが含まれています。

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

障害回復

長所と短所

長所:

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

短所:

  • URLをフェイルオーバーするか、URLをバックアップするようにユーザーを指示する管理者の介入に依存する
  • DR の「ホット」ハードウェアをスタンバイ状態にするため、コストが高い
  • スタンバイ・プラットフォームの構成と更新を本番環境と同期させるための管理オーバーヘッドの増加

ユースケースと前提条件

DR 施設に適切なリソースと予算がある企業組織に便利です。ホットスタンバイの「フルスケーリング」プラットフォームまたは「オンデマンドスケーリング」プラットフォームを活用できます。後者は、運用コストを削減するためにクラウドリカバリに魅力的かもしれません。制限事項

フェイルオーバー管理者は、Citrix Gateway およびStoreFront のDR IPを指すようにアクセスURLのDNSエントリを更新するか、「バックアップ」URLまたは「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容量の整合性に影響を与えないよう管理者に頼る

ユースケースと前提条件

企業の顧客とのより高度ではあるが一般的な構成であり、Citrix ADC GSLB(ADC Advanced以上が必要)を介してアクセス層のURLをアクティブ-アクティブ方式で動作させることができます。これは、ローカルなデータセンターが互いに近接している環境や、データセンターがリモートにあるが、複数サイトのシナリオでユーザーを優先するデータセンター(多くの場合、高度なStoreFront 構成とGSLBによって駆動される)にピン留めする手段がある場合に便利です。

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

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

オンプレミスからクラウドへのプラットフォームまたはクラウドからクラウドへの移行を伴うディザスタリカバリには、オンプレミスのリカバリシナリオには含まれない独自の課題や考慮事項があります。

DR設計計画では、クラウドインフラストラクチャを活用してDR計画が無効になるか、コストがかかるか、DRが発生した場合にターゲット容量を満たすことができないという誤ったステップを回避するために、次の重要な考慮事項に対処する必要があります。

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

影響領域

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

詳細

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

推奨事項

スループットのサイジング計算を確立するときは、DR キャパシティの負荷がいっぱいであると仮定します。同時ユーザーごとに次のデータを取得します。

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

上記のメトリックでは、本番環境のVDAとの間で現在のトラフィックパターンに関するデータを収集すると便利です。また、Citrix と関係のない他のデータフローも、これらのネットワークパスを使用していると予想されるものについて検討することも重要です。Citrix DRの計画には、ネットワークチームとセキュリティチームと協力して、セキュリティゾーンとネットワークセグメントを通過する帯域幅の見積もりを理解し、対応できるようにしてください。帯域幅が大きい場合、Citrix SD-WAN Optimizationは、ワイヤ上のセッションフットプリントを削減したり、複数のネットワーク接続で帯域幅を集約したりするのに役立ちます。

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

影響領域

コスト

詳細

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

推奨事項

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

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

影響領域

コスト 可用性

詳細

お客様は、必要なときにのみ容量を支払うという魅力によって、クラウドに引き寄せられます。これにより、使用の有無にかかわらず、リザーブドインフラストラクチャに料金を支払うことなく、DR コストを大幅に削減できます。

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

意思決定に影響を与える可能性がある答えなければならない主な質問:

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

推奨事項

RTO期間内に予想される容量をパワーオンできるかどうか、およびオンデマンドインスタンスで満たすことができるかどうかを判断するために、まずクラウドプロバイダと連携することをお勧めします。

DRシナリオでVDAの容量可用性の制限を回避するには、できるだけ多くのアベイラビリティーゾーンでVDAをプロビジョニングすることをお勧めします。大規模な場合は、さまざまなクラウドリージョンにまたがってProvisioning し、それに応じてアーキテクチャを調整する価値があるかもしれません。一部のクラウドプロバイダーでは、VM の枯渇をさらに軽減するために、さまざまなサイズの VM インスタンスタイプを採用することを提案しています。

可能な場合は、VDAインスタンスを事前にプロビジョニングし、オフラインにしておき、定期的に更新することをお勧めします。プロビジョニングはリソースと時間集約型のプロセスであり、VDA DR容量をオンデマンドでスケールアウトするには、事前プロビジョニングによって段階的に迅速化できます。

キャパシティの可用性リスクに対するニーズがほとんどない場合は、リソースの可用性を保証するために、予約済みまたは専用のコンピュートキャパシティを活用し、それに応じて予算編成が必要になる場合があります。

DRリカバリ階層を参照することで、オンデマンドモデルと予約専用モデルを組み合わせることができます。この階層では、特定のユースケースではVDAをすぐに使用できるようにする必要がありますが、他のモデルでは、より長いRTOを数日間または数週間でリカバリできる柔軟性があります。ビジネス。

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

影響領域

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

詳細

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

推奨事項

可能な場合は、アプリケーションおよびユーザーデータをDRでCitrix プラットフォームに対してローカルに保ち、WAN全体の待ち時間と帯域幅の要求を減らすことにより、可能な限り最適なパフォーマンスを維持します。

操作に関する考慮事項

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

  • Citrix DRプラットフォームは非製品ではありません。 「ホットスタンバイ」環境のお客様には、コーナーが切断され、DR をテストプラットフォームとして扱うことが考えられます。これは、ソリューションの整合性に悪影響を及ぼします。実際に、保守が非本番環境では見られない方法で壊滅的に間違っていた場合に、そのユーティリティが影響を受けないようにするため、DR は変更を推進する最後のプラットフォームになる可能性があります。
  • パッチ適用とメンテナンス。 「ホットスタンバイ」Citrix プラットフォームを使用する場合、本番環境でのロックステップでの定期的なメンテナンスは、機能的なDRプラットフォームを維持するために不可欠です。OS、Citrix 製品、アプリケーションパッチに関して、DRを本番環境と同期させることが重要です。リスクを軽減するために、パッチ適用とパッチ適用DRの間に数日~1週間かかることを提案します。
  • 定期的なテスト。 DRがリカバリ施設への本番レプリケーションか、「ホットスタンバイ」環境の使用に関係するかにかかわらず、DR計画を定期的にテスト(年に2回以上が理想的)して、リカバリプロセスやプラットフォームの欠陥に精通していることを確認することが重要です。ワークフローが特定され、修正されます。
  • キャパシティ管理。 アクティブ-パッシブおよびアクティブ-アクティブの「常時オン」Citrix 環境の両方に当てはまる場合、DRについても本番環境の容量またはユースケースの変更を考慮する必要があります。特に、Active-Active モデルを使用する場合、リソース使用率は、各環境におけるリソースの 50% 定常状態使用率のしきい値を超えて容易に増加し、DR イベントが発生し、存続するプラットフォームが圧倒され、過負荷。容量は毎月または四半期ごとに確認する必要があります。

概要

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

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

ソース

この記事の目的は、独自の実装計画を支援することです。この作業を容易にするために、独自のニーズに適応できるソース図を提供します:ソース図