How To Reduce the Cost of High Availability in Google Cloud Platform

In this article, Cassius Rhue, vice president of customer experience, SIOS Technology, suggests that when configuring a highly available SQL Server infrastructure in Google Cloud Platform, there are some expenses that are obvious and unavoidable. He explains how other expenses, though, are less obvious and avoidable if you understand your options.

One reason to migrate an on-premises SQL Server infrastructure to Google Cloud Platform (GCP) is to save money. Your on-prem infrastructure may be overbuilt yet underperforming, and the virtual machines (VMs) that Google’s customer engineers can help you configure may be more well adapted to your computing performance and budget needs.

But how do you configure your SQL Server infrastructure for high availability (HA) in GCP? If you need your SQL Server workloads to be accessible no less than 99.99% of the time, you’ll need to put instances of SQL Server in two different GCP zones. Moreover, you’ll need a way to ensure that if one instance goes down, the other can take over immediately to ensure the high availability you need. 

Architecting an HA configuration can be a costly proposition. And, if you make the wrong choices about configuring for HA, you can spend far more money than necessary to secure the availability you seek. 

Learn More: Mission Possible: Operational Flexibility in the Public Cloud

Accounting for Your Options

Where can you avoid overspending? There are fundamentally two approaches to HA that you can deploy in GCP: one involves using the Availability Group (AG) feature built into Microsoft SQL Server; the other involves using a third-party SANless Clustering solution. Since the cost of the underlying GCP compute, storage and memory resources will be the same in either approach, the real opportunities for avoiding unnecessary costs arise from decisions about whether to configure for HA using an AG or a SANless Cluster. 

Let’s first consider what’s common between the two approaches: 

• Both the AG and SANless Cluster approaches integrate with Windows Server Failover Clustering (WSFC). These services, built into Windows Server, monitor the virtual machines (VMs) supporting the individual instances of SQL Server and automatically trigger a rapid failover to the secondary instance if the primary suddenly goes offline. 
• Both the AG and SANless Cluster approaches rely on synchronous data replication services to ensure that your secondary instance of SQL Server has an identical copy of the database that the primary instance has been updating. If the primary instance of SQL Server goes dark, the secondary instance can pick up where the primary left off.

The differences between the two approaches — both in terms of cost and execution — lie in the details. 

First, there’s no additional cost for the AG functionality. It’s part of SQL Server. In contrast, you will need to license and install the third-party SANless Clustering software on each cluster node running SQL Server. That said, it’s important to note that a SANless Cluster handles data replication differently than an AG does, and you may spend more in an AG configuration to compensate for those differences. For example, as a component of SQL Server, the AG replication engine replicates only your user-defined SQL databases. It ignores other files in storage (including, oddly, the SQL system master databases, including those managing jobs and passwords).

In contrast, the replication engine powering a SANless Cluster is independent of SQL Server. It operates at the block level of storage, replicating ones and zeros between designated storage locations. In a SANless Cluster, all your SQL databases, as well as any other data in storage, will be replicated across cluster nodes. If you have other important files stored alongside your SQL databases, you’ll need to license and manage an additional solution to replicate that data in an AG environment. 

The major difference between the two approaches, though, is this: The Basic AG functionality included in SQL Server Standard Edition allows you to replicate only one SQL database per AG. If you want to configure an AG to replicate multiple SQL databases, or if you intend to replicate any number of databases to more than one secondary instance of SQL Server in the same AG, you’ll need to use the Always On AG functionality found in SQL Server Enterprise Edition. For organizations happy with the performance of their workloads on SQL Server Standard Edition, this required shift to SQL Server Enterprise Edition will come as a very costly surprise. 

If you configure for HA using the SANless Clustering approach, however, those costs may be avoidable. The SANless Clustering approach does not restrict the number of databases you can replicate, nor does it limit the number of secondary systems to which you can replicate your data. In other words, the SANless Clustering approach never forces you to move to SQL Server Enterprise Edition to ensure HA. You can continue to use SQL Server Standard Edition if that edition suits your needs. 

Learn More: Hybrid Cloud Adoption: 7 Ways To Overcome Data Security Challenges in the Cloud

Securing the Right Results at the Right Price

How much money might a decision to use SANless Clustering save? Quite a lot, in fact. On identical two-node/4-core SQL Server clusters – one configured as a SANless Cluster running SQL Server Standard Edition and the other configured as an Always On AG running SQL Server Enterprise Edition – the total cost of licenses for the SANless Cluster configuration running SQL Server Standard Edition is 58% lower than the total cost of licenses for the AG configuration running SQL Server Enterprise Edition. Note too that cost for the configuration running SQL Server Standard edition includes the cost of licensing the SANless Clustering software and a full support contract. 

And a 58% savings is just the start. Bump those same configurations up to 24-core systems — remembering that SQL Server Enterprise Edition is licensed on a per-core basis — and the cost of a SANless Cluster running SQL Server Standard Edition is 71% lower than an AG with SQL Server Enterprise Edition. 

Both approaches to HA provide the 99.99% availability you seek, but the SANless Clustering approach can reduce your licensing costs by 58-71%. 

So, ask those questions: What edition of SQL Server do your workloads really require in your new GCP environment? Unless your workloads use the additional resources, other than support for Always On AGs, that SQL Server Enterprise Edition provides, you can create just as effective an HA solution using SQL Server Standard Edition and SANless Clustering while avoiding costly and unnecessary expenses. 

Did you enjoy reading this article? Let us know your thoughts on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We would love to hear from you!