Azure Virtual Machines 上の SQL Server のビジネス継続性と HADRBusiness continuity and HADR for SQL Server on Azure Virtual Machines

適用対象: Azure VM 上の SQL Server

ビジネス継続性とは、障害発生時にビジネスを継続し、復旧の計画を立て、データの高可用性を確保することを意味します。Business continuity means continuing your business in the event of a disaster, planning for recovery, and ensuring that your data is highly available. Azure Virtual Machines 上の SQL Server は、高可用性とディザスター リカバリー (HADR) データベース ソリューションのコストを削減するのに役立ちます。SQL Server on Azure Virtual Machines can help lower the cost of a high-availability and disaster recovery (HADR) database solution.

ほとんどの SQL Server HADR ソリューションは、Azure のみとハイブリッドの両方のソリューションとして、仮想マシン (VM) でサポートされます。Most SQL Server HADR solutions are supported on virtual machines (VMs), as both Azure-only and hybrid solutions. Azure のみのソリューションでは、HADR システム全体が Azure で実行されます。In an Azure-only solution, the entire HADR system runs in Azure. ハイブリッド構成では、ソリューションの一部が Azure で実行され、その他の部分が組織内のオンプレミスで実行されます。In a hybrid configuration, part of the solution runs in Azure and the other part runs on-premises in your organization. Azure 環境は柔軟性が高いので、SQL Server データベース システムの予算や HADR 要件に応じて、部分的に、または完全に Azure に移動できます。The flexibility of the Azure environment enables you to move partially or completely to Azure to satisfy the budget and HADR requirements of your SQL Server database systems.

この記事では、Azure VM 上の SQL Server で使用できるビジネス継続性ソリューションを比較、対比します。This article compares and contrasts the business continuity solutions available for SQL Server on Azure VMs.

概要Overview

サービス レベル アグリーメント (SLA) で求められる HADR 機能が、確実にデータベース システムに備わっているようにすることは、お客様の責任です。It's up to you to ensure that your database system has the HADR capabilities that the service-level agreement (SLA) requires. Azure には、クラウド サービスのサービス復旧、仮想マシンの障害復旧検出などの高可用性メカニズムが用意されていますが、それだけで SLA を満たせることが保証されるわけではありません。The fact that Azure provides high-availability mechanisms, such as service healing for cloud services and failure recovery detection for virtual machines, does not itself guarantee that you can meet the SLA. これらのメカニズムは仮想マシンの高可用性の保護に役立ちますが、VM 内で実行される SQL Server の可用性は保護されません。Although these mechanisms help protect the high availability of the virtual machine, they don't protect the availability of SQL Server running inside the VM.

VM がオンラインで正常であっても、SQL Server インスタンスで障害が発生する可能性があります。It's possible for the SQL Server instance to fail while the VM is online and healthy. Azure によって提供される高可用性メカニズムでも、ソフトウェアまたはハードウェアの障害からの回復やオペレーティング システムのアップグレードなどのイベントのために、VM のダウンタイムが生じます。Even the high-availability mechanisms provided by Azure allow for downtime of the VMs due to events like recovery from software or hardware failures and operating system upgrades.

Azure の geo 冗長ストレージ (GRS) は、geo レプリケーションと呼ばれる機能と共に実装されます。Geo-redundant storage (GRS) in Azure is implemented with a feature called geo-replication. GRS は、ご利用のデータベースに適したディザスター リカバリー ソリューションではない可能性があります。GRS might not be an adequate disaster recovery solution for your databases. geo レプリケーションではデータを非同期的に送信するため、障害が発生したときに最新の更新が失われる場合があります。Because geo-replication sends data asynchronously, recent updates can be lost in a disaster. geo レプリケーションの制限事項の詳細については、「geo レプリケーション サポート」セクションを参照してください。More information about geo-replication limitations is covered in the Geo-replication support section.

デプロイ アーキテクチャDeployment architectures

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

高可用性とディザスター リカバリーの両方の機能を持つ SQL Server ソリューションを実装するために、テクノロジを組み合わせることができます。You can combine the technologies to implement a SQL Server solution that has both high-availability and disaster recovery capabilities. 使用するテクノロジによっては、ハイブリッド デプロイで、Azure 仮想ネットワークを使った VPN トンネルが必要になる場合があります。Depending on the technology that you use, a hybrid deployment might require a VPN tunnel with the Azure virtual network. 以下の各セクションでは、デプロイ アーキテクチャの例をいくつか示します。The following sections show you some example deployment architectures.

