InterWorx Clustering

An InterWorx Cluster using the InterWorx Cluster Panel is a collection of servers that cooperate to make it appear to the outside world that there is a single hardware or VM server unit providing the set of supported services.

• First, one of the servers is designated as the Cluster Manager with the rest of the cluster servers acting as subordinate nodes to the Cluster Manager. The Cluster Manager commands the cluster and receives incoming connections which are handled by a software load balancer.
• The load balancer then routes relevant connections to the children nodes, which do the work of handling the service request, executing PHP or perl scripts, and responding to the client. This all occurs seamlessly without the user knowing that they could be talking to different hardware each time a fresh connection is made.M
• Each server on the cluster is still accessed and maintained independently outside of the set of supported services, and as such there is no confusion about what server you are connecting to when SSH’ing into an IP.

The following services are available for clustering by the InterWorx Cluster Panel load balancer. Connecting to these servers on the cluster’s public IP’s will cause the load balancer to route the connection to a child node if and only if there is a load-balancing policy setup for that service. Otherwise, the cluster manager will handle the request.

• HTTP (TCP port 80)
• HTTPS (TCP port 443)
• SMTP (TCP port 25)
• POP3 (TCP port 110)
• IMAP (TCP port 143)
• FTP (TCP port 21)

The following services are synchronized and available from any server in the cluster, but are accessed directly from a specific server in the cluster. In other words, the connection does not pass through the load-balancer.

• DNS (UDP port 53 and TCP port 53)
• NodeWorx/SiteWorx (limited on nodes) (TCP ports 2080 and 2443)

All hosts are challenged with provisioning enough hardware resources to meet the demands of their clients. It’s an art that is sometimes difficult to predict beforehand, and often a greedy website will decimate your service’s quality. Fixing this issue with non-scalable panels requires migrations and possibly expensive downtime for your client. With the cluster panel, scaling is as easy as tacking on additional Cluster Panel nodes to dissipate high workloads amongst more hardware.

A single server is always a single point of failure. A cluster, on the other hand, dilutes the risk across multiple servers, allowing for redundancy of services in the event of a catastrophic failure on a single device. In the event that a server goes down, InterWorx runs software to detect failures and remove a troubled server from the load-balancing policy. To the outside world, there has been no disruption. Inside, your techs are able to take down the server and repair the fault in order to restore the cluster to full capacity without your service missing a beat. Statistically, you are offered better reliability as your service availability isn’t dependent on a single set of hardware.

While clustering adds a fantastic technological and competitive advantage to any hosting service, it does so at the expense of additional complexity. The InterWorx Cluster Panel attempts to mitigate the knowledge and technical cost of implementation by making setup as simple as setting up an internal cluster network for node-to-node communication and using our interface to activate clustering. Once the cluster is setup, load balancing policies can be built up by mapping a public internet IP and a service port to a set of load balancing rules. InterWorx will handle server-to-server configuration and data synchronization automatically. Any changes made on the master cluster server will be automatically replicated to the nodes.