Windows Server 2012 | SIOS SANless clusters

Cloud Witness To Build Multi-Instance SQL Server Failover Cluster In Azure

September 10, 2018 by Jason Aw Leave a Comment

New Azure ILB Feature Allows You To Build A Multi-Instance SQL Server Failover Cluster In Azure

The new feature, Cloud Witness is my favourite at the moment. Before we look at the new quorum features in Windows Server 2016, I think it is important to know where we came from. In my previous post Understanding the Windows Server Failover Cluster Quorum in Windows Server 2012 R2 I went into some great detail regarding the history and evolution of the cluster quorum. I suggest you review that post to understand how the quorum works in Windows Server 2012 R2. Also, how the new features of Windows Server 2016 are going to make your cluster deployments even more resilient.

Cloud Witness

A Cloud Witness allows you to leverage Azure Blob Storage to act as a witness for your cluster. This witness would be in place of a Disk Witness or File Share Witness. The configuration of a Cloud Witness is extremely easy. From my experience costs next to nothing to host in Azure. The only downside is that the cluster nodes will need to be able to communicate over the internet to with your Azure Blob Storage. Very often cluster nodes are forbidden to communicate over to the public internet. So you will need to coordinate with your security team if you want to enable a Cloud Witness.

There are many compelling reasons for using a Cloud Witness to build the Multi-Instance SQL Server Failover Cluster In Azure. But for me it makes most sense in three very specific environments: Failover Cluster in Azure, Branch Office Clusters, and Multisite Clusters.

On A Closer Look

Let’s take a look at each of these scenarios to see how a Cloud Witness can help.

New ILB Feature For Multi-Instance SQL Server Failover Cluster In Azure — Figure 1 – When you’re trying to build Multi-Instance SQL Server Failover Cluster In Azure, the cloud witness storage account should always be configured Locally Redundant Storage (LRS)

Highly Available Deployments

If you are moving to Azure (or really any cloud provider), you will want to make sure your deployments are highly available. If you are taking about SQL Server, File Servers, SAP or other workloads traditionally clustered with Windows Server Failover Clustering, you will need to use either a File Share Witness or a Cloud Witness, since a Disk Witness is not possible in Azure. With Windows Server 2012 R2 or Windows Server 2008 R2, you will need to use a File Share Witness. Windows Server 2016 makes it possible to use a Cloud Witness. The advantage of a Cloud Witness is that you don’t have to maintain another Windows instance in Azure to host the File Share. Instead, Microsoft allows you to leverage Blob Storage. This gives you a less expensive solution, one that is much easier to manage, and more resilient.

Location

When looking at cluster deployments in branch offices, cost and maintenance is always a consideration. For a retail chain with hundreds or thousands of locations, having a SAN in each location can be cost prohibitive. Each location might to run a two node Hyper-V cluster on a S2D Hyper-converged configuration or a 3^rd party replication solution to host a number of virtual machines. Now what a Cloud Witness can do is to help the business avoid the cost of adding an additional physical server in each location to act as a File Share Witness or the cost of adding a SAN to each location.

Eliminates The Need For A 3^rd Data Center

And finally, when deploying a multisite cluster, the Cloud Witness eliminates the need for a 3^rd data center to host the File Share Witness. Before the introduction of the Cloud Witness, best practice would dictate that the File Share Witness reside in a 3^rd location. Access to a 3^rd datacenter just to host a file share witness was not always feasibly and certainly introduced another layer of complexity. By using a Cloud Witness you eliminate the need to maintain a 3^rd location and access to the witness is done over the public internet, minimizing the network requirements as well.

Site Awareness

When building a multisite cluster, there has always been another common problem. Controlling the failover to always prefer the local site was not possible. While you could specify Preferred Owners, the Preferred Owners setting is commonly misunderstood. Administrators may not have realized this. But do you know even if they didn’t list a server as Preferred Owner, the server is automatically appended to the end of the Preferred Owners list maintained by the cluster. The result of this misunderstanding is that although you may have only listed the local servers as Preferred Owners, you could potentially have a cluster resource failover to the DR site. And this is even when there is a perfectly good node available in the local site. Obviously this is not what you expect and using Site Awareness will eliminate this problem moving forward.

