はじめに
OCIでは、対応するOCIリソースの切り替えコマンドの実行をワンクリックで実装できるFull Stack Disaster Recovery という機能が提供されています。
リージョン障害やメンテナンスなどの計画停止に備える機能として便利です。
サービスの詳細は以下をご参照ください。
OCI Full Stack Disaster Recovery サービス概要
今回は「移動インスタンス」を使用した場合の動作確認をしたかったので、スタート・ドリルの実施を試してみました。
目次
1. 構成イメージ
まずは構成要素についてです。
本検証はComputeを移動インスタンスとした場合の動きを確認したいので、DBを含まないシンプルな構成で、以下のようなイメージを想定しています。
※構成参考：Speaker Deck
DR保護グループのメンバーにComputeインスタンスと、インスタンスにアタッチされるBoot VolumeとBlock Volumeをグループ化したボリューム・グループを追加します。
【使用するリージョン】
・プライマリ・リージョン：Austrailia East (Sydney)
・スタンバイ・リージョン：US West (San Jose)
今回は試しに、プライマリ側で障害が発生した際にスタンバイ側にインスタンスが移動されるシナリオを想定し、「移動インスタンス」というものを設定します。
2. 前提
使用するリソースごとに事前設定が必要なので、これらをクリアしていることを前提とします。
今回使用するリソースはComputeインスタンスとボリューム・グループのみですが、別途操作ログの保管場所としてObject Storageを用意しておく必要があります。
詳細は以下のドキュメントにてご確認ください。
フル・スタック・ディザスタ・リカバリの前提条件
3. FSDR構成
FSDRの構成を作成する大まかな手順は以下です。
①DR保護グループの作成（各リージョンで実施）
②各リージョンのDR保護グループを関連付ける（プライマリとスタンバイのロールを指定）
③各DR保護グループにリソースをメンバーとして登録する
④DR計画を作成
⑤計画の実行
順を追って手順を進めていきます。
3-1. DR保護グループの作成
まずはメニューから、「移行とディザスタ・リカバリ」→「ディザスタ・リカバリ」→「DR保護グループ」をクリックします。
最初のステップとして、プライマリとスタンバイの両方でDR保護グループを作成する必要があるのでSydneyリージョンでDR保護グループの作成画面に進みます。
「DR保護グループの作成」をクリックし、以下の作成画面を表示させます。
ここではDR保護グループの名前とログ保管用のObject Storageのバケットを指定し、ロールやメンバーは未設定のまま「作成」に進みます。
※同様にスタンバイのSan Jose側でもDR保護グループの作成をしますが、同じ手順なので今回は割愛します。
各リージョンで作成が完了したことを確認します。
・Sydneyリージョン側
・San Joseリージョン側
今回はSydney側をプライマリ、San Jose側をスタンバイとします。
3-2. 各リージョンのDR保護グループを関連付ける
次に、作成したDR保護グループを関連付けるためにどちらかのリージョンでDR保護グループの詳細画面に進みます。
※プライマリ側からでもスタンバイ側からでも設定できるため、どちらのリージョンで実施しても問題ありません。
今回はSydneyにてDR保護グループの詳細画面に進み、「関連付け」をクリックします。
ここでロールを指定します。Sydneyをプライマリとしたいので、プライマリを選択します。
ピア・リージョンの選択ができるようになります。
San Joseをピア・リージョンとして選択すると、ピアDR保護グループは先ほどSan Joseで作成したものが自動で選択されるので、そのまま「関連付け」をクリックします。
関連付けが完了するとピアDR保護グループとピア・リージョンが表示されるので、無事に紐づいているかをこちらで確認することができます。
3-3. 各DR保護グループにリソースをメンバーとして登録する
DR保護グループの詳細画面の左下のメニューから「メンバー」→「メンバーの追加」に進みます。まずはプライマリ側で実施します。
「メンバーの追加」画面に進んだらリソースの選択をします。
今回は「コンピュート」と「ボリューム・グループ」をそれぞれ順番に追加していきます。
「リソース・タイプ」で「コンピュート」を選択すると、対象のインスタンスとインスタンス・タイプ（移動インスタンスまたは非移動インスタンス）を選択できるようになります。
今回は移動インスタンスを試してみたいと思います。
また、「VNICマッピングの追加」で宛先VCN、宛先サブネットなどを指定し「追加」に進みます。
同じようにボリューム・グループもメンバーに追加します。
メンバーに追加されました！
3-4. DR計画を作成
次にDR計画を作成します。
DR計画のタイプは4種類あり、それぞれの違いについて以下をご参照ください。
※Speaker Deckより抜粋（ドキュメントの該当箇所：ディザスタ・リカバリ計画のタイプ）
スタンバイ側で設定する必要があるので、San JoseリージョンからDR保護グループの詳細画面に進み、「計画の作成」を選択します。
今回、スタート・ドリルとストップ・ドリルで動作を確認したいので、まずはスタート・ドリルの計画を作成します。
「状態」が「作成中」→「アクティブ」になるのを待ちます。
作成時にDR計画の状態が「失敗」というステータスになった場合はDR計画の詳細画面に進み、「作業リクエスト」→「DR計画の作成」を選択→「エラー・メッセージ」で詳細を確認することができます。
本記事の目次2の前提条件を満たしていないことが原因の場合があります。筆者の場合、下記のエラー・メッセージが表示されました。
An error occurred while trying to create the DR Plan [ocid1.drplan.oc1.us-sanjose-1.amaaaaaassl65iqagt3rubvhjqpuxppujoh4ievkp6y2zwdzcbai24dswysq]. Check work request for more details. Cause - [An error occurred while refreshing DR Protection Group member details. Cause - [An error occurred while validating member [ocid1.instance.oc1.ap-sydney-1.anzxsljrssl65iqccxurxgblqodz7w7pyo642hpo6wowak5li4r77fzm67mq] of DR Protection Group [ocid1.drprotectiongroup.oc1.ap-sydney-1.amaaaaaassl65iqa5fpwzaw4uve5amlf3ay6jpqhbss5lnclaa7x5ejuvneq]. Cause - An error occurred while validating the movable compute instance [ocid1.instance.oc1.ap-sydney-1.anzxsljrssl65iqccxurxgblqodz7w7pyo642hpo6wowak5li4r77fzm67mq] member of the DR Protection Group [ocid1.drprotectiongroup.oc1.ap-sydney-1.amaaaaaassl65iqa5fpwzaw4uve5amlf3ay6jpqhbss5lnclaa7x5ejuvneq] for plan inclusion. Cause: An error occurred while validating member properties for movable instance [ocid1.instance.oc1.ap-sydney-1.anzxsljrssl65iqccxurxgblqodz7w7pyo642hpo6wowak5li4r77fzm67mq] -- [Error getting information for subnet [ocid1.subnet.oc1.ca-toronto-1.aaaaaaaayz3mrw3vkynjplih2oadms3amkxcvxrqrwl35d6t355vb35fe43q]. Cause: Downstream Error: (404, NotAuthorizedOrNotFound, false) Authorization failed or requested resource not found. (opc-request-id: C0C055DEB3BB42B093F46E4311E9CFE2/E7924526E1C00BD40F584C3C43AEFC77/6F88840AC48DEF7C13118365A8B95C5B).]]]
気になったのは、[Error getting information for subnet [ocid1.subnet.oc1.ca-toronto-1.aaaaaaaayz3mrw3vkynjplih2oadms3amkxcvxrqrwl35d6t355vb35fe43q]の箇所です。
【エラーの内容】
Torontoリージョンのサブネット情報の取得でエラー発生（今回はSydney-San Jose間のFSDR構成なので関係ないはずのリージョン）
【原因として考えたこと】
・今回、作成の過程で一度SydneyリージョンとTorontoリージョンの保護グループを関連付けしていたことがあった（メンバーの定義を変更せず、関連付け解除後に今回のSydneyのDR保護グループをSan Joseと関連付け）
・ComputeのVNICマッピングの定義でTorontoのVCNが指定されたままになっていた
【解決策】
・メンバーの編集画面からComputeの編集に進み、「VNICマッピング・リスト」を確認し、過去に定義されているマッピングを削除
・正しいVNICマッピングの追加し、更新（またはメンバーから一度Computeを削除し、再度正しい定義をした上でメンバーに追加）
同様の事象が出た場合は、この手順を踏むとDR計画の作成に進めるはずです！
DR計画が無事に作成されると、状態が「アクティブ」に切り替わります。
作成したDR計画の詳細画面に進むと、「計画グループ」というDR計画のステップが自動で組まれていることがわかります。カスタム・スクリプトを使用する場合など、必要であれば自分でグループの追加をしてステップを追加することも可能です。
カスタム・スクリプトを使った実装については以下をご参照ください。
Oracle Cloud Infrastructureフル・スタック・ディザスタ・リカバリを実行コマンドで使用して、カスタム・スクリプトを起動します
3-5. DR計画の実行
計画の実行をしてみます。
ステータスが「進行中」に切り替わり、現在どの計画グループが進行中になっているのかを「計画実行グループ」の項目から確認することができます。
「期間」は開始されてからの経過時間を示しています。
成功すると、スタンバイ側のSan JoseのメンバーにComputeインスタンスとボリューム・グループが表示されます。
※今回は「移動インスタンス」のパターンで試しており、実行前はプライマリ側にのみメンバーが存在していたため、無事にスタンバイ側でComputeインスタンスが起動され、ボリューム・グループもレプリケートされたことがわかります。
ちなみに、所要時間は4分程度でした。
同様の手順でストップ・ドリルの計画を作成して実行し、ドリルを終了します。
スタート・ドリル中はスタンバイのSan Jose側のメンバーにComputeインスタンスとボリューム・グループが出現しましたが、終了したのでメンバーは空の状態に戻ります。
計画の実行が失敗した場合は、原因を辿るためにログの表示をします。
計画の詳細画面→「計画実行グループ」の失敗している項目のメニューより「ログの表示」または「ログのダウンロード」を選択します。
どこでエラーが起きているかをここで確認することが可能です。
原因の追求をまずはする必要がありますが、先ほどの画面から失敗している計画をスキップすることも可能です。
スキップすると、「キュー済」になっている次の計画グループから順に実行されます。
今回はドリルのみ実施したのでロールの入れ替えはありませんでしたが、スイッチ・オーバーまたはフェイル・オーバーを実施するとプライマリとスタンバイが入れ替わります。
OCIコンソールから、Sydney側のロールがスタンバイに変更され、San Joseがプライマリに切り替わったことがわかります。
まとめ
移動インスタンス使用時の切り替えの動作確認のためドリルの機能を使ってテストしてみましたが、スタート・ドリル（プリチェックおよびスタンバイ側へのボリューム・グループのレプリケート、Computeインスタンスの起動含む）は4分程でスムーズに実施できました！
エラーの発生などつまづいたポイントもいくつかありましたが、構成の作成から計画の実行までの操作は比較的シンプルだと思います。
ドリルの機能は切り替えのリハーサルの位置付けなので、実装前に動作を試したい場合などに有用です。
おまけ
各リージョンの関係性（どのリージョンが関連づけられているか、どちらがプライマリでどちらがスタンバイなのか等）をマップで確認することも可能です。
コンソールのメニューから「移行とディザスタ・リカバリ」→「ディザスタ・リカバリ」→「概要」に進むとリージョン・マップが表示さます。
リージョン間の関連付けのほか、リージョンのヘルス状態やDR保護グループの有無を色で確認できます。カーソルをリージョンの位置に合わせるとリージョン名と「スタンバイ」または「プライマリ」が表示されます。
今回SydneyとSan Joseが想定通り紐づいており、両方のリージョンでDR保護グループが正常に動作していることが確認できました。
参考情報
Speaker Deck
・OCI Full Stack Disaster Recovery サービス概要
OCIドキュメント
・フル・スタック・ディザスタ・リカバリ
YouTube
・Automate Disaster Recovery orchestration using OCI Full Stack DR
・OCI Full Stack Disaster Recovery - Non moving compute enhancements
・Introducing New Enhancements for OCI Full Stack Disaster Recovery (FSDR)
・Understanding movable and non-movable compute
オラクルエンジニア通信
・新機能：FSDRのインスタンスの移動と容量予約の統合
・OCI Full Stack Disaster Recoveryの非移動コンピュートの拡張機能
・OCI Full Stack Disaster Recovery service(FSDR)をOCIで利用するメリット
Help Center
・
フル・スタックの障害時リカバリを使用したOCIリージョン間での仮想マシンの移動
・OCI Full Stack DRを使用して、移動していないコンピュート・ブロック・ボリュームをDRドリル・プランでアタッチまたはデタッチ
Maximum Availability Architecture
・OCI Full Stack Disaster Recovery Introduces DR Drills
Qiita
・OCI Full Stack Disaster Recovery (FSDR) が Load Balancer 対応になったので試してみた