Q&A from SQL Server Containers as a Service

Last week I presented a webinar on DH2i’s newest offering: Containers as a Service for SQL Server. We received a lot of terrific questions throughout the webinar but were unable to answer them all. This blog post includes my response to every question that was asked and I hope it can be of use to you.

 

  • How many instances do I need for this to make sense?

Containers as a Service is a great solution for 1-2 instances because it is an easy way to attain HA and better manageability. Savings will start to become really significant when you get to 2-3 instances and beyond.

 

  • Is there an outage during the failover of instances?

The only outage you may experience is a pause that lasts as long as it takes SQL Server to stop and restart.

 

  • What does installing DxEnterprise mean for Microsoft support?

Our software is fully Microsoft certified. DxEnterprise is not only just leveraging standalone applications; it can also be completely uninstalled from an environment without affecting other processes. The only change will be a loss of HA during the uninstall window.

 

  • How does SQL licensing work with Containers as a Service? Do you still have to license SQL per container or is it per VM?

We do not change any of the rules on what you need to license for SQL Server, so you will need to license per VM. Our software gives you the ability to install and stack as many SQL Server instances as you want, up to SQL Server’s established limit of 50 instances per licensed host.

 

  • How do you come up with 32 licenses vs. 8 licenses on this slide?

On the left hand side we’ve shown that we have 8 instances and 8 virtual machines. We’ve multiplied the 8 VMs by the 4-core minimum that Microsoft has for licensing SQL Server on a VM to get to 32. With the DH2i solution you only need 2 virtual machines because you can stack 4 instances, so doing the same here, you end up with 8 total licenses. Your stacking ratio may vary for your workloads, but an average ratio we see is 4:1.

 

  • What do you solve that Windows Containers can’t help me with? 

We hope to be able to manage Microsoft Containers with DxEnterprise as we learn more about the technology upon its release. But overall, Microsoft Containers are focused on stateless apps and the development phase, while DH2i is focused on stateful applications and taking things to the production level. DxEnterprise can also do containers for existing SQL Server instances with no code changes. DxEnterprise is very focused on HA, consolidation and QoS delivery while Microsoft containers are more for installing and provisioning tasks.

 

  • If I already have some SQL in the cloud but I have a different cloud provider than Rackspace, what can you do for me?

Because our containers are infrastructure agnostic, we can work with you to set up this solution in whatever mix of physical, cloud or virtual you have in your environment—and through whichever vendor you are working with. However, since we already have a solution architected with Rackspace, we can’t guarantee the pricing will be the same in your specific environment.

 

  • How does CaaS compare with Availability Groups?  

Availability Groups (AG) is impressive technology and allows you to do real-time reads off of a replica. With that being said, I have rarely come across cases where this is a strict requirement for an individual’s entire SQL state. Many folks have a very small subset of their environment that requires this. However, this requires you to be on Enterprise everything, which gets very expensive.

This is also not a consolidation play because it basically doubles the number of VMs you need, and with AG, everything needs to be like-for-like. You can mix and match operating systems within a DxEnterprise environment.

Lastly, AG means managing everything at the database level, while with DxEnterprise, this is all instance-level failover. So logins, alerts and jobs all move with the SQL Server instance whenever there is a failover.

Generally speaking, management of AG is just kind of a nightmare because anything you do to your primaries you have to do to all of your replicas. There are a variety of other networking issues you’ll face as well. There are active directory requirements; you have to have a backup domain controller at each domain, etc.

 

  • I have a requirement for FISMA compliance due to health data – how do you manage this?

We will apply whatever standards required by you, our customers, to ensure you are in compliance. We will work with you to properly manage security for the OS, filesystem or the instance.

 

  • How do you move existing clustered and stand-alone SQL Server instances to DH2i CaaS?

Backup-copy-restore is the process. We do have a data transfer tool, DxTransfer that would aid in the process. We will work with you directly to put together a plan appropriate for your needs.

 

  • How will performance be impacted?

DxEnterprise is a lightweight orchestration stack and is not in the I/O path of your applications; thus, there is no performance penalty for applications running on DxEnterprise.

 

  • How do you troubleshoot performance issues?

DxEnterprise reports performance statistics per node and per instance. This allows you to see at-a-glance which nodes/instances are consuming the most resources and how best to balance your workload across nodes. Monitoring and troubleshooting performance issues internal to the applications remain the same with/out DxEnterprise.

 

  • What are some recommendations for managing the disks that must move with the applications, especially from on-premises to cloud?

This is typically handled by replication between on-premise/off-premise/cloud storage. On failover to an alternate site, you would split/reverse replication.

 

  • How would a reporting solution (read only replica) set up with this model?

You can leverage SQL replication, log shipping or database mirroring for read-only needs. DxEnterprise is not the same as Microsoft Availability Groups because there is no WSFC in the stack.

 

  • Is the failover time only affected by SQL restart time or does the failover time grow with the size of disks used by SQL?

Failover time is determined by the amount of time it takes to stop and start the instance. The size of the disk has very little impact on the failover time. The number of disks required and used by the application would have some impact – it depends entirely on how long it takes for the NTFS driver to bring each of the volumes online.

 

  • If we host 4 instances on 2 VM as per your slide, how does it perform since there are only 4 CPUs on each VM?

We haven’t done any official benchmarking, but we have customers running a much higher number of instances on lower spec hardware all the time.

 

  • What is your uptime SLA and DR options?

We will adopt Rackspace’s SLA for all virtual machines. Though, when running on top of DxEnterprise, the downtime would be greatly reduced because we can patch/upgrade our software without taking down the applications.

DR options are available. Please contact us for your specific needs.

 

  • My SQL Server instances run on 4-core VMs. We have around 10 SQL Server instances and 10 VMs. If I migrate 10 instances to containers, what should the VM configuration be?

Sizing all depends on specific needs. We can work with you to scale up/out as needed. However, you could easily reduce your VM/Core count moving to CaaS.

 

  • How do you manage resource contentions when you run four instances on the same VM?

A lot of this can be internal to SQL Server by setting max memory. The rest would mean balancing the workload between nodes. There are built-in knobs to tune within DxEnterprise, such as setting max alerts/utilization on the system resources and priority for each of the applications. Perf monitor and tuning are an on-going process. We will work with you to scale as needed.

 

  • When stacking 4 instances on a VM, does that mean you could have one default and three named SQL server instances in a VM?

Every instance within a CaaS virtual pod must have its own unique name. So yes, you could have one default instance per pod with the rest being named.

 

Hopefully you like what you are hearing about DH2i’s Containers as a Service for SQL Server. Please give me a shout at connor.cox@dh2i.com if you have any questions, and don’t forget that we are offering free 30-day trials to test Containers as a Service yourself.

Connor Cox