LANとWi-Fiによる負荷分散

Mac OS X 10.6またはUbuntu 9.10またはWindows XP（マルチブート）を実行するMacを持っています。ソリューションは、どのシステムにも適用できます。

私は2つのISPを持っています。1つはWi-Fi経由でアクセスでき、もう1つはLAN経由でアクセスできます。Mac OS XIでは、優先順位、つまり最初に選択するネットワークを定義できます。しかし、私がやりたいのは、両方のネットワークとの負荷分散です。

追加のハードウェアを購入したくありません。これが役立つ場合は、未使用のWi-Fiルーターをいくつか持っています。

Linuxでプログラムをコンパイルして構成することは、私にとっては問題ありません。

同様の質問：複数のゲートウェイを使用した負荷分散

Linuxに近いトピックは、ルートの「メトリック」設定です。小さい数値は大きい数値よりも優先されます。両方のルートに同じメトリックを指定した場合、それらは等しい確率で選択されると思います。

あなたが達成しようとしているテクニックはマルチホーミングと呼ばれていると思います。直接の経験はありません。ただし、覚えておかなければならないことがいくつかあります。

• デフォルトでは、デフォルトルートは1つだけになると思います。これは、すべての発信トラフィックがデフォルトで1つのインターフェースを優先することを意味します。複数のデフォルトルートがあるか、そのルートを時間の経過とともに動的に変更することを検討する必要があります。
• 個々の着信（TCP）接続の存続期間中は、接続したときと同じインターフェースにとどまる必要があります。おもう。

誰にでも、それらは私が現時点で考えることができるすべてのポインターです。

ルーティングテーブルに同じメトリックで両方のインターネット接続をインストールするルーティングメトリックシステムを使用できます。次に、オペレーティングシステムはこれらのルートの両方を等しく使用し、送信トラフィックを両方のリンクに効果的に分割します。

リクエストへの応答としての着信トラフィックも、リクエストが送信されたインターフェース（パブリックIP）に戻るため、バランスを取る必要があります。

これの問題は、セッションの永続性にあります。たとえば、リンクの1つを介してWebサイトを表示しますが、次のページビューは他のインターフェースからロードバランシングされます。これにより、ソースIPアドレスが常に変化するため、一部のアプリケーションが混乱します。

したがって、アプリケーション、宛先、またはプロトコルごとに、等コストルートを使用せずに、トラフィックの一部のみを他のインターフェイスに分割することになるでしょう。トラフィックパスの一貫性を保つためのものです。

Connectify Dispatchには、必要なものだけを実行するソリューションがあります。現在はWindowsのみですが、OS Xでソフトウェアを仮想化して使用することに成功しています。

あなたは既にWindows XPを実行していたので、自分でその部分を理解できると思いました。

これに関する最大の問題は、Windowsが複数のNICのサポートを簡単に提供できることですが、OS Xでは実装がそれほど簡単ではありません。

ある種の回避策があります。私のアプリケーションは負荷分散を行うことができます。2つの接続を定義して、両方を使用することができます。

次に、サーバーIPの1つをIPSの1つにルーティングします。

Mac OS 10.6の場合：

route add -host XXX.XXX.XXX.XXX 192.168.1.1

これは非常に具体的で、サーバーのIPが常に同じ場合にのみ機能します。そして、アプリケーションが何らかの方法で負荷分散できる場合。

出て行くすべてのトラフィックが1つのISPであり、入ってくるトラフィックが別のISPであるようなことをしなければ、これは不可能だと思います。

両方のトラフィックを2つの別々のネットワークに分割している理由は、それらが元に戻るようには思えません。1つのISPから2つのパイプがあった場合、それが可能になるかもしれません。

前に言った人のように、とにかくデフォルトが必要だと思います。特定のトラフィックを1つのルートで抑制し、残りを別のルートで抑制することができます。ここでは、LANのような負荷分散が機能するとは考えないでください。

例：192.168.2。*を使用して更新を実行するWi-Fi ISPは、192.168.1。* LAN ISPを使用して半減期を実行します。

下記のURLは特に勝利7を対象としていますが、そこからアイデアを得る必要があります。インターフェイスの負荷に応じてデフォルトゲートウェイのメトリックを変更するため、負荷分散につながります。

