Xtellus 360 can be configured to run as a cluster. Everything required to setup and run the cluster is shipped with the product. The clustering is at software level and no special hardware is required. A 360 cluster requires minimum 3 machines. The machines could be virtual machines but different physical machines will give a more failure safe environment. In a cluster with 3 machines, one machine can fail or be taken down without causing runtime interruptions.
With 5 machines, 2 can fail. The number of machines that can fail is calculated as
(number of machines - 1) / 2
Compared to a single machine setup, the 360 cluster give failover and scalability. In a cluster setup single machines can be taken down for service without affecting the solution.
The cluster relies on Zookeeper to synchronize activities among the machines. Zookeeper is well-known and used by almost all companies that handle large data volumes such as Facebook, Yahoo and others.
The cluster is configured in the standard 360 configuration site. A new menu will appear after the cluster setup has been installed. At the cluster page minimum 3 machines has to be selected where the current machine is one of them. Before the cluster can be started it needs to be validated, a check to verify that the selected machines can work as a cluster, such as versions, firewall ports are verified. After a successful verification the cluster can be activated.
The activation makes all the machines aware of the cluster and all services restart in a clustered mode. The configuration is identical after the cluster is activated. Changes to the configuration can be done through the web configuration at any of the machines in the cluster, changes are immediately visible at all machines.
In most services code can be attached by configure a class container which points to Eclipse project and jar-files, in a standalone installation changes in the attached code are picked up directly but in a cluster setup the container must be published manually in the web configuration. All code in the published container is then visible to all machines in the cluster.
All components in 360 Studio (Eclipse) are aware of the cluster and a load-balancing/failover connection to the service is used.
In the release of this writings which is 3.2 the schedulers don't load-balance job to all machines in the cluster, there is one leader machine. If the leader dies another machine take the leadership and starts schedule the jobs. The leadership is agreed when the scheduler starts and two schedulers can have different leaders. In future releases the scheduled jobs will be load-balanced to all machines in the cluster.
The recommended configuration is to monitor a network/shared folder. The cluster handles the file locking and make sure the files are processed only once. The file processing is load-balanced among all the machines. Backup and error folders can be configured and again a network/shared folder is recommended. If a local path is used as either the monitored, backup or error folder that path/drive must exists or be creatable on all machines.
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. In the release of this writings which is 3.2 the messages are not replicated to other machines in the cluster. This means that if one machine in the cluster goes down the queuing system will continue to function but messages stored at the machine that went down is not processed until it is up again. Future releases will use a replicating storage engine.
Cluster functions in user code
360 come with components for global properties, number series, locking, semaphores, read-write lock etc. All functions in this category works for the cluster environment as well as for the standalone environment. Using them will make it simple to switch between cluster and standalone environments.
360 use the Log4j framework for logging from user code. In a standalone setup that logging is done to text files. In a cloud setup logging is done both to text files and to a cluster database that is visible from all machines.