Sitecore Managed Cloud Standard - ディザスタ リカバリのオートメーション


概要

この記事では、Sitecoreのディザスタ リカバリ(災害復旧、DR)ソリューション内の様々なオートメーション タスクによって実行される機能について説明します。PaaS向けManaged Cloud Standardディザスタ リカバリは、AzureのAutomationアカウントのRunbookを使用してディザスタ リカバリのタスクを実行します。

Automationアカウント、RunbookおよびRunbookのスケジューラなどの関連するサービスは、DRのセットアップ中に、DRのコントロール リソース グループ内に作成されます。

オートメーションには、以下の三種類が存在します。

スナップショット(Snapshot)

スナップショットのRunbookは、プライマリSitecore環境の様々な設定とサービスのバックアップを作成します。以下にリストアップされているアクションを毎時間実行するように設定されています(「Web App backup scheduling」を除く)。関連する設定のJSONファイルとWeb Appのバックアップ(以下のテーブルに記載されているアクションに記載)は、コントロール リソース グループのストレージ アカウント内に保存されます。

アクション 説明
Web AppプランのSKUのバックアップ レベル、サイズ、およびプライマリSitecore環境のキャパシティなどのWeb Appプランの詳細が収集され、Blobとして保存される(WebAppSpecs.json)。プライマリ リージョンにプロビジョニングされたWeb Appのみが対象となる。
Web Appプランの設定のバックアップ プライマリSitecore環境のWeb Appプランの設定がが収集され、Blobとして保存される(WebAppSetting.json)。
プライマリ リージョンにプロビジョニングされたWeb Appのみが対象となる。
Web Appのバックアップ フィルターの作成 セカンダリ環境に復元する必要のない特定のパスを除外するために、プライマリSitecoreロールにバックアップ フィルターを適用する。
詳細については、KB1001292の「ディザスタ リカバリのバックアップ実行時に除外されるファイルの一覧」の節を参照のこと。
Web Appバックアップのスケジューリング

プライマリSitecoreロールのWeb Appコンテンツのバックアップ スケジュールが設定される。バックアップ スケジューラは12時間間隔で実行されるように設定される。バックアップの保持期間は3日間である。この間隔と保持期間の設定はblobとして保存され(SchedulerConfig.json)、バックアップのスケジュールのニーズに合わせて変更することが可能。
Web App管理操作アラートの作成 「Administrative operation has failed」と呼ばれるバックアップ失敗時のアラートが設定される。このアラートのタイトルは管理操作の失敗を示しており、部分的なバックアップの失敗アラートも管理操作に該当する点に注意。
SQL Serverデータベースの仕様のバックアップ Edition、MaxSizeBytes、CapacityなどのSitecoreのSQL Serverデータベースの仕様がプライマリ環境から収集され、コントロール リソース グループのストレージ アカウントにBlobとして保存される(DatabaseSpecs.json)。
Azure Searchプロパティのバックアップ(Azure Searchと連携して動作しているSitecoreのみ) レプリカ数、パーティション数などのAzure Searchの仕様がプライマリ環境から収集され、コントロール リソース グループのストレージ アカウントにBlobとして保存される(SearchSpecs.json)。
Redis Cacheプロパティのバックアップ サイズ、SKU、シャード数などのRedis Cacheの仕様がプライマリ環境から収集され、コントロール リソース グループのストレージ アカウントにBlobとして保存される(CacheSpecs.json)。
Web Appオートスケール設定のバックアップ プライマリSitecore環境のWeb Appオートスケール設定が収集され、コントロール リソース グループのストレージ アカウントにBlobとして保存される(ScaleSetting.json)。プライマリ リージョンにプロビジョニングされたWeb Appのみが対象となる。 
Web Appバックアップ ストレージ アカウントのblob URLのコピー BlobへのWeb Appのバックアップ パスのURLは、コントロール リソース グループ内のKey Vaultに保存される。

同期(Synchronize)

同期のRunbookは、スナップショットのRunbookによって実行されるバックアップをもとに、セカンダリ環境に関連するリソースを復元または更新します。以下にリストアップされているアクションを三時間ごとに実行されるように設定されています。

アクション 説明
SQLデータベースの同期

フェイルオーバー グループに含まれる、関連するデータベースの同期。

スナップショットのRunbookによって行われたバックアップから、データベースのスペックも更新される(DatabaseSpecs.json)。