Azure のみ:高可用性ソリューションAzure only: High-availability solutions

SQL Server の高可用性ソリューションは、Always On 可用性グループを使用して、データベース レベルで実現することができます。You can have a high-availability solution for SQL Server at a database level with Always On availability groups. また、Always On フェールオーバー クラスター インスタンスを使用して、インスタンス レベルで高可用性ソリューションを作成することもできます。You can also create a high-availability solution at an instance level with Always On failover cluster instances. 保護を強化するために、フェールオーバー クラスター インスタンスで可用性グループを作成し、両方のレベルで冗長性を持たせることもできます。For additional protection, you can create redundancy at both levels by creating availability groups on failover cluster instances.

テクノロジTechnology アーキテクチャの例Example architectures
可用性グループAvailability groups 同じリージョンの Azure VM で実行している可用性レプリカによって、高い可用性が実現します。Availability replicas running in Azure VMs in the same region provide high availability. Windows フェールオーバー クラスタリングには Active Directory ドメインが必要であるため、ドメイン コントローラー VM を構成する必要があります。You need to configure a domain controller VM, because Windows failover clustering requires an Active Directory domain.

冗長性と可用性を高めるために、可用性グループの概要に関するドキュメントに従って、Azure VM を異なる可用性ゾーンにデプロイすることができます。For higher redundancy and availability, the Azure VMs can be deployed in different availability zones as documented in the availability group overview. 可用性グループ内の SQL Server VM が可用性ゾーンにデプロイされている場合は、Azure SQL VM CLI および Azure クイックスタート テンプレートに関する記事に記載されているように、Azure Standard Load Balancer をリスナーに使用します。If the SQL Server VMs in an availability group are deployed in availability zones, then use Azure Standard Load Balancer for the listener, as documented in the Azure SQL VM CLI and Azure Quickstart templates articles.
可用性グループAvailability groups
詳細については、「Azure Virtual Machines での AlwaysOn 可用性グループの自動構成: Resource Manager」を参照してください。For more information, see Configure availability groups in Azure (GUI).
フェールオーバー クラスター インスタンスFailover cluster instances フェールオーバー クラスター インスタンスは SQL Server VM でサポートされています。Failover cluster instances are supported on SQL Server VMs. FCI 機能には共有ストレージが必要であるため、次の 5 つのソリューションは Azure VM 上の SQL Server で機能します。Because the FCI feature requires shared storage, five solutions will work with SQL Server on Azure VMs:

- Windows Server 2019 用の Azure 共有ディスクの使用。- Using Azure shared disks for Windows Server 2019. 共有マネージド ディスクは、マネージド ディスクを複数の仮想マシンに同時に接続できるようにする Azure 製品です。Shared managed disks are an Azure product that allow attaching a managed disk to multiple virtual machines simultaneously. クラスター内の VM では、SCSI の永続的な予約 (SCSI PR) を使用するクラスター化アプリケーションによって選択された予約に基づいて、接続されたディスクに対して読み取りまたは書き込みを行うことができます。VMs in the cluster can read or write to your attached disk based on the reservation chosen by the clustered application through SCSI Persistent Reservations (SCSI PR). SCSI PR は、オンプレミスの記憶域ネットワーク (SAN) 上で実行されているアプリケーションによって使用される、業界標準のストレージ ソリューションです。SCSI PR is an industry-standard storage solution that's used by applications running on a storage area network (SAN) on-premises. マネージド ディスクで SCSI PR を有効にすると、これらのアプリケーションを Azure にそのまま移行することができます。Enabling SCSI PR on a managed disk allows you to migrate these applications to Azure as is.

- Windows Server 2016 以降用のソフトウェアベースの仮想 SAN を提供するための、記憶域スペース ダイレクト (S2D) の使用。- Using Storage Spaces Direct (S2D) to provide a software-based virtual SAN for Windows Server 2016 and later.

