エクスポート (0) 印刷
すべて展開
このトピックはまだ評価されていません - このトピックを評価する

Windows Azure のビジネス継続性テクニカル ガイダンス

最終更新日: 2013 年 9 月

発行日: 2012 年 3 月

執筆者: Patrick Wickline、Jason Roth

概要

高可用性および災害復旧の要件を満たすには、1) クラウド プラットフォームの機能についての詳細な技術的知識、および 2) 分散サービスの適切な設計方法、の 2 種類の知識が必要です。ここでは前者について、つまり、ビジネス継続性に関する Windows Azure Platform の機能と制限事項について説明します。また、主題ではないアーキテクチャとデザイン パターンにも触れます。設計については、その他のリソース セクションの内容を参照してください。

情報は次の各セクションに整理されています。

  • 1.ローカル障害からの復旧: 負荷が急増した場合、物理ハードウェア (ドライブ、サーバー、ネットワーク デバイスなど) がすべてエラーを起こし、リソースが使い果たされることがあります。このセクションでは、このような条件の下で高可用性を保持するために Windows Azure が提供する機能について説明します。

  • 2.Windows Azure の地域の損失からの復旧: 広範囲にわたる障害はまれですが、発生する可能性はあります。地域全体がネットワーク障害のために孤立したり、自然災害のために物理的に破損したりすることがあります。ここでは、Windows Azure の機能を使用して地理的に離れたさまざまな地域にまたがるアプリケーションを作成する方法について説明します。

  • 3.内部設置型から Windows Azure への復旧: クラウドによって災害復旧のコストが大きく変わります。組織は Windows Azure を使用して復旧のために別のサイトを設置できるようになります。これはセカンダリ データセンターを構築および管理するコストの何分の 1 かで実行できます。ここでは、内部設置型のデータセンターをクラウドに拡張するために Windows Azure が提供する機能について説明します。

  • 4.データの破損または偶発的な削除からの復旧: アプリケーションにデータを破損するバグが含まれていたり、オペレーターが誤って重要なデータを削除する可能性があります。ここでは、データをバックアップし、以前のある時点の状態に復元するために Windows Azure が提供する機能について説明します。

  • 5.その他のリソース: Windows Azure での可用性と災害復旧を取り扱っているその他の重要なリソースです。

1.ローカル障害からの復旧

アプリケーションの可用性に対しては、ドライブやサーバーなどのデバイスの障害、および重要なリソースの枯渇 (負荷がピーク状態のコンピューターなど)、の 2 つの主な脅威があります。Windows Azure には、このような状況で高可用性を有効にする、リソース管理、柔軟性、負荷分散、およびパーティション分割の組み合わせが用意されています。これらの機能の一部はすべてのクラウド サービスに対して自動的に実行されます。ただし、場合によっては、アプリケーション開発者が効果を上げるために追加の作業を行う必要があります。

コンピューティング (PaaS)

Windows Azure によってホストされるすべてのクラウド サービスは、1 つ以上の Web ロールやワーカー ロールのコレクションです。特定のロールの 1 つ以上のインスタンスを同時に実行できます。インスタンスの数は、構成によって決まります。ロール インスタンスはファブリック コントローラー (FC) と呼ばれるコンポーネントで監視および管理されます。FC はソフトウェアとハードウェアの両方の障害を自動的に検出して応答します。

  • すべてのロール インスタンスは独自の仮想マシン (VM) で実行され、ゲスト エージェント (GA) を通じてその FC と通信します。GA はリソースおよびノード メトリックを収集します。これには、VM の使用状況、状態、ログ、リソースの使用状況、例外、および障害の状態が含まれます。FC は、構成可能な間隔で GA に対してクエリを実行し、GA が応答しないと VM が再起動されます。

  • ハードウェア障害が発生した場合、関連付けられている FC は影響を受けるすべてのロール インスタンスを新しいハードウェア ノードに移動し、そのトラフィックにルーティングするようにネットワークを再構成します。

これらの機能の恩恵を受けるには、開発者はすべてのサービス ロールがロール インスタンスに状態を保存しないようにする必要があります。代わりに、すべての持続データは、Windows Azure ストレージ サービスや SQL データベース などの持続性のあるストレージからアクセスされる必要があります。これによって、要求はどのロールでも処理できるようになります。また、これはロール インスタンスが一時的または永続的なサービス状態において一貫性を損なうことなくいつでも障害を発生する可能性があることも意味します。

状態をロールの外部に保存する要件はいくつかの影響を与えます。これは、たとえば、Windows Azure ストレージ テーブルに関連するすべての変更は、可能であれば、単一のエンティティ グループ トランザクションで変更される必要があることを意味します。もちろん、すべての変更を単一のトランザクションで常に行うことができるわけではありません。ロール インスタンスが永続的な状態のサービスに対して 2 回以上の更新にわたる長時間実行している操作に割り込む場合、ロール インスタンスのエラーによって問題が発生しないように特別な注意が必要です。別のロールがそのような操作を再試行しようとするときは、作業が部分的に完了している場合を予測して処理する必要があります。

たとえば、複数のストア間のデータを分割するサービスにおいて、分割データベースを再配置している間にワーカー ロールに障害が発生すると、分割データベースの再配置が完了しなかったり、別のワーカー ロールによって最初から繰り返されたりして、データが孤立したり、破損したりする潜在的な可能性があります。問題を回避するために、長時間実行している操作はべき等操作 (つまり、問題を起こさずに繰り返しが可能) または増分再開が可能 (つまり、最新の障害の時点からの継続が可能) である必要があります。

  • べき等操作になるには、実行時間の長い操作は何度実行しても、たとえ実行の途中で中断されても、同じ結果が得られる必要があります。

  • 増分再開ができるようにするためには、長時間実行している操作はかなり小さなアトミック操作のシーケンスで構成される必要があり、後続の各呼び出しが前の操作が停止した場所をピックアップできるように、持続性のあるストレージに進行状況を記録する必要があります。

最後に、すべての長時間実行している操作は成功するまで繰り返し呼び出される必要があります。たとえば、プロビジョニング操作は Windows Azure キューに配置されて、成功した場合にのみワーカー ロールによってキューから削除される可能性があります。中断された操作で作成されたデータをクリーンアップするために、ガベージ コレクションが必要となる場合があります。

柔軟性

各ロールに対して実行されているインスタンスの最初の数は、各ロールの構成で決まります。管理者は予測される負荷に基づいて、複数のインスタンスで実行するように各ロールを最初に構成する必要があります。ただし、ロール インスタンスは使用パターンの変更に合わせてスケール アップまたはスケール ダウンを簡単に行うことができます。これは Windows Azure ポータル、Windows PowerShell、Service Management API、またはサード パーティのツールで実行することができます。FC が新しいインスタンスを自動的に準備し、そのロールのロード バランサーに挿入します。

Windows Azure: Web サイトの一般的な可用性 + モバイル サービス、新しい AutoScale + アラート サポート、クレジット カード不要の MSDN」にしたがって、Windows Azure を有効にして、負荷に基づいてロールを自動的に拡張することができます。また、自動スケーリングはプログラムによって組み込み、「4: 自動スケーリングと Windows Azure」で説明されているようなフレームワークを使用してクラウド サービスのために構成することもできます。

パーティション分割

