Windows Azure Archives - SIOS SANless clusters

Windows Azure Disaster Recovery Options Just Got Better With ExpressRoute

February 19, 2018 by Jason Aw Leave a Comment

Just today I received notice that ExpressRoute, a new Windows Azure Network option, was release in Preview. Essentially ExpressRoute will now allow you to lease a private connection to the Windows Azure Cloud through a limited number of network service providers and exchange providers. Speeds ranging from 10 Mbps through 10 Gbps are available through either an Exchange Provider or Network Service Provider.

What’s Good About ExpressRoute?

Previously the only way to connect your on-premise site was to configure a site-to-site VPN to your virtual network. While this is a nice option, having a direct connection like ExpressRoute that bypasses the public network is going to allow for much less latency and a more reliable connection.

Adjust Capacity For Disaster Recovery Or For Additional Data Protection

If you are trying to use data replication solutions like DataKeeper to replicate data into the Azure cloud for disaster recovery, or out of Azure to your private network for additional data protection, you will appreciate the various different link speeds available which will allow you to adjust capacity should your bandwidth needs change over time.

Even if you are not ready to move your whole production network to the clouds at this time, I believe using something like Windows Azure in lieu of maintaining a separate disaster recovery facility makes a lot of sense, especially now that robust direct connectivity options are available.

Reproduced with permission from https://clusteringformeremortals.com/2014/02/21/windows-azure-disaster-recovery-options-just-got-better-with-expressroute/

Windows Azure High Availability Options For SQL Server

February 18, 2018 by Jason Aw Leave a Comment

Downtime! Who Should Bear The Responsibility?

Ensuring High Availability Options For SQL Server all the time is probably a main reason we make use of Cloud Services. However, protecting against downtime associated with cloud outages is something that anyone deploying on ANY cloud service needs to address. It is easy to simply deploy your app in “the cloud” and assume that it is someone else’s problem to manage now. Cloud providers probably have more resources and expertise to ensure your servers stay up. But the ultimate responsibility to ensure that your critical application is available rests squarely on your shoulders.

High Availability Options For SQL Server Isn’t As Easy As ABC

Believe it or not, simply deploying your SQL Server in Windows Azure does not make it “highly available”. To make it highly available, you must use traditional tools and techniques that you might use in your own datacenter. While there is some varying of opinion on this topic, I believe that High Availability Options For SQL Server 2012/2014 are as follows:

Regardless of which option you choose, you are going to want to become familiar with the Windows Azure Fault Domain as described below:

“Nonetheless, in Windows Azure a rack of computers is indeed identified as a fault domain. And the allocation of a fault domain is determined by Windows Azure at deployment time. A service owner cannot control the allocation of a fault domain, however can programmatically find out which fault domain a service is running within. Windows Azure Compute service SLA guarantees the level of connectivity uptime for a deployed service only if two or more instances of each role of a service are deployed”

Have your SQL Server reside in different Fault Domains

As you start deploying Windows Azure VMs, ensure each SQL Server and any “witness” servers reside in different Fault Domains. You do this by putting all of the VMs in the same “Availability Set”. Essentially, each server in the same Availability Set resides in a different Fault Domain, hopefully eliminating failures.

Windows Azure High Availability Options For SQL Server — VMs in the same Availability Set provisioned in different Fault Domains

Put all VMs in different Fault Domains and configure a SQL Server Failover Cluster or Availability Group to protect against the usual types of outages that might be localized to a single rack of servers, AKA, Fault Domain. I’ve written a step-by-step article entitled Creating a SQL Server 2014 AlwaysOn Failover Cluster (FCI) Instance in Windows Azure IaaS with DataKeeper which should help in your endeavor to build resiliency within the Azure cloud for your SQL Server.

But What Happens If Windows Azure Has A Major Outage That Takes Out A Whole Region?

Natural disaster or human error would likely be the cause of such an outage. Unfortunately, at this point there is no way to stretch an Azure Virtual Private Network between two different Azure Regions. This includes Southeast Asia. However, the Azure Virtual Private Network can support a site-to-site VPN connection with a limited number of VPN devices. These devices are from Cisco, Juniper and even Microsoft RRAS.

How About Somewhere Outside Of Azure?

