Dans cet article


Offres d'emploi

Tags

Clustering TOMCAT et MULTICAST

Clustering TOMCAT et MULTICAST

Prérequis

La première chose  a faire pour réaliser un clustering TOMCAT est bien sur de posséder deux instances de TOMCAT.

Deux cas sont possibles. Vos deux instances sont sur la même machine (ou VM), auquel cas, il faut bien changer les ports d’écoute de vos TOMCAT. (Rappel ceci sont situés dans le fichier server.xml)

Si vous avez deux machines (ou VM) bien distincte, il n’est pas nécessaire de changer le ports d’écoute.

Configuration du cluster

Pour ceci il suffit de rajouter cette instruction dans le fichier server.xml. Vous pouvez lancer les deux instances de TOMCAT et celles-ci vont se trouver. Bien entendu, la configuration du cluster peut aller beaucoup plus loin. Dans la documentation, on peut constater qu’il est possible de faire beaucoup plus de chose comme le montre cette exemple. En particulier spécifier les adresses de multicast.

<
Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
                 channelSendOptions="8">

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

          <
Channel className="org.apache.catalina.tribes.group.GroupChannel">
            <
Membership className="org.apache.catalina.tribes.membership.McastService"
                        address="228.0.0.4"
                        port="45564"
                        frequency="500"
                        dropTime="3000"/>
            <
Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
                      address="auto"
                      port="4000"
                      autoBind="100"
                      selectorTimeout="5000"
                      maxThreads="6"/>

            <
Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
              <
Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
            <
/Sender>
            <
Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
            <
Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
          <
/Channel>

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

          <
Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
                    tempDir="/tmp/war-temp/"
                    deployDir="/tmp/war-deploy/"
                    watchDir="/tmp/war-listen/"
                    watchEnabled="false"/>

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

De facto l’adresse de MULTICAST peut poser problème si vous avez deux machines séparées sur un réseau (ou VM). De base sur Debian (cas ou vous avez plusieurs interfaces) par exemple la route n’existe pas et les deux instances de TOMCAT ne se verront pas sur le réseau. Pour pallier ce problème, il faut rajouter la route comme ceci:

route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0

Ainsi les deux TOMCAT pourront se trouver à travers le réseau et votre CLUSTER de TOMCAT pourra fonctionner correctement.

 

L'équipe AXOPEN

Voir aussi les articles suivants

Le rôle de l’architecture dans les SI

Le rôle de l’architecture dans les SI

Le 13/07/2010 par Pierre Liseron

La comparaison avec le BTP : L’architecte système d’information conçoit l’architecture du système d’information, c’est-à-dire qu’il conçoit les différentes briques du système d’information (SI) et leur imbrication et est chargé de leur évolution. L’architecte système d’information est au système d’information de l’entreprise ce que l’architecte est à son bâtiment, si ce n’est que le système d’information est amené à évoluer plus fréquemment. Pour mener à bien sa mission, l’architecte système d’information doit en premier lieu étudier les besoins du client (sa direction ou bien le client chez qui il est en mission), établir une cartographie du système en analysant l’existant, puis proposer un modèle d’architecture et enfin la mettre en œuvre en choisissant une infrastructure matérielle et logicielle.
Lire l'article

Performances et disponibilités des systèmes distribués
Les systèmes distribués proposent des solutions permettant d’améliorer l’agilité globale du système d’information souhaitée par beaucoup de décideurs, par l’intermédiaire notamment des architectures orientées services (SOA). Ces systèmes permettent aussi de mettre en place des architectures informatiques permettant d’améliorer les performances ainsi que la disponibilité des systèmes informatiques. Cette étude s’attachera à aborder uniquement l’aspect performances et disponibilité des systèmes distribués par l’intermédiaire de l’analyse des architectures sous-jacentes. Nous verrons ainsi les avantages de ce type de système mais aussi les difficultés rencontrées lors de leur mise en œuvre.
Lire l'article