FC は、アップグレード ドメインおよびフォールト ドメインの 2 つのパーティションを使用します。

  • アップグレード ドメインは、グループ内でサービスのロール インスタンスをアップグレードするために使用されます。Windows Azure はサービス インスタンスを複数のアップグレード ドメインに展開します。インプレース アップグレードでは、FC は 1 つのアップグレード ドメインのすべてのインスタンスを停止して、それらをアップグレードし、再起動してから次のアップグレード ドメインに移動します。この方法は、アップグレード プロセス中にサービス全体が使用できなくなることを防ぎます。

  • フォールト ドメインは、ハードウェアやネットワークの障害の可能性があるポイントを明らかにします。複数のインスタンスがある各ロールに対して、FC は孤立したハードウェア障害によってサービスが中断されることを防ぐために、インスタンスが複数のフォールト ドメインに分散されるようにします。Windows Azure におけるサーバーおよびクラスターの障害は、フォールト ドメインによって管理されます。

サービス レベル アグリーメント」によって、マイクロソフトは、複数の Web ロール インスタンスが異なるフォールト ドメインおよびアップグレード ドメインに展開される場合、99.95% 以上の時間で外部に接続されることを保証します。更新ドメインとは異なり、フォールト ドメインの数を制御する方法はありません。Windows Azure が自動的にフォールト ドメインを割り当て、それらにロール インスタンスを分散します。すべてのロールの少なくとも最初の 2 つのインスタンスは、異なるフォールト ドメインおよびアップグレード ドメインに配置されます。これは少なくとも 2 つのインスタンスがあるすべてのロールが SLA を満たすようにするためです。これは次の図で表されます。

フォールト ドメインの分離 (簡略表示)

負荷分散

Web ロールへのすべてのインバウンド トラフィックはステートレスなロード バランサーを通過し、そのロード バランサーはクライアント要求をロール インスタンス間に分散します。個々のロール インスタンスにはパブリック IP アドレスがなく、インターネットから直接のアドレス指定は可能ではありません。Web ロールはステートレスであるため、すべてのクライアント要求はすべてのロール インスタンスにルーティングできます。StatusCheck イベントは 15 秒ごとに発生します。これはロールがトラフィックを受信する準備ができているのか、または使用中なのかを示すために使用できますが、ロード バランサーのローテーションからは外す必要があります。

仮想マシン (IaaS)

Windows Azure の仮想マシンは、高可用性に関連するいくつかの点で PaaS のコンピューティング ロールとは異なります。場合によっては、高可用性を確保するために追加作業を行う必要があります。

ディスクの持続性

PaaS のロール インスタンスとは異なり、仮想マシンのドライブに保存されているデータは仮想マシンが再配置される場合でも永続的です。Windows Azure の仮想マシンは、Windows Azure ストレージに BLOB として存在する VM ディスクを使用します。Windows Azure ストレージの可用性という特性のために、仮想マシンのドライブに保存されているデータも高い可用性を備えています。D: ドライブはこの規則の例外であることに注意してください。D: ドライブは VM をホストするラック サーバーの実際の物理的記憶領域で、そのデータは VM がリサイクルされると失われます。D: ドライブは一時ストレージのみを目的としています。

パーティション分割

Windows Azure は PaaS アプリケーションの層 (Web ロールおよびワーカー ロール) をネイティブで認識するため、フォールト ドメインと更新ドメインにそれらを適切に分散できます。これに対し、IaaS アプリケーションの層は、可用性セットを使用して手動で定義する必要があります。可用性セットは、IaaS の下での SLA に必要です。

Windows Azure VM の可用性セット

上の図で、IIS 層および SQL の層は異なる可用性セットに割り当てられています。これは、各層のすべてのインスタンスがフォールト ドメインに分散することによってハードウェア冗長性を備え、更新中に削除されないようにします。可用性セットの構成の詳細については、「仮想マシンの可用性管理」を参照してください。

負荷分散

VM 全体に分散するトラフィックが VM にある場合は、クラウド サービスの VM および特定の TCP や UDP エンドポイントにわたるロード バランスをグループ化する必要があります。詳細については、「仮想マシンの負荷分散 (Linux) - Windows Azure」を参照してください。VM が別のソースからの入力 (キュー メカニズムなど) を受信する場合、ロード バランサーは必要ではありません。ロード バランサーは、トラフィックをノードに送信する必要があるかどうかを判断するために基本的な正常性チェックを使用します。また、VM がトラフィックを受信する必要があるかどうかを判断する、アプリケーション固有の正常性メトリックを実行するために独自のプローブを作成することもできます。

ストレージ

Windows Azure ストレージは、BLOB、テーブル、キュー、および VM ディスク ストレージを提供する、Windows Azure の基本の永続的データ サービスです。これはレプリケーションとリソース管理の組み合わせを使用して、単一のデータ センター内で高可用性を提供します。Windows Azure ストレージの可用性についての SLA では、99.9% 以上の時間で、データの追加、更新、読み取り、および削除に対する正しい形式の要求が正常に問題なく処理され、ストレージ アカウントがインターネット ゲートウェイに接続できることが保証されます。

レプリケーション

Windows Azure ストレージのデータの持続性は、地域内の完全に独立した物理ストレージ サブシステムにある複数のドライブにすべてのデータの複数のコピーを維持することによって促進されます。データは同期的にレプリケートされ、すべてのコピーが書き込みが承認される前にコミットされます。Azure ストレージには強い一貫性があります。これは読み取りが最新の書き込みを反映していることが保証されていることを意味します。また、データのコピーは、ビット崩壊を検出して修復するために継続的にスキャンされます。ビット崩壊は、格納されているデータの整合性を脅かす脅威ですが、よく見過ごされます。サービスは Windows Azure ストレージを使用するだけで、レプリケーションから恩恵を受けられます。ローカル障害から復旧するためにサービス開発者が追加作業を行う必要はありません。

リソースの管理

2012 年 6 月 7 日より後に作成されたストレージ アカウントは 200 TB まで拡張することができます (以前の最大値は 100 TB)。追加領域が必要となった場合は、アプリケーションが複数のストレージ アカウントを活用できるように設計する必要があります。

VM ディスク

仮想マシンの VM ディスクは、Windows Azure ストレージにページ BLOB として格納され、BLOB ストレージとまったく同じ持続性とスケーラビリティのプロパティを提供します。この設計によって、VM を実行しているサーバーがエラーとなり、VM を別のサーバーで再起動しなければならない場合でも、仮想マシンのディスク上のデータは永続的なものになります。

データベース

SQL データベース

Windows Azure SQL データベース は、サービスとしてのデータベースを提供します。これにより、リレーショナル データベースのプロビジョニング、データの挿入、およびクエリをアプリケーションで迅速に行うことができます。使い慣れた SQL Server の機能の多くが提供される一方で、ハードウェア、構成、修正、および回復力に関する負担は取り除かれます。

note
SQL データベース は、SQL Server と 1:1 で対応する機能を提供するものではありません。クラウド アプリケーションに固有の、一連の異なる要件 (柔軟な拡張、メンテナンス コストを削減するサービスとしてのデータベースなど) を満たすことを目的としています。詳細については、「データ シリーズ: Windows Azure の仮想マシンの SQL Server 対 SQL データベース」を参照してください。

レプリケーション

