![シナリオ#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](https://image.slidesharecdn.com/s10-140708051612-phpapp02/85/S10-33-320.jpg)
S10 日本東西リージョンでのディザスタ リカバリ環境の実現
- 1. 1
- 3. 目次 • 概要 • ストレージ • コンピューティング • SQL Database • シナリオ 3
- 4. 4
- 5. ディザスタ リカバリとは • 災害などによりデータセンター全体または一部の機能が停止した場合 に、その被害を最小限に抑える対策をすること。 • 一般的なバックアップでは、退避したデータは同一のデータセンター 内に保管されることが多い。 その場合、地震・火災・浸水などにより、運用環境のデータと共に退 避したメディアも利用できなくなってしまう。 このような状況でもシステムの運用が継続できるよう、地理的に離れ た場所にデータを退避し、また、データのみならずシステムが稼働し ているサーバー環境もほぼ同一のものを用意しておくことで、短時間 の停止でシステムの運用を再開することができる。 5
- 6. 世界中のMicrosoft Azureデータ センター 6 日本東西DCを含む 世界中に展開されています。 • オーストラリア構築中 • 中国は21Vianet社により運営 http://azure.microsoft.com/ja-jp/regions/
- 7. Microsoft Azure のディザスタ リカバリ機能 Microsoft Azure ではサービスごとにディザスタ リカバリに活用でき る機能を持っています。 • Storage • コンピューティング • SQL Database 7
- 8. 8
- 9. 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
- 10. リージョンの組み合わせ • GRS、RA-GRS では、ユーザーが指定したリージョンをプライマリ 拠点としてデータを保存し、セカンダリ拠点となる同一地域のもう一 方のリージョンに、そのデータを非同期に複製 • プライマリ拠点とセカンダリ拠点の組み合わせ 10 東日本 西日本 東アジア 東南アジア 米国中北部 米国中南部 米国西部 米国東部 米国中部 米国東部 2 北ヨーロッパ 西ヨーロッパ ブラジル南部（※） 米国中南部 オーストラリア西部 オーストラリア東部 中国北 中国東
- 11. 地理冗長ストレージ（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
- 12. 地理冗長ストレージ（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
- 13. 読み取りアクセス Geo 冗長ストレージ（RA-GRS） • 地理冗長ストレージと同様に、プライマリ拠点からセカンダリ拠点に データが複製される • セカンダリ拠点のデータには読み取り専用でいつでもアクセスできる。 そのエンドポイントは、プライマリ拠点のアカウント名に 接尾辞「-secondary」を付与したものになる。 • SLA: 13 BLOB Table Queue 日本(東) BLOB Table Queue 日本(西) アカウント名.<service>.core.windows.net アカウント名-secondary.<service>.core.windows.net (読み取りのみ)(読み書き) http://blogs.msdn.com/b/windowsazurej/archive/2013/12/19/blog-windows-azure-storage-redundancy-options-and-read-access-geo-redundant-storage.aspx
- 14. ゾーン冗長ストレージ（ZRS） • 複数のゾーン（施設）に渡ってデータを3重化 • 1つのリージョンあるいは2つのリージョンに渡る • ブロック BLOB のみをサポート（ページ BLOB、テーブル、キュー は対象外） • 施設における火災などへの耐久性を向上する 14
- 15. ローカル冗長ストレージ（LRS） ※参考 • 同じ拠点内の 3 つのストレージ ノードに、トランザクションを同時 に複製することにより、ストレージ アカウントのすべてのデータの 耐久性を確保 • 異なる障害ドメイン、異なる更新ドメインのノードに複製 • このストレージはディザスタ リカバリではないが、RA-GRS、GRS、 ZRSいずれも、各拠点内では LRS と同様に 3 つのストレージ のノー ドにデータが同期される • SLA:99.9% 15 http://blogs.msdn.com/b/windowsazurej/archive/2013/12/19/blog-windows-azure-storage-redundancy-options-and-read-access-geo-redundant-storage.aspx
- 16. レプリケーションの選択 • Storage を新規に作成 16 以下から選択 • ローカル冗長 • ジオ (主要地域) 冗長 • 読み取りアクセス Geo 冗長 • 既存の Storage を変更
- 17. 17
- 18. コンピューティングのディザスタ リカバリ • Cloud Services、Virtual Machines、Web Sites といったコン ピューティング サービスは、Traffic Manager によって災害対策を 行うことができる。 • Traffic Manager は DNS の 役割を担い、正常時はプライマリ拠点の サービスのグローバル IP アドレスを返すが、プライマリ拠点のサー ビスにアクセスできない場合は、その次に指定したサービスのグロー バル IP アドレスをクライアントに返す。 ※ Traffic Manager の負荷分散方法に“フェールオーバー”を指定した場合 18
- 19. 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）
- 20. 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
- 21. Traffic Manager の負荷分散方法 Traffic Manager には、3つの負荷分散方法が用意されている。 ディザスタ リカバリを目的とする場合、「フェールオーバー」が相応 しい負荷分散方法になる。 • フェールオーバー • ラウンド ロビン • パフォーマンス 21 http://msdn.microsoft.com/library/azure/dn339010.aspx
- 22. Traffic Manager の設定 • Traffic Manager を作成 22 フェイルオーバーを選択 • エンドポイントを追加
- 23. 23
- 24. SQL Database のディザスタ リカバリ • SQL Database は、利用しているエディションに応じてディザスタ リカバリの方法を選択可能 24 エディション 方法 Web*1 • 別リージョンの BLOB への自動エクスポート Business*1 Basic • Geo-Restore • 別リージョンの BLOB への自動エクスポート Standard • Geo-Restore • Standard Geo-Replication • 別リージョンの BLOB への自動エクスポート Premium • Geo-Restore • Standard/Active Geo-Replication • 別リージョンの BLOB への自動エクスポート
- 25. 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
- 26. Geo-Replication • 自動で非同期にレプリケーション • Standard Geo-Replication は、対となるリージョンにオフラインのレプ リカを作成（Standard, Premium エディション) • Active Geo-Replication は、任意のリージョンに最大 4 つの読み取り専用 レプリカを作成（Premium エディションのみ） • レプリケーションを停止すると 複製先はオンラインまたは 書き込み可能になる • レプリカをプライマリに昇格さ せるには、レプリケーションの 停止と共に、クライアントの 接続先変更が必要 • Standard, Premium エディション でのみ利用可能 26http://msdn.microsoft.com/library/azure/dn783447.aspx Standard, Premium エディション
- 27. Geo-Replication レプリカの追加 27 複製先のリージョンと SQL Database サーバーを選択 「オフライン」がStandard Geo-Replication 「オンライン」がActive Geo-Replication
- 28. 別リージョンの BLOB への自動エクスポート • 時間指定により別リージョンの Azure BLOB に BACPAC ファイルをエクスポートする • プライマリ拠点の災害時には、別リージョンの BLOB にある BACPAC ファイルをインポートしてデータを復旧 28 SQL Database 日本(東) SQL Database BLOB 日本(西) BACPAC file 自動エクスポート インポート 自動 手動 全ての エディション
- 29. 29
- 30. シナリオ#1 – GRS による Virtual Machines のリカバリ • 東日本リージョンで Virtual Machines を稼働し、 インスタンスのディスクイメージを GRS により複製 • 東日本リージョンが災害で利用できなくなった場合、 GRSのフェールオーバーにより西日本リージョンからアクセスできる ディスクイメージから Virtual Machines を新たに作成して復旧 30 日本(東) 日本(西) 日本(東) 日本(西) アカウント名.blob.core.windows.net/vhds/～.vhd アカウント名.blob.windows.net/vhds/～.vhd 仮想マシン 新規作成
- 31. シナリオ#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 コピー
- 32. シナリオ#3 – Web サービスのディザスタ リカバリ • 東日本、西日本リージョンで Web サイトを稼働させる • クライアントからのアクセスは Traffic Manager を利用し、 東日本、西日本の順にフェールオーバーさせる • 東日本リージョンのサービスが利用できなくなった場合、 ユーザーからのアクセスは次の順位の西日本リージョンに転送される • 東日本リージョンが復旧すれば、アクセスは東日本に戻る 32 日本(東)japaneast.azurewebsites.net （優先順位1） 日本(西)japanwest.azurewebsites.net （優先順位2） 日本(東) 日本(西)japanwest.azurewebsites.net （優先順位2） japaneast.azurewebsites.net （優先順位1）
- 33. シナリオ#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
- 34. 34
- 35. 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 http://msdn.microsoft.com/library/azure/dn783447.aspx 35
- 36. 36