リスナー、クライアント接続、アプリケーションのフェールオーバーListeners, Client Connectivity, Application Failover

適用対象: ○SQL Server XAzure SQL Database XAzure SQL Data Warehouse XParallel Data WarehouseAPPLIES TO: yesSQL Server noAzure SQL Database noAzure SQL Data Warehouse noParallel Data Warehouse

このトピックでは、 Always On 可用性グループAlways On availability groups クライアント接続とアプリケーションのフェールオーバー機能に関する考慮事項について説明します。This topic contains information about considerations for Always On 可用性グループAlways On availability groups client connectivity and application-failover functionality.

注意

通常のリスナー構成では、 Transact-SQLTransact-SQL ステートメントまたは PowerShell コマンドレットを使用して最初の可用性グループ リスナーを簡単に作成できます。For the majority of the common listener configurations, you can create the first availability group listener simply by using Transact-SQLTransact-SQL statements or PowerShell cmdlets. 詳細については、このトピックの「 関連タスク」を参照してください。For more information, see Related Tasks, later in this topic.

このトピックの内容In This Topic:

可用性グループ リスナーAvailability Group Listeners

可用性グループ リスナーを作成することによって、特定の可用性グループのデータベースへのクライアント接続が可能になります。You can provide client connectivity to the database of a given availability group by creating an availability group listener. 可用性グループ リスナーは、Always On 可用性グループのプライマリ レプリカまたはセカンダリ レプリカ内のデータベースにアクセスするためにクライアントが接続できる仮想ネットワーク名 (VNN) です。An availability group listener is a virtual network name (VNN) to which clients can connect in order to access a database in a primary or secondary replica of an Always On availability group. 可用性グループ リスナーによって、クライアントは、接続先の SQL Server の物理インスタンス名が不明な場合でも、可用性レプリカに接続できます。An availability group listener enables a client to connect to an availability replica without knowing the name of the physical instance of SQL Server to which the client is connecting. 現在のプライマリ レプリカの現在の場所に接続するために、クライアント接続文字列を変更する必要はありません。The client connection string does not need to be modified to connect to the current location of the current primary replica.

可用性グループ リスナーには、ドメイン ネーム システム (DNS) のリスナー名、リスナー ポート指定、および 1 つ以上の IP アドレスが含まれます。An availability group listener consists of a Domain Name System (DNS) listener name, listener port designation, and one or more IP addresses. 可用性グループ リスナーでは、TCP プロトコルのみがサポートされています。Only the TCP protocol is supported by availability group listener. リスナーの DNS 名も、ドメインおよび NetBIOS 内で固有であることが必要です。The DNS name of the listener must also be unique in the domain and in NetBIOS. 作成された新しい可用性グループ リスナーは、関連付けられた仮装ネットワーク名 (VNN)、仮想 IP (VIP)、可用性グループの依存関係と共に、クラスター内のリソースになります。When you create a new availability group listener it becomes a resource in a cluster with an associated virtual network name (VNN), virtual IP (VIP), and availability group dependency. クライアントは、DNS を使用して VNN を複数の IP アドレスに解決した後、接続要求が成功するかタイムアウトするまで、それぞれのアドレスに接続を試みます。A client uses DNS to resolve the VNN into multiple IP addresses and then tries to connect to each address, until a connection request succeeds or until the connection requests time out.

1 つ以上の読み取り可能なセカンダリ レプリカに対して読み取り専用のルーティングが構成されている場合、プライマリ レプリカに対する読み取りを目的としたクライアント接続は読み取り可能なセカンダリ レプリカにリダイレクトされます。If read-only routing is configured for one or more readable secondary replicas, read-intent client connections to the primary replica are redirected to a readable secondary replica. さらに、SQL Server の 1 つのインスタンスでプライマリ レプリカがオフラインになり、SQL Server の他のインスタンスで新しいプライマリ レプリカがオンラインになると、可用性グループ リスナーによって、クライアントは新しいプライマリ レプリカに接続できます。Also, if the primary replica goes offline on one instance of SQL Server, and a new primary replica comes online on another instance of SQL Server, the availability group listener enables clients to connect to the new primary replica.

