ディザスタリカバリ2.0の手順
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
このトピックでは、災害復旧プロセスのさまざまな手順について説明します。デプロイメント・タスク、呼び出しタスク、およびフェールバック・タスクの役割と責任など、詳細については、災害復旧2.0の役割と責任を参照してください。
Sitecore Cloud Operationsは、お客様のご要望に応じて、事前にセカンダリAzureリージョンにDR環境を作成します。たとえば、本番環境がデプロイされた直後または後でこれを行うように要求できます。環境は最初は運用環境と一致しますが、その後、コストを節約するために下位レベルにスケールダウンされます。ディザスター リカバリー プロセスが開始されると、環境は再びスケール アップされます。
お客様は、災害復旧プロセスの開始を要求または許可する責任があります。これを実行すると、回復プロセスは次の手順に従います。
-
セカンダリAzureリージョン (DRリージョン) に切り替える
-
DR環境がスケールアップされる
-
DRリージョンへのフェールオーバーが完了しました
-
DRリージョンからライブ配信を開始する
Azureサービスのスケーリング
次のAzureサービスは、DRフェールオーバー プロセスの一部として、運用SKUとレベルに合わせてスケールアップされます。既定の運用トポロジとDRトポロジとレベルに含まれるAzure SKUの完全な一覧については、次の記事を参照してください。
Azureアプリケーション ゲートウェイ
すべてのApplication Gatewayインスタンスは、対応する運用SKUとレベルに合わせてスケールアップされます。
Azureアプリ サービス
すべてのAzure Appサービスは、対応する運用SKUとレベルに合わせてスケールアップされます。
Azure SQLデータベース
すべてのAzure SQLエラスティック プールは、対応する運用SKUとレベルに合わせてスケールアップされます。
Azure Redisキャッシュ
Azure Redisには、次の2つのフェールオーバー スケーリング手順が必要です。
-
Basic C0はStandard C0にスケーリングされます。
-
Standard C0はPremium P1にスケーリングされます。
Redis Cacheのスケーリング アクティビティには約30分かかります。この間、Azure Redisキャッシュへのアクセスが断続的に行われる可能性があります。このスケールアップ活動は、Microsoft Azureに完全に依存しています。Sitecoreは、Redis Cacheインスタンスのスケーリング時間に影響を与えたり、保証したりすることはできません。
Searchサービス (SearchStax経由のSolr)
Managed Cloudには、初期の運用デプロイの一部として (SearchStax経由の) Solr検索のプロビジョニングが含まれています。DRが含まれる場合、Sitecoreは専用のDR Solr検索クラスターの提供も保証します。DRプロセスが開始されると、DR検索クラスターがフェイルオーバー環境に接続されます。これらのビジネス目標を達成するために、Sitecoreは3時間ごとにバックアップを取ります。これには、すべてのSolr設定ファイル、Solrコレクション、エイリアス、セキュリティ ファイル、カスタムJARファイルが含まれます。 運用クラスターからのバックアップが正常に完了すると、復元プロセスがDR環境で開始されます。
フェイルオーバー後のアクティビティ
プライマリ環境からのフェイルオーバーが成功したら、Web Appフォルダの内容と構造を変更または更新しないことをお勧めします。ソースの場所 (最初のプライマリ ロケーション) の整合性を維持するために、SitecoreはApp Serviceの同期をオフにします。SQLデータベースの同期は、プライマリの場所が使用可能な場合、維持されます。
プライマリ環境のフェイルオーバー中は、サービスが一時的に中断されることが予想されます。ソース・ロケーションのアクティブ・ユーザー・セッションはドロップされ、ユーザーは再認証が必要で、新しいセッションがセカンダリ・ロケーションで確立されます。これには、プライマリRedisキャッシュ インスタンスに格納されているアクティブなセッション データが含まれます。
フェイルバック
運用環境へのフェールバックは、以前に影響を受けたリージョンのすべてのサービスがオンラインに戻った場合にのみ可能です。Sitecoreは、お客様の要求に応じてフェイルバック プロセスを開始します。フェールバック プロセスでは、App Serviceの更新と変更はプライマリ環境と同期されません。
プライマリ環境へのフェールバック中に、サービスが一時的に中断されます。ソース・ロケーションのアクティブ・ユーザー・セッションはドロップされ、プライマリ・ロケーションがオンラインに戻ったときに新しいセッションが確立されます。これには、Redis Cacheインスタンスに保存されているアクティブなセッションデータが含まれます。ログインしていたユーザーは、プライマリ環境でセッションを開く前に再認証する必要があります。
顧客カスタムAzureサブスクリプション
カスタマー カスタムAzureサブスクリプションは、DRフェールオーバー後に必要になる可能性のあるSitecore以外のコンポーネントの場所として使用できる空のAzureサブスクリプションです。
サブスクリプションを受け取ると、空のAzureリソース グループのみが含まれます。Sitecoreは、このサブスクリプション内にAzureサービスをデプロイしません。お客様は、Customer-custom Productionサブスクリプションと対応するCustomer-custom DRサブスクリプション内のリソースのデプロイを所有します。