エクスポート (0) 印刷
すべて展開
11 人のうち 6 人が、役に立ったと評価しています - このトピックを評価する

Windows Azure の仮想マシン内の SQL Server の高可用性と災害復旧

更新日: 2013年8月

Windows Azure の仮想マシン (VM) と SQL Server の組み合わせを使用すると、データベース管理者は HADR (High Availability and Disaster Recovery) データベース システムのコストを削減できます。SQL Server で使用可能なほとんどの HADR ソリューションは、クラウド ソリューションとハイブリッド IT ソリューションとしての両方として、Windows Azure の仮想マシンでサポートされます。クラウド データベース ソリューションでは、HADR システム全体が Windows Azure で実行されます。クライアント アプリケーションは、Windows Azure 内から、またはインターネット (たとえば、オンプレミス ネットワーク) から HADR システムに接続できます。ハイブリッド IT データベース ソリューションでは、HADR のシステムの一部が Windows Azure で実行され、システムの残りの部分は組織内のオンプレミスで実行されます。Windows Azure 環境は柔軟性が高いため、SQL Server データベース システムの予算と HADR の要件に合わせて、部分的または完全にクラウドに移行することができます。

Windows Azure の仮想マシンでの SQL Server HADR ソリューションの必要性

Windows Azure VM で SQL Server を実行する場合は、データベース システムがサービス レベル契約 (SLA) で求められる HADR 機能を備えていることをデータベース管理者が確認する必要があります。クラウド サービスにおけるサービスの修復や仮想マシンにおける障害復旧検出など、Windows Azure は高可用性メカニズムを提供しますが、それ自体で SQL Server の目的の HADR 機能が保証されるわけではありません。このようなメカニズムは、VM の高可用性を保護するものであり、VM で実行される SQL Server の高可用性を保護するものではありません。VM がオンラインで正常なときに SQL Server インスタンスに障害が発生する可能性もあります。さらに、Windows Azure によって提供される高可用性メカニズムにおいても、ソフトウェア/ハードウェア障害からの復旧、オペレーティング システムのアップグレードなどのイベントが原因で、VM の長時間のダウンタイムが発生する可能性があります。

また、Windows Azure の地理冗長ストレージ (GRS、ジオレプリケーションとも呼ばれます) は、お使いのデータベースにとって適切な災害復旧ソリューションでない可能性もあります。ジオレプリケーションでは、ディスク障害後の Windows Azure ディスクの復旧時間やデータの損失を制御することはできません。つまり、SQL Server 災害復旧ソリューションの 1 つで可能であった、障害時の RTO と RPO を制御することはできません。ジオレプリケーションの制限事項の詳細については、「別個のディスク上のデータ ファイルおよびログ ファイルに対してはジオレプリケーションがサポートされない」で説明します。

HADR デプロイ アーキテクチャ

Windows Azure でサポートされている SQL Server 製品の HADR テクノロジは次のとおりです。

テクノロジを組み合わせることにより、クラウドのみの環境またはハイブリッド IT 環境で、高可用性と災害復旧機能の両方を備えた SQL Server ソリューションを実装することができます。使用するテクノロジによっては、ハイブリッド IT デプロイにおいて Windows Azure 仮想ネットワークを使用した VPN トンネルが必要になる場合があります。以降のセクションでは、デプロイ アーキテクチャの例をいくつか紹介します。

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

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

 

テクノロジ サンプル アーキテクチャ

AlwaysOn 可用性グループ

Windows Azure VM 内ですべての可用性レプリカを実行して、同じ Windows Azure データセンター内の高可用性を実現します。Windows サーバー フェールオーバー クラスタリング (WSFC) では Active Directory ドメインが必要となるため、SQL Server 仮想マシンに加えてドメイン コントローラーを構成する必要があります。

Windows Azure AlwaysOn 可用性グループ

詳細については、「チュートリアル: Windows Azure AlwaysOn 可用性グループ (GUI)」を参照してください。

データベース ミラーリング

