3

私は、Tomcat 7 または Glassfish 3.1 (おそらく GlassFish ですが、これはまだ決定されていません) のいずれかを使用する Java SE 7 / Java EE 6 アプリケーションに取り組んでいます。このアプリケーションは、最近すべての主要なブラウザで広く採用されている新しい WebSockets テクノロジを利用します。

多くの調査、フォーラムの閲覧、およびメーリング リストの監視を通じて、(現在、AFAICT) mod_jk/isapi_redirect も mod_proxy も WebSocket を確実にサポートしていない (またはまったくサポートしていない) と判断しました。これらは、Tomcat または GlassFish クラスターでトラフィックをロード バランシング/誘導するための 2 つの実証済みの方法であるため、これは明らかに問題を表しています。

一方、Tomcat と GlassFish にはどちらも組み込みの Web サーバーがあり、Apache や IIS と同じくらい効率的に静的コンテンツを提供できると広く宣伝されています。冗長性/負荷分散が必要でない限り、これらのサーバーのいずれか。

したがって、これらすべてが次の質問につながります。

  1. Tomcat/GlassFish クラスターで負荷を分散するために、Apache や IIS はもはや必要ですか? Tomcat または GlassFish サーバーのクラスターの前に、他のシナリオで使用するものと同様に、標準のロード バランサーを単純に配置し、中間の Web サーバーをまったく使用しない方が、同じくらい効率的 (またはそれ以上) ではないでしょうか? それとも、標準のロード バランサーが TC/GF で動作しないという技術的な理由がまだありますか? 標準のロード バランサーを使用できると仮定すると、WebSockets (Coyote など) をサポートするものを簡単に見つけて使用できます。
  2. 標準のロード バランサーが Tomcat/GlassFish で動作しない場合、他にどのようなオプションがありますか? Java EE を使用してパフォーマンスと信頼性の高い WebSocket テクノロジを実現するにはどうすればよいでしょうか?

警告: 私は、ダム ラウンド ロビン プロトコル (ラウンド ロビン DNS など) に限定された負荷分散テクノロジを考慮したくありません。これらのオプションは、クラスター内の別のサーバーよりもはるかに多くの接続を処理しているか、ダウンしているサーバーに簡単に送信される可能性があるため、信頼できる/冗長であるとは考えていません。もちろん、ラウンドロビン DNS のようなものは、互換性を気にせずに WebSocket で簡単に使用できることを知っています。

4

1 に答える 1

3

標準ロードバランサーの直後に Tomcat インスタンスを配置するアプローチを使用する予定でした。セットアップでは SSL を多用しています。ロード バランサーの背後で物事をシンプルに保ち、Web コンテナーで SSL の構成が異なる場合と SSL がない場合を避けるために、ロード バランサーで SSL を終了させたいと考えました。

ただし、ロード バランサーの SSL 復号化ハードウェアにはかなりのバグがありました。したがって、SSL を復号化することのみを目的として、Web コンテナーとロード バランサーの間に Web サーバー (nginx) を配置することになりました。

これは私たちに当てはまった特殊なケースですが、覚えておく価値があります。これ以外に、ロード バランサーと Web コンテナーの間に Web サーバーを配置する理由がわかりません。ロード バランサーは、Web コンテナーで問題なく動作するはずです。シンプルさを目指し、セットアップ内のさまざまなコンポーネントを最小限に抑えます。

于 2012-11-14T19:52:54.553 に答える