Hybris Cluster Deployment: The One-Stop Guide

To my surprise something so powerful and in demand was not documented properly for beginners. I  had to jump through a lot of hoops, so here is my effort to provide everything I know about clustering hybris. I have chosen to host this cluster on AWS. for now.

This article will assume you have basic knowledge of hybris and its architecture, later if I find time I will provide more details, which I will brush over right now. so prep the system by uploading Hybris version 6.5 on it, write down b2c extensions in localextensions.xml and in local.properties copy down the below settings.

1clustermode=true  
2cluster.id=0 #change for each node
3cluster.broadcast.method=jgroups
4cluster.broadcast.method.jgroups=de.hybris.platform.cluster.jgroups.JGroupsBroadcastMethod
5cluster.broadcast.method.jgroups.tcp.bind_addr=`aws.private.ip`
6cluster.broadcast.method.jgroups.tcp.bind_port=7800
7cluster.broadcast.method.jgroups.channel.name=hybris-broadcast
8cluster.broadcast.method.jgroups.configuration=jgroups-tcp.xml

the next step is in platform folder, make a file

jgroups-tcp.xml

exec ant command start the server + init.

go in cluster page check if nodes are showing up. Once a proper instance is configured make an ami of it and take the cluster.id and from the environment cluster.broadcast.method.jgroups.tcp.bind_addr and http://169.254.169.254/meta-data (link) could be used for auto-scaling it requires two parameters which cluster.id and ip which can be automated.

for deploying cluster in UDP unicast method; use below config in local.properties files;

1clustermode=true  
2cluster.nodes.autodiscovery=true #if enabled, you wont have to explicitly define cluster node id.
3cluster.broadcast.methods=unicast  
4cluster.broadcast.method.unicast.serveraddress=`aws.private.ip`
5cluster.broadcast.method.unicast.port=9997 #needs to be same in all clusters
6cluster.broadcast.method.unicast.clusternodes= this-node-private-ip:with-above port ; other-node-private-ip:with-same-port ;
7cluster.broadcast.method.unicast.sync.nodes.interval=1 #anything below, will not sync.

That’s it. What I realized is if your cluster is going to handle a blackfriday load, you are better off with jgroups as its faster, but for normal node 3 nodes in unicast with load balancer would suffice. One could use multiple clusters with multiple groups each having their own workload like for example one cluster group handles storefront and 2nd cluster group handles backend activities like cornJobs and indexing, and third cluster group handles back office/admin. But it raises a question does not installing those extensions on other cluster group create DB problems? For example, if storefront extension is not available in cluster group 3 will it create a problem in database models, I feel it should not until or unless some custom extension is deployed However I will have to test thoroughly. To even better understand the difference between different clustering method, I plan on running a detailed jmeter load test. I will publish my results soon with a test case.

log4j.logger.de.hybris.platform.cluster.PingBroadcastHandler=DEBUG

add above for debugging.

Change the required settings of the session as required if nodes in cluster require session replication or you could use few of your nodes for storefront and other nodes with no session replication for back office. I have seen this happen before. For example, one node is for consumers and others for back office/admin. So consumer one will have extensions related to him and not of back office, and vice versa for back office node. When load hits just let auto-scaling handle the consumer end nodes.

as I find time I will try to keep this post updated and differentiate in parts, and explain further.