可用性グループ リスナーに関する必須情報については、「 可用性グループ リスナーの作成または構成 (SQL Server)」を参照してください。For essential information about availability group listeners, see Create or Configure an Availability Group Listener (SQL Server).

このセクションの内容In This Section:

可用性グループ リスナーの構成Availability Group Listener Configuration

可用性グループ リスナーは、以下のものによって定義されます。An availability group listener is defined by the following:

一意の DNS 名A unique DNS name
これは仮想ネットワーク名 (VNN) とも呼ばれています。This is also known as a Virtual Network Name (VNN). DNS ホスト名に対する Active Directory の名前付け規則が適用されます。Active Directory naming rules for DNS host names apply. 詳細については、サポート技術情報の「 Active Directory でのコンピューター、ドメイン、サイト、および OU の名前付け規則 」を参照してください。For more information, see the Naming conventions in Active Directory for computers, domains, sites, and OUs KB article.

1 つ以上の仮想 IP アドレス (VIP)One or more Virtual IP addresses (VIPs)
VIP は、可用性グループがフェールオーバーする 1 つ以上のサブネットに対して構成されます。VIPs are configured for one or more subnets to which the availability group can failover.

IP アドレスの構成IP address configuration
特定の可用性グループ リスナーの IP アドレスには、動的ホスト構成プロトコル (DHCP) または 1 つ以上の静的 IP アドレスを使用します。For a given availability group listener, the IP address uses either Dynamic Host Configuration Protocol (DHCP) or one or more static IP addresses.

  • 動的ホスト構成プロトコル (DHCP)Dynamic Host Configuration Protocol (DHCP)

    可用性グループが 1 つのサブネット上にある場合、DHCP を使用するようにすべての可用性グループ リスナーの IP アドレスを構成できます。If an availability group resides on a single subnet, you can configure all the availability group listener IP addresses to use DHCP. 実稼動前の環境では、DHCP を使用すると、別のサブネット上のリモート サイトに対するディザスター リカバリーを必要としない可用性グループを簡単にセットアップできます。For pre-production environments, DHCP offers an easy setup for an availability group that does not require disaster recovery to a remote site on a separate subnet. ただし、実稼働環境では DHCP と可用性グループ リスナーを組み合わせて使用しないでください。However, you should not use DHCP in conjunction with an availability group listener in a production environment. これは、ダウンタイムが発生した場合に DHCP の IP リース期限が切れると、リスナーの DNS 名に関連付けられている新しい DHCP IP アドレスの再登録に余分な時間がかかるためです。This is because, in the event of down time, if the DHCP IP lease expires, extra time is required to re-register the new DHCP IP address associated with the listener DNS name. 余分な時間がかかると、クライアント接続に失敗します。The extra time will cause client-connection failure.

  • 静的 IP アドレスStatic IP addresses

    実稼働環境では、可用性グループ リスナーで静的 IP アドレスを使用することをお勧めします。In production environments, we recommend that availability group listeners use static IP addresses. また、可用性グループがマルチサブネット ドメインのサブネットにまたがっている場合、可用性グループ リスナーで静的 IP アドレスを使用する必要があります。Furthermore, where availability groups extend across subnets in a multi-subnet domain, an availability group listener must use static IP addresses.

    ハイブリッド ネットワーク構成とサブネットにまたがる DHCP は、可用性グループ リスナーではサポートされていません。Hybrid network configurations and DHCP across subnets are not supported for availability group listeners. これは、フェールオーバーが発生すると動的 IP アドレスの期限が切れたり、解放されたりする場合があり、全体的な可用性が低下するおそれがあるためです。This is because when a failover happens, a dynamic IP might expire or be released, which jeopardizes overall high availability.

可用性グループ リスナー ポートの選択Selecting an Availability Group Listener Port

可用性グループ リスナーを構成する場合は、ポートを指定する必要があります。When configuring an availability group listener, you must designate a port. 既定のポートを 1433 に構成すると、クライアント接続文字列をシンプルにできます。You can configure the default port to 1433 in order to allow for simplicity of the client connection strings. 1433 を使用する場合は、接続文字列でポート番号を指定する必要がありません。If using 1433, you do not need to designate a port number in a connection string. また、各可用性グループ リスナーに個別の仮想ネットワーク名があるため、1 つの WSFC で構成された各可用性グループ リスナーが同じ既定のポート 1433 を参照するように構成できます。Also, since each availability group listener will have a separate virtual network name, each availability group listener configured on a single WSFC can be configured to reference the same default port of 1433.

標準ではないリスナー ポートを指定することもできます。ただし、その場合、可用性グループ リスナーに接続するたびに、接続文字列で接続先ポートを明示的に指定する必要があります。You can also designate a non-standard listener port; however this means that you will also need to explicitly specify a target port in your connection string whenever connecting to the availability group listener. また、標準以外のポートに対して、ファイアウォールのアクセス許可を有効にする必要があります。You will also need to open permission on the firewall for the non-standard port.

可用性グループ リスナー VNN で既定のポート 1433 を使用する場合、クラスター ノード上の他のサービスがそのポートを使用していないことを確認する必要があります。確認しない場合、ポートの競合が発生する可能性があります。If you use the default port of 1433 for availability group listener VNNs, you will still need to ensure that no other services on the cluster node are using this port; otherwise this would cause a port conflict.

SQL Server のインスタンスの 1 つが、インスタンス リスナーを通じて TCP ポート 1433 を既にリッスンしていて、コンピューター上の他のサービス (SQL Server の別のインスタンスを含む) がポート 1433 をリッスンしていない場合は、可用性グループ リスナーでポートの競合は発生しません。If one of the instances of SQL Server is already listening on TCP port 1433 via the instance listener and there are no other services (including additional instances of SQL Server) on the computer listening on port 1433, this will not cause a port conflict with the availability group listener. これは、可用性グループ リスナーが同じサービス プロセス内で同じ TCP ポートを共有できるためです。This is because the availability group listener can share the same TCP port inside the same service process. ただし、同じポートをリッスンするように、SQL Server の複数のインスタンス (サイド バイ サイド) を構成しないでください。However multiple instances of SQL Server (side-by-side)should not be configured to listen on the same port.

リスナーを使用したプライマリ レプリカへの接続Using a Listener to Connect to the Primary Replica

可用性グループ リスナーを使用して読み取り/書き込みアクセスでプライマリ レプリカに接続するには、可用性グループ リスナーの DNS 名を接続文字列で指定します。To use an availability group listener to connect to the primary replica for read-write access, the connection string specifies the availability group listener DNS name. 可用性グループ プライマリ レプリカが新しいレプリカに変更された場合、可用性グループ リスナーのネットワーク名を使用している既存の接続は解除されます。If an availability group primary replica changes to a new replica, existing connections that use an availability group listener's network name are disconnected. その後、可用性グループ リスナーへの新しい接続によって、新しいプライマリ レプリカにダイレクトされます。New connections to the availability group listener are then directed to the new primary replica. ADO.NET プロバイダー (System.Data.SqlClient) の基本的な接続文字列の例を次に示します。An example of a basic connection string for the ADO.NET provider (System.Data.SqlClient) is as follows:

Server=tcp: AGListener,1433;Database=MyDB;IntegratedSecurity=SSPI  

可用性グループ リスナーのサーバー名を使用する代わりに、プライマリ レプリカまたはセカンダリ レプリカの SQL Server 名のインスタンスを直接参照することもできます。ただし、その場合、新しい接続が現在のプライマリ レプリカに自動的にダイレクトされるという利点がなくなります。You can still choose to directly reference the instance of SQL Server name of the primary or secondary replicas instead of using the availability group listener server name, however if you choose to do so you will lose the benefit of new connections being directed automatically to the current primary replica. また、読み取り専用ルーティングの利点もなくなります。You will also lose the benefit of read-only routing.

リスナーを使用した読み取り専用セカンダリ レプリカ (読み取り専用ルーティング) への接続Using a Listener to Connect to a Read-Only Secondary Replica (Read-Only Routing)

