Azure 仮想マシンにおける SQL Server の高可用性とディザスター リカバリーHigh availability and disaster recovery for SQL Server in Azure Virtual Machines

Microsoft Azure 仮想マシン (VM) と SQL Server を使用すると、高可用性ディザスター リカバリー (HADR) データベース ソリューションのコストを削減できます。Microsoft Azure virtual machines (VMs) with SQL Server can help lower the cost of a high availability and disaster recovery (HADR) database solution. ほとんどの SQL Server HADR ソリューションでは、Azure のみのソリューションとしても、ハイブリッドのソリューションとしても、Azure 仮想マシンがサポートされています。Most SQL Server HADR solutions are supported in Azure virtual machines, both as Azure-only and as 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 には、リソースの作成と操作に関して、2 種類のデプロイ モデルがあります。Resource Manager とクラシックです。Azure has two different deployment models for creating and working with resources: Resource Manager and classic. この記事では、両方のモデルについて取り上げていますが、最新のデプロイではリソース マネージャー モデルの使用をお勧めします。This article covers using both models, but Microsoft recommends that most new deployments use the Resource Manager model.

HADR ソリューションの必要性Understanding the need for an HADR solution

サービス レベル アグリーメント (SLA) が必要とする HADR 機能をデータベース システムが備えていることを確認するのは、管理者の責任です。It is up to you to ensure that your database system possesses the HADR capabilities that the service-level agreement (SLA) requires. Azure には、クラウド サービスのサービス復旧、Virtual Machines のディザスター リカバリー検出などの高可用性メカニズムが用意されていますが、それだけで必要な 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 you can meet the desired SLA. これらのメカニズムは VM の高可用性を保護しますが、VM 内で実行される SQL Server の高可用性は保護されません。These mechanisms protect the high availability of the VMs but not the high availability of SQL Server running inside the VMs. VM がオンラインで正常であっても、SQL Server インスタンスで障害が発生する可能性があります。It is possible for the SQL Server instance to fail while the VM is online and healthy. さらに、Azure の高可用性メカニズムがあっても、ソフトウェアまたはハードウェアの障害からの回復やオペレーティング システムのアップグレードなどのイベントのために、VM のダウンタイムが生じます。Moreover, even the high availability mechanisms provided by Azure allow for downtime of the VMs due to events such as recovery from software or hardware failures and operating system upgrades.

また、Azure の geo 冗長ストレージ (GRS) は、geo レプリケーションと呼ばれる機能によって実装されており、データベースにとって適切なディザスター リカバリー ソリューションにはならない場合があります。In addition, Geo Redundant Storage (GRS) in Azure, which is implemented with a feature called geo-replication, may not be an adequate disaster recovery solution for your databases. geo レプリケーションでは、データを非同期的に送信するため、障害が発生すると、最新の更新が失われる場合があります。Because geo-replication sends data asynchronously, recent updates can be lost in the event of disaster. geo レプリケーションの制限事項の詳細については、「 別々のディスクのデータとログ ファイルでサポートされていない geo レプリケーション 」セクションを参照してください。More information regarding geo-replication limitations are covered in the Geo-replication not supported for data and log files on separate disks section.

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

Azure でサポートされている SQL Server HADR テクノロジは、次のとおりです。SQL Server HADR technologies that are supported in Azure include:

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

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

SQL Server の高可用性ソリューションは、AlwaysOn 可用性グループ (可用性グループと呼ばれる) を使用してデータベース レベルにするができます。You can have a high availability solution for SQL Server at a database level with Always On Availability Groups - called availability groups. また、AlwaysOn フェールオーバー クラスター インスタンス (フェールオーバー クラスター インスタンス) を使用して、インスタンス レベルで高可用性ソリューションを作成することもできます。You can also create a high availability solution at an instance level with Always On Failover Cluster Instances - failover cluster instances. 冗長性を追加するには、フェールオーバー クラスター インスタンスで可用性グループを作成することで、両方のレベルで冗長性を持たせることもできます。For additional redundancy, 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.
可用性グループAvailability Groups
詳細については、「Azure Virtual Machines での AlwaysOn 可用性グループの自動構成: Resource Manager」を参照してください。For more information, see Configure Availability Groups in Azure (GUI).
フェールオーバー クラスター インスタンスFailover cluster instances 共有記憶域を必要とするフェールオーバー クラスター インスタンス (FCI) は、3 つの異なる方法で作成できます。Failover Cluster Instances (FCI), which require shared storage, can be created in 3 different ways.

