DataKeeper | SIOS SANless clusters

How To Cluster MaxDB On Windows In The Cloud

January 12, 2019 by Jason Aw Leave a Comment

How To Cluster MaxDB On Windows In The Cloud #AZURE #AWS #GCP #SAP

Recently I have had a number of customers looking for a high availability solution to cluster MaxDB on Windows in the cloud. Some customers have been in Azure and some in AWS. But regardless of the cloud platform, they all eventually find the post in the SAP Community WIKI that describes the process.

https://wiki.scn.sap.com/wiki/display/MaxDB/HowTo+-+Embed+SAP+MaxDB+in+MSCS

The Challenge

The challenge with this post in a cloud environment is that there is no shared storage (SAN) available in the Azure, AWS or GCP that allows you to build a traditional shared storage cluster. The beauty of HA in the cloud is that cluster nodes typically reside miles away from each other in another data center, AKA, availability zone (AZ). So even if shared storage was available, it wouldn’t make a lot of sense since it would have to reside in a single AZ. It defeats the purpose of HA all together.

The Solution

However, there is an answer to cluster MaxDB on Windows in the cloud. SIOS DataKeeper is a SANless clustering solution from SIOS technology. It allows locally attached storage to be used in a Windows Server Failover Cluster. This eliminates the need for a SAN. Instead, SIOS keeps locally attached disk in sync using synchronous block level replication technology and presents this storage to WSFC as a clustered disk resource called a DataKeeper volume.

As far as the cluster is concerned, a DataKeeper Volume cluster resource looks like a shared disk. But instead of controlling disk locking (SCSI reservations), it controls the mirror direction. So in every sense of the word it is still a true WSFC, except it uses locally attached storage instead of shared storage. The locally attached storage can be anything from EBS block device to Azure premium disk, or even a local Storage Space with multiple disks stripped together. As long as Windows sees an NTFS formatted volume with a drive letter and the volume size is the same on each instance it can be used in the cluster.

DataKeeper Volume Cluster Resource

This type of cluster is commonly known as a SANless cluster. It has been around for many years enabling geo-clusters and clusters where shared storage was not available. Database admins also love it as it enables them to use local high speed storage devices like PCIe flash or SSD drives. And at the same time, still use WSFC for high availability.

SIOS also supports asynchronous replication. So if you want to add a node in a different geographic location for disaster recovery, you can build a 3-node cluster with 2 nodes in the same region but different fault domains and a 3rd node in an entirely different region, or maybe even back on-prem for disaster recovery options. Or, if you are in Azure you can leverage Azure Site Recovery (ASR) for disaster recovery as SIOS DataKeeper is compatible for ASR.

Both WSFC and SIOS DataKeeper are very dependent upon IP addresses staying the same. So for ASR configurations you will want to make sure you retain your IP address upon failover as described here.

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-retain-ip-azure-vm-failover

SAP

SIOS is no stranger to high availability and disaster recovery for SAP. The SIOS Protection Suite for Linux is a SAP Certified HA solution for SAP and SAP HANA. SIOS DataKeeper is the preferred HA/DR solution for SAP ASCS on Windows in cloud environments. Providing an HA/DR solution for MaxDB on Azure further solidifies SIOS as the SAP high availability experts.

If you have questions about high availability for SAP, or more details about how to Cluster MaxDB On Windows In The Cloud, do go through our other posts

S2D For SQL Server Failover Cluster Instances

September 8, 2018 by Jason Aw Leave a Comment

Storage Spaces Direct For SQL Server Failover Cluster Instances

With the introduction of Windows Server 2016 Datacenter Edition a new feature called Storage Spaces Direct (S2D) was introduced. At a very high level, S2D For SQL Server Failover Cluster Instances allows you to pool together locally attached storage and present it to the cluster as a CSV for use in a Scale Out File Server. Then it can be accessed over SMB 3 and used to hold cluster data such as Hyper-V VMDK files. This can also be configured in a hyper-converged (HCI) fashion such that the application and data can all run on the same set of servers. This is a grossly over-simplified description, but for details, you will want to look here.

Image taken from https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-overview

The main use case targeted is hyper-converged infrastructure for Hyper-V deployments. However, there are other use cases, including leveraging this SMB storage to store SQL Server Data to be used in a SQL Server Failover Cluster Instance

Why would anyone want to do that?

