There are 2 basic components to what is referred to as Clustering.
- Request Load Balancing between all the peers in the cluster
- ability for peers to share the session scope also called in-memory session replication
Session replication is managed in the <servername>\runtime\conf\server.xml file. The main reason for this file is to define the TCPIP multicast port so all the peers can communicate and know when they are online.
Load Balancing is accomplished using 2 Connector settings files:
- Worker.properties file where the server instances are defined
- URIWorkerMap.properties file is where the load balancing is defined
Note: You do not need any session replication in order to do Tomcat Connector Load Balancing, but as of now if you define a Cluster in ColdFusion you will have both of the above defined for you.
When you define a cluster in ColdFusion Enterprise the administrator will take care of editing all the above files to setup your cluster with the correct settings.
Peers can be local or remote servers.
- Session replication or sticky sessions are not required when the session storage is pointed externally to Redis on each cluster member. Redis was added with ColdFusion 2016 as an alternate way of storing the session scope.
- If using in-memory replication you need to use J2EE Sessions for session replication or sticky sessions. All instances participating in the cluster must use J2EE sessions. Therefore, you will need to go to Server Settings ---> Memory Variables and check "Use J2EE session variables" for each cluster member.
In-memory Session Replication
As I stated above the only reason to use the multicast port setup is for in-memory session replication. This feature works but it still takes time to get all the servers synched for every session variable change on all the cluster peers. I would not recommend this for production servers. The replication creates all kinds of traffic, and you never really know how fast all the sessions are synch'd. If you have a server go down, it is not 100% that it will be a seamless hand-off, which is kind of the point to replicating in the first place.
There are several ways to share session or user info across servers:
- Redis if you have ColdFusion 2016
- Client Scope saved to Database
- Distributed EHCache
- Custom DB call
The easiest approach that is tried and true and does not add much overhead is to simply use the client scope, and have the Client scope defined in the ColdFusion Administrator to be saved to the database.
More advanced solutions like Redis and EHCache are out there but will likely take some time to implements and test.
Tomcat Connector Load Balancing
The load balancing that is defined is typically for instances on the same server, although it can just as easily point to remote instances. If you have a hardware load balancer, like an F5, you probably may not need Connector based load balancing.
The files that control the load balancing are located inside 2 files mentioned above and created when you define your connector.
Important: If you ever upgrade your connector these settings will be removed, so make sure to keep backups. As of ColdFusion 11 Updater 4, CF will now archive your old connector settings. It still clears them out, but at least they are not lost. You will need to rebuild them as they were to get load balancing back.
HAProxy - An Open Source Software based Server Load Balancer
As an alternative to Connector load balancer you might look at using a product called HAProxy to route requests. It has similar features as F5 but it is all software based.
If you did use HAProxy you would likely not define any Clustering in ColdFusion at all.
Using the ColdFusion Admin to only Define Load Balancing
If you only want to do load balancing, I have found that you can use the Clustering page in the admin and define your cluster, then once it is saved, you can then remove or comment out the Clustering section in the <servername>\runtime\conf\server.xml file. The result will be that you will have the Load Balancing settings completed for you. The server will not try to find other servers, and potentially replicate sessions.
I have found that if an application is worthy of clustering, it usually will be placed under an F5 like hardware device for load balancer. However, if for some reason you don't have access to an F5 or want to have more granular control of routing requests then setting up Load Balancing with Tomcat is a great way to do it.
I would not recommend using the multicast server peer discovery for session replication. You can share session information in many more reliable ways.
Docker and containers are changing everything with deploying, scaling and session management, I will try and write an article building on this one for Docker soon.