1.接続されたストレージを使用する Azure VM で実行される 2 ノード フェールオーバー クラスター。このストレージは Windows Server 2016 Storage Spaces Direct (S2D) を使用して、ソフトウェア ベースの仮想 SAN を提供します。1. A two-node failover cluster running in Azure VMs with attached storage using Windows Server 2016 Storage Spaces Direct (S2D) to provide a software-based virtual SAN.

2.サード パーティのクラスタリング ソリューションでサポートされるストレージを使用する Azure VM で実行される 2 ノード フェールオーバー クラスター。2. A two-node failover cluster running in Azure VMs with storage supported by a third-party clustering solution. SIOS DataKeeper を使用する具体的な例については、フェールオーバー クラスタリングとサード パーティ製ソフトウェアの SIOS DataKeeper を使用したファイル共有の高可用性に関するページを参照してください。For a specific example that uses SIOS DataKeeper, see High availability for a file share using failover clustering and 3rd party software SIOS DataKeeper.

手順 3.ExpressRoute を介してリモート iSCSI ターゲット共有ブロック記憶域を使用する Azure VM で実行される 2 ノード フェールオーバー クラスター。3. A two-node failover cluster running in Azure VMs with remote iSCSI Target shared block storage via 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.

サードパーティの共有記憶域とデータ レプリケーション ソリューションの場合は、フェールオーバーでのデータ アクセスに関する問題について、ベンダーに問い合わせてください。For third-party shared storage and data replication solutions, you should contact the vendor for any issues related to accessing data on failover.

Azure File Storage 上での FCI の使用は、このソリューションが Premium Storage を利用していないためにまだサポートされていないことに注意してください。Note that using FCI on top of Azure File storage is not supported yet, because this solution does not utilize Premium Storage. 近日中にサポートできるように作業中です。We are working to support this soon.

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

Azure 内の SQL Server データベースのディザスター リカバリー ソリューションを実現するには、可用性グループ、データベース ミラーリング、またはストレージ BLOB によるバックアップと復元を使用します。You can have a disaster recovery solution for your SQL Server databases in Azure 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 protects against complete site outage.
可用性グループAvailability Groups
リージョン内で、すべてのレプリカが同じクラウド サービスおよび同じ VNet 内にある必要があります。Within a region, all replicas should be within the same cloud service and the same VNet. 各リージョンは個別の VNet を持つため、これらのソリューションには VNet と VNet 間の接続が必要です。Because each region will have a separate VNet, these solutions require VNet to VNet connectivity. 詳細については、「Azure Portal を使用した VNet 間接続の構成」をご覧ください。For more information, see Configure a VNet-to-VNet connection using the Azure portal. 詳細については、「さまざまな地域に存在する Azure Virtual Machines に Always On 可用性グループを構成する」を参照してください。For detailed instructions, see Configure a SQL Server Availability Group on Azure Virtual Machines in Different Regions.
データベース ミラーリングDatabase Mirroring プリンシパルとミラーとサーバーが、ディザスター リカバリーのために、異なるデータセンターで実行されます。Principal and mirror and servers running in different datacenters for disaster recovery. サーバー証明書を使ってデプロイする必要があります。You must deploy 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 nor SQL Server 2008 R2 on an Azure VM.
データベース ミラーリング
Azure BLOB ストレージ サービスを使用したバックアップと復元Backup and Restore with Azure Blob Storage Service 実稼働データベースが、ディザスター リカバリーのために、別のデータセンターの BLOB ストレージに直接バックアップされます。Production databases backed up directly to blob storage in a different datacenter for disaster recovery.
バックアップと復元Backup and Restore
詳細については、「Azure Virtual Machines における SQL Server のバックアップと復元」を参照してください。For more information, see Backup and Restore for SQL Server in Azure Virtual Machines.
Azure Site Recovery を使用する Azure への SQL Server のレプリケートおよびフェールオーバーReplicate and Failover SQL Server to Azure with Azure Site Recovery ある Azure データセンターの実稼働 SQL Server が、ディザスター リカバリーのために別の Azure データセンターの Azure Storage に直接レプリケートされます。Production SQL Server of one Azure datacenter replicated directly to Azure Storage of 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

ハイブリッド IT 環境内の SQL Server データベースのディザスター リカバリー ソリューションを実現するには、可用性グループ、データベース ミラーリング、ログ配布、および Azure BLOB ストレージによるバックアップと復元を使用します。You can have a disaster recovery solution for your SQL Server databases in a hybrid-IT environment using availability groups, database mirroring, log shipping, and backup and restore with Azure blog 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.