プリンシパル サーバー、ミラー サーバー、およびミラーリング監視サーバーをすべて同じ Windows Azure データセンターで実行して、高可用性を実現します。ドメイン コントローラーを使用してデプロイできます。

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

代わりにサーバー証明書を使用することにより、ドメイン コントローラーを使用せずに同じデータベース ミラーリング構成をデプロイすることもできます。

Windows Azure 証明付きデータベース ミラーリング

詳細については、「チュートリアル: Windows Azure で高可用性を実現するデータベース ミラーリング」を参照してください。

Windows Azure のみ: 災害復旧ソリューション

データベース ミラーリングまたはストレージ BLOB を使用したバックアップと復元を使用することにより、Windows Azure 内の SQL Server データベースの災害復旧ソリューションを実現できます。

複数の Windows Azure データセンターにわたる Windows Azure のみの可用性グループを構成することはできません。それは、現時点でデータセンター間の仮想ネットワークが Windows Azure でサポートされておらず、Active Directory ドメインを複数の Windows Azure データセンターにまたがって配置できないためです。

 

テクノロジ サンプル アーキテクチャ

データベース ミラーリング

プリンシパル サーバーとミラー サーバーを異なる Windows Azure データセンターで実行して、災害復旧を実現します。Active Directory ドメインを複数の Windows Azure データセンターにまたがってデプロイすることはできないため、サーバー証明書を使用してデプロイする必要があります。

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

詳細については、「チュートリアル: Windows Azure で災害復旧に備えるデータベース ミラーリング」を参照してください。

Windows Azure BLOB ストレージ サービスを使用したバックアップと復元

運用データベースを異なる Windows Azure データセンター内の BLOB ストレージに直接バックアップして、災害復旧を実現します。

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

詳細については、「Windows Azure の仮想マシンにおける SQL Server のバックアップと復元」を参照してください。

ハイブリッド IT: 災害復旧ソリューション

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

 

テクノロジ サンプル アーキテクチャ

AlwaysOn 可用性グループ

いくつかの可用性レプリカを Windows Azure VM で実行し、他のレプリカをオンプレミスで実行して、クロスサイトの災害復旧を実現します。運用サイトは、オンプレミスまたは Windows Azure データセンター内のどちらに配置してもかまいません。

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

すべての可用性レプリカは同一の WSFC クラスター内に存在する必要があるため、WSFC クラスターは両方のネットワーク (マルチサブネット WSFC クラスター) にまたがる必要があります。この構成には、Windows Azure とオンプレミス ネットワーク間の VPN 接続が必要になります。

データベースの災害復旧を正常に行うには、災害復旧サイトにレプリカ ドメイン コントローラーもインストールする必要があります。

詳細については、「チュートリアル: ハイブリット IT AlwaysOn 可用性グループ (PowerShell)」を参照してください。

データベース ミラーリング

  • 一方のパートナーを Windows Azure VM で実行し、他方のパートナーをオンプレミスで実行して、サーバー証明書を使用したクロスサイトの災害復旧を実現します。パートナーは同じ Active Directory ドメインに属している必要はなく、VPN 接続も必要ありません。

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

    詳細については、「チュートリアル: ハイブリッド IT で災害復旧に備えるデータベース ミラーリング」を参照してください。

  • 一方のパートナーを Windows Azure VM で実行し、他方のパートナーを同じ Active Directory ドメイン内のオンプレミスで実行して、クロスサイトの災害復旧を実現します。Windows Azure 仮想ネットワークとオンプレミス ネットワーク間の VPN 接続が必要です。

    データベースの災害復旧を正常に行うには、災害復旧サイトにレプリカ ドメイン コントローラーもインストールする必要があります。

ログ配布

Windows Azure の仮想マシンで一方のサーバーを実行し、オンプレミスで他方のサーバーを実行して、クロスサイトの災害復旧を実現します。ログ配布は Windows ファイル共有に依存するため、Windows Azure 仮想ネットワークとオンプレミス ネットワーク間の VPN 接続が必要になります。

ハイブリット IT ログ配布

データベースの災害復旧を正常に行うには、災害復旧サイトにレプリカ ドメイン コントローラーもインストールする必要があります。

