• Home
  • Cloudflare DNS and CDN With WordPress High Availability On Google Cloud
WordPress HA

Cloudflare DNS and CDN With WordPress High Availability On Google Cloud

Long Title But This Is About Search Rankings

Lets start off skipping the title and saying what this is actually about. Ranking on Google search for a clients site.  First off the site itself is just 2 months old, studies suggest it should take about 3 to 6 months to rank well.  The site languished in the 30s … or page 3 for the first month but now its presenting a commanding ranking.  Of the 283 keywords I track the site ranks in 211. Page 1 rankings now reach 19 on Google, 37 on Bing and 38 on Yahoo….UPDATE…I was looking at last weekends numbers.  27 on Google, 54 on Bing and 63 on Yahoo for page one results.

SEO trends
Latest SEO numbers

SEO isn’t marketing.  Onpage SEO may be, but what does a marketing course teach us about the Offpage SEO which is backlink and server performance related?  Top ranking sites need both and I’d argue that Offpage SEO is more important.  Granted neither of the two halves will rank a site as the top result alone, but too often people focus on Onpage SEO and neglect the technical side of ranking.

Of course the top 3 positions of search results are the next step for the site I’ve mentioned above and feeling confident in content and Onpage SEO I’ve focused recently on the server side of things.  Towards that goal I am testing a WordPress High Availability deployment.

WordPress HA
WordPress HA Utilizes a server cluster with dedicated SQL cluster and failover resources.

CDNs By Definition Remove Bottlenecks

This coupled with Cloudflare DNS and CDN is I think going to produce a server environment that’s obscene. For those who aren’t familiar with a CDN network here is a handy image explaining it.

CDNs store cached versions of your centralized server in regional hubs decreasing the amount of time it takes to acquire a resource.

I’ll update everyone on the effect of the sites rankings.  The first kick in rankings which in the line graphs is where the trend really caught upward direction happened when I moved the site off of a shared hosting server to its own LAMP stack server.  Essentially now I am dividing the stack across auto-scaling servers.

Here’s a the getting started guide as provided by Google.

WordPress High Availability Getting Started Guide

WordPress Deployment Overview

This document aims to provide the information necessary to maintain and perform administrative tasks on your WordPress High Availability deployment from the ​Google Cloud Launcher

Google Cloud Prerequisites

This solution leverages a few GCP features, which require certain APIs to be enabled in your project in order for ​Deployment Manager​ to successfully deploy these resources. The following APIs should be enabled ​before​ you deploy the solution:

  • ●  Google Identity and Access Management (IAM) API
  • ●  Cloud SQL Administration API
  • ●  Cloud Container Builder APIThe Google Identity and Access Management (IAM) API is required in order to create a service account who only has access to the GCS bucket that will also be created as part of the deployment.The Cloud SQL Administration API is required in order to create and interact with the Cloud SQL instances that are created as part of the deployment.The Cloud Container Builder API is required in order to delete the GCS bucket and its contents at deployment deletion time.


    The solution architecture is made up of 5 main components:

  1. A ​Google Cloud SQL​ instance running MySQL configured with failover to handledatabase workloads
  2. A ​Google Cloud Storage​ bucket to act as a synchronization point for content stored in
  1. A ​Managed Instance Group​ for running Cloud SQL proxy tool, responsible for maintaining secure and efficient database connections
  2. A ​Managed Instance Group​ for the VM that will be used to perform administrative functions in WordPress
  3. A ​Managed Instance Group​ for the VMs that will serve the content of your blog
  4. An ​HTTP Load Balancer​ to distribute the traffic between the content serving nodes

Below you can see an architecture diagram of how the components relate to each other.

Key Components & Services

There are two custom services running on the deployed machines that are essential for the solution to function properly. These services are ​gcs-sync ​(running on WordPress instances – both Admin and Content) and ​cloudsql-proxy​ (running on the SQL Proxy instances).

The ​gcs-sync​ service runs a script ​/opt/c2d/downloads/gcs-sync​ that, depending on the role the VM is assigned (Content or Admin), will check in with the GCS bucket tied to the deployment and determine if content needs to be pushed to or pulled from GCS. If you need to interact with the service, you can do so via ​systemctl​. For example:

systemctl stop gcs​-​sync

will kill the script checking GCS, and the node will not receive any updates that come from the Administrator Node. Conversely, if the service needs to be started you can do so with the following command:

systemctl start gcs​-​sync

The ​cloudsql-proxy​ service makes use of the ​Cloud SQL Proxy​ binary so you can connect to your Cloud SQL instance without having to whitelist IP addresses, which can change when instances are deleted and recreated in a Managed Instance Group. The Cloud SQL binary is located at ​/opt/c2d/downloads/cloud_sql_proxy​ and the script that executes the binary is located at ​/opt/c2d/downloads/cloudsql-proxy​. Like the service that runs ​gcs-sync​, it can be interacted with using ​systemctl​. Stopping the service can be done with:

systemctl stop cloudsql​-​proxy

At this point your instance will not be able to communicate with the Cloud SQL instance, and the application will not function. If you needed to manually start the service for any reason you can do so with the following command:

systemctl start cloudsql​-​proxy