ドメインに依存しない可用性グループを作成する

適用対象 SQL Server

Always On 可用性グループ (AG) には、基になる Windows Server フェールオーバー クラスター (WSFC) が必要です。 Windows Server 2012 R2 を使用して WSFC を展開するには、WSFC (ノードとも呼ばれる) に参加しているサーバーが同じドメインに参加している必要があります。 Active Directory Domain Services (AD DS) の詳細については、ここを参照してください。

AD DS と WSFC への依存関係は、以前にデータベース ミラーリング (DBM) 構成で展開されたときよりも複雑になります。DBM は、このような依存関係がなくても、証明書を使用して複数のデータ センターに展開できるためです。 複数のデータ センターにまたがる従来の可用性グループでは、すべてのサーバーが同じ Active Directory ドメインに参加している必要があります。 異なるドメインは、たとえ信頼されたドメインであっても機能しません。 すべてのサーバーが、同じ WSFC のノードである必要があります。 この構成を次の図に示します。 SQL Server 2016 (13.x) 以降のバージョンにも分散 AG があり、異なる方法でこの目標を達成しています。

Windows Server 2012 R2 では、可用性グループで使用できる Windows Server フェールオーバー クラスターの特殊な形式である、Active Directory からデタッチされたクラスターを導入しました。 この種類の WSFC は、同じ Active Directory ドメインにドメイン参加しているノードがまだ必要です。ただし、この場合、WSFC は DNS を使用していますが、ドメインは使用しません。 ドメインが依然として関与しているため、Active Directory からデタッチされたクラスターでは、ドメインを必要としないエクスペリエンスは提供されません。

Windows Server 2016 では、Active Directory からデタッチされたクラスターを基盤にした新しい種類の Windows Server フェールオーバー クラスター、ワークグループ クラスターを導入しました。 ワークグループ クラスターを使用すると、SQL Server は、AD DS を必要としない WSFC 上に可用性グループを展開することができます。 SQL Server では、データベース ミラーリングのシナリオで証明書が必要なように、エンドポイントのセキュリティに証明書を使用する必要があります。 この種類の可用性グループは、ドメインに依存しない可用性グループと呼ばれます。 基になるワークグループ クラスターを使用して可用性グループを展開すると、WSFC を構成するノードの次の組み合わせがサポートされます。

• ドメインに参加しているノードはありません。
• すべてのノードが異なるドメインに参加しています。
• ノードがドメインに参加しているノートとドメインに参加していないノードを組み合わせて混在しています。

次の図は、ドメインに依存しない可用性グループの例を示しています。ここでは、Data Center 1 のノードはドメインに参加していますが、Data Center 2 のノードは DNS のみを使用しています。 この場合、WSFC のノードになるすべてのサーバーで DNS サフィックスを設定します。 可用性グループにアクセスしているすべてのアプリケーションとサーバーが、同じ DNS 情報を参照する必要があります。

ドメインに依存しない可用性グループは、マルチサイトまたはディザスター リカバリーのシナリオだけを目的としたものではありません。 単一のデータ センターに展開し、基本的な可用性グループと共に使用することもできます。 この構成では、次に示すように、証明書を使用したデータベース ミラーリングで実現可能なアーキテクチャと同様のアーキテクチャが提供されます。

ドメインに依存しない可用性グループの展開には、既知の注意事項がいくつかあります。

• クォーラムと共に使用できる監視の種類は、ディスクとクラウドのみです。クラウドは、Windows Server 2016 の新機能です。 可用性グループで共有ディスクが使用される可能性はほとんどないため、ディスクでは問題があります。

• WSFC の基になるワークグループ クラスター バリアントは、PowerShell を使用してのみ作成できますが、その後の管理にはフェールオーバー クラスター マネージャーを使用します。

• Kerberos が必要な場合、Active Directory ドメインにアタッチされた標準の WSFC を展開する必要があるため、ドメインに依存しない可用性グループはオプションではない可能性があります。

