1. ディザスタリカバリ

コンテナのディザスタリカバリ

Version:
日本語翻訳に関する免責事項

このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。

ディザスタリカバリにより、組織は、手動による介入が必要な災害後にミッションクリティカルな機能を維持または迅速に再開できます。Sitecoreディザスタ リカバリ (DR) サービスには、DRベーシック (確認) とDRマネージド (自動) の2つのDRサービス タイプがあります。これらには、コールドスタンバイ(最小インフラストラクチャ)とホットスタンバイ(フルレプリカ)の2つのインフラストラクチャタイプがあります。

  • DR Basic Cold Standby: リアクティブ サービス。復旧とフェイルオーバーのプロセスはイベント後に開始され、お客様からの確認が必要です。これは、目標復旧時間(RTO)が長い費用対効果の高いサービスオプションです。Basic Cold Standby DRサービス・タイプは、必要最小限のインフラストラクチャをプロビジョニングし、重要でないアプリケーションや、データの変更頻度が低い状況でよく使用されます。

    基本的なコールド スタンバイのディザスター リカバリーには、geoレプリケーションが含まれます。障害が発生した場合、セカンダリ リージョンとデータベースへのフェールオーバーは最小限のダウンタイムで行われます。

  • DR Managed Hot Standby: プロアクティブなサービス。フェールバックとフェールオーバーのプロセスは自動的に開始され、プライマリ サイトのレプリカ全体がプロビジョニングされます。これにより、RTO間隔が最短になります。

ご使用の環境に最適な復旧オプションは、フェイルオーバーの開始をプロアクティブにする必要があるか、リアクティブにする必要があるか、および障害が発生したときにどれだけ迅速にオンラインに戻るかによって異なります。

コンテナのディザスタ リカバリの詳細については、Sitecore Managed Cloud Standard - コンテナ ディザスタ リカバリ ナレッジベースの記事を参照してください。

Infrastructure as Code

Managed Cloud Containers環境では、プロビジョニング成果物がGitリポジトリに格納され、GitOpsのベスト プラクティスに従っているInfrastructure as Code (IaC) を使用します。ディザスタリカバリもこれらのプラクティスに従います。

コンテナインフラストラクチャの詳細については、Managed Cloudのアーキテクチャ とManaged Cloudでのデプロイを参照してください。

リカバリー・オプションに関する考慮事項

要件に一致するリカバリ オプションを決定するには、次の表を参考にして、次の点を考慮してください。

  • 停止が発生した場合にサイトをオンラインに戻す必要がある速度。

  • 目標復旧時点 (RPO)。

  • 目標復旧時間 (RTO)。

仕様

DRベーシックコールドスタンバイ

DR管理ホットスタンバイ

バックアップ技術

geoレプリケーション (ACR、SQL Server、KeyVault、Blob Storage)

Azure API

geoレプリケーション (ACR、SQL Server、KeyVault、Blob Storage)

Azure API

回復プロセス

  1. フェイルオーバーに関するお客様の要求/承認

  2. 展開

  3. スイッチオーバー

  4. ライブ配信開始

  5. お客様の検証

  1. スイッチオーバー

  2. ライブ配信開始

  3. お客様の検証

セカンダリ環境の状態

オンデマンドで作成

完全にデプロイされたプライマリ環境の正確なレプリカが稼働している

目標復旧時点 (RPO)

SQL 5秒

アプリケーションはACRのイメージに依存するため、RPOはACRで使用可能な最新のイメージに基づいています。

SQL 5秒

アプリケーションはACRのイメージに依存するため、RPOはACRで使用可能な最新のイメージに基づいています。

目標復旧時間(RTO) - テクノロジーのみ

手動フェイルオーバーの実行にはapproximately 90 minutesかかり、セカンダリSitecoreプロビジョニング、AFDトラフィック スイッチング、SQLスイッチオーバーが含まれます。

自動フェイルオーバー実行approximately 10 minutes 、AFDトラフィックの切り替え、SQLの切り替えが含まれます。

Failback Time - テクノロジーのみ

手動のフェールバック実行にはapproximately 15 minutes時間がかかり、AFDトラフィックの切り替えとSQLの切り替えが含まれます。

自動フェールバックの実行にはapproximately 10 minutes時間がかかり、AFDトラフィックの切り替えとSQLの切り替えが含まれます。

メモ

テクノロジーのRTO値は、システムがSitecoreプラットフォームの復元にかかる時間によって異なります。お客様またはパートナーが関与する手動の手順が必要な場合、これにより有効なRTOが延長される可能性があります。

リージョン間のレプリケーション

一般的なSitecore環境は、次のAzureリソース タイプで構成されています。

  • KeyVault - Azureはセカンダリ環境への読み取り専用レプリケーションを提供し、これによりセカンダリ環境でのSitecoreの継続的な運用が可能になります。

  • Storage Account - ストレージ アカウントで提供されるオブジェクト レプリケーションは、ストレージ アカウント コンテナーをセカンダリ環境に選択的にレプリケートするために使用されます。

  • ACR – ACRとそのイメージは、terraformを使用してプロビジョニングされます。Gitのインフラストラクチャ コードには、最新のターゲット状態が含まれており、セカンダリ状態のプロビジョニングまたは保守に使用されます。

  • AKS – AKSはterraformを使用してプロビジョニングされます。Gitのインフラストラクチャ コードには、最新のターゲット状態が含まれており、セカンダリ状態のプロビジョニングまたは保守に使用されます。

  • Azure SQL – Azureによって提供されるgeoレプリケーションにより、データのレプリケーションが保証されます。

この記事を改善するための提案がある場合は、 お知らせください!