- Windows Server 2012 以降用の Premium ファイル共有の使用。- Using a Premium file share for Windows Server 2012 and later. Premium ファイル共有は、SSD によってバックアップされ、待機時間が常に短く、FCI との使用が完全にサポートされています。Premium file shares are SSD backed, have consistently low latency, and are fully supported for use with FCI.

- クラスタリングのためにパートナー ソリューションでサポートされているストレージの使用。- Using storage supported by a partner solution for clustering. SIOS DataKeeper を使用する具体的な例については、フェールオーバー クラスタリングと SIOS DataKeeper に関するブログ エントリを参照してください。For a specific example that uses SIOS DataKeeper, see the blog entry Failover clustering and SIOS DataKeeper.

- Azure ExpressRoute を介したリモート iSCSI ターゲット用の共有ブロック記憶域の使用。- Using shared block storage for a remote iSCSI target via Azure ExpressRoute. たとえば、NetApp Private Storage (NPS) は、ExpressRoute と Equinix を使用して iSCSI ターゲットを Azure VM に公開します。For example, NetApp Private Storage (NPS) exposes an iSCSI target via ExpressRoute with Equinix to Azure VMs.

Microsoft パートナーの共有ストレージとデータ レプリケーション ソリューションの場合は、フェールオーバーでのデータ アクセスに関する問題について、ベンダーにお問い合わせください。For shared storage and data replication solutions from Microsoft partners, contact the vendor for any issues related to accessing data on failover.

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

可用性グループ、データベース ミラーリング、またはストレージ BLOB によるバックアップと復元を使用して、Azure 内の SQL Server データベースのディザスター リカバリー ソリューションを実現することができます。You can have a disaster recovery solution for your SQL Server databases in Azure by using availability groups, database mirroring, or backup and restore with storage blobs.

テクノロジTechnology アーキテクチャの例Example architectures
可用性グループAvailability groups 可用性レプリカが、障害復旧のために、Azure VM の複数のデータセンターで実行されます。Availability replicas running across multiple datacenters in Azure VMs for disaster recovery. この複数のリージョンにわたるソリューションは、完全なサイトの機能停止の場合の保護に役立ちます。This cross-region solution helps protect against a complete site outage.
可用性グループAvailability groups
リージョン内では、すべてのレプリカが同じクラウド サービスおよび同じ仮想ネットワーク内にある必要があります。Within a region, all replicas should be within the same cloud service and the same virtual network. 各リージョンには個別の仮想ネットワークがあるため、これらのソリューションには仮想ネットワーク間の接続が必要です。Because each region will have a separate virtual network, these solutions require network-to-network connectivity. 詳細については、Azure portal を使用したネットワーク間接続の構成に関するページを参照してください。For more information, see Configure a network-to-network connection by using the Azure portal. 詳細については、さまざまな Azure リージョンに存在する SQL Server Always On 可用性グループの構成に関するページを参照してください。For detailed instructions, see Configure a SQL Server Always On availability group across different Azure regions.
データベース ミラーリングDatabase mirroring プリンシパルとミラーとサーバーが、ディザスター リカバリーのために、異なるデータセンターで実行されます。Principal and mirror and servers running in different datacenters for disaster recovery. サーバー証明書を使用して、それらをデプロイする必要があります。You must deploy them by using server certificates. SQL Server データベース ミラーリングは、Azure VM 上の SQL Server 2008 や SQL Server 2008 R2 ではサポートされていません。SQL Server database mirroring is not supported for SQL Server 2008 or SQL Server 2008 R2 on an Azure VM.
データベース ミラーリング
Azure Blob Storage を使用したバックアップと復元Backup and restore with Azure Blob storage 運用データベースが、ディザスター リカバリーのために、別のデータセンターの BLOB ストレージに直接バックアップされます。Production databases backed up directly to Blob storage in a different datacenter for disaster recovery.
バックアップと復元Backup and restore
詳細については、「Azure VM における SQL Server のバックアップと復元」を参照してください。For more information, see Backup and restore for SQL Server on Azure VMs.
Azure Site Recovery を使用する Azure への SQL Server のレプリケートおよびフェールオーバーReplicate and fail over SQL Server to Azure with Azure Site Recovery ある Azure データセンターの運用 SQL Server インスタンスが、ディザスター リカバリーのために別の Azure データセンターの Azure Storage に直接レプリケートされます。Production SQL Server instance in one Azure datacenter replicated directly to Azure Storage in a different Azure datacenter for disaster recovery.
Azure Site Recovery を使用してレプリケートするReplicate using Azure Site Recovery
詳細については、「SQL Server ディザスター リカバリーおよび Azure Site Recovery を使用した SQL Server の保護」を参照してください。For more information, see Protect SQL Server using SQL Server disaster recovery and Azure Site Recovery.

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