• リスナーが構成されるときは、使用できる DNS に登録される必要があります。 前述したとおり、リスナーに対する Kerberos サポートはありません。

• ドメインが存在しなかったり、連携するように構成されていない可能性があったりするため、SQL Server に接続しているアプリケーションでは、主に SQL Server 認証を使用する必要があります。

• 証明書は、可用性グループの構成で使用されます。

すべてのレプリカ サーバーで DNS サフィックスを設定および確認する

ドメインに依存しない可用性グループのワークグループ クラスターには、共通の DNS サフィックスが必要です。 可用性グループのレプリカをホストする各 Windows Server に DNS サフィックスを設定および確認するには、次の手順に従います。

1. Windows キー + X キーのショートカットを使用して、[システム] を選択します。
2. コンピューター名とフル コンピューター名が同じ場合、DNS サフィックスは設定されていません。 たとえば、コンピューター名が SERVER1 の場合、フル コンピューター名の値を単に SERVER1 にすることはできません。 SERVER1.CONTOSO.LAB のようになっているはずです。 CONTOSO.LAB は DNS サフィックスです。 [ワークグループ] の値は WORKGROUP となります。 DNS サフィックスを設定する必要がある場合は、[設定の変更] を選択します。
3. [システム プロパティ] ダイアログの [コンピューター名] タブで、[変更] を選択します。
4. [コンピューター名/ドメインの変更] ダイアログで、[詳細] を選択します。
5. [DNS サフィックスと NetBIOS コンピューター名] ダイアログで、共通の DNS サフィックスをプライマリ DNS サフィックスとして入力します。
6. [OK] を選択して、[DNS サフィックスと NetBIOS コンピューター名] ダイアログを閉じます。
7. [OK] を選択して、[コンピューター名/ドメインの変更] ダイアログを閉じます。
8. 変更を有効にするために、サーバーを再起動するようメッセージが表示されます。 [OK] を選択して、[コンピューター名/ドメインの変更] ダイアログを閉じます。
9. [閉じる] を選択して、[システム プロパティ] ダイアログを閉じます。
10. 再起動を求めるメッセージが表示されます。 すぐに再起動しない場合は [後で再起動する] を選択し、それ以外の場合は [今すぐ再起動する] を選択します。
11. サーバーが再起動したら、もう一度システムを確認して、共通の DNS サフィックスが構成されていることを確認します。

ドメインに依存しない可用性グループを作成する

現在、SQL Server Management Studio を使用しても、ドメインに依存しない可用性グループの完全な作成は達成できません。 ドメインに依存しない可用性グループの作成は、通常の可用性グループの作成と基本的に同じですが、特定のアスペクト (証明書の作成など) は Transact-SQL でのみ可能です。 次の例では、プライマリとセカンダリの 2 つのレプリカを持つ可用性グループの構成を想定しています。

1. 「Windows Server 2016 のワークグループ クラスターとマルチドメイン クラスター」の手順を使用して、可用性グループに参加するすべてのサーバーで構成されるワークグループ クラスターを展開します。 ワークグループ クラスターを構成する前に、共通の DNS サフィックスが既に構成されていることを確認してください。

2. 可用性グループに参加する各インスタンスで Always On 可用性グループ機能を有効または無効にします。 その際、各 SQL Server インスタンスの再起動が必要になります。

3. プライマリ レプリカをホストするインスタンスごとに、データベース マスター キー (DMK) が必要です。 DMK がまだ存在していない場合は、次のコマンドを実行します。

   CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Strong Password';
   GO
   

4. プライマリ レプリカとなるインスタンスで、セカンダリ レプリカの着信接続用と、プライマリ レプリカのエンドポイントをセキュリティで保護するために使用される証明書を作成します。

   CREATE CERTIFICATE InstanceA_Cert
   WITH SUBJECT = 'InstanceA Certificate';
   GO
   

5. 証明書をバックアップします。 また、必要であれば、秘密キーを使ってさらにセキュリティで保護することもできます。 この例では、秘密キーを使用しません。

   BACKUP CERTIFICATE InstanceA_Cert
   TO FILE = 'Backup_path\InstanceA_Cert.cer';
   GO
   

