Time is running out for SQL Server 2008/R2 support – here’s what to do about it

Time is running out for SQL Server 2008/R2 support – here’s what to do about it
David Bermingham is recognized within the technology community as a high availability expert and has been honored by his peers by being elected to be a Microsoft MVP for the past 8 years, 6 years as a Cluster MVP and 2 years as a Cloud and Datacenter Management MVP. David’s work as director, Technical Evangelist at SIOSTechnology Corp., has him focused on evangelizing Microsoft high availability and disaster recovery solutions as well as providing hands-on support, training and professional services for cluster implementations. David holds numerous technical certifications and draws from more than thirty years of IT experience, including work in the finance, healthcare and education fields, to help organizations design solutions to meet their high availability and disaster recovery needs. David's work recently has him focused on high availability and disaster recovery solutions for the public and private cloud.

Extended support for SQL Server 2008 and 2008 R2 will end in July 2019, giving database and system administrators precious little time to make some necessary changes. Upgrading the software to the latest version is always an option, of course, but for a variety of reasons, that may not be viable for some applications. So Microsoft is providing an alternative: Get three more years of free Extended Security Updates by migrating to the Azure cloud.

While their 2008 vintage may designate these as “legacy” applications, many may still be mission-critical and require some form of high availability (HA) and/or disaster recovery (DR) protections. This article provides an overview of the options available within and for the Azure cloud, and highlights two common HA/DR configurations.

Availability options within the Azure cloud

The Azure cloud offers redundancy within datacenters, within regions and across multiple regions. Redundancy within datacenters is provided by Availability Sets that distribute servers across different Fault Domains residing in different racks to protect against failures at the server and rack levels. Within regions, Azure is rolling out Availability Zones (AZs), which consist of at least three datacenters inter-connected via high-bandwidth, low-latency networks capable of supporting synchronous data replication. For even greater resiliency, Azure offers Region Pairs, where a region gets paired with another within the same geography (e.g. US or Europe) to protect against widespread power or network outages, and major natural disasters.

Administrators should be fully aware, however, that even with the 99.99% uptime assurances afforded by AZs, what counts as downtime excludes many common causes of failure at the application level. Two quite common causes of failure explicitly excluded from the Azure Service Level Agreement are the use of software not provided by Microsoft and what could be called “operator error”—those mistakes mere mortals inevitably make. In effect, the SLA only guarantees “dial tone” for the servers, leaving it up to the customer to ensure uptime for the applications.

Achieving satisfactory HA protection for mission-critical applications is problematic in the Azure cloud, however, owing to the lack of a storage area network (SAN) or other shared storage needed for traditional failover clustering. Microsoft addressed this limitation with Storage Spaces Direct (S2D), a virtual shared storage solution. But S2D support began with Windows Server 2016 and only supports SQL Server 2016 and later. SQL Server’s more robust Always On Availability Groups feature, which was introduced in 2012, is also not an option for the 2008 versions.

Satisfactory DR protection is possible for some applications using Azure Site Recovery (ASR), Microsoft’s DR as a service (DRaaS) offering. While ASR automatically replicates entire VM images from the active instance to a standby instance in another datacenter, it requires manual outage detection and failover. The service is usually able to accommodate Recovery Point Objectives (RPOs) ranging from a few minutes to a few seconds, and Recovery Time Objectives (RTOs) of under one hour.

Third-party failover clustering solutions

With SQL Server’s Failover Cluster Instances (FCIs) requiring shared storage, and with no shared storage available in the Azure cloud, a third-party cluster storage solution is needed. Microsoft recognizes this need for providing HA protection, and includes these instructions for configuring one such solution in its documentation: High Availability for a file share using WSFC, ILB and 3rd-party Software SIOS DataKeeper.

Third-party cluster storage solutions include, at a minimum, real-time data replication and seamless integration with Window Server Failover Clustering. Their design overcomes the lack of shared storage by making locally-attached drives appear as clustered storage resources that can be shared by SQL Server’s FCIs. The block-level data replication occurs synchronously between or among instances in the same Azure region and asynchronously across regions.

The cluster is capable of immediately detecting failures at the application level regardless of the cause and without the exceptions cited in the Azure SLA. As a result, this option is able to ensure not only server dial tone, but also the application’s availability, making it suitable for even the most mission-critical of applications.

Two common configurations

With HA provisions for legacy SQL Server 2008/R2 applications being problematic in the Azure cloud, the only viable option is a third-party storage clustering solution. For DR, by contrast, administrators have a choice of using Azure Site Recovery or the failover cluster for both HA and DR. Here is an overview of both configurations.

Combining failover clustering for HA with ASR for DR affords a cost-effective solution for many SQL Server applications. The shared storage required by FCIs is provided by third-party clustered storage resources in the SANless HA failover cluster, and ASR replicates the cluster’s VM images to another region in a Region Pair to protect against widespread disasters. But like all DRaaS offerings, ASR has some limitations. For example, WAN bandwidth consumption cannot exceed 10 megabytes per second, which might be too low for high-demand applications.

More robust DR protection is possible by using the failover clustering solution in a three-node HA/DR configuration as shown in the diagram. Two of the nodes provide HA protection with rapid, automatic failover, while the third node, located in a different Azure region in a Region Pair adds DR protection.

This configuration uses a third-party cluster storage solution to provide both HA and DR protections across Azure Availability Zones and a Region Pair, respectively.

The main advantage of using the failover cluster for both HA and DR is the ability to accommodate even the most demanding RPOs. Another advantage is that administrators have a single, combined HA/DR solution to manage rather than two separate solutions. The main disadvantage is the slight increase in cost for licensing for the third node.

With two cost-effective solutions for HA/DR protection in the Azure cloud, your organization will now be able to get three more years of dependable service from those legacy SQL Server 2008/R2 applications.

https://www.cybersecuritycloudexpo.com/wp-content/uploads/2018/09/cyber-security-world-series-1.pngInterested in hearing industry leaders discuss subjects like this and sharing their experiences and use-cases? Attend the Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam to learn more.

View Comments
Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *