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

適用対象:Azure VM 上の SQL Server

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

ほとんどの SQL Server HADR ソリューションは、Azure のみとハイブリッドの両方のソリューションとして、仮想マシン (VM) でサポートされます。 Azure のみのソリューションでは、HADR システム全体が Azure で実行されます。 ハイブリッド構成では、ソリューションの一部が Azure で実行され、その他の部分が組織内のオンプレミスで実行されます。 Azure 環境は柔軟性が高いので、SQL Server データベース システムの予算や HADR 要件に応じて、部分的に、または完全に Azure に移動できます。

この記事では、Azure VM 上の SQL Server で使用できるビジネス継続性ソリューションを比較、対比します。

概要

サービス レベル アグリーメント (SLA) で求められる HADR 機能が、確実にデータベース システムに備わっているようにすることは、お客様の責任です。 Azure には、クラウド サービスのサービス復旧、仮想マシンの障害復旧検出などの高可用性メカニズムが用意されていますが、それだけで SLA を満たせることが保証されるわけではありません。 これらのメカニズムは仮想マシンの高可用性の保護に役立ちますが、VM 内で実行される SQL Server の可用性は保護されません。

VM がオンラインで正常であっても、SQL Server インスタンスで障害が発生する可能性があります。 Azure によって提供される高可用性メカニズムでも、ソフトウェアまたはハードウェアの障害からの回復やオペレーティング システムのアップグレードなどのイベントのために、VM のダウンタイムが生じます。

Azure の geo 冗長ストレージ (GRS) は、geo レプリケーションと呼ばれる機能と共に実装されます。 GRS は、ご利用のデータベースに適したディザスター リカバリー ソリューションではない可能性があります。 geo レプリケーションではデータを非同期的に送信するため、障害が発生したときに最新の更新が失われる場合があります。 geo レプリケーションの制限事項の詳細については、「geo レプリケーション サポート」セクションを参照してください。

デプロイ アーキテクチャ

Azure では、ビジネス継続性のための以下の SQL Server テクノロジがサポートされます。

• Always On 可用性グループ
• Always On フェールオーバー クラスター インスタンス (FCI)
• ログ配布
• Azure Blob Storage を使った SQL Server のバックアップと復元
• データベース ミラーリング - SQL Server 2016 では非推奨
• Azure Site Recovery

高可用性とディザスター リカバリーの両方の機能を持つ SQL Server ソリューションを実装するために、テクノロジを組み合わせることができます。 使用するテクノロジによっては、ハイブリッド デプロイで、Azure 仮想ネットワークを使った VPN トンネルが必要になる場合があります。 以下の各セクションでは、デプロイ アーキテクチャの例をいくつか示します。

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

SQL Server の高可用性ソリューションは、Always On 可用性グループを使用して、データベース レベルで実現することができます。 また、Always On フェールオーバー クラスター インスタンスを使用して、インスタンス レベルで高可用性ソリューションを作成することもできます。 保護を強化するために、フェールオーバー クラスター インスタンスで可用性グループを作成し、両方のレベルで冗長性を持たせることもできます。

テクノロジ	アーキテクチャの例
可用性グループ	同じリージョンの Azure VM で実行している可用性レプリカによって、高い可用性が実現します。 Windows フェールオーバー クラスタリングには Active Directory ドメインが必要であるため、ドメイン コントローラー VM を構成する必要があります。 冗長性と可用性を高めるために、可用性グループの概要に関するドキュメントに従って、Azure VM を異なる可用性ゾーンにデプロイすることができます。 開始するには、可用性グループのチュートリアルを確認してください。
フェールオーバー クラスター インスタンス	フェールオーバー クラスター インスタンスは SQL Server VM でサポートされています。 FCI 機能には共有ストレージが必要であるため、次の 5 つのソリューションは Azure VM 上の SQL Server で機能します。 - 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 を準備します

Azure のみ: ディザスター リカバリー ソリューション

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

