私は現在、クライアントから自分のErlangアプリサーバーへのtcp接続の負荷を分散するためにHAProxyを使用しています。接続は永続的です。つまり、最適化されたサーバーでは約64Kクライアントに制限されています(現在、m1.large EC2インスタンスでHAProxyを実行しています)。アプリサーバーは、TCP接続の数に基づいて水平方向にスケーリングするように設計されています。1対1の接続であるため、アプリサーバーと同じ数のHAProxyサーバーが必要になるのですが、 。現在、アプリケーションサーバーへのtcp接続を「プロキシ」して、HAProxyがクライアントをErlangサーバーに送信すると、接続を解放して別のクライアントにサービスを提供できるようにする方法はありますか?論文、既存のソリューションはありますか?アプリサーバーの64Kの制限のみを気にして、負荷分散サーバー自体を気にする必要がないように読むことができますか?
64Kクライアントに制限されていると思うのはなぜですか?あなたはそれ以上に役立つことができるはずです。制限要因であるのはポート数ではなく、任意の時点で開くことができる接続の量を制限するのはメモリとCPUパワーです。チェック: http://www.kegel.com/c10k.html 日付がついています。代わりに、それをc100kまたはc1Mの問題と考えてください。 :-)
ちなみに、haproxyサイトには、負荷分散とhaproxyのアーキテクチャに関する優れた記事があります。 http://haproxy.1wt.eu/download/1.2/doc/architecture.txt
接続制限に関しては、これは理論的にはそれより前にリソースが不足するため到達できない理論上の制限です。
「TCP標準は、ローカルIPアドレスのタプルとして一意の接続識別子を設定します。ローカルTCPポート番号、リモートIPアドレス、およびリモートTCPポート番号。この例では、ローカル番号は両方とも固定されており、約2 ^ 32のリモートIP(バージョン4)アドレスと2 ^ 16 TCPポート番号が残ります、または同時の可能性があるおおよその合計TCP 281,474,976,710,656(2 ^ 48、または2.81 * 10 ^ 14、または281兆)の接続。 "
64k同時[〜#〜] idle [〜#〜]接続は、HAProxyとErlangのピーナッツです。
最初にすることはHAProxyの統計ページを有効にするです。モニタリングとパフォーマンスチューニングには必須です。
それでは限界に入りましょう。
タプルごとに1つの接続しか存在できませんclient_IP:client_PORT:server_IP:server_PORT
。これは、接続がカーネルに格納および取得される方法(つまり、ハッシュテーブル)に由来します。 LinuxとWindowsでも同じです。
私はそれについてaseqに同意しなければなりません。これは理論上の制限ではありません。これは、中程度の負荷テストを行う人が到達する可能性のある非常に実用的な制限です。
現在のセットアップに3台のコンピュータがあるとしましょう:
[Test Computer] [HAProxy Computer] [Erlang Computer]
(front) test_IP:????<------>haproxy_IP:80
(back) haproxy_IP:????<------>erlang_IP:80
すべてのIPが固定され、Webサーバーポートが固定されます。これにより、変数パラメーターとしてポートが1つだけ残るため、接続の最大数は、単一のコンピューターで使用可能なポートの数によって制限されます。ここには余裕がほとんどありません(Ephemeral Ports Rangeを参照)。 Erlangインスタンスと負荷テストインスタンスの両方で、より多くのインスタンスを取得する必要があります。
注:ユーザーは自然に多くのIPからアクセスしますが、負荷テスター(curl、Apache ab、JMeter)は通常、単一のIPを備えた単一のボックスで実行されます(JMeterおよび同様のツールは分散スレーブを使用してスケーリングできます) )。
注:HAProxy接続は常にペアになります(1つはクライアントへの接続、もう1つは内部サーバーへの接続)。 N人のユーザーを許可するには、ほとんどのシステム制限を2 * Nにする必要があるため、この点に注意してください。
少数のポートのみが新しい接続の作成に使用されます。という ephemeral ports
。 Linuxのデフォルトは32768〜61000です。
範囲を拡張します。まず、サーバー上でそれらを使用している実行中のサービスがあるかどうかを確認します。
sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 20000 65000
そのTweakは60%以上のポートしか提供できません。 1台のサーバーでWeb規模を拡大するには十分ではありません。
ポートを閉じた後、1分間ポートを再利用できないことに注意してください(TCP状態)を参照)。これにより、ポートプールが非常に小さくなる可能性があります(例:誰でも10kポート/秒?)。終了時間を変更し、終了ポートの再利用を可能にするカーネル設定。
永続的な接続(これらは少なくとも更新の数分前)が存続する限り、これらの微調整は永続的な接続には必要ありません。それにもかかわらず、潜在的な問題を認識することが重要です。
HAProxyでmaxconn
設定を構成します。これは、いつでも許可されているオープン接続の最大量です。
global
、frontend
ごと、またはbackend
ごとに構成できます。統計ページには、それぞれすべてのアクティブな設定が表示されます。
Ulimitは、単一のプロセスによって開かれるファイルの最大量です(ソケットはLinux上のファイルです)。 Linuxのデフォルトは1kから10kの間です。
HAProxyは、maxconn
パラメーターに基づいてプロセスのulimitを自動的に構成します。
おそらく、Erlangプロセスのulimitを手動で微調整する必要があります。
私はあなたの質問に答える最良の方法は、HAProxyとアプリサーバーの間の1:1マッピングが必要ではないことを指摘することだと思います。 HAProxyでは、いくつかの方法で永続的な接続が可能です。詳細については、「永続的」のドキュメントを検索することをお勧めします: http://haproxy.1wt.eu/download/1.4/doc/configuration.txt 。
たとえば、TCP接続の場合、構成にbalance sourceを追加すると、永続性が提供されます。