Creato da pastuweb.com
Share My Page
My Social Accounts
Account FaceBook Account LinkedIn Account Twitter Account Google Plus Account Git Hub
Load balancing is a technique to distribute load on multiple systems. The first level of load balancing is done by the hardware load balancer. The hardware load balancer distributes load among Apache Web Servers.
The second level of load balancing is done by Apache web servers. Each Apache web server performs the role of software load balancer and distributes load among Liferay Portal application servers.
 
 
Setting Liferay Portal nodes
We need to configure two Liferay Portal server nodes. We will refer to both Liferay Portal servers as liferay-node-01 and liferay-node-02 respectively.
 
On liferay-node-01:
create a directory named node-01 in the root directory, and then extract the Liferay Portal 6.1 GA2 bundle in it.
Similarly on liferay-node-02:
create a directory name, node-02, and extract the Liferay Portal bundle in it.
 
Create a new database schema in the MySQL Database (for example)
 
create database lportal character set utf8;
 
Now create the portal-ext.properties file in the:
node-01\ liferay-portal-6.1.1-ce-ga2 directory
node-02\ liferay-portal-6.1.1-ce-ga2 directory
 
 
with the following content:
jdbc.default.driverClassName =com.mysql.jdbc.Driver
jdbc.default.url = jdbc:mysql://< MySQL Database Server IP >/ lportal?useUnicode = true& characterEncoding = UTF-8& useFastDateParsing = false
jdbc.default.username = < MySQL Database User Name >
jdbc.default.password = < MySQL Password >
 
We are implementing horizontal scaling as both the Liferay Portal nodes are on separate servers. But suppose we want to implement vertical scaling by installing both the Liferay Portal nodes on the same server, we will need to make sure that unique ports are used for both the Liferay Portal nodes. For the Liferay Portal Tomcat bundle, ports can be configured in server.xml.
Software Load Balancer configuration using the Apache Web Server
We need to configure the Apache Web Server to connect with both the Liferay Portal nodes and also distribute the load on both the Liferay Portal nodes. The Apache Web Server provides many options to connect with the Liferay Portal Tomcat server. But there are three options which are more popular.
 
using mod_jk
 
This option allows us to configure the load balancer using the mod_jk module of the Apache Web server. Internally, the mod_jk module connects with the Liferay Portal Tomcat server using the AJP protocol. Using this option, the Apache Web Server distributes all requests on the AJP port of Liferay Portal Tomcat servers.
 
