Windows Azure StorageのGeo-Replicationの紹介

2011-09-172012-05-04

「Windows Azureストレージのジオ・レプリケーションの紹介」を意訳したものです。が、トランザクション整合性の項後半部分は、Blobの知識が無さ過ぎて日本語になっていません。あしからず。

Windows Azure ブロブとテーブルデータのジオ・レプリケーション（地理的複製）を始めたことを発表できて、とても嬉しい。追加コスト無しで、同じリージョン内の100マイル離れた2つのロケーション（拠点）間（例：北アメリカと南アメリカ、北ヨーロッパと西ヨーロッパ、東アジアと南アジア）でレプリケーションをする。ジオ・レプリケーションは、データセンター災害時のデータ耐久性を提供する。

 

耐久性のため、2つの拠点にデータを保存する

ジオ・レプリケーションによって、Windows Azureストレージは2つの拠点でデータ耐久性を守る。両拠点で、 Windows Azure Storageは常にデータを複製し正常状態を維持する。

データの参照、作成、更新、削除をする拠点は、プライマリロケーションと呼称される。 Azureポータルでアカウントを作成した際に選択したリージョンに、プライマリロケーションが存在する（例えば、北アメリカ）。

データがジオ・レプリケーションされる拠点をセカンダリロケーションと呼称される。セカンダリロケーションは、プライマリロケーションを元に自動的に決定する。同じリージョン内の、プライマリとは別のデータセンターがセカンダリになる。

この例では、セカンダリは南中央アメリカに配置される。プライマリロケーションは、Azureポータルで表示される。将来的に、Azureポータルをアップデートし、プライマリ、セカンダリロケーション両方を見れるようになる。Azureポータルでストレージアカウントのプライマリロケーションを見るために、アカウントをクリックする。プライマリリージョンは、右下の国/地域の下に表示される。

 

次の表は、プライマリとセカンダリロケーションの組み合わせを示している。

Primary	Secondary
North Central US	South Central US
South Central US	North Central US
North Europe	West Europe
West Europe	North Europe
South East Asia	East Asia
East Asia	South East Asia

ジオ・レプリケーションの価格と無効化について

ジオ・レプリケーションは、現在のAzureストレージの価格に含まれている。もし、データをジオ・レプリケーションしたくない場合は、ジオ・レプリケーションを無効化できる。ジオ・レプリケーションを停止するために、Microsoft Windows Azure Supportに連絡していただきたい。ジオ・レプリケーションをオフにしても、価格を下げることはできない。

ジオ・レプリケーションをオフにしたとき、セカンダリロケーションからデータが削除される。ジオ・レプリケーションをオフにした後、ジオ・レプリケーションを有効化することにした場合、ストレージアカウントのジオ・レプリケーションを始めるために、プライマリからセカンダリロケーションへ既存のデータをコピーする際の再同期のネットワーク量が、データ転送レートに基づいて課金される。この課金は、ジオ・レプリケーションをオフにした後、再度ジオ・レプリケーションをオンにする時のみ適用される。準備が完了した後、ジオ・レプリケーションを維持する際のトラフィックは追加課金されない。

今のところ、全てのストレージアカウントは、プライマリとセカンダリストレージロケーション間でジオ・レプリケーションモードで、準備が完了しジオ・レプリケーションが始まっている。

ジオ・レプリケーションの動作方法

ストレージのデータ作成や削除、更新をしたとき、プライマリロケーション内で3つの更新ドメインと障害ドメイン間で、異なる３つのストレージノードにレプリケーション(英語参考)される。トランザクションで3つレプリケーションに成功するとクライアントに成功として返ってきます。

裏側で、プライマリロケーションからコミットされたトランザクションをセカンダリロケーションへ非同期にレプリケーションする。セカンダリロケーション内でもデータ耐久性のため、異なる障害・更新ドメインで3つのストレージノードにレプリケーションする。非同期にジオ・レプリケーションするのは、ストレージアカウントの既存の性能に変化を及ぼさないようにするためである。

目的は、プライマリ、セカンダリロケーションの両方でデータ耐久性を維持することである。両方のロケーションで、レプリケーションするのは、それぞれのロケーションで遭遇する（ディスクやノード、ラック、TOR障害などの）共通的な障害から、他のロケーションと通信せずに復旧できるようにするためである。

2つの拠点間の通信は、最新のアップデート分をジオ・レプリケーションする時のみである。一般的な障害が原因で、データをリカバリする際には、もう一つのロケーションと通信する必要はない。これは重要なことだ。プライマリからセカンダリにストレージアカウントがフェイルオーバーした場合、すでにデータ耐久性のためにジオ・レプリケーションされているのでセカンダリロケーションにコミットされたデータがすべてあることを意味する。

