可用性グループ リスナーとは

  • [アーティクル]

適用対象:SQL Server

可用性グループ リスナーは、Always On 可用性グループのプライマリ レプリカまたはセカンダリ レプリカ内のデータベースにアクセスするために、クライアントが接続できる仮想ネットワーク名 (VNN) です。 リスナーを使用すると、クライアントは、SQL Server の物理インスタンス名を知らなくても、レプリカに接続できます。 リスナーはトラフィックをルーティングするため、フェールオーバーの発生後にクライアント接続文字列を変更する必要はありません。

可用性グループ リスナーには、ドメイン ネーム システム (DNS) のリスナー名、リスナー ポート指定、および 1 つ以上の IP アドレスが含まれます。 可用性グループ リスナーでは、TCP プロトコルのみがサポートされています。 リスナーの DNS 名が、ドメインおよび NetBIOS 内で一意である必要があります。 リスナーを作成すると、それは関連付けられた仮想ネットワーク名 (VNN)、仮想 IP (VIP)、可用性グループの依存関係と共に、クラスター内のリソースになります。 クライアントは、DNS を使用して VNN を複数の IP アドレスに解決した後、接続要求が成功するかタイムアウトするまで、それぞれのアドレスに接続を試みます。

1 つ以上の読み取り可能なセカンダリ レプリカに対して読み取り専用のルーティングが構成されている場合、リスナーに対する読み取りを目的としたクライアント接続は読み取り可能なセカンダリ レプリカに自動的にリダイレクトされます。

この記事では、可用性グループ リスナーの概要を示します。 リスナーを構成し、リスナーに接続する方法を学習することもできます。

リスナーのパラメーター

可用性グループ リスナーでは、以下のものが使用されます。

一意の DNS 名
これは仮想ネットワーク名 (VNN) とも呼ばれています。 DNS ホスト名に対する Active Directory の名前付け規則が適用されます。 詳細については、サポート技術情報の「 Active Directory でのコンピューター、ドメイン、サイト、および OU の名前付け規則 」を参照してください。

1 つ以上の仮想 IP アドレス (VIP)
VIP は、可用性グループがフェールオーバーする 1 つ以上のサブネットに対して構成されます。

IP アドレスの構成
特定の可用性グループ リスナーの IP アドレスには、動的ホスト構成プロトコル (DHCP) または 1 つまたは複数の静的 IP アドレスを使用できます。 DHCP を使用すると、フェールオーバー中に接続の遅延が発生する可能性があるため、運用環境での使用はお勧めできません。 複数のサブネットにまたがって拡張される可用性グループ、またはハイブリッド ネットワーク構成を使用する可用性グループは、静的 IP アドレスを使用する必要があります。

リスナー ポート

可用性グループ リスナーを構成する場合は、SSMS でポートを指定する必要があります。 既定のポートを 1433 に構成すると、クライアント接続文字列をシンプルにできます。 つまり、1433 を使用する場合は、アプリケーションの接続文字列にポート番号を含める必要がありません。 また、各可用性グループ リスナーに個別の仮想ネットワーク名があるため、1 つの WSFC で構成された各可用性グループ リスナーが同じ既定のポート 1433 を参照するように構成できます。

可用性グループ リスナー VNN で既定のポート 1433 を使用する場合、クラスター ノード上の他のサービスがそのポートを使用していないことを確認する必要があります。確認しない場合、ポートの競合が発生する可能性があります。

SQL Server のインスタンスの 1 つが、インスタンス リスナーを通じて TCP ポート 1433 を既にリッスンしていて、コンピューター上の他のサービス (SQL Server の別のインスタンスを含む) がポート 1433 をリッスンしていない場合は、可用性グループ リスナーでポートの競合は発生しません。 これは、可用性グループ リスナーが同じプロセス内で同じ TCP ポートを共有できるためです。 しかし、同じポートをリッスンするように、SQL Server の複数のインスタンス (サイド バイ サイド) を構成しないでください。そのうちの 1 つが接続のリッスンに失敗するためです。

標準ではない可用性グループ リスナーのポートを指定することもできます。 しかし、その場合、リスナーに接続する際に、アプリケーション接続文字列でターゲット ポートを明示的に使用する必要もあります。 また、このポートに対して、ファイアウォールのアクセス許可を有効にする必要もあります。

名前とポート (1433 ではない場合) を使用してリスナーに接続できます。 このポートは、リスナー ポートか、リッスンするように構成されている基本となる SQL Server ポートのいずれかにすることができます。

次の例では、リスナーの機能の一部を示します。

設定:

  • SQL Server がリッスンしている IP: 192.168.20.2
  • SQL Server がリッスンしているポート: 50254
  • 構成済みのリスナー IP: 192.168.20.15
  • 構成済みのリスナー名: aglistener19
  • 構成済みのリスナー ポート: 50123

  1. IP アドレスとポートを使用してリスナーに接続します。 この接続は成功します。

    sqlcmd -S 192.168.20.15,50123 
1>

  2. ポートを使用せず、名前のみでリスナーに接続ます。 既定以外のポートが使用されたため、この接続は失敗します。 このポートを指定する必要があります。

    sqlcmd -S aglistener19

  3. リスナー名と構成済みのポートでリスナーに接続します。 この接続は成功します。

    sqlcmd -S aglistener19,50123 
1>

  4. 最後に、リスナーと SQL Server ポートに接続します。 この場合、リスナー ポートではなく、SQL Server がリッスンしているポートを使用していることに注意してください。 この接続も成功します。

    sqlcmd -S aglistener19,50254
1>

フェールオーバー時のクライアント接続動作

可用性グループのフェールオーバーが発生すると、可用性グループへの既存の永続的な接続は終了します。このため、クライアントが、同じプライマリ データベースまたは読み取り専用セカンダリ データベースとの連携を保つには、新しい接続を確立する必要があります。 フェールオーバーがサーバー側で発生している間は、可用性グループへの接続が失敗することがあります。この場合、プライマリが完全にオンラインになるまで、クライアント アプリケーションは接続を再試行します。

クライアント アプリケーションの接続の試行中、接続のタイムアウト期間が経過する前に可用性グループがオンラインに戻ると、クライアント ドライバーによる内部での再試行のいずれかが正常に接続できる場合があります。このとき、アプリケーションでエラーは発生しません。

次の手順

これで、可用性グループ リスナーがどのように機能するか、リスナーの作成方法、リスナーに接続するようにアプリケーションを構成する方法について理解しました。 また、可用性グループの正常性を確保するために、さまざまな可用性グループの監視戦略を確認することもできます。

可用性グループの詳細については、「Always On 可用性グループとは (SQL Server)」を参照してください。