ストレージサービスの地理冗長 (GRS) の障害時の挙動について


皆さんこんにちは。Azure テクニカルサポートの平原です。本日は、時々皆様からご質問をいただくストレージサービスの GRS の障害時の挙動についてご紹介をいたします。

目次

  • 地理冗長 (GRS) とローカル冗長 (LRS) の違い
  • 地理冗長の障害時の挙動
  • ディザスタリカバリ (DR) サイトの構築

 

地理冗長 (GRS) とローカル冗長 (LRS) の違い

まず事前段階として、「地理冗長」と「ローカル冗長」の違いについて説明をいたします。

ローカル冗長 (LRS)

「ローカル冗長」とは、1つのリージョン内でデータを冗長化する方法です。ローカル冗長の場合、同一拠点内にコピー(レプリカ)を3つ保持します。この3つのデータは別々の障害ドメイン(フォールトドメイン)に配置され、単一障害点が分離されています。万一3つのうち1つのデータ消失した場合には、残りのものから復帰をします。

例として、東日本にストレージアカウントを1つ作成し、データを配置した場合を考えます。ストレージサービスの内部では分散ファイルシステム (DFS) が構築されており、そのデータは内部で3つのレプリカが作成され、ユーザーの見えないところで自動的に冗長化が図られています。ユーザーがあるデータの書き込みを行った場合には、3つのレプリカへの書き込みが成功してから、書き込みが成功します。読み込みの場合には、3つのうちのいづれかのレプリカから読み込みが行われています。

地理冗長 (GRS)

「地理冗長」とは、ストレージアカウントのあるリージョンと対になるリージョンにもレプリカを保持する方法です。対になるリージョンは事前に決まっており、例えば「東日本」の場合は「西日本」といった形です。ストレージアカウントに設定されているリージョンをプライマリリージョンと言い、対になるリージョンをセカンダリリージョンと言います。プライマリリージョンにデータを保存する方法は、「ローカル冗長」と同じです。地理冗長では、それに加えて、セカンダリリージョンにも、障害ドメインを考慮してレプリカを3つ配置します。1つ注意点としては、セカンダリリージョンへのデータのレプリケーションは非同期に行われる点です。そのため、データの書き込み直後では、プライマリリージョンとセカンダリリージョン間のレプリカのデータ同期については時間差があります。(通常は15分未満程度ですが、SLAの設定はありません) また、値段面では、地理冗長の方がデータ量が多くなるため、地理冗長の方がローカル冗長よりも若干値段が高く設定されています。

例として、東日本にストレージアカウントを1つ作成した場合を考えましょう。1つファイルを配置した場合を考えると、東日本に3つのレプリカが配置され、西日本に3つのレプリカが配置されます。ただし書き込み処理は、東日本での3つのレプリカの書き込みが完了した時点で完了し、西日本へのレプリカの書き込みはそのあと非同期で行われます。

各冗長化については、以下のドキュメントが参考になります。

 

補足

これ以外にも「読み取りアクセス地理冗長」もありますが、通常の地理冗長との違いは、セカンダリーからもデータの読み込みが可能なことです。これを使うことで、例えばアプリケーションのファイルの読み取り作業などで、一時的にプライマリリージョンが利用できないときにも、セカンダリーからデータが読み込めるため、データ読み取りの可用性を上げることが可能です。(これを利用するためにはアプリケーション側への実装が必要になります。)

 

地理冗長の障害時の挙動

地理冗長は、何らかの天災(地震、大火災、大規模破壊)があった場合に備えて、データロスを防ぐものです。それでは、何らかの天災があった場合に、地理冗長ではどのようにデータを復旧するのでしょうか?ここでは例として、東日本に、地理冗長設定のストレージアカウントを作り、その内部にデータがあるとし、東日本で何らかの大災害が発生した場合を考えましょう。

大災害により、データセンターに影響が出た場合でも、マイクロソフトは復旧の余地がある限り、まずはプライマリ拠点での復旧を検討します。もし復旧の余地があり復旧ができる場合にはマイクロソフトは全力で復旧に取り組みを行います。マイクロソフト側で諸々検討をした結果、どうしても復旧ができない場合には、セカンダリリージョンへのフェールオーバーを検討等します。フェールオーバーが妥当だと判断された場合に、ストレージアカウントのフェールオーバーが実施されます。このフェールオーバーは、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が割り振られます

このため、通常時の URL (“http://<ストレージアカウント>.blob.windows.net/フォルダー名/VHD名.vhd” など) をそのままご利用いただくことができ、ストレージの切り替えにあたり、お客様側で必要な作業は特にございません。

この地理冗長におけるフェールオーバーのタイミングは、事前に予期できない大災害を想定しており、状況によって大きくかわるため、復旧までの時間は決まっていません(ただしマイクロソフトとしては可能な限り早い復旧を試みます)。またフェールオーバーのタイミングで、セカンダリが新しいプライマリとなります。ここで、新たなセカンダリが、フェールオーバーのタイミングで決定され設定されます。この新しいセカンダリは状況に応じて地理的に近いものが選択されます。例えば、日本リージョンの場合には、東アジアや東南アジアが選ばれることが想定されます.

 

補足

ストレージ GRS は、ストレージの機能になるため、プライマリ拠点からセカンダリ拠点にデータコピー (レプリカ作成) されるのは、ストレージ アカウント内の VHD ファイルのみとなります。

そのため、何らかの大障害によるフェールオーバーが発生し、プライマリが切り替わった際には、
コピーしてある VHD ファイルをもとに仮想マシンなどの環境を再構成していただく必要がございます。

VHD ファイルに保存されているのは、仮想マシンのディスクのデータのみとなりますので、
IP アドレスなどのリソースは、障害発生の復旧のタイミングにて、
仮想マシン作成時に新たに設定しなおしていただく必要がございます。
また、仮想ネットワークなどの、仮想マシンに紐づいている各種リソースに関しても、 同様に再作成が必要となります。

ディザスタリカバリ (DR) サイトの構築

ストレージサービスの大災害の場合、上記の通りの挙動となります。上記記載の通り、注意点としては、予期できない大災害時においては、マイクロソフトとしても可能な限りの復旧の手を尽くしますが、復旧までの時間は決まっていません。地理冗長の場合、対となるリージョンにデータの保持はしております。しかし、地理冗長は大災害時のデータロスに備えたものであり、早急な復旧を目的としたものではないため、上記の通り状況によっては早急な復旧はできない可能性があります。

大災害時においても、基幹業務 (LOB) アプリケーションのより高度な可用性が必要な場合には、別リージョンにも DR サイトの配置を事前にしておくことをお勧めいたします。サーバーが Web サービス・アプリケーションの場合には、トラフィックマネージャを使うことで、アクティブ・アクティブスタンバイも可能です。また、DRサイトを一時的に休眠状態にしておき、問題発生時に起動をする、コールドスタンバイも可能かと思います。

サーバーがデータベースなどの固有データを持っている場合は、本番サーバー・DR サーバー間でデータの定期的なレプリケーションや、定期的なバックアップなどを検討しないといけません。これは利用するアプリケーション・シナリオにより異なり、もう少し状況が複雑になります。こちらは、お客様の要件に合わせて、シナリオに沿った復旧プランなどを検討をする必要があります。

Comments (1)

  1. Junya Yamaguchi より:

    Blogに掲載して頂き、ありがとうございます。

Skip to main content