Well, for starters you can now build a highly available 2-node SQL Server Failover Cluster Instance (FCI) with SQL Server Standard Edition, without the need for shared storage. Previously, if you wanted HA without a SAN you pretty much were driven to buy SQL Server Enterprise Edition and make use of Always On Availability Groups or purchase SIOS DataKeeper and leverage the 3rd party solution which lets you build SANless clusters with any version of Windows or SQL Server. SQL Server Enterprise Edition can really drive up the cost of your project, especially if you were only buying it for the Availability Groups feature.

In addition to the cost associated with Availability Groups, there are a number of other technical reasons why you might prefer a Failover Cluster over an AG. Application compatibility, instance vs. database level protection, large number of databases, DTC support, trained staff, etc., are just some of the technical reasons why you may want to stick with a Failover Cluster Instance.

SIOS DataKeeper Solution Vs S2D For SQL Server Failover Cluster Instances

Microsoft lists both the SIOS DataKeeper solution and the S2D solution as two of the supported solutions for SQL Server FCI in their documentation here.

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-high-availability-dr

When comparing the two solutions, you have to take into account that SIOS has been allowing you to build SANless Clusters since 1999. But the S2D For SQL Server Failover Cluster Instances is still in its infancy. Having said that, there are bound to be some areas where S2D has some catching up to do. Or, simply features that they will never support simply due to the limitations with the technology.

Before Choosing Your SANless Cluster Solution

Have a look at the following table for an overview of some of the things you should consider before you choose your SANless cluster solution.

S2D For SQL Server Failover Cluster Instances

If we go through this chart, we see that SIOS DataKeeper clearly has some significant advantages. For one, DataKeeper supports a much wider range of platforms, going all the way back to Windows Server 2008 R2 and SQL Server 2008 R2. The S2D solution only supports the latest releases of Windows and SQL Server 2016/2017. S2D also requires the Datacenter Edition of Windows, which can add significantly to the cost of your deployment. In addition, SIOS delivers the ONLY HA/DR solution for SQL Server on Linux that works both on-prem and in the cloud.

Analysis Of The Differences

But beyond the cost and platform limitations, I think the most glaring gap comes when we start to consider disaster recovery options for your SANless cluster. Allan Hirt, SQL Server Cluster guru and fellow Microsoft Cloud and Datacenter Management MVP, recently posted about this S2D limitation. In his article Revisiting Storage Spaces Direct and SQL Server FCIs Allan points out that due to the lack of support for stretching S2D clusters across sites or including an S2D based cluster as a leg in an Always On Availability Group, the best option for DR in the S2D scenario is log shipping!

Don’t get me wrong. Log shipping has been around forever and will probably be around long after I’m gone. But that is taking a HUGE step backwards when we think about all the disaster recovery solutions we have become accustomed to, like multi-site clusters, Availability Groups, etc.

In contrast, the SIOS DataKeeper solution fully supports Always On Availability Groups. Better yet – it can allow you to stretch your FCI across sites to give you the best HA/DR solution you could hope to achieve in terms of RTO/RPO. In an Azure environment, DataKeeper also support Azure Site Recovery (ASR), giving you even more options for disaster recovery.

The rest of this chart is pretty self explanatory. It basically consist of a list hardware, storage and networking requirements that must be met before you can deploy an S2D cluster. An exhaustive list of S2D requirements is maintained here. https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-hardware-requirements

SIOS Datakeeper. What’s Good

The SIOS DataKeeper solution is much more lenient. It supports any locally attached storage and as long as the hardware passes cluster validation, it is a supported cluster configuration. The block level replication solution has been working great ever since 1 Gbps was considered a fast LAN and a T1 WAN connection was considered a luxury.

SANless clustering is particularly interesting for cloud deployments. The cloud does not offer traditional shared storage options for clusters. So for users in the middle of a “lift and shift” to the cloud that want to take their clusters with them they must look at alternate storage solutions. For cloud deployments, SIOS is certified for Azure, AWS and Google and available in the relevant cloud marketplace. While there doesn’t appear to be anything blocking deployment of S2D based clusters in Azure or Google, there is a conspicuous lack of documentation or supportability statements from Microsoft for those platforms.

Make A Safe Choice

SIOS DataKeeper has been doing this since 1999. SIOS has heard all the feature requests, uncovered all the bugs, and has a rock solid solution for SANless clusters that is time tested and proven. While Microsoft S2D is a promising technology, as a 1st generation product I would wait until the dust settles and some of the feature gap closes before I would consider it for my business critical applications.

To know more about S2D For SQL Server Failover Cluster Instances, find out here SIOS DataKeeper

Reproduced with permission from Clusteringformeremortals.com

Different Highly Available SQL Server Storage Configurations in Azure

March 27, 2018 by Jason Aw Leave a Comment

