ドメインに依存しない可用性グループDomain Independent Availability Groups

Always On 可用性グループ (AG) には、基になる Windows Server フェールオーバー クラスター (WSFC) が必要です。Always On Availability Groups (AGs) require an underlying Windows Server failover cluster (WSFC). Windows Server 2012 R2 を使用して WSFC を展開するには、WSFC (ノードとも呼ばれる) に参加しているサーバーが同じドメインに追加されていることが常に必要です。Deploying a WSFC through Windows Server 2012 R2 has always required that the servers participating in a WSFC, also known as nodes, are joined to the same domain. Active Directory Domain Services (AD DS) の詳細については、ここを参照してください。For more information on Active Directory Domain Services (AD DS), see here.

データベース ミラーリング (DBM) は、このような依存関係を持たずに、証明書を使用して複数のデータ センターに展開できるため、AD DS と WSFC の依存関係は、DBM の構成で以前に展開されたものよりも複雑です。The AD DS and WSFC dependency is more complex than what has been previously deployed with a Database Mirroring (DBM) configuration, since DBM can be deployed across multiple data centers using certificates, without any such dependencies. 複数のデータ センターに広がる従来の可用性グループでは、すべてのサーバーが同じ Active Directory ドメインに参加している必要があります。異なるドメインでは、信頼されたドメインであっても動作しません。A traditional availability group spanning more than one data center requires that all servers must be joined to the same Active Directory domain -- different domains, even trusted domains, do not work. すべてのサーバーが、同じ WSFC のノードである必要があります。All the servers must be nodes of the same WSFC. この構成を次の図に示します。The following figure shows this configuration. SQL Server 2016 には、異なる方法でこの目的を達成することもできる、分散された可用性グループもあります。SQL Server 2016 also has distributed availability groups which can also achieve this goal in a different way.

同じドメインに接続された 2 つのデータ センターに広がる WSFC

Windows Server 2012 R2 では、可用性グループで使用できる Windows Server フェールオーバー クラスターの特殊な形式である、Active Directory がデタッチされたクラスターを導入しました。Windows Server 2012 R2 introduced an Active Directory-Detached Cluster, a specialized form of a Windows Server failover cluster which can be used with availability groups. この種類の WSFC は、同じ Active Directory ドメインにドメイン参加しているノードがまだ必要です。ただし、この場合、WSFC は DNS を使用していますが、ドメインは使用しません。This type of WSFC still requires the nodes to be domain-joined to the same Active Directory domain, but in this case the WSFC is using DNS, but not using the domain. ドメインが引き続き含まれているため、Active Directory がデタッチされたクラスターでは、完全にドメインを必要としないエクスペリエンスを提供することはまだありません。Since a domain is still involved, an Active Directory-Detached Cluster still does not provide a completely domain-free experience.

Windows Server 2016 では、Active Directory がデタッチされたクラスター (ワークグループ クラスター) を基にした新しい種類の Windows Server フェールオーバー クラスターを導入しました。Windows Server 2016 introduced a new kind of Windows Server failover cluster based on the foundation of the Active Directory-Detached Cluster -- a Workgroup Cluster. ワークグループ クラスターによって、SQL Server 2016 は、AD DS を必要としない WSFC の上部に可用性グループを展開することができます。A Workgroup Cluster allows SQL Server 2016 to deploy an availability group on top of a WSFC that does not require AD DS. SQL Server では、データベース ミラーリングのシナリオで証明書が必要なように、エンドポイントのセキュリティに証明書を使用する必要があります。SQL Server requires the use of certificates for endpoint security, just as the database mirroring scenario requires certificates. 可用性グループのこの種類は、ドメインに依存しない可用性グループと呼ばれます。This type of an availability group is called a Domain Independent Availability Group. 基になるワークグループ クラスターでの可用性グループの展開では、WSFC を構成するノードに対して次の組み合わせをサポートします。Deploying an availability group with an underlying Workgroup Cluster supports the following combinations for the nodes that will make up the WSFC:

  • ドメインに参加しているノードはありません。No nodes are joined to a domain.
  • すべてのノードが異なるドメインに参加しています。All nodes are joined to different domains.
  • ノードがドメインに参加しているノートとドメインに参加していないノードを組み合わせて混在しています。Nodes are mixed, with a combination of domain-joined and non-domain-joined nodes.

次の図は、Data Center 1 のノードはドメインに参加していますが、Data Center 2 のノードは DNS のみを使用する場合のドメインに依存しない可用性グループの例を示します。The next figure shows an example of a Domain Independent Availability Group where the nodes in Data Center 1 are domain-joined but the ones in Data Center 2 only use DNS. この場合、WSFC のノードになるすべてのサーバーで DNS サフィックスを設定します。In this case, set the DNS suffix on all servers that will be nodes of the WSFC. 可用性グループにアクセスしているすべてのアプリケーションとサーバーが、同じ DNS 情報を参照する必要があります。Every application and server accessing the availability group must see the same DNS information.

