LBFO と NLB を併用する場合の注意事項について

Last Update: feedback 共有

本記事はマイクロソフト社員によって公開されております。

本記事は 2015 年 10 月 29 日に公開された記事を本ブログに移行した記事になります。

こんにちは Windows プラットフォーム サポートです。

今回は、LBFO (Load Balancing and Failover) と NLB (Network Load Balancing) を併用する際の注意事項についてご紹介致します。

1. 事例のご紹介

図 1. ネットワーク構成例 (1)

図 2. ネットワーク構成例 (2)

上記いずれの構成も、NLB クラスター IP アドレス宛の通信は、ルーター (L3 スイッチ) や L2 スイッチでパケットがフラッディングし、最終的に LBFO によってチーミングを構成する全ての NIC アダプターに到達致します。
このとき、NIC チーミングでスタンバイ アダプターを指定し、”アクティブ / スタンバイ” の構成を取っていたとしても、スタンバイの NIC アダプターで受信したパケットは破棄されず TCPIP.sys ドライバーに転送されます。
その結果、アクティブ アダプター経由およびスタンバイ アダプター経由で同一のパケットを重複して受信することとなります。

以下は、上述の構成において、クライアントからサーバーに Web アクセス (TCP 80 番ポート使用) を行った際の通信シーケンス例となります。
クライアント、サーバー共に相手からの応答待ちで再送要求が発生し、通信遅延が発生していることが確認できます。
同一構成で帯域制御装置のみ存在しない場合には通信遅延が発生しないことから、帯域制御装置の動作が影響して遅延が発生していることが想定されます。

表 1. クライアント (10.100.192.100) 上で取得したパケット キャプチャー

1
2
3
4
5
6
7
8
9
10
11
12
Frame Time             Delta     S-IP Address   D-IP Address   S-Port D-Port Protocol Desctiption
-----------------------------------------------------------------------------------------------------
1 20:00:01.7254181 0.0000000 10.100.192.100 10.120.172.101 60000 80 TCP Flags=......S.,
2 20:00:01.7275593 0.0021412 10.120.172.101 10.100.192.100 80 60000 TCP Flags=.....R..,
3 20:00:01.7275596 0.0000003 10.120.172.101 10.100.192.100 80 60000 TCP Flags=...A..S.,
4 20:00:01.7275936 0.0000340 10.100.192.100 10.120.172.101 60000 80 TCP Flags=...A....,
5 20:00:01.7276411 0.0000475 10.100.192.100 10.120.172.101 60000 80 HTTP Request, GET
6 20:00:02.0317132 0.3040721 10.100.192.100 10.120.172.101 60000 80 TCP [ReTransmit #5]
7 20:00:02.6401235 0.6084103 10.100.192.100 10.120.172.101 60000 80 TCP [ReTransmit #5]
8 20:00:03.8412593 1.2011358 10.100.192.100 10.120.172.101 60000 80 TCP [ReTransmit #5]
9 20:00:04.7352085 0.8939492 10.120.172.101 10.100.192.100 80 60000 TCP Flags=...A..S.,
10 20:00:04.7352765 0.0000680 10.100.192.100 10.120.172.101 60000 80 TCP Flags=...A....,

※ Frame 2 で Reset を受信しておりますが、3 Way-hand-shake には影響はありません。
※ Frame 5 で HTTP Request を送信してますが、応答がなく再送を 3 回繰り返し、おおよそ 4 秒後にサーバーが応答している状況が確認できます。

表 2. サーバー (10.120.172.101) 上で取得したパケット キャプチャー

1
2
3
4
5
6
7
8
9
Frame Time             Delta     S-IP Address   D-IP Address   S-Port D-Port Protocol Desctiption
-----------------------------------------------------------------------------------------------------
1 20:00:01.7623087 0.0000000 10.100.192.100 10.120.172.101 60000 80 TCP Flags=......S.,
2 20:00:01.7623087 0.0000000 10.100.192.100 10.120.172.101 60000 80 TCP Flags=......S.,
3 20:00:01.7624433 0.0001272 10.120.172.101 10.100.192.100 80 60000 TCP Flags=.....R..,
4 20:00:01.7624633 0.0000154 10.120.172.101 10.100.192.100 80 60000 TCP Flags=...A..S.,
5 20:00:04.7703551 3.0078878 10.120.172.101 10.100.192.100 80 60000 TCP Flags=...A..S.,
6 20:00:08.6831641 3.9128044 10.100.192.100 10.120.172.101 60000 80 HTTP Request, GET
7 20:00:08.6833164 0.0001443 10.120.172.101 10.100.192.100 80 60000 TCP Flags=...A....,

※ Frame 1 および Frame 2 で、同時刻にクライアントから Syn を 2 つ受信しており、Frame 3 で Reset を応答しています。
※ Frame 4 にて Syn / Ack を送信するものの応答が無く、Frame 5 の再送後、約 4 秒後に HTTP Request を受信しています。

2. 対処方法について

以下のいずれかの対応を検討ください。

1. “アクティブ / スタンバイ” の構成で KB3179574 を適用してレジストリ DropStandbyReceive を設定する。

レジストリ DropStandbyReceive を設定することで、スタンバイ NIC で受信したパケットが破棄されるようになります。

レジストリ DropStandbyReceive の設定方法は以下 URL を参照ください。

August 2016 update rollup for Windows 8.1 and Windows Server 2012 R2

https://support.microsoft.com/en-us/help/3179574

2. チーミング モードを “LACP” または “静的” として構成する。

チーミング モードを “LACP” または “静的” にて設定することで、2 つの Syn パケットを受信することが無くなり、その結果 Reset 応答をしなくなります。

3. 参考

NIC チーミングの概要
https://technet.microsoft.com/ja-jp/library/hh831648.aspx

何でも屋: 可用性に対応する
https://technet.microsoft.com/ja-jp/magazine/jj149029.aspx

[特記事項]
本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。