Considerations for operating MS SQL in the cloud, in production, DR, or hybrid scenarios. By Nick Rubtsov
What is a cloud? Shared hosting Grid computing Lots of marketing
Pros of a cloud Low initial cost Distribution across multiple datacenters, DR/BC Someone else is responsible for infrastructure Improved performance (under certain conditions) Ease and speed of deployment Ability to easily assign costs Forces to clean up coding Supported by all the buzzwords
Cons of a cloud High sustained cost in production (for larger deployments) Poor performance (under certain conditions) Lack of control over the infrastructure and ability to troubleshoot it Lack of flexibility (you get what everyone else gets) Cloud-specific idiosyncrasies Coding mistakes can be critical, and lead to higher expenses
Types of clouds Private Public
Deployment types Cloud-based Hosted in-house Hybrid Cloud-based with CDN
Deployment scenarios and goals Disaster Recovery and Business Continuity Moving highly available systems to the cloud Development and QA Complete outsourcing to the cloud Offsite ready backup and cold/hot sites Pilot projects
MS SQL in the cloud: cloud-based vs. hosted in-house All the pros and cons of cloud-based deployment apply. Idiosyncrasies – MS Azure hates SQL Placement of SQL clients really matters, and can add to expenses Dedicated WAN links to the cloud are an option Know your performance metrics and do evaluate your cost!
MS SQL in the cloud: hybrid deployment Geo-cluster (SiOS DataKeeper) AlwaysOn Availability groups (SiOS DataKeeper) Database Mirroring Verify you have enough WAN bandwidth! Check the latency! You might have to switch from VPN to direct WAN link to access the cloud.
2-node replicated cluster: Geo-cluster with SiOS 2-node replicated cluster:
3-node cluster with hybrid storage: Geo-cluster with SiOS 3-node cluster with hybrid storage:
4-node cluster with hybrid storage Geo-cluster with SiOS 4-node cluster with hybrid storage
AlwaysOn Availability Groups with SiOS Configure the cluster in multinode mode:
AlwaysOn Availability Groups with SiOS Configure availability groups
Geo-cluster vs. AlwaysOn Geo-cluster is easier to administer, but has slower failover, especially over WAN AlwaysOn fails over faster, but requires more administration (although some of it can be automated) Database Mirroring can be used, if WFCS cannot be used for some reason.
Things to watch out for: Make sure that the nodes are configured IDENTICALLY! Especially the network names. Make sure that identical domain policies apply to all nodes, and that these policies are correct. Make sure your cloud servers have static IPs. Dynamic allocation with reservations isn’t good enough! Know the infrastructure between your hosted and cloud servers. Make sure that the IPs you think your servers have match what the servers see (due to multiple NATs in the clouds and on your end). Make sure you have enough bandwidth for your amount of changes, and that the latency isn’t ridiculously high (you might have to change the location of your servers in the cloud, or the cloud, if the latency is high; or get a dedicated WAN link to the cloud).
Common mistakes in cloud deployments Not defining the goals for cloud deployment early on Not evaluating the performance requirements against the potential solutions Not researching the cloud as applied to your requirements Not properly stress-testing the pilot project Not performing a realistic cost analysis Listening to cloud’s sales representatives
What to look for in a cloud Discussion