Site Awareness fixes this problem by always preferring the local site when deciding which node to bring online. So in a normal circumstance a clustered workload will always failover to a local node unless you have a complete site outage. In which case one of the DR nodes will come online. The same holds true once you are running in the DR site. The cluster will recover the workload on a server in the DR site if it was previously running on a node in the DR site. Site Awareness will always prefer a local node.

Fault Domains

Building upon site awareness is Fault Domains. Fault Domains goes a step further and lets you define Node, Chasse, and Rack locations in addition to Site. Fault Domains have three benefits: Storage Affinity in a Stretch Cluster, increases Storage Spaces resiliency. It enhances the Health Services alerts by including meta data about the location of the associated resources raising the alarm. Storage Affinity will help ensure that your cluster workloads and storage are running in the same location. You certainly wouldn’t want your VM reading and writing data that is sitting on a CSV in a different city.

However, I think the biggest winner here is the Storage Spaces Direct (S2D) scenario. SD2 will leverage the information you provide about your cluster nodes location (Site, Rack, Chassis) to ensure that the multiple copies of data that is written for redundancy all live in different Fault Domains. This helps ensure that data placement is optimized so that the failure of a single Node, Chassis, Rack or Site does not bring down your entire S2D deployment. Cosmos Darwin has an excellent video on Channel 9 that explains this concept in great detail.

Summary

Windows Server 2016 adds several new enhancements to the cluster quorum that will provide some immediate benefits to your cluster deployments. In addition, check out some of the other great new cluster enhancements like rolling system upgrade, Virtual Machine Resiliency, Workgroup and Multi-Domain Clusters and others.

To read about other tips such as building a new Multi-Instance SQL Server Failover Cluster In Azure with Cloud Witness, have a read at our posts.

Reproduced with permission from Clusteringformeremortals.com

Learn Windows Server 2012 R2 Failover Clustering

March 12, 2018 by Jason Aw Leave a Comment

Learn Windows Server 2012 R2 Failover Clustering – Microsoft Virtual Academy

For those who have never been exposed to clustering or just new to clustering in Windows Server 2012 R2, this is the class for you. Symon Perriman (@SymonPerriman), 5nine Software Vice President of Business Development and Elden Christensen, Microsoft Principal Program Manager Lead, live and breathe failover clustering. With such great knowledgeable instructors, this two men would definitely be able to give you some great ideas on your next project or simply give you an alternative view. You can’t ask for any better instructors. Stop what you are doing and watch this RIGHT NOW!

http://www.microsoftvirtualacademy.com/training-courses/failover-clustering-in-windows-server-2012-r2

Reproduced with permission from https://clusteringformeremortals.com/2015/02/12/learn-windows-server-2012-r2-failover-clustering-microsoft-virtual-academy/

Create SQL Server 2014 Failover Cluster Instance with DataKeeper

February 15, 2018 by Jason Aw Leave a Comment

Create SQL Server 2014 Failover Cluster Instance with DataKeeper

UPDATE – Due to new features introduced, I have updated my guidance on deploying SQL Server clusters on Azure. The latest article can be found here: https://clusteringformeremortals.com/2015/01/01/step-by-step-how-to-configure-a-sql-server-failover-cluster-instance-fci-in-microsoft-azure-iaas-sqlserver-azure-sanless/

This is the 3^rd post in the series on High Availability and Disaster Recovery in Windows Azure. This post contains step-by-step instructions for implementing a Windows Server Failover Cluster in the Windows Azure IaaS Cloud between two cluster nodes in different Fault Domains. While this post focuses on building a SQL Server 2014 Failover Cluster Instance, you could protect any cluster aware application with just making some minor adjustments to the steps below. In my next post, I will show you how to extend this cluster to a third node in a different datacenter for a very robust disaster recovery plan. Because Azure does not have a clustered storage option, we will use the 3^rd party solution called DataKeeper Cluster Edition for our cluster storage.

This post assumes you have created a Virtual Network in Azure and you have your first DC already provisioned in Azure. If you haven’t done that yet, you will want to go ahead and have a look at the first two posts on this topic.