今回のジオ・レプリケーションのファーストリリースでは、データがどれぐらいでジオ・レプリケーションされるかのSLAを提供していない。通常は、プライマリロケーションでデータがコミットされてから数分でジオ・レプリケーションされる。

ジオ・フェイルオーバーの動作方法

プライマリロケーションに影響のある大災害が発生した場合、まず最初にプライマリロケーションにリストアを試みる。重大な影響のある自然災害や、いくつかのめったに起こらない自称によりプライマリロケーションにリストアすることができない場合、ジオ・フェイルオーバーを実行する必要がある。このような事態になったとき、影響のある顧客にサブスクリプションの連絡情報に通知する。（現在、この通知をよりプログラム化するための調査をしているところである。）フェイルオーバーの中で、顧客の“account.service.core.windows.net”DNSエントリーはプライマリロケーションからセカンダリロケーションを返すよう更新する。DNSの変更が伝搬すれば、既存のブロブとテーブルURIが動作するようになる。これは、アプリケーションのURIを変更する必要がないことを意味する。既存のすべてのURIはジオ・フェイルオーバー前後で同じ動作をする。

たとえば、ストレージアカウント“myaccount” のプライマリロケーションを北中央アメリカに設定すると、myaccount.<service>.core.windows.net のDNSエントリは北中央アメリカへトラフィックを誘導する。もし、ジオ・フェイルオーバーに成功すると、myaccount.<service>.core.windows.net DNSエントリーは更新され、すべてのトラフィックを南中央アメリカへ誘導する。

フェイルオーバー発生後、セカンダリとして使用されていたロケーションは、別のジオ・フェイルオーバーが発生するまで新しいプライマリロケーションとなる。さらに、ストレージアカウントが新しいプライマリにフェイルオーバーした後、同じリージョン内に新しいセカンダリロケーションの準備を始める。

将来的には、（リージョン内に２つ以上のDCが準備されたとき）セカンダリロケーションを選択できるようにする計画である。

ジオ・レプリケーションの順番とトランザクション整合性について

ジオ・レプリケーションは、パーティションキー内のすべてのデータは、プライマリロケーションでコミットされた順番で、セカンダリロケーションに反映することが保障されている。これは、パーティション間では、ジオレプリケーションする順番を保証していないと言える。異なるパーティションは異なるスピードでジオ・レプリケーションすることを意味する。しかしながら、すべての更新が、セカンダリロケーションでジオ・レプリケートされ、コミットされると、セカンダリロケーションはプライマリロケーションと同じ状態となる。しかし、ジオ・レプリケーションは非同期なので、大災害で、直近の更新が失われる可能性がある。

たとえば、次のようなケースを考えてみる。2つのブロブとして、「foo」と「bar」を持っているとする。
ブロブ「foo」にトランザクションAとBを実行し、ブロブ「bar」にトランザクションXとYを実行する。トランザクションBの前にトランザクションAがジオ・レプリケーションされることが保障され、トランザクションYの前にトランザクションXがジオ・レプリケーションされることが保障される。しかし、「foo」に対するトランザクションと「bar」に対するトランザクション間のジオ・レプリケーションのそれぞれのタイミングについては何も保障されない。

もし災害が発生し、それが原因でトランザクションがジオ・レプリケーションされたなっかた場合、トランザクションAとXがジオ・レプリケーションされ、トランザクションBとYが失われる可能性がある。または、トランザクションAとBがジオ・レプリケーションされ、トランザクションXもYもジオ・レプリケーションされない可能性がある。他の組み合わせもありえる。保障されるのは、同じブロブのジオ・レプリケーションの順番のみ保障される。ブロブ名の代わりにエンティティのパーティションキーが定義されるアプリケーションによって決まるパーティションを除いて、テーブルを含む操作の順番です。パーティションキーの詳細は、Windows Azure Storage Abstractions and their Scalability Targetsを参照していただきたい。

このため、ジオ・レプリケーションを活用するベストな方法は、可能な時はいつでもパーティションキーをまたがるリレーションシップを避けることだ。同じパーティションキーの値をもつテーブルのリレーションシップのみを使用すべきである。単一のパーティションキー内のすべてのトランザクションは順番にジオ・レプリケーションされるので、セカンダリ上で、順番にコミットされることが保障される。

Windows Azureストレージによってサポートされている唯一の複数オブジェクトのトランザクションは、Windows Azureテーブルのエンティティグループトランザクションです。ジオ・レプリケーションは、このバッチを自動的に実行する。それゆえに、すべてのバッチトランザクションはセカンダリ上で自動的にコミットされる。

まとめ

これは、データセンターでの災害時のデータ耐久性を提供するジオ・レプリケーションの最初のステップです。次のステップは、フェイルオーバー後、現在調査中の分野ですが、アプリケーションリカバリを支援するのに必要な機能を提供することです。