SSMS のレプリカの追加ウィザードを使用して、既存の AlwaysOn 可用性グループに Azure レプリカを追加できます。It is possible to use the Add Replica Wizard in SSMS to add an Azure replica to an existing Always On Availability Group. 詳しくは、「Tutorial: Extend your Always On Availability Group to Azure (チュートリアル: Always On 可用性グループを Azure に拡張する)」をご覧ください。For more information, see Tutorial: Extend your Always On Availability Group to Azure.
データベース ミラーリングDatabase Mirroring クロスサイトでのディザスター リカバリーのために、1 つのサーバーが Azure VM で実行され、もう 1 つがオンプレミスで実行されます。One partner running in an Azure VM and the other running on-premises for cross-site disaster recovery using server certificates. パートナーは、同じ Active Directory ドメイン内にある必要がなく、VPN 接続も必要ありません。Partners do not 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 nor 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 ストレージ サービスを使用したバックアップと復元Backup and Restore with Azure Blob Storage Service オンプレミスの実稼働データベースが、ディザスター リカバリーのために、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 in Azure Virtual Machines.
Azure Site Recovery を使用する Azure への SQL Server のレプリケートおよびフェールオーバーReplicate and Failover SQL Server to Azure with Azure Site Recovery オンプレミスの実稼働 SQL Server が、ディザスター リカバリーのために Azure Storage に直接レプリケートされます。On-premises production SQL Server 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 での 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 a 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 の可用性セットを使用すると、高可用性ノードを別個の障害ドメイン (FD) と更新ドメイン (UD) に配置できます。Availability sets in Azure enable you to place the high availability nodes into separate Fault Domains (FDs) and Update Domains (UDs). Azure VM を同じ可用性セットに配置するには、同じクラウド サービスにデプロイする必要があります。For Azure VMs to be placed in the same availability set, you must deploy them in the same cloud service. 同じクラウド サービス上にあるノードのみが同じ可用性セットに属することができます。Only nodes in the same cloud service can participate in the same availability set. 詳細については、「 Virtual Machines の可用性管理」を参照してください。For more information, see Manage the Availability of Virtual Machines.

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

Azure の RFC に準拠していない DHCP サービスが原因で、特定のフェールオーバー クラスター構成の作成が失敗する場合があります。これは、クラスター ネットワーク名に重複する IP アドレス (クラスター ノードのいずれかと同じ IP アドレスなど) が割り当てられているためです。The non-RFC-compliant DHCP service in Azure can cause the creation of certain failover cluster configurations to fail, due to the cluster network name being assigned a duplicate IP address, such as the same IP address as one of the cluster nodes. これは、Windows フェールオーバー クラスター機能に依存する、可用性グループを実装するときに問題になります。This is an issue when you implement Availability Groups, which depends 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, then NODE1 requests a dynamically assigned IP address for the cluster network name.
  2. DHCP サービスは、要求が NODE1 自体から送られてきていると認識するため、DHCP サービスからは NODE1 自体の IP アドレス以外の IP アドレスは取得できません。No IP address other than NODE1’s own IP address is given by the DHCP service, since 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 network name, and the default cluster group fails to come online.
  4. 既定のクラスター グループは、NODE2 に移動されます。NODE1 の IP アドレスはクラスター IP アドレスとして処理され、既定のクラスター グループがオンラインになります。The default cluster group moves to NODE2, which treats NODE1’s IP address as the cluster IP address and brings the default cluster group online.
  5. NODE2 が NODE1 との接続を確立しようとするときに、NODE1 宛てのパケットは、NODE1 の IP アドレスが NODE2 の IP アドレスに解決されるため、NODE2 から送信されません。When NODE2 attempts to establish connectivity with NODE1, packets directed at NODE1 never leave NODE2 because it resolves NODE1’s IP address to itself. NODE2 が NODE1 との接続を確立できず、クォーラムを失って、クラスターがシャットダウンされます。NODE2 cannot establish connectivity with NODE1, then loses quorum and shuts down the cluster.
  6. 一方、NODE1 は NODE2 にパケットを送信できますが、NODE2 は応答できません。In the meantime, NODE1 can send packets to NODE2, but NODE2 cannot reply. NODE1 はクォーラムを失い、クラスターをシャットダウンします。NODE1 loses quorum and shuts down the cluster.

