マルチキャストを使用しないTomcatセッション複製

Question

iは、ホスティングプロバイダーでレンタルされた2つの専用ルートサーバーを使用する予定です。これらのマシンはクラスター内でTomcat 6を実行します。 後で追加のマシンを追加する場合-異なるサブネットに配置されるため、マルチキャストでアクセスできる可能性は低いです。

Tomcatをマルチキャストなしで実行できますか？ Tomcat 6クラスタリングのすべてのチュートリアルには、マルチキャストハートビートが含まれています。 SimpleTcpClusterに代わるものはありますか？

またはこの状況で他の選択肢がより適切ですか？

Answer 1

両方のサーバー間の距離を制御せず（2つの異なるデータセンターにある場合があります）、専用のサーバー間通信回線がないため、ラウンドロビンDNSまたはクライアントをいずれかにリダイレクトするロードバランサーを介してそれらを実行しますwww1.yourdomain.xxxまたはwww2.yourdomain.xxxを使用して、サーバー通信を慎重に処理してください。

サーバーが相互に頻繁に通信している場合、アーキテクチャを変更したり、アプリケーションの「フィット」に合わせて最適化したり、 1台のサーバーで（少なくともしばらく）、またはサーバーの場所、距離、ケーブル接続を制御できる専用ホスティングに移動します。それ以外の場合、サーバー間通信、ハートビートなどは、それと通信しているクライアントと同じチャネル（たとえば、同じネットワークセグメント）を使用するため、全員が遅くなる可能性があります。

あなたが本当にそんなに多くの負荷を期待しているなら、少なくともいくらかのお金が関係していると思いますか？賢く使用し、セットアップスキルを使用して、制御ラインや専用回線のない分散クラスタリングを設定するよりも難しい問題に対処します。

Answer 2

他の答えを出した後に質問へのコメントを見るあなたの質問が何であるかについて私は困惑しています...それはセッションの複製に関するものですか？クラスター通信？計画されたソリューション自体に問題があるのではなく、問題を述べる方が良い場合があります。

いくつかの考えられる問題と簡単な答えを述べます：

アプリケーションはCPU / RAMを集中的に使用します

• プロファイリング、最適化、再試行
• より大きな/より良いサーバーを購入する

アプリケーションは帯域幅を集中的に使用します

• あなたの質問で言及したcheapoクラスタリングを使用すると、同じ（クローキングされた）チャネルがクライアント間通信と同じサーバー間通信に使用されるため、おそらく悪化します
• さまざまな種類の帯域幅を分離できる場合があります。静的コンテンツとは異なるサーバーから動的コンテンツを提供することにより、ここでサーバー間通信の必要はありません

アプリケーションはストレージ集約型です

• より大きなサーバーを取得
• 専用ホスティングに行き、必要な数の回転ディスクに収まる
• 他のモデル（amazons S3ストレージなど）が機能するかどうかを確認します）

アプリケーションはスラッシュで区切られている可能性が高い

• 上記の要因（または他の要因）のどれがアプリケーションの制限を決定しているかを判断し、それを修正します。

セッションレプリケーションが必要ですか？

• Tomcats SessionManagerインターフェースは小さく、自分で簡単に実装/拡張できます。任意のセッションレプリケーションに使用します。 StandardManager のドキュメントをご覧ください。および詳細情報の実装

その他のアイデア

• EC2（amazon）、Googleサービス、その他のクラウドコンピューティングのセットアップなど、より柔軟なセットアップをご覧ください。独自のクラウドストレージとサーバー間通信機能を使用します。このインフラストラクチャに依存しすぎないように注意してください。

確かに何かを忘れましたが、これは出発点になるかもしれません。より良い答えを得るために、根本的な問題の性質についてより具体的にしてください：）

Answer 3

私はyale Central Authentication Server（CAS）を展開しようとしていますが、これは冗長性のためにクラスター化したいと思います。これはインフラストラクチャの重要な部分だからです。ユーザーがアプリケーションAにログインし、シングルサインオンドメインに参加するアプリケーションBに移動した後、アプリケーションBがユーザーにアクティブな「チケット」があるかどうかを判断するために、CASにリクエストを送信するため、CASではセッションを複製する必要があります。チケットを検証するために自身をアドレス指定するノードをアプリケーションBに示すデバイスがないため、1つのノード内のすべてのアクティブチケットをクラスター内のすべてのノードに複製する必要があります。つまり、アプリケーションのBは、ユーザーのCookie内のチケットを検証するときに、ユーザーがログインしているアプリケーションAの元のセッションのsessionIdを認識しないため、セッションのスティッキ性はここでは解決できません。

したがって、CASでは、すべてのノードでセッションを複製する必要があります。ネットワークがマルチキャストをサポートするという要件により、重要なオーバーヘッドが追加され、このアプローチの展開が少し重くなります。 Googleプロジェクトでこのプロジェクトをテストしました：

http://code.google.com/p/memcached-session-manager

これは非常に便利でデプロイが簡単なようです（少なくともLinux OSでは）が、残念ながらセッションフェイルオーバーのみを提供し、セッションレプリケーションソリューションではありません。

Answer 4

http://code.google.com/p/memcached-sessionを使用するだけ-manager / 。それは素晴らしく機能します。 20台のTomcatサーバーがセッションを共有するこのセットアップに何年も使用しています。セッションレプリケーションを処理するために、1つまたは2つのmemcachedサーバーを使用できます。