Always On Availability Groups Now Supported in Google Compute Engine

I’m excited to finally be able to talk about something Erik, Tara, and I have been working on for the last few months.

Here in the SQL Server community, when I mention cloud, you probably think of two companies: Microsoft and Amazon. We’ve been blogging about SQL in AWS for years, and Microsoft throws a ton of marketing money at the SQL Server community, talking about Azure at every possible conference and user group.

Turns out there’s another cloud company.

They’re kinda big. You might have heard of them. And they’re turning their attention to Microsoft SQL Server shops.

Google Compute Engine is infrastructure-as-a-service (IaaS), selling virtual machines by the hour like Azure VMs and AWS EC2. You can run whatever you like in these VMs, and Google has long supported running SQL Server in GCE. You could build your own SQL Servers, or use pre-built (and licensed) instances of SQL Server 2012, 2014, or 2016 – but only Standard or Web Editions.

Today, GCE supports Enterprise Edition AND Always On Availability Groups.

We’ve got a white paper coming soon on how to build and test it, plus more cool stuff in the pipeline that DBAs will love.

Why Run SQL Server in Google Compute Engine?

Lemme get one thing straight first: the single biggest decision factor when it comes to cloud providers is the list of cloud services you’re already using. If your developers are building things like crazy on top of a service that’s only available in one provider, you probably want to stick with that cloud provider. If you try to span cloud providers, you’re going to run into latency issues and data egress charges.

I’m no cloud analyst, but I’d guess this is why cloud vendors are racing to build things nobody else has. (For Microsoft, that means things like Azure SQL Data Warehouse.) Cloud vendors want you to use these proprietary services so that you get locked in.

But as long as you don’t get tied into proprietary services – and most on-premises shops running SQL Server haven’t yet – then you can look at other decision factors like VM support, storage speed, networking, etc. It’s kind of a religious war right now – to give you an idea of one guy’s take, read The HFT Guy’s post. (I don’t agree with some of the stuff in that post- for example, AWS’s dedicated instances make sense if you need to lift-and-shift SQL Server from on-premises VMware licensed by the host.)

Religious flame wars aside, one of GCE’s biggest differentiators is their billing:

  • With Azure VMs, you pay a set price per hour. You can kill your VM whenever you want, and the billing stops. If you want a discount, you either gotta shut the VM off (ha ha ho ho), or you gotta contact a salesperson and sign an Enterprise Agreement. (Gotta protect those highly-paid partners.)
  • With AWS EC2, you can get discounts. If you decide you want to keep a VM instance size around for a while, you can reserve that instance, pay an up-front fee, and then pay less by the hour for that VM. It’s not very flexible, though.
  • With Google Compute Engine, your price just goes down. The longer you keep a VM running, the VM price just keeps dropping, and I’m not talking about years – I’m talking about weeks. You automatically get up to 30% off workloads that run for a significant portion of the billing month. Here’s more details.

The small business guy in me really loves the simple GCE approach. Don’t force me to make financial gambles on my 3-year infrastructure plan – that’s why I’m in the cloud in the first place.

Speaking of financial gambles, let’s talk licensing.

How to License SQL Server in Google Compute Engine

Just like the other providers, there’s two ways you can do this.

With Bring Your Own Licensing (BYOL), if you own licenses already, and your licensing agreement allows it, you can use those.

If you don’t have cloud-friendly licensing, or if you’re starting a new project, then you’ll want to avoid forking over a large up-front fee for licensing. Google will rent you the licensing along with your VM:

  • Enterprise Edition – $0.399 per core/hour (roughly $300/core/month)
  • Standard Edition – $0.1645 per core/hour (roughly $118/core/month)

Because you, dear reader, are a data geek, you’re going to run numbers and realize that renting Enterprise Edition licensing from Google for a year almost exactly matches up with what it would cost you to buy that same licensing outright ($3500/core/year). (AWS is the same story.)

If you know that your licensing needs are predictable, and that you’re going to need SQL Server Enterprise Edition for a year or more, and you can afford the up-front costs, then yes, you should buy that licensing and bring it to the cloud. But again – the cloud is about flexibility, being able to adapt to changing demands.

That’s a big focus in our upcoming white paper, too: how DBAs can help the company adapt to changing performance and availability demands by just spinning up a new VM, adding it into your AG, failing over to it, and shooting the old one.

Like admins say these days, treat your servers like cattle, not like pets – and we’re going to show you how to do it with SQL Server. I’m excited to show you that soon, and I’m honored that Google asked us to be a part of the project.

Let’s talk about it at Google Cloud Next.

I’ll be at Google Cloud Next, GCP’s conference, on March 8-10 in San Francisco. We’ll be talking more about the specifics in the Running Microsoft SQL Server on GCE session. If you’re already registered for Next, you can reserve a seat in the session now.

See you there, and I can’t wait to share more details soon.

Previous Post
Updating the Stack Overflow Demo Database
Next Post
SQL Server DBA’s Guide to the Gitlab Outage

6 Comments. Leave new

  • That’s boss. I’m happy that all the hard work that all of you have put in has paid off. Keep up the good work.

    Reply
  • I was excited when I read AlwaysOn is supported on GCP, the fact that you played a part in it makes me super happy 🙂

    Reply
  • Great article, thanks Brent. I was having an issue getting the routing configured properly, kept getting “Creating route “clusterip1″ failed. Error: Invalid value for field ‘resource.destRange’: ‘10.0.1.102/32’. 10.0.1.102/32 hides the address space of the network (10.0.0.0/16). Cannot change the routing of packets destined for the network.”

    After reading some of the Google documentation on this subject it appears that maybe the WSFCSUBNET1 and WSFCSUBNET2 mentioned only during the VM creation should have been created using a /24 subnet, while the VM instances themselves use a /16 subnet.

    Anyway, I’m about to blow away my lab and try again using that assumption. I’ll let you know if I have any more luck.

    Reply
  • Hi, I would like to check that whether I can add a SQL Server VM built in GCE as a Secondary replica to on-prem DC where our Primary Replica runs? Basically setting up a Hybrid AlwaysOn set up between On-prem & GCP. Just want to check even it is possible? with SQL Server 2017. If its possible , I can work with my network team to help me to get thru pre-requisites

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.

Menu
{"cart_token":"","hash":"","cart_data":""}