Finding Common Ground Between Sys Admins and Database Admins, Part 3

SANless failover cluster software provides a versatile and affordable high availability solution that satisfies the needs of both Sys and DB Admins.

Dave Bermingham is Microsoft Cloud and Datacenter Management MVP at SIOS Technology, and David Klee is Founder & Chief Architect at Heraflux Technologies. 

The first article in this three-part Industry Perspectives series examined the different perspectives Sys and DB Admins have regarding high availability, with SANs as an example of how these differences can create conflict. The second article dove deeper into potential conflicts involving the HA provisions for SQL Server, VMware and public cloud services. This third and final part outlines how SANless failover clustering can satisfy the HA needs of both Sys and DB Admins.

Although it is certainly possible to implement high-availability provisions that operate independently of the servers’ operating system, leveraging useful OS features can be advantageous for a variety of reasons. Among the more compelling ones are inherent compatibility, greater staff familiarity, higher performance, and lower capital and operating expenditures. For this reason, failover clustering for Windows and Linux are covered separately.

Failover Clusters for Windows

Windows Server Failover Clustering is a powerful and proven feature included with the Windows Server OS. But on its own, WSFC does not provide a complete HA solution for mission-critical database applications. Something more is needed, and that something is increasingly the application-level protection afforded by a SANless failover cluster.

The typical SANless failover clustering software leverages WSFC to deliver carrier-class high availability cost-effectively. All of these solutions provide a combination of real-time data replication, continuous application monitoring and configurable failover/failback policies. Most are also able to operate across both the LAN and WAN in private, public and hybrid clouds.

Some of the more robust solutions also offer advanced capabilities like wizard-driven ease of configuration and operation, a choice of block-level synchronous or asynchronous replication, WAN optimization to maximize performance, and manual switchover of primary and secondary server assignments to facilitate planned maintenance.

Although these solutions are generally storage-agnostic, enabling them to work with SANs of endless variety, shared-nothing SANless failover clusters are preferred for critical database applications because they eliminate potential single points of failure.

Failover Clusters for Linux

The Linux operating system lacks the equivalent of WSFC as a holistic foundation for high availability. In its place is a collection of open source components that include, at a minimum, data replication, server clustering and a resource manager with a heartbeat monitor. But because getting the full application-level HA stack to work well using open source software is extraordinarily difficult, only very large organizations have the wherewithal needed to even consider taking on the task.

A SANless failover cluster designed for Linux offers a more dependable and affordable alternative to the do-it-yourself open source software project. While some of these solutions might leverage useful features available in Linux and/or related open source software, most employ technologies proven in other environments. Either way, these solutions can offer the same combination of mission-critical protection and ease-of-use as those available for Windows.

Be aware, however, that some Linux HA solutions may offer robust support only for open source database software and not commercial databases like SQL Server. Or their support for SQL Server might require the use of Always On Availability Groups in the more expensive Enterprise Edition. So be sure to find one that works well with the Always On Failover Cluster Instances in the Standard Edition.

Eliminating Single Points of Failure

In a failover cluster with only two nodes, a single point of failure exists whenever one of the server instances is out of service, including for service—an inevitable and unacceptable situation for database applications. Shown in the diagram is a three-node SANless failover cluster that maintains protection during both planned maintenance and that rare occurrence of two concurrent failures.

A three-node SANless failover cluster experiencing two concurrent failures

In this example, server #1 is initially the primary that replicates data to both servers #2 and #3. If it experiences a problem, the cluster automatically fails over to server #2, which then becomes the primary replicating data to server #3. After the IT department repairs and returns server #1 to service, it could be restored as the primary or server #2 could continue in that capacity replicating data to both servers #1 and #3. Should server #2 fail before server #1 is again operational, the application would failover to server #3, as shown.

Conclusion

SANless failover cluster software provides a versatile and affordable high availability solution that satisfies the needs of both Sys and DB Admins. Sys Admins get a single, easy-to-use solution for all of the organization’s HA needs, from the Windows and/or Linux applications that can tolerate some downtime to those that cannot—ever. DB Admins get both high availability and high performance without hassle or hits to their budgets. And the CIO can now check this important item off the to-do list.

Opinions expressed in the article above do not necessarily reflect the opinions of Data Center Knowledge and Informa.

Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish