可用性グループ通信用の専用ネットワークの構成

SQL Server 2012 AlwaysOn可用性グループには、可用性グループのレプリカやデータベースミラーリングセッションをホストするSQLServerインスタンスごとにデータベースミラーリングエンドポイントが必要です。このSQLServerインスタンスエンドポイントは、1つ以上の可用性グループレプリカやデータベースミラーリングセッションによって共有され、プライマリレプリカと関連するセカンダリレプリカ間の通信のメカニズムです。

プライマリレプリカのデータ変更ワークロードによっては、可用性グループのメッセージングスループット要件が重要になる場合があります。このアクティビティは、同時の非可用性グループアクティビティからのトラフィックにも敏感です。帯域幅の低下と同時トラフィックが原因でスループットが低下している場合は、可用性レプリカをホストしているSQLServerインスタンスごとに可用性グループトラフィックを専用のネットワークアダプターに分離することを検討してください。この投稿では、このプロセスについて説明し、スループットが低下したシナリオで予想されることについても簡単に説明します。

この記事では、5ノードの仮想ゲストWindows Serverフェールオーバークラスター（WSFC）を使用しています。 WSFCの各ノードには、非共有ローカルストレージを使用する独自のスタンドアロンSQLServerインスタンスがあります。各ノードには、パブリック通信用の個別の仮想ネットワークアダプター、WSFC通信用の仮想ネットワークアダプター、および可用性グループ通信専用の仮想ネットワークアダプターもあります。この投稿では、各ノードの可用性グループ専用ネットワークアダプターに必要な情報に焦点を当てます。

専用NICを使用した可用性グループの設定は、共有NICプロセスとほぼ同じですが、可用性グループを特定のNICに「バインド」するために、最初にLISTENER_IPを指定する必要があります。 CREATE ENDPOINTの引数 コマンド、専用NICの前述のIPアドレスを使用します。以下に、5つのWSFCノードにわたる各エンドポイントの作成を示します。

:CONNECT SQL2K12-SVR1
 
USE [master];
GO
 
CREATE ENDPOINT [Hadr_endpoint] 
    AS TCP (LISTENER_PORT = 5022, LISTENER_IP = (192.168.20.31))
    FOR DATA_MIRRORING (ROLE = ALL, ENCRYPTION = REQUIRED ALGORITHM AES);
GO
 
IF (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') <> 0
BEGIN
    ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
END
GO
 
USE [master];
GO
 
GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [SQLSKILLSDEMOS\SQLServiceAcct];
GO
 
:CONNECT SQL2K12-SVR2
 
-- ...repeat for other 4 nodes...

専用NICに関連付けられたこれらのエンドポイントを作成した後、可用性グループトポロジを設定する残りの手順は、共有NICシナリオの場合と同じです。

可用性グループを作成した後、プライマリレプリカ可用性データベースに対してデータ変更の負荷をかけ始めると、[ネットワーク]タブのタスクマネージャーを使用して、可用性グループの通信トラフィックが専用NICに流れていることがすぐにわかります（最初のセクションはスループットです）。専用可用性グループNICの場合）：

また、さまざまなパフォーマンスカウンターを使用して統計を追跡することもできます。次の画像では、Inetl [R] PRO_1000 MTネットワーク接続_2が専用の可用性グループNICであり、他の2つのNICと比較してNICトラフィックの大部分を占めています。

可用性グループトラフィック専用のNICを使用することで、アクティビティを分離し、理論的にはパフォーマンスを向上させることができますが、専用NICの帯域幅が不十分な場合は、パフォーマンスが低下し、可用性グループトポロジの状態が低下することが予想されます。

たとえば、プライマリレプリカの専用可用性グループNICを28.8 Kbpsの発信転送帯域幅に変更して、何が起こるかを確認しました。言うまでもなく、それは良くありませんでした。可用性グループのNICスループットが大幅に低下しました：

数秒以内に、さまざまなレプリカの状態が低下し、いくつかのレプリカが「同期していない」状態に移行しました。

プライマリレプリカの専用NICを64Kbpsに増やしたところ、数秒後に最初のキャッチアップスパイクも発生しました：

状況は改善しましたが、この低いNICスループット設定で定期的な切断とヘルス警告を目撃しました：

プライマリレプリカに関連する待機統計についてはどうですか？

専用NICに十分な帯域幅があり、すべての可用性レプリカが正常な状態にある場合、2分間のデータロード中に次の分​​布が見られました。

HADR_WORK_QUEUE 新しい作業を待機している予想されるバックグラウンドワーカースレッドを表します。 HADR_LOGCAPTURE_WAIT 新しいログレコードが利用可能になるまでの別の予想される待機を表し、Books Onlineによると、ログスキャンが追いついた場合、またはディスクから読み取っている場合に予想されます。

可用性グループを異常な状態にするためにNICのスループットを十分に下げたとき、待機タイプの分布は次のようになりました。

これで、新しい上位待機タイプHADR_NOTIFICATION_DEQUEUEが表示されます。 。これは、Books Onlineで定義されている「内部使用のみ」の待機タイプの1つであり、WSFC通知を処理するバックグラウンドタスクを表します。興味深いのは、この待機タイプが問題を直接示していないことですが、テストでは、可用性グループのメッセージングスループットの低下に関連してこの待機タイプがトップに上がることが示されています。

つまり、十分な帯域幅を備えたネットワークスループットを提供している場合は、可用性グループのアクティビティを専用のNICに分離することが有益です。ただし、専用ネットワークを使用しても十分な帯域幅を保証できない場合は、可用性グループトポロジの状態が低下します。