読み取り専用ルーティング SQL ServerSQL Serverは、可用性グループ リスナーへの着信接続を、読み取り専用ワークロードを許可するように構成されたセカンダリ レプリカへルーティングする、 の機能です。Read-only routing refers to the ability of SQL ServerSQL Server to route incoming connections to an availability group listener to a secondary replica that is configured to allow read-only workloads. 次の条件が満たされる場合、可用性グループ リスナー名を参照する着信接続を、読み取り専用レプリカに自動的にルーティングできます。An incoming connection referencing an availability group listener name can automatically be routed to a read-only replica if the following are true:

  • 少なくとも 1 つのセカンダリ レプリカが読み取り専用アクセスに設定され、各読み取り専用セカンダリ レプリカとプライマリ レプリカが読み取り専用ルーティングをサポートするように構成されている。At least one secondary replica is set to read-only access, and each read-only secondary replica and the primary replica are configured to support read-only routing. 詳細については、このセクションの後の「 読み取り専用ルーティングの可用性レプリカを構成するには」を参照してください。For more information, see To Configure Availability Replicas for Read-Only Routing, later in this section.

  • 接続文字列は、可用性グループに含まれるデータベースを参照します。The connection string references a database involved in the Availability Group. これに代わる方法は、接続に使うログインで、データベースを既定のデータベースとして構成することです。An alternative to this would be the login used in the connection has the database configured as its default database. 詳しくは、読み取り専用ルーティングでのアルゴリズムの動作に関するこちらの記事をご覧ください。For more information, see this article on how the algorithm works with read-only routing.

  • 接続文字列は可用性グループ リスナーを参照し、着信接続のアプリケーションの目的が読み取り専用に設定されている (たとえば、ODBC または OLEDB の接続文字列、接続属性、またはプロパティで Application Intent=ReadOnly キーワードを使用している)。The connection string references an availability group listener, and the application intent of the incoming connection is set to read-only (for example, by using the Application Intent=ReadOnly keyword in the ODBC or OLEDB connection strings or connection attributes or properties). 詳細については、このセクションの後の「 読み取り専用アプリケーションの目的および読み取り専用ルーティング」を参照してください。For more information, see Read-Only Application Intent and Read-Only Routing, later in this section.

読み取り専用ルーティングの可用性レプリカを構成するにはTo Configure Availability Replicas for Read-Only Routing

データベース管理者は、可用性レプリカを次のように構成する必要があります。A database administrator must configure the availability replicas as follows:

  1. 読み取り可能なセカンダリ レプリカとして構成する可用性レプリカごとに、データベース管理者はセカンダリ ロールにのみ影響する次の設定を構成する必要があります。For each availability replica that you want to configure as a readable secondary replica, a database administrator must configure the following settings, which take effect only under the secondary role:

    • 接続アクセスを「すべて」または「読み取り専用」に設定する必要があります。Connection access must be set to "all" or "read only".

    • 読み取り専用ルーティングの URL を指定する必要があります。The read-only routing URL must be specified.

  2. これらのレプリカごとに、プライマリ ロールに対して読み取り専用ルーティング リストを指定する必要があります。For each of these replicas, a read-only routing list must be specified for the primary role. 1 つ以上のサーバー名をルーティング ターゲットとして指定します。Specify one or more server names as routing targets.

関連タスクRelated Tasks

読み取り専用アプリケーションの目的および読み取り専用ルーティングRead-Only Application Intent and Read-Only Routing

アプリケーションの目的の接続文字列プロパティは、読み取り/書き込み用または読み取り専用のどちらかの可用性グループ データベースにダイレクトされる、クライアント アプリケーションの要求を表します。The application intent connection string property expresses the client application's request to be directed either to a read-write or read-only version of an availability group database. 読み取り専用ルーティングを使用するには、可用性グループ リスナーに接続するときに、クライアントが接続文字列内で読み取り専用のアプリケーションの目的を使用する必要があります。To use read-only routing, a client must use an application intent of read-only in the connection string when connecting to the availability group listener. 読み取り専用のアプリケーションの目的がないと、可用性グループ リスナーへの接続は、プライマリ レプリカ上のデータベースに送られます。Without the read-only application intent, connections to the availability group listener are directed to the database on the primary replica.

アプリケーションの目的の属性は、ログイン中にクライアントのセッションに格納されます。その後、SQL Server のインスタンスがこの目的を処理し、可用性グループの構成およびセカンダリ レプリカ内のターゲット データベースの現在の読み取り/書き込み状態に基づいて、実行する操作を決定します。The application intent attribute is stored in the client's session during login and the instance of SQL Server will then process this intent and determine what to do according to the configuration of the availability group and the current read-write state of the target database in the secondary replica.

