PaaS 1.0の災害復旧
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
災害復旧は、手動介入が必要な災害後に組織がミッションクリティカル機能を維持または迅速に再開することを可能にします。Sitecore災害復旧(DR)サービスは、DR Basic(確認 )とDR管理(自動)の2種類のDRサービスを提供します。これらには2つのインフラストラクチャタイプがあります
(最小インフラ)とホットスタンバイ(フルレプリカ):-
DR 基本コールドスタンバイ
。復旧およびフェイルオーバーのプロセスはイベント後に開始され、顧客からの確認が必要です。これはコスト効率の良いサービスオプションで、より長い復旧時間(RTO)が設定されます。基本コールドスタンバイDRサービスタイプは最低限必要なインフラをプロビジョニングし、重要でないアプリケーションやデータが頻繁に変更される場合によく利用されます。基本的なコールドスタンバイ災害復旧にはジオレプリケーションが含まれます。災害発生時には、セカンダリーリージョンとデータベースへのフェイルオーバーが最小限のダウンタイムで行われます。
-
DR マネージドホットスタンバイ
。フェイルバックおよびフェイルオーバープロセスは自動的に開始されます。プライマリサイトのレプリカ全体をプロビジョニングします。これによりRTO間隔が最も短くなります。
環境に合った復旧方法は、フェイルオーバー開始を先手に行うか受動的か、そして障害発生時にどれくらい早く復旧したいかによって異なります。
!注Sitecoreの災害復旧プロセスの詳細については、災害復旧ポリシー文書をご覧ください。
リカバリーオプションの考慮事項
ご自身の要件に合った回復オプションを判断するには、以下の表を参考にして考慮してください:
- 障害が発生した場合にサイトをどれくらい早く復旧させる必要があるか。
- リカバリーポイント目標(RPO)。
- 回復時間目標(RTO)。
仕様
基本コールドスタンバイ
DR 管理されたホットスタンバイ
バックアップ技術
SQL Azure ジオレプリケーション
Azure APIs.
SQL Azure ジオレプリケーション
Azure APIs
回復プロセス
-
フェイルオーバーの顧客要望/承認
-
展開
-
リストア
-
切り替え
-
ライブで始めて
-
顧客検証
-
切り替え
-
ライブで始めて
-
顧客検証
二次環境状態
オンデマンド作成
プライマリ環境の正確な複製。Sitecore Azure Web Appsが完全に展開され、停止
リカバリーポイント目標(RPO)
SQL 5秒
WebApp 3時間
SQL 5秒
WebApp 3時間
回復時間目標(RTO) - 技術のみ
4時間
< 1分
フェイルバック時間 - テクノロジーのみ
4時間
10分
!注技術のRTO値は、システムがSitecoreプラットフォームを復元するのにかかる時間によって異なります。顧客やパートナーが手動で行う必要がある場合は、実質的なRTOが延長されることがあります。
領域間の複製
典型的なSitecore環境は、App Services、Azure SQL、Application Insights、Solr、Redis Cacheの5つのAzureリソースタイプで構成されています。Sitecoreすべてのリソースのサイズとインスタンス数が二次データセンターに複製されることを保証します。しかし、ファイルやデータがバックアップ・復元されるのはApp ServicesとAzure SQLのみです。他のサービスは、一時的なデータであるか、成功した復元に必要でないため、レプリケートされません。具体的には以下の通りです:
- App Services – すべてのファイル/データはバックアップされ、復元されます。
- Azure SQL – すべてのファイル/データはバックアップされ、復元されます。
- Redis Cache – Redis Cacheには通常、Sitecoreサイトが復元される前に期限切れとなるユーザーセッションデータが含まれているため、データが複製されません。そのため、災害復旧戦略の一部として含まれていません。
- Application Insights – Application Insightsには健康監視データしか含まれないため、データは複製されません。これはSitecoreサイトの実行時間には必要ありません。