こんにちは、アーキテクトのやまぱんです。
Azure ストレージ アカウント のフェールオーバについてまとめてみます。
MS Learn でいうとこのあたりに記載されています。
- Azure ストレージのディザスター リカバリー計画とフェールオーバー
補足コメントや質問、いいね、拡散、是非お願いします🥺！
間違ってたら優しく教えてください！
きっかけ
ストレージ アカウントのフェールオーバについて調べる機会があったので、せっかくなのでまとめてみます。
手動で構成するとすると大変なので、本当クラウドストレージ万歳って感じです（いまさら）🙌
ストレージ アカウント のフェールオーバの概要
ストレージ アカウントのフェールオーバはストレージ アカウントの設定で冗長性が GRS か RA-GRS の場合に利用することができます。リージョン障害が発生した場合 Azure 基盤側によしなに(マネージドで)フェールオーバすることができます。
GRS と RA-GRS ストレージの違い
RA-GRS の RA は Read Access でジオリージョンの読み取りアクセスを提供します。
具体的にフェールオーバーの観点でいえば、GRS の場合はフェールオーバーを実施しないとセカンダリーリージョンのデータにアクセスできないのに対して、RA-GRS の場合はフェールオーバーしなくてもセカンダリーリージョンのデータにアクセスすることができます。
その他、GRS や RA-GRS に関するデータの持ち方などに関しては下記の MS Learnを見てみてください
- geo 冗長ストレージ - MS Learn
https://learn.microsoft.com/ja-jp/azure/storage/common/storage-redundancy
セカンダリーリージョンの読み取り専用エンドポイントを確認する
- RA-GRS の場合の表示
以下のように読み取り専用の エンドポイントが表示される。
以下は blob ストレージの場合の例。
<ストレージ アカウント名>-secondary.blob.core.windows.net
たとえば、BLOB ストレージのプライマリ エンドポイントが myaccount.blob.core.windows.net の場合、セカンダリ エンドポイントは myaccount -secondary.blob.core.windows.net になります。
ストレージ アカウント → 冗長性 → ストレージ エンドポイント → セカンダリ〇〇エンドポイント
- GRS の場合の表示
比較のために、GRS の場合も見てみましょう。
リージョンレプリケーションの同期間隔
- 非同期レプリケーション
- 同期間隔は数分 (15分未満) 、ただし SLA は設定されていない。
- 現在レプリケーションが走っているか、完了しているかを確認する方法はない（もしあったら教えてください）
プライマリ リージョンへの最新の書き込みと、セカンダリ リージョンへの最後の書き込みとの間隔は、回復ポイントの目標 (RPO) と呼ばれます。 RPO は、データを復旧できる対象の時点を示します。 現在、データをセカンダリ リージョンにレプリケートするのにかかる時間に関する SLA はありませんが、Azure Storage プラットフォームでは通常、RPO は 15 分未満となります。
フェールオーバーの種類
大きく３つの種類があります。
- フェールオーバーの計画
https://learn.microsoft.com/ja-jp/azure/storage/common/storage-disaster-recovery-guidance#plan-for-failover
ざっくりまとめると以下のような感じです。
カスタマーマネージド計画フェールオーバー（プレビュー）
- 平常時に行うことができ、フェールオーバーのテストに利用できるフェールオーバー
- データが失われることはない
- 元のプライマリ リージョン内のデータのコピーが保持され、geo 冗長が維持されます。
- カスタマー マネージド計画フェールオーバーは現在プレビュー段階であり、次のリージョンに限り提供されます。
フランス中部 / フランス南部/ インド中部 / インド西部 / 東アジア/ 東南アジア
・顧客が管理する計画フェールオーバー (プレビュー)
https://learn.microsoft.com/ja-jp/azure/storage/common/storage-disaster-recovery-guidance#customer-managed-planned-failover-preview
カスタマーマネージド計画外フェールオーバー
- 問題が発生した時に行うフェールオーバー
- 元のプライマリ リージョン内のデータのコピーが削除され、geo 冗長が失われ、LRS(GZRSの場合はZRS)になります。ただし、再有効化後には冗長性を戻すことが可能。
- データが失われる可能性あり。(プライマリのリージョンのデータが削除されるのでレプリケーションが完了していないデータは失われる)
カスタマーマネージドフェールオーバーは以下のように実施することが可能
MS 管理のフェールオーバー
- リージョン全体に及ぶような大規模な障害が発生した場合に MS が手動で行うフェールオーバー
- プライマリ リージョンは利用できなくなりますが、セカンダリ リージョンは利用できます。
- 以下のように記載あり、こちらに依存するのは推奨されない。
Microsoft が管理するフェールオーバーに依存しないでください。これは、やむを得ない場合にのみ使用されます。
エンドポイントのフェールオーバー
今回の post で最もクラウドストレージ万歳っていうところです。
ストレージ アカウントがフェールオーバーされると、エンドポイントが書き換わり(ＤＮＳ)クライアント(ストレージ アカウントを利用する側)からは同じURL(エンドポイント)を利用して引き続き、フェールオーバー後のストレージ アカウントにアクセスできるようになる。
パブリックアクセスの場合はパブリックな名前解決ができていれば特に考慮事項はないが、プライベート エンドポイントを利用している場合にはあらかじめ準備が必要。
ストレージ アカウントのサービス エンドポイントの DNS (ドメイン ネーム システム) エントリは、フェールオーバー プロセスの間に、セカンダリ リージョンのエンドポイントが新しいプライマリ エンドポイントになるように自動的に更新されます。
・GRS とフェールオーバー
https://learn.microsoft.com/ja-jp/azure/storage/common/storage-disaster-recovery-guidance#geo-redundant-storage-and-failover
パブリックエンドポイントを利用している場合
上述の通り、特段の設定変更なく、引き続きおなじURLを用いて利用可能。
プライベート エンドポイントを利用している場合
プライベート エンドポイントをあらかじめフェールオーバー先のリージョン(セカンダリリージョン)に作成しておき、プライマリのエンドポイントに対してフェールオーバー先のリージョンに作成したプライベート エンドポイント経由で通信できるようにしおく必要がある。つまり、事前にプライベート エンドポイントが２つ必要(プライマリリージョンのプライベート エンドポイントとセカンダリリージョンのプライベート エンドポイント)。
フェールオーバー時にはセカンダリリージョンに設置したプライベート エンドポイントの宛先がフェールオーバーされたセカンダリのストレージ アカウントに切り替わる。
（プライマリリージョンが大きな災害を受けた時にはストレージ アカウントだけではなくプライマリのプライベート エンドポイントなども利用できなくなる想定だが、もしプライマリのプライベート エンドポイントが生きている場合は引き続きプライマリのプライベート エンドポイントからフェールオーバーしたセカンダリのストレージ アカウントにアクセスができる）