This document describes the best-practice how to setup and use the Xtellus 360 cluster environment.
Settings and configurations
In a cluster environment all nodes must have access to configuration files. All configurations done through the 360 Web administration interface is automatically cluster wide and accessible from all nodes but additional configuration files for a specific solution is normally required. These additional configuration files are often in xml format or whatever format the developer is most familiar with and they are normally stored at local file system.
In a cluster environment these additional configuration files should be stored in a shared file system or in the cluster database shipped with 360 Cluster. Connection to the cluster database can be found in the database category inside 360 Studio.
Global properties included in 360 are cluster wide, and always accessible from any node. When possible it is recommended to use Global Properties.
Developing the solution
When developing the solution it is important to remember that the code could be executed at any machine in the cluster and therefore the local file system may not be the same between two executions of the same function. Common files should be stored at a shared disc or file server or stored in the shipped cluster database.
In some solutions synchronizations between activities are required. The 360 cluster version has a specific category 360 Cloud with cluster wide Lock, ReadWriteLock and Semaphores to address this. An example: an XML file needs to be created before other jobs can start read it, the reader jobs use the ReadWriteLock with read locking and the job creating the XML file also use the ReadWriteLock with write locking. This means that the reader jobs can read the file simultaneously until the job creating the XML file block all the readers with a write lock. Important is that this works no matter on which nodes the jobs are executed.
The 360 framework has built in support for cluster. The components automatically recognize that it is running in a cluster environment and perform a cluster connection. A cluster connection means that the connection works even when some nodes in the cluster are down. Use the 360 framework components to connect to get failover and scalability.
Schedulers in a 360 cluster environment use a leader algorithm which means that a specific scheduler is running on all machines in the cluster but only one (the leader) is submitting the jobs. If the leader node goes down the remaining nodes agree on a new leader which starts to submit the jobs.
This is all done automatically and no extra configuration is required.
Use a network/shared folder. The cluster handles file locking and make sure the files are processed only once. The file processing is load-balanced among all the machines.
Select a shared file path in Web administration, no extra configuration is required.
The queuing system is extremely high performing in a cluster setup where all the machines share the load of both storing and delivering messages to clients.
No extra configuration is required.
360 handle the cluster setup for the web service container and also load-balancing between the nodes. The cluster also handles failover for the nodes in the cluster. In this solution a separate server is used to retrieve the requests and distribute them to the cluster. This is a very stable solution even if the distributing server is a single point of failure. Windows NLB can be used instead of a distributing server to perform load-balancing and failover through a virtual IP
Everything is configured in Web administration except NLB. NLB in case that is used is configured separately.