3

フロントエンドのロードバランサーとしてApacheを使用してubuntuサーバーでテストTomcat Clusteringしました。session replication私のテスト経験から、Tomcat クラスタリングを使用しない方がよいと思いますが、各ノードをスタンドアロンとして実行し、セッション レプリケーションを使用せずにお互いを認識しないようにする方がよいと言えます。速度が遅く、Tomcat サービスの起動に時間がかかり、より多くのメモリを消費すると感じたからです。また、FarmDeployer展開では常に信頼できるとは限らず、構成全体を<Host></Host>要素の下に配置して、ファーム デプロイヤーが機能するようにし、各仮想ホスティングと巨大な server.xml ファイルを配置する必要があります。以下は、私が使用したノードの 1 つからのクラスター構成の tomcat 仮想ホスティングです。

<Host name="site1.mydomain.net" debug="0" appBase="webapps" unpackWARs="true" autoDeploy="true">
<Logger className="org.apache.catalina.logger.FileLogger"
directory="logs" prefix="virtual_log1." suffix=".log" timestamp="true"/>
<Context path="" docBase="/usr/share/tomcat/webapps/myapp" debug="0" reloadable="true"/>

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
<Manager className="org.apache.catalina.ha.session.DeltaManager" 
          expireSessionsOnShutdown="false"
          notifyListenersOnReplication="true"/>

        <Channel className="org.apache.catalina.tribes.group.GroupChannel">
            <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
                  address="192.168.1.8"
                  port="4001"
                  selectorTimeout="100"
                  maxThreads="6"/>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor">
                <Member className="org.apache.catalina.tribes.membership.StaticMember"
                      port="4002"
                      securePort="-1"
                      host="192.168.1.9"
                      domain="staging-cluster"
                      uniqueId="{0,1,2,3,4,5,6,7,8,9}"/>

             <!--   <Member className="org.apache.catalina.tribes.membership.StaticMember"
                      port="4002"
                      securePort="-1"
                      host="192.168.1.9"
                      domain="staging-cluster"
                      uniqueId="{0,1,2,3,4,5,6,7,8,9}"/> -->

            </Interceptor>
        </Channel>
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve" filter=""/>
<Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>

<ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>

  <Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
            tempDir="/usr/share/tomcat/temp/"
            deployDir="/usr/share/tomcat/webapps/"
            watchDir="/usr/share/tomcat/watch/"
            watchEnabled="true"/>
    </Cluster>
</Host>

Tomcat クラスタリングは本番環境での使用に適していますか、それともセッション レプリケーションの別の方法はありますか? または、上記の構成で微調整できるものが欠けていますか?

どんなアイデアでも大歓迎です。ありがとう！

4

1 に答える 1

6

tomcat のセッション フェイルオーバー/セッション レプリケーション ソリューションの 1 つは、スティッキー セッションと非スティッキー セッションの両方をサポートするmemcached-session-manager (msm) です。msm は、セッションのバックアップ/ストレージのバックエンドとしてmemcached (または memcached プロトコルを使用するバックエンド) を使用します。

スティッキー モードでは、セッションは引き続き tomcat に保持され、memcached は追加のバックアップ (セッション フェイルオーバー用) としてのみ使用されます。

非スティッキー モードでは、セッションは memcached にのみ保存され、Tomcat には保存されなくなります。非スティッキー セッションと同様に、セッション ストアは外部にある必要があります (古いデータを避けるため)。

membase / membase bucketsの特別なサポートもあります。これは、適切な認証で特定のバケットにアクセスできるホスト型ソリューションに役立ちます。

セッションのシリアライゼーションはプラグ可能であるため、Java のシリアライゼーション (および Serializable を実装するクラス) に縛られることはありません。たとえば、利用可能な最速のシリアライゼーション戦略の 1 つであるkryo シリアライザーが利用可能です。

msmのホームページでは主にスティッキー セッションのアプローチについて説明しています。非スティッキー セッションの詳細については、メーリング リストで検索または質問してください。

構成に関する詳細と例は、msm wiki (SetupAndConfiguration)にあります。

于 2012-01-31T20:49:08.463 に答える