SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

Date: June 30, 2023
Tags: , ,

Achieving HADR for SQL Server Without Breaking the Bank

Achieving HA/DR for SQL Server Without Breaking the Bank

High availability and disaster recovery (HA/DR) are essential requirements for all database environments, especially mission-critical ones. However, many businesses face challenges in achieving HA/DR without significantly inflating costs. If you’re grappling with these issues, this article will shed light on an effective solution.

SQL Server Standard Edition is widely used, but it comes with certain limitations: it supports only two nodes in a cluster. However, by leveraging the capabilities of SIOS DataKeeper Cluster Edition, you can overcome this limitation, enabling replication of data to a third node for disaster recovery.

This strategy could save you over 70% on your SQL Server licensing by allowing you to use SQL Server Standard Edition to create a SANLess SQL Server Failover Cluster Instance (FCI) instead of upgrading to SQL Server Enterprise Edition and using Always On Availability Groups.

This blog post aims to guide you through the process of using SIOS DataKeeper for data recovery on a third node that is not part of the cluster.

Configuring Your Nodes

In this scenario, let’s consider that you have two nodes, namely DataKeeper-1 and DataKeeper-2, configured in a cluster. These nodes have their E drive replicating with each other. Also, DataKeeper-1 is replicating to a third node, DataKeeper-3, which is not part of the cluster. It’s important to note that with SQL Server Standard Edition, the third node can never be part of the cluster.

Preparing the Third Node

Firstly, ensure that DataKeeper-3 is separate from the cluster. With this, you now have a two-node cluster (DataKeeper-1 and DataKeeper-2) with SQL Server configured as a failover cluster instance, but still replicating to the third node, DataKeeper-3, using SIOS DataKeeper.

Navigating a Disaster Recovery Process

So, how would this work in an actual disaster? Here are the steps you would need to follow:

  1. Simulate a Disaster: In this case, to simulate a disaster, we take SQL Server offline on the cluster (DataKeeper 1 and 2).
  2. Switch to DataKeeper 3: With SQL Server offline, we switch over to DataKeeper-3. The volume E on DataKeeper 3, however, is initially not accessible.
  3. Unlock the Volume: To unlock the volume on DataKeeper-3, you would need to execute a command-line operation as shown in the tutorial video called ‘emcmd . switchovervolume’
  4. Attach Databases: In a real disaster, you’ll want to have a standalone instance of SQL Server running on DataKeeper-3. From this standalone instance, you could then attach the user-defined databases.
  5. Replicate Back to the Cluster: Data written on DataKeeper-3 is replicated back to DataKeeper-1 and DataKeeper-2. This can be verified using the SIOS DataKeeper interface.

Post-Disaster Recovery

Once the disaster is resolved, you can switch back the volume to the original source using a similar process.

By leveraging SIOS DataKeeper Cluster Edition, you can implement a robust, cost-effective, and efficient high availability/disaster recovery strategy for your SQL Server environment. This process not only helps save significant costs by eliminating the need for upgrading to SQL Server Enterprise Edition, but it also ensures data availability and a quick recovery during a disaster.

Check out this video for a complete walkthrough of the process and ensure your SQL Server remains resilient, without breaking the bank.

Reproduced with permission from SIOS