クラウドエンジニアブログ

ストレージアカウントの手動フェールオーバー

uchizono-toshiteru

内苑 利映

皆さん、こんにちは!内苑です!
この記事では、Azure ストレージアカウントの手動フェールオーバーの動作について、実際にオペレーションをしながら解説していきたいと思います。

  1. はじめに
  2. 動作仕様
  3. 動作検証
  4. まとめ


1. はじめに

ご存じの通り、Azure のストレージ アカウントにはデータコピーのオプションが用意されておりますが、今回の機能はセカンダリ リージョンにデータコピーを行う以下 2つのいずれかのオプションが設定されたストレージ アカウントにて実施可能なものとなります。

  • geo 冗長ストレージ (GRS)
    LRS を使用して、プライマリ リージョンの 1つの物理的な場所内で、データを同期的に 3回コピーし、その後セカンダリ リージョンの 1つの物理的な場所にデータを非同期的にコピーする。セカンダリ リージョンでは、データは常に LRS を使用して 3回同期的にレプリケートされ、プライマリ リージョンと合わせて計 6つのデータコピーが作成される。
  • 読み取りアクセス geo 冗長ストレージ (RA-GRS)
    GRS に加え、通常時もセカンダリ リージョンのデータに対して読み取りアクセスが可能となる。

これまで、ストレージ アカウントのフェールオーバーは、Microsoft 社によってリージョン規模の災害発生時に自動で行われるものであり、ユーザー任意のタイミングで手動で行うことはできなかったのですが、現在はパブリックプレビューにて手動フェールオーバーを実行することができるようになっています。


2. 動作仕様

通常時、ユーザーは Azure ポータルや、Azure Storage Explore などからストレージ アカウントに接続し、データのアップロードや更新を行います。その際の書き込み動作はプライマリエンドポイント経由でプライマリ リージョンのストレージ アカウントに対して実施され、非同期でセカンダリ リージョンにデータがコピーされます。

動作仕様1


ユーザー任意のタイミングでフェールオーバーを開始すると、フェールオーバープロセスにより Azure Storage により提供される DNS エントリの更新が行われ、セカンダリ エンドポイントがストレージ アカウントに対する新しいプライマリ エンドポイントになります。

動作仕様2


DNS エントリが更新され、要求が新しいプライマリ エンドポイントに送られるようになると、書き込みアクセスが復元されます。以降のデータ書き込みはセカンダリリージョンに対して行われます。

動作仕様3


フェールオーバー後、ストレージアカウントはローカル冗長 (LRS) で構成されるため、リージョンレベルの冗長を継続して行う場合は改めて GRS、または RA-GRS の構成に設定する必要があります。ただし、こちらの Microsoft 社の公開情報ではこんなことが書かれています。

ストレージ アカウントが geo 冗長に再構成された後、新しいプライマリから新しいセカンダリへの別のフェールオーバーが開始される可能性があります。この場合、フェールオーバー前の元のプライマリ リージョンが再びプライマリ リージョンになり、ローカル冗長に構成されます。その場合、フェールオーバー後のプライマリ リージョン (元のセカンダリ) のすべてのデータが失われます。


要するに、フェールオーバー後に geo 冗長構成の設定を行うと、フェールバックとみなされプライマリエンドポイントを元のプライマリ リージョンに戻すという動作であると読み取れます。この辺りは実際に動かしながら確認していこうかと思います。


3. 動作検証

それでは、実環境で動作を確認していきます。検証に使用するストレージアカウントを以下の通り作成します。

名前:failoverteststr
アカウントの種類:StorageV2 (汎用 v2)
レプリケーション:地理冗長ストレージ (GRS)
場所:東日本

また、フェールオーバー後どの時点のデータが保持されているかを確認できるよう、10秒ごとにテーブルに現在時刻を書き込む処理を Logic Apps で実装し、実行しながら処理を進めていきます。

対象のストレージアカウントのリソース画面で、[geo レプリケーション] タブを選択し、セカンダリロケーションの状態が [利用可能] であることを確認します。

動作検証1


利用可能であることを確認したら、その下の [フェールオーバーの準備 (プレビュー) ] を選択し、最後の同期時刻を確認したら [フェールオーバー (プレビュー) ] を実行します。最後の同期時刻が AM11:14 頃になっていますね。AM 11:17 に実行したので、およそ 3分前くらいまでのデータはフェールオーバー後にも保持されていそうです。

動作検証2


実行するとフェールオーバーのステータスが [処理中] になります。

動作検証3


フェールオーバー中は、Azure Storage Explore から該当のテーブルを見ようとしてもこのように表示されなくなりました。

Azure ポータル上では以下のようにエラーが表示され、アクセス可能なエンドポイントがいいえ、となっています。

動作検証4


約 15分ほどでフェールオーバーが完了しました。データ量が多いともしかするともう少し時間がかかるかもしれません。

動作検証5


完了とともにエンドポイントに切り替わりも完了するのでしょうか。Logic Apps の処理もほぼ同時に復旧しているようです。

動作検証6


また、最後の同期時刻が AM11:14 となっていましたが、Logic Apps の実行履歴を見ると、AM11:19 までは書き込みの処理が成功しているようでした。

動作検証7


実際のフェールオーバー後のテーブルを確認してみると、Logic Apps で成功していた処理時間とほぼ一致してデータが残っていました。

動作検証8


Azure ポータルにてストレージの概要を確認すると、以下のようにステータスが変化していました。

レプリケーション:地理冗長ストレージ (GRS) ⇒ ローカル冗長ストレージ (LRS)
場所:東日本 ⇒ 西日本

動作検証9


それでは、フェールバックする動作を確認するため、Logic Apps の処理を再開しつつストレージアカウントのレプリケーションを GRS に設定します。

動作検証10


11:53 に構成変更を実行しました。

動作検証11


セカンダリリージョン東日本が利用可能になり、データ同期が開始されます。

動作検証12


同期が完了し、フェールオーバー可能な状態になってから 4時間ほど様子を見ていましたが、自動でフェールバックが発動するというような動きは見られませんでした。プライマリは西日本のままです。

動作検証13


エンドポイントの URL はフェールオーバー前のままなので、フェールオーバー完了後も問題なくテーブルへのデータ書き込み動作が再開されました。

動作検証14


動作検証は以上となります。どういう条件でフェールバックが起こるのかはもう少し調査が必要そうですね。


4. まとめ

実際にフェールオーバーの動作を確認してみましたが、かなり直近のデータを保持した状態で切り替わるようです。データの書き込み量や、元々のデータ量によって保持期間はブレがあるかもしれないので、[最後の同期時刻] に表示されるところまでは残る、という風に思ったほうがいいかもしれません。
あまり起こりえないシチュエーションかもしれませんが、フェールオーバーを手動で行う際は参考にしていただければ幸いです。

尚、データ移行の目的で実施するのは NG と公開情報には記載されているので注意してください。

【総合】お問い合わせ

ソリューションに関する全般的なお問い合わせはお気軽にご相談ください。

ピックアップ

セミナー情報
クラウドエンジニアブログ
clouXion
メールマガジン登録