Earlier this week, SIOS invited me to join them in a webinar over at MSSQL tips. You can watch the webinar recording if you register for it in “OnDemand” mode on their site here.

Dave Bermingham joined me on the webinar – he’s a great technologist and a long time Microsoft MVP in cloud and datacenter management. He works for SIOS.

The main points of the webinar were:

1. Maybe you could be running your workloads on SQL Server Standard. (I blogged about that earlier this week, too.)
2. Maybe Availability Groups aren’t always all folks think they are (especially if you want to be SQL Server Standard – see an older post from me about “Basic Availability Groups” )
3. The DataKeeper product from SIOS makes a really compelling case for moving to failover cluster instances in the cloud and VMWare environments. (Watch the webinar for a pretty informative demo from Dave on that)

Using SIOS + FCI To Move Some Folks to SQL Server Standard

This is a common pattern that we’ve helped quite a few clients deploy this year and last. Especially with some of the SQL Server 2019 changes to licensing combined with earlier changes – SQL Server standard, as I discussed in the Standard v. Enterprise post, is more and more compelling.

This year at Straight Path we helped more than a few clients achieve High Availability in the AWS cloud on EC2 VMs. At least three of these clients were also able to move from enterprise edition (2 originally with AGs, one originally with mirroring) to Standard and get the same or better performance, realize significant license savings – and maintain the cross-Availability Zone availability their applications demanded.

We’ve also helped other clients with “a bit too many DBs” in an AG (over a few hundred!!) move to FCIs in VMWare and AWS utilizing SIOS DataKeeper. This improved performance (no more worker thread exhaustion and some of the performance overhead from managing so many DBs in an AG).

The webinar gets into some more of those details.

Some of the Questions

We answered a handful of questions on the webinar – but we told folks we’d try to get to more of the questions in a follow-up blog post:

1. Do the volumes on both nodes have to be identical (drive letter, size, etc.) for DataKeeper replication? Yes – same drive letter 100% – remember we are using DK to perform block-level storage replication and presenting that storage as though it is shared storage. When SQL Server fails over to the secondary node – it will be looking for its data files on the same drive they were on on the other side. Technically speaking, they can be different sizes – but please do not do that! We’ve seen folks burn themselves by growing a file on the “Source” (the SIOS DK term for the node generating the data for the DK cluster – the primary SSQL node) but neglecting to grow it on the “Target” (the secondary). If you do that – once the used space on the source is larger than the source’s capacity – your mirror will break. You stay online, but you won’t have failover ability until you resize and rebuild the mirror. SIOS has extensive documentation about all of these things and the right way to resize.
2. “Can you please share an article link that will (be) helpful to configure this prod environment?” I’m not sure which this was about. But SIOS has a decent set of documentation around configuring their product. This one about configuring SIOS DK and a windows cluster in AWS is a good starting point. I’ll have a post up later this week or next discussing our “typical AWS EC2” footprint as well – that may help.
3. Why do you prefer R5D EC2 instance types over R5, and why not X1E class? I’ll do a post later this week or next talking about our EC2 sizing approach – the real short answer is – R5D has the NVME drives available – which is excellent for TempDB and also excellent for the SIOS bitmap files – both of which are transient, not necessary to survive a reconfigure – but want ideal performance. X1E looks really good with memory to core ratios, I agree. But when you look at the throughput to the EBS volumes – you realize why AWS advertises those as “Memory intensive workloads” servers – they mean memory intense – but not IO intense. I’ll write more about that in a future post.

There were a few questions around licensing as well. I may do a quick refresher post around what Microsoft gave us with the third node available with DR. I try and avoid giving detailed, written licensing advice, though!!! It changes enough and is complicated enough that I don’t want to lead folks astray. But I’ll try and do an updated licensing post this month and cover some of the thoughts there, at least.

Thanks for coming to the webinar! I’ll share some links here if I add some posts relevant to these questions or expand a bit more on some of the things we like to see in an AWS SQL Server environment.