DataKeeper | SIOS SANless clusters

How to Avoid IO Bottlenecks: DataKeeper Intent Log Placement Guidance for Windows Cloud Deployments

May 9, 2022 by Jason Aw Leave a Comment

How to Avoid IO Bottlenecks: DataKeeper Intent Log Placement Guidance for Windows Cloud Deployments

To ensure optimal application performance, when deploying SIOS DataKeeper it is important to place the intent log (bitmap file) on the lowest latency disk available, avoiding an IO bottleneck. In AWS, GCP and Azure, the lowest latency disk available is an ephemeral drive. However, in Azure, the difference between using an ephemeral drive vs Premium SSD is minimal, so it is not necessary to use the ephemeral drive when running DataKeeper in Azure. In AWS and GCP however, it is imperative to relocate the intent log to the ephemeral drive, otherwise write throughput will be significantly impacted.

When leveraging an ephemeral disk for the bitmap file there is a tradeoff. The nature of an ephemeral drive is that the data stored on it is not guaranteed to be persistent. In fact, if the cloud instance is stopped from the console, the ephemeral drive attached to the instance is discarded and a new drive is attached to the instance. In this process the bitmap file is discarded and a new, empty bitmap file is put in its place.

There are certain scenarios where if the bitmap file is lost, a complete resync will occur. For instance, if the primary server of a SANless cluster is shutdown from the console a failover will occur, but when the server comes back online a complete resync will occur from the new source of the mirror to the old source. This happens automatically, so the user does not have to take any action and the active node stays online during this resync period.

There are other scenarios where bitmap file placement can also impact performance. For instance, if you are replicating NVMe drives you will want to carve out a small partition on the NVMe drive to hold the bitmap file. A general rule of thumb is that the bitmap file should be on the fastest, lowest latency disk available on the instance. It should also be located on a disk that is not overly taxed with other IO operations.

Information on how to relocate the intent log can be found in the DataKeeper documentation. Additional information regarding how the intent log is used can be found in the DataKeeper documentation.

Reproduced with permission from SIOS

How To Resize a SIOS DataKeeper Volume or Mirror

March 27, 2022 by Jason Aw Leave a Comment

How To Resize a SIOS DataKeeper Volume or Mirror

In this 4.5 minute video, SIOS demonstrates how to properly resize an existing SIOS DataKeeper volume or mirror. In this case, we are protecting a SQL Server resource via failover clustering. The SIOS DataKeeper resource that we will resize will be Volume ‘s’.

Launch SIOS DataKeeper, go to the mirror you are resizing. The reason you do this is for business requirements or because you are running out of space exponentially. First, stop mirroring by choosing Pause and unlock mirror or you can go to the Actions panel on the right and choose Pause and unlock all mirrors if your job has multiple mirrors.
It says OK. Once the mirror is paused, now go to the source and you want to grow your space, choose Extend, next, and then finish. Switch over to target and do the same. Extend, next, finish. Go back to the mirror and Choose Continue and lock mirror. The mirror is back in a mirroring state and none of the roles were taken offline.

Let us know if this has been helpful!

How To Resize a SIOS DataKeeper Volume or Mirror | SIOS

Reproduced with permission from SIOS

How to Remove SIOS DataKeeper Storage from SIOS LifeKeeper

March 23, 2022 by Jason Aw Leave a Comment

How to Remove SIOS DataKeeper Storage from SIOS LifeKeeper

Greg Tucker, SIOS Senior Product (Windows) Support Engineer will demonstrate in this 3-minute video, how to properly remove SIOS DataKeeper storage from SIOS LifeKeeper.

It is highly recommended that you remove the DataKeeper resource from the cluster prior to removing DataKeeper.

At the end of the video, Greg shares the SIOS Support contact info in the event there are other questions or issues.

How to Remove SIOS DataKeeper Storage from SIOS LifeKeeper | SIOS

Reproduced with permission from SIOS

How To Create A DataKeeper Replicated Volume That Has Multiple Targets Via CLI

July 31, 2021 by Jason Aw Leave a Comment

How To Create A DataKeeper Replicated Volume That Has Multiple Targets Via CLI

I often help people automate the configuration of their infrastructure so they can build 3-node clusters that span Availability Zones and Regions. The CLI for creating a DataKeeper Job and associated mirrors that contain more than one target can be a little confusing, so I’m documenting it here in case you find yourself looking for this information. The DataKeeper documentation describes this as a Mirror with Multiple Targets.

The environment in this example looks like this:

PRIMARY (10.0.2.100) – in AZ1
SECONDARY (10.0.3.100) – in AZ2
DR (10.0.1.10) – in a different Region

I want to create a synchronous mirror from PRIMARY to SECONDARY and an asynchronous mirror from PRIMARY to DR. I also have to make sure the DataKeeper Job knows how to create a mirror from SECONDARY to DR in case the SECONDARY or DR server ever become the source of the mirror. EMCMD will be used to create this multiple target mirror.

We need to first create the Job that contains all this possible endpoints and define whether the mirror will be Sync (S) or Async (A) between those endpoints.

emcmd . createjob ddrive sqldata primary.datakeeper.
local D 10.0.2.100 secondary.datakeeper.
local D 10.0.3.100 S primary.datakeeper.local D 10.0.2.100 dr.
datakeeper.local D 10.0.1.10 
A secondary.datakeeper.local D 10.0.3.100 dr.datakeeper.
local D 10.0.1.10 A

That single “createjob” command creates the Job. It might be a little easier to look at that command like this:

emcmd . createjob ddrive sqldata 
primary.datakeeper.local D 10.0.2.100 secondary.datakeeper.local 
D 10.0.3.100 S primary.datakeeper.local D 10.0.2.100 dr.datakeeper.
local D 10.0.1.10 A secondary.datakeeper.local D 10.0.3.100 
dr.datakeeper.local D 10.0.1.10 A

Next we need to create the mirrors.

emcmd 10.0.2.100 createmirror D 10.0.1.10 A
emcmd 10.0.2.100 createmirror D 10.0.3.100 S

Our DataKeeper Job should now look like this in the DataKeeper UI

One-to-many DataKeeper Replicated Volume

One-to-many DataKeeper Replicated VolumeAnd then finally we can register the DataKeeper Volume Resource in the cluster Available Storage with this command.

emcmd . registerclustervolume D

DataKeeper Volume in Available Storage

The DataKeeper Volume Resource will now appear in Available Storage as shown below.

DataKeeper Volume in Available StorageYou are now ready to install SQL Server, SAP, File Server or any other clustered resource you normally protect with Windows Server Failover Clustering.

Reproduced with permission from Clusteringformeremortals

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