How To Create A Site-To-Site VPN Tunnel To The Windows Azure Cloud

Extending Your Datacenter To The Azure Cloud

While creating a VPN connection to your primary Datacenter is not a pre-requisite, I highly recommend you considering doing it. This way you can be ready for our hybrid disaster recovery configuration which will be discussed in the next post.

The high levels steps which we will illustrate in this post are as follows:

Provision two Windows Server 2012 R2 Servers
Add the servers to the domain
Enable the Failover Clustering feature
Create the cluster
Create a replicated volume cluster resource with DataKeeper Cluster Edition
Install SQL 2014 Failover Cluster Instance

Provision Two Windows Server 2012 R2 Server

Click on the Virtual Machine tab in the left column and then click the New button in the bottom left corner.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

Choose New Virtual Machine From Gallery

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

For our cluster we are going to choose Windows 2012 R2 Datacenter

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

Choose the latest Version Release Date, Name the VM and Size. The user name and password will be the local administrator account that you will use to log in to the VM to complete the configuration.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

On this next page you will choose the following:

Cloud Service: I choose the same Cloud Service that I created when I provisioned my first VM. Cloud Service documentation says that it is used for load balancing, but I see no harm in putting all of the cluster VMs and DCs in the same Cloud Service for easier management. By choosing an existing Cloud Service my Virtual Network and Subnets are automatically selected for me.

Storage Account: I choose an existing Storage Account

Availability Set: This is EXTREMELY important. You want to make sure all of your VMs reside in the same Availability Set. By put putting all of your VMs in the same Availability Set you guarantee that the VMs all run in a different Fault Domain.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

The last page shows the ports where this VM can be reached.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

Once the VM is created you will see it as a new VM in the Azure Portal

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

The next step is to add additional storage to the VM. Azure best practices would have you put your databases and log files on the same volume, otherwise you must disable the Geo-replication feature that is enabled by default. The following article describes this issue in more detail: http://msdn.microsoft.com/en-us/library/jj870962.aspx#BKMK_GEO

To add additional storage to your VM, click on the VM and then Dashboard to get to the VMs dashboard. Once there, click on Attach.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

There are lots of things to consider when considering storage options for SQL Server. The safest and easiest method is the one we will use in this post. We will use a single volume for our data and log files and have caching disabled. You will want to read this article for the latest information on SQL Server Performance Considerations and best practices for Azure.

http://msdn.microsoft.com/en-us/library/windowsazure/dn133149.aspx

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

After you add this additional volume, you will need to open each VM and use Disk Management to initialize and format the volumes. For the purpose of this demo we will format this volume as the “F:\” drive.

You now have one VM called SQL1. You will want to complete the same process as described about to provision another VM and call it SQL2, making sure you put it in the same Cloud Service, Availability Set and Storage Account. Also make sure to attach another volume to SQL2 just as you have done for SQL1 and format it as the F:\ drive.

When you have finished provisioning both VMs we will move forward to the next step, adding them to the domain.

Add Them To Domain

Adding SQL1 and SQL2 to the domain is a simple process. Assuming you have been following along with my previous posts, you have already created your domain and have a DC called DC2 provisioned in the same Cloud Service as SQ1 and SQL2. Adding them to the domain is as simple as connecting to the VMs and adding the VMs to the domain just as you would for in a regular on-premise network. If you configured the Virtual Network properly the new VMs should boot with an IP address assigned by DHCP which specifies the local DC2 and the domain controller.

Click Connect to open an RDP session to SQL1 and SQL2

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

IPconfig /all shows the current IP configuration. Windows Azure requires that you leave the addresses set to use the DHCP server, however the IP address will not change for the life of the VM. You should notice that your DNS server is set to the local DNS server that you created in the previous article previously.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

Add SQL1 and SQL2 to the domain and continue with the next steps.

Enable Failover Clustering Feature

On both SQL1 and SQL2 you will enable the Failover Clustering feature

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

Create Cluster

If you are familiar with clustering then the following steps should be very familiar to you with just a few exceptions, so pay close attention to avoid problems that are specific to deploying clusters in Windows Azure.

We will start by creating a single node cluster, this will allow us to make the necessary adjustment to the cluster name resource before we add the second node to the cluster. Use Failover Cluster Manager and start by choosing Create Cluster. Add SQL1 to the selected servers and click Next.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

In order for us to install SQL Server 2014 into the cluster at the later steps, we will need to complete cluster Validation

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

Step through the rest of the cluster creation process as shown below. We will call this cluster SQLCLUSTER, which is simply the name we use to manage the cluster. This is NOT the name that you client applications will eventually connect to.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

Once the cluster create process completes, you will notice that the cluster name resource fails to come online, this is expected.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

The name resource failed to come online because the IP resource failed to come online. The IP address failed to come online because the address that the DHCP server handed out is the same as the physical address of the server, in this case 10.10.11.5, so there is a duplicate IP address conflict.

In order to fix this, we will need to go into the properties of the IP Address resource and change the address to another address in the same subnet that is not currently in use. I would select an address that is at the higher end of the subnet range in order to reduce the possibility that in the future you might deploy a new VM and Azure will hand out that cluster IP address, causing an IP address conflict. In order to eliminate this possibility, Microsoft will have to allow us more control over the DHCP address pool. For now, the only way to completely eliminate that possibility is to create a new subnet in the Virtual Private Network for any new VMs that you might deploy later, so only this cluster resides in this subnet. If you DO plan to deploy more VMs in this subnet, you might as well deploy them all at the same time so you know which IP addresses they will use, that way you can use whatever IP addresses are left of for the cluster(s).

To change the IP address, choose the Properties of the IP Address cluster resource and specify the new address.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

Once the address is changed, right click on the Cluster Name resource and tell it to come online.

We are now ready to add the the second node to the cluster. In the Failover Cluster Manager, select Add Node

Browse out to your second node and click Add.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

Run all the validation tests once again.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

When you click finish, you will see that the node was added successfully, but because there is no shared storage in Azure, no disk witness for the quorum could be created. We will fix that next.

We now need to add a File Share Witness to our cluster to ensure the quorum requirements for two node cluster are satisfied. The file share witness will be configured on the DC2 server, the domain controller that is also running in the Azure Cloud.

Open up a RDP session to the domain controller in your Azure Private Cloud

Connect to your domain controller and create a file share called “Quorum”. You will need to give the Cluster Computer Name Object (which we called SQLCluster in this example) read/write permissions at both the Share level and Security (NTFS) level. If you are not familiar with creating a file share witness, you may want to review my previous post for more detail.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

Once the file share witness folder is created on the domain controller, we need to add the witness in the cluster configuration using the Failover Cluster Manager on SQL1

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

The File Share Witness should now be configured as shown below.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

Create Replicated Volume Cluster Resource With DataKeeper Cluster Edition

A traditional failover cluster requires a shared storage device, like a SAN. The Azure IaaS cloud does not offer a storage solution that is capable of being used as a cluster disk, so we will use the 3^rd party data replication solution called DataKeeper Cluster Edition which will allow us to create a replicate volume resource which can be used in place of a shared disk. A 14-day trial license is generally available for testing upon request.

Once you download DataKeeper, install it and license it on both SQL1 and SQL2 and reboot the servers. Once the servers reboot, connect to SQL1, launch the DataKeeper UI and complete the steps below.

“Connect” to both SQL1 and SQL2

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

Now click on “Create Job” and follow the steps illustrated below to create the mirror and DataKeeper Volume cluster resource.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

Choose the source of the mirror. When you choose the IP Address for the source and target, be sure to choose IP address of the server itself, DO NOT CHOOSE THE CLUSTER IP ADDRESS!

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

For this implementation where both nodes are in the Azure Cloud, choose synchronous replication with no compression, as shown below.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

Click Done and you will be asked if you want to register this mirror in Windows Server Failover Clustering. Click Yes.

You will now see there is DataKeeper Volume Resource in Available Storage when you open the Windows Server Failover Cluster GUI

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

You are now ready to install SQL Server into the cluster.

Install SQL Server 2014 Failover Cluster Instance

