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 for 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.

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, defeating the purpose of HA all together.

However, there is an answer. SIOS DataKeeper, a SANless clustering solution from SIOS technology, allows locally attached storage to be used in a Windows Server Failover Cluster, eliminating 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.

DataKeeper and MaxDB
Typical 2-node WSFC across Availability Zones with a 3rd node in a different Region

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.

This type of cluster is commonly known as a SANless cluster and 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, yet 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.

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 and 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, Hana, MaxDB, SQL Server in Azure, AWS, GCP or any other platform leave me a comment or reach me on Twitter @daveberm

How to Cluster MaxDB on Windows in the Cloud #Azure #AWS #GCP #SAP

#Ignite2018 Session: Ensure application availability with cloud-based disaster recovery, Azure Site Recovery #SAP #BusinessContinuity

I’m a big fan of Azure Site Recovery for Disaster Recovery and was glad to attend the Ignite session today presented by Rochak Mittal and Ashish Gangwar

BRK3304 – Architecting mission-critical, high-performance SAP workloads on Azure

In one of the architecture slides they showed how an entire SAP deployment could be protected by Azure Site Recovery (ASR) and recovered in the event of a disaster in just a few minutes. Using Azure Recovery Plans allows you to have explicit control over recovery, including creating dependencies on resources as well as invoking scripts within a VM to help facilitate the complete recovery.

It seems like yesterday, but it was back in May of 2014 when I first started assisting Microsoft with providing a HA solution for SAP ASCS in Azure. That solution involves using DataKeeper to build a SANless cluster solution for ASCS and still stands today as the only HA solution that also works with ASR for disaster recovery configurations such as the one shown in this demo at Ignite.

Shared disks in Azure with SIOS DataKeeper

If you need help planning your highly available SAP deployment is Azure definitely reach out to me, I’d be glad to assist.



#Ignite2018 Session: Ensure application availability with cloud-based disaster recovery, Azure Site Recovery #SAP #BusinessContinuity