可用性グループ、データベース ミラーリング、ログ配布、および Azure Blob Storage によるバックアップと復元を使用して、ハイブリッド IT 環境内の SQL Server データベースのディザスター リカバリー ソリューションを実現することができます。You can have a disaster recovery solution for your SQL Server databases in a hybrid IT environment by using availability groups, database mirroring, log shipping, and backup and restore with Azure Blob storage.

テクノロジTechnology サンプル アーキテクチャExample Architectures
可用性グループAvailability groups クロスサイト障害復旧のために、いくつかの可用性レプリカが Azure VM で実行され、その他のレプリカがオンプレミスで実行されます。Some availability replicas running in Azure VMs and other replicas running on-premises for cross-site disaster recovery. 実稼働サイトは、オンプレミスに置くことも、Azure データセンターに置くこともできます。The production site can be either on-premises or in an Azure datacenter.
可用性グループ
すべての可用性レプリカは同じフェールオーバー クラスターに存在する必要があるため、クラスターは両方のネットワークにまたがっている必要があります (マルチサブネット フェールオーバー クラスター)。Because all availability replicas must be in the same failover cluster, the cluster must span both networks (a multi-subnet failover cluster). この構成には、Azure とオンプレミス ネットワークの間の VPN 接続が必要です。This configuration requires a VPN connection between Azure and the on-premises network.

データベースのディザスター リカバリーを成功させるには、ディザスター リカバリー サイトにレプリカ ドメイン コントローラーもインストールする必要があります。For successful disaster recovery of your databases, you should also install a replica domain controller at the disaster recovery site.
データベース ミラーリングDatabase mirroring 一方のパートナーを Azure VM で実行し、もう一方をオンプレミスで実行して、サーバー証明書を使用したクロスサイトでのディザスター リカバリーを行います。One partner running in an Azure VM and the other running on-premises for cross-site disaster recovery by using server certificates. パートナーは、同じ Active Directory ドメイン内にある必要がなく、VPN 接続も必要ありません。Partners don't need to be in the same Active Directory domain, and no VPN connection is required.
データベース ミラーリングDatabase mirroring
もう 1 つのデータベース ミラーリング シナリオとして、クロスサイト障害復旧のために、1 つのパートナーを Azure VM で実行し、もう 1 つを同じ Active Directory ドメイン内のオンプレミスで実行するという形式があります。Another database mirroring scenario involves one partner running in an Azure VM and the other running on-premises in the same Active Directory domain for cross-site disaster recovery. Azure Virtual Network とオンプレミス ネットワークの間の VPN 接続が必要です。A VPN connection between the Azure virtual network and the on-premises network is required.