このシナリオは、クラスター ネットワーク名をオンラインにするために、クラスター ネットワーク名にリンク ローカル IP アドレス (169.254.1.1 など) のような未使用の静的 IP アドレスを割り当てることによって回避できます。This scenario can be avoided by assigning an unused static IP address, such as a link-local IP address like 169.254.1.1, to the cluster network name in order to bring the cluster network name online. このプロセスを簡略化するには、可用性グループのための 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).

可用性グループ リスナーのサポートAvailability group listener support

可用性グループ リスナーは、Windows Server 2008 R2、Windows Server 2012、Windows Server 2012 R2、および Windows Server 2016 を実行している Azure VM でサポートされます。Availability group listeners are supported on Azure VMs running Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016. このサポートは、可用性グループ ノードである 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 that are running in Azure as well as those running on-premises.

リスナーを設定するための主なオプションには、外部 (パブリック) と内部の 2 つがあります。There are two main options for setting up your listener: external (public) or internal. 外部 (パブリック) リスナーは、インターネットに接続されているロード バランサーを使用し、インターネット経由でアクセスできるパブリック仮想 IP (VIP) と関連付けられます。The external (public) listener uses an internet facing load balancer and is associated with a public Virtual IP (VIP) that is accessible over the internet. 内部リスナーは、内部ロード バランサーを使用し、同じ Virtual Network 内のクライアントのみをサポートします。An internal listener uses an internal load balancer and only supports 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. リスナーの設定方法については、次を参照してください。For instructions on setting up a listener, see

この場合でも、サービス インスタンスに直接接続することで、各可用性レプリカに個別に接続できます。You can still connect to each availability replica separately by connecting directly to the service instance. また、可用性グループはデータベース ミラーリング クライアントとの下位互換性があるため、レプリカがデータベース ミラーリングと同様に、次のように構成されていれば、データベース ミラーリング パートナーのように可用性レプリカに接続できます。Also, since 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 similar to database mirroring:

  • 1 つのプライマリ レプリカと 1 つのセカンダリ レプリカ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 を使用する、このデータベース ミラーリングと同様の構成に対応するクライアント接続文字列の例を、次に示します。An example client connection string that corresponds to this database mirroring-like configuration using ADO.NET or SQL Server Native Client is below:

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

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

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

オンプレミス ネットワークと Azure 間に長いネットワーク待ち時間が生じる期間があることを前提にして、HADR ソリューションをデプロイする必要があります。You should deploy your HADR solution with the assumption that there may be periods of time with high network latency between your on-premises network and Azure. レプリカを Azure にデプロイする際は、同期モードで、同期コミットではなく非同期コミットを使用してください。When deploying replicas to Azure, you should use asynchronous commit instead of synchronous commit for the synchronization mode. オンプレミスと Azure の両方にデータベース ミラーリング サーバーをデプロイする際は、高い安全性モードではなく高いパフォーマンス モードを使用してください。When 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 may 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 of transactions. ストレージ アカウントの geo レプリケーションを無効にするオプションがない場合は、特定のデータベースのすべてのデータ ファイルとログ ファイルを同じディスクに置く必要があります。If you do not have the option to disable geo-replication on the storage account, you should keep all data and log files for a given database on the same disk. データベースのサイズのために複数のディスクを使用する必要がある場合は、データの冗長性を確保するために、前に示したディザスター リカバリー ソリューションのいずれかをデプロイする必要があります。If you must use more than one disk due to the size of the database, you need to deploy one of the disaster recovery solutions listed above to ensure data redundancy.

次の手順Next steps

Azure 仮想マシンと SQL Server を作成する必要がある場合は、「 Azure での SQL Server 仮想マシンのプロビジョニング」を参照してください。If you need to create an Azure virtual machine with SQL Server, see Provisioning a SQL Server Virtual Machine on Azure.

Azure VM で実行されている SQL Server のパフォーマンスを最大限まで高めるには、「 Azure Virtual Machines における SQL Server のパフォーマンスに関するベスト プラクティス」のガイダンスをご覧ください。To get the best performance from SQL Server running on an Azure VM, see the guidance in Performance Best Practices for SQL Server in Azure Virtual Machines.

Azure VM での SQL Server の実行に関するその他のトピックについては、「 Azure Virtual Machines における SQL Server」を参照してください。For other topics related to running SQL Server in Azure VMs, see SQL Server on Azure Virtual Machines.

その他のリソースOther resources