Azure Storage account failover

手動でAzure StorageアカウントのFailoverができるようになりました(Preview)。

いつの間にか使えるようになってたので試しておきたいと思います。

制限事項および注意事項

現状West US 2とWest US Centralのリージョンペアでのみ利用できます。
その他StorageのFailoverについては以下のドキュメントをきちんと読んで理解しておきましょう。

特にフェールオーバー時のデータ損失の可能性については十分に考慮すべきです。

データはプライマリ リージョンからセカンダリ リージョンに非同期に書き込まれるため、プライマリ リージョンへの書き込みがセカンダリ リージョンにレプリケートされるまでの間に常に遅延があります。 プライマリ リージョンが使用できなくなった場合、最新の書き込みがまだセカンダリ リージョンにレプリケートされていない可能性があります。

強制的にフェールオーバーを行うと、セカンダリ リージョンが新しいプライマリ リージョンになり、ストレージ アカウントがローカル冗長に構成されるため、プライマリ リージョンのデータはすべて失われます。 フェールオーバーが発生した時点でセカンダリに既にレプリケートされているデータはすべて維持されます。 ただし、プライマリに書き込まれたデータのうち、セカンダリにレプリケートされていなかったものは、永久に失われます。

またフェールオーバー後、元セカンダリ(フェールオーバー後のプライマリ)はローカル冗長(LRS)に構成されるので、再度GRSまたはRA-GRSに構成しなおすとレプリケーションに関する費用が発生するのも注意が必要です。(※元プライマリは無くなるので)

その他注意事項はドキュメントにある通りですが簡単に挙げておきます。

  • Azure VM … VMはフェールオーバーされません。
  • Unmanaged Disks … Blobの一部ですが利用された状態のままだとフェールオーバーできません(VMをシャットダウンするなりしておく必要があります)
  • Azure File Syncはフェールオーバーをサポートしていません。同期の停止・データの損失などの可能性があるのでFile Syncを含むストレージアカウントはフェールオーバーしないようにしましょう。
  • Data Lake Storage Gen2の階層型名前空間を使っている場合フェールオーバーできません。
  • アーカイブ済みBlobを含むストレージアカウントはフェールオーバーできません。
  • Premium Block Blobを含むストレージアカウントはフェールオーバーできません。(※現時点でPremium Block BlobをサポートするストレージアカウントはそもそもGRSがサポートされてない)

あとRA-GRSを使っている場合、セカンダリで読み取りできるので利用方法によってはフェールオーバーするよりRA-GRSでセカンダリを読み取るにとどめるなりするほうが良いかもしれません。

Microsoftがフェールオーバーを行う場合がありますが(大規模障害など。今まで一度もないはず)、この場合利用者は何もする必要がありません。またMicrosoft管理のフェールオーバーが完了するまでストレージへの書き込みアクセスは不可となります。(RA-GRSの場合はセカンダリで読み取りは可)

という感じで手動ならではの自身が負うリスクや課題はありますが、それらを理解したうえであればストレージのフェールオーバーは大規模なDRの役に立つでしょう。

Previewの登録

まだこの機能はPreviewなので、事前準備が必要です。以下のようにフェールオーバー用のプロバイダーを登録しましょう。

Register-AzureRmProviderFeature -FeatureName CustomerControlledFailover -ProviderNamespace Microsoft.Storage

機能が承認されて有効化されるまでしばらく(数日?)かかります。

フェールーバーのやり方

対象リージョンでGRS/RA-GRSでストレージを作成するとポータル上のブレードのGeo-replicationで以下のような見た目になります。

image

プロバイダーが登録されていると「Prepare for failover (preview)」ボタンを有効になっています。これクリックすると確認画面のあとフェールオーバーします。簡単ですね。Azure PowerShellやAzure CLI、REST APIでも利用可です。

動作確認

いちおうフェールオーバー前の状態を見ておきます。nslookupの実行結果はこんな感じ。
image

プライマリはWest US 2のIPアドレスです。
image

ポータル上でフェールオーバーを実行すると確認画面がでます。Last Syncも出してくれるあたり便利ですね。
imageimage
完了するまでは意外と時間がかかります。
処理開始後、しばらくするとプライマリもセカンダリもアクセス不可になります。セカンダリはそのうち権限がないぽいエラーになりDNSで正引きもできなくなります。だいたい15分あれば完了します。(大半はDNSの反映待ちな気がするな)

完了後のnslookupはこんな感じでプライマリのリージョンが変わってることがわかります。
image
image

フェールオーバー後は元セカンダリがプライマリとなりLRSになります。(切り替えて元プライマリを外した感じ)
image

Last Syncの取得

プライマリからの最終同期時刻であるLast Syncの取得はStorage SDKを使って取得すると楽です。REST APIを使ってセカンダリのエンドポイントにアクセスすることで取得することもできますがSharedKeyの署名とか面倒です。C#で書くならStorage SDK使うほうがいいですね。。
image

まとめ

利用は用量用法を守ってお使いください。システムの構成やフェールオーバーの効果や影響については十分に吟味して使いましょう。
とはいえコントロールできる余地が増えるのは良いのかも知れません。難しいけど。

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト /  変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト /  変更 )

%s と連携中