データベースのディザスター リカバリーを成功させるには、ディザスター リカバリー サイトにレプリカ ドメイン コントローラーもインストールする必要があります。For successful disaster recovery of your databases, you should also install a replica domain controller at the disaster recovery site. SQL Server データベース ミラーリングは、Azure VM 上の SQL Server 2008 や SQL Server 2008 R2 ではサポートされていません。SQL Server database mirroring is not supported for SQL Server 2008 or SQL Server 2008 R2 on an Azure VM.
ログ配布Log shipping クロスサイト障害復旧のために、1 つのサーバーが Azure VM で実行され、もう 1 つがオンプレミスで実行されます。One server running in an Azure VM and the other running on-premises for cross-site disaster recovery. ログ配布は Windows ファイル共有に依存しているため、Azure Virtual Network とオンプレミス ネットワークの間の VPN 接続が必要です。Log shipping depends on Windows file sharing, so a VPN connection between the Azure virtual network and the on-premises network is required.
ログ配布
データベースのディザスター リカバリーを成功させるには、ディザスター リカバリー サイトにレプリカ ドメイン コントローラーもインストールする必要があります。For successful disaster recovery of your databases, you should also install a replica domain controller at the disaster recovery site.
Azure Blob Storage を使用したバックアップと復元Backup and restore with Azure Blob storage オンプレミスの運用データベースが、ディザスター リカバリーのために、Azure Blob Storage に直接バックアップされます。On-premises production databases backed up directly to Azure Blob storage for disaster recovery.
バックアップと復元Backup and restore
詳細については、Azure Virtual Machines における SQL Server のバックアップと復元に関するページを参照してください。For more information, see Backup and restore for SQL Server on Azure Virtual Machines.
Azure Site Recovery を使用する Azure への SQL Server のレプリケートおよびフェールオーバーReplicate and fail over SQL Server to Azure with Azure Site Recovery オンプレミスの運用 SQL Server インスタンスが、ディザスター リカバリーのために Azure Storage に直接レプリケートされます。On-premises production SQL Server instance replicated directly to Azure Storage for disaster recovery.
Azure Site Recovery を使用してレプリケートするReplicate using Azure Site Recovery
詳細については、「SQL Server ディザスター リカバリーおよび Azure Site Recovery を使用した SQL Server の保護」を参照してください。For more information, see Protect SQL Server using SQL Server disaster recovery and Azure Site Recovery.

Azure での無料 DR レプリカFree DR replica in Azure

ソフトウェア アシュアランスを所有している場合は、パッシブ ディザスター リカバリー インスタンスの追加のライセンス コストを発生させることなく、SQL Server でハイブリッド ディザスター リカバリー (DR) プランを実装できます。If you have Software Assurance, you can implement hybrid disaster recovery (DR) plans with SQL Server without incurring additional licensing costs for the passive disaster recovery instance.

次の図では、12 個のコアを使用するオンプレミスの SQL Server デプロイ用のディザスター リカバリー レプリカとして、12 個のコアを使用する Azure 仮想マシンで実行されている SQL Server が、セットアップで使用されています。In the following image, the setup uses SQL Server running on an Azure virtual machine that uses 12 cores as a disaster recovery replica for an on-premises SQL Server deployment that uses 12 cores. これまでは、オンプレミス デプロイと Azure Virtual Machines デプロイのために、SQL Server の 12 個のコアをライセンスする必要がありました。In the past, you would need to license 12 cores of SQL Server for the on-premises deployment and the Azure Virtual Machines deployment. 新しい特典では、Azure 仮想マシン上で実行するためのパッシブ レプリカの特典が提供されます。The new benefit offers passive replica benefits for running on an Azure virtual machine. 現在は、Azure Virtual Machines 上のパッシブ レプリカのディザスター リカバリーの条件が満たされている限り、オンプレミスで実行されている SQL Server の 12 個のコアのみをライセンスする必要があります。Now you would need to license only 12 cores of SQL Server running on-premises, as long as the disaster recovery criteria for the passive replica on Azure Virtual Machines are met.

Azure の無料のディザスター リカバリー レプリカ

詳細については、製品ライセンス条項に関するページを参照してください。For more information, see the product licensing terms.

このベネフィットを有効にするには、SQL Server の仮想マシン リソースに移動します。To enable this benefit, go to your SQL Server virtual machine resource. [設定] の下にある [構成] を選択してから、 [SQL Server ライセンス][ディザスター リカバリー] オプションを選びます。Select Configure under Settings, and then choose the Disaster Recovery option under SQL Server License. この SQL Server VM がパッシブ レプリカとして使用されることを確認するためのチェック ボックスをオンにし、 [適用] を選択して設定を保存します。Select the check box to confirm that this SQL Server VM will be used as a passive replica, and then select Apply to save your settings.

Azure でディザスター リカバリー レプリカを構成する

Azure での SQL Server HADR の重要な考慮事項Important considerations for SQL Server HADR in Azure

Azure の VM、ストレージ、およびネットワークには、オンプレミスの非仮想化 IT インフラストラクチャとは異なる動作特性があります。Azure VMs, storage, and networking have different operational characteristics than an on-premises, non-virtualized IT infrastructure. Azure での HADR SQL Server ソリューションの実装を成功させるには、これらの違いを理解し、それに対応したソリューションを設計する必要があります。A successful implementation of an HADR SQL Server solution in Azure requires that you understand these differences and design your solution to accommodate them.