http://www.youtube.com/watch?v=Qh5Eb8sXvuk

私はこの同じ質問を数十回、数十通りの方法で聞いたことがあります。まず、内部セッションと外部セッションは同様に処理されますが、同じではありません。すべての内部セッションに対して、複数の外部セッションが存在する可能性があり、その逆も同様です。あなたが話していることは論理的に不可能ではありませんが、少しのプログラミングと準備が必要です。一部のデバイスは、イーサネット接続またはwifiを集約してネットワーク内部でより高速なネットワーク速度を実現する機能を備えて構築されていますが、外部ネットワークの場合、FAILOVERを備えたデバイスしか見つかりませんでした。ただし、各EXTERNALセッションに対して異なるゲートウェイを介してトラフィックをリダイレクトする接続プロトコルで、基本的なスイッチング（0または1のifステートメント）を使用できます。次に、セッションIDでメインセッション内にサブセッションをラップすることにより、各内部セッションに接続された各外部セッションを追跡する必要があります。次に、サイトドメインを確認する方法、またはセッションIDを使用して内部ルーティングを完了する方法が必要になります（つまり、外部セッションごとに、クライアントからのメッセージを区別できるようにする必要があります。各サイトのパイプが設定され、サイトがパイプを拒否しないようにするために、データを要求または送信していたサイト。これは、ルーターに新しいネットワークプロトコルを構築し、接続を区別する方法を決定する必要があることを意味します（サイトドメインによってのみ行われる場合、ルーターから実行できる場合がありますが、クライアントは、これを否定するウェブサイトの外部ゲート。両端で行われる場合、クライアントは何らかの識別子（通常はバイナリマスキングの数値）を追跡する必要があります。これにより、送信受信をメインゲートでルーティングされる外部セッションと照合できます。つまり、ネットワークを処理するために独自のプロトコルをプログラムする必要があり、自分で構築するか（クライアントとホストの両方のプログラミングを使用するか）、または何かを構築するかどうかを決定する必要があります。これは、既存の既存のプログラミングと互換性があります（ホストとクライアント間のメッセージングによってバインドされる必要があり、ホストの摩耗を増やしますが、クライアントには新しいものはありません）。unixを知っている場合、またはwinserverプログラミングを知っている場合、これはほんの少しの時間で実行できますが、バランスをとる各デバイスに大量のリソースを割り当てる必要があります。クライアントは、識別子（通常はバイナリマスキングの数値）を追跡する必要があります。これにより、送信受信をメインゲートでルーティングされる外部セッションと照合できます。つまり、ネットワークを処理するために独自のプロトコルをプログラムする必要があり、自分で構築するか（クライアントとホストの両方のプログラミングを使用するか）、または何かを構築するかどうかを決定する必要があります。これは、既存の既存のプログラミングと互換性があります（ホストとクライアント間のメッセージングによってバインドされる必要があり、ホストの摩耗を増やしますが、クライアントには新しいものはありません）。unixを知っている場合、またはwinserverプログラミングを知っている場合、これはほんの少しの時間で実行できますが、バランスをとる各デバイスに大量のリソースを割り当てる必要があります。クライアントは、識別子（通常はバイナリマスキングの数値）を追跡する必要があります。これにより、送信受信をメインゲートでルーティングされる外部セッションと照合できます。つまり、ネットワークを処理するために独自のプロトコルをプログラムする必要があり、自分で構築するか（クライアントとホストの両方のプログラミングを使用するか）、または何かを構築するかどうかを決定する必要があります。これは、既存の既存のプログラミングと互換性があります（ホストとクライアント間のメッセージングに拘束される必要があり、ホストの摩耗を増やしますが、クライアントには新しいものはありません）。unixを知っている場合、またはwinserverプログラミングを知っている場合、これはほんの少しの時間で実行できますが、バランスをとる各デバイスに大量のリソースを割り当てる必要があります。通常、バイナリマスキングの数値。これにより、送信受信をメインゲートでルーティングされる外部セッションと照合できます。つまり、ネットワークを処理するために独自のプロトコルをプログラムする必要があり、自分で構築するか（クライアントとホストの両方のプログラミングを使用するか）、または何かを構築するかどうかを決定する必要があります。これは、既存の既存のプログラミングと互換性があります（ホストとクライアント間のメッセージングに拘束される必要があり、ホストの摩耗を増やしますが、クライアントには新しいものはありません）。unixを知っている場合、またはwinserverプログラミングを知っている場合、これはほんの少しの時間で実行できますが、バランスをとる各デバイスに大量のリソースを割り当てる必要があります。通常、バイナリマスキングの数値。これにより、送信受信をメインゲートでルーティングされる外部セッションと照合できます。つまり、ネットワークを処理するために独自のプロトコルをプログラムする必要があり、自分で構築するか（クライアントとホストの両方のプログラミングを使用するか）、または何かを構築するかどうかを決定する必要があります。これは、既存の既存のプログラミングと互換性があります（ホストとクライアント間のメッセージングに拘束される必要があり、ホストの摩耗を増やしますが、クライアントには新しいものはありません）。unixを知っている場合、またはwinserverプログラミングを知っている場合、これはほんの少しの時間で実行できますが、バランスをとる各デバイスに大量のリソースを割り当てる必要があります。これにより、送信受信をメインゲートでルーティングされる外部セッションと照合できます。つまり、ネットワークを処理するために独自のプロトコルをプログラムする必要があり、自分で構築するか（クライアントとホストの両方のプログラミングを使用するか）、または何かを構築するかどうかを決定する必要があります。これは、既存の既存のプログラミングと互換性があります（ホストとクライアント間のメッセージングに拘束される必要があり、ホストの摩耗を増やしますが、クライアントには新しいものはありません）。unixを知っている場合、またはwinserverプログラミングを知っている場合、これはほんの少しの時間で実行できますが、バランスをとる各デバイスに大量のリソースを割り当てる必要があります。これにより、送信受信をメインゲートでルーティングされる外部セッションと照合できます。つまり、ネットワークを処理するために独自のプロトコルをプログラムする必要があり、自分で構築するか（クライアントとホストの両方のプログラミングを使用するか）、または何かを構築するかどうかを決定する必要があります。これは、既存の既存のプログラミングと互換性があります（ホストとクライアント間のメッセージングに拘束される必要があり、ホストの摩耗を増やしますが、クライアントには新しいものはありません）。unixを知っている場合、またはwinserverプログラミングを知っている場合、これはほんの少しの時間で実行できますが、バランスをとる各デバイスに大量のリソースを割り当てる必要があります。自分で構築するか（クライアントとホストの両方のプログラミングを使用して）、または古い既存のプログラミングと互換性のあるものを構築するか（ホスト間のメッセージングにバインドする必要があるか）を決定する必要があります。とクライアントは、ホストの摩耗を増やしますが、クライアントにとって新しいものはありません）。unixを知っている場合、またはwinserverプログラミングを知っている場合、これはほんの少しの時間で実行できますが、バランスをとる各デバイスに大量のリソースを割り当てる必要があります。自分で構築するか（クライアントとホストの両方のプログラミングを使用して）、または古い既存のプログラミングと互換性のあるものを構築するか（ホスト間のメッセージングにバインドする必要があるか）を決定する必要があります。とクライアントは、ホストの摩耗を増やしますが、クライアントにとって新しいものはありません）。unixを知っている場合、またはwinserverプログラミングを知っている場合、これはほんの少しの時間で実行できますが、バランスをとる各デバイスに大量のリソースを割り当てる必要があります。ホストにより多くの摩耗をもたらしますが、クライアントにとって新しいものはありません）。unixを知っている場合、またはwinserverプログラミングを知っている場合、これはほんの少しの時間で実行できますが、バランスをとる各デバイスに大量のリソースを割り当てる必要があります。ホストにより多くの摩耗をもたらしますが、クライアントにとって新しいものはありません）。unixを知っている場合、またはwinserverプログラミングを知っている場合、これはほんの少しの時間で実行できますが、バランスをとる各デバイスに大量のリソースを割り当てる必要があります。

より大規模な企業スタイルのネットワークの場合、ネットワークをメッシュ化し、各フロアまたは部門に専用のゲートウェイを提供して、複数のISPを許可し、それらのいずれにも過度の負荷をかけないようにすることができます。また、変更を送信したり別のゲートウェイにリダイレクトしたりするハブがフェイルオーバーを処理することもできます。これにより、フォールトトレランスが提供されます。