エクスポート (0) 印刷
すべて展開

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

更新日: 2014年6月

Microsoft Azure の仮想マシン (VM) と SQL Server の組み合わせを使用すると、HADR (High Availability and Disaster Recovery) データベース ソリューションのコストを削減できます。ほとんどの SQL Server HADR ソリューションは、Azure 専用として、およびハイブリッド ソリューションとして、Azure の仮想マシンでサポートされます。Azure 専用ソリューションでは、HADR システム全体が Azure で実行されます。ハイブリッド構成では、ソリューションの一部が Azure で実行され、残りの部分は組織内のオンプレミスで実行されます。Azure 環境は柔軟性が高いため、SQL Server データベース システムの予算と HADR の要件に合わせて、部分的または完全に Azure に移行することができます。

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

また、Azure の地理冗長ストレージ (GRS) は、ジオレプリケーションと呼ばれる機能と一緒に実装されますが、お使いのデータベースにとって適切な災害復旧ソリューションでない可能性もあります。ジオレプリケーションではデータが非同期的に送信されるので、災害発生時に最新の更新内容が失われる恐れがあります。ジオレプリケーションの制限事項の詳細については、「別個のディスク上のデータ ファイルおよびログ ファイルに対してはジオレプリケーションがサポートされない」セクションを参照してください。

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

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

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

 

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

AlwaysOn 可用性グループ

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

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

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

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

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

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

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

 

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

AlwaysOn 可用性グループ

Azure 内の複数のデータセンターにまたがって実行される可用性レプリカによって災害復旧を実現します。この複数の地域にわたるソリューションは、完全なサイトの停止から保護されます。

地域内では、すべてのレプリカが同じクラウド サービスおよび同じ VNet 内に配置される必要があります。各地域には個別の VNet が設置されるので、これらのソリューションでは VNet 間接続が必要です。詳細については、「VNet 間の接続の構成」を参照してください。

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

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

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

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

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

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

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

 

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

AlwaysOn 可用性グループ

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

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

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

詳細については、「Tutorial: AlwaysOn Availability Groups in Hybrid IT」を参照してください。

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

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



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

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

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

ログ配布

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

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

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

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

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

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

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

Azure 内の可用性セットを使用して、高可用性ノードを別個のフォールト ドメイン (FD) およびアップグレード ドメイン (UD) に配置できます。Azure VM を同じ可用性セットに配置するには、これらを同じクラウド サービスにデプロイする必要があります。同じクラウド サービスにデプロイされているノードのみが同じ可用性セットに属することができます。詳細については、「仮想マシンの可用性の管理」を参照してください。

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 はクォーラムを失い、クラスターをシャットダウンします。

クラスター ネットワーク名をオンラインにするために未使用の静的 IP アドレス (たとえば、169.254.1.1 などのリンクにローカルな IP アドレス) をクラスター ネットワーク名に割り当てることによって、このシナリオを回避できます。このプロセスを簡略化する方法については、「AlwaysOn 可用性グループ向けに Azure の Windows フェールオーバー クラスターを構成する方法」を参照してください。

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

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

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

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

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

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

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

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

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

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

関連項目

表示:
© 2014 Microsoft