SQL データベース には、ノード レベルのエラーに対する回復力が組み込まれています。データベースに対するすべての書き込みは、クォーラム コミットの手法を使用して複数のバックグラウンド ノードに自動的にレプリケートされます (トランザクションが成功と見なされて終了するためには、プライマリと少なくとも 1 つのセカンダリでアクティビティがトランザクション ログに書き込まれたことが確認される必要があります)。ノードでエラーが発生した場合は、データベースがいずれかのセカンダリ レプリカに自動的にフェールオーバーします。これにより、クライアント アプリケーションに対する一時的な接続の中断が発生します。したがって、Windows Azure SQL データベース のすべてのクライアントが何らかの形式の一時的な接続処理を実装する必要があります。詳細については、「SQL Azure での一時的な違反を処理するアプリケーション ブロックの使用」を参照してください。

リソースの管理

各データベースの作成時にサイズの上限を構成します。現在使用できる最大サイズは 150 GB です。データベースのサイズが上限に達すると、INSERT コマンドや UPDATE コマンドが拒否されるようになります (データのクエリと削除は引き続き実行できます)。

データベース内では、Windows Azure SQL データベース はリソースの管理にファブリックを使用します。ただし、エラーの検出には、ファブリック コントローラーではなく、リング型トポロジを使用します。クラスター内の各レプリカには 2 つのネイバーがあり、レプリカはネイバーに障害が発生すると検出します。レプリカに障害が発生した場合は、そのネイバーが再構成エージェント (RA) を起動して、別のコンピューターでレプリカを再作成するようにします。エンジン調整は、論理サーバーがコンピューターに対して過大なリソースを使用していない、またはコンピューターの物理的制限を超えていないことを確認するために用意されています。

柔軟性

アプリケーションが 150 GB のデータベースの上限値を超える要求を行う場合は、スケールアウト アプローチを実行する必要があります。Windows Azure SQL データベース でのスケールアウトは、シャーディングとして知られる、複数の SQL データベース の間のデータを手動でパーティション分割することで実行されます。このスケールアウト アプローチはコストをスケールに対して線形に近い形で増加させます。柔軟な増加 (キャパシティ オン デマンド) により、容量とコストを必要に応じて増やすことができます。これは、データベースが最大可能サイズではなく、1 日あたりに使用される実際の平均サイズに基づいて課金されるためです。

仮想マシンの SQL Server 2012 (IaaS)

Windows Azure の仮想マシン (IaaS) に SQL Server 2012 をインストールすると、AlwaysOn 可用性グループやデータベース ミラーリングなど、SQL Server の従来の可用性機能を利用することができます。Windows Azure VM、ストレージ、およびネットワーキングは、内部設置型の非仮想化 IT インフラストラクチャとは異なる動作特性を持つことに注意してください。Windows Azure 内に HADR SQL Server ソリューションを正常に実装するには、これらの違いを理解し、その違いを反映するようにソリューションを設計する必要があります。

可用性セット内の高可用性ノード

Windows Azure に高可用性ソリューションを実装した場合、Windows Azure 内の可用性セットを使用して、高可用性ノードを別個のフォールト ドメインおよびアップグレード ドメインに配置できます。簡単に言うと、可用性セットは Windows Azure の 1 つの概念です。詳細については、「仮想マシンの可用性の管理」を参照してください。これは、AlwaysOn 可用性グループ、データベース ミラーリング、その他の方法を問わず、データベースが実際に高可用性を備えていることを確認するために従う必要があるベスト プラクティスです。このベスト プラクティスに従わない場合、システムが高可用性を備えていると確信していても、すべてのノードが Windows Azure データセンターの同じフォールト ドメインに配置されていれば、すべてのノードが同時に停止する可能性があります。この推奨事項はログ配布には適用されません。それは、災害復旧機能として、すべてのサーバーが Windows Azure の別々のデータセンターの場所 (地域) で実行されているようにする必要があるためです。定義で、これらのデータセンターの場所は、別個のフォールト ドメインです。

Windows Azure VM を同じ可用性セットに配置するには、これらを同じクラウド サービスにデプロイする必要があります。同じクラウド サービスにデプロイされているノードのみが同じ可用性セットに属することができます。さらに、VM はサービス復旧後も IP を管理するようにするために同じ VNet 内にある必要があります。そのため、DNS の更新時間を避けています。

Windows Azure のみ: 高可用性ソリューション

AlwaysOn 可用性グループまたはデータベース ミラーリングを使用して、Windows Azure 内の SQL Server データベース向けの高可用性ソリューションを実現できます。

次の図は、Windows Azure の仮想マシンで実行している AlwaysOn 可用性グループのアーキテクチャを示しています。この図は、このテーマについての詳細な解説記事「Windows Azure の仮想マシン内の SQL Server の高可用性と災害復旧」から引用したものです。

Windows Azure AlwaysOn 可用性グループ

次の図は、Windows Azure の仮想マシンのデータベース ミラーリングの使用方法を示しています。この図も、このテーマについての詳細な解説記事「Windows Azure の仮想マシン内の SQL Server の高可用性と災害復旧」から引用したものです。

Windows Azure データベース ミラーリング
note
両方のアーキテクチャにドメイン コントローラーが必要であることに注意してください。ただし、データベース ミラーリングでサーバー証明書を使用して、ドメイン コントローラーを不要にすることができます。

その他の Windows Azure Platform サービス

Windows Azure クラウド サービスは Windows Azure 上で構築されます。したがって、ローカル障害からの復旧には、前に説明したプラットフォームの機能の恩恵が受けられます。場合によっては、特定の処理を行って特定のシナリオでの可用性を高めることができます。

アクセス制御サービス (可用性)

アクセス制御サービス (ACS) 2.0 では、すべての名前空間のバックアップが 1 日に 1 回取られて、オフサイトの安全な場所に保存されます。ACS の地域データ センターの 1 つで復旧不可能なデータ損失が発生したことが確認されると、顧客のサブスクリプションを回復するために最新のバックアップが復元されます。バックアップの頻度のために、最大 24 時間分のデータ損失が発生する可能性があります。詳細については、「アクセス制御サービス (災害復旧)」を参照してください。

サービス バス (可用性)

Windows Azure サービス バスの一時的な機能停止状態を緩和するために、永続的なクライアント側キューを作成することを検討します。これにより、一時的に代替の、ローカル ストレージ メカニズムを使用して、サービス バス キューに追加できないメッセージを保存します。サービスを復元した後で、一時的に保存されたメッセージの処理方法を決定することができます。詳細については、「Service Bus で仲介型メッセージングを使用したパフォーマンス向上のヒント集」を参照してください。詳細については、「サービス バス (災害復旧)」を参照してください。

モバイル サービス (可用性)

Windows Azure モバイル サービスには、可用性について 2 つの考慮事項があります。1 つは、モバイル サービスに関連付けられた SQL データベース の定期的バックアップです。また、モバイル サービス スクリプトもバックアップします。詳細については、「障害が発生した場合にモバイル サービスを復旧する」を参照してください。モバイル サービスで一時的な機能停止が発生した場合、代替の Windows Azure データセンターを一時的に使用する必要があることがあります。詳細については、「モバイル サービス (災害復旧)」を参照してください。

HDInsight (可用性)

