(Experimental)
Clustering an OMERO instance consists of starting multiple OmeroBlitz servers with each allocating user sessions based on some criteria. There are at least two reasons one may want to cluster the OMERO server: availability and throughput.
Availability
Having the ability to have two servers up at the same time implies that even if you have to restart one of the servers, there should be no down-time. Currently, OmeroSessions are sticky to a cluster node and so it's not possible shutdown a node at any time, but all new sessions can be redirected to the server which is to be left turned on, then when all active sessions have completed, the chosen server can be shutdown.
Throughput
The other main reason to have other servers running is to service more user sessions simultaneously. Out of the box, each OmeroBlitz process is configured for 400MB of memory. When dealing with memory intensive operations like rendering, each added server can benefit make a difference. This is only a part if the story, since much of the bottleneck is not the server itself but other shared resources like the database or the filesystem, and so to further extend throughput, you will need to parallelize these.
Installation
If you are using the default OmeroGrid application descriptor quickly enabling clustering is as simple as executing:
bin/omero config set omero.cluster.redirector configRedirector bin/omero node backup start
This starts a second node, named "backup", which contains a second OmeroBlitz server, "Blitz-1". By default, this newly created server will not be used until sessions are manually redirected to it.
See also : ScalingOmero
