同一サブネット内で負荷分散不可
サーバー間等の同一サブネット内における通信で、負荷分散装置を介したSLBが正常に行えない場合に考えられるトラブルについて説明します。
現象
負荷分散装置配下のサーバーから他のサーバーに対する通信を負荷分散するようにしたが、通信出来ない。送信元のサーバーと分散対象サーバーは同一サブネットにあるとします。
上記は、青線のようにパソコンからWebサーバーに通信があった場合、赤線のようにWebサーバーがDBサーバーを参照してページを応答するシステムで、WebサーバーとDBサーバーが同一サブネット内にある例です。
切り分け方法
スイッチにポートミラーリングの設定を行い、WireShark等で送信元サーバーと仮想IPアドレス間のパケットを採取します。
仮想IPアドレスへの送信パケットがあり、応答がない場合、分散対象サーバーから直接応答が返っていないか確認するため、送信元サーバーと分散対象サーバー間のパケットを採取します。
原因
送信元サーバーから仮想IPアドレスへの送信があり、応答は分散対象サーバーから直接帰っている場合、送信元サーバーは異なるサーバーから応答があったと認識しています。
送信元サーバーから172.16.1.4に対して通信したのに、172.16.1.5から応答があると通信は成り立ちません。
これは、送信元サーバーは仮想IPアドレスに送信するのに対し、分散対象サーバーから応答する時は、送信元IPアドレスが同一サブネット内なので直接応答出来るためです。
つまり、同一サブネット内ではARPによりMACアドレスを解決して直接応答出来るため、帰りの通信が負荷分散装置を介さない事が原因です。
対処
応答パケットも負荷分散装置を介して通信するようにすれば、正常に通信可能です。この方法として2つの例を示します。
1つ目の方法は、サブネットを分ける方法です。サブネットが分かれていれば、応答パケットが負荷分散装置を介するため、送信元IPアドレスは仮想IPアドレスに変換されます。
負荷分散装置は、単純にパケットを振り分けているのではなくコネクションを管理しており、戻りのパケットを認識して送信元を仮想IPアドレスに変換します。従って、上の図で言えばWebサーバーは仮想IPアドレス172.16.1.4に送信し、172.16.1.4から応答があったと認識するため、正常に通信可能です。
この方法は、サブネットを跨いで負荷分散するため分かり易いですが、一旦構築したシステムのサブネットを分けるのは変更点が多く困難です。例えば、負荷分散装置でサブネットを分ける設定が必要で、サーバー側でもIPアドレスやゲートウェイの設定変更が必要です。
2つ目の方法は、負荷分散装置でソースNATを行い、送信時に送信元IPアドレスを仮想IPアドレス等に変換する方法です。
分散対象サーバーでは仮想IPアドレスから通信があったと認識するため、分散対象サーバーからの応答パケットは宛先が仮想IPアドレスになり、負荷分散装置を介して戻りの通信も行われます。
サブネットを分ける方法と同じで、応答パケットが負荷分散装置を介した時点で、送信元アドレスは仮想IPアドレスに変換されます。
この方法は、負荷分散装置でソースNATの設定をする必要がありますが、サブネットを分けるような大きな変更は必要ありません。留意点としては、分散対象サーバーのログ等に送信元が全て仮想IPアドレスで記録される事です。つまり、トラブル発生時等に、分散対象サーバー側でどこから通信があったか調査する事が困難になる可能性があります。
補足
上記のトラブルはサーバー間だけでなく、パソコンからサーバーへの通信における負荷分散でも発生します。
このような構成の場合も、負荷分散装置でソースNATの設定を行うと、戻りのパケットも負荷分散装置を介して応答するため、正常に通信出来るようになります。留意点も同じで、分散対象サーバー上のログは、送信元が全て仮想IPアドレスになります。
- 応用編「サーバー負荷分散」
- トラブル対応「URL単位の負荷分散が出来ない」