Hybris cluster deployment: The one-stop guide
Published on Dec 5, 2017
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
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
http://169.254.169.254/meta-data (link) could be used for auto-scaling it requires two parameters which
ip which can be automated.
for deploying cluster in UDP unicast method; use below config in
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.
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.