eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Even though the cloud finally has become the preferred carrier for many—but certainly not most—enterprise applications, IT organizations remain hesitant to trust all public clouds to host Microsoft SQL Server applications.
Why? What are the differences among the Big 5: Google Cloud, IBM Cloud, AWS, Oracle and Microsoft Azure? Glad you asked. Among the concerns is the increased risk and complexity associated with running SQL Server in any public cloud, where high-availability (HA) clustering configurations can be challenging to implement—and can increase the overall cost of the solution.
In this eWEEK Data Point Interview, Dave Bermingham (pictured), Microsoft Cloud and Data Center Management MVP at SIOS Technology, offers readers a list of seven things IT professionals should know when considering running Microsoft SQL Server in the Google Cloud.
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 eight years, six years as a Cluster MVP and two years as a Cloud and Data Center Management MVP.
Data Point 1: High-availability clustering can get considerably more complicated in the cloud’s virtual environment.
The layers of abstraction across compute, storage and networking resources in a virtualized public cloud infrastructure can make it extraordinarily difficult to ensure HA provisions function as desired under all possible failure scenarios. This is especially true in a multi-site or hybrid cloud environment where additional networking configurations are required and cluster quorum settings must be considered carefully.
Data Point 2: Networking in the Google Cloud does not support gratuitous ARP, meaning typical cluster client redirection does not work.
While virtual IP addresses and client access points are still used for client redirection, additional work must be done at the network layer including creating customer subnets and host specific routes to help facilitate client redirection.
Data Point 3: Resilient Storage Area Network (SAN) services are not available in the Google Cloud.
Cluster-aware storage simply does not exist as a service in the Google Cloud, and being cognizant of the cluster is fundamentally important to achieving high availability. Indeed, without full and continuous awareness of the cluster’s status end to end, a failover can fail or result in data being lost or corrupted.
Data Point 4: Overlaying purpose-built SAN-less cluster software atop the Google Cloud Platform can overcome these and other limitations to afford mission-critical high availability.
It is possible to create a shared-nothing HA cluster configuration within the Google Cloud or in a hybrid cloud environment using special shared-nothing software purpose-built for real-time data replication and automatic failover. These solutions normally offer support for virtually any application, and some have features specifically designed for SQL Server.
Data Point 5: SAN-less clusters can make the less expensive Standard Edition with Always On Failover Clustering just as reliable as Enterprise Edition’s Always On Availability Groups.
One way organizations can be assured of providing high availability for SQL Server applications in the Google Cloud is to use Always On Availability Groups in the Enterprise Edition. But because this approach is considerably more expensive, the cost is normally only justifiable if other features of Enterprise Edition are also required. With a SAN-less cluster designed for use with SQL Server, however, all database applications can be made HA using only the Standard Edition.
Data Point 6: Seamless use of Windows Server Failover Clustering dramatically simplifies the management of high-availability SQL Server applications.
A common technique for supporting Failover Cluster Instances (FCIs) in SQL Server Standard Edition is to use the familiar Windows Server Failover Clustering feature built into the operating system. Using WSFC simplifies satisfying the need for automatic and seamless failover and failback on a fully redundant and fully synchronized multi-site configuration. Such seamless failover/failback also enables software updates and patches to be installed with minimal downtime.
Data Point 7: SAN-less cluster configurations afford additional important advantages of being storage agnostic and delivering improved performance.
Continuously replicating and synchronizing data across the wide-area network (WAN) can have an adverse impact on performance, especially when special provisions are required to accommodate different storage systems. SAN-less clusters that support robust capabilities like block-level replication and data compression provide the means to assure high performance and high availability in cloud and hybrid-cloud environments where traditional SAN-based replication solutions do not apply.