以下のディザスタ リカバリ（災害復旧、DR）タイプが、次のように変更されます。
新しいタイプへのサポートは現在進行中であることにご注意ください。古いDRタイプは、既存のお客様のDR環境が移行してから廃止されます。
以下の表は、新旧のDRタイプの対応表です。
| 旧 | 新 | 備考 |
| 基本 (Basic) | DR Basic コールド スタンバイ (DR Basic Cold Standby) | 移行 |
| 基本的なgeoレプリケーション(Basic Geo-Replication) | DR Basic コールド スタンバイ (DR Basic Cold Standby) | 完全に一致 |
| ホットウォーム(Hot-Warm) | DR Managed ホット スタンバイ (DR Managed Hot Standby) | 移行 |
| ホット マニュアル(Hot Manual) | DR Managed ホット スタンバイ (DR Managed Hot Standby) | 移行 |
| ホット オート(Hot Auto) | DR Managed ホット スタンバイ (DR Managed Hot Standby) | 完全に一致 |
Sitecore マネージド クラウドのディザスタ リカバリ機能を使用すると、災害後にミッション クリティカルな機能を維持または迅速に再開できるようになり、お客様の事業継続計画をサポートできます。本番環境（プライマリ）を含むリージョンで災害が発生した場合、ディザスタ リカバリ ツールを使用すると、環境を別のリージョン（セカンダリ）またはディザスタ リカバリ サイトに復旧できます。
Sitecoreでは現在、2つのディザスタ リカバリ オプションを提供しています:
本記事では、お客様が知っていただくべき災害復旧構成、ワークフロー、およびアーキテクチャの側面に関する情報を提供します。
全ての災害復旧オプションで共通となる、以下の前提条件があります。
災害が発生すると、Sitecoreは15分以内にアラート メールを受信します。アラート メールに基づいて、Sitecoreはアラートの信頼性を検証し、事象を調査するためのお問い合わせを作成し、最初の調査についてお客様に通知します。事象が何らかの災害の結果によるものであること、つまりプライマリ リソース グループを一時的に回復できないことが判明した場合、Sitecoreはサービス タイプに応じて、お客様からの承認後、またはお客様からの承認なしでフェイルオーバー プロセスを開始します。フェイルオーバープロセスは、プライマリ環境が利用可能になるまでビジネス クリティカルなアクティビティを継続できるセカンダリ環境をお客様に提供します。
留意点:
Sitecoreは、次の2つのディザスタ リカバリ機能を提供します。
DR Basic コールド スタンバイ
DR Basic コールド スタンバイ オプションは、より長い回復時間を要します。フェイルオーバー プロセスの一環として、セカンダリ Sitecore XP/XM 環境が作成されるためです。
DR Basic コールド スタンバイは、Geoレプリケーションも提供します。
Geoレプリケーションを含むDR Basic コールド スタンバイは、セカンダリ リージョンにデータベースの継続的なコピーを作成します。災害時には、セカンダリ リージョンにフェイルオーバーし、最小限のダウンタイムでデータベースを起動できます。
DR Managed ホット スタンバイ
ホット スタンバイ リカバリ オプションは、コールド スタンバイのディザスタ リカバリ構成と比較して、リカバリ時間が最も短くなります。
これは、セットアップ中にセカンダリSitecore XP・XM環境がプロビジョニングされているためです。
フェイルオーバーの際に、webアプリを開始し、Traffic Managerのエンドポイントを切り替えて、サービスをオンラインに戻します。
特定のディザスタ リカバリ機能の詳細についてのご質問がありましたら、Sitecoreサポートポータルからサポートのお問い合わせを送信してください。
Sitecore XP・XMソリューションを構築する場合、ディザスタ リカバリの導入について、いくつかの点を新たに検討する必要があります。本節では、最も一般的なものをいくつか説明します。
SQLサーバーのGeoレプリケーションとフェイルオーバー グループ
ディザスタ リカバリは、AzureのSQLサーバー向けGeoレプリケーションを使用します。ただし、データベースを複数のフェイルオーバー グループに追加できない制限があります。したがって、そのような既存のフェイルオーバー グループは削除する必要があります。
これは、ディザスタ リカバリを設定する前に、プライマリSQLサーバー向けにフェイルオーバー グループを使用されていたSitecore環境のお客様に適用されます。
ディザスタ リカバリのセットアップを進める前に、以下の手順で更新・検証してください。
Azureリージョンの選択
Azureは、レイテンシが定義された境界を持つリージョンにデータ センターを編成し、専用のリージョン低レイテンシ ネットワークを介して接続されます。セカンダリ データセンターを選択する際には、プライマリと同じリージョンにあるデータセンターを選択して、高速バックアップと一貫したお客様の配信速度を確保することをお勧めします。互換性のある地域には、本記事を参照してください。
コントロール リソース グループのAzureリージョン
コントロール リソース グループのリージョンを選択する際の、厳密なルールや特別なルールといったものはありません。考慮すべき事項は次のとおりです。
サード パーティのサービスAPI
Sitecoreの実装が、IPに基づいてアクセスを制限するサード パーティのサービスAPIを使用している場合、セカンダリ データセンターのIPをサービスに登録することが不可欠です。IPの登録に失敗すると、セカンダリSitecore環境をオンラインにするのに遅延が生じる可能性があります。
サービス停止ページ
Managed Cloudはサービス停止の際に、Azure Functionsを使用して、サービス停止ページを表示します。Azure Functionsを使用すると、サービス停止ページから503コードが返され、サービスが利用できないことが示されます。例えば、サービス停止ページには以下のように、 サイトがまもなくオンラインに戻ることを訪問者様に説明するために必要な情報のみを含めることをお勧めします。
サービス停止ページは、デフォルトで簡単なテキストが記述されているだけのページです。サポートケースを作成することにより、サービス停止(Outage)アプリへの一時的なアクセスをリクエストして、貴社の要件に基づいて停止アプリをカスタマイズできます。
アクセス
カスタム構成、カスタムドメイン等でリソースを更新する場合は、Traffic Manager、Function App（サービス停止ページを提供）、及びセカンダリ リソース グループへの一時的なアクセスを提供できます。
本節では、マネージド クラウドが提供するディザスタ リカバリ オプションの制限について説明します。
コントロール リソース グループの削除はできない
コントロール リソース グループには、セカンダリ データセンターでSitecore XP・XM環境を正常に復元するために使用されるすべてのリソースが含まれています。コントロール リソース グループまたはそのリソースを削除すると、リカバリを正常に実行できなくなる可能性があります。
ディザスタ リカバリのバックアップ実行時に除外されるファイルの一覧
ディザスタ リカバリのセットアップは、ディザスタ リカバリのフェイルオーバーのニーズを満たすために、全てのWebアプリをバックアップするバックアップ プロセスを構成します。本プロセスを実現するために、バックアップから除外されるファイルがプライマリWebアプリにあります。次の表では、除外されるファイルについて説明します（Sitecore XP・XM 9.1 Initial Release以降が対象）。
| ファイル | トポロジー | ロール | 詳細 |
|
\site\wwwroot\App_Data\logs | * | * |
一時ファイル、またはログ ファイルです。 |
| \site\wwwroot\bin\Feature.HADR_PublishAPI.dll \site\wwwroot\bin\Foundation.HADR_WebApi.dll | * | CM | HADR関連のAPIファイル。 |
リカバリ時間を考慮し、xDBはリカバリから除外される
大規模なコンテンツ データベースではかなりの時間がかかる可能性があるため、フェイルオーバー プロセスの実行にかかるリカバリ時間の中で、xDBの再構築はカバーされません。分析インデックスが再構築されない場合でも、リストに依存する機能（EXM等）にのみ影響し、フロント エンド サイトには影響しません。
フェイルオーバー中の特定の基盤システムのカスタマイズは回復されない
環境に追加されている、標準のManaged Cloudトポロジーの一部ではないAzureリソースまたはサービスは、フェイル オーバーの処理中には回復されません。これらのコンポーネントは、フェイルオーバー プロセスが完了した後で個別に追加する必要があります。
xConnect 検索インデクサー
Sitecore XPは、ソリューション全体でアクティブなxConnect検索インデクサーWebジョブを、1つだけ持つことができます。フェイルオーバーとサービスの復元が行われる場合は、インデクサーをシャットダウンする必要があります。
Azureの要件とコストに関する考慮事項
全てのディザスタ リカバリ オプションは、Azure WebApp BackupとTraffic Managerに依存しており、最低でもStandardの価格レベルのWebAppsが必要です。
フェイルオーバーがサポートされない状況
本番サイトをセカンダリ データ センターに復元できない状況がいくつかあります。例えば、認証やTraffic Manager等のグローバルなAzureサービスがダウンしている場合です。
Azure Service Busはサポートされない
HADRは、Azure Service Busの同期、バックアップ・復元、またはレプリケーションをサポートしません。これは、Sitecore XP・XMバージョン9.2.0及びSitecore XP・XMバージョン9.3.0にのみ適用されます。
カスタマイズされたリソースはサポートされない
標準のSitecore マネージド クラウド スタンダードのリソース以外のカスタム リソースとリソース構成はサポートされません。これには、プライマリ リソース グループのWAF、AFD、Traffic Manager、ストレージ アカウント、およびSQL エラスティック プールが含まれます。カスタム同期、バックアップ、復元、またはレプリケーションはサポートされません。
カスタムドメインまたはSSLバインディングは更新されない
フェイルオーバーの実行中、HADRは停止アプリまたはセカンダリWebアプリのカスタム ドメインまたはSSLバインディングを更新しません。
ディザスタ リカバリのテストはサポートされない
現時点では、お客様の実装に対するディザスタ リカバリ シナリオのテストはサポートされません。
Managed CloudのSitecoreはモジュールを含めたり、追加のサービスを構成できるようにするオプションを提供しています。しかしながら、Sitecoreディザスタ リカバリ ソリューションはデフォルトではモジュールへの完全なサポートを提供しておりません。以下に、モジュールおよび構成に対するディザスタ リカバリ サポートの性質に関しての詳細を記載します。
SXAはディザスタ リカバリで標準でサポートされています。SXA関連の構成はセカンダリ環境に同期されます。
JSSはディザスタ リカバリで標準でサポートされています。JSS関連のバイナリ、構成およびアイテムはセカンダリ環境に同期されます。
以下に記載されているモジュールは標準ではサポートされておらず、セカンダリ向けには手動で構成する必要があります。
プライマリSitecore XP/CMインストール（すなわち、お客様のプライマリ環境）中にインストールされたこれらのモジュールについては、フェイルオーバーの処理中に復元することができません。そのため、これらのモジュールはフェイルオーバーの処理が完了した後に個別に追加する必要があります。
カスタム構成およびインストールされたモジュールの機能性の保証は、ディザスタ リカバリ サービスの範囲には含まれておりません。そのため、カスタム ソリューションは、ドキュメントに記載されているディザスタ リカバリ サービスの手順を許容して対応することができるように設計していただく必要があります。
弊社ディザスタ リカバリ ソリューションは、プライマリ環境からの構成の多くを同期するため、リバース プロキシは部分的にサポートされています。
セカンダリCDロールでリバース プロキシを有効化するには、プライマリCDロールで作成したものと同じように、セカンダリで\home\site\applicationHost.xdtを作成します。
バックアップ・復元にカスタムWebアプリを含める
カスタムのWebアプリとは、Sitecoreロールではなく、デフォルトではプロビジョニングされないWebアプリ、すなわちお客様または外部のベンダーによって作成されるWebアプリのことです。
HADRは、自動スケーリング設定、WebアプリサービスプランSKU、アプリケーション設定と接続文字列、およびWebコンテンツの同期を管理します。
コンテンツの同期では、connectionstring.config、appsetting.config等の環境ベースの設定は変更されません。ユーザーはフェイルオーバー後に変更する必要があります。
ユーザーは、セットアップ後に_backup.filterを変更して、バックアップの除外を実現することもできます。
前提条件:
カスタムデータベース名
デフォルトでは、DRは、Azure MarketplaceまたはSitecore AzureToolkitで事前定義された名前でプロビジョニングされたデータベース名をサポートします。
さらにDRは、次のMSのドキュメントに記載されている、Azureによる制限に従ったカスタム名のデータベースもサポートします。
リソースの名前付けに関する制限事項 - Azure Resource Manager | Microsoft Learn
|
手順 |
説明 | |
|---|---|---|
|
1 |
プライマリ環境が上記の前提条件を満たしているかを確認します。 セットアップ、フェイルオーバー、およびフェイルバックを実行するときに必要となる考慮事項節を理解します。 ドキュメントに記載されている制限を理解します。制限が環境に影響を与える場合は、アクション プランを作成します。 追加のサポートと、それがカスタマイズにどのように影響するかを確認します。このドキュメントに記載されていないプライマリ環境で行われたカスタマイズは、DRではサポートされていないことに注意してください。 | |
|
2 |
お客様がDRセットアップを要求します。 |
「DR Basic ColdStandby Setup」サービスリクエストを作成するか、 または「DR Managed HotStandby Setup」サービスリクエストを作成します。 |
|
3 |
CloudOpsが前提条件と制限のチェックを行います。 | |
|
4 |
CloudOpsがDRセットアップを実行します。 |
CloudOpsはDRをプロビジョニングします。 |
|
5 |
CloudOpsが、お客様にDRセットアップのステータスを通知します。 |
CloudOpsは、DRセットアップの前、最中、および後に通知し、更新を提供します。 |
|
6 |
お客様が、関連するDNS構成DNSプロバイダーとトラフィック マネージャーを実行します。 |
「よくある質問」節に記載されているように、顧客は、DNS CNAMEレコードを使用して、トラフィックマネージャーのDNS名を指すようにCDインスタンスのカスタムドメインを構成します。 考慮事項節の「アクセス」項目で述べたように、CloudOpsは関連するリソースへの一時的なアクセスを提供するのに役立ちます。 CloudOpsは、構成および検証プロセスを支援する場合があります。 |
|
7 | サービス停止アプリのコンテンツを構成します。 |
「よくある質問」節に記載されているように、お客様の仕様に従ってサービス停止ページを構成します。 考慮事項節の「アクセス」項目で述べたように、CloudOpsチームは関連するリソースへの一時的なアクセスの提供を支援します。 |
|
|
手順 |
説明 |
|---|---|---|
|
1 |
Sitecoreサポートがプライマリ リージョンの可用性・災害アラートを受信します。 |
弊社の制御リソース グループにおける監視サービスが、Sitecoreサポートがアクションを実行するためのアラートを生成します。 |
|
2 |
Sitecoreサポートがお客様に災害を通知します。 |
お客様が災害の詳細について記載された通知を受け取ります。 |
|
3 |
フェイルオーバーが必要であると判断された場合、お客様がフェイルオーバーを要求します。 |
お客様はサポートのお問い合わせを作成していただき、フェイルオーバーの活動を承認していただきます。 |
|
4 |
Sitecoreサポートがフェイルオーバーを実行し、フェイルオーバーの状況についてお客様に通知します。 |
状況の更新については、作成されたサポートのお問い合わせ上でご連絡します。 |
|
5 |
任意で、お客様がセカンダリ環境にカスタム構成またはプロビジョニングを適用します。 |
フェイルオーバーを実行するときに必要となる考慮事項節を理解します。 ドキュメントに記載されている制限を理解します。制限が環境に影響を与える場合は、アクションプランを作成します。 追加のサポートと、それがカスタマイズにどのように影響するかを確認します。このドキュメントに記載されていないプライマリ環境で行われたカスタマイズは、DRではサポートされないことに注意してください。 |
|
|
手順 |
説明 |
|---|---|---|
|
1 |
Sitecoreサポートがプライマリ リージョンの可用性・リカバリ アラートを受信します。 |
弊社の制御リソース グループにおける監視サービスが、Sitecoreサポートがアクションを実行するためのアラートを生成します。 |
|
2 |
Sitecoreサポートがお客様に復旧を通知し、フェイルバックの活動への承認を求めます。 |
通知は、フェイルオーバーの活動の際に作成されたサポートのお問い合わせ上でご連絡します。 |
|
3 |
お客様にフェイルバックを承認していただきます。 |
承認は、フェイルオーバーの活動の際に作成されたサポートのお問い合わせ上で行っていただきます。 |
|
4 |
Sitecoreサポートがフェイルバックを実施し、フェイルバックの状況についてお客様に通知します。 |
状況の更新については、作成されたサポートのお問い合わせ上でご連絡します。 |
|
手順 | 説明 | |
|---|---|---|
|
1 |
CloudOpsがプライマリ リージョンの可用性・災害アラートを受信します。 |
制御リソース グループの監視サービスは、CloudOpsがアクションを実行するためのアラートを生成します。 |
|
2 |
フェイルオーバーが自動的に実行されます。 |
|
|
3 |
CloudOpsはフェイルオーバーのステータスをお客様に通知します。 |
|
|
4 |
オプションで、お客様がセカンダリ環境でカスタム構成またはプロビジョニングを適用します。 |
フェイルオーバーを実行するときに必要となる考慮事項節を理解します。 ドキュメントに記載されている制限を理解します。制限が環境に影響を与える場合は、アクションプランを作成します。 追加のサポートと、それがカスタマイズにどのように影響するかを確認します。このドキュメントに記載されていないプライマリ環境でカスタマイズが行われていると、DRではサポートされないことに注意してください。 |
|
手順 |
説明 | |
|---|---|---|
|
1 |
CloudOpsはプライマリ リージョンの可用性・災害アラートを受信します。 |
制御リソース グループの監視サービスは、CloudOpsがアクションを実行するためのアラートを生成します。 |
|
2 |
フェイルバックは自動的に実行されます。 |
|
|
3 |
CloudOpsはフェイルバックのステータスをお客様に通知します。 |
|
これらは、ディザスタ リカバリのセットアップ中にプライマリSitecore 環境に適用される変更であり、フェイルオーバーやフェイルバックなどのスムーズなディザスタ リカバリ操作を可能にするために必要なものです。
Sitecore webアプリのデータベース接続文字列
接続文字列のデータソースは、ディザスタ リカバリのセットアップ中にプライマリSQLサーバーからフェイルオーバー グループ エンドポイントに変更されます。これは、フェイルオーバーを実行する機能を有効にするために使用されます。
Sitecore ロール関連の変更
データベース接続文字列はApp_Config\ConnectionStrings.configにあります。
例えば、以下のような接続文字列は、次のように変更されます。
変更前：
<add name="security" connectionString="Data Source=primary-sql.database.windows.net" />
変更後：
<add name="security" connectionString="Data Source=primary-fg.database.windows.net" />
Identity Server
\Settings\Sitecore\IdentityServer\SitecoreMembershipOptions\ConnectionStringのConfig\production\Sitecore.IdentityServer.Host.xml ファイル内の、XPとXMの双方のトポロジでのIDサーバーのロールが更新されます。
追加の更新
Sitecoreバージョン 9.1.0以降のcortex-processing、ma-ops、xc-search ロールのデータベース接続文字列が更新されます。これらはApp_Data\jobs\continuous<specific-name>\App_Config\ConnectionStrings.configに適用されます。
cortex-processing → ProcessingEngine
ma-ops → AutomationEngine
xc-search → IndexWorker
Azure Search
接続文字列は、プライマリおよびセカンダリのAzure Search URLで構成されます。例えば、以下のような接続文字列は、次のように変更されます。
変更前：
<add name="cloud.search" connectionString="serviceUrl=https://primary-as.search.windows.net;apiVersion=2017-11-11;apiKey=F377288DE1D8549E5338AEA836DF7BE6" />
変更後：
<add name="cloud.search" connectionString="serviceUrl=https://primary-as.search.windows.net;apiVersion=2017-11-11;apiKey=abc123|serviceUrl=https://secondary-as.search.windows.net;apiVersion=2017-11-11;apiKey=abc1234" />
Hotfixのパッチ
Sitecoreバージョン9.1.0、9.1.1、および9.2.0のCD、CM、rep、およびprcのロールには、site\wwwroot\binにhotfix パッチ（Sitecore.ContentSearch.Azure.dll）が含まれます。
IndexAPI config
以下のファイルはプライマリCMロールにアップロードされます：
WebApi.config はsite\wwwroot\App_Config\Include\Sitecore.ContentIndexing.WebApi にアップロードされます。
Sitecore.ContentIndexing.WebApi.dll はsite\wwwroot\bin にアップロードされます。これは、ディザスタリカバリ専用です。
Sitecoreマネージド クラウド環境のマネージド クラウド ディザスタ リカバリ（DR）機能は、どうやってリクエストできますか？
お客様は、お近くのSitecoreオフィスまたはSitecoreの営業チームを通じて、Sitecore XP・XM 環境のディザスタ リカバリのセットアップをリクエストできます。
ディザスタ リカバリのセットアップが完了したら、どのようなアクションを実行する必要がありますか？
ディザスタ リカバリのセットアップが完了したら、お客様は次のアクションを実行していただく必要があります：
上記を実施する方法の説明は、ディザスタ リカバリのセットアップの提供後に、Sitecoreエンジニアから提供されます。または、お客様はSitecore サポート ポータルで詳細情報についてサポートのお問い合わせを送信していただけます。
ディザスタ リカバリのセットアップが完了した後に導入される新しいリソースは何ですか？
ディザスタ リカバリのセットアップのプロビジョニング後、お客様は、選択したDRタイプに応じて、次のリソース グループをご覧いただけるようになります：
お客様はディザスタ リカバリのリソースへのアクセス権が制限されていますか？
Sitecoreは、お客様に追加のリソース グループ（コントロール及びセカンダリ）への制限付きアクセスを提供します。これにより、Sitecore はバックアップ ポリシーと自動化に関連する構成への変更を防ぐことができます。
ディザスタ リカバリのセットアップのためにペアになったリージョンはどのように選択されますか?
Sitecoreは、Microsoftの標準に準拠した、お客様にとって最適な地域を選択します。詳細は、この記事を参照してください。
デフォルトのサービス停止ページを更新できますか？
はい、停止機能アプリへの一時的なアクセスを（Sitecore サポート ケースを使用して）リクエストし、デフォルトのサービス停止ページを更新できます。
フェイルオーバー後、プライマリ リソース グループの全てが使用可能になりますか？
いいえ、標準のマネージド クラウド リソース（Webapps、SQL DB、検索サービス）のみを復元します。HADRの現在の制限については、「制限」節を参照してください。
カスタム ドメインと SSL バインディングは、フェイルオーバー中にプライマリ環境から複製されますか？
いいえ、必要な全てのカスタム ドメインとSSLバインディングは、お客様が一時アクセスをリクエストして（Sitecore サポート ケースを使用して）セカンダリ リソースに追加する必要があります。
SolrCloudのディザスタ リカバリを有効化するにはどうすればよいですか？
マネージド クラウド インスタンスとSolrCloudを併せて購入いただいたお客様につきましては、Sitecoreは次の手順に従って、ディザスタ リカバリのセットアップを有効にし、両者にディザスタ リカバリの可用性を提供します。
なぜセカンダリのWeb AppはDRのプロビジョニング後に停止するのですか？
Sitecoreは、データベース内の情報へのアクセスや更新を行う基盤サービスを有しています。これには、オンラインになっているプライマリのSitecoreロールがこれらのアクションを実施しているため、セカンダリのロールがデータベース内の情報を処理・更新しようとして、問題を起こすことを防ぐ狙いがあります。