読み取り専用のアプリケーションの目的を指定する ADO.NET プロバイダー (System.Data.SqlClient) の接続文字列の例を次に示します。An example of a connection string for the ADO.NET provider (System.Data.SqlClient) that designates read-only application intent is as follows:

Server=tcp:AGListener,1433;Database=AdventureWorks;IntegratedSecurity=SSPI;ApplicationIntent=ReadOnly  

この接続文字列の例では、クライアントはポート 1433 で AGListener という名前の可用性グループ リスナーを介して AdventureWorks データベースへの接続を試みます (可用性グループ リスナーが 1433 でリッスンしている場合、このポートの指定を省略できます)。In this connection string example, the client is attempting to connect to the AdventureWorks database via an availability group listener named AGListener on port 1433 (you may also omit the port if the availability group listener is listening on 1433). この接続文字列は、 ApplicationIntent プロパティが ReadOnlyに設定されているため、 読み取りを目的とした接続文字列となります。The connection string has the ApplicationIntent property set to ReadOnly, making this a read-intent connection string. この設定がない場合、サーバーは接続の読み取り専用へのルーティングを試行しません。Without this setting, the server would not have attempted a read-only routing of the connection.

可用性グループのプライマリ データベースは、読み取り専用の受信ルーティング要求を処理し、プライマリ レプリカに参加していて読み取り専用ルーティング用に構成されているオンラインの読み取り専用レプリカを特定します。The primary database of the availability group processes the incoming read-only routing request and attempts to locate an online, read-only replica that is joined to the primary replica and is configured for read-only routing. クライアントは、プライマリ レプリカ サーバーから接続情報を受け取り、特定された読み取り専用レプリカに接続します。The client receives back connection information from the primary replica server and connects to the identified read-only replica.

アプリケーションの目的は、クライアント ドライバーから下位の SQLServer インスタンスに送信できます。Note that the application intent can be sent from a client driver to a down-level instance of SQL Server. この場合、読み取り専用のアプリケーションの目的は無視され、接続は通常どおり続行されます。In this case, application intent of read-only is ignored and the connection proceeds as normal.

読み取り専用ルーティングをバイパスする場合、または、可用性グループ リスナー名を使用せずに SQL Server のプライマリ レプリカ インスタンスに直接接続する場合は、"アプリケーションの目的" 接続プロパティを ReadOnly に設定しません (指定しない場合、既定では、ログイン中は ReadWrite )。You can bypass read-only routing by not setting the application intent connection property to ReadOnly (when not designated, the default is ReadWrite during login) or by connecting directly to the primary replica instance of SQL Server instead of using the availability group listener name. 読み取り専用レプリカに直接接続する場合は、読み取り専用ルーティングも実行されません。Read-only routing will also not occur if you connect directly to a read-only replica.

関連タスクRelated Tasks

可用性グループ リスナーのバイパスBypassing Availability Group Listeners

可用性グループ リスナーでフェールオーバー リダイレクトと読み取り専用ルーティングが有効にされている場合、クライアント接続でこれらを使用する必要はありません。While availability group listeners enable support for failover redirection and read-only routing, client connections are not required to use them. また、クライアント接続は、可用性グループ リスナーに接続する代わりに、SQLServer のインスタンスを直接参照できます。A client connection can also directly reference the instance of SQL Server instead of connecting to the availability group listener.

SQL Server のインスタンスにとって、接続のログインで、可用性グループ リスナーまたは他のインスタンス エンドポイントのどちらを使用するかは関係ありません。To the instance of SQL Server it is irrelevant whether a connection logs in using the availability group listener or using another instance endpoint. SQL Server のインスタンスは、接続先データベースの状態を確認し、可用性グループの構成およびインスタンス上のデータベースの現在の状態に基づいて、接続を許可または禁止します。The instance of SQL Server will verify the state of the targeted database and either allow or disallow connectivity based on the configuration of the availability group and the current state of the database on the instance. たとえば、クライアント アプリケーションが SQL Server ポートのインスタンスに直接接続し、可用性グループでホストされているターゲット データベースに接続する場合、ターゲット データベースがプライマリ状態でオンラインであれば接続は成功します。For example, if a client application connects directly to a instance of SQL Server port and connects to a target database hosted in an availability group, and the target database is in primary state and online, then connectivity will succeed. ターゲット データベースがオフラインまたは移行状態の場合は、データベースへの接続が失敗します。If the target database is offline or in a transitional state, connectivity to the database will fail.

