Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
1
本ドキュメントの更新について
• 以下の日付でドキュメントを更新、確認しています。
2
バージョン
1.00 2015/2/28 ・初版リリース
目次
• 概要
• ストレージ
• コンピューティング
• SQL Database
• シナリオ
3
4
ディザスタ リカバリとは
• 災害などによりデータセンター全体または一部の機能が停止した場合
に、その被害を最小限に抑える対策をすること。
• 一般的なバックアップでは、退避したデータは同一のデータセンター
内に保管されることが多い。
その場合...
世界中のMicrosoft Azureデータ センター
6
日本東西DCを含む
世界中に展開されています。
• オーストラリア構築中
• 中国は21Vianet社により運営
http://azure.microsoft.com/ja-jp/re...
Microsoft Azure のディザスタ リカバリ機能
Microsoft Azure ではサービスごとにディザスタ リカバリに活用でき
る機能を持っています。
• Storage
• コンピューティング
• SQL Database
7
8
Storage のディザスタ リカバリ
ストレージは4種類の冗長構成を選択することができる。
• 地理冗長ストレージ(GRS = Geo Redundant Storage)
• 読み取りアクセス地理冗長ストレージ
(RA-GRS = Read...
リージョンの組み合わせ
• GRS、RA-GRS では、ユーザーが指定したリージョンをプライマリ
拠点としてデータを保存し、セカンダリ拠点となる同一地域のもう一
方のリージョンに、そのデータを非同期に複製
• プライマリ拠点とセカンダリ拠点の組...
地理冗長ストレージ(GRS)#1
• BLOB、テーブル、キューのデータを、プライマリ拠点から何百キロ
も離れた場所にあるセカンダリ拠点に複製
• プライマリ拠点で大災害が発生し復旧ができない場合、セカンダリ拠
点にフェールオーバーされる。その...
地理冗長ストレージ(GRS)#2
• プライマリ拠点への書き込みが完了した後、そのデータが非同期でセ
カンダリ拠点に複製
• トランザクションは非同期で複製されるため、プライマリ拠点には複
製によるアプリケーションへの影響はない。
• 非同期に...
読み取りアクセス Geo 冗長ストレージ(RA-GRS)
• 地理冗長ストレージと同様に、プライマリ拠点からセカンダリ拠点に
データが複製される
• セカンダリ拠点のデータには読み取り専用でいつでもアクセスできる。
そのエンドポイントは、プライ...
ゾーン冗長ストレージ(ZRS)
• 複数のゾーン(施設)に渡ってデータを3重化
• 1つのリージョンあるいは2つのリージョンに渡る
• ブロック BLOB のみをサポート(ページ BLOB、テーブル、キュー
は対象外)
• 施設における火災など...
ローカル冗長ストレージ(LRS) ※参考
• 同じ拠点内の 3 つのストレージ ノードに、トランザクションを同時
に複製することにより、ストレージ アカウントのすべてのデータの
耐久性を確保
• 異なる障害ドメイン、異なる更新ドメインのノードに...
レプリケーションの選択
• Storage を新規に作成
16
以下から選択
• ローカル冗長
• ジオ (主要地域) 冗長
• 読み取りアクセス Geo 冗長
• 既存の Storage を変更
17
コンピューティングのディザスタ リカバリ
• Cloud Services、Virtual Machines、Web Sites といったコン
ピューティング サービスは、Traffic Manager によって災害対策を
行うことができる。
...
Traffic Manager のフェールオーバー イメージ
19
Traffic Manager の設定
• DNS名:yourcompany.trafficmanager.net
• 負荷分散方法:フェールオーバー
• 登録エンドポイント
...
Traffic Manager の動作
Traffic Manager がトラフィックをエンドポイントにルーティングする
仕組みは以下の手順となる。
20
DNS
Server
監視
負荷分散方法
Traffic Manager Profile...
Traffic Manager の負荷分散方法
Traffic Manager には、3つの負荷分散方法が用意されている。
ディザスタ リカバリを目的とする場合、「フェールオーバー」が相応
しい負荷分散方法になる。
• フェールオーバー
• ラ...
Traffic Manager の設定
• Traffic Manager を作成
22
フェイルオーバーを選択
• エンドポイントを追加
23
SQL Database のディザスタ リカバリ
• SQL Database は、利用しているエディションに応じてディザスタ
リカバリの方法を選択可能
24
エディション 方法
Web*1
• 別リージョンの BLOB への自動エクスポート
...
Geo-Restore
• RA-GRS の BLOB ストレージに
週一回の完全バックアップ、毎日の差分バックアップが取得される
• プライマリ リージョンの災害時には、RA-GRS によって複製された
最新のバックアップから、任意のリージョ...
Geo-Replication
• 自動で非同期にレプリケーション
• Standard Geo-Replication は、対となるリージョンにオフラインのレプ
リカを作成(Standard, Premium エディション)
• Active...
Geo-Replication レプリカの追加
27
複製先のリージョンと SQL Database サーバーを選択
「オフライン」がStandard Geo-Replication
「オンライン」がActive Geo-Replication
別リージョンの BLOB への自動エクスポート
• 時間指定により別リージョンの Azure BLOB に
BACPAC ファイルをエクスポートする
• プライマリ拠点の災害時には、別リージョンの BLOB にある
BACPAC ファイルをイン...
29
シナリオ#1 – GRS による Virtual Machines のリカバリ
• 東日本リージョンで Virtual Machines を稼働し、
インスタンスのディスクイメージを GRS により複製
• 東日本リージョンが災害で利用できなく...
シナリオ#2 - RA-GRS による Virtual Machines のリカバリ
• 東日本リージョンで仮想マシンを稼働し、
インスタンスのディスクイメージを RA-GRS により複製
• 東日本リージョンが災害で利用できなくなった場合、
...
シナリオ#3 – Web サービスのディザスタ リカバリ
• 東日本、西日本リージョンで Web サイトを稼働させる
• クライアントからのアクセスは Traffic Manager を利用し、
東日本、西日本の順にフェールオーバーさせる
• ...
シナリオ#4 – Web サービスと SQL DB の DR
• 東日本、西日本リージョンで Web Sitesを稼働させる
• クライアントからのアクセスは Traffic Manager を利用し、東日本、西日本の順にフェールオーバーさせる...
34
Appendix
• Windows Azure ストレージの冗長オプションと読み取りアクセス地
理冗長ストレージ
http://blogs.msdn.com/b/windowsazurej/archive/2013/12/19/
blog-w...
36
Nächste SlideShare
Wird geladen in …5
×

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

7.534 Aufrufe

Veröffentlicht am

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

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

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

×