詳細については、「チュートリアル: ハイブリッド IT で災害復旧に備えるログ配布」を参照してください。

Windows Azure BLOB ストレージ サービスを使用したバックアップと復元

オンプレミスの運用データベースを Windows Azure BLOB ストレージに直接バックアップして、災害復旧を実現します。

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

詳細については、「Windows Azure の仮想マシンにおける SQL Server のバックアップと復元」を参照してください。

Windows Azure 内の SQL Server HADR に関する重要な考慮事項

Windows Azure VM、ストレージ、およびネットワーキングは、オンプレミスの非仮想化 IT インフラストラクチャとは異なる動作特性を持ちます。Windows Azure 内に HADR SQL Server ソリューションを正常に実装するには、これらの違いを理解し、その違いを反映するようにソリューションを設計する必要があります。

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

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

Windows Azure VM を同じ可用性セットに配置するには、これらを同じクラウド サービスにデプロイする必要があります。同じクラウド サービスにデプロイされているノードのみが同じ可用性セットに属することができます。

Windows Azure ネットワーキングでの WSFC クラスターの動作

Windows Azure 内に RFC に準拠していない DHCP サービスがあると、クラスターのネットワーク名が重複する IP アドレス (クラスター ノードの 1 つと同じ IP アドレス) が割り当てられることが原因で、特定の WSFC クラスター構成の作成が失敗する可能性があります。これは、WSFC 機能に依存する AlwaysOn 可用性グループを実装する場合に問題になります。

2 ノードのクラスターが作成されてオンライン状態になる場合のシナリオについて説明します。

  1. クラスターがオンライン状態になると、NODE1 が、クラスターのネットワーク名に対して動的に割り当てられた IP アドレスを要求します。

  2. DHCP サービスは、その要求の発信元が NODE1 自体であると認識します。そこで、NODE1 の IP アドレス以外の IP アドレスは DHCP サービスによって与えられません。

  3. Windows によって、NODE1 とクラスター ネットワーク名の両方に対して重複するアドレスが割り当てられていることが検出されます。既定のクラスター グループはオンライン状態になることができません。

  4. 既定のクラスター グループが NODE2 に移行します。NODE2 では、NODE1 の IP アドレスがクラスターの IP アドレスとして処理され、既定のクラスター グループがオンラインになります。

  5. NODE2 が NODE1 との接続を確立しようとするとき、NODE1 の IP アドレスは NODE2 自体に解決されるため、NODE1 宛てのパケットは NODE2 を離れません。NODE2 は NODE1 との接続を確立できず、クォーラムを失い、クラスターをシャットダウンします。

  6. 一方、NODE1 は NODE2 にパケットを送信できますが、NODE2 は応答できません。NODE1 はクォーラムを失い、クラスターをシャットダウンします。

WSFC クラスター構成が異なると、Windows Azure DHCP サービスおよびネットワークとその特定の構成がやり取りする方法に基づいて、その動作も異なります。クラスター ネットワーク名をオンラインにするために未使用の静的 IP アドレス (たとえば、169.254.1.1 などのリンクにローカルな IP アドレス) をクラスター ネットワーク名に割り当てることによって、これらの動作を回避できます。その後、クラスター ネットワーク名を削除できます。クラスター ネットワーク名は可用性グループによって使用されないためです。このプロセスを簡略化する方法については、「AlwaysOn 可用性グループ向けに Windows Azure の Windows フェールオーバー クラスターを構成する方法」を参照してください。

Windows Azure AlwaysOn 可用性グループに関する次のチュートリアルでは、さまざまなシナリオで可用性グループを構成する方法を詳しく説明します。

可用性グループ リスナーのサポート

