次の方法で共有

Azure VM 上の SQL Server のビジネス継続性と HADR

  • [アーティクル]

適用対象: Azure VM 上の SQL Server

この記事では、Azure Virtual Machines (VM) 上の SQL Server を使用して高可用性とディザスター リカバリー (HADR) に使用できる Azure 専用ソリューションとハイブリッド ビジネス継続性ソリューションを比較対照します。

ビジネス継続性とは、障害発生時にビジネスを継続し、復旧の計画を立て、データの高可用性を確保することを意味します。 Azure Virtual Machines 上の SQL Server は、高可用性とディザスター リカバリー (HADR) データベース ソリューションのコストを削減するのに役立ちます。

Note

Azure Migrate を使用すれば、フェールオーバー クラスター インスタンスと可用性グループのソリューションを Azure VM 上の SQL Server にリフト アンド シフトできます。

概要

Azure VM 上の SQL Server では、次の種類のソリューションがサポートされています。

  • Azure のみ: HADR システム全体が Azure で実行されます。
  • ハイブリッド: ソリューションの一部が Azure で実行され、他の部分は組織内のオンプレミスで実行されます。

Azure 環境は柔軟性が高いので、SQL Server データベース システムの予算や HADR 要件に応じて、部分的に、または完全に Azure に移動できます。 データベースシステムの HADR 機能は、目標復旧時間 (RTO)、目標復旧時点 (RPO)、およびサービス レベル アグリーメント (SLA) のビジネス要件を満たすように選択する必要があります。

クラウド サービスのサービス復旧、仮想マシンの障害復旧検出など、Azure が提供する組み込みの高可用性メカニズムは、 SLA を満たせることが保証されるわけではありません。 これらのメカニズムは仮想マシンの高可用性の保護に役立ちますが、VM 内で実行される SQL Server の可用性は保護されません。 VM がオンラインで正常であっても、SQL Server インスタンスで障害が発生する可能性があります。 Azure によって提供される高可用性メカニズムでも、ソフトウェアまたはハードウェアの障害からの回復やオペレーティング システムのアップグレードなどのイベントのために、VM のダウンタイムが生じます。

ビジネス継続性の特徴

次の表は、高可用性 (HA)、ディザスター リカバリー (DR)、またはその両方 (HA/DR) に使用できる Azure 専用機能とハイブリッド SQL Server 機能の両方を示しています。

これらの SQL Server 機能は、Azure のみの構成とハイブリッド構成の両方でビジネス継続性のためにサポートされています。 高可用性とディザスター リカバリー (HA/DR)、高可用性 (HA) の両方に最適なオプションもあれば、ディザスター リカバリー (DR) に使用されるオプションもあります。

SQL Server 機能 HA/DR のオプション 詳細
Always On 可用性グループ 高可用性とディザスター リカバリー 異なる可用性ゾーンやリージョンにレプリカを追加することで、データベース レベルの保護を提供し、高可用性とディザスター リカバリーを強化します。
Always On フェールオーバー クラスター インスタンス (FCI) 高可用性 共有ストレージを使用して、インスタンス レベルで保護を提供します。 可用性グループと組み合わせることで、データベースとインスタンスの両方のレベルに対する保護を強化します。
ログ配布 障害復旧 ディザスター リカバリーのデータベース レベルの保護には、プライマリ サーバーからトランザクション ログ バックアップを送信し、それらをセカンダリ サーバーに復元することが含まれます。 Azure ファイル共有が必要です。
Azure Blob Storage を使った SQL Server のバックアップと復元 障害復旧 ディザスター リカバリー保護のために Azure Blob Storage に保存されている運用データベース バックアップ。
Azure Site Recovery 障害復旧 VM をプライマリ サイトからセカンダリ サイトにレプリケートするディザスター リカバリー ソリューション。

テクノロジを組み合わせて、高可用性とディザスター リカバリーの両方の機能を備えた SQL Server ソリューションを実装することができます。 使用するテクノロジによっては、ハイブリッド デプロイで、Azure 仮想ネットワークを使った VPN トンネルが必要になる場合があります。 テクノロジは同じですが、Azure またはハイブリッド設計での設定方法にはいくつかの違いがある可能性があります。