可用性セット内の高可用性ノードHigh-availability nodes in an availability set

Azure の可用性セットを使用すると、高可用性ノードを別個の障害ドメインと更新ドメインに配置できます。Availability sets in Azure enable you to place the high-availability nodes into separate fault domains and update domains. Azure プラットフォームによって、可用性セット内の各仮想マシンに更新ドメインと障害ドメインが割り当てられます。The Azure platform assigns an update domain and a fault domain to each virtual machine in your availability set. データセンター内のこの構成により、計画的または計画外のメンテナンス イベント中に、少なくとも 1 つの仮想マシンが利用可能であり、99.95% の Azure SLA が満たされることが保証されます。This configuration within a datacenter ensures that during either a planned or unplanned maintenance event, at least one virtual machine is available and meets the Azure SLA of 99.95 percent.

高可用性の設定を構成するには、参加するすべての SQL Server 仮想マシンを同じ可用性セットに配置して、メンテナンス イベント中のアプリケーションまたはデータの損失を回避します。To configure a high-availability setup, place all participating SQL Server virtual machines in the same availability set to avoid application or data loss during a maintenance event. 同じクラウド サービス上にあるノードのみが同じ可用性セットに属することができます。Only nodes in the same cloud service can participate in the same availability set. 詳細については、仮想マシンの可用性の管理に関するページを参照してください。For more information, see Manage the availability of virtual machines.

可用性ゾーン内の高可用性ノードHigh-availability nodes in an availability zone

可用性ゾーンは、Azure リージョン内の一意の物理的な場所です。Availability zones are unique physical locations within an Azure region. それぞれのゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータセンターで構成されています。Each zone consists of one or more datacenters equipped with independent power, cooling, and networking. リージョン内での可用性ゾーンの物理的な分離は、少なくとも 1 つの仮想マシンが利用可能であり、99.99% の Azure SLA が満たされることを保証することで、データセンターで障害が発生した場合にアプリケーションとデータを保護するのに役立ちます。The physical separation of availability zones within a region helps protect applications and data from datacenter failures by ensuring that at least one virtual machine is available and meets the Azure SLA of 99.99 percent.

高可用性を構成するには、参加する SQL Server 仮想マシンをリージョン内の可用性ゾーンに分散させて配置します。To configure high availability, place participating SQL Server virtual machines spread across availability zones in the region. 可用性ゾーン間のネットワーク間転送については、追加料金が発生します。There will be additional charges for network-to-network transfers between availability zones. 詳細については、可用性ゾーンに関するページをご覧ください。For more information, see Availability zones.

Azure ネットワークでのフェールオーバー クラスターの動作Failover cluster behavior in Azure networking

Azure の RFC に準拠していない DHCP サービスにより、特定のフェールオーバー クラスター構成の作成に失敗する可能性があります。The non-RFC-compliant DHCP service in Azure can cause the creation of certain failover cluster configurations to fail. この失敗は、クラスター ネットワーク名に重複する IP アドレス (クラスター ノードの 1 つと同じ IP アドレスなど) が割り当てられていることが原因で発生します。This failure happens because the cluster network name is assigned a duplicate IP address, such as the same IP address as one of the cluster nodes. これは、Windows フェールオーバー クラスター機能に依存する、可用性グループを使用するときに問題になります。This is an issue when you use availability groups, which depend on the Windows failover cluster feature.

