SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

Archives for February 2018

Static IP In Azure Now Available

by Leave a Comment

Reserve Your Static IP in Azure

You now can reserve a static public IP for your cloud service in Azure. Usually, your static IP would release when you stopped all VMs in your cloud service. This way, you would be issued a new one the next time you started your VMs. You had to keep at least one VM running in each cloud service all the time, probably for the demos to work properly without a bunch of rework each time.

The Best Bit? It’s Free!

And even better news, the 1st five static IP addresses you reserve are FREE. Now I can turn off all of my VMs and sleep easy at night knowing that my addresses won’t change, breaking my SQL Server Failover Cluster demo. Most of all, I can be sure that I won’t exceed my $200 MSDN Azure credit, which is always a good thing.

http://msdn.microsoft.com/en-us/library/azure/dn690120.aspx

Reproduced with permission from https://clusteringformeremortals.com/2014/06/19/static-ip-in-azure-now-available/

Windows Server Failover Cluster Quorum Types In Windows Server 2012 R2

by Leave a Comment

Cluster Quorum types? What Does It Do?

Before we get started with all the great new cluster quorum types in Windows Server 2012 R2, we should take a moment and understand what it does and how we got to where we are today. Rob Hindman describes quorum best in his blog post…

“The quorum configuration in a failover cluster determines the number of failures that the cluster can sustain while still remaining online.”

The Beginning: Disk Only

Prior to Windows Server 2003, there was only one quorum type, Disk Only. Now there are different cluster quorum types. Disk Only is still available today, but is not recommended as the quorum disk is a single point of failure. In Windows Server 2003 Microsoft introduce the Majority Node Set (MNS) quorum. This was an improvement as it eliminated the disk only quorum as a single point of failure in the cluster. However, it did have its limitations. As implied in its name, Majority Node Set must have a majority of nodes to form a quorum and stay online. So, this quorum model is not ideal for a two node cluster where the failure of one node would only leave one node remaining. One out of two is not a majority, so the remaining node would go offline.

The Introduction Of File Share Witness

Microsoft introduced a hotfix that allowed for the creation of a File Share Witness (FSW) on Windows Server 2003 SP1 and 2003 R2 clusters. Essentially the FSW is a simple file share on another server that is given a vote in a MNS cluster. The driving force behind this innovation was Exchange Server 2007 Continuous Cluster Replication (CCR), which allowed for clustering without shared storage. Of course, without shared storage a Disk Only Quorum was not an option. Effective MNS clusters would require three or more cluster nodes. Hence, the introduction of the FSW to support two node Exchange CCR clusters.

The New Disk Witness Keeps A Copy Of Cluster Database

Windows Server 2008 saw the introduction of a new witness type, Disk Witness. Unlike the old Disk Only quorum type, the Disk Witness allows the users to configure a small partition on a shared disk that acts as a vote in the cluster, similar to that of the FSW. However, the Disk Witness is preferable to the FSW. This is because it keeps a copy of the cluster database and eliminates the possibility of “partition in time”. If you’d like to read more about partition in time, I suggest you read the File Share Witness vs. Disk Witness for local clusters.

Improvements

Windows Server 2012 continued to improve upon quorum options. It is my belief that many of these new features were driven by two forces: Hyper-V and SQL Server AlwaysOn Availability Groups. With Hyper-V, we began to see clusters that contained many more nodes than we have typically seen in the past. In a majority node set, as soon as you lose a majority of your votes, the remaining nodes go offline. For example, if you have a Hyper-V cluster with seven nodes, and you were to lose four of those nodes, the remaining nodes would go offline, even though there are three nodes remaining. This might not be exactly what you want to happen. So in Windows Server 2012, Microsoft introduced Dynamic Quorum.

Dynamic Quorum

Dynamic Quorum does what its name implies. It adjusts the quorum dynamically. So in the scenario described about, assuming I didn’t lose all four servers at the same time, as servers in the cluster went offline, the number of votes in the quorum would adjust dynamically. When node one went offline, I would then in theory have a six node cluster. When node two went offline, I would then have a five node cluster, and so on. In reality, if I continued to lose cluster nodes one by one, I could go all the way down to a two node cluster and still remain online. And, if I had configured a witness (Disk or File Share) I could actually go all the way down to a single node and still remain online.

Read more about cluster quorum types at….

http://blogs.msdn.com/b/microsoft_press/archive/2014/04/28/from-the-mvps-understanding-the-windows-server-failover-cluster-quorum-in-windows-server-2012-r2.aspx

Reproduced with permission from https://clusteringformeremortals.com/2014/04/29/understanding-the-windows-server-failover-cluster-quorum-in-windows-server-2012-r2/

Configure Sanless Hyper-V Failover Cluster With DataKeeper

by Leave a Comment

Configure Sanless Hyper-V Failover Cluster With DataKeeper

Questions about SANLess

Q. What is a SANLess cluster?
A. It is a cluster that uses local storage instead of a SAN.

Q. Why would I want to Configure Sanless Hyper-V Failover Cluster?
A. There are a few reasons:

  • Eliminate the cost of a SAN
  • Eliminate the SAN as a single point of failure
  • Take advantage of high speed storage options such a Fusion-io ioDrives and other high speed storage devices that plug in locally
  • Stretch the cluster across geographic locations for disaster recovery
  • Simplify management
  • Eliminate the need for a SAN administrator

Configure Sanless Hyper-V Failover Cluster with DataKeeper Cluster Edition is easy

If you know anything about Windows Server Failover Clustering, then you already know 99% of the solution. No need to worry if you have never built a Windows Server Failover Cluster before. Microsoft has made it easy and painless. For the beginners, I have written a step-by-step article that tells you how to build a Windows Server 2012 #SANLess cluster in my blog post here.