6. 手順 4 と 5 を繰り返し、証明書の適切な名前 (InstanceB_Cert など) を使用して、セカンダリ レプリカごとに証明書を作成してバックアップします。

7. プライマリ レプリカでは、可用性グループのセカンダリ レプリカごとにログインを作成する必要があります。 このログインには、ドメインに依存しない可用性グループで使用されるエンドポイントに接続するためのアクセス許可が付与されます。 たとえば、InstanceB という名前のレプリカの場合、次の操作を実行します。

   CREATE LOGIN InstanceB_Login WITH PASSWORD = 'Strong Password';
   GO
   

8. 各セカンダリ レプリカで、プライマリ レプリカのログインを作成します。 このログインには、エンドポイントに接続するためのアクセス許可が付与されます。 たとえば、InstanceB という名前のレプリカでは、次の操作を実行します。

   CREATE LOGIN InstanceA_Login WITH PASSWORD = 'Strong Password';
   GO
   

9. すべてのインスタンスで、作成されたログインごとにユーザーを作成します。 このユーザーは、証明書を復元するときに使用されます。 たとえば、プライマリ レプリカのユーザーを作成するには、次を実行します。

   CREATE USER InstanceA_User FOR LOGIN InstanceA_Login;
   GO
   

10. プライマリになる可能性があるレプリカでは、関連するすべてのセカンダリ レプリカでログインとユーザーを作成します。

11. 各インスタンスで、作成されたログインとユーザーがある他のインスタンスに証明書を復元します。 プライマリ レプリカで、すべてのセカンダリ レプリカの証明書を復元します。 各セカンダリで、プライマリ レプリカの証明書を復元します。また、プライマリになる可能性があるその他のレプリカにも復元します。 次に例を示します。

    CREATE CERTIFICATE [InstanceB_Cert]
    AUTHORIZATION InstanceB_User
    FROM FILE = 'Restore_path\InstanceB_Cert.cer';
    

12. レプリカになる各インスタンスに、可用性グループによって使用されるエンドポイントを作成します。 可用性グループの場合は、エンドポイントの種類は DATABASE_MIRRORING である必要があります。 エンドポイントでは、手順 4 で認証のインスタンスのために作成した証明書を使用します。 次の例では、証明書を使用してエンドポイントを作成するための構文を示しています。 適切な暗号化方法と、環境に関連するその他のオプションを使用します。 使用できるオプションの詳細については、「CREATE ENDPOINT」を参照してください。

    CREATE ENDPOINT DIAG_EP STATE = STARTED AS TCP (
        LISTENER_PORT = 5022,
        LISTENER_IP = ALL
    )
    FOR DATABASE_MIRRORING (
        AUTHENTICATION = CERTIFICATE InstanceX_Cert, ROLE = ALL
    );
    

13. エンドポイントに接続できるように、ステップ 8 のインスタンスで作成された各ログインに権限を割り当てます。

    GRANT CONNECT ON ENDPOINT::DIAG_EP TO [InstanceX_Login];
    GO
    

14. 基になる証明書とエンドポイントのセキュリティが構成されたら、指定した方法を使用して、可用性グループを作成します。 セカンダリの初期化に使用するバックアップを手動でバックアップ、コピー、および復元するか、自動シード処理を使用することをお勧めします。 ウィザードを使ってセカンダリ レプリカを初期化するには、サーバー メッセージ ブロック (SMB) ファイルを使用する必要がありますが、このファイルは、ドメインに参加していないワークグループ クラスターを使用する場合は動作しない可能性があります。

15. リスナーを作成する場合は、その名前と IP アドレスの両方が DNS に登録されていることを確認します。

関連するコンテンツ

• 可用性グループ ウィザードの使用 (SQL Server Management Studio)
• [新しい可用性グループ] ダイアログ ボックスの使用 (SQL Server Management Studio)
• Transact-SQL (T-SQL) を使用した Always On 可用性グループの作成