--- title: "Hosting Clusters 101 – An Overview" source: "https://docs.nexcess.com/sites-stores/hosting-services/sites-and-stores/clusters/" description: "Do you seek a hosting solution with increased scale and availability? A Nexcess Hosting Cluster Solution can provide what you are looking for. Learn more!" vertical: "Sites & Stores" date: "2022-01-11" last_modified: "2026-06-30" --- # Hosting Clusters 101 – An Overview ## What is Clustered Web Hosting? > Clustered hosting is primarily an enterprise hosting solution, with the main benefits being increased scale and availability. It provides a way of scaling horizontally among multiple servers, which increases maximum throughput, and adds fault tolerance through redundancy. ## Hosting Cluster Challenges The benefits outlined above are short, simple, and clearly valuable. Unfortunately, those advantages come at a cost, both financial and in the form of significantly increased complexity. It’s easy enough to lose track of all the moving pieces in a single server environment, and this can grow exponentially with the size of a cluster solution if left unchecked. On the other hand, things like version control, configuration management, and good naming conventions can all be extremely valuable with this kind of solution. It can also be beneficial to maintain a reference diagram of the application and cluster layout and its interaction with all external systems. The simplest form a cluster can take is a two-server solution. The second server is used to offload a heavy piece of the infrastructure, such as a database service, to its dedicated server with its own resources. There generally isn’t much added complexity in this basic layout, as most of these services can work across a network just as well as they would when accessed locally. When you add in multiple servers performing the same role, you have to face bigger challenges like ensuring state and data consistency. These objectives are primarily handled by using services like **Redis** to store cache and session data that can be shared between servers and a network file system to ensure the files are consistent. These external resources do add overhead to actions, though, and network file systems, in particular, can become a bottleneck if not implemented intelligently. ## Nexcess Hosting Cluster Solution The above sections give a short overview of the benefits and difficulties of a cluster solution. The rest of this article will cover how Nexcess implements this and provide an introduction on interacting and managing sites on a Nexcess cluster service. ### Cluster Layout Nexcess clusters come in two basic layouts. The first is a single server with an external database server. The second will include at minimum a file server, database server, load balancer, and one or more web nodes. A lot of the information below will be primarily focused on the second type as it is more complex by design. However, many of the items will still apply to the first type and quite a bit will even apply to environments with only a single dedicated server as well. One great benefit of using a load-balanced environment, even with only a single web node, is that it makes scaling up for busy periods much easier. Building additional web nodes and adding them to the environment is a straightforward process that can be done without interruption to the site. It’s also a common practice to add an “admin” node that provides a dedicated server for site administrators that is less impacted during moments of heavy load on the front end of the site. Servers in a cluster all have hostnames sharing a common prefix, followed by their role and a number that uniquely identifies it among other servers in that role. So, with a prefix of **gpc999**, the hostnames would be something like: - ``` gpc999-lb1.us-midwest-1.nxcli.net.yaml (Load Balancer) ``` - ``` gpc999-fs1.us-midwest-1.nxcli.net.yaml (File Server) ``` - ``` gpc999-db1.us-midwest-1.nxcli.net.yaml (Database Server) ``` - ``` gpc999-node1.us-midwest-1.nxcli.net.yam (Web Node 1) ``` - ``` gpc999-node2.us-midwest-1.nxcli.net.yaml (Web Node 2) ``` - ``` gpc999-admin1.us-midwest-1.nxcli.net.yaml (Web Node for admin traffic) ``` The servers are all connected on a local network or **“backnet”.**To take advantage of that setup, each server also has an **internal hostname** consisting of the beginning of their **external hostname**followed by **-int.** One example would be: - ``` gpc999-node1-int, gpc999-db1-int ``` ### Services #### Apache - **Where:** Web nodes. - **Apache Description:** Web server that runs only on web nodes and routes traffic to the applications. #### PHP-FPM - **Where:** Web nodes. - **PHP-FPM Description:** Dynamic requests are routed to this by Apache. This service executes the actual application code for any application written in **PHP**. #### MySQL - **Where:** Database server. - **MySQL Description:** Relational database service. Nexcess predominantly uses **MariaDB**. #### NFS - **Where:** File server. - **NFS Description:** Network File System allowing for files to be shared among all servers. #### HAProxy - **Where:** Load balancer. - **HAProxy Description:** Robust load balancing software used to route traffic to web nodes evenly. #### Ipvsadm - **Where:** Load balancer. - **Ipvsadm Description:** Simple load balancing software used to route traffic to web nodes evenly. #### Varnish - **Where:** Load balancer. - **Varnish Description:** Highly configurable and fast page cache. #### Redis - **Where:** File server or load balancer for instances without replication. - **Redis Description:** Fast caching and session storage supported by most applications. #### Elasticsearch - **Where:** File server or load balancer. - **Elasticsearch Description:** Search engine supported by many applications. #### RabbitMQ - **Where:** File server or load balancer - **RabbitMQ Description:** Message broker used for running tasks asynchronously. ## Managing a Nexcess Cluster Solution ### SiteWorx **SiteWorx** is the primary control panel for managing any Nexcess service outside our cloud platform. For cluster solutions, this service runs on the load balancer. Here you can do the following: - Add/remove domains or create domain aliases - Change the **PHP** version used by a site - Reset **SSH** password or manage **SSH** keys - Whitelist IP addresses for **SSH/SFTP/FTP** access - Add and remove databases - Manage database users - Manage other control panel users ### SSH All servers are accessible via **SSH**, but the load balancer is treated as the gateway to the cluster. Once logged in to the load balancer, shortcuts are available via configuration in **.ssh/config** file for the user that allows quickly logging into other hosts: - ssh node1 - ssh db1 This is added by default on newer clusters but is currently not present on all. If these shortcuts aren’t working for you, contact our support team, and we can get it added to an existing service. ### Adding Domains or Accounts Clusters can support as many sites as the resources allow, and as mentioned above, new sites can be added via the **SiteWorx** control panel. These sites can also be distributed among multiple **SiteWorx** accounts, which means they will be under separate **Unix** users on the servers for better isolation between them. New sites can be added to existing **SiteWorx** accounts, however, new **SiteWorx** accounts must be created by our support team. Note: Adding secondary domains (not aliases) to an environment using **HAProxy** requires a minor modification to the Apache configuration on each newly created domain. At this time, this needs to be done manually by our support team. ### MySQL As mentioned above, databases and users can be managed via **SiteWorx**. Accessing **MySQL** remotely, however, requires firewall whitelisting for specific IP addresses that our support team can only do. Alternatively, it can be accessed using an **SSH** tunnel through the load balancer which most **MySQL** clients support. ### SMTP The default settings for **SMTP** in most applications use **localhost port 25** for sending email. Due to this fact email will be sent from the server on which the process running. Email sent during a web request will be sent from a web node, whereas a cron job will send mail from whatever server that cron job is running on (likely a file server or a load balancer). ### Restarting Services We do not provide root access to our servers; however we do allow the ability to restart/reload most of the services listed above via **sudo**. You’ll also need to ensure you’re logged into the proper server using the information outlined above for the various services. ### Cron Cron is available on all servers, however, the best place to run most cron jobs is on the file server as it saves overhead from **NFS** and tends to perform better as a result of that. Note that the **PHP** version used by cron jobs is set manually via the **PATH** variable at the top of the **crontab** file. ### CLI Commands The **PHP** version used by **CLI** commands is set in your user’s **.bashrc** file which is read on login. While commands can be run from almost any server due to **NFS**, commands involving many file changes will perform best when run directly on the file server. ### Logs Apache access logs and error logs for all web nodes are available via **NFS** on the load balancer. They are located here, where **xx.xx.xx.xx** is the internal IP address of the specific web node: - /var/log/interworx/xx.xx.xx.xx/example.com/logs/ **PHP** errors that occur during web requests will either be written to the site’s Apache error log or to a **php-fpm** error log: - /home/${USER}/var/php-fpm/error.log ### Apache Configuration Most site-specific Apache configuration changes can be done via **.htaccess.** Certain items require a higher scope, and our support team can implement these. ### PHP Configuration Most **PHP** settings can be done via the **.user.ini** file in the site’s document root. You can find a reference of settings in the [List of php.ini directives – Manual](https://www.php.net/manual/en/ini.list.php). Settings marked with **PHP\_INI\_PERDIR** or **PHP\_INI\_ALL** can be set in the **.user.ini** file. These settings are only read by web requests, though command line configuration can be adjusted through the use of flags appended to the command. ## Conclusion This article was intended to provide a high-level overview of what a cluster solution is, when to use one, and how to manage one with Nexcess. Some topics mentioned may require much more detail than seen here, and therefore may be covered in future articles of their own to explore their full depths.