Five Tips for Deploying SQL in the Cloud

David Bermingham is Senior Technical Evangelist at SIOS.

For many organizations, moving applications that can tolerate brief periods of downtime to the cloud is a straightforward decision with clear benefits. The cost justification is usually easy to figure out and the cloud almost always comes out looking like a sound investment.  However, concerns about how to provide high availability and disaster protection in the cloud may make this decision more difficult for business-critical applications such as SQL.

Understanding the facts can help you make informed decisions about moving applications to the cloud, while ensuring the important business operations that depend on them are protected from downtime and data loss. Here are five tips for deploying SQL in the cloud that can save businesses money and ensure the most value is derived from cloud deployment:

Build Your Team

When moving to the cloud you’re using the cloud’s infrastructure and servers, so you’re still going to need the same players on your team as you would on premise. This includes:

Understand Service Level Agreements

One of the first things you need to understand when moving to the cloud is what service level agreement (SLA) the cloud provider is offering. SLA identifies the agreed-upon services that will be offered by the cloud provider. If you don’t look very hard you might think that you can sit back and put your feet up when moving to the cloud, but you can’t assume providers will ensure your SQL will stay up and running.

Companies should be looking for ways to deliver on their SLA commitments and provide the same level of availability protection for these business-critical applications in cloud environments as they do in traditional on-premises failover clustering environments. Your SLA is only as good as its weakest link, so it’s important to consider availability in all areas; including internet, cloud platform, geographic recovery, virtual machines, storage, SQL Server, application servers and AD/DNS.

SQL License, BYOL, Pay As You Go, or PaaS?

Another thing to consider is if you should bring your own licenses, pay additional licensing fees or use PaaS. You should calculate the server license needed, compare and analyze your requirement and see which method is less expensive. It’s also important to consider if you want to pay for the investment up front or pay a monthly cost over time. Looking at your company’s break-even point can help in making this decision. When renting a license, you will start spending more on SQL server licensing sometime around the two-year point. Every instance is different, but if you anticipate being in the cloud for more than two years it’s often more cost effective in the long run to bring your own license.

Other questions to consider: Are you passing the cost off to customers? Service providers that are building a service and selling it to customers can pad the monthly cost of SQL servers into their offering. In that case it would make sense to rent licenses in cloud. Can you take advantage of PaaS? How does SQL Server AlwaysOn impact licensing? How does Instance Size impact licensing? It’s important to address these questions upfront, so you’re able to assess all of your options ahead of deployment.

Choose Your Instance Size Wisely

Choosing a cloud instance size can be more complicated than you might think. There are a lot of different sizes and they typically offer more as time goes on. It’s also important to understand that one size doesn’t fit all; they will all have different amounts of central processing units (CPU), memory, storage, network etc. For example, one may have enough CPUs, but when you start looking at storage throughput you may really need the next level up. That can impact your decision. However, the benefit of the cloud is if you don’t get it right the first time, it is easy to resize. But if you don’t get it right the first time with an on-premise server, it’s incredibly difficult to package it back up and exchange it for a new one.

Choose the Right HA and DR Solutions

Most companies architect solutions to be highly available (HA), but do not always account for disaster recovery (DR). Cloud does not negate the need for HA, DR and backup. The concepts behind both HA and DR are similar – make your systems available when you need them. HA options are essentially the same as on premise (database mirroring, log shipping, backup and restore), but there is no SAN available. Availability groups provide benefits that include quick failover, readable secondary, automatic page repair and don’t require third-party products.

Failover Cluster Instance provides easier management, but lacks SAN or another shared storage device. Cloud providers have storage that just attaches to each instance for availability groups but in failover cluster without a SAN you’re not going to be able to build a failover cluster instance unless you use some type of third-party storage device. It does however protect an entire instance, support DTC, and work with SQL Server Standard Edition as well as support SQL Server 2008 R2 and earlier.

Whether you’re starting the process or still just thinking about making a move to the cloud, it’s important to consider how you will protect business-critical applications from downtime and data loss. While traditional SAN-based clusters are not possible in these environments, SAN-less clusters can provide a simple, cost-efficient alternative to implement a failover cluster in a cloud.  These clusters not only provide HA protection, but also enable significantly greater configuration flexibility and potentially dramatic savings in licensing costs.

Opinions expressed in the article above do not necessarily reflect the opinions of Data Center Knowledge and Penton.

Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating. View previously published Industry Perspectives in our Knowledge Library.