データベース ミラーリングを Always On 可用性グループAlways On availability groupsに移行している間、セカンダリ レプリカが 1 つしか存在せず、これにユーザーが接続できない場合は、アプリケーションでデータベース ミラーリング接続文字列を指定できます。Alternatively, while migrating from database mirroring to Always On 可用性グループAlways On availability groups, applications can specify the database mirroring connection string as long as only one secondary replica exists and it disallows user connections. 詳細については、このセクションの後の「 データベース ミラーリング接続文字列と可用性グループの使用」を参照してください。For more information, see Using Database-Mirroring Connection Strings with Availability Groups, later in this section.

データベース ミラーリング接続文字列と可用性グループの使用Using Database-Mirroring Connection Strings with Availability Groups

可用性グループに 1 つしかセカンダリ レプリカが存在せず、さらに、その可用性グループが、セカンダリ レプリカに ALLOW_CONNECTIONS = READ_ONLY または ALLOW_CONNECTIONS = NONE が構成されている場合、クライアントは、データベース ミラーリングの接続文字列を使用してプライマリ レプリカに接続できます。If an availability group possesses only one secondary replica and is configured with either ALLOW_CONNECTIONS = READ_ONLY or ALLOW_CONNECTIONS = NONE for the secondary replica, clients can connect to the primary replica by using a database mirroring connection string. 可用性グループに存在する可用性レプリカが 2 つだけ (プライマリ レプリカおよび 1 つのセカンダリ レプリカ) であれば、既存のアプリケーションをデータベース ミラーリングから可用性グループに移行する際にこの方法を用いることができます。This approach can be useful while migrating an existing application from database mirroring to an availability group, as long as you limit the availability group to two availability replicas (a primary replica and one secondary replica). セカンダリ レプリカをさらに追加する場合は、可用性グループの可用性グループ リスナーを作成し、その可用性グループ リスナー DNS 名を使用するようにアプリケーションを更新する必要があります。If you add additional secondary replicas, you will need to create an availability group listener for the availability group and update your applications to use the availability group listener DNS name.

データベース ミラーリングの接続文字列を使用する際、クライアントは、 SQL ServerSQL Server Native Client または .NET Framework Data Provider for SQL ServerSQL Serverを使用できます。When using database mirroring connection strings, the client can use either SQL ServerSQL Server Native Client or .NET Framework Data Provider for SQL ServerSQL Server. クライアントが指定する接続文字列には、最低限、1 つのサーバー インスタンスの名前 ( イニシャル パートナー名) が指定されている必要があります。接続先の可用性レプリカを初期状態でホストするサーバー インスタンスは、この名前によって識別されます。The connection string provided by a client must minimally supply the name of one server instance, the initial partner name, to identify the server instance that initially hosts the availability replica to which you intend to connect. 接続文字列には、必要に応じて、別のサーバー インスタンスの名前を指定することもできます。これを フェールオーバー パートナー名といい、初期状態でセカンダリ レプリカをホストするサーバー インスタンスは、フェールオーバー パートナー名として識別されます。Optionally, the connection string can also supply the name of another server instance, the failover partner name, to identify the server instance that initially hosts the secondary replica as the failover partner name.

データベース ミラーリングの接続文字列の詳細については、「 データベース ミラーリング セッションへのクライアントの接続 (SQL Server)」を参照してください。For more information about database mirroring connection strings, see Connect Clients to a Database Mirroring Session (SQL Server).

フェールオーバー時のクライアント接続動作Behavior of Client Connections on Failover

可用性グループのフェールオーバーが発生すると、可用性グループへの既存の永続的な接続は終了します。このため、クライアントが、同じプライマリ データベースまたは読み取り専用セカンダリ データベースとの連携を保つには、新しい接続を確立する必要があります。When an availability group failover occurs, existing persistent connections to the availability group are terminated and the client must establish a new connection in order to continue working with the same primary database or read-only secondary database. フェールオーバーがサーバー側で発生している間は、可用性グループへの接続が失敗することがあります。この場合、プライマリが完全にオンラインになるまで、クライアント アプリケーションは接続を再試行します。While a failover is occurring on the server side, connectivity to the availability group may fail, forcing the client application to retry connecting until the primary is brought fully back online.