可用性グループ (HADR)

Azure VM 上の SQL Server をデータベース レベルで保護するには、高可用性とディザスター リカバリー (HADR) ソリューションとして可用性グループを使用します。 同じリージョン内の Azure VM で実行している可用性レプリカにより、高可用性が実現されます。 Windows フェールオーバー クラスタリングには Active Directory ドメインが必要であるため、ドメイン コントローラー VM が必要です。

プライマリ レプリカ、セカンダリ レプリカ、およびファイル共有監視で構成される WSFC クラスター上のドメイン コントローラーを示す図。

開始するには、可用性グループのチュートリアルを確認してください。

可用性グループの概要に記載されているように、冗長性、可用性、ディザスター リカバリー保護を高めるために、Azure VM をさまざまな可用性ゾーンにデプロイできます。 Azure VM の複数のデータセンターで実行できるように可用性レプリカを拡張すると、ディザスター リカバリーの範囲がさらに広がります。 この複数のリージョンにわたるソリューションは、サイト全体の停止から保護するのに役立ちます。

プライマリ レプリカとセカンダリ レプリカが 非同期コミットによって接続されている 2 つのリージョンを示す図。

リージョン内では、すべてのレプリカが同じクラウド サービスおよび同じ仮想ネットワーク内にある必要があります。 各リージョンには個別の仮想ネットワークがあるため、これらのソリューションにはネットワーク間の接続が必要です。 詳細については、Azure portal を使用したネットワーク間接続の構成に関するページを参照してください。 詳細については、さまざまな Azure リージョンに存在する SQL Server Always On 可用性グループの構成に関するページを参照してください。

ハイブリッド構成では、一部の可用性レプリカが Azure VM で実行され、他のレプリカがクロスサイトのディザスター リカバリーのためにオンプレミスで実行されます。 実稼働サイトは、オンプレミスに置くことも、Azure データセンターに置くこともできます。

オンプレミスから Azure に構成された可用性グループの図。

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

データベースのディザスター リカバリーを成功させるには、ディザスター リカバリー サイトにレプリカ ドメイン コントローラーもインストールする必要があります。 開始するには、可用性グループのチュートリアルを確認してください。

フェールオーバー クラスター インスタンス (HA)

Azure VM 上の SQL Server はフェールオーバー クラスター インスタンス (FCI) をサポートしており、このソリューションはインスタンス レベルで高可用性を提供します。 保護を強化するために、フェールオーバー クラスター インスタンス上に可用性グループを作成することで、データベース レベルとインスタンス レベルの両方の冗長性を確保できます。 FCI 機能には共有ストレージが必要で、Azure VM 上の SQL Server と連携するソリューションは 5 つあります。

  • Windows Server 2019 用の Azure 共有ディスクの使用。 共有マネージド ディスクは、マネージド ディスクを複数の仮想マシンに同時に接続できるようにする Azure 製品です。 クラスター内の VM では、SCSI の永続的な予約 (SCSI PR) を使用するクラスター化アプリケーションによって選択された予約に基づいて、接続されたディスクに対して読み取りまたは書き込みを行うことができます。 SCSI PR は、オンプレミスの記憶域ネットワーク (SAN) 上で実行されているアプリケーションによって使用される、業界標準のストレージ ソリューションです。 マネージド ディスクで SCSI PR を有効にすると、これらのアプリケーションを Azure にそのまま移行することができます。

  • Windows Server 2016 以降用のソフトウェアベースの仮想 SAN を提供するための、記憶域スペース ダイレクト (S2D) の使用。

  • Windows Server 2012 以降用の Premium ファイル共有の使用。 Premium ファイル共有は、SSD によってバックアップされ、待機時間が常に短く、FCI との使用が完全にサポートされています。

  • クラスタリングのためにパートナー ソリューションでサポートされているストレージの使用。 SIOS DataKeeper を使用する具体的な例については、フェールオーバー クラスタリングと SIOS DataKeeper に関するブログ エントリを参照してください。

  • Azure ExpressRoute を介したリモート iSCSI ターゲット用の共有ブロック記憶域の使用。 たとえば、NetApp Private Storage (NPS) は、ExpressRoute と Equinix を使用して iSCSI ターゲットを Azure VM に公開します。