To start the SQL Server 2014 cluster installation, you must download the SQL 2014 ISO to SQL1 and SQL2. You can use SQL Server 2014 Standard Edition for a simple two node cluster. If you want to extend this cluster to a 3^rd site for disaster recovery as we will discuss in the next post, then you will need the Enterprise Edition because the Standard Edition only supports a 2-node cluster. If you are only looking for a simple two node solution than SQL Server Standard Edition can be a much more economical solution.

Once SQL Server 2014 is downloaded to the servers, mount the ISO and run the setup. The option that we want is to open is in the Advanced tab. Open the Advanced tab and run the “Advanced cluster preparation“. My good friend and fellow Cluster MVP, Robert Smit, told me about using the Advanced option. Basically, the Advanced option lets you split the install into two different processes, preparation and completion. Many things can go wrong with cluster installations, usually related to active directory and privileges. If you use the standard install method you may wait 20 minutes or longer for the installation to complete, only to find out that at the last minute the cluster was unable to register the CNO in active directory and the whole installation fails. Not only did the whole installation fail, now you may have a partially installed SQL Server cluster and you have a mess to clean up. By using the Advanced method you are able to minimize the risk by putting the risky section just at the end during cluster completion. If cluster completion fails, you simply need to diagnose the problem and re-run just the cluster completion process once again.

If you really want to save some time, check out Robert’s article on installing SQL Cluster with a configuration file, it is pretty easy to do and saves a bunch of time if you are doing multiple installations. However, for our purposes we will walk through the SQL install with the GUI as shown below.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

For demo purposes, I just used the administrator account for each of the services. In production you will want to create separate accounts for each service as a best practice.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

Once the install completes it looks like this.

Now we are ready to move forward with part two of the installation, Advanced Cluster Completion.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

Give the SQL instance a name. This is the name the clients will connect to. In this case I called it SQLINSTANCE1.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

This is where the magic happens. If you configured the mirror in DataKeeper as described earlier, you will see the DataKeeper Volume listed here as an Available Shared Disk, when actually it is simply a replicated volume pair.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

One the Cluster Network Configuration page, it is important to choose IPv4 and to specify an address that is not in use in your subnet. As stated before, this address should be at the higher end of the DHCP range to help minimize the risk that Azure will assign that address to another VM in the future. I highly suggest that you have a subnet that is dedicated to your cluster to avoid possible conflicts until Windows Azure offers us greater control over the IP addresses and DHCP ranges. Later, after the cluster is created, you will need to delete this client access point and add the client access point as described in http://blogs.msdn.com/b/sqlalwayson/archive/2013/08/06/availability-group-listener-in-windows-azure-now-supported-and-scripts-for-cloud-only-configuration.aspx. I will publish a blog post in the future that describes this process in detail.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

On this page make sure you Click Add Current User, or specify the accounts you wish to use to administer SQL Server.

Starting with SQL Server 2012, tempdb no longer needs to be part of the SQL Server Cluster. If you move the tempdb to a non-replicated volume, you will need to make sure that directory structure exists on each node. To change the location of the tempdb, click on the Data Directories tab and change the location where the tempdb is located.

When the installation completes on SQL1, it is time to run the SQL installer on SQL2 and add the second node to the cluster. Run the Setup on SQL2 and choose Add node to a SQL Server failover cluster.

Creating A SQL Server 2014 Alwayson FCI In Windows Azure IAAS with DataKeeper

After the installation completes, you now have a fully functional SQL Server 2014 Failover Cluster Instance running on the Azure Cloud. Each instance is in a different Fault Domain providing a high level of resiliency. Be sure to replace the client access point with a client access point as described in my post…

In the next post in this series I will show you how to extend this two node cluster to a third node for a multi-site cluster. This third-node will be located in my on-premise data center, which will give us the ultimate in both high availability and disaster recovery.

Read here for more information about SQL Server 2014 Failover Cluster Instance

Reproduced with permission from https://clusteringformeremortals.com/2014/01/10/creating-a-sql-server-2014-alwayson-failover-cluster-fci-instance-in-windows-azure-iaas-azure-cloud/

Clustering SQL Server 2012 On Windows Server 2012 with DataKeeper

