What methods are there for provisioning shared storage for a SQL Server 2012 Cluster in Azure?
As a Data Platform consultant, I can think of many ways that this could be achieved, these could include
- Using an Iscsi target from some provisioned storage e.g. a scale out file server or virtual SAN
- Using Windows Server 2016 Storage Spaces Direct
- Using volume level mirroring Software
All these are viable solutions and for every N consultants that you stick in a room toy are likely to get N^(n-1) variations on the answers above (plus of course some that are way out there).
What are the supported methods for provisioning shared storage for a SQL Server 2012 Cluster in Azure?
Prior to 1st March 2017 there was no official statement as to the supported methods of providing shared storage in azure but there were blog posts and recommendations around using SIOS DataKeeper Cluster Edition. This was picked up by clients that I was working with and escalated through our contacts at Microsoft to try and get a definitive support statement.
On the 1st of March Microsoft updated their blog post to State:
- SQL Server failover cluster instances (FCI) are supported in the following scenarios:
- SQL Server FCI on Windows Server 2016 with Storage Spaces Direct. For more information, see Configure SQL Server Failover Cluster Instance on Azure Virtual Machines.
- SQL Server FCI on Windows Server 2012 or Windows Server 2012 R2 through SIOS DataKeeper (a third-party clustering solution).
What things should I be aware of when clustering SQL Server 2012 in Azure
The following is a list of bullet points that I have discovered and are
- SIOS DataKeeper cluster Edition does not support mount points without 3rd party scripts so design your deployment to use individual volumes
- SIOS Support is handled in the UK by Openminds, these people together with SIOS cannot be more helpful in providing information and support (reach out to them if you need help, they are more than willing to assist)
- The SQL Server clustering required an Azure Internal Load Balancer, this takes a bit of getting your head around
- Ensure that NetBios is switched off for the SQL Server IP Address otherwise you will not be able to connect
- Ensure that RPC/WMI (TCP Port 135) is added to your load balancer rules to allow service status and control
- Ensure that DAC (TCP Port 1434) is added to your load balancer rules to allow your “get out of jail free” connection (Dedicated Admin Connection)
- Load balancer rules are currently based on a combination of port and back end servers, this combination needs to be unique. This means that Port 135 can only be used once (Not Great for multiple instances). See my other blogs for a workaround
- You will need to disable the SQL Server browser (as it cannot be used for additional instances) as the workaround provided in my other blog posts is only for TCP and not UDP