Being an independent website hosting solution, it’s important not to cut corners for the sake of cost cutting or saving time. I learned an extremely important lesson during my time at a data storage startup company. Clients are really angry when data is lost. Nothing drives that point home clear quite like being on a conference call during Thanksgiving dinner. Try to trouble shoot a Fortune-100 customer outage while your family is celebrating the holidays. Yes, that really happened at a prior company I worked for. Not fun.
Data redundancy and high availability were priority number one for my website hosting architecture. The rest of this post outlines the current website hosting architecture I’m running all of Zimventures clients on. A quick hat-tip to Linode, the company who provides all the back-end networking and hardware. I’ve been a Linode client for over a decade and would highly recommend their cloud platform.
The Zimventures website hosting solution employs two servers, fronted by a Linode Node Balancer. The balancer is responsible for monitoring the health of each server. It routes HTTP/HTTPS traffic to the primary server until it fails a health check. Should the primary server stop accepting web traffic, the balancer will route all traffic to the backup. Using a combination of replication technologies, primary and backup servers are always in sync. A tertiary server is in the works for the architecture. You can never be too safe.
Apache & Let’s Encrypt
SSL services are provided by the wonderful folks at Let’s Encrypt and Certbot. Each day, on the primary server, a cron job runs to check the renewal status of all client certificates. After the cron job completes, rsync is run to ensure the certificates are duplicated to the backup server. Just above the WordPress configuration directory, resides the Apache configuration file for each site. Rsync replicates the Apache configuration file from the primary to the backup server (described in the Local Storage section). Not to brag, but Zimventures charges nothing for SSL in our website hosting solutions. SSL isn’t an add-on. It’s the way the web should work by default.
Most of my potential clients websites use WordPress as their content management system (CMS). WordPress, for better or worse, can only use MySQL as its back-end database. On the Zimventures website hosting solution, MySQL Group Replication is configured to keep client data replicated and in sync. Extending beyond the standard master/slave topology, Group Replication allows multiple MySQL nodes to keep a mirror image of databases between dispirate nodes. I currently run Group Replication so that only the primary server is active (writable). A read-only version of the database is maintained by the backup server. If the primary server fails, the backup server will will disable its read-only mode, and become the primary MySQL server.
Every Apache site is backed by a piece of local storage which contains the WordPress installation, among other files. That storage is replication between the primary and backup server every 5 minutes via an rsync job. I’ve configured all of the websites to be hosted out of the default Apache location of /var/www/<site>. Within each <site> directory, the Apache configuration file exists for both the HTTP and HTTPS variants. Rsync synchronizes the configuration with the backup server. In addition, the /etc/apache/sites-enabled directory is rsync’d between the primary and backup server. By applying a simlink to the Apache ‘sites-enabled’ directory from the /var/www/<site>/<site>.conf file, we’re ensured that the backup server is kept completely up to date. Now we’re thinking with portals!
Nashua Website Hosting
Yeah, yeah, you knew this part was coming. If you’re looking for a local resource for designing, developing and hosting your small business’ website – please consider picking up the phone and giving me a call. No agencies, no sales guys, no b.s. Just the best technology, design, and customer service: all in a reasonable price. Let’s make your brand amazing!