HDInsight に関連付けられているデータは、Windows Azure ストレージで指定される高い可用性と持続性を備えた Windows Azure BLOB ストレージに既定で保存されます。Hadoop MapReduce ジョブに関連付けられたマルチノード処理は、HDInsight が必要とする場合に準備される一時的な Hadoop 分散ファイル システム (HDFS) 上で実行されます。MapReduce ジョブの結果も、既定で Windows Azure BLOB ストレージに保存されます。これは、Hadoop クラスターがプロビジョニング解除された後、処理されたデータには持続性があり、高可用性を保つようにするためです。詳細については、「HDInsight (災害復旧)」を参照してください。

チェック リスト: ローカル障害

 

サービス/地域 チェックリスト

コンピューティング (PaaS)

  • 各ロールに 2 つ以上のインスタンスを構成する。

  • ロール インスタンスではなく、持続性のあるストレージで状態を永続化する。

  • StatusCheck イベントを適切に処理する。

  • 可能であれば、トランザクションの関連する変更をラップする。

  • ワーカー ロール タスクがべき等で再起動可能であることを確認する。

  • 成功するまで操作を呼び出し続ける。

  • 自動スケールの方法を検討する。

仮想マシン (IaaS)

  • D: ドライブを永続ストレージに使用しない。

  • サービス層のコンピューターを可用性セットにグループ化する。

  • 負荷分散とオプションのプローブを構成する。

ストレージ

  • データまたは帯域幅がクォータを超えている場合、複数のストレージ アカウントを使用する。

SQL データベース

  • 一時的なエラーを処理するために再試行ポリシーを実行する。

  • スケールアウトの方法として、パーティション分割/シャーディングを使用する。

仮想マシンの SQL Server 2012 (IaaS)

  • 仮想マシンについての前の推奨事項に従う。

  • AlwaysOn など、SQL Server の高可用性機能を使用する。

アクセス制御サービス (可用性)

  • ローカル障害に必要な追加の可用性の手順はない。

サービス バス (可用性)

  • バックアップとして永続的なクライアント側キューを作成することを検討する。

モバイル サービス (可用性)

  • モバイル サービスに関連付けられた SQL データベース を定期的にバックアップする。

  • モバイル サービス スクリプトをバックアップする。

HDInsight (可用性)

  • ローカル障害に必要な追加の可用性の手順はない。

2.Windows Azure の地域の損失からの復旧

Windows Azure は地域と呼ばれる物理的および論理的な単位に分割されます。地域は、ごく近くにある 1 つ以上のデータセンターで構成されます。このドキュメントの作成の時点では、Windows Azure には 8 つの地域 (北米 4、アジア 2、ヨーロッパ 2) があります。

まれに、1 つの地域全体の施設がネットワーク エラーなどでアクセスできなくなったり、自然災害などで完全に失われたりする可能性があります。ここでは、地域に分散するアプリケーションを作成するための Azure の機能について説明します。地域は、1 つの地域の障害が他の地域に影響を与える可能性を最小限に抑えるように設計されています。

コンピューティング (PaaS)

リソースの管理

地域へのコンピューティング インスタンスの分散は、各対象地域に個別のクラウド サービスを作成し、各クラウド サービスに配置パッケージをパブリッシュして実行されます。ただし、アプリケーション開発者またはトラフィック管理サービスが、さまざまな地域のクラウド サービスのトラフィックを分散する必要があることに注意してください。

災害復旧のために配置する予備のロール インスタンスの数を事前に確認することは、キャパシティ プランニングの重要な要素です。フルスケールのセカンダリ配置を持つと必要になったときに容量がすぐに使用できるようになりますが、これは実質的にコストが倍になります。一般的なパターンは、重要なサービスを実行するのに十分な規模の小さなセカンダリ配置だけを持つ方法です。容量を予約し、セカンダリ環境の構成をテストするために、少なくとも小規模のセカンダリ配置を作成することをお勧めします。

note
サブスクリプションのクォータは、容量が保証されているわけではありません。クォータは単なる与信限度です。容量を保証するには、ロールの必要数がサービス モデルで定義され、ロールが配置される必要があります。

負荷分散

地域間でトラフィックの負荷分散を行うためには、トラフィック管理ソリューションを使用する必要があります。Windows Azure には、「Traffic Manager の概要」(現在、CTP 内) が用意されています。また、同様のトラフィック管理機能を提供しているサードパーティのサービスを活用することもできます。

方法

地域間で分散コンピューティングを実行するために、多くの代替方法があります。これらは、特定のビジネス要件とアプリケーション環境に合わせる必要があります。大まかに言えば、方法は次の 3 つのカテゴリに分割できます。

  • 災害発生時の再配置: この方法では、アプリケーションは災害時に最初から再配置されます。これは、復旧時間が保障されている必要のない、重要ではないアプリケーションに適しています。

  • ウォーム スペア (アクティブ/パッシブ): セカンダリ ホステッド サービスは代替地域で作成され、ロールは最小容量を保証するために配置されます。ただし、このロールは実稼働トラフィックを受信しません。この方法は、地域間にトラフィックを分散するように設計されていないアプリケーションに役立ちます。

  • ホット スペア (アクティブ/アクティブ): アプリケーションは複数の地域で実稼働負荷を受信するように設計されています。各地域のクラウド サービスは DR のために必要な容量よりも大きく構成されている場合があります。また、クラウド サービスは災害およびフェールオーバー時に必要に応じてスケールアウトする可能性があります。この方法は、アプリケーション デザインにかなりの投資を必要としますが、復旧時間が短いことが保証されていること、すべての復旧場所で連続してテストが実行できること、および、容量を有効に使用できることなど、大きな利点を備えています。

分散設計の詳細については、このドキュメントでは説明しません。次のドキュメントでは、これらのシナリオについて詳しく説明します。

仮想マシン (IaaS)

IaaS VM の復旧は、多くの点で PaaS コンピューティングの復旧と似ています。ただし、IaaS VM は VM および VM ディスクの両方から構成されているという事実が重要な違いです。

  • BLOB コピー API を使用して VM ディスクをコピーする: 複数の地域で VM を作成するためには、VM ディスクを代替地域にコピーする必要があります。VM ディスクは単に BLOB であるため、標準的な BLOB のコピー (REST API) を使用して実行することができます。

  • OS ディスクからデータ ディスクを分割する: IaaS VM については、VM を再作成せずに OS ディスクの変更はできないということを考慮する必要があります。これは、復旧計画で災害後に再配置することになっている場合には問題ではありません。ただし、容量を予約するためにウォーム スペア アプローチを使用している場合には問題となる場合があります。これを適切に実行するには、プライマリの場所とセカンダリの場所の両方に正しい OS ディスクを配置し、アプリケーション データは別のドライブに保存する必要があります。可能であれば、両方の場所に提供できる標準の OS 構成を使用します。フェールオーバー後、データ ドライブをセカンダリ DC にある既存の IaaS VM に取り付ける必要があります。CopyBlob API を使用して、データ ディスクのスナップショットをリモート サイトにコピーします。

  • 複数の VM ディスクのジオフェールオーバー後の潜在的な一貫性の問題: VM ディスクは Windows Azure ストレージ BLOB として実行され、同じジオレプリケーションの特性を備えています (下記参照)。VM ディスクはジオフェールオーバー後に一貫性のある状態になることが保証されています。ただし、ディスクが原因でディスク間の一貫性についての保証はありません。これは、ジオレプリケーションが非同期で個別にレプリケートするためです。これは、場合によっては問題を引き起こす可能性があります (ディスク ストライピングの場合など)。これらの場合、ジオフェールオーバー後に一貫性を復元するために追加作業が必要となる場合があります。バックアップの精度を確認するために、Data Protection Manager などのバックアップ製品を使用してアプリケーション データのバックアップと復元を行う必要があります。