クライアント アプリケーションの接続の試行中、接続のタイムアウト期間が経過する前に可用性グループがオンラインに戻ると、クライアント ドライバーによる内部での再試行のいずれかが正常に接続できる場合があります。このとき、アプリケーションでエラーは発生しません。If the availability group comes back online during a client application's connection attempt but before the connect timeout period, the client driver may successfully connect during one of its internal retry attempts and no error will be surfaced to the application in this case.

可用性グループ マルチサブネット フェールオーバーのサポートSupporting Availability Group Multi-Subnet Failovers

接続文字列で MultiSubnetFailover 接続オプションをサポートするクライアント ライブラリを使用している場合、MultiSubnetFailover を "True" または "Yes" に設定して (使用しているプロバイダーの構文によって異なります)、別のサブネットへの可用性グループのフェールオーバーを最適化できます。If you are using client libraries that support the MultiSubnetFailover connection option in the connection string, you can optimize availability group failover to a different subnet by setting MultiSubnetFailover to "True" or "Yes", depending on the syntax of the provider you are using.

注意

可用性グループ リスナーおよび SQL Server フェールオーバー クラスター インスタンス名への単一サブネット接続およびマルチサブネット接続の両方に対して、この設定を推奨します。We recommend this setting for both single and multi-subnet connections to availability groups listeners and to SQL Server Failover Cluster Instance names. このオプションを有効にすると、単一サブネットのシナリオでも、さらに最適化されます。Enabling this option adds additional optimizations, even for single-subnet scenarios.

MultiSubnetFailover 接続オプションは TCP ネットワーク プロトコルのみで機能します。また、可用性グループ リスナーに接続する場合、および SQL Server 2017SQL Server 2017に接続している仮想ネットワーク名を使用する場合にのみサポートされます。The MultiSubnetFailover connection option only works with the TCP network protocol and is only supported when connecting to an availability group listener and for any virtual network name connecting to SQL Server 2017SQL Server 2017.

マルチサブネット フェールオーバーを有効にする ADO.NET プロバイダー (System.Data.SqlClient) の接続文字列の例を次に示します。An example of the ADO.NET provider (System.Data.SqlClient) connection string that enables multi-subnet failover is as follows:

Server=tcp:AGListener,1433;Database=AdventureWorks;IntegratedSecurity=SSPI; MultiSubnetFailover=True  

MultiSubnetFailover 接続オプションは、可用性グループが単一のサブネットのみにある場合でも、 True に設定することをお勧めします。The MultiSubnetFailover connection option should be set to True even if the availability group only spans a single subnet. これにより、今後、クライアント接続文字列を変更することなく、複数のサブネットをサポートするように新しいクライアントをあらかじめ構成することができ、単一サブネットのフェールオーバーのパフォーマンスも最適化できます。This allows you to preconfigure new clients to support future spanning of subnets without any need for future client connection string changes and also optimizes failover performance for single subnet failovers. MultiSubnetFailover 接続オプションは必須ではありませんが、サブネットのフェールオーバーが速くなるという利点があります。While the MultiSubnetFailover connection option is not required, it does provide the benefit of a faster subnet failover. これは、クライアント ドライバーが、可用性グループに関連付けられている各 IP アドレスの TCP ソケットを同時に開こうとするためです。This is because the client driver will attempt to open up a TCP socket for each IP address in parallel associated with the availability group. クライアント ドライバーは、最初の IP が正常に応答するのを待ち、応答した場合は、その IP を接続に使用します。The client driver will wait for the first IP to respond with success and once it does, will then use it for the connection.

可用性グループ リスナーと SSL 証明書Availability Group Listeners and SSL Certificates