Microsoft パートナーの共有記憶域とデータ レプリケーション ソリューションの場合、フェールオーバーでのデータ アクセスに関する問題についてはベンダーにお問い合わせください。

開始するには、FCI 用に VM を準備します。

ログ配布 (DR)

Azure のもう 1 つのディザスター リカバリー ソリューションは、プライマリ サーバー上のプライマリ データベースから別のセカンダリ サーバー上の 1 つ以上のセカンダリ データベースにトランザクション ログのバックアップを自動的に送信するログ配布です。 ログ配布の構成では、Azure ファイル共有を使用してトランザクション ログ バックアップを保存します。

Azure でのログ配布の図。

ハイブリッド環境でログ配布を構成する必要がある場合は、1 つのサーバーは Azure VM に配置され、もう 1 つはクロスサイト ディザスター リカバリー用にオンプレミスに配置されます。 ログ配布は Windows ファイル共有に依存しているため、Azure Virtual Network とオンプレミス ネットワークの間の VPN 接続が必要です。

ログ配布の図。

データベースのディザスター リカバリーを成功させるには、ディザスター リカバリー サイトにレプリカ ドメイン コントローラーもインストールする必要があります。

バックアップと復元 (DR)

ディザスター リカバリーには、運用データベースのバックアップが必要です。 Azure では、ディザスター リカバリーのために、別のデータセンターの BLOB ストレージに直接バックアップされます。

1 つのリージョンのデータベースを、別のリージョンの Blob Storage にバックアップすることを示す図。

ハイブリッド ソリューションでは、オンプレミスの運用データベースを Azure Blob Storage に直接バックアップして、ディザスター リカバリーを強化できます。

バックアップと復元の図。

詳細については、Azure Virtual Machines における SQL Server のバックアップと復元に関するページを参照してください。

Azure Site Recovery (DR) を使用したレプリケーション

Azure Site Recovery は、Azure とハイブリッド構成の両方でディザスター リカバリー ソリューションとして使用できます。

Azure 内では、1 つの Azure データセンターにある運用 SQL Server インスタンスが、ディザスター リカバリーのために別の Azure データセンターの Azure Storage に直接レプリケートされます。

ある Azure データセンターのデータベースが、別のデータセンターでのディザスター リカバリーのために Azure Site Recovery レプリケーションを使用していることを示す図。

ハイブリッド環境の場合、オンプレミスの運用 SQL Server インスタンスが、ディザスター リカバリーのために Azure Storage に直接レプリケートされます。

Azure Site Recovery を使用するレプリケートの図

詳細については、「SQL Server ディザスター リカバリーおよび Azure Site Recovery を使用した SQL Server の保護」を参照してください。

Azure での無料 DR レプリカ

ソフトウェア アシュアランスを所有している場合は、パッシブ ディザスター リカバリー インスタンスの追加のライセンス コストを発生させることなく、SQL Server でハイブリッド ディザスター リカバリー (DR) プランを実装できます。 また、すべてのレプリカが Azure でホストされている場合は、従量課金制ライセンスを持つライセンス不要の DR レプリカの対象となります。

たとえば、3 つのレプリカすべてが Azure 内でホストされている場合は、2 つの無料パッシブ セカンダリを使用できます。

すべてが Azure 内の場合の 2 つの無料パッシブの図

または、1 つのライセンスされたプライマリ (オンプレミス)、1 つの HA 用無料パッシブと 1 つの DR 用無料パッシブ (オンプレミス)、および 1 つの DR 用無料パッシブ (Azure 内) を使用して、ハイブリッド フェールオーバー環境を構成することもできます。