February 9, 2018 by Jason Aw Leave a Comment

A Little Recap

In my previous post I walked through the process of building a 2-node cluster up to the point where we are ready to start clustering SQL Server 2012 on Windows Server 2012. If you have completed those steps, you are ready to move on and actually create your clustered application with my suggested SIOS Datakeeper Cluster Edition.

Next step, clustering SQL Server 2012

First up, we have SQL Server 2012. SQL Server 2012 cluster installation is pretty much identical to SQL 2008/2008 R2 cluster installations, so most of this will apply even if you are using SQL 2008/2008 R2. The terminology around SQL Server 2012 Clustering gets a little convoluted. You will hear mention of SQL Server AlwaysOn, which essentially could mean one of two different things: AlwaysOn Availability Groups or AlwaysOn Failover Cluster Instance. The confusion arises because both solutions require some level of integration with Windows Server Failover Clustering and it is even further confused by the fact that you can deploy a combination of AlwaysOn Availability Groups and AlwaysOn Failover Clustering, but that is a topic for another day!

Breaking It Down In Easy-To-Understand Terms

Essentially AlwaysOn Availability Groups is what used to be called Database Mirroring in SQL 2008 R2 and earlier. It has some new bells and whistles that overcome some of the limitations of earlier versions of database mirroring, so it is certainly worth checking it out. AlwaysOn Failover Cluster Instance is simply what used to be called a SQL Server Failover Cluster. This is the latest edition of the same clustering technology that has been available since early versions of SQL Server. One of the best new features of SQL Server 2012 AlwaysOn Failover Cluster Instance is the ability to have nodes in different subnets. This was a major limitation in earlier versions of SQL Server. In a previous blog entry I discussed some of the limitations of AlwaysOn Availability Groups, you should check that out before you make any decisions on which technology to deploy.

Let’s Start

With that said, this article is going to focus on the Step-by-Step instructions on deploying a SQL Server 2012 AlwaysOn Failover Cluster Instance.

Step 1

Make sure your cluster storage is ready. If you followed the instructions in my previous post, you will know that instead of a shared disk resource, we are going to use a replicated disk resource using the 3^rd party software DataKeeper Cluster Edition. If you are using shared storage and have added the storage than you can skip right to Step 2 where we begin the SQL install. Otherwise, follow the steps below to configure the software to replicate the local disks for use in a SQL cluster.

Configuring DataKeeper Cluster Edition

Install and configure DataKeeper Cluster Edition
1. Run DK Setup
2. Go through the entire installation process selecting all of the default values.
3. Restart the computer after the installation completes as prompted and repeat the process on the SECONDARY server
4. Launch the DataKeeper UI on PRIMARY and click Connect to Server. Connect to PRIMARY and then connect to SECONDARY
5. Click on Create Job and walk through the Create Job wizard to create a mirror of the E drive
  
  Choose the source volume of the mirror and the IP address of the NIC that will carry the replication traffic.
  
  Choose the target of the mirror and click Next
  
  Here you will choose your mirror options:
  Compression – only enable for replication across a WAN
  Asynchronous – choose this for all WAN replication
  Synchronous – this is ideal for LAN replication
  Maximum bandwidth – used in WAN replication as a way to put a cap on the amount of bandwidth replication is allowed to use. Generally it should be left on 0, however for initial mirror creation you may want to limit the bandwidth so replication does not use all available bandwidth to do the initial synchronization
  
  Once you click Done the mirror will be created.
  
  Once the mirror is created you will be prompted to register the volume in Windows Server Failover Clustering (WSFC). Click Yes and a new DataKeeper Volume Resource will be registered in Available Storage (see picture in Step 2).

Step 2

We are going to begin the installation of SQL Server 2012 on the first cluster node.

Before we begin, make sure your storage appears in Failover Cluster Manager and is assigned to the Available Storage group as shown below
At this point we are going to launch the SQL Server 2012 setup and go to the Installation Tab and click New SQL Server failover cluster installation
Step through the installation as shown in the following screen shots.

The following error is expected if your servers are not connected to the internet. If you are connected to the internet you should go ahead and accept the updates it finds.

