まず、問題の背景を説明します。私は、いくつかの Web サーバーの負荷を分散するために Cisco CSS11501 を使用しています。これらの Web サーバーには、内部と外部の 2 つのネットワーク インターフェイスがあり、リクエストは内部インターフェイスに送信されています。
ウェブサーバーはクライアントの IP アドレスを確認する必要があるため、CSS を NAT を実行するように構成しています。
TCP パケットはインターネット上の送信元アドレスを持つ Web サーバーにヒットするため、Web サーバーはロード バランサーを経由せず、外部インターフェイス経由でパケットをクライアントに送り返そうとします。これらのリクエストが外部インターフェイス経由でインターネットに送り返されるのを防ぐため、これらのボックスにルーティング ルールを追加し、インターネット上の送信元アドレスを持つすべてのトラフィックがロード バランサーをゲートウェイとして使用するようにしました。この部分は正常に動作しています。
また、MySQL スレーブなどの内部サービスのロード バランサとして CSS を使用することもできます。
これを実行すると、同様の問題が発生します。TCP 接続は Web サーバーからロード バランサーへ、そしてロード バランサーから MySQL スレーブへ送られますが、CSS は元の Web サーバーのソース アドレスを偽装します。次に、MySQL スレーブは、ロード バランサー経由ではなく、内部ネットワーク経由で Web サーバーに直接応答を送信しようとします。
理想的な解決策は、CSS に内部ネットワーク上でソース アドレスのスプーフィングを行わず、インターネットから発信されたリクエストに対してのみ行うように指示することです。これは可能ですか?
それができない場合、他のトラフィック (SSH など) を純粋に内部ネットワーク上に維持しながら、負荷分散されたトラフィックをロード バランサー経由で戻す方法はありますか?
CSS11501 を使用して内部サービスの負荷を分散する別の方法はありますか?
答え1
CSS は元の Web サーバーのソース アドレスを偽装します。その後、MySQL スレーブは、ロード バランサー経由ではなく、内部ネットワーク経由で Web サーバーに直接応答を送信しようとします。
理解できません。CSS がソース IP を偽装する場合、mysql は CSS IP をソースとして認識し、IP が偽装されている場合は Web サーバーではなく CSS に応答する必要があります...
とにかく、グループコマンドこれにより、1つまたは複数のサービスに対して、リクエストの送信元アドレスを別のアドレスに隠すことができます。これは、
mysqlのロードバランシングに必要な機能だと思います。