Sql-server – Any Reason to have Regular Failover Clustering in Azure Cloud

availability-groupscloudclusteringfailoversql server

Is there a reason to have Regular SQL Failover Clustering when database is in Azure Cloud?

I understand the benefits having Availability Groups in Azure Cloud for Database-Level protection. People can transition heavy Read queries to the secondary replica (to prevent locking-blocking, tempdb issues), offload maintenance tasks, etc.

However why would someone require Failover Clustering in Azure Cloud for Server-level protection? Don't Cloud Services inherently offer server level protection by itself? This is different to question which asks about Availability Groups: Any Reason to have AlwaysOn Failover Clustering in Azure Cloud? , this question is about FCI

Best Answer

Is there a reason to have Regular SQL Failover Clustering when database is in Azure Cloud?

This completely depends on your use cases, knowledgebase, requirements, and cost.

In some ways it would make sense to use S2D and setup an FCI over an AG, most notably the storage costs for high perf disk can be larger. Since each node in an AG has a whole copy of the database, it may inflate costs or may not be required to have multiple separate copies in a single site.

People can transition heavy Read queries to the secondary replica (to prevent locking-blocking, tempdb issues), offload maintenance tasks, etc.

Be very careful with this wording, as there can still be redo blocking, ghost record cleanup, version store blowing out tempdb, and no maintenance (except checkdb and backups) can be done on the database. This will also incur extra I/O charges for the reads/writes and also for the base disk usage in Azure whereas the FCI would not.

Don't Cloud Services inherently offer server level protection by itself? Don't Cloud Services inherently offer server level protection by itself?

Not to argue the point, but as the comments have said there can be issues with the physical location/hardware/connection that the "cloud" is running, so just by having it there doesn't mean you get to walk away without a care in the world. In Azure, for example there are different domains to make sure servers aren't taken down all at the same time for things like patching, which is an example of something that still takes place even in the cloud and isn't indicative of a failure or issue (such as hardware lost/down/etc.).

There are different levels of offerings, some are IaaS (such as this) and some are PaaS (such as AzureDB). In IaaS offerings it is basically you running your own VMs, whether in the cloud or in some datacenter you own the same applies. If this question were to be geared towards a PaaS item, then it would be incumbent upon the PaaS team to do this as you the end user won't have control over this, by choosing IaaS you're taking control over this.

By using IaaS you're responsible for configuring and managing the resources to have uptime and availability, thus it is incumbent upon you for IaaS to choose the correct cloud, OS, and software settings/configurations. Some may prove to be more expensive, tedious, etc., than others.