Web App設定の復元(ディザスタ リカバリ ホット スタンバイのみ) スナップショットのRunbookによってストレージ アカウントに保存された設定で、セカンダリWeb Appが更新される(WebAppSetting.json)。
Web AppプランのSKUの復元(ディザスタ リカバリ ホット スタンバイのみ) スナップショットのRunbookによってストレージ アカウントに保存された設定を元に、セカンダリWeb Appが更新される(WebAppSpecs.json)。
Redis Cacheプロパティの復元(ディザスタ リカバリ ホット スタンバイのみ) スナップショットのRunbookによってストレージ アカウントに保存された設定で、セカンダリRedis Cacheが更新される(CacheSpecs.json)。
Azure Searchプロパティの復元(Azure Searchを使用しているディザスタ リカバリ ホット スタンバイのソリューションのみ) スナップショットのRunbookによってストレージ アカウントに保存された設定で、セカンダリAzure Searchが更新される(SearchSpecs.json)。
Web Appのオートスケール設定の復元(ディザスタ リカバリ ホット スタンバイのみ) スナップショットのRunbookによってストレージ アカウントに保存されたオートスケール設定で、セカンダリWeb Appが更新される(ScaleSetting.json)。
Web Appの復元(ディザスタ リカバリ ホット スタンバイのみ)

Web Appのバックアップ スケジューラによってストレージ アカウントに保存されたバックアップで、セカンダリweb appの内容が更新される。復元を行うために、同期のRunbookによってセカンダリWeb Appの復元のwebjobが開始される。

注: 復元のwebjobは、DRのセットアップ中にセカンダリ ロールに作成されます。

注: これらのアクションの多くは、「ディザスタ リカバリ ホット スタンバイ」にのみ適用されます。「基本的なディザスタ リカバリ コールド スタンバイ」については、リストアップされたアクションはフェイルオーバー中に実施されます。

状態マネージャ(State Manager)

状態マネージャのRunbookは、セカンダリ環境への自動的なフェイルオーバーとプライマリ環境へのフェイルバックを実行する必要があるため、「ディザスタ リカバリ ホット スタンバイ」にのみ適用されます。状態マネージャは、必要なときにフェイルオーバーまたはフェイルバックのいずれかを実行できるように、コンテンツ配信ロールの正常性ステータスとSitecore Coreデータベースの可用性を基準として、プライマリ環境の正常性ステータスを定期的に確認します。フェイルオーバーまたはフェイルバックが必要か否かを判定するために、以下のリソースが5分ごとに、30秒間隔で順番に確認されます。

アクション 説明
フェイルオーバー
オートメーションのrunbook(スナップショットおよび同期)の停止 セカンダリ環境でのバックアップと復元の操作を停止する。
セカンダリ環境でWeb Appを起動 RTO(目標復旧時間)を伸ばすために、他のアクションを実行する前に、フェイルオーバー処理の一環としてセカンダリ環境でSitecoreロールが起動される。
SQL Serverフェイルオーバー グループの切り替え・フェイルオーバー

SQL Serverフェイルオーバー グループのセカンダリ環境への強制フェイルオーバーを実施する。
強制フェイル オーバーは、機能していないプライマリSQLサーバーから直近の更新が伝達されるのを無期限に待つことなく、セカンダリSQLサーバーを直ちに切り替えてプライマリSQLサーバーの役割を担当させるようにする。
しかしながら、セカンダリSQLサーバーへのデータは非同期的にレプリケーションされるため、この操作を行うとデータの損失が発生する可能性がある。

プライマリSQLサーバーでShardテーブルを更新(XPのみ) Shardテーブルがセカンダリ データベースを指すように設定されていることを確認する。
コンテンツのインデックス作成(Azure Searchのみ) SQL Serverのスイッチオーバー後に最新のデータが利用できるようにする。
xDBインデックスの再構築(Azure Searchを利用するXPソリューションのみ) SQL Serverのスイッチオーバー後に最新のデータが利用できるようにする。
フェイルバック
セカンダリ環境のWeb Appの停止 Sitecoreロールのインスタンスが一つだけ実行している状態(つまり、プライマリのSitecoreロールが実行されている状態)にする。
SQL Serverフェイルオーバー グループの切り替え・フェイルオーバー SQL Serverのフェイルオーバー グループをプライマリ環境に切り替える。
プライマリSQLサーバーでShardテーブルを更新(XPのみ) Shardテーブルがプライマリ データベースを指すように設定されていることを確認する。
コンテンツのインデックス作成(Azure Searchのみ) SQL Serverのスイッチオーバー後に確実に最新のデータが利用できるようにする。
xDBインデックスの再構築(Azure Searchを利用するXPソリューションのみ) SQL Serverのスイッチオーバー後に確実に最新のデータが利用できるようにする。
オートメーションのrunbook(スナップショットおよび同期)の開始 セカンダリ環境でのバックアップと復元の操作を再開する。

 

註: 以下の関連記事もご参照ください。
Sitecore Managed Cloud Standard - ディザスタ リカバリ(災害復旧)