2 ノード クラスターを作成し、オンラインにするシナリオを考えてみましょう。Consider the scenario when a two-node cluster is created and brought online:

  1. クラスターがオンラインになると、NODE1 によって、クラスター ネットワーク名のために動的に割り当てられた IP アドレスが要求されます。The cluster comes online, and then NODE1 requests a dynamically assigned IP address for the cluster network name.
  2. DHCP サービスでは要求が NODE1 自体からのものであることが認識されるため、DHCP サービスで NODE1 自体の IP アドレス以外の IP アドレスは提供されません。The DHCP service doesn't give any IP address other than NODE1's own IP address, because the DHCP service recognizes that the request comes from NODE1 itself.
  3. NODE1 とフェールオーバー クラスターのネットワーク名の両方に重複するアドレスが割り当てられていることが Windows によって検出されると、既定のクラスター グループはオンラインになることができません。Windows detects that a duplicate address is assigned both to NODE1 and to the failover cluster's network name, and the default cluster group fails to come online.
  4. 既定のクラスター グループは NODE2 に移動されます。The default cluster group moves to NODE2. NODE2 によって、NODE1 の IP アドレスはクラスター IP アドレスとして処理され、既定のクラスター グループがオンラインになります。NODE2 treats NODE1's IP address as the cluster IP address and brings the default cluster group online.
  5. NODE2 では、NODE1 との接続を確立しようとするときに、NODE1 の IP アドレスがそれ自体に解決されるため、NODE1 宛てのパケットは NODE2 から送信されません。When NODE2 tries to establish connectivity with NODE1, packets directed at NODE1 never leave NODE2 because it resolves NODE1's IP address to itself. NODE2 では NODE1 との接続を確立できず、クォーラムが失われ、クラスターがシャットダウンされます。NODE2 can't establish connectivity with NODE1, and then loses quorum and shuts down the cluster.
  6. NODE1 では NODE2 にパケットを送信できますが、NODE2 は応答できません。NODE1 can send packets to NODE2, but NODE2 can't reply. NODE1 はクォーラムを失い、クラスターをシャットダウンします。NODE1 loses quorum and shuts down the cluster.

このシナリオは、クラスター ネットワーク名をオンラインにするために、クラスター ネットワーク名に未使用の静的 IP アドレスを割り当てることによって回避できます。You can avoid this scenario by assigning an unused static IP address to the cluster network name in order to bring the cluster network name online. たとえば、169.254.1.1 のようなリンク ローカル IP アドレスを使用できます。For example, you can use a link-local IP address like 169.254.1.1. このプロセスを簡略化するには、可用性グループのための Azure での Windows フェールオーバー クラスターの構成に関するページを参照してください。To simplify this process, see Configuring Windows failover cluster in Azure for availability groups.

詳細については、「Azure Virtual Machines での AlwaysOn 可用性グループの自動構成: Resource Manager」を参照してください。For more information, see Configure availability groups in Azure (GUI).

可用性グループ リスナーのサポートSupport for availability group listeners

可用性グループ リスナーは、Windows Server 2012 以降を実行している Azure VM でサポートされています。Availability group listeners are supported on Azure VMs running Windows Server 2012 and later. このサポートは、可用性グループ ノードである Azure VM 上で有効になっている負荷分散エンドポイントを使用して実現されます。This support is made possible by the use of load-balanced endpoints enabled on the Azure VMs that are availability group nodes. Azure で実行されているクライアント アプリケーションと、オンプレミスで実行されているものの両方に対してリスナーを動作させるには、特別な構成手順に従う必要があります。You must follow special configuration steps for the listeners to work for both client applications running in Azure and those running on-premises.

リスナーを設定するための主なオプションには、外部 (パブリック) と内部の 2 つがあります。There are two main options for setting up your listener: external (public) or internal. 外部 (パブリック) リスナーでは、インターネットに接続されているロード バランサーを使用し、インターネット経由でアクセスできるパブリック仮想 IP と関連付けられます。The external (public) listener uses an internet-facing load balancer and is associated with a public virtual IP that's accessible over the internet. 内部リスナーでは、内部ロード バランサーを使用し、同じ仮想ネットワーク内のクライアントのみをサポートします。An internal listener uses an internal load balancer and supports only clients within the same virtual network. どちらのタイプのロード バランサーの場合でも、Direct Server Return を有効にする必要があります。For either load balancer type, you must enable Direct Server Return.

可用性グループが複数の Azure サブネットにまたがっている場合 (複数の Azure リージョンにわたるデプロイなど)、クライアント接続文字列には MultisubnetFailover=True を含める必要があります。If the availability group spans multiple Azure subnets (such as a deployment that crosses Azure regions), the client connection string must include MultisubnetFailover=True. これにより、別のサブネット内のレプリカへのパラレル接続が試行されます。This results in parallel connection attempts to the replicas in the different subnets. リスナーの設定手順については、Azure での可用性グループの ILB リスナーの構成に関するページを参照してください。For instructions on setting up a listener, see Configure an ILB listener for availability groups in Azure.

