可用性グループが広く普及している今、このタイプの環境でのSQLServerの初期計画およびインストール中に見落とされる可能性のあるトピックについて説明したいと思いました。フォールトトレラントな構成を実現するには、データベース接続のセットアップにいくつかの検討と計画を立てる必要があります。
この投稿ではAlwaysOn環境の設定の詳細については説明しませんが、さらに役立つ情報が必要な場合は、AaronBertrandの投稿「AlwaysOnのトラブルシューティング–多くの目がかかる場合があります」を参照することをお勧めします。環境を構成したら、データベース接続を提供する次のステップは、SQLManagementStudioまたはT-SQLを使用して可用性グループリスナーを作成することです。
ALTER AVAILABILITY GROUP [GroupName] ADD LISTENER N'ListenerName' (WITH IP ((N'10.x.x.x', N'255.255.255.0')), PORT=1433);
AGリスナー接続文字列
仮想ネットワーク名（VNN）はDNSに登録されており、プライマリレプリカが存在するSQLServerインスタンスによって常に所有されています。 AGリスナーの構成中に提供されるすべてのIPアドレスは、同じ仮想ネットワーク名でDNSに登録されます。
AGリスナーを作成したら、クライアントが接続できることを確認する必要があります。アプリケーション接続は常に同じように動作しますが、接続文字列内の特定のサーバーを指す代わりに、AGリスナーを指します。
AGリスナーは、TCPを使用してのみ接続でき、ローカルDNSによって、VNNにマップされているIPアドレスとTCPポートのリストに解決されます。クライアントは、接続を取得するか、接続タイムアウトに達するまで、各IPアドレスへの接続を順番に試行します。使用を検討する重要な接続文字列パラメーターはMultiSubnetFailoverです。このパラメータがtrueに設定されている場合、クライアントは並列接続を試行し、接続を高速化し、必要に応じてクライアントのフェイルオーバーを高速化します。
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True
フェールオーバーが発生すると、クライアント接続がリセットされ、AGリスナーの所有権がプライマリレプリカの役割を引き継ぐSQLServerインスタンスに移動します。次に、VNNエンドポイントは、新しいプライマリレプリカインスタンスの新しいIPアドレスとTCPポートにバインドされます。クライアントによっては、AGへの自動再接続が発生するか、影響を受けるアプリケーションまたは接続を手動で再起動する必要がある場合があります。
アプリケーションの意図
可用性グループを実装する最大の理由の1つは、バックアップ環境または障害復旧環境を活用して、運用環境から作業をオフロードする機能を提供することです。これらのサーバーは、バックアップ、分析、アドホッククエリ、レポート、またはデータベースの読み取り専用コピーがあれば十分なその他の操作に使用できるようになりました。
セカンダリレプリカへの読み取り専用アクセスを提供するために、ApplicationIntent接続文字列パラメーターが使用されます。 SQL Serverエンドポイントのオプションの読み取り専用ルーティングリストは、各レプリカで構成できます。このリストは、ApplicationIntent =ReadOnlyパラメーターを使用するクライアント接続要求を、適切なアプリケーションインテントフィルターで構成された最初の使用可能なセカンダリレプリカにリダイレクトするために使用されます。
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True;ApplicationIntent=ReadOnly;
アプリケーションインテントフィルタリング
可用性グループに接続しているクライアントからのアプリケーションインテントを容易にするには、グループ内の各SQLServerインスタンスを適切なアプリケーションインテントフィルターで構成する必要があります。フィルタは、各レプリカが受け入れる接続のタイプを決定します。
「すべての接続を許可する」というプライマリロールの接続を持つように構成されたプライマリレプリカは、AGリスナーを介して行われたすべての接続を受け入れます。 「読み取り/書き込み接続を許可する」として構成されたプライマリレプリカは、「ApplicationIntent=ReadOnly」を指定する接続を拒否します。
レプリカを構成するときは、それぞれが読み取り可能なセカンダリになるかどうかも定義する必要があります。 「いいえ」として構成されたレプリカは、すべての接続を拒否します。このレプリカは、ディザスタリカバリ状況でのフェイルオーバーにのみ使用されると想定されています。セカンダリレプリカが「はい」として構成されている場合、「ApplicationIntent =ReadOnly」が指定されていない場合でも、すべての接続が許可されますが、読み取りアクセスに対してのみ許可されます。最後に、セカンダリが「読み取り専用インテント」として構成されている場合、「ApplicationIntent=ReadOnly」を指定したクライアントのみが接続を許可されます。
読み取り専用ルーティング
サーバーインスタンスでApplicationIntentを構成し、必要な接続文字列を作成する方法がわかったので、可用性グループの読み取り専用ルーティングを構成する必要があります。上記で定義した接続文字列を使用してAGリスナーに接続すると、リスナーはプライマリレプリカインスタンスにクエリを実行し、プライマリ（読み取り/書き込み）または読み取り専用セカンダリのどちらに接続するかを決定します。これを実現するには、レプリカがプライマリの役割を引き受ける場合に使用される各可用性レプリカのルーティングリストを作成する必要があります。通常、ベストプラクティスは、各読み取り専用セカンダリレプリカのすべての読み取り専用ルーティングURLを、リストの最後にローカルレプリカURLとともに含めることです。読み取りインテント接続要求は、ルーティングリストで最初に使用可能な読み取り可能なセカンダリにルーティングされます。セカンダリ間の負荷分散はありません。
まず、各レプリカを変更して、読み取り専用のルーティングURLを提供します。
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER01.mydomain.com:1433')); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER02.mydomain.com:1433'));
次に、各レプリカを変更して、特定のレプリカが主要な役割を果たしているときに使用される読み取り専用ルーティングリストを提供します。
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER02','COMPUTER01')));
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER01','COMPUTER02'))); ルーティングURLは「TCP：//：」の形式である必要があります。 URLの決定については、MattNeerincxによって作成されたこのブログとスクリプトを参照してください。
結論
読み取り専用ルーティングが構成され、AGリスナーが作成され、クライアントアプリケーションが正しい接続文字列を使用している場合、可用性グループの完全なフォールトトレラント接続が必要です。接続と、フェイルオーバー時にサーバーを追跡するアプリケーションの機能をテストするために、時間をかけてください。