Businesses today face a great number of uncertainties on a daily basis. From natural disasters to power outages and network service issues, IT teams are constantly pressured to keep their organization’s applications and sensitive data online and available at all times.
Despite the abundance of risks, too many businesses are not adequately taking precautions as 1 in 5 companies don’t have a disaster recovery plan. Many organizations already rely on SQL Server for its scalability and performance abilities but haven’t built a holistic business continuity plan due to high availability (HA) and disaster recovery (DR) challenges.
In March, we released DxEnterprise Extended Vhosts – new technology aimed to optimize SQL Server HA and DR for greater business resilience. DH2i Product Manager Connor Cox recently held a demo to show how this new technology can be used to easily build a unified SQL Server HA and DR environment that achieves complete business resilience. For a deep dive into the session, check out the highlights below.
This demo starts with an environment that contains an on-premises site, which has a 4-node DxEnterprise cluster with HA instances and shared storage set up between the nodes. We will show how to add 2 nodes that are running on Linux in Azure to the existing cluster and then add an HA instance along with shared storage to those Linux nodes. We’ll finish off by using DxEnterprise Extended Vhosts, a stacked-clustering technology, to build a hybrid, cross-platform Availability Group (AG) between the HA instances to achieve both local HA and DR between on-premises and the cloud.
Tour On-premises Cluster
The image below shows DxAdmin, the management UI for DxEnterprise that enables admins to manage their DxEnterprise clusters. Any tasks that can be performed using DxAdmin can also be done using the CLI method. The cluster view displays an existing DxEnterprise cluster (DxCluster) which contains 13 instances running across 4 different VMs (DEMO1, DEMO2, DEMO3, DEMO4). The green indicates the VM where each instance is active on. A key factor to note is that DxEnterprise supports any version of SQL Server (version 2017+ for AGs), allowing a mix of multiple different SQL Server versions in our single cluster to provide flexibility. DxEnterprise also enables us to stack multiple active instances per node to achieve consolidation (displayed in the image below). The first step is to add 2 remote Red Hat Linux nodes into this environment.
DxAdmin Management Console
Add 2 Azure Linux Nodes
In this scenario, DxEnterprise has already been installed onto the RHEL servers. Starting with the “MRKTRHEL3” node, use the dxcli join-cluster command and enter y to continue joining the node. You’ll then be asked if you want to join via NAT Proxy – a secure tunneling feature that utilizes DH2i’s Matchmaking service to privately introduce disparate nodes to one another. Once the nodes find one another, communication thereafter is direct so that no data ever flows through that entity. Enter y to continue.
DxEnterprise Cluster Management
Next, you’ll enter the passkey which can be generated from the existing cluster by clicking “Cluster Membership,” “Manage OTPK,” then “New” and setting the appropriate expiration date/time. Use the same OTPK to join the second Linux node using the dxcli join-cluster command (MRKTRHEL2).
Once you’ve entered the passkey for both nodes, each will now show as a part of the existing DxEnterprise cluster – all completed without the use of VPNs or the risk of exposing open ports. Furthermore, you can see that we are running several different versions of Windows Server and Linux operating systems within the cluster – a native capability of DxEnterprise technology to help simplify datacenter management and offer additional flexibility.
DxEnterprise Cluster with Joined Linux Nodes
Add Highly Available (HA) Instances to Linux Nodes
The next step is to configure the HA instance that will run between the Linux nodes. We’ll start by creating a Virtual Host (Vhost) – a name and IP address that we associate members to. Right-click on “Virtual Hosts” in the tree view on the left-hand side and click “Add a virtual host.” You’ll name the Vhost and assign the appropriate IP address that will be bound to the active node for the Vhost, in this case, 10.1.4.101. Users have the option to assign multiple IP addresses or none at all, depending on the scenario.
Next, you’ll supply the probe port, which is generally used in cloud environments where an internal load balancer is set up to route an active node. Our active Linux nodes are in the Azure cloud, so we will supply the probe port 30001. Finish off by selecting the 2 Linux nodes so that they are listed under “Selected Members” and click “Yes” when asked to commit to the changes.
Creating a Virtual Host (Vhost)
You can now see that the new Vhost (VHOST0) will display under the tree view and the IP address is active on the MRKTRHEL2 node, making it bound to that node. This is what provides a consistent connection string regardless of where the instance is active and allows users to always connect via the Vhost name or IP address and the instance name or port number.
Vhost Details Pane
Vhost Member1 (MRKTRHEL2) Details
Add Shared Storage Between Linux Nodes
The next section will cover adding shared storage to the Vhost we just created. We’ve already provisioned an Azure shared disk to associate with the Vhost. You’ll start by right-clicking on “Diskgroups” in the tree view, then “Manage virtual host diskgroup” and select the available disk before submitting. This now means that wherever the Vhost is active, that disk is presented and provides read/write access only to the active node, ensuring full data integrity.
Vhost Diskgroup Management
The next step is adding a SQL Server instance to the Vhost. You must first install a SQL Server instance with the same name on both nodes that are part of the Vhost. Once installed, right-click on the Vhost (VHOST0) and select “Add SQL instance.” Select the instance you want to add (in this case MSSQLSERVER), provide a description (optional), then enter the path for the data, which is the volume associated with the cluster disk that’s under the Vhost. You’ll enter your login credentials to allow DxEnterprise to manage the instance, click “OK” and commit to the changes.
Vhost Instance Maintenance
Once processing is complete, the grey triangle to the left of “localhost” will switch to green, meaning the instance is now successfully being managed by DxEnterprise. The instance is now highly available and will automatically failover from node 1 (MRTKRHEL2) to node 2 (MRTKRHEL3) in the event of an outage or other types of service issues. Manual failovers can also be initiated from the tool if desired.
Highly Available SQL Server Instance
Build Hybrid, Cross-platform AG between HA Instances
The final step of the demo is to create an Availability Group (AG) between the HA instances on-site and in the cloud. First, we’ll create another Vhost, which is different from the previous Vhost created. This Vhost will be an Extended Vhost (ExVhost) which utilizes other Vhosts as members rather than nodes. You’ll provide a name for the Vhost (EXVHOST1), assign an IP address, if necessary, (in this case we don’t need to assign one), and then select “VHOST” as the member type. Next, select the Vhost members – we’ll use VHOST0 (our Vhost in Azure) and VHOST1 (our Vhost on-site). For this environment, we’ll move VHOST1 up in the list to serve as the primary for the AG as it is our local Vhost. Select “OK” and commit.
Creating an Extended Vhost (ExVhost)
You’ll be able to see the ExVhost running across the underlying Vhosts in the tree view and can now create the AG. Right-click on the ExVhost and then “Add availability group.” Give the AG a name (AG01), check the tunnel box to automatically build the networking tunnels used to create the AG between the sites, click “OK” and then “Yes” to confirm.
Add an Availability Group (AG)
Once processing is complete and the connection has been made, you can see that VHOST1/MAINTENANCE is now the primary. Regardless of where VHOST1 is active, the primary is VHOST1. VHOST1 can failover from one node member to another (i.e. from DEMO2 to DEMO3), providing local HA for the instance. On top of local HA, you now have remote disaster recovery (DR). Given that the entire site VHOST1 resides in goes down, VHOST0 will be promoted to the primary for the AG – in this case, MRKTRHEL2 would become the primary.
Availability Group (AG) Details
At this point, you can add and remove databases associated with the AG by right-clicking on the AG and selecting “Manage availability databases.” You can also use the management tool to perform manual failovers by right-clicking on a Vhost member under the ExVhost and selecting “Start hosting on Member.” This enables you to switch the primary (VHOST1) from where it’s currently active to the secondary (VHOST0).
We now have 2 failover instances (MSSQLSERVER and MAINTENANCE) that are linked together by the AG (AG01), delivering both local HA and DR remotely to the cloud. As a result, you have achieved complete business resilience between your on-premises site and the cloud.
Prefer to see the demo live in action? Follow this link to watch the full demo video: https://dh2i.com/dxenterprise-extended-vhosts-demo/
Ready to see how DxEnterprise can optimize your SQL Server HA and DR environment? Schedule a private demo, customized for your organization’s needs: https://dh2i.com/demo