ストレージ

BLOB、テーブル、キュー、および VM ディスク ストレージのジオレプリケーションを使用した復旧

Windows Azure BLOB では、テーブル、キュー、および VM ディスクは既定ですべてジオレプリケートされます。ジオレプリケーションは、このストレージ データを特定の地理的地域内の数百マイル離れた場所にあるペアのデータセンターにレプリケートします。ジオレプリケーションを使用すると、データ センターで大きな災害が発生したときのデータの持続性が向上します。この最初のバージョンでは、いつフェールオーバーが発生するかはマイクロソフトによって制御されており、元のプライマリの場所が一定の時間内に復旧不可能と見なされるような大きな災害が発生した場合にのみフェールオーバーが行われます。シナリオによっては、これには数日かかる場合があります。将来的には、お客様がストレージ アカウントのフェールオーバーを個別に制御できるようになる予定です。データは通常数分以内にレプリケートされますが、同期の間隔はまだ SLA によってカバーされていません。詳細については、「Windows Azure ストレージのジオレプリケーションの概要」を参照してください。

ジオフェールオーバーが行われた場合、アカウントへのアクセス方法に変更はありません (URL とアカウント キーは変わりません)。ただし、ストレージ アカウントはフェールオーバー後には別の地域に存在し、これはストレージ アカウントと同じ地域にある必要があるアプリケーションには影響を与える可能性があります。同じデータ センターでストレージ アカウントを必要としないサービスとアプリケーションについても、データセンター間の待機時間と帯域幅の料金がトラフィックをフェールオーバー地域に一時的に移動させなければならない理由になる可能性があります。これは災害復旧方法全体に組み入れることができます。

ジオレプリケーションの地域マッピング:

ストレージと同じ地域にある必要があるデータの他のインスタンスを配置する場所を知るために、データがジオレプリケーションされている場所を知ることは重要です。次の表では、プライマリの場所とセカンダリの場所のペアを示しています。

 

Primary Secondary

米国中北部

米国中南部

米国中南部

米国中北部

米国東部

米国西部

米国西部

米国東部

北ヨーロッパ

西ヨーロッパ

西ヨーロッパ

北ヨーロッパ

東南アジア

東アジア

東アジア

東南アジア

ジオレプリケーションの料金:

ジオレプリケーションは Windows Azure ストレージの現在の価格に含まれます。これは地理冗長ストレージと呼ばれます。自分のデータにジオレプリケーションを行う必要がない場合は、自分のアカウントのジオレプリケーションを無効にできます。これにはローカルな冗長ストレージと呼ばれ、ジオレプリケートされたストレージの割引料金で課金されます。ローカル冗長ストレージ (LRS) に関する詳細については、ここを参照してください

ジオフェールオーバーが発生したかどうかの判断

ジオフェールオーバーが発生した場合、これが Windows Azure サービス ダッシュボードに報告されます。ただし、アプリケーションは、ストレージ アカウントの地理的地域を監視することによって自動的にこれを検出できます。これは、ストレージが移動される地理的地域のコンピューティング リソースのアクティブ化など、他の復旧操作を実行するために使用できます。これは Get Storage Account Properties を使用してサービス管理 API からクエリを実行できます。関連するプロパティは次のとおりです。

<GeoPrimaryRegion>primary-region</GeoPrimaryRegion>
<StatusOfPrimary>[Available|Unavailable]</StatusOfPrimary>
<LastGeoFailoverTime>DateTime</LastGeoFailoverTime
<GeoSecondaryRegion>secondary-region</GeoSecondaryRegion
<StatusOfSecondary>[Available|Unavailable]</StatusOfSecondary>

VM ディスクとジオフェールオーバー
  • VM ディスクのセクションで説明したように、フェールオーバー後の VM ディスク間でデータに一貫性の保証はありません。バックアップの精度を確認するために、Data Protection Manager などのバックアップ製品を使用してアプリケーション データのバックアップと復元を行う必要があります。

データベース

SQL データベース (災害復旧)

Azure SQL データベース の復旧は、Azure SQL データベース のインポートおよびエクスポート サービスを使用してデータベースを Azure ストレージ BLOB にエクスポートすることによって実現できます。これは 3 とおりの方法で実行できます。

  • 別のデータ センターのストレージ アカウントを使用して BLOB にエクスポートする

  • 同じデータ センター内のストレージ アカウントを使用して BLOB にエクスポートします (さらに、Windows Azure ストレージの地理分散システムを使用して別のデータ センターにコピーします)。

  • オンプレミスの SQL Server にインポートします。

詳細については、MSDN の「Windows Azure SQL データベースにおけるビジネス継続性」を参照してください。

仮想マシンでの SQL Server (災害復旧)

IaaS 上で実行されている SQL Server データベースを代替の Windows Azure データセンターで復旧するには、データベースのミラーリングとストレージ BLOB での復元の 2 つのオプションがあります。今回の SQL Server 2012 可用性グループは Windows Azure データセンター間でサポートされていません。それは、現時点でデータセンター間の仮想ネットワークが Windows Azure でサポートされておらず、Active Directory ドメインを複数の Windows Azure データセンターにまたがって配置できないためです。

災害復旧のためにデータベース ミラーリングを使用する場合は、プリンシパル サーバーとミラー サーバーを異なる Windows Azure データセンターで実行する必要があります。これは、サーバー証明書を使用して配置する必要があることを意味します。これは、Active Directory ドメインが複数の Windows Azure データセンターにわたるためには、内部設置型のネットワーク経由でトラフィックのルーティングが必要であるためです。次の図は、この設定を示しています。

Windows Azure データベース ミラーリング (DR)

もう 1 つのオプションは、標準バックアップを使用し、Windows Azure ストレージ BLOB に復元します。

Windows Azure ブログへバックアップ

詳細については、「Windows Azure の仮想マシン内の SQL Server の高可用性と災害復旧」を参照してください。

その他の Windows Azure Platform サービス

Windows Azure の複数の地域でクラウド サービスを実行しようとする場合、依存関係ごとに影響について検討する必要があります。次のセクションでは、サービスに固有のガイダンスでは代替の Windows Azure データセンターにおいては同じ Windows Azure サービスを使用する必要があると想定されています。これには、構成タスクとデータ レプリケーション タスクの両方があります。

場合によっては、これらの手順はデータセンター イベント全体ではなく、サービス固有の障害を軽減するために役立つ可能性があります。アプリケーションの観点からは、サービス固有の障害は単に制限的なもので、サービスを代替の Windows Azure の地域へ一時的に移行する必要があります。

アクセス制御サービス (災害復旧)

アクセス制御サービス (ACS) は、Windows Azure の地域にまたがらない一意の名前空間名を使用します。ACS 2.0 では、すべての名前空間が 1 日に 1 回、オフサイトの安全な場所にバックアップされます。障害が発生した場合、ACS 操作スタッフが最新のバックアップを使用して離れた Windows Azure の地域にある顧客のサブスクリプションを復元しようと試みることができます。バックアップの頻度のために、最大 24 時間分のデータ損失が発生する可能性があります。地域的なフェールオーバーには SLA がなく、復旧時間はシナリオによっては数日かかる場合があります。

