GCP has a rather robust and highly available architecture (24 regions and 73 availability zones) as it is. Compute Engine implements an abstraction layer between the availability zones and physical clusters of machines within the data centers where each cluster of physical machines has its own independent software, power, cooling, network and security infrastructure, as well as its own computing and storage resources.
We will review the Compute Engine and Cloud Database (Cloud SQL) high availability features available.
Google Compute Engine High Availability
When designing your Compute Engine applications, we want to have them tolerant of errors, network failures, and unexpected disasters. This will help minimize failures within your application. Designed properly, your applications should be able to handle errors correctly, for example by redirecting traffic from the failed instance to the active instance and be able to run automatically after a restart.
To design for high availability, create virtual machine instances across at least two availability zones located in two regions. This ensures that even if a zone or an entire region goes down, your application can continue working. If all of your instances are hosted in the same zone or region, your application will not be resilient to failure of Google infrastructure.
GCP allows you to put your instances in Instance Groups. This is a group of instances that are designed for a common purpose and are designed to be used with load balances to route traffic between the instances. Instance groups also provide:
- Autoscaling – automatically scale the number of VM instances in the group if demand (load) increases
- Autohealing – If VM instance is unhealthy, automatically recreate it
- Support for Multiple Zones – You can create instance groups across zone in the same region.
Managed load balancing helps manage high volumes of traffic and can keep from a particular VM instance from getting overloaded. The load balancer provides:
- Network Load Balancing: With forwarding rules – deploy applications across multiple regions (using regional Instance Groups) and have rules to distribute traffic to all VMs in that region. Each forwarding rule can stem off of just one external IP address so your users always appear to be accessing the same site.
- Global Load Balancing, With HTTP(S) Load Balancing you can distribute traffic across regions, so you can ensure that requests are routed to the closest region or, if there were a failure (or capacity limitation), failover to a healthy instance in the next closest region. You could also use HTTP(S) Load Balancing to distribute traffic based on content type. For example, you might setup your servers to deliver your static content such as media and images from one server, and any dynamic content from a different server.
Startup and Shutdown Scripts
Virtual Machine instances can have start-up and shutdown scripts associated to them that are initiated when the instance starts or stops. You could use such a script to back data up, install software. The scripts run in any event an instance is shut down—even if it was unintentional.
The scripts can then be used to create a bootstrap procedure and shut them down cleanly. Instead of using a custom image to configure the instance, you can use a startup script. After each restart, the startup script runs and can be used to install or update software, and ensure the appropriate services are running.
The shutdown script can perform important actions like closing connections, saving state of transactions and backing up data.
Cloud SQL High Availability
Google Cloud SQL is a managed relational database service that supports database engines including SQL Server, MySQL and PostgreSQL, and can connect with most applications. It provides backup and replication capabilities for high availability.
You can create a highly available Cloud SQL instance in two types of locations:
- Regional location—specific geographical locations, such as New York.
- Multiregional location—an extended geographic area that includes two or more geographic locations, such as the United States.
The only difference between regional and multiregional locations is for backup purposes. A multiregional instance can save backups in multiple regions for higher resiliency.