That leads us to thinking about alternate locations outside of Azure, even our own private data center. I recently wrote a step-by-step article that explains how to extend your on premise datacenter to the Azure Cloud. Connect datacenter to Windows Azure, configure AlwaysOn Availability Groups or AlwaysOn Failover Clustering (multisite) for protection from catastrophic Azure failures. I’ve written previously about the Advantages of Multisite Clustering vs. Availability Groups. So in my lab I decided to create a 2-node SQL Failover Cluster Instance up in Azure and then add a 3^rd node in my primary data center. I’ve written the detailed configuration steps in my blog post entitled Creating a Multisite Cluster in Windows Azure for Disaster Recovery.

If you rather use AlwaysOn Availability Groups, you probably want to visit the tutorials called AlwaysOn Availability Groups in Windows Azure (GUI) and Listener Configuration for AlwaysOn Availability Groups in Windows Azure. If you are using SQL 2008 R2 or earlier I’m sure you could configure database mirroring. At this point if your are moving to Azure, I’m assuming you are probably deploying SQL Server 2012 or 2014. Other technology like Log Shipping and Replication are options for moving data, but I don’t consider them high availability solutions.

Reproduced with permission from https://clusteringformeremortals.com/2014/01/15/windows-azure-high-availability-options-for-sql-server-azure-cloud-iaas/

Create Multi-Site Cluster In Windows Azure For DR With DataKeeper

February 15, 2018 by Jason Aw Leave a Comment

Create Multi-Site Cluster In Windows Azure For DR With DataKeeper

This is the 4^th post in my series on High Availability and Disaster Recovery for Windows Azure with SIOS DataKeeper Cluster Edition. This is a step-by-step post on the processes to create multi-site cluster. It builds upon the Azure configuration that we built during my first three articles…

We are now going to extend the existing cluster (SQL1 and SQL2) to your local data center, SQL3. This configuration will give you both high availability for your application within the Azure Cloud, as well as a disaster recovery solution should Azure suffer a major outage. You could configure this in reverse as well with your on premise datacenter as your primary site and use Windows Azure as your disaster recovery site. And of course this solution illustrates SQL Server as the application, but any cluster aware application can be protected in the same fashion.

At this point, if you have been following along your network should look like the illustration below.

Add SQL3 To The Cluster

To add SQL3 to the cluster, the first thing we need to do is make sure SQL3 is up and running, fully patched and added to the domain. We also need to make sure that it has an F:\ drive attached that is of the same size as the F:\ drives in use in Azure. And finally, if you relocated tempdb on the SQL cluster, make sure you have the directory structure where tempdb is located pre-configured on SQL1 as well.

Next we will add the Failover Cluster feature to SQL3.

Create A Multi-Site Cluster In Windows Azure For DR With DataKeeper

With failover clustering installed on SQL3, we will open Failover Cluster Manager on SQL1 and click Add Node

Create A Multi-Site Cluster In Windows Azure For DR With DataKeeper

Select SQL3 and click Next

Create A Multi-Site Cluster In Windows Azure For DR With DataKeeper

Run all the validation tests on SQL3

Create A Multi-Site Cluster In Windows Azure For DR With DataKeeper

Let’s take a look at some of the warnings in the validation report

The RegisterAllProvidersIP property is set to 1, which can be good when you intend to Create Multi-Site Cluster. You can read more about this setting here: http://technet.microsoft.com/en-us/library/ca35febe-9f0b-48a0-aa9b-a83725feb4ae

Create A Multi-Site Cluster In Windows Azure For DR With DataKeeper

This next warning talks about only having a single network between the cluster nodes. At this time Azure only supports a single network interface between VMs. Do note there is nothing you can do about this warning. However, this network interface is fully redundant behind the scenes. Safely ignore this message.

Create A Multi-Site Cluster In Windows Azure For DR With DataKeeper

Of course you are going to see a lot of warnings around storage. That’s because this cluster has no shared storage. Instead it relies on replicated storage by SIOS DataKeeper Cluster Edition. As stated below, this is perfectly fine as the database will be kept in sync with the replication software.

Create A Multi-Site Cluster In Windows Azure For DR With DataKeeper

We are now ready to add SQL3 to the cluster.

