翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon EC2 for SQL Server セクション
Amazon EC2 は、自己管理 SQL Server データベースをサポートしています。つまり、インフラストラクチャとデータベース環境のセットアップを完全に制御することができます。Amazon EC2 でデータベースを実行することは、独自のサーバーでデータベースを実行することとよく似ています。データベースとオペレーティングシステムレベルのアクセスを完全に制御できるため、選択したツールを使用して、オペレーティングシステム、データベースソフトウェア、パッチ、データ複製、バックアップ、および復元を管理することができます。この移行オプションでは、 AWS アーキテクチャのベストプラクティスに基づいて、EC2 インスタンス、ストレージボリューム、スケーラビリティ、ネットワーク、セキュリティなど、すべてのコンポーネントを設定、設定、管理、調整する必要があります。同じリージョンまたは異なる AWS リージョンのインスタンス間でのデータレプリケーションとリカバリは、お客様の責任となります。
## Amazon EC2 を選ぶタイミング
Amazon EC2 は、以下の場合に SQL Server データベースの移行オプションとして適しています。
+ データベースを完全に制御し、基盤となるオペレーティングシステム、データベースのインストール、設定にアクセスする必要があります。
+ バックアップとリカバリ、オペレーティングシステムとデータベースへのパッチ適用、オペレーティングシステムとデータベースパラメータの調整、セキュリティの管理、高可用性またはレプリケーションの設定など、データベースを管理したい場合。
+ Amazon RDS が現在サポートしていない機能やオプションを使いたい場合。詳細については、Amazon RDS ドキュメントの「[サポートされていない機能とサポートが制限されている機能](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.FeatureNonSupport)」を参照してください。
+ Amazon RDS でサポートされていない特定の SQL Server バージョンが必要です。サポートされているバージョンとエディションのリストについては、Amazon RDS ドキュメントの 「[Amazon RDS での SQL Server バージョン](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.VersionSupport)」を参照してください。
+ データベースのサイズとパフォーマンス要件は、現在の Amazon RDS for SQL Server サービスを超えています。詳細については、Amazon RDS ドキュメントの「[Amazon RDS DB インスタンスストレージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html)」を参照してください。
+ アプリケーションに適合しない可能性がある自動ソフトウェアパッチは避けたいです。
+ Amazon RDS for SQL Server のライセンス込みモデルを使用する代わりに、独自のライセンスを持参する必要があります。
+ 現在の制限よりも高い IOPS とストレージ容量を実現したい場合。詳細については、Amazon RDS ドキュメントの「[Amazon RDS DB インスタンスストレージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html)」を参照してください。
Amazon EC2 で現在サポートされている SQL Server の機能とバージョンのリストについては、このガイドの後半にある「[Amazon EC2 と Amazon RDS から選択する](comparison.md)」を参照してください。
# 高可用性
Amazon EC2 上の SQL Server データベースでは、SQL Server がサポートする任意のレプリケーションテクノロジーを使用して、高可用性、データ保護、およびディザスタリカバリを実現することができます。一般的なソリューションには、ログ配布、データベースミラーリング、Always On 可用性グループ、Always On フェイルオーバークラスターインスタンスなどがあります。
次の図は、1 つの AWS リージョン内の複数のアベイラビリティーゾーンで Amazon EC2 で SQL Server を使用する方法を示しています。プライマリデータベースは読み書き可能なデータベースであり、セカンダリデータベースは高可用性のためにログシッピング、データベースミラーリング、またはAlways On可用性グループによって設定されます。プライマリデータベースからのトランザクションデータはすべて転送され、ログ配布の場合は非同期でセカンダリデータベースに適用でき、Always On 可用性グループとミラーリングの場合は非同期で適用できます。
![\[SQL Server on Amazon EC2 in a Multi-AZ configuration in one AWS Region\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/migration-sql-server/images/sql-migration-ec2.png)
# ログ配布
ログ配布では、プライマリデータベースインスタンスから別の DB インスタンスにある 1 つ以上のセカンダリデータベース(*ウォームスタンバイ*とも呼ばれる)にトランザクションログのバックアップを自動的に送信できます。ログ配布では、SQL Server エージェントジョブを使用して、トランザクションログバックアップのバックアップ、コピー、適用を自動化します。ログ配布は一般的にディザスタリカバリ機能と考えられていますが、プライマリ DB インスタンスに障害が発生した場合にセカンダリ DB インスタンスを昇格できるようにすることで、高い可用性を実現することもできます。RTO と RPO に柔軟性がある場合や、データベースがそれほどミッションクリティカルではないと考えられる場合は、ログ配布を使用して SQL Server データベースの可用性を高めることを検討してください。
ログ配布では、必要に応じてプライマリデータベースの読み取り専用コピーとして使用できるセカンダリデータベースにアクセスできるようになるため、データベースの可用性が向上されます。セカンダリ・データベースに変更が反映される前に、プライマリ・データベースで誤って変更されたデー タをリカバリできる遅延時間 (より長い遅延時間) を設定することができます。
プライマリ DB インスタンスとセカンダリ DB インスタンスを別々のアベイラビリティーゾーンで実行し、モニタリングインスタンスをデプロイしてログ配布の詳細をすべて追跡することをお勧めします。ログ配布グループのバックアップ、コピー、復元、または障害イベントは、モニターインスタンスから利用できます。ログ配布設定は、プライマリサーバーからセカンダリサーバーに自動的にフェールオーバーされません。ただし、プライマリーデータベースが利用できなくなった場合、どのセカンダリーデータベースも手動でオンラインにすることができます。
ログ配布はディザスタリカバリソリューションとしてよく使用されますが、アプリケーションの要件によっては高可用性ソリューションとしても使用できます。ログ配布は次の場合に使用します。
+ RTO と RPO の要件は柔軟に設定することができます。ログ配布は RPO を数分、RTO を数分から数時間で提供します。
+ セカンダリデータベースへの自動フェイルオーバーは必要ではありません。
+ セカンダリデータベースからデータを読みたい場合、リストア操作中に読み取り可能である必要はありません。
MARS の詳細については、[ Microsoft SQL Server](https://docs.microsoft.com/en-us/sql/database-engine/log-shipping/about-log-shipping-sql-server) のドキュメントを参照してください。
# データベースのミラーリング
データベースミラーリングは EC2 インスタンス上にあるデータベースを、完全またはほぼ完全な読み取り専用コピー (ミラー) を別の DB インスタンスに提供します。Amazon RDS はデータベースミラーリングを使用して、Amazon RDS for SQL Server のマルチ AZ サポートを提供しています。この機能により、データベースの可用性と保護が向上し、アップグレード中もデータベースを使用可能な状態に保つメカニズムが提供されます。
**注記**
[Microsoft のドキュメント](https://docs.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server)によると、データベースミラーリングはSQL Serverの将来のバージョンで削除される予定です。代わりに Always On可用性グループを使用するよう計画してください。
データベースミラーリングでは、SQL サーバーは次の 3 つの役割のいずれかを担うことができます。
+ プライマリ読み取り/書き込みバージョンのデータベースをホストするプリンシパルサーバー。
+ プリンシパルデータベースのコピーをホストするミラーサーバー。
+ オプションの監視サーバー。このサーバーは高安全モードでのみ使用可能です。データベースミラーの状態をモニタリングし、プライマリデータベースからミラーデータベースへのフェイルオーバーを自動化します。
プリンシパルサーバーとミラーサーバーの間でミラーリングセッションが確立されます。ミラーリング中、プリンシパルデータベースで行われたすべてのデータベース変更は、ミラーデータベースでも実行されます。データベースミラーリングは、同期操作でも非同期操作でもかまいません。これは、高安全モードと高性能モードという 2 つのミラーリング動作モードによって決まります。
+ **高安全モード**:このモードは同期操作を使用します。このモードでは、データベースミラーリングセッションは、挿入、更新、削除操作をプリンシパルデータベースからミラーデータベースにできるだけ早く同期します。データベースが同期されるとすぐに、トランザクションはプリンシパルデータベースとミラーデータベースの両方でコミットされます。ミラーデータベースが同じまたは異なるアベイラビリティーゾーンにあるが、同じ AWS リージョン内でホストされている場合は、このオペレーションモードを使用することをお勧めします。
+ **高性能モード:**このモードでは、非同期オペレーションを使用します。このモードでは、データベースミラーリングセッションは挿入、更新、削除操作をプリンシパルデータベースからミラーデータベースに同期しますが、プリンシパルデータベースがトランザクションをコミットしてからミラーデータベースがトランザクションをコミットするまでに時間差が生じることがあります。ミラーデータベースが異なる AWS リージョンにある場合は、このモードを使用することをお勧めします。
データベースミラーリングは次の場合に使用します。
+ RTO と RPO の要件が厳しく、プライマリデータベースとセカンダリデータベース間の遅延があってはなりません。データベースミラーリングでは、RPO は 0 秒 (同期コミットの場合)、数秒から数分の RTO を提供する。
+ セカンダリデータベースから読み取る必要はありません。
+ ミラーリング監視サーバーが同期モードに設定されている場合は、自動フェイルオーバーを実行したい場合。
+ 推奨オプションである Always On 可用性グループは使用できません。
機能制限:
+ 1 対 1 のフェイルオーバーのみがサポートされます。複数のデータベース宛先をプライマリデータベースと同期させることはできません。
MARS の詳細については、[ Microsoft SQL Server](https://docs.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server) のドキュメントを参照してください。
# Always On 可用性グループ
SQL Server Always On 可用性グループは、SQL Server データベースの高可用性とディザスタリカバリソリューションを提供します。可用性グループは、フェイルオーバーされるユーザーデータベースのセットで構成されます。これには、1 セットの読み取り/書き込み可能なプライマリデータベースと、複数セット (1 ～ 8) の関連するセカンダリデータベースが含まれます。セカンダリデータベースをプライマリデータベース (SQL Server Enterprise エディションのみ) の読み取り専用コピーとしてアプリケーション層で利用できるようにして、読み取りワークロードのスケールアウトアーキテクチャを実現することができます。セカンダリデータベースはバックアップ操作に使用することもできます。
SQL Server Always On 可用性グループは、同期コミットモードと非同期コミットモードの両方をサポートしています。同期モードでは、変更がコミットされたり、セカンダリレプリカのログに書き込まれたりした後に、プライマリレプリカがデータベーストランザクションをコミットします。このモードを使用すると、計画的な手動フェイルオーバーと、レプリカが同期している場合の自動フェイルオーバーを実行することができます。同じ環境内の SQL Server インスタンス間で同期コミットモードを使用できます (たとえば、すべてのインスタンスがオンプレミスであるか、すべてのインスタンスが にある場合) AWS。
非同期コミットモードでは、プライマリレプリカはセカンダリレプリカを待たずにデータベーストランザクションをコミットします。異なる環境にある SQL Server インスタンス間で非同期コミットモードを使用できます (たとえば、オンプレミスと にインスタンスがある場合) AWS。
Always On 可用性グループは高可用性またはディザスタリカバリに使用することができます。この方法は次の場合に使用します。
+ RTO と RPO の要件は柔軟に設定することができます。Always On 可用性グループでは、RPO は秒単位、RTO は秒単位から分単位です。
+ データベースグループを管理し、フェイルオーバーしたい場合。Always On 可用性グループは、SQL Server 2019 の同期コミットモードで 0 ～ 4 個のセカンダリレプリカをサポートします。
+ 同期コミットモードでは自動フェイルオーバーを使用したい場合、監視サーバーは必要ではありません。
+ セカンダリデータベースから読みたい場合。
+ 複数のデータベース宛先をプライマリデータベースと同期したい場合。
SQL Server 2016 SP1 以降の SQL Server Standard エディションでは、可用性グループごとに 1 つの読み取り不可能なセカンダリデータベースとリスナーに基本的な高可用性が提供されます。また、可用性グループごとに最大 2 つのノードをサポートします。
# フェイルオーバー常時稼働のフェールオーバークラスターインスタンス
SQL Server Always On フェイルオーバークラスターインスタンス (FCI) は Windows Server フェイルオーバークラスタリング (WSFC) を使用して、サーバーインスタンスレベルで高可用性を提供します。FCI は SQL Server の単一インスタンスで、複数の WSFC ノードにインストールされます。これにより、SQL Server のインストール全体にわたって高可用性が実現されます。基盤となるノードでハードウェア、オペレーティングシステム、アプリケーション、またはサービスの障害が発生した場合、SQL Server インスタンス内のすべてが別の WSFC ノードに移動されます。これには、システムデータベース、SQL Server ログイン、SQL Server エージェントジョブと、証明書が含まれます。
通常、次の場合は Always on 可用性グループよりも FCI の方が適しています。
+ エンタープライズエディションの代わりに SQL Server スタンダードエディションを使用しています。
+ インスタンスごとに多数の小規模データベースがあります。
+ SQL Server エージェントのジョブ、ログインなどのインスタンスレベルのオブジェクトを絶えず変更しています。
に FCIsをデプロイするには、次の 4 つのオプションがあります AWS。
+ 永続予約機能を搭載した Amazon EBS Multi-Attach
+ Amazon FSx for Windows File Server
+ Amazon FSx for NetApp ONTAP
+ AWS パートナーからのソリューション
## 永続予約機能を搭載した Amazon EBS Multi-Attach の使用
[Amazon EBS Multi-Attach と NVMe 予約](https://docs.aws.amazon.com/ebs/latest/userguide/nvme-reservations.html)は、Windows Server フェイルオーバークラスターの共有ストレージとして Amazon EBS `io2` ボリュームを使用した SQL Server FCI の作成をサポートします。この機能は、Amazon EBS `io2`ボリュームを使用してフェイルオーバークラスターを構築できるようにすることで、フェイルオーバークラスターのセットアッププロセスを簡素化します。これらのボリュームは、インスタンスと同じアベイラビリティーゾーンに限りアタッチできます。Amazon EBS `io2`ボリュームを使用して Windows Server フェイルオーバークラスターをデプロイするには、最新の AWS NVMe ドライバーを使用する必要があります。
Amazon EBS ボリュームおよびインスタンスストアボリュームは、[Nitro ベースのインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances)で NVMe ブロックデバイスとして公開されます。Amazon EBS `io2` ボリュームを使用して WSFC および SQL Server FCI を形成する際に設定した [SCSI 永続予約機能](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-nvme-drivers.html#configure-scsi-persistent-reservations)を使用して [AWS NVMe ドライバー](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-nvme-drivers.html)をインストールする必要があります。
この機能の詳細については、 AWS ブログ記事[「How to deploy a SQL Server failover cluster with Amazon EBS Multi-Attach on Windows Server](https://aws.amazon.com/blogs/modernizing-with-aws/how-to-deploy-a-sql-server-failover-cluster-with-amazon-ebs-multi-attach-on-windows-server/)」を参照してください。
## Amazon FSx for Windows File Server の使用
[Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) は、フルマネージドの共有ファイルストレージを提供します。ストレージを 2 つのアベイラビリティーゾーンに同期して自動的に複製し、高可用性を実現します。FSx for Windows File Server ストレージを使用すると、Amazon EC2 での SQL Server の高可用性デプロイを簡素化および最適化できます。
Microsoft SQL Server を使用すると、通常、WSFC 内の複数のデータベースノードにデプロイされ、各ノードは共有ファイルストレージにアクセスできます。FSx for Windows File Server は、SQL Server 高可用性デプロイの共有ストレージとして、アクティブデータファイルのストレージとして、および SMB ファイル共有監視として使用できます。
FSx for Windows File Server を使用して SQL Server FCI デプロイの実行の複雑さとコストを削減する方法については、「[Amazon FSx for Windows File Server を使用して Microsoft SQL サーバーの高可用性デプロイを簡素化する](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/)」を参照してください。このブログ記事では、共有ストレージソリューションとして Amazon FSx Multi-AZ ファイルシステムを使用して SQL Server FCIs をデプロイする手順についてもステップバイステップで説明しています。詳細については、[Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) ドキュメントを参照してください。
## Amazon FSx for NetApp ONTAP の使用
Amazon FSx for NetApp ONTAP は、NetApp ONTAP ファイルシステム上に構築された、信頼性が高く、スケーラブルで、パフォーマンスが高く、機能が豊富なファイルストレージを提供するフルマネージドサービスです。FSx for ONTAP は、NetApp ファイルシステムの使い慣れた機能、パフォーマンス、機能、および API オペレーションと、フルマネージド AWS サービスの俊敏性、スケーラビリティ、およびシンプルさを兼ね備えています。
FSx for ONTAP は、Windows および Linux システムの NFS、SMB、iSCSI プロトコルを介してデータへのマルチプロトコルアクセスを提供します。ブログ記事「[Amazon FSx for NetApp ONTAP を使用した SQL Server の高可用性デプロイ](https://aws.amazon.com/blogs/modernizing-with-aws/sql-server-high-availability-amazon-fsx-for-netapp-ontap/)」で詳しく説明されているように、可用性が高い SQL Server Always On FCI アーキテクチャを構築できます。FSx for ONTAP は、目標復旧時間 (RTO) と目標復旧時点 (RPO) の要件を満たすために AWS リージョン 、SQL Server 環境を別の環境にフェイルオーバーする簡単な方法も提供します。詳細については、ブログ記事「[FSx for ONTAP を使用した SQL Server Always-On フェイルオーバークラスターインスタンスの HA と DR の実装](https://aws.amazon.com/blogs/storage/implementing-ha-and-dr-for-sql-server-always-on-failover-cluster-instance-using-amazon-fsx-for-netapp-ontap/)」を参照してください。
を使用して SQL Server ソリューションを AWS Launch Wizard にデプロイし AWS、Always On 可用性グループと単一ノードデプロイをサポートすることもできます。Launch Wizard は、FSx for ONTAP を共有ストレージとして Amazon EC2 上の SQL Server Always on FCI のデプロイをサポートします。このサービスは、複雑な手動デプロイプロセスを、共有ストレージに依存するオンプレミス SQL Server ワークロードの移行を加速するガイド付きコンソールベースのウィザードに置き換えることで、時間と労力を節約します。Launch Wizard が数時間で SQL Server FCIs[「Simplify SQL Server Always On deployments with AWS Launch Wizard and Amazon FSx](https://aws.amazon.com/blogs/storage/simplify-sql-server-always-on-deployments-with-the-aws-launch-wizard-and-amazon-fsx/)」を参照してください。Launch Wizard は、共有ストレージソリューションとして [Amazon FSx for Windows File Server](https://aws.amazon.com/fsx/windows/) を使用することで、SQL Server Always On FCI のデプロイもサポートしています。
## AWS パートナーからのソリューションの使用
+ [SIOS DataKeeper](https://us.sios.com/) は、 AWS リージョン および アベイラビリティーゾーン間で高可用性クラスターフェイルオーバーサポートを提供します。SIOS DataKeeper は [AWS Marketplace](https://aws.amazon.com/marketplace/seller-profile?id=3c91e2f7-fc8d-4cce-a8aa-1e37abcb4408) で利用できます。
+ DH2i の [DxEnterprise](https://dh2i.com/dxenterprise-high-availability/) により、Kubernetes の SQL Server 可用性グループの完全自動フェイルオーバーと、Windows および Linux の統合インスタンスフェイルオーバーが可能になります。D2HI は [AWS Marketplace](https://aws.amazon.com/marketplace/seller-profile?id=4e97d4b7-3366-42fd-8be8-732d38c9e24b) で使用できます。
# FSx for Windows File Server
FSx for Windows File Server は、SMB (Server Message Block) プロトコルを使用してアクセス可能な、フルマネージド、高信頼性、スケーラブルなファイルストレージを提供します。Windows Server 上に構築されており、ユーザークォータ、エンドユーザーファイルの復元、Microsoft Active Directory (AD) 統合など、さまざまな管理機能を備えています。シングル AZ とマルチ AZ 配置オプション、完全マネージド型バックアップ、保管中および転送中のデータの暗号化が可能です。ソリッドステートドライブ (SSD) とハードディスクドライブ (HDD) のストレージオプションを使用すると、ワークロードのコストとパフォーマンスを最適化することができます。また、ストレージをスケールしたり、ファイルシステムのスループットパフォーマンスをいつでも変更したりできます。Amazon FSx ファイルストレージは、Windows、 で実行されている Linux コンピューティングインスタンス AWS、およびオンプレミスからアクセスできます。
Amazon FSx では、継続的可用性 (CA) ファイル共有と小規模なファイルシステムをサポートしているため、高可用性 SQL Server デプロイ用の共有 Windows ストレージを簡単にデプロイできます。このオプションは次のようなユースケースに適しています。
+ WSFC インスタンス内の SQL Server ノードが使用する共有ストレージとして使用することができます。
+ WSFC を使用する任意の SQL Server クラスターで使える SMB ファイル共有ウィットネスとして使用することができます。
Amazon FSx は、ファイルシステムあたり最大 2 GB/秒のベースラインスループット、数十万 IOPS、および安定したサブミリ秒のレイテンシーにより、高速なパフォーマンスを実現します。
SQL インスタンスに適切なパフォーマンスを提供するために、ファイルシステムのサイズに関係なくスループットレベルを選択することができます。スループットキャパシティでは、アクセスする SQL Server インスタンスにファイルサーバーが提供できる IOPS が高くなります。
ストレージ容量によって、保存できるデータ量だけでなく、そのストレージで実行できる IOPS の数も決まります。各ギガバイトのストレージは 3 IOPS です。各ファイルシステムのサイズは最大 64 TB までプロビジョニングすることができます。
SQL Server の高可用性デプロイの複雑さとコストを削減するために Amazon FSx を設定および使用する方法については、 AWS Storage ブログの[「Simplify your Microsoft SQL Server high availability deployments using FSx for Windows File Server](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/)」を参照してください。新しい CA 共有の作成の詳細については、[FSx for Windows File Server のドキュメント](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/managing-file-shares.html#create-ca-share)を参照してください。
# ディザスタリカバリ
多くの組織が SQL Server データベースに高可用性を実装していますが、真の IT レジリエンスを必要とする組織にとっては、それだけでは十分ではありません。ミッションクリティカルなデータベースのデータ損失やダウンタイムを回避するために、ディザスタリカバリソリューションを実装することをお勧めします。SQL Server のデプロイにマルチリージョンのディザスタリカバリアーキテクチャを採用すると、次のことが実現できます。
+ 事業継続性の実現
+ 地理的に分散した顧客ベースのレイテンシーの改善
+ 監査や規制の要件を満たす
ディザスタリカバリのオプションには、[ログ配信](ec2-log-shipping.md)、[Always On 可用性グループ](ec2-always-on.md)、[Amazon S3 に保存され、リージョン間でレプリケートされる Amazon EBS スナップショット](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-copy-snapshot.html)、[Always On 可用性グループと組み合わせた Always On フェイルオーバークラスターインスタンス (FCIs)](ec2-fci.md)、分散可用性グループなどがあります。 Amazon S3 AWS
## 分散可用性グループ
分散可用性グループを使用するアーキテクチャは、複数リージョンの SQL Server のデプロイに最適なアプローチです。分散可用性グループは、2 つの別々の可用性グループにまたがる特殊な種類の可用性グループです。複数の可用性グループのうちの 1 つの可用性グループと考えることができます。基盤となる可用性グループは 2 つの異なる WSFC クラスターで構成されます。
分散可用性グループは疎結合されているため、単一の WSFC クラスターを必要とせず、SQL Server によって管理されます。WSFC クラスターは個別に管理され、送信は主に 2 つの可用性グループ間で非同期で行われるため、別のサイトでのディザスタリカバリ設定が容易です。各可用性グループのプライマリレプリカは、独自のセカンダリレプリカを同期します。
分散可用性グループでは、現時点では手動フェイルオーバーのみがサポートされています。データが失われないようにするには、グローバルプライマリデータベース(つまり、プライマリ可用性グループのデータベース) のすべてのトランザクションを停止します。次に、分散可用性グループを同期コミットに設定します。