代替地域で ACS を使用するには、その地域の ACS 名前空間を構成する必要があります。ACS 2.0 を使用していてデータ損失の可能性を懸念される場合は、「ACS 管理サービス」を確認することをお勧めします。このインターフェイスは管理者が名前空間を管理し、すべての関連データのインポートおよび抽出を可能にします。このインターフェイスを使用することによって、現在の ACS が提供するものを上回る、高いレベルのデータの一貫性を実現するカスタム バックアップおよび復元ソリューションを開発できます。その他の可用性の考慮事項については、"アクセス制御サービス (可用性)" を参照してください。

サービス バス (災害復旧)

ACS のように、サービス バスは、Windows Azure の地域にまたがらない一意の名前空間名を使用します。したがって、最初の要件は代替地域で必要なサービス バス名前空間を設定することです。ただし、キューに登録されたメッセージの持続性についても考慮事項があります。Windows Azure の地域間でメッセージをレプリケートするにはいくつかの方法があります。これらのレプリケーション方法とその他の災害復旧計画の詳細については、「Service Bus の障害および災害に対する Service Bus アプリケーションの保護」を参照してください。その他の可用性の考慮事項については、"サービス バス (可用性)" を参照してください。

Web サイト (災害復旧)

Windows Azure の Web サイトを Windows Azure のセカンダリ地域に移行するには、パブリッシュに使用できる Web サイトのバックアップが必要です。障害が Windows Azure データセンター全体を含んでいなければ、サイト コンテンツの最新のバックアップをダウンロードするために FTP を使用することができる場合があります。次に、容量を予約するために以前に Web サイトを作成していない場合は、代替地域で新しい Web サイトを作成します。サイトを新しい地域にパブリッシュし、必要な構成の変更を行います。これらの変更には、データベース接続文字列またはその他の地域固有の設定が含まれる場合があります。必要に応じて、サイトの SSL 証明書を追加し、DNS の CNAME レコードを変更して、カスタム ドメイン名が再配置された Windows Azure の Web サイトの URL を参照するようにします。

モバイル サービス (災害復旧)

Windows Azure のセカンダリ地域で、アプリケーションのバックアップ モバイル サービスを作成します。代替地域にも SQL データベース を復元します。次に、Windows Azure コマンド ライン ツールを使用して、モバイル サービスを代替地域へ移動します。次に、復元したデータベースを使用するようにモバイル サービスを構成します。このプロセスの詳細については、「障害が発生した場合にモバイル サービスを復旧する」を参照してください。その他の可用性の考慮事項については、"モバイル サービス (可用性)" を参照してください。

HDInsight (災害復旧)

HDInsight に関連付けられているデータは、既定では Windows Azure BLOB ストレージに保存されます。HDInsight では、MapReduce ジョブを処理する Hadoop クラスターは分析されているデータを保持するストレージ アカウントと同じ地域に併置する必要があります。Windows Azure ストレージに利用可能なジオレプリケーション機能を使用すると、何らかの理由によりプライマリ地域が使用できなくなった場合、データがレプリケートされたセカンダリ地域のデータにアクセスできます。データがレプリケートされ、処理を継続する地域で新しい Hadoop クラスターを作成することができます。その他の可用性の考慮事項については、"HDInsight (可用性)" を参照してください。

SQL レポート (災害復旧)

現時点では、Windows Azure の地域の損失からの復旧には、異なる Windows Azure の地域における複数の SQL レポート インスタンスが必要です。これらの SQL レポート インスタンスは、同じデータにアクセスする必要があり、そのデータには災害が発生した場合の独自の復旧計画が必要です。また、各レポートに RDL ファイルの外部バックアップ コピーを保持できます。

メディア サービス (災害復旧)

Windows Azure メディア サービスには、エンコードとストリーミングのために異なる復旧方法があります。通常、ストリーミングは地域的な障害が発生している場合にはより重要になります。これに備えて、2 つの異なる Windows Azure の地域にメディア サービス サービス アカウントを用意する必要があります。エンコードされた内容は、両方の地域に配置される必要があります。障害時には、ストリーミング トラフィックを代替地域にリダイレクトできます。エンコードは任意の Windows Azure の地域で実行できます。ライブ イベントの処理中など、エンコードが時間の影響を受ける場合、ジョブを障害中に代替のデータセンターへ送信する準備をしておく必要があります。

仮想ネットワーク (災害復旧)

構成ファイルを使用すると、代替の Windows Azure の地域で仮想ネットワークを最も速く設定できます。Windows Azure のプライマリ地域で仮想ネットワークを構成した後、ネットワーク構成ファイルに現在のネットワークの仮想ネットワーク設定のネットワーク構成ファイルへのエクスポートを行います。プライマリ地域で障害が発生した場合、保存された構成ファイルからネットワーク構成ファイルのインポートを行います。次に、その他のクラウド サービス、仮想マシン、またはクロスプレミス設定を構成して、新しい仮想ネットワークで作業します。

チェック リスト: 災害復旧

 

サービス/地域 チェックリスト

コンピューティング (PaaS)

  • 複数の地域にわたる災害復旧方法を作成する。

  • 代替地域の容量の予約においてのトレードオフを理解する。

  • Windows Azure Traffic Manager (CTP) などのトラフィック ルーティング ツールを使用する。

仮想マシン (IaaS)

  • BLOB の VM ディスク リソースを代替データセンターにコピーする。

  • VM ディスクまたはディスク コンテンツの定期的なバックアップを実行する。

ストレージ

  • ストレージ リソースのジオレプリケーションを無効にしない。

  • フェールオーバーが発生した場合のジオレプリケーションの代替地域を理解する。

  • ユーザー制御のフェールオーバー方法のカスタム バックアップ方法を作成する。

SQL データベース (災害復旧)

  • SQL データベース を BLOB ストレージにエクスポートする。

  • 前のストレージについての考慮事項に基づいて災害復旧計画を作成する。

仮想マシンでの SQL Server (災害復旧)

  • 複数の地域にわたるデータベース ミラーリングを使用する。

  • または、バックアップを使用して、BLOB ストレージに復元する。

アクセス制御サービス (災害復旧)

  • 代替地域で ACS 名前空間を構成する。

  • ACS 2.0 管理サービスを使用して、カスタム バックアップ ソリューションを作成する。

サービス バス (災害復旧)

  • 代替地域のサービス バス名前空間を構成する。

  • 地域間のメッセージのカスタム レプリケーションの方法を検討する。

Web サイト (災害復旧)

  • プライマリ地域の外部で Web サイトのバックアップを保持する。

  • 障害が部分的である場合は、FTP で現在のサイトの取得を試みる。

  • 代替地域で新しいまたは既存の Web サイトに Web サイトを配置するための計画を立てる。

  • アプリケーションおよび DNS の CNAME レコードの両方の構成変更を計画する。

モバイル サービス (災害復旧)

  • 代替地域のバックアップ モバイル サービスを作成する。

  • 関連付けられた SQL データベース のバックアップを保持して、フェイルオーバー中に復元する。

  • Windows Azure コマンドライン ツールを使用してモバイル サービスを移動する。

HDInsight (災害復旧)

  • レプリケートされたデータのある地域で新しい Hadoop クラスターを作成する。