For Service Account best practices read the following: http://msdn.microsoft.com/en-us/library/ms143504.aspxFor our lab purposes I am just using the Administrator account

Before you click next, click on the Data Directories tab and change the location of tempdb. With Windows Server 2012 tempdb no longer has to reside on the cluster storage. In our example we are moving tempdb to the C drive to avoid replicating unnecessary data.

At this point you will need to make sure to create the same tempdb directory on the SECONDARY server as advised by the warning.

Congratulations, the 1^st cluster node has been installed.

We are now ready to install SQL on the second node of the cluster.

Go to the SECONDARY server and launch the SQL Server 2012 Setup and follow the wizard as shown in the following screen shots, starting with clicking on Add node to a SQL Server failover cluster.

The following error is expected if your servers are not connected to the internet. If you are connected to the internet you should go ahead and accept the updates it finds.

Congratulations – you have built a 2-node SQL Server 2012 AlwaysOn Failover Cluster Instance. Open up Failover Cluster Manager and you should see something that looks like this.This article “clustering SQL Server 2012 in a Windows Server 2012 cluster” was meant to be just a quick run through on how to install SQL 2012 in a Windows Server 2012 cluster. For additional reading start here and let Google be your friend!

Reproduced with permission from https://clusteringformeremortals.com/2013/01/05/clustering-sql-server-2012-on-windows-server-2012-step-by-step/

Clustering Windows Server 2012 Step-By-Step

February 8, 2018 by Jason Aw Leave a Comment

Basic Steps Of Any Cluster

This article is the first in a series of articles on Clustering Windows Server 2012. This first article covers the basics first steps of any cluster, regardless of whether you are clustering Hyper-V, SQL Server Failover Clusters, File Servers, iSCSI Target Server or others. Future articles will cover more detailed instructions for each cluster resource type, but the following information is applicable to ALL clusters.

I’m assuming you know a little bit about clusters and why you would want to build one, so I won’t go into those details in this particular post. I also assume you are familiar with Windows Server 2012 and basic things like DNS, AD, etc. It is also worth noting that in Windows Server 2012 failover clustering comes with every edition, unlike Windows Server 2008 R2 and earlier where failover clustering was only included in Enterprise Edition and above.

Focus On Basic 2-Node Cluster

This particular series will focus on a basic 2-node cluster, where we have two servers (named PRIMARY and SECONDARY) running Windows Server 2012 in a Windows Server 2012 Domain (domain controller named DC). It also assumes that PRIMARY and SECONDARY can communicate with each other over two network connections I have labeled PUBLIC and PRIVATE. In production scenarios these network connections should run through entirely different network gear (switches, routers, etc) to eliminate any single point of failure.

Let’s Start! Clustering Windows Server 2012, here we go!

This series will be written in a very basic, step-by-step style that walks you through the process in an ordered list with basic instructions and plenty of screen shots to help illustrate the procedure where needed. So let’s begin at the beginning…