1 つのドメインに参加している 2 つのノードを含むワークグループ クラスター

ドメインに依存しない可用性グループは、マルチサイトまたはディザスター リカバリー シナリオに使用するためだけではありません。A Domain Independent Availability Group is not just for multi-site or disaster recovery scenarios. これは、1 つのデータ センターに展開することができ、基本的な可用性グループ (Standard Edition 可用性グループとしても知られる) でも使用され、次のように証明書を含むデータベース モニタリングを使用して達成するために使用されるものに同様のアーキテクチャを提供します。It can be deployed in a single data center and even used with a Basic Availability Group (also known as a Standard Edition availability group) to provide a similar architecture to what used to be achieved using Database Mirroring with certificates as shown.

Standard Edition の AG の高レベルのビュー

ドメインに依存しない可用性グループの展開には、既知の注意事項がいくつかあります。Deploying a Domain Independent Availability Group has some known caveats:

  • クォーラムと共に使用できる監視の種類は、ディスクとクラウドのみです。クラウドは、Windows Server 2016 の新機能です。The only witness types available for use with quorum are disk and cloud, which is new in Windows Server 2016. 可用性グループによる共有ディスクの使用はほとんどないため、ディスクでは問題があります。Disk is problematic since there is most likely no use of shared disk by the availability group.
  • WSFC の基になるワークグループ クラスター バリアントは、PowerShell を使用してのみ作成できますが、フェールオーバー クラスター マネージャーを使用して管理することができます。The underlying Workgroup Cluster variant of a WSFC can only be created using PowerShell, but it can then be administered using the Failover Cluster Manager.
  • Kerberos が必要な場合、Active Directory にアタッチされる標準の WSFC を展開する必要があります。ドメインに依存しない可用性グループは、オプションではない可能性があります。If Kerberos is required, you must deploy a standard WSFC that is attached to an Active Directory domain, and a Domain Independent Availability Group is probably not an option.
  • リスナーが構成されるときは、使用できる DNS に登録される必要があります。While a listener can be configured, it must be registered in DNS to be usable. 前述のとおり、リスナーに対する Kerberos サポートはありません。As noted above, there is no Kerberos support for the listener.
  • ドメインが存在しなかったり、連携するように構成されていない可能性があったりするため、SQL Server に接続しているアプリケーションでは、主に SQL Server 認証を使用します。Applications connecting to SQL Server should primarily use SQL Server authentication since domains may not exist, or may not be configured to work together.
  • 証明書は、可用性グループの構成で使用されます。Certificates will be used in the configuration of the availability group.

すべてのレプリカ サーバーで DNS サフィックスを設定および確認するSet and verify the DNS suffix on all replica servers

共通の DNS サフィックスは、ドメインに依存しない可用性グループのワークグループ クラスターに必要です。A common DNS suffix is necessary for a Domain Independent Availability Group’s Workgroup Cluster. 可用性グループのレプリカをホストする各 Windows Server に DNS サフィックスを設定および確認するには、次の手順に従います。To set and verify the DNS suffix on each Windows Server that will host a replica for the availability group, follow these instructions:

  1. Windows キー + X キーのショートカットを使用して、[システム] を選択します。Using the Windows Key + X shortcut, select System.
  2. コンピューター名と完全なコンピューター名が同じ場合は、DNS サフィックスは設定されていません。If the computer name and the full computer name are the same, the DNS suffix has not been set. たとえば、コンピューター名が ALLAN の場合、完全なコンピューター名の値は、ALLAN だけにはなりません。For example, if the computer name is ALLAN, the value for the full computer name should not be just ALLAN. ALLAN.SQLHA.LAB のようになります。It should be something like ALLAN.SQLHA.LAB. SQLHA.LAB は、DNS サフィックスです。SQLHA.LAB is the DNS suffix. ワークグループの値は、WORKGROUP となります。The value for Workgroup should say WORKGROUP. DNS サフィックスを設定する必要がある場合は、[設定の変更] を選択します。If you need to set the DNS suffix, select Change Settings.
  3. [システムのプロパティ] の [コンピューター名] タブで、[変更] をクリックします。On the System Properties dialog, click Change on the Computer Name tab.
  4. [コンピューター名/ドメイン名の変更] ダイアログで、[詳細] をクリックします。On the Computer Name/Domain Changes dialog, click More.
  5. [DNS サフィックスと NetBIOS コンピューター名] ダイアログで、プライマリ DNS サフィックスとして、共通の DNS サフィックスを入力します。On the DNS Suffix and NetBIOS Computer Name dialog, enter the common DNS suffix as the Primary DNS suffix.
  6. [OK] をクリックして、[DNS サフィックスと NetBIOS コンピューター名] ダイアログを閉じます。Click OK to close the DNS Suffix and NetBIOS Computer Name dialog.
  7. [OK] をクリックして、[コンピューター名/ドメイン名の変更] ダイアログを閉じます。Click OK to close the Computer Name/Domain Changes dialog.
  8. 変更を有効にするために、サーバーを再起動するようメッセージが表示されます。You will be prompted to restart the server for the changes to take effect. [OK] をクリックして、[コンピューター名/ドメイン名の変更] ダイアログを閉じます。Click OK to close the Computer Name/Domain Changes dialog.
  9. [閉じる] をクリックして、[システムのプロパティ] ダイアログを閉じます。Click Close to close the System Properties dialog.
  10. 再起動を求めるメッセージが表示されます。You will be prompted to restart. すぐに再起動しない場合は、[後で再起動] をクリックします。それ以外の場合は、[今すぐ再起動する] をクリックします。If you do not want to restart immediately, click Restart Later, otherwise click Restart Now.
  11. サーバーが再起動されたら、もう一度システムを確認して、共通の DNS サフィックスが構成されていることを確認します。After the server has rebooted, verify that the common DNS suffix is configured by looking at System again.

