水平方向にスケーラブルなソフトウェアロードバランサーがsslを分散する例がないのはなぜですか？

ssl、ローカルセッション、および負荷分散に関して、相互に関連していると思われる質問がたくさんあります。そのため、この質問については、事前にお詫び申し上げます。

ファイルベースのセッションを使用するWebサイトがあります。サイトの性質はほとんどがhttpですが、一部のセクションはsslです。現在、ファイルベースのセッションのため、sslリクエストは以前のhttpリクエストと同じサーバーにヒットする必要があります。

時間の制約のため、増加したhttpおよびsslトラフィックの負荷を分散するために、可能な限り簡単なことをしたいと考えています。

スティッキーロードバランシングアルゴリズムには2つのオプションがあるようです。

• IPベース
• クッキーベース

IPベースのソリューションはおそらく機能しますが、ハッシュアルゴリズムは、サーバーがダウンしたり追加されたときにユーザーが移動するサーバーを変更する可能性があります。これは、現在のファイルベースのセッション設定では望ましくありません。また、ユーザーがWebサイトを閲覧しているときに、IPを合法的に変更することは技術的には可能だと思います。

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 |    
     + ----- + + --- + + --- + + --- + + --- +    
     Apache 4の安価なWebサーバー
     mod_ssl
     ハプロキシ 

上記の例のsslデコード部分は、水平方向にスケーラブルではない潜在的なボトルネックのようです。

私はhaproxyを見ました、そしてそれはあなたが複数のsslデコーダを持つことを可能にするこのような何かを可能にする 'mode tcp'オプションを持っているようです：

              ハプロキシ
                 |
            -------------
            | |
ssl-decoder-1 ssl-decoder2
            | |
        -------------------
        | | |  
      web1 web2 web3

ただし、そのような設定では、haproxyがsslをデコードしていないため、クライアントIPが失われるようです：https ://cloud-support.engineyard.com/discussions/problems/335-haproxy-not-passing-x-forwarded -ために

私もnginxを見てきましたが、水平方向にスケーラブルなsslデコーダーの明示的な例も見ていません。潜在的なボトルネックとしてnginxを持つ人々の多くの例があるようです。そして、少なくともこのリンクは、nginxが「TCP接続をバッ​​クエンドに透過的に渡すことをサポートしていない」と言ってIPを失うような、proxyのような設定のオプションさえないことを示唆しているようです。Apacheを渡す方法nginxプロキシを介したSSLトラフィック？。

質問：

• 増加したトラフィックに対処するために、より多くのsslデコーダーを追加するセットアップの例が他にないように思われるのはなぜですか？
• これは、sslのデコード手順が理論上のボトルネックにすぎないためであり、実際には、1つのデコーダーで、とんでもないトラフィックがあるサイトを除いて、基本的に十分でしょうか？
• 頭に浮かぶもう1つの考えられる解決策は、sslの必要性が高まっている人は、中央のセッションストアも持っているため、クライアントが連続するリクエストでどのWebサーバーにヒットするかは関係ありません。次に、すべてのWebサーバーでmod_sslまたは同等のものを有効にします。
• 上記のhaproxyソリューションは（クライアントIPの問題以外に）機能しているように見えますが、クライアントIPを維持しながらデコーダーの数を増やすことで機能する、粘着性のあるCookieベースのソフトウェアロードバランサーソリューションに出くわすか、技術的にはそうではない可能性があります。可能（クライアントIPを取得するにはリクエストをデコードする必要があるため、この場合、デコーダーのボトルネックが発生します）。

私が言ったことすべてが真実であると仮定すると、これらは私の選択肢のようです：

• IPハッシュを使用します（IPを正当に変更する可能性のあるユーザー、およびサーバーの追加と削除のシナリオには不適切です）
• nginxまたはmod_sslを、ssl要求に触れる最初のプログラムとして使用します。これは、潜在的なsslデコードのボトルネックになります。
• ssl要求に触れる最初のプログラムとしてhaproxyを使用し、水平方向のsslスケーラビリティーを獲得しますが、ssl要求のWebサーバーレベルでログに記録されたIPはありません（おそらく一時的にOK）
• 長期的には、モバイルまたは集中型のセッションストアに移行し、スティッキーセッションを不要にします

「最も簡単なこと」は、真剣に言えば、集中型セッションストアに移動することです。ロードバランサー、haproxy、SSL、およびその他の部分を使用して、このすべての配管をセットアップする必要があります。これまでに見たセッション処理コードのすべてのビットで、さまざまなストレージエンジンを接続するのは簡単です。少しのコードと非常に少ない複雑さですべての問題を解決します。

wombleは、共有されたセッションストアがあらゆる面で非常に簡単になることについて正しいです。彼の回答に加えて、質問の負荷分散部分について少し詳しく説明します。

増加したトラフィックに対処するために、より多くのsslデコーダーを追加するセットアップの例が他にないように思われるのはなぜですか？