Two Options For Making A Highly Available Virtual Machine

If you have followed the steps in my post, you are ready to create your first highly available virtual machine. The first option assumes that you have an existing virtual machine that you want to make highly available. The second option assumes you are building a highly available virtual machine from scratch.

Configuring The DataKeeper Volume Cluster Resource

A SANLess Hyper-V cluster requires one VM per volume. Therefore, you will want to make sure you have your storage partitioned so that you have enough volumes for each VM. The storage on each cluster node should be configured identically in terms of drive letters and partition sizes. Have the partitions configured properly and your VM resides on the partition you want to replicate. Then, open the DataKeeper interface and walk through the three step wizard to create the DataKeeper Volume Resources as shown in below.

First, open the DataKeeper interface and click on Connect to Server. Do this twice to connect to both servers.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Once you are connected, click on Create Job to create a mirror of the volume that contains the virtual machine you want to make highly available as shown below. In this example we will mirror the E drive.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Whenever possible, keep replication traffic on a private network. In this case, we are using the 10.0.0.0/8 network for replication traffic. This can be a simple patch cable that connects the two servers across two unused NICs.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

The final screen shows the options available for mirroring. For local area networks, Synchronous mirroring is preferred. When replicating across wide area networks, you will want to use Asynchronous replication and possibly enable compression. I would not limit the Maximum bandwidth. Because that could potentially cause your mirror to go out of sync if your rate of change (Disk Right Bytes/sec) exceeds the Maximum bandwidth specified. However, you may want to temporarily enable Maximum bandwidth during the initial mirror creation process. Otherwise, DataKeeper may flood the network with the initial replication traffic as it tries to get in sync as quickly as possible. Both Maximum bandwidth and Compression settings can be adjusted after the mirror is created. However, you cannot change between Synchronous and Asynchronous mirroring once the mirror has been created without deleting the mirror and recreating it.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

At the end of the mirror creation process you will see a popup asking if you want to auto-register this volume as a cluster volume. Select Yes, this will create a DataKeeper volume resource in Failover Clustering Available Storage.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

You are now ready to create your highly available VMs.

Option 1 – Clustering An Existing VM

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Once again, this procedure assumes you have an existing VM that you want to make highly available. If you do not have an existing VM, you will want to follow the procedure in Option 2 – Creating a Highly Available VM. Otherwise, you should have a VM when looking at Hyper-V Manager as shown below.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

All the VM files should already be located on the replicated volume, as shown below. If not, you will have to relocate the files before attempting to cluster the VM.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

To begin the clustering process, open up Failover Cluster Manager. Right click on Configure Roles and choose Virtual Machine as the role you want to create.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

This will launch the High Availability Wizard. At this point you should select the VM that you want to cluster and step through the wizard as shown below.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

You will see that the VM resource will be created, but there will be some warnings. The warnings indicate that the E drive is not currently part of the VM Cluster Resource Group.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

To make the DataKeeper Volume E part of the VM Cluster Resource Group, right click on the role and choose Add Storage. Add the DataKeeper Volume that you will see listed in Available Disks.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

The last part is to choose the Properties of the Virtual Machine Configuration (not the Virtual Machine) resource and make it dependent upon the storage you just added to the resource group.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

You should now be able to start the VM.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Option 2- Creating A Highly Available VM From Scratch

Assuming you want to create a highly available VM from scratch, you can complete this entire process from the Hyper-V Virtual Machine Manager as shown below. This step assumes that you have already created a mirror of the E drive using DataKeeper as described in Configuring the DataKeeper Volume Resource section.

To get started, open the Failover Cluster Manager and right click on Roles and choose Virtual Machine – New Virtual Machine.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Follow through with the steps of the wizard and select the options that you want to use for the VM. When choosing where to place the VM, select the cluster node that currently is the owner of Available Storage. It will also be the source of the mirror.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Make sure when specifying the Name and Location of the VM, you select the location of the replicated volume.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

The rest of the options are up to you. Just make sure the VHD file is located on the replicated volume.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

You will see the highly available VM is created, but there is a warning about the storage. You will need to add the DataKeeper Volume Resource to the VM Cluster Resource Group as shown below.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

After the DataKeeper Volume is added to the VM Cluster Resource Group, add the DataKeeper Volume as a dependency of the Virtual Machine Configuration resource.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

You now have a highly available virtual machine.

Configuring A Sanless Hyper-V Failover Cluster With DataKeeper Cluster Edition

Summary

In this blog post, we discussed what constitutes a #SANLess cluster. We chose SIOS DataKeeper to Configure Sanless Hyper-V Failover Cluster. Once built, the cluster behaves exactly like a SAN based cluster, This includes having the ability to do Live Migration, Quick Migration and automated failover in the event of unexpected failures.

A #SANLess cluster eliminates the expense of a SAN as well as the single point of failure of a SAN. DataKeeper Cluster Edition supports multiple nodes in a SAN. So configurations that stretch both LAN and WAN are all possible solutions for Hyper-V high availability and disaster recovery. DataKeeper supports any local storage. This opens up the possibility of using high speed local attached SSD or NAND Flash storage for high performance without giving up high availability.

If you enjoy reading tips to Configure Sanless Hyper-V Failover Cluster, read more about clustering here

Reported with permission from https://clusteringformeremortals.com/2014/03/04/configuring-a-sanless-hyper-v-failover-cluster-with-datakeeper-cluster-edition/

Windows Azure Disaster Recovery Options Just Got Better With ExpressRoute

by 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

by 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 3rd 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/