1. Download and copy the mod_jk module in the < APACHE_HOME >/ modules directory.
2. Create a new file called mod_jk.conf in the < APACHE_HOME >/ conf directory, and add the following configuration into it:
LoadModule 
jk_module modules/mod_jk.so
JkWorkersFile /etc/httpd/conf/workers.properties
JkShmFile /var/log/httpd/mod_jk.shm
JkLogFile /var/log/httpd/mod_jk.log
JkLogLevel info JkLogStampFormat "[% a %b %d %H:% M:% S %Y] "
JkMount /* loadbalancer
 
3.Now edit the httpd.conf file located in the < APACHE_HOME >/ conf directory, and add the following line at the bottom:
Includemod_jk.conf
4. Add a new file called worker.properties in the < APACHE_HOME >/ conf directory, and add the following lines into it:
 
#Name of the load balancer workers
worker.list = loadbalancer
#Worker configuration for liferay-node-01
#AJP Connector port of node-01 on liferay-node-01 server
worker.node-01.port = 8009
worker.node-01.host = < IP of liferay-node-01 server >
worker.node-01.type = ajp13
#Factor which decides the load sharing by this worker in the cluster
worker.node-01. lbfactor = 1
#Worker configuration for liferay-node-02
worker.node-02.port = 8009
worker.node-02.host = < IP of liferay-node-02 server >
worker.node-02.type = ajp13
worker.node-02.lbfactor = 1
#load balancer configuration properties
worker.loadbalancer.type = lb
#list of worker nodes that are part of the cluster
worker.loadbalancer.balance_workers = node-01, node-02
worker.loadbalancer.sticky_session = 1
worker.loadbalancer.method = B
 
5. Now edit the server.xml file of liferay-node-01 located in node-01\liferay-portal-6.1.1-ce-ga2\tomcat-7.0.27\conf, and add the jvmRoute attribute to the <Engine> tag as given here:
 
< Engine defaultHost ="localhost" name ="Catalina" jvmRoute ="node-01" >
 
6. Similarly, add the jvmRoute parameter in server.xml of liferay-node-02. Here the value of jvmRoute will be node-02.
 
7. We are ready to test our configuration. Restart both the Liferay Portal nodes and the Apache Web Server to test the configuration. We can access Liferay Portal directly by using the http:// < Apache Web Server IP > URL.
 
We configured the load balancer method to Busyness (B) which means, the load balancer will distribute the requests depending upon the load on Liferay Portal Tomcat servers. Other possible load balancer methods include By Requests (distributes the load based on the number of requests and load factor of the worker) and By Traffic (distributes load based on the traffic in bytes and load factor).
Finally, we enabled session stickiness. Session stickiness is used to distribute all the requests for a specific session to a specific Liferay Portal Server node. Only in case of failure of the specific node, subsequent requests will be served by the other node.
 
In order to make sure the sticky session functionality works fine, we configured jvmRoute in both the Tomcat nodes with unique values. The Apache Web Server appends jvmRoute in the session ID and based on the jvmRoute value, the Apache Web Server can ensure sending requests to the right Liferay Portal Tomcat node.
 
using mod_proxy_ajp
 
Another way to configure the software load balancer using Apache Web Server is through the mod_proxy_ajp and mod_proxy_balancer modules. This is a newer approach introduced in Apache Web Server 2.2. It uses the mod_proxy module and connects the Liferay Portal server using the AJP protocol.
 
1. Create a new file called mod_proxy_ajp.conf in the < APACHE_HOME >/ conf directory, and add the following content:
 
 
LoadModuleproxy_modulemodules/mod_proxy.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule proxy_balancer_module /modules/mod_proxy_balancer.so
 
2. In the same file, add the following configuration settings:
 
< VirtualHost *: 80 >
ServerName localhost.localdomain
ErrorLog /var/ log/ apache2/ ajp.error.log
CustomLog /var/ log/ apache2/ ajp.log combined
< Proxy *>
AddDefaultCharSet Off
Order deny, allow
Allow from all
</ Proxy >
ProxyPass / balancer:// ajpCluster/ stickysession = JSESSIONID
ProxyPassReverse / balancer:// ajpCluster/ stickysession = JSESSIONID
< Proxy balancer:// ajpCluster >
BalancerMember ajp:// < IP of liferay-node-01 >: 8009 route = node-01
BalancerMember ajp:// < IP of liferay-node-02 >: 8009 route = node-02
ProxySet lbmethod = byrequests
</ Proxy >
</ VirtualHost >
 
3. Now edit the httpd.conf file located in the < APACHE_HOME >/ conf directory, and add the following lines at the bottom:
 
Include mod_proxy_ajp.conf
 
4. Now, edit the server.xml file of liferay-node-01 located in node-01\ liferay-portal-6.1.1-ce-ga2\ tomcat-7.0.27\conf, and add the jvmRoute attribute to the < Engine > tag as shown here:
 
< Engine defaultHost =" localhost" name =" Catalina" jvmRoute =" node-01" >
 
5. Similarly, add the jvmRoute parameter in server.xml of liferay-node-02. Here the value of jvmRoute will be node-02.
 
6. Now restart both the Liferay Portal Servers and the Apache Web server, and test the configuration using the http:// < Apache Web Server IP > URL.
 
using mod_proxy_http
 
This method is very similar to mod_proxy_ajp. The only difference here is the load balancer configuration. Here the Apache Web Server and the Liferay Portal Tomcat server will connect using the HTTP or HTTPS protocol.
 
1. we need to load the necessary modules. Create a new file called mod_proxy_http.conf in the < APACHE_HOME >/ conf directory and add the following content:
 
LoadModuleproxy_modulemodules/ mod_proxy.so
LoadModule proxy_http_module modules/ mod_proxy_http.so
LoadModule proxy_balancer_module /modules/ mod_proxy_balancer.so
 
2. In the same file, add the following configuration settings:
 
< VirtualHost *: 80 >
ServerName localhost.localdomain
ErrorLog /var/ log/ apache2/ http.error.log
CustomLog /var/ log/ apache2/ http.log combined
< Proxy *>
AddDefaultCharSet Off
Order deny, allow
Allow from all
</ Proxy >
ProxyPass / balancer:// httpCluster/ stickysession = JSESSIONID
ProxyPassReverse / balancer:// httpCluster/ stickysession = JSESSIONID
< Proxy balancer:// httpCluster >
BalancerMember http:// < IP of liferay-node-01 >: 8080 route = node-01
BalancerMember http:// < IP of liferay-node-02 >: 8080 route = node-02
ProxySet lbmethod = byrequests
</ Proxy >
</ VirtualHost >
 
3. Now edit the httpd.conf file located in the < APACHE_HOME >/ conf directory and add the following line at the bottom:
Include mod_proxy_http.conf
 
4. Now edit the server.xml file of liferay-node-01 located in node-01\ liferay-portal-6.1.1-ce-ga2\ tomcat-7.0.27\conf, and add the jvmRoute attribute to the < Engine > tag as follows:
< Engine defaultHost =" localhost" name =" Catalina" jvmRoute =" node-01" >
 
5. Similarly, add the jvmRoute parameter in server.xml of liferay-node-02. Here the value of jvmRoute will be node-02.
 
6. Now restart both the Liferay Portal Servers and the Apache Web server and test the configuration using the http:// < IP of Apache Web Server > URL.
 
  • The software load balancer configuration using mod_jk is most recommended. It gives the best performance.
  • The mod_proxy_ajp module is similar to mod_jk but it is relatively new. If there is a need to use a secured connection between the Apache Web Server and Liferay Portal Tomcat server, we can consider using the mod_proxy_http module.
  • None of the connectors use both the connectors at the same time. The Liferay Portal Tomcat server, by default, enables both the connectors. It is a best practice to disable the connector which we are not using. This can save resources on the Liferay Portal application server. We can disable any of the connectors by commenting the respective < Connector > tag from the server.xml file of the Liferay Portal Tomcat server.
 
 
To set up a cluster of Liferay Portal Server nodes, we need to ensure all shared resources are either centralized or replicated.
 
Session replication configuration
For every user conversation, a web session object is created and managed by the Liferay Portal application server.
In a clustered environment, it is possible that subsequent user requests are served by different Liferay Portal nodes. So, it is very important to make sure that the same session object is available on all clustered nodes.
 
Session replication is a technique to replicate the session information across all the nodes.
We can ensure automatic recovery after the failover of any node.
 
In our load balancer configuration, we configured session stickiness which ensures all requests related to the same user session are served through a specific node.
Suppose that node goes down; in this case, the load balancer sends subsequent requests to another node in the cluster. If the new node does not have the session information of the same user, it considers it as a new session and in this situation the user will be logged out of the system. With the help of session replication, we can avoid this situation and ensure transparent switching between nodes.
 
1. Stop the Liferay Portal nodes
2. Edit the server.xml file of liferay-node-01 located in node-01\ liferay-portal-6.1.1-ce-ga2\ tomcat-7.0.27\conf, and add the following configuration inside the <Engine> tag:
 
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster" channelSendOptions="6"> 
<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 ="5000" selectorTimeout ="100" 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"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/ >
</Channel>
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve" filter =".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;"/ >
<Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/ >
<ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/ >
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/ > 
 
</ Cluster >
3. Edit the web.xml file of liferay-node-01 located in node-01\ liferay-portal-6.1.1-ce-ga2\ tomcat-7.0.27\ webapps\ ROOT\ WEB-INF and at the bottom of the file before the </ web-app > tag, add the following content:
< distributable/ >
4. Now repeat steps 2 and 3 on liferay-node-02.
5.Restart both the Liferay Portal nodes.
 
We have used IP multicast to connect both the Tomcat servers. Once both the nodes connect with each other, they establish a set of sender and receiver socket channels. The session replication data is transferred using these channels.
 
The Application Server does not replicate sessions of any application unless the application is enabled for session replication. So, we enabled session replication for the Liferay Portal application by adding the < distributable > tag in web.xml.
 
Session replication is not a mandatory requirement for cluster configuration. Session replication consumes lots of server and network resources. So if there is not a real need to handle transparent failover, it is advisable to avoid session replication.
 
Cache replication configuration
Liferay Portal, by default, uses the Ehcache caching framework for caching persistence and service layer resources. It caches resources in memory and the filesystem.
 
In the clustered environment, each Liferay Portal node will have its own copy of the cache. It is very important to invalidate or replicate the cache on all the Liferay Portal nodes if the cache is invalidated or updated on any of the nodes.
 
Replication using RMI (Remote Method Invocation)
It is the default implementation for replication. The RMI-based replication works on the TCP protocol. Cached resources are transferred using the serialization and deserialization mechanism of Java. It generates a lot of network traffic between clustered nodes. Each node will connect to other nodes in the cluster and send cache replication messages.
 
1. Stop both the Liferay Portal nodes
2. Add the following properties to the portal-ext.properties file of both the Liferay Portal nodes:
 
net.sf.ehcache.configurationResourceName =/ehcache/ hibernate-clustered.xml
net.sf.ehcache.configurationResourceName.peerProviderProperties =peerDiscovery=automatic,multicastGroupAddress = ${multicast.group.address["hibernate"]}, 
multicastGroupPort= ${multicast.group.port[" hibernate"]}, timeToLive = 1
ehcache.multi.vm.config.location =/ehcache/ liferay-multi-vm-clustered.xml
ehcache.multi.vm.config.location.peerProviderProperties = peerDiscovery = automatic, multicastGroupAddress = ${multicast.group.address[" multi-vm"]},
multicastGroupPort = ${multicast.group.port[" multi-vm"]}, timeToLive = 1
multicast.group.address[" hibernate"] = 233.0.0.4
multicast.group.port[" hibernate"] = 23304
multicast.group.address[" multi-vm"] = 233.0.0.5
multicast.group.port[" multi-vm"] = 23305
 
3. Now restart both the Liferay Portal nodes.
 
Liferay Portal uses two separate Ehcache configurations for the hibernate cache and the Liferay service layer cache. Liferay ships with two different sets of configuration files for each hibernate and service layer cache. By default, it uses the non-replicated version of the cache file. Using the portal-ext.properties file, we can tell Liferay to use the replicated cache configuration file.
 
Replicated Ehcache configuration files internally use IP multicast to establish the RMI connection between each Liferay node.
 
Replication using JGroups
JGroups is a powerful framework used for multicast communication. The Ehcache framework also supports replication using JGroups.
 
1. Stop both the Liferay Portal nodes
2. Add the following properties to the portal-ext.properties file of both the Liferay Portal nodes:
 
ehcache.multi.vm.config.location =/ ehcache/ liferay-multi-vm-clustered.xml
ehcache.multi.vm.config.location.peerProviderProperties=connect=UDP(mcast_addr=multicast.group.address["hibernate"];
mcast_port=multicast.group.port["hibernate"];):
PING:MERGE2:FD_SOCK:VERIFY_SUSPECT:pbcast.NAKACK:UNICAST:pbcast.STABLE:FRAG:pbcast.GMS
ehcache.bootstrap.cache.loader.factory = com.liferay.portal.cache.ehcache.JGroupsBootstrapCacheLoaderFactory
ehcache.cache.event.listener.factory = net.sf.ehcache.distribution.jgroups.JGroupsCacheReplicatorFactory
net.sf.ehcache.configurationResourceName =/ ehcache/ hibernate-clustered.xml
net.sf.ehcache.configurationResourceName.peerProviderProperties = peerDiscovery = connect = UDP( mcast_addr = multicast.group.address[" multi-vm"]; 
mcast_port = multicast.group.port[" multi-vm"];):
PING: MERGE2: FD_SOCK:VERIFY_SUSPECT:pbcast.NAKACK:UNICAST:pbcast.STABLE:FRAG:pbcast.GMS
multicast.group.address[" hibernate"] = 233.0.0.4
multicast.group.port[" hibernate"] = 23304
multicast.group.address[" multi-vm"] = 233.0.0.5
multicast.group.port[" multi-vm"] = 23305
 
3. Now restart both the Liferay Portal nodes.
 
We used the UDP protocol to connect Liferay Portal nodes. With this option both Liferay Portal nodes also connect with each other using IP multicast.
 
Replication using Clustr Links (only for Liferay Enterprise)
Internally, this feature uses JGroups to replicate the cache across the network.
 
1. Stop both the Liferay Portal nodes
2. Now deploy the ehcache-cluster-web enterprise plugin on both the Liferay Portal servers.
3. Now, edit portal-ext.properties of both the nodes:
cluster.link.enabled = true
ehcache.cluster.link.replication.enabled = true
net.sf.ehcache.configurationResourceName =/ehcache/ hibernate-clustered.xml
ehcache.multi.vm.config.location =/ehcache/liferay-multi-vm-clustered.xml
4. Now restart both the Liferay Portal nodes.
 
This option centralizes all Ehcache changes at one place and then distributes changes to all the nodes of the cluster. This in turn reduces unnecessary network transfers.
 
 
Media Library replication configuration
Liferay stores the metadata of the Media Library content in the Liferay database, but the actual resources are stored using various repository stores. So, we need to ensure that the Media Library content is stored at a centralized place.
 
The actual media files are stored by default on the filesystem.
 
Differents options:
Using the Advanced File System store
It stores files on the filesystem, but it divides files into multiple directories.
To use this option in a clustered environment, we need to use a Storage Area Network appliance or Network File System.
We need to mount the storage SAN or the NFS directory on both the Liferay Portal nodes.
 
1. Stop both the Liferay Portal nodes
2. Add the following properties to portal-ext.properties of both the Liferay Portale nodes:
dl.store.impl=com.liferay.portlet.documentlibrary.store.AdvancedFileSystemStore
dl.store.file.system.root.dir=<SAN or NFS dir>
 
3. Now restart both the Liferay Portal nodes.
 
We need to make sure the SAN appliance supports file locking, as multiple nodes will access the filesystem at the same time.
 
Using JCR store
Liferay Portal uses Apache Jackrabbit as JCR implementation.
Jackrabbit provides both filesystem and database storage for the content. By default, the Jackrabbit configuration uses filesystem storage. Naother option is to configure Jackrabbit to use the database.
 
But it is preferred DBStore.
 
Using DBStore
New type of repository store in Liferay 6.1.
 
1. Stop both the Liferay Portal nodes
2. Edit portal-ext.properties of both nodes:
dl.store.impl=com.liferay.portlet.documentlibrary.store.DBStore
3. Now restart both the Liferay Portal nodes.
 
Search Indexes replication configuration
Liferay provides a powerful built-in search feature. The default installation uses the Lucene search engine to provide search capability. 
The Lucene search engine stores the index on the filesystem. It is very important to ensure that search indexes are either centralized or replicated across all the nodes.
 
Index storage on Network Storage (SAN)
1. Stop both the Liferay Portal nodes
2. Edit portal-ext.properties of both nodes:
lucene.dir=<SAN based mapped directory>
3. Now restart both the Liferay Portal nodes.
4. Now, access the Portal and sign in using admin user name. Control Panel -> Server Administration -> Rebuild all search indexes
 
Index replication using Cluser Link (only for Liferay Enterprise)
1. Stop both the Liferay Portal nodes
2. Edit portal-ext.properties of both nodes:
cluster.link.enabled = true
lucene.replicate.write = true
3. Now restart both the Liferay Portal nodes.
 
Using Apache Solr search engine instead of Lucene
Unlike Lucene, Solr runs as a separate application. In a clustered environment, Liferay Portal nodes connect to centralize the Solr server to search and index the data.
 
If the Portal application is expected to have a large amount of data written to search indexes, it is advisable to use the Solr search engine instead of other options.
The Solr server provides a master/slave server concept.
 
Quartz jobs replication configuration
There are various features in Liferay which internally use scheduled jobs. 
In a clustered environment, it is very important to ensure that all the nodes are aware about running scheduler jobs.
 
Internally, Liferay Portal uses the Quartz scheduler. Quartz is a very popular open source scheduler engine. Quartz scheduler stores data related to scheduled jobs in the Liferay database. It is possible that multiple nodes start the same job at the same time. This can create havoc (total block). To prevent this situation, you need to configure Quartz for the clustered environment.
 
1. Stop both the Liferay Portal nodes
2. Edit portal-ext.properties of both nodes:
org.quartz.jobStore.isClustered = true
3. From Liferay db, drop all the tables starting with QUARTZ_. Only If Liferay tables are already created.
4. Now restart both the Liferay Portal nodes.