An Overview Of Performance Differences of Highly Available SQL Server Storage Configurations In #Azure: SMB 3.0 File Service Or Premium Storage

There are a few options when it comes to SQL server storage configurations in Azure. If you want to know, you can get some good idea from this article Windows Server Failover Cluster on Azure IAAS VM – Part 1 (Storage). It talks about the newly released Azure File Service that can be used to host SQL Server cluster data over SMB 3.0. Remember, till date Azure File Service cannot support Premium Storage. You are bound to about 1,000 IOPS or 60 MB/s per file share. With these limits in mind, Azure File Service is probably going to to be an option for databases with minimal IO demands.

Check Out My Test Results

Different Highly Available SQL Server Storage Configurations in Azure

So the plan was to test a few different SQL Server Storage Configurations. I provisioned a DS4 VM and attached some premium storage. Next, I attached a SMB 3.0 File share using Azure File Service. Here’s how I configured my SQL Server Storage Configurations.

F:\ – Three 1 TB P30 Premium Storage Disks added to a single 3TB pool
G:\ – One 1 TB P30 Premium Storage Disk (no Storage Pool)
Z:\ – SMB 3.0 File share on Azure File Services

The Process

Be really careful when you’re configuring the Storage Pool for use in a cluster. Either you create the Storage Pool before the cluster is up, or use the Powershell script in Sql Alwayson with Windows 2012 R2 Storage Spaces if the cluster had already been created. I’ve created a Simple mirror (RAID o) Please note that I’m not worried about redundancy since Azure storage has triple redundancy on the backend.

To configure the Storage Pool for use in a cluster, you have to be careful on how you proceed. You either have to create the Storage Pool before you create the cluster or if the cluster is already created, use the Powershell script described in Sql Alwayson with Windows 2012 R2 Storage Spaces. For increased performance, the pool I created was a Simple mirror (RAID 0). I’m not concerned about redundancy since the Azure storage on the backend has triple redundancy.

I should get up to three times the performance of a single disk, since I’ve three disk in the Storage Pool in a RAID 0. Now, if I choose to add even more disk to the pool, I’ll enjoy even higher performance. A single P30 disk gives me 5000 IOPS and 200 MB/S. Based on this, I should expect up to 15000 IOPS and 600 MB/S throughput for my pool.

Now that I have the storage out of the way, I configured Dskspd to run the same test on each of the different volumes. Here is what I did with the parameters using Dskspd.

Diskspd.exe -b8K -d60 -h -L -o8 -t16 -r -w30 -c50M F:\io.dat

Diskspd.exe -b8K -d60 -h -L -o8 -t16 -r -w30 -c50M G:\io.dat Diskspd.exe -b8K -d60 -h -L -o8 -t16 -r -w30 -c50M Z:\io.dat

And The Results Are Out

The results on different SQL Server Storage Configurations were rather predictable and summarized below.

Different Highly Available SQL Server Storage Configurations in Azure

Looking at the result, this particular job did not push the upper limits of the theoretical maximum of any of these storage solutions. However, the latency had a significant impact on the overall performance of this particular test. The test used 8k blocks in a mix of 30% writes and 70% reads to simulate a typical SQL Server OLTP workload.

Of course, the more money you want to spend, the more performance you can expect to achieve. It’s relative.

Price Comparison Of SQL Server Storage Configuration in Azure

As of November 24, 2015, the price for the best solution shown here (F:\) would cost $1,216/month. It promises full access to 3 TB of storage with unlimited reads/writes.

The second best solution (G:\) would give you 1 TB of storage at 1/3 the price, $405/month. Azure File Share is priced at $0.10/GB plus additional charges for read/write operations. You are only charged for the actual usage. So estimating the actual cost will be very dependent on your usage. You are at about 25% of the cost of Premium Storage before the additional charges for read/write operations.

Prices, like everything else in the Cloud, tend to change rapidly to address the market demands. Have a look at the latest price information at https://azure.microsoft.com/en-us/pricing/details/storage/ for the latest price information.

Summary

From this compilation and price overview of SQL Server Storage Configurations, Azure File Services does look enticing from a price perspective. The latency at this point does not make it a viable option for any serious SQL Server workload. Instead, have a look at utilizing premium storage and leveraging either host based replication solutions such as SIOS DataKeeper to build SQL Server Failover Cluster Instances (SQL Standard or Enterprise) or look at SQL Server Enterprise Edition and AlwaysOn AG.

Reproduced with permission from https://clusteringformeremortals.com/2015/11/24/highly-available-sql-server-storage-options-in-azure-smb-3-0-file-service-or-premium-storage-a-look-at-performance-differences/

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/

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