June 2020
M T W T F S S
« Mar    
1234567
891011121314
15161718192021
22232425262728
2930  

Categories

WordPress Quotes

Be Content with what you have; rejoice in the way things are. When you realize there is nothing lacking, the whole world belongs to you.
Lao Tzu
June 2020
M T W T F S S
« Mar    
1234567
891011121314
15161718192021
22232425262728
2930  

Short Cuts

2012 SERVER (64)
2016 windows (9)
AIX (13)
Amazon (40)
Ansibile (19)
Apache (135)
Asterisk (2)
cassandra (2)
Centos (211)
Centos RHEL 7 (270)
centos8 (3)
chef (3)
cloud (2)
cluster (3)
Coherence (1)
DB2 (5)
DISK (25)
DNS (9)
Docker (30)
Eassy (11)
ELKS (1)
EXCHANGE (3)
Fedora (6)
ftp (5)
GIT (3)
GOD (2)
Grub (1)
Hacking (10)
Hadoop (6)
health (2)
horoscope (23)
Hyper-V (10)
IIS (15)
IPTABLES (15)
JAVA (7)
JBOSS (32)
jenkins (1)
Kubernetes (7)
Ldap (5)
Linux (188)
Linux Commands (166)
Load balancer (5)
mariadb (14)
Mongodb (4)
MQ Server (24)
MYSQL (84)
Nagios (5)
NaturalOil (13)
Nginx (35)
Ngix (1)
openldap (1)
Openstack (6)
Oracle (35)
Perl (3)
Postfix (19)
Postgresql (1)
PowerShell (2)
Python (3)
qmail (36)
Redis (12)
RHCE (28)
SCALEIO (1)
Security on Centos (29)
SFTP (1)
Shell (64)
Solaris (58)
Sql Server 2012 (4)
squid (3)
SSH (10)
SSL (14)
Storage (1)
swap (3)
TIPS on Linux (28)
tomcat (62)
Ubuntu (1)
Uncategorized (30)
Veritas (2)
vfabric (1)
VMware (28)
Weblogic (38)
Websphere (71)
Windows (19)
Windows Software (2)
wordpress (1)
ZIMBRA (17)

WP Cumulus Flash tag cloud by Roy Tanck requires Flash Player 9 or better.

Who's Online

0 visitors online now
0 guests, 0 bots, 0 members

Hit Counter provided by dental implants orange county

Clustering Tomcat Server

Clustering Tomcat Server
A cluster of two Tomcat is a more Tomcats that are hosted in the same Java application. The main function of cluster Tomcat is to perform replication of open sessions in each cluster of Tomcat, so Tomcat each contain their sessions and their attributes, as well as the attributes of the other sessions and Tomcats. Each Tomcat cluster is called a node.

With the Tomcat cluster can achieve high availability, so that if a cluster node fails, the requests coming to this node are forwarded to another active node. All this without the user noticing, because your session is active on other cluster nodes.

The figure below shows the architecture of the cluster of Tomcat:

 

 

Tomcat cluster configuration
I will take into consideration that you have two instances of Tomcat, Apache and Java installed on your server. Below is a description of the environment that will be used in this small project, it is worth remembering that it is only a test project:

Two instances of virtual machines in VirtualBox;
Each VM with 512MB RAM and 8GB HD;
Each VM operating system with CentOS 5.7 (Final).

Note: This configuration can be performed on any Linux server.

requirements:

To perform the replication sessions between nodes in the cluster a few points should be checked:

All session attributes must implement java.io.Serializable;
Having the application web.xml <distributable/> the attribute or set a property in the context of the application configuration file server.xml;
Configure the load balancer with sticky session option active, to keep the same user requests a system going to the same cluster node, except when this node fails.

Starting the configuration:

The configuration of the Tomcats to the cluster is made from editing the server.xml file, located in the conf (<product the tomcat> / conf / server.xml) for each Tomcat.

What should be done is uncomment the whole tag and add cluster configuration adapting the parameters to the hosting environment. Just below the cluster configuration:

 

<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>  

 

In each Tomcat cluster have the same tag with a small difference in the configuration:

 

 

 

we have to identify each node in the same file “server.xml”. In Tomcat The Tomcat and B will need to make some changes to the nodes can communicate:

 

 

Note: Changes are highlighted in bold, but these changes are an example of configuration, not necessarily have to use these same values, can be done with other values.After making these settings, simply start the Tomcats that they begin to replicate its sessions, or begin working on the cluster.To start the Tomcats just enter the directory bin / in each Tomcat and run the following command:

sh startup.sh
Load Balancing
he service is able to forward requests to multiple servers within a cluster, so that each cluster node is not overloaded, thus ensuring the use level of all computing resources within the cluster.In this project, the Apache will be responsible for balancing the load between two Tomcats. Apache will receive the requests coming from the customer and by the amount of requests sent to each Tomcat, it will be transferred to each of them.The figure below shows the architecture of Tomcat cluster with load balancing:

Configuring the Load Balancer
As was said in previous posts, responsible for load balancing Apache. To do this using Apache mod_proxy and mod_proxy_balancer. With mod_proxy Apache works as a proxy FTP, HTTP and SSL. Mod_proxy_balancer already provides a service load balancing for HTTP, FTP and ajp13. The mod_proxy_balancer depends on the use of mod_proxy.Currently there are two methods of load balancing:For quantities of requests, where each cluster node will receive a request at a time so that none of us get overwhelmed.
For traffic, where a dedicated balancer cluster node to which the request for travel on much information while the other requests will be sent to other servers.

The scenario will be where the cluster configuration will be described below:

Server IP = 192.168.56.101
Application to be used in this example is a system to ask for lunch which was developed at the company I work. The system is jBroca.

The configuration of the load balancer will be made in the configuration file of the Apache “httpd.conf”. In CentOS Apache configuration file is located inside the / etc / httpd / conf /.

Insert this at the end of httpd.conf:

<VirtualHost 192.168.56.101:80>
ServerName 192.168.56.101
ProxyRequests Off<Proxy 192.168.56:80>
Order deny,allow
Allow from all
</Proxy>ProxyPass /teste balancer://balancer lbmethod=byrequests stickysession=JSESSIONID nofailover=off
ProxyPassReverse /teste http://192.168.56.101:8080/jbroca
ProxyPassReverse /teste http://192.168.56.101:8081/jbroca

<Proxy balancer://balancer>

BalancerMember http://192.168.56.101:8080/jbroca route=node01 loadfactor=1
BalancerMember http://192.168.56.101:8081/jbroca route=node02 loadfactor=1

</Proxy>

<Location /balancer-manager>

setHandler balancer-manager
Order Deny,Allow
Deny from all
Allow from 192.168.56.101

</Location>

</VirtualHost>

In this section we setup a virtualhost which will be responsible for receipt of requests for the url 192.168.56.101/jbroca. Below is a description of each item in this configuration:ServerName: determines the name of the virtual host, in this case 192.168.56.101/jbroca.
ProxyRequest off: Determines that Apache will not be used as a proxy server or a reverse proxy.
ProxyPass / test balancer :/ / balancer lbmethod = byrequests stickysession nofailover = JSESSIONID = off: any request for use in the context / test will use the load balancer balancer to meet demand.
lbmethod = byrequests: is where you define the type of load balancing, in which case load balancing is per request.
stickysession = JSESSIONID: defines that Apache will direct requests for the same section to the same server.
nofailover = off: defines that all servers within the cluster will be able to overcome the failure of a server cluster that become inactive, the Apache server this will divert requests to another server.The following options are settings used to correct the responses from the servers in the cluster that are balanced, based on the request coming from the client:

ProxyPassReverse / jbroca http://192.168.56.101:8080/jbroca
ProxyPassReverse / jbroca http://192.168.56.101:8081/jbroca

Now is where we declare to the load balancer cluster members and their respective characteristics:

<Proxy Balancer://balancer>
BalancerMember http://192.168.56.101:8080/jbroca route = node01 loadfactor = 1
BalancerMember http://192.168.56.101:8081/jbroca route = node02 loadfactor = 1
</ Proxy>

The last option enables the load balancer management for browsers 192.168.56.101 domain. To view the balancer-manager in the browser just type:

http://192.168.56.101/balancer-manager

<Location /balancer-manager>
SetHandler balancer-manager
Order Deny, Allow
Deny from all
Allow from 192.168.56.101
</ Location>

With this, the Apache is configured to perform load balancing, routing requests to both servers within the cluster.

To test whether all configuration is correct, start the Tomcats and start the Apache server starts correctly, your cluster is working and just access the browser to check if the balancer is working properly. In the example above go to:

http://192.168.56.101/jbroca

Access to different browsers and make sure the balancer is actually directing the requests to each server. In this example that was used, the address bar shows that the requests are balanced:

http://192.168.56.101/jbroca/autenticarUsuario.do; jsessionid = 9225E01A70F0A90B2283244B2CF554D3.node01
http://192.168.56.101/jbroca/autenticarUsuario.do; jsessionid = 4B2BF75B6B2F99EAB791D512E52AC626.node02

The return address shows requests divided in two Tomcats cluster. The balancer-manager also shows that the requests are balanced.

We end here, hope you all have managed to understand what I had to pass. The application will not be available to be used only in the company I work, then the application you develop and test applications running on the cluster.

Thank you all.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  

  

  

Blue Captcha Image
Refresh

*

Protected by WP Anti Spam