Did you know you can now run a stand-alone SQL Server virtual machine in production—and that Microsoft will provide you with a Service-Level Agreement (SLA)? With the recent changes that Microsoft has made to the Virtual Machine Computing platform (A.K.A., IaaS), they’re pushing the envelope to make it tremendously easier for customers to deploy production workloads. Essentially, if you’re okay with less than ~43 minutes per month, you can run your workload on a single virtual machine as long as the following are true:
– The OS Disk is comprised of premium storage
– All data disks attached are premium storage
If you operate with the above configuration, you may not need to build availability sets and expensive SQL Server clusters—or worry about complex Azure IaaS configuration. Eliminating these clusters could reduce the following:
Cost: Everyone loves to reduce cost where they can by not having to support a paired set of virtual machines or paying for licensing twice for each node. This makes a big difference—in fact, it’s a game changer.
Complexity: Many of the High Availability (HA) configurations in Azure IaaS are complex and require a significant learning curve to obtain the skill set. Plus, HA/DR/BC is not really a skill you teach—it’s more so wisdom and experience in my opinion, so knowing what to do when it hits the fan is hard to rehearse and synthesize.
Time to Market: Infrastructure can be deployed, built and designed at ten times the speed as the same with a cluster.
So, to summarize, here’s a breakdown to help shed some light on this new offering:
At 10th Magnitude, we get the opportunity to work closely with the Microsoft product team, so when this ability was released, we had to verify it. In verifying this information, I thought it was especially cool to hear the operations folks at Microsoft say that these are legal commitments, but that they also strive for less than the SLAs they’re bound to. The question remains: Why or when would I still need a true High Availability/Disaster Recovery (HA/DR) configuration? It boils down to two points:
– Do you need a legal SLA of 99.95 percent? (This is back to that ol’ 22 minutes of downtime.)
– Does your application truly depend on the readable secondary/read-only routing capability? I don’t mean you just use it to run ad-hoc queries and the secondary gives you a live copy of the data without disturbing performance with the database’s core purpose to be an OLTP repository (lots of transactions). I’m talking about hardcore, bleeding-edge .NET 4.5 thoroughly-tested read-only routing from the connection string of your said application.
I do believe those are the two points you would use to decide on going with a cluster. If you currently point any reports or applications directly at the readable secondary, use the move to Azure as an opportunity to remove the single point of failure and bad practice. You can also replicate the data you need to a specifically-purposed database or start thinking about your Data Lake strategy.
How Do You Prepare for a World Without Clusters in Azure?
A single, stand-alone VM may have an uptime SLA, but this doesn’t provide a proper DR/BC strategy and could still cause errors in the case of planned outage. Before heading down this path, consider the following:
SLA: Can the database and its dependent applications be taken down on the weekends for planned VM host maintenance?
Auto-Recovery: Are all the databases able to recovery cleanly in the case of an unplanned reboot?
Backups: Are the databases properly backed up off the server in case of a critical reboot or hardware migration failure?
Monitoring: Does the SQL VM have sufficient monitoring to identify issues related to system restore or unplanned downtime?
Operations: Do current operational processes notify the team when there are issues connecting to a disk volume? Or just in case of general database failures?
Automation: If a maintenance error impacts your systems, do you have an automated way of restoring and recovering the database solution?
I can’t tell you how many customers I’ve worked with where their SQL Server footprint has almost made it too cost prohibitive—or it’s just downright scared them off knowing their DBAs would need to start managing things and files that they’re not used to doing today.
Getting Started
Before deploying a cluster or a single instance SQL server, we’d be happy to review your SQL environment to help choose the best path and avoid pitfalls, so shoot us a line to get started. However you deploy SQL in Azure, we can also help with a number of adoption accelerators to ease the transition.
That’s all for now, but feel free to follow us on Twitter to stay on top of Microsoft announcements and all things cloud.