DNS サフィックスの正常に終了した構成

ドメインに依存しない可用性グループを作成するCreate a Domain Independent Availability Group

現在、ドメインの独立した可用性グループの作成は、SQL Server Management Studio を使用して完全に達成することはできません。Creating a Domain Independent Availability Group cannot currently be achieved completely using SQL Server Management Studio. ドメインに依存しない可用性グループの作成は、標準の可用性グループの作成と基本的に同じですが、特定のアスペクト (証明書の作成など) は Transact-SQL でのみ可能です。While creating the Domain Independent Availability Group is basically the same as the creation of a normal availability group, certain aspects (such as creating the certificates) are only possible with Transact-SQL. 次の例は、2 つのレプリカを持つ可用性グループの構成を想定しています。プライマリが 1 つとセカンダリが 1 つです。The example below assumes an availability group configuration with two replicas: one primary and one secondary.

  1. このリンクの手順を使用して、すべてが可用性グループに参加するサーバーで構成されるワークグループ クラスターを展開します。Using the instructions at this link, deploy a Workgroup Cluster composed of all servers that will participate in the availability group. ワークグループ クラスターを構成する前に、共通の DNS サフィックスが既に構成されていることを確認します。Ensure that the common DNS suffix is already configured before configuring the Workgroup Cluster.
  2. 可用性グループに追加する各インスタンスの Always On 可用性グループ機能を有効にしますEnable the Always On Availability Groups feature on each instance that will be participating in the availability group. これには、各 SQL Server インスタンスの再起動が必要がです。This will require a restart of each SQL Server instance.
  3. プライマリ レプリカをホストするインスタンスごとに、データベース マスター キーが必要です。Each instance that will host the primary replica requires a database master key. マスター キーがまだ存在していない場合は、次のコマンドを実行します。If a master key does not exist already, run the following command: CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Strong Password'; GO
  4. プライマリ レプリカとなるインスタンスで、セカンダリ レプリカの着信接続用と、プライマリ レプリカのエンドポイントをセキュリティで保護するために使用される証明書を作成します。On the instance that will be the primary replica, create the certificate that will be used both for inbound connections on the secondary replicas and for securing the endpoint on the primary replica. CREATE CERTIFICATE InstanceA_Cert WITH SUBJECT = 'InstanceA Certificate'; GO
  5. 証明書をバックアップします。Back up the certificate. また、必要であれば、秘密キーを使ってさらにセキュリティで保護することもできます。You can also secure it further with a private key if desired. この例では、秘密キーを使用しません。This example does not use a private key. BACKUP CERTIFICATE InstanceA_Cert TO FILE = 'Backup_path\InstanceA_Cert.cer'; GO
  6. 手順 4 と 5 を繰り返して、InstanceB_Cert などの証明書の適切な名前を使用し、セカンダリ レプリカごとに証明書を作成してバックアップします。Repeat Steps 4 and 5 to create and back up certificates for each secondary replica, using appropriate names for the certificates, such as InstanceB_Cert.
  7. プライマリ レプリカでは、可用性グループのセカンダリ レプリカごとにログインを作成する必要があります。On the primary replica, you must create a login for each secondary replica of the availability group. このログインには、ドメインに依存しない可用性グループによって使用されるエンドポイントに接続するアクセス許可が付与されます。This login will be granted permissions to connect to the endpoint used by the Domain Independent Availability Group. たとえば、InstanceB という名前のレプリカの場合For example, for a replica named InstanceB: CREATE LOGIN InstanceB_Login WITH PASSWORD = 'Strong Password'; GO
  8. 各セカンダリ レプリカで、プライマリ レプリカのログインを作成します。On each secondary replica, create a login for the primary replica. このログインには、エンドポイントに接続するアクセス許可が付与されます。This login will be granted permissions to connect to the endpoint. たとえば、InstanceB という名前のレプリカで次を実行します。For example, on a replica named InstanceB: CREATE LOGIN InstanceA_Login WITH PASSWORD = 'Strong Password'; GO
  9. すべてのインスタンスで、作成されたログインごとにユーザーを作成します。On all instances, create a user for each login that was created. これは、証明書を復元するときに使用されます。This will be used when restoring the certificates. たとえば、プライマリ レプリカのユーザーを作成するには、次を実行します。For example, to create a user for the primary replica: CREATE USER InstanceA_User FOR LOGIN InstanceA_Login; GO
  10. プライマリになる可能性があるレプリカでは、関連するすべてのセカンダリ レプリカでログインとユーザーを作成します。For any replica that may be a primary, create a login and user on all relevant secondary replicas.
  11. 各インスタンスで、作成されたログインとユーザーがある他のインスタンスに証明書を復元します。On each instance, restore the certificates for the other instances that had a login and user created. プライマリ レプリカで、すべてのセカンダリ レプリカの証明書を復元します。On the primary replica, restore all secondary replica certificates. 各セカンダリで、プライマリ レプリカの証明書を復元します。また、プライマリになる可能性があるその他のレプリカにも復元します。On each secondary, restore the certificate of the primary replica, and also on any other replica that could be a primary. 例:For example: CREATE CERTIFICATE [InstanceB_Cert] AUTHORIZATION InstanceB_User FROM FILE = 'Restore_path\InstanceB_Cert.cer'
  12. レプリカになる各インスタンスに、可用性グループによって使用されるエンドポイントを作成します。Create the endpoint that will be used by the availability group on each instance that will be a replica. 可用性グループの場合は、エンドポイントに DATABASE_MIRRORING の型がある必要があります。For availability groups, the endpoint must have a type of DATABASE_MIRRORING. エンドポイントでは、手順 4 で認証のインスタンスのために作成した証明書を使用します。The endpoint uses the certificate created in Step 4 for that instance for authentication. 以下の構文は、証明書を使用してエンドポイントを作成する例を示しています。Example syntax is shown below to create an endpoint using a certificate. 適切な暗号化方法と、環境に関連するその他のオプションを使用します。Use the appropriate encryption method and other options relevant to your environment. 使用できるオプションの詳細については、「CREATE ENDPOINT (Transact-SQL)」を参照してください。For more information on the options available see CREATE ENDPOINT (Transact-SQL). CREATE ENDPOINT DIAG_EP STATE = STARTED AS TCP ( LISTENER_PORT = 5022, LISTENER_IP = ALL ) FOR DATABASE_MIRRORING ( AUTHENTICATION = CERTIFICATE InstanceX_Cert, ROLE = ALL )
  13. エンドポイントに接続できるように、手順 9 のインスタンスで作成された各ユーザーに権限を割り当てます。Assign rights to each user created on that instance in Step 9 to be able to connect to the endpoint. GRANT CONNECT ON ENDPOINT::DIAG_EP TO 'InstanceX_User'; GO
  14. 基になる証明書とエンドポイントのセキュリティが構成されたら、指定した方法を使用して、可用性グループを作成します。Once the underlying certificates and endpoint security are configured, create the availability group using your preferred method. セカンダリの初期化に使用するバックアップを手動でバックアップ、コピー、および復元するか、または自動シード処理を使用することをお勧めします。It is recommended to manually back up, copy, and restore the backup used to initialize the secondary, or use automatic seeding. セカンダリ レプリカを初期化するためのウィザードの使用には、サーバー メッセージ ブロック (SMB) ファイルが関係し、ドメインに参加していないワークグループ クラスターを使用する場合は動作しない可能性があります。Using the Wizard to initialize the secondary replicas involves the use of Server Message Block (SMB) files, which may not work when using a non-domain-joined Workgroup Cluster.
  15. リスナーを作成する場合は、その名前と IP アドレスの両方が DNS に登録されていることを確認します。If creating a listener, make sure that both its name and its IP address are registered in DNS.

次の手順Next steps