環境が 1 つのプライマリ オンプレミスのプライマリ レプリカを使用したハイブリッドのときの 3 つの無料パッシブ

詳細については、製品ライセンス条項に関するページを参照してください。

このベネフィットを有効にするには、SQL Server の仮想マシン リソースに移動します。 [設定] で [構成] を選択したら、[SQL Server ライセンス] で [HA/DR] オプションを選択し、[適用] を選択して設定を保存します。 3 つすべてのレプリカが Azure でホストされている場合、従量課金制のお客様にも HA/DR ライセンスの種類を使用する権利があります。

Azure でのディザスター リカバリー レプリカの構成に関する図。

Azure での SQL Server HADR の重要な考慮事項

Azure の VM、ストレージ、およびネットワークには、オンプレミスの非仮想化 IT インフラストラクチャとは異なる運用特性があります。 Azure での HADR SQL Server ソリューションの実装を成功させるには、これらの違いを理解し、それに対応したソリューションを設計する必要があります。

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

Azure の可用性セットを使用すると、高可用性ノードを別個の障害ドメインと更新ドメインに配置できます。 Azure プラットフォームによって、可用性セット内の各仮想マシンに更新ドメインと障害ドメインが割り当てられます。 データセンター内のこの構成により、計画的または計画外のメンテナンス イベント中に、少なくとも 1 つの仮想マシンが利用可能であり、99.95% の Azure SLA が満たされることが保証されます。

高可用性の設定を構成するには、参加するすべての SQL Server 仮想マシンを同じ可用性セットに配置して、メンテナンス イベント中のアプリケーションまたはデータの損失を回避します。 同じクラウド サービス上にあるノードのみが同じ可用性セットに属することができます。 詳細については、仮想マシンの可用性の管理に関するページを参照してください。

可用性ゾーン内の高可用性ノード

可用性ゾーンは、Azure リージョン内の一意の物理的な場所です。 それぞれのゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータセンターで構成されています。 リージョン内での可用性ゾーンの物理的な分離は、少なくとも 1 つの仮想マシンが利用可能であり、99.99% の Azure SLA が満たされることを保証することで、データセンターで障害が発生した場合にアプリケーションとデータを保護するのに役立ちます。

高可用性を構成するには、参加する SQL Server 仮想マシンをリージョン内の可用性ゾーンに分散させて配置します。 可用性ゾーン間のネットワーク間転送については、追加料金が発生します。 詳細については、可用性ゾーンに関するページをご覧ください。

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

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

クラウド環境 に対応するために役立つクラスターと HADR 設定については、「HADR 構成のベスト プラクティス」を参照してください。

geo レプリケーション サポート

Azure ディスク内の geo レプリケーションでは、同じデータベースのデータ ファイルとログ ファイルを別のディスクに保存することはできません。 GRS は、各ディスク上の変更を個別に非同期的にレプリケートします。 このメカニズムでは、1 つのディスク内の geo レプリケートされたコピーでの書き込み順序は保証されますが、複数のディスクでの geo レプリケートされた各コピーでは保証されません。 データ ファイルとログ ファイルを個別のディスクに格納するようにデータベースを構成すると、障害発生後の復旧されたディスクには、ログ ファイルより新しいデータ ファイルのコピーが含まれる可能性があります。その場合、SQL Server の先書きログとトランザクションの ACID プロパティ (原子性、一貫性、分離性、持続性) が破損します。

ストレージ アカウントの geo レプリケーションを無効にするオプションがない場合は、データベースのすべてのデータおよびログ ファイルを同じディスクに保持します。 データベースのサイズのために複数のディスクを使用する必要がある場合は、データの冗長性を確保するために、前述の一覧表示されたディザスター リカバリー ソリューションのいずれかをデプロイします。

次のステップ

可用性グループとフェールオーバー クラスター インスタンスのどちらが、ビジネスに最適なビジネス継続性ソリューションであるかを判断します。 その後、高可用性とディザスター リカバリー用に環境を構成するためのベスト プラクティスを確認します。