S10 日本東西リージョンでのディザスタリカバリ環境の実現

本ドキュメントの更新について
• 以下の日付でドキュメントを更新、確認しています。
2
バージョン
1.00 2015/2/28 ・初版リリース

目次
• 概要
• ストレージ
• コンピューティング
• SQL Database
• シナリオ
3

ディザスタリカバリとは
• 災害などによりデータセンター全体または一部の機能が停止した場合
に、その被害を最小限に抑える対策をすること。
• 一般的なバックアップでは、退避したデータは同一のデータセンター
内に保管されることが多い。
その場合、地震・火災・浸水などにより、運用環境のデータと共に退
避したメディアも利用できなくなってしまう。
このような状況でもシステムの運用が継続できるよう、地理的に離れ
た場所にデータを退避し、また、データのみならずシステムが稼働し
ているサーバー環境もほぼ同一のものを用意しておくことで、短時間
の停止でシステムの運用を再開することができる。
5

世界中のMicrosoft Azureデータセンター
6
日本東西DCを含む
世界中に展開されています。
• オーストラリア構築中
• 中国は21Vianet社により運営
http://azure.microsoft.com/ja-jp/regions/

Microsoft Azure のディザスタリカバリ機能
Microsoft Azure ではサービスごとにディザスタリカバリに活用でき
る機能を持っています。
• Storage
• コンピューティング
• SQL Database
7

Storage のディザスタリカバリ
ストレージは4種類の冗長構成を選択することができる。
• 地理冗長ストレージ（GRS = Geo Redundant Storage）
• 読み取りアクセス地理冗長ストレージ
（RA-GRS = Read Access - Geo Redundant Storage）
• ゾーン冗長ストレージ for Block Blobs
（ZRS = Zone Redundant Storage for Block Blobs）
• ローカル冗長ストレージ（LRS = Local Redundant Storage）
※ この内、ローカル冗長ストレージは同じ施設内での冗長化のため、
ディザスタリカバリを目的とするものではない。
9

リージョンの組み合わせ
• GRS、RA-GRS では、ユーザーが指定したリージョンをプライマリ
拠点としてデータを保存し、セカンダリ拠点となる同一地域のもう一
方のリージョンに、そのデータを非同期に複製
• プライマリ拠点とセカンダリ拠点の組み合わせ
10
東日本西日本
東アジア東南アジア
米国中北部米国中南部
米国西部米国東部
米国中部米国東部 2
北ヨーロッパ西ヨーロッパ
ブラジル南部（※）米国中南部
オーストラリア西部オーストラリア東部
中国北中国東

地理冗長ストレージ（GRS）#1
• BLOB、テーブル、キューのデータを、プライマリ拠点から何百キロ
も離れた場所にあるセカンダリ拠点に複製
• プライマリ拠点で大災害が発生し復旧ができない場合、セカンダリ拠
点にフェールオーバーされる。その際、ストレージの DNS エントリ
“アカウント名.<service>.core.windows.net” がプライマリ拠点か
らセカンダリ拠点を指すように自動で更新される。
11
BLOB
Table
Queue
日本(東)
BLOB
Table
Queue
日本(西)
アカウント名.<service>.core.windows.net
BLOB
Table
Queue
日本(東)
BLOB
Table
Queue
日本(西)
アカウント名.<service>.core.windows.net

地理冗長ストレージ（GRS）#2
• プライマリ拠点への書き込みが完了した後、そのデータが非同期でセ
カンダリ拠点に複製
• トランザクションは非同期で複製されるため、プライマリ拠点には複
製によるアプリケーションへの影響はない。
• 非同期による複製のため、プライマリ拠点とセカンダリ拠点では若干
の差分がある。
• セカンダリ拠点のデータは、プライマリ拠点で災害が発生しフェール
オーバーしてセカンダリ拠点に DNS エントリが割り当てられるまで、
ユーザーは参照することができない。
• SLA：99.9%
12
http://blogs.msdn.com/b/windowsazurej/archive/2013/12/19/blog-windows-azure-storage-redundancy-options-and-read-access-geo-redundant-storage.aspx

読み取りアクセス Geo 冗長ストレージ（RA-GRS）
• 地理冗長ストレージと同様に、プライマリ拠点からセカンダリ拠点に
データが複製される
• セカンダリ拠点のデータには読み取り専用でいつでもアクセスできる。
そのエンドポイントは、プライマリ拠点のアカウント名に
接尾辞「-secondary」を付与したものになる。
• SLA:
13
BLOB
Table
Queue
日本(東)
BLOB
Table
Queue
日本(西)
アカウント名.<service>.core.windows.net アカウント名-secondary.<service>.core.windows.net
(読み取りのみ)(読み書き)

