SSLを分散する水平方向にスケーラブルなソフトウェアロードバランサーの例がないのはなぜですか？
相互に関連しているように見えるSSL、ローカルセッション、および負荷分散に関して多くの質問があります。この質問の長さについて、事前にお詫び申し上げます。
ファイルベースのセッションを使用するWebサイトがあります。サイトの性質上、ほとんどがhttpですが、一部のセクションはsslです。現在、ファイルベースのセッションのため、sslリクエストは以前のhttpリクエストと同じサーバーにヒットする必要があります。
時間の制約があるため、httpトラフィックとSSLトラフィックの増加を負荷分散するために可能な限り簡単なことをしたいと思います。
スティッキーロードバランシングアルゴリズムには2つのオプションがあるようです。
- iPベース
- クッキーベース
IPベースのソリューションはおそらく機能しますが、ハッシュアルゴリズムは、サーバーがダウンしたり追加されたりしたときにユーザーがアクセスするサーバーを変更する可能性があります。これは、現在のファイルベースのセッション設定では望ましくありません。また、ユーザーがWebサイトを閲覧しているときに、合法的にipsを変更することは技術的に可能であると思います。
Cookieベースのアルゴリズムの方が優れているように見えますが、SSLで暗号化したときにCookieを検査できないことには、独自の問題があるようです。
私はsslの負荷分散方法の例を探していましたが、Cookieベースの負荷分散を実行でき、別のsslデコーダーを追加することでssl負荷の増加に対処できるセットアップの明示的な例を見つけることができないようです。
私が見た明示的な例のほとんどは、ブラウザークライアントとロードバランサーの間にsslデコーダー（通常はハードウェア、Apache_mod_ssl、またはnginx）が配置されています。例には通常、次のようなものがあるようです（ http://haproxy.1wt.eu/download/1.3/doc/architecture.txt から変更）：
192.168.1.1 192.168.1.11-192.168.1.14 ------- + ----------- + ----- + ---- -+ ----- + | | | | | +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ | LB1 | | A | | B | | C | | D | + ----- + + --- + + --- + + --- + + --- + Apache4の安価なWebサーバー mod_ssl haproxy
上記の例のsslデコード部分は、水平方向にスケーラブルではない潜在的なボトルネックのようです。
私はhaproxyを見てきましたが、次のようなものを許可する「mode tcp」オプションがあるようです。これにより、複数のsslデコーダーを使用できます。
haproxy | ------------- | | ssl-decoder-1 ssl-decoder2 | | ------------------- | | | web1 web2 web3
ただし、このような設定では、haproxyがSSLをデコードしていないため、クライアントIPが失われるようです。 https://cloud-support.engineyard.com/discussions/problems/335-haproxy-not-passing -x-forwarded-for
Nginxも調べましたが、水平方向にスケーラブルなsslデコーダーの明示的な例もありません。潜在的なボトルネックとしてnginxを持っている人々の多くの例があるようです。そして、少なくともこのリンクは、nginxが「透過的にTCPを渡すことをサポートしていない」と言って、IPを失うhaproxyのようなセットアップのオプションさえ持っていないことを示唆しているようですバックエンドへの接続」 nginxプロキシを介してApache SSLトラフィックを渡す方法は？ 。
質問：
- トラフィックの増加に対処するためにsslデコーダーを追加するセットアップの例がもっとあるように思われないのはなぜですか？
- それは、SSLデコードのステップが理論上のボトルネックにすぎず、実際には、ばかげたトラフィックのあるサイトを除いて、基本的に1つのデコーダーで十分だからですか？
- 頭に浮かぶ別の可能な解決策は、おそらく、このようにSSLのニーズが高まっている人は、集中型のセッションストアを持っているため、クライアントがシーケンシャルリクエストでどのWebサーバーにアクセスするかは問題ではありません。次に、すべてのWebサーバーでmod_sslまたは同等のものを有効にすることができます。
- 上で引用したhaproxyソリューションは（クライアントIPの問題を除いて）機能しているようですが、クライアントIPを維持しながらデコーダーの数を増やすことで機能する、スティッキーなCookieベースのソフトウェアロードバランサーソリューションに出くわしたことがあります。可能です（クライアントIPを取得するために要求をデコードする必要があるため、この場合、デコーダーのボトルネックが発生します）。
私が言ったことがすべて真実であると仮定すると、これらは私の選択肢のようです。
- iPハッシュを使用する（IPを合法的に変更する可能性のあるユーザー、およびサーバーの追加と削除のシナリオには適していません）
- sslリクエストに触れる最初のプログラムとしてnginxまたはmod_sslを使用します。これは潜在的なsslデコードのボトルネックになります
- sslリクエストにアクセスする最初のプログラムとしてhaproxyを使用し、水平方向のsslスケーラビリティを取得しますが、sslリクエストのWebサーバーレベルでipsがログに記録されない状態で動作します（おそらく一時的に問題ありません）
- 長期的には、モバイルまたは集中型のセッションストアに移行し、スティッキーセッションを不要にします
「最も単純なこと」は、真剣に言えば、一元化されたセッションストアに移動することです。ロードバランサー、haproxy、SSL、およびその他のすべての配管をセットアップする必要があります。これまでに見たセッション処理コードのすべてのビットで、さまざまなストレージエンジンをプラグインするのは簡単です。少しのコードとごくわずかな追加の複雑さがすべての問題を解決します。
wombleは、共有セッションストアについて正しいので、すべての作業がはるかに簡単になります。彼の答えに加えて、私は質問の負荷分散部分について少し拡張することができます：
トラフィックの増加に対処するためにsslデコーダーを追加するセットアップの例がもっとあるように思われないのはなぜですか？
最新 マルチコアPCは数千を実行できます 1秒あたりのSSLトランザクション。そして、それがボトルネックになった場合は、 F5 、Citrix、Ciscoなどの専用アプライアンスをさらに高速化できます。そのため、ほとんどのサイトは、優れた単一デバイスのSSLおよび負荷分散ソリューションを超えることはありません。
私が言ったことがすべて真実であると仮定すると、これらは私の選択肢のようです。
これが必要になった場合は、SSL復号化を水平方向にスケーリングするためのオプションがあります。
一般的なアプローチは、高可用性SSLアクセラレータペアにDNSラウンドロビンを使用することです。つまり、ドメインの複数のIPアドレスを公開し、各IPアドレスはSSLアクセラレータのペアを指します。
この場合、DNS TTLがユーザーセッションの途中でタイムアウトし、ユーザーが別のアプリケーションサーバーにぶつかることを心配する可能性があります。これは一般的なことではありませんが、発生する可能性があります。A共有セッションストアは一般的なソリューションですが、他の方法で処理することもできます。
一例として、SSL復号化をアプリケーションサーバーのバランシングから分離することができます。 SSL処理は、基本的な負荷分散よりもCPUに負荷がかかるため、1つのロードバランサーで2つのSSLアクセラレータを飽和させることができます。このような：
Internet --> DNS round robin to multiple SSL accelerators --> plain HTTP to a single HTTP load balancer --> plain HTTP to multiple application servers
冒頭で述べたように、共有セッションストアは多くのことを簡素化し、SSL /負荷分散レイヤーに多くの複雑さを加えるよりもほぼ確実に優れた長期的なソリューションです。
製品が進化したときに、このような2年前の質問に答えるのは楽しいことです。現在、haproxyはPROXYプロトコルをサポートしています。これにより、純粋なTCPモードでも、クライアントのIPをネクストホップに渡すことができます。ネイティブSSL、および必要に応じてSSLスティッキ性もサポートします。 SSLファーム（おそらくhaproxyサーバーから作成された）の前の最初のレイヤーとして使用します。したがって、リクエストは少し前倒しで、実装が追いついたようです:-)
私はここでwombleとJesperに同意します。最も簡単で最良のルートは、コードを修正することです。もちろん、システム管理者として私たちはそのオプションを持っていないことがよくありますが、その場合でも、真に水平ではなくても、比較的安価な最新のハードウェアを拡張するのに十分なトリックを引き出すことができます。
私はあなたがclient-ipを失うことについて心配しているところについてコメントするために投稿したかっただけです。主要なL7 /プロキシソリューションのいずれでも、X-Forwarded-For（または必要なもの）ヘッダーをリクエストに挿入できます。次に、リクエストを受信するバックエンドWebサーバーで、ログファイル形式を変更して、layer3クライアントIPのログに使用したファイルの同じスペースにその値を記録できます。そうすれば、ログ解析ソフトウェアは違いを認識しません（テールを調整するときにも違いを認識しません）。
すべてにトレードオフがあり、セットアップについて十分に理解していませんが、ha-proxy、nginx、およびニスのトリオが間違っていると、ロードバランシングを移動することをお勧めします。プロキシレイヤーツールに。これにより、SSLの問題が解決されるだけでなく、キャッシュ、コンテンツスイッチング、ヘッダー操作などの新しいオプションが多数提供されます。
いくつかのランダムな考え;）
まず、ファイルベースのセッションデータを使用することに決めた人を撃ちます。ファイルシステムからのデータの読み取り/書き込みが、必要なデータをプルするためにソースに戻るよりも速くなる方法はありません。これは、それについての最悪の方法についてです。
私は個人的に、セッションにデータを保存する方が、必要に応じてデータベースから直接データを取得するよりも優れているという状況を見たことがありません。そうは言っても、memcacheまたは同様のキャッシュ戦略を使用すると、サイトを数百万のユーザーに拡張できる場所を見てきましたが、それはセッションを使用するのと同じボールパークでもありません。
次に、セッションをまったく使用しない最大の理由である負荷分散を見つけました。参考までに-スティッキーはスタックを意味するものではありません。スティッキーセッションがオンになっている場合でも、アプリの使用中にユーザーが別のサーバーにシャッフルされる可能性が非常に高くなります。これは、最も不適切な時期に発生します。スティッキーとは、ロードバランサーがtryでユーザーを起動したサーバーにプッシュバックすることを意味しますが、これは保証ではありません。
この点は通常、人々をデータベースにセッションを保存するように導きます...これは完全であると私は信じています失敗。セッションが機能するためには、各ページリクエストでセッションをロードして書き込む必要があります。データベースに保存する場合（負荷分散サーバーに必要）、これには2つのサーバークエリが必要です。1つ目はデータを取得し、2つ目は更新を書き込みます。
失敗する部分は、人々は通常セッションを使用するため、ユーザー名などを取得するためにデータベースに戻る必要がないことです...しかし、ページがセッションをロードするためにデータベースにクエリを実行する必要がある場合は...まあ、ここでロジックの問題を確認できるはずです。
セッションの場合はさらに悪いことになります...ページプロセッサは、ページのライフサイクルの最後にセッションデータをデータベースに書き戻す必要があるためです。何かが変更された場合に備えて。つまり、そのユーザーの名前を取得するための1つのクエリではなく、2つになります。単一ページの読み込みごと。さらに、それ自体のパフォーマンスに影響を与えるデータのシリアル化と逆シリアル化を意味します。
私のポイントは、セッションは悪であり、通常はセッションがない方が良いということです。 1つのWebサーバーでのみ実行されるトラフィックの少ないサイトでは、パフォーマンスを向上させる必要はありません。また、Webファームで実行されているトラフィックの多いサイトは、そのためスケーリングが制限されています。
フロントでHaproxyを使用する代わりに、ラウンドロビンDNSを使用して複数のSSLデコーダー間で大まかなバランシングを実行し、それをhaproxyに渡して適切なロードバランシングを行うことができます。