SQL レポート (災害復旧)

  • 別の地域での代替の SQL レポート インスタンスを保持する。

  • その地域に対象をレプリケートする別の計画を保持する。

メディア サービス (災害復旧)

  • 代替地域でメディア サービス アカウントを作成する。

  • 両方の地域で同じ内容をエンコードして、ストリーム フェールオーバーをサポートする。

  • 障害の場合には、エンコード ジョブを代替地域に送信する。

仮想ネットワーク (災害復旧)

  • エクスポートされた仮想ネットワーク設定を使用して、別の地域でテーブルを再作成する。

3.内部設置型から Windows Azure への復旧

Windows Azure では、高可用性および災害復旧のために内部設置型のデータセンターの Windows Azure への拡張を有効にするサービスの包括的なセットをご用意しています。

  • ネットワーク: 仮想プライベート ネットワークで、内部設置型のネットワークをクラウドに安全に拡張します。

  • コンピューティング: 内部設置型の Hyper-V を使用すると、既存の VM を Windows Azure に移行 (リフト アンド シフト) することができます。

  • ストレージ: StorSimple はファイル システムを Windows Azure ストレージに拡張します。Windows Azure バックアップ サービスには、ファイルと SQL データベース の Windows Azure ストレージへのバックアップが用意されています。

  • データベース レプリケーション: SQL 2012 可用性グループを使用して、内部設置型データの高可用性と災害復旧を実行できます。

ネットワーク

Windows Azure 仮想ネットワークによって、Windows Azure に論理的に独立しているセクションを作成し、IPsec 接続を使用して、内部設置型のデータセンターまたは単一のクライアント コンピューターに安全に接続することができます。仮想ネットワークを使用すると、Windows Server、メインフレーム、および UNIX で実行中のシステムなど、内部設置型のデータおよびアプリケーションへの接続性を提供しながら、Windows Azure のスケーラブルなオンデマンドのインフラストラクチャを簡単に活用できます。詳細については、こちらを参照してください。

コンピューティング

内部設置型の Hyper-V を使用すると、VM への変更や VM 形式への変換を行わずに、既存の VM を Windows Server 2012 を実行している Windows Azure & サービス プロバイダーに移行 (リフト アンド シフト) できます。詳細については、「ディスクおよびイメージの管理」を参照してください。

ストレージ

内部設置型のデータのバックアップ サイトとして Azure を使用するためには、いくつかのオプションがあります。

StorSimple

StorSimple は内部設置型のアプリケーションのクラウド ストレージを安全で透過的に統合し、 高パフォーマンスの階層になったローカルおよびクラウド ストレージ、ライブ アーカイブ、クラウドベースのデータ保護と災害復旧を実現する単一のアプライアンスを提供します。詳細については、「StorSimple - クラウドに統合されたストレージ - 内容 & 理由」を参照してください。

Windows Azure Backup サービス

Windows Azure Backup サービスは、Windows Server 2012、Windows Server 2012 Essentials、および System Center 2012 Data Protection Manager で慣れ親しんだバックアップ ツールを使用してクラウド バックアップを可能にします。これらのツールは、バックアップの保存場所 (ローカル ディスクまたは Windows Azure ストレージ) に依存せずにバックアップ管理のためのワークフローを提供します。クラウドにデータをバックアップした後は、権限を与えられたユーザーがバックアップを任意のサーバーに簡単に回復できます。

増分バックアップにより、ファイルの変更部分だけがクラウドに転送されます。そうすることで、ストレージ領域の効率的な使用、帯域幅の消費の削減、および複数のバージョンのデータの特定の時点へのサポートが可能になります。また、データ保持ポリシー、データ圧縮、データ転送調整などの追加機能の使用も選択できます。Windows Azure をバックアップの場所として使用すると、バックアップが自動的に "オフサイト" であるという明白な利点があります。これによって、オンサイトのバックアップ メディアをセキュリティで保護するための特別の要件が必要なくなります。詳細については、「Windows Azure Backup の概要」および「Windows Azure Backup で DPM を構成する」を参照してください。

データベース

AlwaysOn 可用性グループ、データベース ミラーリング、ログ配布、および Windows Azure BLOB ストレージを使用したバックアップと復元を使用して、ハイブリッド IT 環境の SQL Server データベースの災害復旧ソリューションを実現できます。これらのソリューションはすべて Windows Azure の仮想マシンで実行される SQL Server を使用します。

AlwaysOn 可用性グループは、データベース レプリカが社内とクラウド内の両方に存在するハイブリッド IT 環境で使用できます。これは、次の図に示されており、詳細な解説記事である「Windows Azure の仮想マシン内の SQL Server の高可用性と災害復旧」から引用したものです。

ハイブリット IT AlwaysOn 可用性グループ

データベース ミラーリングも、内部設置型のサーバーおよびこの証明書ベースの設定のクラウドで行うことができます。次の図は、この概念を示しています。

ハイブリット IT データベース ミラーリング

ログ配布は、内部設置型のデータベースを Windows Azure の仮想マシンの SQL Server データベースと同期するために使用できます。

ハイブリット IT ログ配布

最後に、内部設置型のデータベースを Windows Azure BLOB ストレージに直接バックアップできます。

ハイブリット IT ブログへバックアップ

詳細については、「Windows Azure の仮想マシン内の SQL Server の高可用性と災害復旧」および「Windows Azure の仮想マシンにおける SQL Server のバックアップと復元」を参照してください。

チェック リスト: 内部設置型のシナリオ

 

サービス/地域 チェックリスト

ネットワーク

  • 仮想ネットワークを使用して、内部設置型のデータベースをクラウドに安全に接続する。

コンピューティング

  • Hyper-V と Windows Azure の間に VM を再配置する。

ストレージ

  • クラウド ストレージを使用するために StorSimple サービスを利用する。

  • Windows Azure Backup サービスを使用する。

データベース

  • バックアップとして Windows Azure VM 上での SQL Server の使用を検討する。

  • AlwaysOn 可用性グループを設定する。

  • 証明書ベースのデータベース ミラーリングを構成する。

  • ログ配布を使用する。

  • 内部設置型のデータベースを Windows Azure BLOB ストレージにバックアップする。

4.データの破損または偶発的な削除からの復旧

このシナリオは、アプリケーション エラーまたはオペレーターのエラーによって破損したデータまたは誤って削除されたデータの復旧についてのものです。

ストレージ

Windows Azure ストレージでは、自動レプリカによってデータの回復力が提供されますが、アプリケーション コードで (または開発者やユーザーによって) データが誤って (意図せず) 削除されたり更新されたりした場合のデータの破損を防ぐことはできません。アプリケーション エラーやユーザー エラーが発生した場合にデータの忠実性を維持するには、より高度なテクニックを使用する必要があります (データを監査ログと共にセカンダリ ストレージにコピーするなど)。開発者は、Snapshot Blob (REST API) を利用して、BLOB のコンテンツの特定の時点での読み取り専用スナップショットを作成することができます。これは BLOB のデータ忠実性ソリューションの基礎として使用できます。

BLOB ストレージとテーブル ストレージのバックアップ

BLOB とテーブルは持続性に優れていますが、常にデータの現在の状態を表します。データの意図しない変更や削除から復旧するために、データを以前の状態に復元することが必要になる場合があります。これは、Windows Azure によって提供される機能を使用して、特定の時点のコピーを保存して保持することによって実現できます。

