コンテナーの障害回復
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
障害回復によって、組織は、手動介入が必要な障害が発生した後、ミッション クリティカルな機能を維持したり、迅速に再開したりできます。Sitecore 障害回復 (DR) サービスは、DR Basic (確認) と DR Managed (自動) の 2 つの DR サービス タイプを提供します。これらはさらに、コールド スタンバイ (最小限のインフラストラクチャ) とホット スタンバイ (フル レプリカ) の 2 つのインフラストラクチャ タイプに分けられます。
-
DR Basic コールド スタンバイ: リアクティブ サービス。回復およびフェールオーバー プロセスは、イベント後に開始され、顧客からの確認が必要です。これは費用対効果の高いサービス オプションですが、目標復旧時間 (RTO) が長くなります。Basic コールド スタンバイ DR サービス タイプは、必要最小限のインフラストラクチャをプロビジョニングし、多くの場合、非クリティカル アプリケーションや、データが頻繁には変更されない状況で使用されます。
Basic コールド スタンバイ障害回復には、geo レプリケーションが含まれます。障害が発生した場合、セカンダリ リージョンとデータベースへのフェールオーバーが最小限のダウンタイムで行われます。
-
DR Managed ホット スタンバイ: プロアクティブ サービス。フェールバックおよびフェールオーバー プロセスは自動的に開始し、プライマリ サイトの全体的レプリカをぷびじょニングします。これにより、RTO 間隔が最短になります。
環境に最適な回復オプションは、フェールオーバーの開始がプロアクティブであるか、リアクティブであるか、また、停止が発生したときにどれだけ迅速にオンラインに復帰する必要があるかによって異なります。
コンテナーの障害回復の詳細については、ナレッジ ベースの記事「 Sitecore Managed Cloud Standard - コンテナーの障害回復」を参照してください。
Infrastructure as Code
Managed Cloud Containers 環境は、Infrastructure as Code (IaC) を使用します。ここでは、プロビジョニング アーティファクトは Git リポジトリに保存され、GitOps ベスト プラクティスに従います。障害回復も、これらのベスト プラクティスに従います。
コンテナー インフラストラクチャの詳細については、「Managed Cloud アーキテクチャ」と「Managed Cloud でのデプロイ」を参照してください。
回復オプションに関する考慮事項
どの回復オプションが要件に最も適しているかを判断するには、次の表を参考にして検討してください。
-
停止が発生した場合、サイトがどれだけ早くオンラインに復帰する必要があるか。
-
目標復旧時点 (RPO)。
-
目標復旧時間 (RTO)。
|
仕様 |
DR Basic コールド スタンバイ |
DR Managed ホット スタンバイ |
|---|---|---|
|
バックアップ テクノロジー |
geo レプリケーション (ACR、SQL Server、KeyVault、Blob Storage) Azure API |
geo レプリケーション (ACR、SQL Server、KeyVault、Blob Storage) Azure API |
|
回復プロセス |
|
|
|
セカンダリ環境状態 |
オンデマンドで作成 |
稼働中のプライマリ環境の正確なレプリカが完全にデプロイされている |
|
目標復旧時点 (RPO) |
SQL 5 秒 アプリケーションは ACR のイメージに依存しているため、RPO は ACR で使用可能な最新のイメージに基づきます。 |
SQL 5 秒 アプリケーションは ACR のイメージに依存しているため、RPO は ACR で使用可能な最新のイメージに基づきます。 |
|
目標復旧時間 (RTO) - テクノロジーのみ |
手動フェールオーバーの実行には約 90 分かかり、セカンダリ Sitecore プロビジョニング、AFD トラフィック スイッチング、および SQL スイッチオーバーを含みます。 |
手動フェールオーバーの実行には約 10 分かかり、AFD トラフィック スイッチングと SQL スイッチオーバーを含みます。 |
|
フェールバック時間 - テクノロジーのみ |
手動フェールオーバーの実行には約 15 分かかり、AFD トラフィック スイッチングと SQL スイッチオーバーを含みます。 |
自動フェールオーバーの実行には約 10 分かかり、AFD トラフィック スイッチングと SQL スイッチオーバーを含みます。 |
テクノロジーの RTO 値は、システムが Sitecore プラットホームの回復にかかる時間によって異なります。顧客またはパートナーが関与する手動ステップが必要な場合、実効 RTO が延長される可能性があります。
リージョン間のレプリケーション
典型的な Sitecore 環境は、次の Azure リソース タイプで構成されます。
-
KeyVault - Azure は、セカンダリ環境に読み取り専用のレプリケーションを提供し、これにより、セカンダリ環境での Sitecore の継続運用を可能にします。
-
ストレージ アカウント - ストレージ アカウントで提供されるオブジェクト レプリケーションは、ストレージ アカウント コンテナーをセカンダリ環境に選択的に複製するために使用されます。
-
ACR – ACR とそのイメージは、terraform を使用してプロビジョニングされます。Gitのインフラストラクチャ コードには最新のターゲット状態が含まれ、セカンダリ状態のプロビジョニングまたは維持に使用されます。
-
AKS – AKS は、terraform を使用してプロビジョニングされます。Git のインフラストラクチャ コードには最新のターゲット状態が含まれ、セカンダリ状態のプロビジョニングまたは維持に使用されます。
-
Azure SQL – Azure が提供する geo レプリケーションにより、データの複製が保証されます。