最新のマルチコアPCは、 1秒あたり数千の SSLトランザクションを実行できます。そして、それがボトルネックになる場合は、F5、Citrix、Ciscoなどの専用アプライアンスがさらに高速になる可能性があります。そのため、ほとんどのサイトが、優れた単一デバイスのSSLおよび負荷分散ソリューションを超えることはありません。

私が言ったことすべてが真実であると仮定すると、これらは私の選択肢のようです：

SSL復号を必要に応じて水平方向にスケーリングするオプションがあります。

一般的なアプローチは、DNSラウンドロビンを使用して高可用性のSSLアクセラレータペアを作成することです。つまり、ドメインの複数のIPアドレスを発行し、各IPアドレスはSSLアクセラレータのペアを指します。

この場合、ユーザーセッションの途中でDNS TTLタイムアウトが発生し、ユーザーが別のアプリケーションサーバーにぶつかることを心配する必要があります。これはよくあることではありませんが、発生する可能性があります。共有セッションストアは一般的なソリューションですが、他の方法で処理することもできます。

1つの例として、SSL復号化をアプリケーションサーバーの分散から分離できます。SSL処理は、基本的なロードバランシングよりもCPUに負荷がかかるため、単一のロードバランサーでいくつかの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サーバーから作成されます）。だからあなたのリクエストは少し前のことで、実装は追いついたようです:-)

ここではウォンブルとジェスパーに同意します。最も簡単で最良の方法は、コードを修正することです。もちろん、システム管理者にはそのオプションがないことがよくありますが、その場合でも、本当に水平ではないにしても、比較的安価な最新のハードウェアを十分に拡張するために利用できるトリックがあります。

client-ipを失うことについて心配している場所についてコメントを投稿したかっただけです。主要なL7 /プロキシソリューションのいずれでも、リクエストにX-Forwarded-For（または必要なもの）ヘッダーを挿入できます。次に、リクエストを受信するバックエンドウェブサーバーで、ログファイルの形式を変更して、layer3クライアントIPのログに使用したファイルの同じスペースにその値を記録できます。このようにして、ログ解析ソフトウェアは違いを認識しません（また、テールの場合も違いはありません）。

すべてにはトレードオフがあり、セットアップについては十分な情報がありませんでしたが、ha-proxy、nginx、varnishのトリオを間違えると、負荷分散を移動することをお勧めしますプロキシ層ツールに。これにより、sslの問題が解決されるだけでなく、キャッシング、コンテンツの切り替え、ヘッダー操作などの新しいオプションが多数提供されます。

いくつかのランダムな考え;）

まず、ファイルベースのセッションデータを使用することに決めた人を撃ちます。ファイルシステムからのデータの読み取り/書き込みが、ソースに戻って必要なデータをプルするよりも高速になる方法はありません。これは、最悪の方法についてです。

個人的には、セッションにデータを保存する方が、必要に応じてデータベースから直接プルするよりも良い状況を見たことがありません。そうは言っても、memcacheまたは同様のキャッシュ戦略を使用すると、サイトが数百万のユーザーに拡大するのに役立つ場合がありますが、それはセッションを使用する場合と同じことではありません。

次に、セッションをまったく使用しない最大の理由である負荷分散を見つけました。FYI-スティッキーはスタックを意味しません。スティッキーセッションがオンになっていても、アプリの使用中にユーザーが別のサーバーにシャッフルされる可能性が非常に高くなります。これは、最も都合の悪いときに起こります。スティッキーとは、ロードバランサーがユーザーを開始したサーバーにプッシュしようとすることを意味しますが、それが保証されるわけではありません。

この点は通常、人々をセッションをデータベースに保存するように導きます...これは完全な失敗だと私は思います。セッションが機能するためには、ページ要求ごとにロードして書き込む必要があります。データベースに格納されている場合（負荷分散サーバーに必要）、2つのサーバークエリが必要です。1つはデータを取得するため、2つ目は更新を書き込むためです。

失敗する部分は、ユーザーが通常セッションを使用するため、ユーザー名などを取得するためにデータベースに戻る必要がないことです...しかし、ページがデータベースを照会してセッションをロードする必要がある場合は...ここでロジックの問題を確認できるはずです。

セッションではさらに悪いことです...ページプロセッサは、ページライフサイクルの最後にセッションデータをデータベースに書き戻す必要があるためです。つまり、そのユーザーの名前を取得するための1つのクエリではなく、2つのクエリになります。すべての単一ページの読み込み。さらに、それ自体がパフォーマンスに影響を与えるデータのシリアライズとデシリアライズを意味します。

私のポイントは次のとおりです。セッションは邪悪であり、通常はそれなしでうまくいきます。1つのWebサーバーでのみ実行されるトラフィックの少ないサイトでは、発生する可能性のあるパフォーマンスの向上は必要ありません。Webファームで実行されているトラフィックの多いサイトは、そのためスケーリングが制限されています。

フロントでHaproxyを使用する代わりに、ラウンドロビンDNSを使用して、複数のSSLデコーダー間で大まかなバランシングを行い、適切なロードバランシングのためにそれをhaproxyに渡すことができます。