Windows Azure BLOB で特定の時点のバックアップを実行するには、BLOB のスナップショット機能を使用できます。各スナップショットで発生する料金は、BLOB の前回のスナップショットの状態からの差分を格納するために必要なストレージの料金だけです。スナップショットは基になる元の BLOB に依存しているため、バックアップ データが誤って削除されても問題にならないように別の BLOB (さらには別のストレージ アカウント) にコピーすることをお勧めします。Windows Azure テーブルでは、別のテーブルまたは Windows Azure BLOB に特定の時点のコピーを作成することができます。テーブルと BLOB のアプリケーション レベルのバックアップの詳しい実行方法と例については、次のドキュメントを参照してください。

データベース

SQL データベース には、いくつかの Windows Azure SQL データベースにおけるビジネス継続性 (バックアップ、復元) オプションを使用できます。データベースは、データベース コピー機能または DAC インポート/エクスポート サービスを使用してコピーできます。データベース コピーではトランザクションの一貫性が確保されますが、bacpac (インポート/エクスポート サービスを使用) では確保されません。これらのオプションはどちらも、データ センター内のキューに基づくサービスとして実行されます。現時点では、完了に要する時間の SLA は提供されていません。

note
データベース コピーとインポート/エクスポート サービスでは、ソース データベースの負荷がかなり高くなるため、リソースの競合や調整イベントが発生する可能性があります (次のセクションの「共有リソースと調整」で説明します)。

SQL データベースのバックアップ

Windows Azure SQL データベース の特定の時点のバックアップを実行するには、Windows Azure SQL データベースのコピー コマンドを使用します。このコマンドを使用すると、トランザクション全体で一貫性のあるデータベースのコピーを同じ論理データベース サーバーまたは別のサーバーに作成できます。いずれの場合も、コピー元のデータベースから完全に独立した、正常に機能するデータベースのコピーが作成されます。作成されたコピーは、それぞれ特定の時点への復旧のオプションを表します。新しいデータベースの名前をコピー元のデータベースの名前に変更することで、データベースの状態を完全に復元できます。または、Transact-SQL クエリを使用して新しいデータベースからデータの特定の部分のみを復元することもできます。SQL Database の詳細については、「Windows Azure SQL データベースにおけるビジネス継続性」を参照してください。

仮想マシンの SQL Server のバックアップ (IaaS)

IaaS の SQL Server には、従来のバックアップとログ配布の 2 つのオプションがあります。従来のバックアップを使用すると特定の時点に復元することができますが、復旧プロセスには時間がかかります。従来のバックアップを復元すると、最初の完全バックアップで開始し、次に、その後で作成されたバックアップを適用する必要があります。2 つ目のオプションは、ログ配布セッションを構成してログ バックアップの復元を遅延させます (2 時間単位など)。これには、プライマリで作成されたエラーから復旧するためのウィンドウが用意されています。

その他の Windows Azure Platform サービス

Windows Azure Platform サービスには、ユーザー制御のストレージ アカウントまたは SQL データベース に情報を保存するものがあります。アカウントまたはストレージ リソースが削除されたり、破損したりしている場合、これにより、サービスに重大なエラーが発生する可能性があります。このような場合、リソースが削除されたり、破損したりしているのであれば、これらを再作成できるバックアップを管理することが重要です。

Windows Azure の Web サイトや Windows Azure モバイル サービスには、関連するデータベースをバックアップし、管理する必要があります。Windows Azure メディア サービスと仮想マシンには、関連付けられた Windows Azure ストレージ アカウントとそのアカウント内のすべてのリソースを管理する必要があります。たとえば、仮想マシンには、Windows Azure BLOB ストレージの VM ディスクをバックアップして管理する必要があります。

チェック リスト: データの破損または偶発的な削除

 

サービス/地域 チェックリスト

ストレージ

  • 重大なストレージのリソースを定期的にバックアップする。

  • BLOB のスナップショット機能を使用することを検討する。

データベース

  • Database Copy コマンドを使用して特定の時点へのバックアップを作成する。

仮想マシンの SQL Server のバックアップ (IaaS)

  • 従来のバックアップと復元の方法を使用する。

  • 遅延ログ配布セッションを作成した。

Web サイト

  • 関連するデータベースが存在する場合は、バックアップして管理する。

モバイル サービス

  • 関連するデータベースをバックアップして、管理する。

メディア サービス

  • 関連付けられたストレージ リソースをバックアップして、管理する。

仮想マシン

  • BLOB ストレージの VM ディスクをバックアップして、管理する。

5.その他のリソース

フェールセーフ: 回復力のあるクラウド アーキテクチャに関するガイダンス: 回復力のあるクラウド アーキテクチャを構築するためのガイダンス、それらのアーキテクチャを Microsoft テクノロジ上に実装するためのガイダンス、およびそれらのアーキテクチャを特定のシナリオで実装するための秘訣を提供することを目的としています。

Windows Azure アプリケーションの災害復旧と高可用性: 可用性と災害復旧の詳細な概要。これは参照用データおよびトランザクション データの手動レプリケーションの問題について説明します。最後のセクションでは、可用性の最上位レベルの Windows Azure データセンター間のさまざまな種類の DR トポロジの概要を説明します。

Windows Azure SQL データベースにおけるビジネス継続性: バックアップと復元方法を主に中心とする、可用性についての Windows Azure SQL データベース の可用性のテクニックにのみ焦点を合わせます。クラウド サービスで SQL データベース を使用している場合、この記事および関連するリソースを確認する必要があります。

Windows Azure の仮想マシン内の SQL Server の高可用性と災害復旧: データベース サービスをホストするためにサービスとしてのインフラストラクチャ (IaaS) を使用する場合に利用できる可用性オプションについて説明します。ここでは AlwaysOn 可用性グループ、データベース ミラーリング、ログ配布、およびバックアップと復元について説明します。同じセクションに、これらのテクノロジの使用方法を示すいくつかのチュートリアルがあります。

Windows Azure クラウド サービスで大規模なサービスを設計するためのベスト プラクティス: 高度にスケーラブルなクラウド アーキテクチャの開発に注目して説明します。スケーラビリティを向上させるために使用する技法の多くは、可用性も向上させます。また、負荷が増加してアプリケーションが拡張できない場合は、スケーラビリティは可用性の問題になります。

Windows Azure の仮想マシンにおける SQL Server のバックアップと復元

寄稿者および校閲者

Luis Carlos Vargas Herring、Drew McDaniel、David Magar、Ganesh Srinivasan、Milan Gada、Nir Mashkowski、Harsh Mittal、Sasha Nosov、Selcin Turkarslan、Cephas Lin、Cheryl McGuire、Bill Mathers、Mandi Ohlinger、Sidney Higa、Michael Green、Heidi Steen、Matt Winkler、Shayne Burgess、Larry Franks、Brad Severtson、Yavor Georgiev、Glenn Gailey、Tim Ammann、Ruppert Koch、Seth Manheim、Abhinav Gupta、Steve Danielson、Corey Sanders、John Deutscher


ビルド日:

2013-11-04
この情報は役に立ちましたか。
(残り 1500 文字)
フィードバックをいただき、ありがとうございました

コミュニティの追加

追加
表示:
© 2014 Microsoft. All rights reserved.