可用性グループのリスナーは、Windows Server 2012 を実行している Windows Azure VM でサポートされています。このサポートは、可用性グループ ノードである Windows Azure VM で Direct Server Return (DSR) が有効になっている負荷分散エンドポイントを使用すると、利用できるようになります。Windows Azure で実行しているクライアント アプリケーションとハイブリッド IT のオンプレミスで実行しているクライアント アプリケーションの両方に対して Windows Azure のリスナーを機能させるには、特別な構成手順に従う必要があります。クラウドのみの可用性グループの配置に対してリスナーを設定する手順については、「チュートリアル:Windows Azure での AlwaysOn 可用性グループのリスナー構成」を参照してください。

可用性グループのリスナーは、Windows Server 2008 R2 ではまだサポートされていません。ただし、サービス インスタンスに直接接続することによって、それぞれの可用性レプリカに個別に接続できます。また、AlwaysOn 可用性グループはデータベース ミラーリング クライアントと下位互換性があるため、次のようにレプリカがデータベース ミラーリングと同様に構成されている限り、データベース ミラーリング パートナーのように可用性レプリカに接続できます。

  • 1 つのプライマリ レプリカと 1 つのセカンダリ レプリカ。

  • セカンダリ レプリカが読み取り不可として構成されている ([読み取り可能なセカンダリ] オプションを [いいえ] に設定)。

このように ADO.NET または SQL Server Native Client を使用してデータベース ミラーリングと同様の構成を行った場合の、対応するクライアント接続文字列の例を次に示します。

Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;

クライアント接続の詳細については、次のトピックを参照してください。

ハイブリッド IT でのネットワーク待機時間

オンプレミス ネットワークと Windows Azure との間のネットワーク待機時間が長くなることを想定したうえで、適宜 HADR ソリューションをデプロイする必要があります。AlwaysOn 可用性グループをデプロイする場合は、クロスプレミス同期モードの場合、同期コミットではなく、非同期コミットを使用する必要があります。オンプレミスと Windows Azure の両方にデータベース ミラーリング サーバーをデプロイする場合は、高い安全性モードではなく高パフォーマンス モードを使用します。

仮想ディスクでは読み取り/書き込みキャッシュを使用しない

Windows Azure VM で SQL Server を実行する場合の一般的な推奨事項として、オペレーティング システム ディスク (C) または一時ディスク (D) を使用しないことが挙げられます。前者は 127 GB の制限があり、読み取りキャッシュと書き込みキャッシュの両方が既定で構成されます。これは、サーバーのパフォーマンスに悪影響を及ぼす可能性があります。後者の場合、仮想マシンの再起動後にデータが保持されません。したがって、一般的な推奨事項としては、読み取り/書き込みキャッシュが構成されていない別個のデータ ディスクを用意し、データベース ファイル用に使用します。別個のディスクを接続した場合、ディスク容量を最大で 1 TB までカスタマイズすることもできます。

データベース ファイルをオペレーティング システム ディスクに格納する必要がある場合は、VM のプロビジョニングを行うときに書き込みキャッシュを無効にすることをお勧めします。オペレーティング システム ディスクの読み取りキャッシュは無効にできません。

別個のディスク上のデータ ファイルおよびログ ファイルに対してはジオレプリケーションがサポートされない

Windows Azure ディスク内のジオレプリケーションでは、同じデータベースのデータ ファイルおよびログ ファイルを別個のディスクに格納できません。GRS では、各ディスクの変更が個別に非同期的にレプリケートされます。このメカニズムでは、ジオレプリケートされたコピーの単一のディスク内の書き込み順序が保証されますが、複数のディスクのジオレプリケートされたコピー間の書き込み順序は保証されません。データ ファイルとログ ファイルが別々のディスクに格納されるようにデータベースを構成すると、障害後の復旧されたディスクにログ ファイルよりも新しいデータ ファイルのコピーが含まれる可能性があります。その場合、SQL Server の先行書き込みログとトランザクションの ACID プロパティが破損します。ストレージ アカウントにジオレプリケーションを無効にするオプションがない場合は、特定のデータベースのすべてのデータ ファイルとログ ファイルを同じディスクに格納する必要があります。データベースのサイズが大きいため複数のディスクを使用する必要がある場合は、上記のいずれかの災害復旧ソリューションをデプロイして、データの冗長性を確保する必要があります。

参照

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

コミュニティの追加

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