可用性グループ リスナーへの接続時に、参加している SQL Server のインスタンスがセッションの暗号化と共に SSL 証明書を使用していることがあります。この場合、強制的に暗号化するために、接続クライアント ドライバーが SSL 証明書のサブジェクト代替名をサポートする必要があります。When connecting to an availability group listener, if the participating instances of SQL Server use SSL certificates in conjunction with session encryption, the connecting client driver will need to support the Subject Alternate Name in the SSL certificate in order to force encryption. SQL Server ドライバーでの証明書のサブジェクト代替名のサポートは、ADO.NET (SqlClient)、Microsoft JDBC、および SQL Native Client (SNAC) に対して計画されています。SQL Server driver support for certificate Subject Alternative Name is planned for ADO.NET (SqlClient), Microsoft JDBC and SQL Native Client (SNAC).

X.509 証明書は、すべての可用性グループ リスナー セットのリストを証明書のサブジェクト代替名に設定して、フェールオーバー クラスターに参加している各サーバー ノードに対して構成する必要があります。A X.509 certificate must be configured for each participating server node in the failover cluster with a list of all availability group listeners set in the Subject Alternate Name of the certificate.

たとえば、WSFC に AG1_listener.Adventure-Works.comAG2_listener.Adventure-Works.comAG3_listener.Adventure-Works.comという 3 つの可用性グループ リスナーがある場合、証明書のサブジェクト代替名を次のように設定する必要があります。For example, if the WSFC has three availability group listeners with the names AG1_listener.Adventure-Works.com, AG2_listener.Adventure-Works.com, and AG3_listener.Adventure-Works.com, the Subject Alternative Name for the certificate should be set as follows:

CN = ServerFQDN  
SAN = ServerFQDN,AG1_listener.Adventure-Works.com, AG2_listener.Adventure-Works.com, AG3_listener.Adventure-Works.com  

可用性グループ リスナーとサーバー プリンシパル名 (SPN)Availability Group Listeners and Server Principal Names (SPNs)

可用性グループ リスナーへのクライアント接続で Kerberos を有効にするには、各可用性グループ リスナー名のドメイン管理者が、Active Directory 内にサーバー プリンシパル名 (SPN) を構成する必要があります。A Server Principal Name (SPN) must be configured in Active Directory by a domain administrator for each availability group listener name in order to enable Kerberos for the client connection to the availability group listener. SPN が登録されている場合、可用性レプリカをホストするサーバー インスタンスのサービス アカウントを使用する必要があります。When registering the SPN, you must use the service account of the server instance that hosts the availability replica . SPN がすべてのレプリカで機能するためには、可用性グループをホストする WSFC クラスター内のすべてのインスタンスで同じサービス アカウントを使用する必要があります。For the SPN to work across all replicas, the same service account must be used for all instances in the WSFC cluster that hosts the availability group.

SPN は、Windows コマンド ライン ツールの setspn を使用して構成します。Use the setspn Windows command line tool to configure the SPN. たとえば、 AG1listener.Adventure-Works.com というドメイン アカウントで実行されるように構成された、一連の SQL Server インスタンスでホストされている corp/svclogin2という名前の可用性グループの SPN を構成する場合は、次のようになります。For example to configure an SPN for an availability group named AG1listener.Adventure-Works.com hosted on a set of instances of SQL Server all configured to run under the domain account corp/svclogin2:

setspn -A MSSQLSvc/AG1listener.Adventure-Works.com:1433 corp/svclogin2  

SQL Server の SPN の手動登録の詳細については、「 Kerberos 接続用のサービス プリンシパル名の登録」を参照してください。For more information about manual registration of a SPN for SQL Server, see Register a Service Principal Name for Kerberos Connections.

関連タスクRelated Tasks

関連コンテンツRelated Content

参照See Also

AlwaysOn 可用性グループの概要 (SQL Server) Overview of Always On Availability Groups (SQL Server)
AlwaysOn クライアントの接続 (SQL Server) Always On Client Connectivity (SQL Server)
可用性レプリカに対するクライアント接続アクセスについて (SQL Server) About Client Connection Access to Availability Replicas (SQL Server)
アクティブなセカンダリ: 読み取り可能なセカンダリ レプリカ (Always On Availability Groups) Active Secondaries: Readable Secondary Replicas (Always On Availability Groups)
データベース ミラーリング セッションへのクライアントの接続 (SQL Server)Connect Clients to a Database Mirroring Session (SQL Server)