Move SQL Server 2008 And 2008 R2 Clusters To Azure For Extended Support

Earlier this year Microsoft announced extended support if you move SQL Server 2008 and 2008 R2 Clusters to Azure. For all the details, check out https://www.microsoft.com/en-us/sql-server/sql-server-2008. If you choose not to move, your extended support ends on July 9th, 2019.

If you are still running SQL Server 2008 R2, it’s probably because you never upgraded your application. Hence newer versions of SQL are not supported. Or perhaps, you decided not to fix what isn’t broken. Regardless of these reasons, you have just bought yourself another three years of support if you migrate to Azure.

Now migrating workloads to Azure is a pretty well documented procedure, using Azure Site Recovery. That process should be pretty seamless for you for your standalone instances of SQL Server.

But what about those clustered instances of SQL Server? You certainly don’t want to give up availability when you move to the Azure. Part of the beauty of Azure is that they have infrastructure that you can only dream of. However, it is incumbent upon the user to configure their applications to take full advantage of the infrastructure to ensure that your deployments are highly available.

With SQL Server 2008 and 2008 R2, high availability commonly means SQL Server Failover Clustering on either Windows Server 2008 R2 or Windows Server 2012 R2. If you are new to Azure, you will quickly discover that there is no native option that supports  shared storage clusters. Instead, you will need to look at a SANLess cluster solution such as SIOS DataKeeper. Microsoft list SIOS DataKeeper as the HA solution for SQL Server Failover Clustering in their documentation.

Getting Started

Let’s begin the move SQL Server 2008 And 2008 R2 Clusters To Azure For Extended Support. Here are the high level steps you will need to take.

• Replace the Physical Disk Resource in your existing on premise SQL Server cluster with a DataKeeper Volume Resource. Do the same for MSDTC resources if you use MSDTC.
• Remove your Disk Witness and replace it with a File Share Witness.
• Use Azure Site Recovery to replicate your cluster nodes into Azure, making sure each replicated node resides in a different Fault Domain or in different Availability Zones in Azure
• Recovery your replicate cluster nodes in Azure
• Replace the File Share Witness with a File Share hosted in Azure
• Configure the Internal Load Balancer in Azure for client redirection. This includes running the Powershell script on the local nodes to update the SQL Cluster IP resource to listen for the ILB probe
• Assuming the IP addresses and subnet of the SQL Server cluster instances changed as part of this migration, you will also need to do some cleanup of the cluster IP address and the DataKeeper job endpoints to reflect the new IP addresses

I know I left out a lot of the details. But if you find yourself in the position of having to do a lift and shift of SQL Server to Azure, or any cloud for that matter, I’d be glad to get on the phone with you to answer any questions you may have. Keep in mind, the same steps apply for any version of SQL that you plan to migrate to Azure.

If you need to move SQL Server 2008 And 2008 R2 Clusters To Azure, get in touch with us.
Reproduced with permission from Clusteringformeremortals.com