テクノロジ	アーキテクチャの例
可用性グループ	可用性レプリカが、障害復旧のために、Azure VM の複数のデータセンターで実行されます。 この複数のリージョンにわたるソリューションは、完全なサイトの機能停止の場合の保護に役立ちます。 リージョン内では、すべてのレプリカが同じクラウド サービスおよび同じ仮想ネットワーク内にある必要があります。 各リージョンには個別の仮想ネットワークがあるため、これらのソリューションには仮想ネットワーク間の接続が必要です。 詳細については、Azure portal を使用したネットワーク間接続の構成に関するページを参照してください。 詳細については、さまざまな Azure リージョンに存在する SQL Server Always On 可用性グループの構成に関するページを参照してください。
データベース ミラーリング	プリンシパルとミラーとサーバーが、ディザスター リカバリーのために、異なるデータセンターで実行されます。 サーバー証明書を使用して、それらをデプロイする必要があります。
Azure Blob Storage を使用したバックアップと復元	運用データベースが、ディザスター リカバリーのために、別のデータセンターの BLOB ストレージに直接バックアップされます。 詳細については、「Azure VM における SQL Server のバックアップと復元」を参照してください。
Azure Site Recovery を使用する Azure への SQL Server のレプリケートおよびフェールオーバー	ある Azure データセンターの運用 SQL Server インスタンスが、ディザスター リカバリーのために別の Azure データセンターの Azure Storage に直接レプリケートされます。 詳細については、「SQL Server ディザスター リカバリーおよび Azure Site Recovery を使用した SQL Server の保護」を参照してください。

ハイブリッド IT: ディザスター リカバリー ソリューション

可用性グループ、データベース ミラーリング、ログ配布、および Azure Blob Storage によるバックアップと復元を使用して、ハイブリッド IT 環境内の SQL Server データベースのディザスター リカバリー ソリューションを実現することができます。

テクノロジ	サンプル アーキテクチャ
可用性グループ	クロスサイト障害復旧のために、いくつかの可用性レプリカが Azure VM で実行され、その他のレプリカがオンプレミスで実行されます。 実稼働サイトは、オンプレミスに置くことも、Azure データセンターに置くこともできます。 すべての可用性レプリカは同じフェールオーバー クラスターに存在する必要があるため、クラスターは両方のネットワークにまたがっている必要があります (マルチサブネット フェールオーバー クラスター)。 この構成には、Azure とオンプレミス ネットワークの間の VPN 接続が必要です。 データベースのディザスター リカバリーを成功させるには、ディザスター リカバリー サイトにレプリカ ドメイン コントローラーもインストールする必要があります。 開始するには、可用性グループのチュートリアルを確認してください。
データベース ミラーリング	一方のパートナーを Azure VM で実行し、もう一方をオンプレミスで実行して、サーバー証明書を使用したクロスサイトでのディザスター リカバリーを行います。 パートナーは、同じ Active Directory ドメイン内にある必要がなく、VPN 接続も必要ありません。 もう 1 つのデータベース ミラーリング シナリオとして、クロスサイト障害復旧のために、1 つのパートナーを Azure VM で実行し、もう 1 つを同じ Active Directory ドメイン内のオンプレミスで実行するという形式があります。 Azure Virtual Network とオンプレミス ネットワークの間の VPN 接続が必要です。 データベースのディザスター リカバリーを成功させるには、ディザスター リカバリー サイトにレプリカ ドメイン コントローラーもインストールする必要があります。
ログ配布	クロスサイト障害復旧のために、1 つのサーバーが Azure VM で実行され、もう 1 つがオンプレミスで実行されます。 ログ配布は Windows ファイル共有に依存しているため、Azure Virtual Network とオンプレミス ネットワークの間の VPN 接続が必要です。 データベースのディザスター リカバリーを成功させるには、ディザスター リカバリー サイトにレプリカ ドメイン コントローラーもインストールする必要があります。
Azure Blob Storage を使用したバックアップと復元	オンプレミスの運用データベースが、ディザスター リカバリーのために、Azure Blob Storage に直接バックアップされます。 詳細については、Azure Virtual Machines における SQL Server のバックアップと復元に関するページを参照してください。
Azure Site Recovery を使用する Azure への SQL Server のレプリケートおよびフェールオーバー	オンプレミスの運用 SQL Server インスタンスが、ディザスター リカバリーのために Azure Storage に直接レプリケートされます。 詳細については、「SQL Server ディザスター リカバリーおよび Azure Site Recovery を使用した SQL Server の保護」を参照してください。

Azure での無料 DR レプリカ

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

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

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

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

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

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

次のステップ

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