この場合でも、サービス インスタンスに直接接続することで、各可用性レプリカに個別に接続できます。You can still connect to each availability replica separately by connecting directly to the service instance. また、可用性グループはデータベース ミラーリング クライアントとの下位互換性があるため、レプリカがデータベース ミラーリングと同様に、次のように構成されていれば、データベース ミラーリング パートナーのように可用性レプリカに接続できます。Also, because availability groups are backward compatible with database mirroring clients, you can connect to the availability replicas like database mirroring partners as long as the replicas are configured similarly to database mirroring:

  • 1 つのプライマリ レプリカと 1 つのセカンダリ レプリカがある。There's one primary replica and one secondary replica.
  • セカンダリ レプリカが読み取り不可として構成されている ( [読み取り可能なセカンダリ] オプションが [いいえ] に設定されている)。The secondary replica is configured as non-readable (Readable Secondary option set to No).

ADO.NET または SQL Server Native Client を使用する、このデータベース ミラーリングと同様の構成に対応するクライアント接続文字列の例を以下に示します。Here's an example client connection string that corresponds to this database mirroring-like configuration using ADO.NET or SQL Server Native Client:

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

クライアント接続の詳細については、以下を参照してください。For more information on client connectivity, see:

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

オンプレミス ネットワークと Azure 間に長いネットワーク待ち時間が生じる期間がある可能性があることを前提として、HADR ソリューションをデプロイします。Deploy your HADR solution with the assumption that there might be periods of high network latency between your on-premises network and Azure. レプリカを Azure にデプロイする場合、同期モードでは同期コミットではなく、非同期コミットを使用します。When you're deploying replicas to Azure, use asynchronous commit instead of synchronous commit for the synchronization mode. オンプレミスと Azure の両方にデータベース ミラーリング サーバーをデプロイする場合は、高い安全性モードではなく、高いパフォーマンス モードを使用します。When you're deploying database mirroring servers both on-premises and in Azure, use the high-performance mode instead of the high-safety mode.

geo レプリケーション サポートGeo-replication support

Azure ディスク内の geo レプリケーションでは、同じデータベースのデータ ファイルとログ ファイルを別個のディスクに格納することはできません。Geo-replication in Azure disks does not support the data file and log file of the same database to be stored on separate disks. GRS は、各ディスク上の変更を個別に非同期的にレプリケートします。GRS replicates changes on each disk independently and asynchronously. このメカニズムでは、1 つのディスク内の geo レプリケートされたコピーでの書き込み順序は保証されますが、複数のディスクでの geo レプリケートされた各コピーでは保証されません。This mechanism guarantees the write order within a single disk on the geo-replicated copy, but not across geo-replicated copies of multiple disks. データ ファイルとログ ファイルを個別のディスクに格納するようにデータベースを構成すると、障害発生後の復旧されたディスクには、ログ ファイルより新しいデータ ファイルのコピーが含まれる可能性があります。その場合、SQL Server の先書きログとトランザクションの ACID プロパティ (原子性、一貫性、分離性、持続性) が破損します。If you configure a database to store its data file and its log file on separate disks, the recovered disks after a disaster might contain a more up-to-date copy of the data file than the log file, which breaks the write-ahead log in SQL Server and the ACID properties (atomicity, consistency, isolation, and durability) of transactions.

ストレージ アカウントの geo レプリケーションを無効にするオプションがない場合は、データベースのすべてのデータおよびログ ファイルを同じディスクに保持します。If you don't have the option to disable geo-replication on the storage account, keep all data and log files for a database on the same disk. データベースのサイズのために複数のディスクを使用する必要がある場合は、データの冗長性を確保するために、前述の一覧表示されたディザスター リカバリー ソリューションのいずれかをデプロイします。If you must use more than one disk due to the size of the database, deploy one of the disaster recovery solutions listed earlier to ensure data redundancy.

次のステップNext steps

可用性グループフェールオーバー クラスター インスタンスのどちらが、ビジネスに最適なビジネス継続性ソリューションであるかを判断します。Decide if an availability group or a failover cluster instance is the best business continuity solution for your business. その後、高可用性とディザスター リカバリー用に環境を構成するためのベスト プラクティスを確認します。Then review the best practices for configuring your environment for high availability and disaster recovery.