皆さんこんにちは。Azure テクニカルサポートの平原です。本日は、時々皆様からご質問をいただくストレージサービスの GRS の障害時の挙動についてご紹介をいたします。
目次
- 地理冗長 (GRS) とローカル冗長 (LRS) の違い
- 地理冗長の障害時の挙動
- ディザスタリカバリ (DR) サイトの構築
地理冗長 (GRS) とローカル冗長 (LRS) の違い
まず事前段階として、「地理冗長」と「ローカル冗長」の違いについて説明をいたします。
ローカル冗長 (LRS)
「ローカル冗長」とは、１つのリージョン内でデータを冗長化する方法です。ローカル冗長の場合、同一拠点内にコピー（レプリカ）を３つ保持します。この３つのデータは別々の障害ドメイン（フォールトドメイン）に配置され、単一障害点が分離されています。万一３つのうち１つのデータ消失した場合には、残りのものから復帰をします。
例として、東日本にストレージアカウントを１つ作成し、データを配置した場合を考えます。ストレージサービスの内部では分散ファイルシステム (DFS) が構築されており、そのデータは内部で３つのレプリカが作成され、ユーザーの見えないところで自動的に冗長化が図られています。ユーザーがあるデータの書き込みを行った場合には、３つのレプリカへの書き込みが成功してから、書き込みが成功します。読み込みの場合には、３つのうちのいづれかのレプリカから読み込みが行われています。
地理冗長 (GRS)
「地理冗長」とは、ストレージアカウントのあるリージョンと対になるリージョンにもレプリカを保持する方法です。対になるリージョンは事前に決まっており、例えば「東日本」の場合は「西日本」といった形です。ストレージアカウントに設定されているリージョンをプライマリリージョンと言い、対になるリージョンをセカンダリリージョンと言います。プライマリリージョンにデータを保存する方法は、「ローカル冗長」と同じです。地理冗長では、それに加えて、セカンダリリージョンにも、障害ドメインを考慮してレプリカを３つ配置します。１つ注意点としては、セカンダリリージョンへのデータのレプリケーションは非同期に行われる点です。そのため、データの書き込み直後では、プライマリリージョンとセカンダリリージョン間のレプリカのデータ同期については時間差があります。(通常は１５分未満程度ですが、SLAの設定はありません) また、値段面では、地理冗長の方がデータ量が多くなるため、地理冗長の方がローカル冗長よりも若干値段が高く設定されています。
例として、東日本にストレージアカウントを１つ作成した場合を考えましょう。１つファイルを配置した場合を考えると、東日本に３つのレプリカが配置され、西日本に３つのレプリカが配置されます。ただし書き込み処理は、東日本での３つのレプリカの書き込みが完了した時点で完了し、西日本へのレプリカの書き込みはそのあと非同期で行われます。
各冗長化については、以下のドキュメントが参考になります。
- Windows Azure ストレージでのローカル冗長ストレージの提供
https://blogs.msdn.microsoft.com/windowsazurej/2012/06/12/windows-azure-37/ - Windows Azure ストレージの冗長オプションと読み取りアクセス地理冗長ストレージ
https://blogs.msdn.microsoft.com/windowsazurej/2013/12/19/windows-azure-5/ - Azure Storage のレプリケーション
https://azure.microsoft.com/ja-jp/documentation/articles/storage-redundancy/
補足
これ以外にも「読み取りアクセス地理冗長」もありますが、通常の地理冗長との違いは、セカンダリーからもデータの読み込みが可能なことです。これを使うことで、例えばアプリケーションのファイルの読み取り作業などで、一時的にプライマリリージョンが利用できないときにも、セカンダリーからデータが読み込めるため、データ読み取りの可用性を上げることが可能です。（これを利用するためにはアプリケーション側への実装が必要になります。）
地理冗長の障害時の挙動
地理冗長は、何らかの天災（地震、大火災、大規模破壊）があった場合に備えて、データロスを防ぐものです。それでは、何らかの天災があった場合に、地理冗長ではどのようにデータを復旧するのでしょうか？ここでは例として、東日本に、地理冗長設定のストレージアカウントを作り、その内部にデータがあるとし、東日本で何らかの大災害が発生した場合を考えましょう。
大災害により、データセンターに影響が出た場合でも、マイクロソフトは復旧の余地がある限り、まずはプライマリ拠点での復旧を検討します。もし復旧の余地があり復旧ができる場合にはマイクロソフトは全力で復旧に取り組みを行います。マイクロソフト側で諸々検討をした結果、どうしても復旧ができない場合には、セカンダリリージョンへのフェールオーバーを検討等します。フェールオーバーが妥当だと判断された場合に、ストレージアカウントのフェールオーバーが実施されます。このフェールオーバーは、IPアドレスがプライマリリージョンの IP からセカンダリリージョンへの IP の切り替えで実施されます。
ブロブエンドポイントの例
xxxxx.blob.core.windows.net (123.xxx.xxx.xxx) ⇒ xxxxx.blob.core.windows.net (222.yyy.yyy.yyy) # 123.xxx.xxx.xxx が東日本、222.yyy.yyy.yyy が西日本 # テーブル、キュー、ファイルストレージもそれぞれ別のIPが割り振られていますが、それぞれ対応する西日本のIPが割り振られます
この地理冗長におけるフェールオーバーのタイミングは、事前に予期できない大災害を想定しており、状況によって大きくかわるため、復旧までの時間は決まっていません(ただしマイクロソフトとしては可能な限り早い復旧を試みます)。またフェールオーバーのタイミングで、セカンダリが新しいプライマリとなります。ここで、新たなセカンダリが、フェールオーバーのタイミングで決定され設定されます。この新しいセカンダリは状況に応じて地理的に近いものが選択されます。例えば、日本リージョンの場合には、東アジアや東南アジアが選ばれることが想定されます。
ディザスタリカバリ (DR) サイトの構築
ストレージサービスの大災害の場合、上記の通りの挙動となります。上記記載の通り、注意点としては、予期できない大災害時においては、マイクロソフトとしても可能な限りの復旧の手を尽くしますが、復旧までの時間は決まっていません。地理冗長の場合、対となるリージョンにデータの保持はしております。しかし、地理冗長は大災害時のデータロスに備えたものであり、早急な復旧を目的としたものではないため、上記の通り状況によっては早急な復旧はできない可能性があります。
大災害時においても、基幹業務 (LOB) アプリケーションのより高度な可用性が必要な場合には、別リージョンにも DR サイトの配置を事前にしておくことをお勧めいたします。サーバーが Web サービス・アプリケーションの場合には、トラフィックマネージャを使うことで、アクティブ・アクティブスタンバイも可能です。また、DRサイトを一時的に休眠状態にしておき、問題発生時に起動をする、コールドスタンバイも可能かと思います。
サーバーがデータベースなどの固有データを持っている場合は、本番サーバー・DR サーバー間でデータの定期的なレプリケーションや、定期的なバックアップなどを検討しないといけません。これは利用するアプリケーション・シナリオにより異なり、もう少し状況が複雑になります。こちらは、お客様の要件に合わせて、シナリオに沿った復旧プランなどを検討をする必要があります。