ゾーン冗長ストレージ（ZRS）
• 複数のゾーン（施設）に渡ってデータを3重化
• 1つのリージョンあるいは2つのリージョンに渡る
• ブロック BLOB のみをサポート（ページ BLOB、テーブル、キュー
は対象外）
• 施設における火災などへの耐久性を向上する
14

ローカル冗長ストレージ（LRS） ※参考
• 同じ拠点内の 3 つのストレージノードに、トランザクションを同時
に複製することにより、ストレージアカウントのすべてのデータの
耐久性を確保
• 異なる障害ドメイン、異なる更新ドメインのノードに複製
• このストレージはディザスタリカバリではないが、RA-GRS、GRS、
ZRSいずれも、各拠点内では LRS と同様に 3 つのストレージのノー
ドにデータが同期される
• SLA:99.9%
15

レプリケーションの選択
• Storage を新規に作成
16
以下から選択
• ローカル冗長
• ジオ (主要地域) 冗長
• 読み取りアクセス Geo 冗長
• 既存の Storage を変更

コンピューティングのディザスタリカバリ
• Cloud Services、Virtual Machines、Web Sites といったコン
ピューティングサービスは、Traffic Manager によって災害対策を
行うことができる。
• Traffic Manager は DNS の役割を担い、正常時はプライマリ拠点の
サービスのグローバル IP アドレスを返すが、プライマリ拠点のサー
ビスにアクセスできない場合は、その次に指定したサービスのグロー
バル IP アドレスをクライアントに返す。
※ Traffic Manager の負荷分散方法に“フェールオーバー”を指定した場合
18

Traffic Manager のフェールオーバーイメージ
19
Traffic Manager の設定
• DNS名：yourcompany.trafficmanager.net
• 負荷分散方法：フェールオーバー
• 登録エンドポイント
1. japaneast.cloudapp.net（日本東）
2. japanwest.cloudapp.net（日本西）
3. eastasia.azurewebsites.net（東アジア）
日本(東)japaneast.cloudapp.net
（優先順位1）
日本(西)japanwest.cloudapp.net
（優先順位2）
東アジアeastasia.azurewebsites.net
（優先順位3）
日本(東)
日本(西)japanwest.cloudapp.net
（優先順位2）
東アジアeastasia.azurewebsites.net
（優先順位3）
japaneast.cloudapp.net
（優先順位1）

Traffic Manager の動作
Traffic Manager がトラフィックをエンドポイントにルーティングする
仕組みは以下の手順となる。
20
DNS
Server
監視
負荷分散方法
Traffic Manager Profile
① ②
③
④
japaneast.cloudapp.net
（優先順位1）
japanwest.cloudapp.net
（優先順位2）
eastasia.azurewebsites.net
（優先順位3）
yourcompany.azurewebsites.net
http://msdn.microsoft.com/library/azure/dn339010.aspx

Traffic Manager の負荷分散方法
Traffic Manager には、3つの負荷分散方法が用意されている。
ディザスタリカバリを目的とする場合、「フェールオーバー」が相応
しい負荷分散方法になる。
• フェールオーバー
• ラウンドロビン
• パフォーマンス
21

Traffic Manager の設定
• Traffic Manager を作成
22
フェイルオーバーを選択
• エンドポイントを追加

SQL Database のディザスタリカバリ
• SQL Database は、利用しているエディションに応じてディザスタ
リカバリの方法を選択可能
24
エディション方法
Web*1
• 別リージョンの BLOB への自動エクスポート
Business*1
Basic
• Geo-Restore
Standard
• Geo-Restore
• Standard Geo-Replication
Premium
• Geo-Restore
• Standard/Active Geo-Replication

Geo-Restore
• RA-GRS の BLOB ストレージに
週一回の完全バックアップ、毎日の差分バックアップが取得される
• プライマリリージョンの災害時には、RA-GRS によって複製された
最新のバックアップから、任意のリージョンにデータベースを復元す
ることができる
• バックアップの複製は 1 日 1 回実施されるため、最大で 24 時間分
のデータ損失が発生する
25
Web, Standard, Premium エディション
SQL Database
BLOB
日本(東)
Backup file
SQL Database
BLOB
日本(西)
Backup file
自動バックアップ RA-GRS による複製
( 1 日 1 回)
復元
自動
手動
http://blogs.msdn.com/b/windowsazurej/archive/2014/10/02/blog-azure-sql-database-Geo-Restore.aspx

Geo-Replication
• 自動で非同期にレプリケーション
• Standard Geo-Replication は、対となるリージョンにオフラインのレプ
リカを作成（Standard, Premium エディション)
• Active Geo-Replication は、任意のリージョンに最大 4 つの読み取り専用
レプリカを作成（Premium エディションのみ）
• レプリケーションを停止すると
複製先はオンラインまたは
書き込み可能になる
• レプリカをプライマリに昇格さ
せるには、レプリケーションの
停止と共に、クライアントの
接続先変更が必要
• Standard, Premium エディション
でのみ利用可能
26http://msdn.microsoft.com/library/azure/dn783447.aspx
Standard, Premium エディション

