4

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

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

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

4

4 に答える 4

3

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

考えられる問題をいくつか、簡単な回答とともに説明します。

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

  • プロファイルし、最適化し、再試行します
  • より大きく/より良いサーバーを購入する

アプリケーションは帯域幅を大量に消費します

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

アプリケーションはストレージを大量に消費します

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

アプリケーションはスラッシュドットである可能性があります

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

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

  • TomcatのSessionManagerインターフェースは小さく、自分で簡単に実装/拡張できます。好きなセッションレプリケーションに使用します。詳細については、StandardManagerのドキュメントと実装を参照してください。

その他のアイデア

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

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

于 2008-10-03T13:44:52.873 に答える
3

両方のサーバー間の距離を制御できず (2 つの異なるデータセンターにある可能性があります)、専用のサーバー間通信回線がないため、ラウンドロビン DNS またはクライアントを www1.yourdomain にリダイレクトするロードバランサーを介してそれらを実行したいと思います。 .xxx または www2.yourdomain.xxx を使用し、サーバー通信を慎重に処理します。

サーバーが相互に頻繁に通信している場合は、アーキテクチャを変更するか、アプリケーションを最適化して 1 つのサーバーに「適合」するようにするか (少なくともしばらくの間)、場所を制御する専用ホスティングを使用するかのいずれかを検討する可能性があります。サーバーの距離とケーブル接続。そうしないと、サーバー間通信、ハートビートなどで、通信しているクライアントと同じチャネル (同じネットワーク セグメントなど) が使用され、全員の速度が低下する可能性があります。

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

于 2008-10-03T13:20:41.987 に答える
1

イェール中央認証サーバー (CAS) を展開しようとしていますが、これはインフラストラクチャの重要な部分であるため、冗長性のためにクラスター化したいと考えています。ユーザーがアプリケーション A にログインし、シングル サインオン ドメインに参加しているアプリケーション B に移動した後、アプリケーション B は、ユーザーがアクティブな「チケット」を持っているかどうかを判断する要求を CAS に送信するため、CAS はセッションを複製する必要があります。 . チケットを検証するためにどのノードにアドレス指定する必要があるかをアプリケーション B に示すデバイスがないため、1 つのノード内のすべてのアクティブなチケットをクラスター内のすべてのノードに複製する必要があります。つまり、ここではセッション スティッキ性は解決策にはなりません。アプリケーション B は、ユーザーの Cookie 内のチケットを検証するときに、

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

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

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

于 2011-01-17T17:50:17.617 に答える
0

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

于 2013-12-03T09:06:53.447 に答える