Windows Server Failover Cluster on Azure IAAS VM – Part 1 (Storage)
Hello, cluster fans. This is Mario Liu. I’m the Support Escalation Engineer in Windows High Availability team in Microsoft CSS Americas. I have a good news for you that starting in April, 2015, Microsoft supports Windows Server Failover Cluster on Azure IAAS VMs. Here is the supportability announcement for Windows Server on Azure VMs as the blog is written: https://support.microsoft.com/en-us/kb/2721672. Cluster feature is part of the announcement. This KB subjects to change once we make more improvements for WSFC on Azure IAAS VMs. Check the above link for the latest updates.
Today I’d like to share what are the main differences when you deploy a WSFC on-premises comparing with Azure VM. First, the VM OS must be Windows Server 2012 R2, or Windows Server 2008 R2 and Windows Server 2012 with hotfix https://support.microsoft.com/en-us/kb/2854082. Then, at a high level, the cluster feature does not change inside the VM. This is still a standard Server OS feature. The challenges are outside – Storage and Network. Let me start with Storage first.
The big block to implement cluster on Azure is that Azure does not provide native shared block storage to VMs, which is different than on-premises – Fiber Channel SAN or iSCSI. That limits SQL Server AlwaysOn availability groups (AG) the primary use case scenario in Azure because SQL AG does not need shared storage. Instead, it leverages replication at the application layer to replicate data across Azure IaaS VMs.
Till now, we have more options to work around the shared storage limitation; and that is how we can expand the scenarios beyond SQL AlwaysOn.
Option 1: Application-level replication for non-shared storage
This is the same as SQL Server AlwaysOn availability groups.
Option 2: Volume-level replication for non-shared storage
In other words, 3rd party storage replication.
A common 3rd party solution is SIOS DataKeeper Cluster Edition. Microsoft and SIOS have worked together and ensured this solution is fully supported. For more details, please check SIOS’s website:
https://us.sios.com/products/datakeeper-cluster/
Option 3: Leverage ExpressRoute for remote iSCSI Target shared block storage for file based storage from an Azure IaaS VMs
ExpressRoute is an Azure exclusive feature. It enables you to create dedicated private connections between Azure datacenters and infrastructure that’s on your premises. It has high throughput network connectivity to guarantee that the disk performance won’t be degraded.
One of the existing examples is: NetApp Private Storage (NPS) exposes an iSCSI Target via ExpressRoute with Equinix to Azure IaaS VMs
https://channel9.msdn.com/Blogs/Windows-Azure/Availability-on-Demand-ASR-with-NetApp-Private-Storage
For more details about ExpressRoute, please see https://azure.microsoft.com/en-us/services/expressroute/
Option 4 (Not supported): Use an Azure VM as iSCSI Target to provide shared storage to cluster nodes.
It uses the similar iSCSI concept as in option 3 but is much more simplified. You move the iSCSI target into Azure. The reason we do not support this is mainly due to performance hit. However, if you’d like to set up a cluster in Azure VMs as a proof of concept, you’re welcome to do so. This is the easiest way to have the shared storage. Please limit this option for development and lab purpose and don’t use it in production.
There will be more options to present “shared storage” to cluster as new scenarios present in the future. We’ll update this blog along with the KB once new announcement becomes available. As long as you fix the storage, you’ve built the foundation of the cluster. In my next blog, I’ll go through the network part. Stay tuned and enjoy the clustering in Azure!
Mario Liu
Support Escalation Engineer
CSS Americas | WINDOWS | HIGH AVAILABILITY
Comments
- Anonymous
June 17, 2015
The comment has been removed