Geo-Replication レプリカの追加
27
複製先のリージョンと SQL Database サーバーを選択
「オフライン」がStandard Geo-Replication
「オンライン」がActive Geo-Replication

別リージョンの BLOB への自動エクスポート
• 時間指定により別リージョンの Azure BLOB に
BACPAC ファイルをエクスポートする
• プライマリ拠点の災害時には、別リージョンの BLOB にある
BACPAC ファイルをインポートしてデータを復旧
28
SQL Database
日本(東)
SQL Database
BLOB
日本(西)
BACPAC file
自動エクスポートインポート
自動
手動
全てのエディション

シナリオ#1 – GRS による Virtual Machines のリカバリ
• 東日本リージョンで Virtual Machines を稼働し、
インスタンスのディスクイメージを GRS により複製
• 東日本リージョンが災害で利用できなくなった場合、
GRSのフェールオーバーにより西日本リージョンからアクセスできる
ディスクイメージから Virtual Machines を新たに作成して復旧
30
日本(東) 日本(西) 日本(東) 日本(西)
アカウント名.blob.core.windows.net/vhds/～.vhd アカウント名.blob.windows.net/vhds/～.vhd
仮想マシン
新規作成

シナリオ#2 - RA-GRS による Virtual Machines のリカバリ
• 東日本リージョンで仮想マシンを稼働し、
インスタンスのディスクイメージを RA-GRS により複製
• 東日本リージョンが災害で利用できなくなった場合、
ユーザーの判断・タイミングでセカンダリのディスクイメージを
新たなストレージにリージョン内で高速コピーし、
そのディスクイメージから Virtual Machines を新たに作成して復旧
31
日本(東) 日本(西) 日本(東)
アカウント名.blob.core.windows.net/vhds/～.vhd アカウント名-secondary.blob.core.windows.net/vhds/～.vhd
日本(西)
仮想マシン
新規作成
アカウント名-secondary.blob.core.windows.net/vhds/～.vhd 新アカウント名.blob.core.windows.net/vhds/～.vhd
コピー

シナリオ#3 – Web サービスのディザスタリカバリ
• 東日本、西日本リージョンで Web サイトを稼働させる
• クライアントからのアクセスは Traffic Manager を利用し、
東日本、西日本の順にフェールオーバーさせる
• 東日本リージョンのサービスが利用できなくなった場合、
ユーザーからのアクセスは次の順位の西日本リージョンに転送される
• 東日本リージョンが復旧すれば、アクセスは東日本に戻る
32
日本(東)japaneast.azurewebsites.net
（優先順位1）
日本(西)japanwest.azurewebsites.net
（優先順位2）
日本(東)
日本(西)japanwest.azurewebsites.net
（優先順位2）
japaneast.azurewebsites.net
（優先順位1）

シナリオ#4 – Web サービスと SQL DB の DR
• 東日本、西日本リージョンで Web Sitesを稼働させる
• クライアントからのアクセスは Traffic Manager を利用し、東日本、西日本の順にフェールオーバーさせる
• 東日本リージョンの SQL Database をプライマリとし、Active Geo-Replication で西日本リージョンにレプリカ
を作成
• [ケース 1] 正常時は西日本の Web Sites も DB は東日本に接続
• [ケース 2] 東日本の Web Sites のみの障害時、Web Sites は西日本にフェールオーバーするが、DB は東日本に
アクセス
• [ケース 3] 東日本の災害時、DB のレプリケーションを停止して西日本の DB を書き込み可能にし、西日本の
Web Sites の接続先を手動で西日本の DB に変更
33
日本(東) 日本(西) 日本(東) 日本(西) 日本(東) 日本(西)
Active Geo-Replication
Traffic Manager Traffic Manager Traffic Manager
Active Geo-Replication
切断
手動切替
ケース 1 ケース 2 ケース 3

Appendix
• Windows Azure ストレージの冗長オプションと読み取りアクセス地
理冗長ストレージ
http://blogs.msdn.com/b/windowsazurej/archive/2013/12/19/
blog-windows-azure-storage-redundancy-options-and-read-
access-geo-redundant-storage.aspx
• Traffic Manager
http://msdn.microsoft.com/ja-jp/library/azure/hh745750.aspx
• Geo-Restore
http://blogs.msdn.com/b/windowsazurej/archive/2014/10/02/
blog-azure-sql-database-Geo-Restore.aspx
• Geo-Replication in Azure SQL Database
35

S10 日本東西リージョンでのディザスタ リカバリ環境の実現

More Related Content

What's hot

Similar to S10 日本東西リージョンでのディザスタ リカバリ環境の実現

More from Microsoft Azure Japan