Create A Multi-Site Cluster In Windows Azure For DR With DataKeeper

Once you click Finish, SQL3 will be added to the cluster as shown below.

Create A Multi-Site Cluster In Windows Azure For DR With DataKeeper

However, there are a few things we need to do to complete this installation. Next we will work of the following steps:

Add an additional IP address to the Cluster Name Object
Tune the heartbeat settings
Extend the DataKeeper mirror to SQL3
Install SQL 2014 on SQL3

Add An Additional IP Address To The Cluster Name Object

To Create Multi-Site Cluster, we added SQL3 to the cluster. So from a single site cluster, it becomes a multi-subnet cluster. If the cluster was originally created as a single site cluster and you later add a node that resides in a different subnet, you have to manually add a second IP address to the Cluster Name Object and create an OR dependency. For more information on this topic, view the following article. http://blogs.msdn.com/b/clustering/archive/2011/08/31/10204142.aspx

To add a second IP address to the Cluster Name Object (CNO), we must use the PowerShell commands described in the article mentioned above.

Create A Multi-Site Cluster In Windows Azure For DR With DataKeeper

Now if you are following along with the MSDN article I referenced, you would expect to see these “NewIP” somewhere in the GUI. However, at least with Windows 2012 R2 I am not currently seeing this resource in the GUI.

Create A Multi-Site Cluster In Windows Azure For DR With DataKeeper

However, if I right click on the SQLCLUSTER name and choose properties and try to add NewIP as a dependency, I see it is listed as a possible resource.

Create A Multi-Site Cluster In Windows Azure For DR With DataKeeper

Choose “NewIP” and also make the dependency type “OR” as shown below.

Create A Multi-Site Cluster In Windows Azure For DR With DataKeeper

Once you click OK, it now appears in the GUI as an IP Address that needs to be configured.

Create A Multi-Site Cluster In Windows Azure For DR With DataKeeper

We can now choose the properties of this IP Address and configure the address to use an IP address that is not currently in use in the 10.10.10.0/24 subnet, which is the same subnet where SQL3 resides.

Create A Multi-Site Cluster In Windows Azure For DR With DataKeeper

Tune The Heartbeat Settings

We now are ready to tune the heartbeat settings. Essentially, we are going to be a little more tolerant with network communication. Furthermore, since SQL3 is located across a VPN connection with some latency on the line and we only have the single network interface on the cluster nodes. I highly recommend you read this article by Elden Christensen to help you decide what the right settings for your requirements are:http://blogs.msdn.com/b/clustering/archive/2012/11/21/10370765.aspx

For our environment, we are going go to what he is calling the “Relaxed” setting by setting the SameSubnetThreshold to 10 heartbeats and the CrossSubnetThreshold to 20 heartbeats.

The commands are:

(get-cluster).SameSubnetThreshold = 10

(get-cluster).CrossSubnetThreshold = 20

Create A Multi-Site Cluster In Windows Azure For DR With DataKeeper

What this means is that heartbeats will continue to be sent every 1 second, but a SQL1 and SQL2 will only be considered dead after 10 missed heartbeats. SQL3 will be dead after 20 missed heartbeats. This will increase your Recovery Time Objective slightly (5-10 seconds), but it will also eliminate potential false failovers.

Extend The DataKeeper Mirror To SQL3

Before we can install SQL 2014 on SQL3 we must extend the DataKeeper mirror so that it includes SQL3 as a replication target. Of course you must install DataKeeper Cluster Edition on SQL3 first, and make sure that is has a F:\ drive at least as big as the source of the mirror. Once DataKeeper is installed

Create A Multi-Site Cluster In Windows Azure For DR With DataKeeper

Install SQL 2014 On SQL3

Now it is time to install SQL 2014 onto the 3^rd node. The process is exactly the same as it was to install in on SQL2. Start by launching SQL Setup on SQL3.

Create A Multi-Site Cluster In Windows Azure For DR With DataKeeper

Run through all the steps…

Create A Multi-Site Cluster In Windows Azure For DR With DataKeeper

At this point in the installation you have to pick an IP address that is valid for SQL3’s subnet. The cluster will add this IP address with an “OR” dependency to the client access point.

Create A Multi-Site Cluster In Windows Azure For DR With DataKeeper