皆さん、こんにちは！内苑です！
この記事では、Azure ストレージアカウントの手動フェールオーバーの動作について、実際にオペレーションをしながら解説していきたいと思います。
ご存じの通り、Azure のストレージ アカウントにはデータコピーのオプションが用意されておりますが、今回の機能はセカンダリ リージョンにデータコピーを行う以下 2つのいずれかのオプションが設定されたストレージ アカウントにて実施可能なものとなります。
これまで、ストレージ アカウントのフェールオーバーは、Microsoft 社によってリージョン規模の災害発生時に自動で行われるものであり、ユーザー任意のタイミングで手動で行うことはできなかったのですが、現在はパブリックプレビューにて手動フェールオーバーを実行することができるようになっています。
通常時、ユーザーは Azure ポータルや、Azure Storage Explore などからストレージ アカウントに接続し、データのアップロードや更新を行います。その際の書き込み動作はプライマリエンドポイント経由でプライマリ リージョンのストレージ アカウントに対して実施され、非同期でセカンダリ リージョンにデータがコピーされます。
ユーザー任意のタイミングでフェールオーバーを開始すると、フェールオーバープロセスにより Azure Storage により提供される DNS エントリの更新が行われ、セカンダリ エンドポイントがストレージ アカウントに対する新しいプライマリ エンドポイントになります。
DNS エントリが更新され、要求が新しいプライマリ エンドポイントに送られるようになると、書き込みアクセスが復元されます。以降のデータ書き込みはセカンダリリージョンに対して行われます。
フェールオーバー後、ストレージアカウントはローカル冗長 (LRS) で構成されるため、リージョンレベルの冗長を継続して行う場合は改めて GRS、または RA-GRS の構成に設定する必要があります。ただし、こちらの Microsoft 社の公開情報ではこんなことが書かれています。
ストレージ アカウントが geo 冗長に再構成された後、新しいプライマリから新しいセカンダリへの別のフェールオーバーが開始される可能性があります。この場合、フェールオーバー前の元のプライマリ リージョンが再びプライマリ リージョンになり、ローカル冗長に構成されます。その場合、フェールオーバー後のプライマリ リージョン (元のセカンダリ) のすべてのデータが失われます。
要するに、フェールオーバー後に geo 冗長構成の設定を行うと、フェールバックとみなされプライマリエンドポイントを元のプライマリ リージョンに戻すという動作であると読み取れます。この辺りは実際に動かしながら確認していこうかと思います。
それでは、実環境で動作を確認していきます。検証に使用するストレージアカウントを以下の通り作成します。
名前：failoverteststr
アカウントの種類：StorageV2 (汎用 v2)
レプリケーション：地理冗長ストレージ (GRS)
場所：東日本
また、フェールオーバー後どの時点のデータが保持されているかを確認できるよう、10秒ごとにテーブルに現在時刻を書き込む処理を Logic Apps で実装し、実行しながら処理を進めていきます。
対象のストレージアカウントのリソース画面で、[geo レプリケーション] タブを選択し、セカンダリロケーションの状態が [利用可能] であることを確認します。
利用可能であることを確認したら、その下の [フェールオーバーの準備 (プレビュー) ] を選択し、最後の同期時刻を確認したら [フェールオーバー (プレビュー) ] を実行します。最後の同期時刻が AM11:14 頃になっていますね。AM 11:17 に実行したので、およそ 3分前くらいまでのデータはフェールオーバー後にも保持されていそうです。
実行するとフェールオーバーのステータスが [処理中] になります。
フェールオーバー中は、Azure Storage Explore から該当のテーブルを見ようとしてもこのように表示されなくなりました。
Azure ポータル上では以下のようにエラーが表示され、アクセス可能なエンドポイントがいいえ、となっています。
約 15分ほどでフェールオーバーが完了しました。データ量が多いともしかするともう少し時間がかかるかもしれません。
完了とともにエンドポイントに切り替わりも完了するのでしょうか。Logic Apps の処理もほぼ同時に復旧しているようです。
また、最後の同期時刻が AM11:14 となっていましたが、Logic Apps の実行履歴を見ると、AM11:19 までは書き込みの処理が成功しているようでした。
実際のフェールオーバー後のテーブルを確認してみると、Logic Apps で成功していた処理時間とほぼ一致してデータが残っていました。
Azure ポータルにてストレージの概要を確認すると、以下のようにステータスが変化していました。
レプリケーション：地理冗長ストレージ (GRS) ⇒ ローカル冗長ストレージ (LRS)
場所：東日本 ⇒ 西日本
それでは、フェールバックする動作を確認するため、Logic Apps の処理を再開しつつストレージアカウントのレプリケーションを GRS に設定します。
11:53 に構成変更を実行しました。
セカンダリリージョン東日本が利用可能になり、データ同期が開始されます。
同期が完了し、フェールオーバー可能な状態になってから 4時間ほど様子を見ていましたが、自動でフェールバックが発動するというような動きは見られませんでした。プライマリは西日本のままです。
エンドポイントの URL はフェールオーバー前のままなので、フェールオーバー完了後も問題なくテーブルへのデータ書き込み動作が再開されました。
動作検証は以上となります。どういう条件でフェールバックが起こるのかはもう少し調査が必要そうですね。
実際にフェールオーバーの動作を確認してみましたが、かなり直近のデータを保持した状態で切り替わるようです。データの書き込み量や、元々のデータ量によって保持期間はブレがあるかもしれないので、[最後の同期時刻] に表示されるところまでは残る、という風に思ったほうがいいかもしれません。
あまり起こりえないシチュエーションかもしれませんが、フェールオーバーを手動で行う際は参考にしていただければ幸いです。
尚、データ移行の目的で実施するのは NG と公開情報には記載されているので注意してください。