Add the Failover Clustering Feature on all of the servers you want to add to the cluster
1. Open the Server Manager Dashboard (this 1^st step will need to be completed on both PRIMARY and SECONDARY)
2. Click on Add roles and features
3. Choose Role-based or feature-based installation
4. Choose the server on which you wish to enable the failover cluster feature
5. Skip over the Server Roles page
6. On the Features page select Failover Clustering and click Next and then confirm the installation
Before we start configuring the cluster, we need to consider what kind of storage the cluster will use. Traditionally clusters will use some sort of SAN, but with Windows 2012 not all clusters will use a SAN. For instance, if you are building a cluster to support SQL Server AlwaysOn Availability Groups your storage will be replicated by SQL Server, eliminating the need for a SAN. Also, with SMB 3.0 being support as cluster storage for Hyper-V and SQL Server you may not have a traditional SAN for storage. And let’s not forget clustered Storage Spaces with shared SAS drives is also a possibility in Windows Server 2012. In addition to the options mentioned above, you also can use local disks and 3^rd party host based replication solutions like DataKeeper Cluster Edition which is an excellent alternative which I blog about pretty frequently.For the purposes of this post to share about Clustering Windows Server 2012 , I am going to assume you have no shared storage. However, if you do have shared storage at this point you should configure you storage such that you have LUN(s) carved out and shared with each of the cluster nodes with one LUN being used as a disk witness and the remaining LUNs can be used for the application which you want to cluster. In lieu of a disk witness for our quorum, I am going to use a node and file share witness quorum type which I will explain later.
Now that Failover Clustering is enabled on each server, you can open the Failover Cluster Manager on your PRIMARY server. The first thing we will want to do is to run “Validate Configuration” so we can identify any potential issues before we begin. Click on Validate Cluster
Step through the Validate a Configuration Wizard as shown in the following steps.
1. Select the servers you want to cluster
2. Run all tests (depending on what roles you have installed on the servers you may get more or less tests. For instance, if Hyper-V is enabled there are new Hyper-V specific tests for clusters)
3. Assuming your cluster “passed” validation you should have a report that looks similar to mine. You will notice that my report contains “warnings” but no errors. It is important for you to view the report and understand what warnings might be present, but you as long as you understand the warnings and they make sense for your particular environment you can move on. If you validation “failed”, you MUST fix the failures before moving on. Click View Report to view the report
4. You will see all of my warnings are related to storage, so I am not concerned since I have not configured any shared storage, so I would expect some of these thests to produce warnings.

Once Validation completes without any errors, you will automatically be thrown into the Create Cluster Wizard. Walk through this wizard as shown below to create your basic cluster.
1. In this first screen you will choose a name for your cluster and pick an IP address that will be associated with this name in DNS. This name is just the name used to manage your cluster – this is NOT the name that your clients will use to connect to the clustered resource(s) you will eventually create. Once you create this access point a new computer object will be created in AD with this name and a DNS A record will be created with this name and IP address.
2. On the confirmation screen you will see the name and IP address you selected. You will also see an option which is new with Windows Server 2012 failover clustering…”Add all eligible storage to the cluster”. Personally I’m not sure why this is selected by default, as this option can really confuse things. By default, this selection will add all shared storage (if you have it configured) to the cluster, but I have also seen it add just local, non-shared disks, to the cluster as well. I suppose they want to make it easy to support symmetric storage, but generally any host based or array based replication solutions are going to have some pretty specific instructions on how to add symmetric storage to the cluster and generally this option to add all disks to the cluster is more of a hindrance than a help when it comes to asymmetric storage. For our case, since I have no shared storage configured and I don’t want the cluster adding any local disks to the cluster for me automatically I have unchecked the Add all eligible storage to the cluster option.
3. After you click next you will see that the cluster has finished the creation process, but there may be some warnings. In our case the warnings are probably related to the quorum configuration which we will take care of in the next step. Click View Report to check out any warnings.
  
  You see that the warning is telling use to change the quorum type.
Because we have no shared storage, we will not be using a Node and Disk Majority quorum as suggested. Instead, we will use and Node and File Share Majority quorum. The following steps will help us configure the Node and File Majority Quorum
1. A File Share Witness needs to be configured on a server that is not part of the cluster. A file share witness is a basic file share that the cluster computer name (MYCLUSTER in our case) has read/write access. The first step involves creating this file share. In our example, we are going to create a file share on our DC and give MYCLUSTER read/write access to it.
2. The file share does not need to reside on a Windows 2012 server, but it does need to be on a Windows Server in the same domain as the cluster. The important thing to remember is that the cluster computer name that we created needs read/write access at both the share level and NTFS level. The following are some screen shots that walk you through this process on the DC server which is running Windows Server 2012 in my lab.
3. Now that we have the file share created on DC, we will go back to PRIMARY and use the Failover Cluster Manager to change the quorum type as shown in the following steps.
  
  If by chance this wizard fails, it is most likely related to the permissions on the file share. Make sure you give the cluster computer name read/write permissions at BOTH the file share and security (NTFS) level and try again.
You now have a basic 2-node cluster and are ready to move on to the next step of series Clustering Windows Server 2012 which is creating your cluster resources. I will be publishing a series of articles on how to cluster different resources, starting with SQL 2012 in my next post.