SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • Products
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • News and Events
  • Clustering Simplified
  • Success Stories
  • Contact Us
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

Deployment of a SQL Server Failover Cluster Instance on Huawei Cloud

September 28, 2021 by Jason Aw Leave a Comment

Huawei Cloud high availability ECS IaaS

Deployment of a SQL Server Failover Cluster Instance on Huawei Cloud

*DISCLAIMER: While the following completely covers the high availability portion within the scope of our product, this is a setup “guide” only and should be adapted to your own configuration.

Overview

HUAWEI CLOUD is a leading cloud service provider not just in China but also has global footprint with many datacenters around the world. They bring Huawei’s 30-plus years of expertise together in ICT infrastructure products and solutions and are committed to providing reliable, secure, and cost-effective cloud services to empower applications, harness the power of data, and help organizations of all sizes grow in today’s intelligent world. HUAWEI CLOUD is also committed to bringing affordable, effective, and reliable cloud and AI services through technological innovation.

DataKeeper Cluster Edition provides replication in a virtual private cloud (VPC) within a single region across availability zones for the Huawei cloud. In this particular SQL Server clustering example, we will launch four instances (one domain controller instance, two SQL Server instances and a quorum/witness instance) into three availability zones.

Huawei Cloud SIOS Datakeeper HA Architecture

DataKeeper Cluster Edition provides support for a data replication node outside of the cluster with all nodes in Huawei cloud. In this particular SQL Server clustering example, four instances are launched (one domain controller instance, two SQL Server instances and a quorum/witness instance) into three availability zones. Then an additional DataKeeper instance is launched in a second region including a VPN instance in both regions. Please see Configuration of Data Replication From a Cluster Node to External DR Site for more information. For additional information on using multiple regions please see Connecting Two VPCs in Different Regions.

Huawei Cloud SIOS Datakeeper DR architecture

DataKeeper Cluster Edition also provides support for a data replication node outside of the cluster with only the node outside of the cluster in Huawei Cloud. In this particular SQL Server clustering example, WSFC1 and WSFC2 are in an on-site cluster replicating to a Huawei Cloud instance. Then an additional DataKeeper instance is launched in a region in Huawei Cloud. Please see Configuration of Data Replication From a Cluster Node to External DR Site for more information.

Huawei Cloud SIOS Datakeeper Hybrid DR Architecture

Requirements

Description Requirement
Virtual Private Cloud In a single region with three availability zones
Instance Type Minimum recommended instance type: s3.large.2
Operating System See the DKCE Support Matrix
Elastic IP One elastic IP address connected to the domain controller
Four instances One domain controller instance, two SQL Server instances and one quorum/witness instance
Each SQL Server ENI (Elastic Network Interface) with 4 IPs

·         Primary ENI IP statically defined in Windows and used by DataKeeper Cluster Edition

·         Three IPs maintained by ECS while used by Windows Failover Clustering , DTC and SQLFC

Volumes Three volumes (EBS and NTFS only)

·         One primary volume (C drive)

·         Two additional volumes

o    One for Failover Clustering

o    One for MSDTC

Release Notes

Before beginning, make sure you read the DataKeeper Cluster Edition Release Notes for the latest information. It is highly recommended that you read and understand the DataKeeper Cluster Edition Installation Guide.

Create a Virtual Private Cloud (VPC)

A virtual private cloud is the first object you create when using DataKeeper Cluster Edition.

*A virtual Private Cloud (VPC) is an isolated private cloud consisting of a configurable pool of shared computing resources in a public cloud.

  1. Using the email address and password specified when signing up for Huawei Cloud, sign in to the Huawei Cloud Management Console.
  2. From the Services dropdown, select Virtual Private Cloud.

  1. On the right side of the screen, click on Create VPC and select the region that you want to use.
  2. Input the name that you want to use for the VPC
  3. Define your virtual private cloud subnet by entering your CIDR (Classless Inter-Domain Routing) as described below
  4. Input the subnet name, then click Create Now.

*A Route Table will automatically be created with a “main” association to the new VPC. You can use it later or create another Route Table.

*HELPFUL LINK:
Huawei’s Creating a Virtual Private Cloud (VPC)

Launch an Instance

The following walks you through launching an instance into your subnet. You will want to launch two instances into one availability zone, one for your domain controller instance and one for your SQL instance. Then you will launch another SQL instance into another availability zone and a quorum witness instance into yet another availability zone.

*HELPFUL LINKS:
Huawei Cloud ECS Instances

  1. Using the email address and password specified when signing up for Huawei Cloud, sign in to the Huawei Cloud Management Console.
  2. From the Service List dropdown, select Elastic Cloud Server.

  1. Select Buy ECS button and choose the Billing Mode, Region and AZ (Availability Zone) to deploy the Instance
  2. Select your Instance Type. (Note:Select s3.large.2 or larger.).
  3. Choose an Image. Under Public Image, select the Windows Server 2019 Datacenter 64bit English image
    1. For Configure Network, select your VPC.
    2. For Subnet, select an Subnet that you want to use, select Manually-specified IP address and input the IP address that you want to use
    3. Select the Security Group to use or Edit and select an existing one.
    4. Assign an EIPif you need the ECS instance to access the internet
    5. Click Configure Advanced Settings and provide a name for the ECS, use Password for Login Mode and provide the secure password for Administrator login
    6. Click Configure Now on Advanced Options Add a Tag to name your instance and Click on Confirm
  4. Perform final review of the Instance and click on Submit.

*IMPORTANT: Make a note of this initial administrator password. It will be needed to log on to your instance.

Repeat the above steps for all instances.

Connect to Instances

You can connect to your domain controller instance via Remote Login from the ECS pane.

Login as administrator and enter your administrator password.

*BEST PRACTICE: Once logged on, it is best practice to change your password.

Configure the Domain Controller Instance

Now that the instances have been created, we started with setting up the Domain Service instance.

This guide is not a tutorial on how to set up an Active Domain server instance. We recommend reading articles on how to set up and configure an Active Directory server. It is very important to understand that even though the instance is running in a Huawei cloud, this is a regular installation of Active Directory.

Static IP Addresses

Configure Static IP Addresses for your Instances

  1. Connect to your domain controller instance.
  2. Click Start/ Control Panel.
  3. Click Network and Sharing Center.
  4. Select your network interface.
  5. Click Properties.
  6. Click Internet Protocol Version 4 (TCP/IPv4), then Properties.
  7. Obtain your current IPv4 address, default gateway and DNS server for the network interface from Amazon.
  8. In the Internet Protocol Version 4 (TCP/IPv4) Properties dialog box, under Use the following IP address, enter your IPv4 address.
  9. In the Subnet mask box, type the subnet mask associated with your virtual private cloud subnet.
  10. In the Default Gateway box, type the IP address of the default gateway and then click OK.
  11. For the Preferred DNS Server, enter the Primary IP Address of Your Domain Controller(ex. 15.0.1.72).
  12. Click Okay, then select Close. Exit Network and Sharing Center.
  13. Repeat the above steps on your other instances.

Join the Two SQL Instances and the Witness Instance to Domain

*Before attempting to join a domain make these network adjustments. On your network adapter, Add/Change the Preferred DNS server to the new Domain Controller address and its DNS server. Use ipconfig /flushdns to refresh the DNS search list after this change. Do this before attempting to join the Domain.

*Ensure that Core Networking and File and Printer Sharing options are permitted in Windows Firewall.

  1. On each instance, click Start, then right-click Computer and select Properties.
  2. On the far right, select Change Settings.
  3. Click on Change.
  4. Enter a new Computer Name.
  5. Select Domain.
  6. Enter Domain Name– (ex. docs.huawei.com).
  7. Click Apply.

*Use Control Panel to make sure all instances are using the correct time zone for your location.

*BEST PRACTICE: It is recommend that the System Page File is set to system managed (not automatic) and to always use the C: drive.

Control Panel > Advanced system settings > Performance > Settings > Advanced > Virtual Memory. Select System managed size, Volume C: only, then select Set to save.

Assign Secondary Private IPs to the Two SQL Instances

In addition to the Primary IP, you will need to add three additional IPs (Secondary IPs) to the elastic network interface for each SQL instance.

  1. From the Service List dropdown, select Elastic Cloud Server.
  2. Click the instance for which you want to add secondary private IP addresses.
  3. Select NICs > Manage Virtual IP Address.
  4. Click on Assign Virtual IP address and select Manual enter an IP address that is within the subnet range for the instance (ex. For 15.0.1.25, enter 15.0.1.26). Click Ok.
  5. Click on the More dropdown on the IP address row, and select Bind to Server, select the server to bind the IP address to, and the NIC card.
  6. Click OK to save your work.
  7. Perform the above on both SQL Instances.

*HELPFUL LINKS:
Managing Virtual IP Addresses
Binding a Virtual IP Address to an EIP or ECS

Create and Attach Volumes

DataKeeper is a block-level volume replication solution and requires that each node in the cluster have additional volume(s) (other than the system drive) that are the same size and same drive letters. Please review Volume Considerations for additional information regarding storage requirements.

Create Volumes

Create two volumes in each availability zone for each SQL server instance, a total of four volumes.

  1. From the Service List dropdown, select Elastic Cloud Server.
  2. Click the instance for which you want to manage
  3. Go to the Disks tab
  4. Click Add Disk to add a new volume of your choice and size, make sure you select the volume in the same AZ as the SQL server that you intend to attach it to
  5. Select the check box to agree to the SLA and Submit
  6. Click Back to Server Console
  7. Attach the disk if necessary to the SQL instance
  8. Do this for all four volumes.

*HELPFUL LINKS:
Elastic Volume Service

Configure the Cluster

Prior to installing DataKeeper Cluster Edition, it is important to have Windows Server configured as a cluster using either a node majority quorum (if there is an odd number of nodes) or a node and file share majority quorum (if there is an even number of nodes). Consult the Microsoft documentation on clustering in addition to this topic for step-by-step instructions. Note: Microsoft released a hotfix for Windows 2008R2 that allows disabling of a node’s vote which may help achieve a higher level of availability in certain multi-site cluster configurations.

Add Failover Clustering

Add the Failover Clustering feature to both SQL instances.

  1. Launch Server Manager.
  2. Select Features in the left pane and click Add Features in the Features This starts the Add Features Wizard.
  3. Select Failover Clustering.
  4. Select Install.

Validate a Configuration

  1. Open Failover Cluster Manager.
  2. Select Failover Cluster Manager, select Validate a Configuration.
  3. Click Next, then add your two SQL instances.

Note: To search, select Browse, then click on Advanced and Find Now. This will list available instances.

  1. Click Next.
  2. Select Run Only Tests I Select and click Next.
  3. In the Test Selection screen, deselect Storage and click Next.
  4. At the resulting confirmation screen, click Next.
  5. Review Validation Summary Report then click Finish.

Create Cluster

  1. In Failover Cluster Manager, click on Create a Cluster then click Next.
  2. Enter your two SQL instances.
  3. On the Validation Warning page, select No then click Next.
  4. On the Access Point for Administering the Cluster page, enter a unique name for your WSFC Cluster. Then enter the Failover Clustering IP address for each node involved in the cluster. This is the first of the three secondary IP addresses added previously to each instance.
  5. IMPORTANT!Uncheck the “Add all available storage to the cluster” checkbox. DataKeeper mirrored drives must not be managed natively by the cluster. They will be managed as DataKeeper Volumes.
  6. Click Next on the Confirmation
  7. On Summary page, review any warnings then select Finish.

Configure Quorum/Witness

  1. Create a folder on your quorum/witness instance (witness).
  2. Share the folder.
    1. Right-click folder and select Share With / Specific People….
    2. From the dropdown, select Everyone and click Add.
    3. Under Permission Level, select Read/Write.
    4. Click Share, then Done. (Make note of the path of this file share to be used below.)
  3. In Failover Cluster Manager, right-click cluster and choose More Actions and Configure Cluster Quorum Settings. Click Next.
  4. On the Select Quorum Configuration, choose Node and File Share Majority and click Next.
  5. On the Configure File Share Witness screen, enter the path to the file share previously created and click Next.
  6. On the Confirmation page, click Next.
  7. On the Summary page, click Finish.

Install and Configure DataKeeper

After the basic cluster is configured but prior to any cluster resources being created, install and license DataKeeper Cluster Edition on all cluster nodes. See the DataKeeper Cluster Edition Installation Guide for detailed instructions.

  1. Run DataKeeper setup to install DataKeeper Cluster Edition on both SQL instances.
  2. Enter your license key and reboot when prompted.
  3. Launch the DataKeeper GUI and connect to server.

*Note: The domain or server account used must be added to the Local System Administrators Group. The account must have administrator privileges on each server that DataKeeper is installed on. Refer to DataKeeper Service Log On ID and Password Selection for additional information.

  1. Right click on Jobs and connect to both SQL servers.
  2. Create a Job for each mirror you will create. One for your DTC resource, and one for your SQL resource..
  3. When asked if you would like to auto-register the volume as a cluster volume, select Yes.

*Note: If installing DataKeeper Cluster Edition on Windows “Core” (GUI-less Windows), make sure to read Installing and Using DataKeeper on Windows 2008R2/2012 Server Core Platforms for detailed instructions.

Configure MSDTC

  1. For Windows Server 2012 and 2016, in the Failover Cluster Manager GUI, select Roles, then select Configure Role.
  2. Select Distributed Transaction Coordinator (DTC), and click Next.

*For Windows Server 2008, in the Failover Cluster Manager GUI, select Services and Applications, then select Configure a Service or Application and click Next.

  1. On the Client Access Point screen, enter a name, then enter the MSDTC IP address for each node involved in the cluster. This is the second of the three secondary IP addresses added previously to each instance. Click Next.
  2. Select the MSDTC volume and click Next.
  3. On the Confirmation page, click Next.
  4. Once the Summary page displays, click Finish.

Install SQL on the First SQL Instance

  1. On the domain controller server create a folder and share it..
    1. For example “TEMPSHARE” with Everyone permission.
  2. Create a sub folder “SQL” and copy the SQL .iso installer into that sub folder.
  3. On the SQL server, create a network drive and attach it to the shared folder on the domain controller.
    • . For example “net use S: \\\TEMPSHARE
  4. On the SQL server the S: drive will appear. CD to the SQL folder and find the SQL .iso installer. Right click on the .iso file and select Mount. The setup.exe installer will appear with the SQL .iso installer.

F:\>Setup /SkipRules=Cluster_VerifyForErrors /Action=InstallFailoverCluster

  1. On Setup Support Rules, click OK.
  2. On the Product Key dialog, enter your product key and click Next.
  3. On the License Terms dialog, accept the license agreement and click Next.
  4. On the Product Updates dialog, click Next.
  5. On the Setup Support Files dialog, click Install.
  6. On the Setup Support Rules dialog, you will receive a warning. Click Next, ignoring this message, since it is expected in a multi-site or non-shared storage cluster.
  7. Verify Cluster Node Configuration and click Next.
  8. Configure your Cluster Network by adding the “third” secondary IP address for your SQL instance and click Next. Click Yes to proceed with multi-subnet configuration.
  9. Enter passwords for service accounts and click Next.
  10. On the Error Reporting dialog, click Next.
  11. On the Add Node Rules dialog, skipped operation warnings can be ignored. Click Next.
  12. Verify features and click Install.
  13. Click Close to complete the installation process.

Install SQL on the Second SQL Instance

Installing the second SQL instance is similar to the first one.

  1. On the SQL server, create a network drive and attach it to the shared folder on the domain controller as explained above for the first SQL server.
  2. Once the .iso installer is mounted, run SQL setup once again from the command line in order to skip the Validate Open a Command window, browse to your SQL install directory and type the following command:

Setup /SkipRules=Cluster_VerifyForErrors /Action=AddNode /INSTANCENAME=”MSSQLSERVER”

(Note: This assumes you installed the default instance on the first node)

  1. On Setup Support Rules, click OK.
  2. On the Product Key dialog, enter your product key and click Next.
  3. On the License Terms dialog, accept the license agreement and click Next.
  4. On the Product Updates dialog, click Next.
  5. On the Setup Support Files dialog, click Install.
  6. On the Setup Support Rules dialog, you will receive a warning. Click Next, ignoring this message, since it is expected in a multi-site or non-shared storage cluster.
  7. Verify Cluster Node Configuration and click Next.
  8. Configure your Cluster Network by adding the “third” secondary IP address for your SQL Instance and click Next. Click Yes to proceed with multi-subnet configuration.
  9. Enter passwords for service accounts and click Next.
  10. On the Error Reporting dialog, click Next.
  11. On the Add Node Rules dialog, skipped operation warnings can be ignored. Click Next.
  12. Verify features and click Install.
  13. Click Close to complete the installation process.

Common Cluster Configuration

This section describes a common 2-node replicated cluster configuration.

  1. The initial configuration must be done from the DataKeeper UI running on one of the cluster nodes. If it is not possible to run the DataKeeper UI on a cluster node, such as when running DataKeeper on a Windows Core only server, install the DataKeeper UI on any computer running Windows XP or higher and follow the instruction in the Core Only section for creating a mirror and registering the cluster resources via the command line.
  2. Once the DataKeeper UI is running, connect to each of the nodes in the cluster.
  3. Create a Job using the DataKeeper UI. This process creates a mirror and adds the DataKeeper Volume resource to the Available Storage.

!IMPORTANT: Make sure that Virtual Network Names for NIC connections are identical on all cluster nodes.

  1. If additional mirrors are required, you can Add a Mirror to a Job.
  2. With the DataKeeper Volume(s)now in Available Storage, you are able to create cluster resources (SQL, File Server, etc.) in the same way as if there were a shared disk resource in the cluster. Refer to Microsoft documentation for additional information in addition to the above for step-by-step cluster configuration instructions.

Connectivity to the cluster (virtual) IPs

In addition to the Primary IP and secondary IP, you will also need to configure the virtual IP addresses in the Huawei Cloud so that they can be routed to the active node.

  1. From the Service List dropdown, select Elastic Cloud Server.
  2. Click on one of the SQL instance for which you want to add cluster virtual IP address (one for MSDTC, one for SQL Failover Cluster)
  3. Select NICs > Manage Virtual IP Address.
  4. Click on Assign Virtual IP address and select Manual enter an IP address that is within the subnet range for the instance (ex. For 15.0.1.25, enter 15.0.1.26). Click Ok.
  5. Click on the More dropdown on the IP address row, and select Bind to Server, select both the server to bind the IP address to, and the NIC card.
  6. Use the same steps 4. and 5 for the MSDTC and SQLFC virtual IPs
  7. Click OKto save your work.

Management

Once a DataKeeper volume is registered with Windows Server Failover Clustering, all of the management of that volume will be done through the Windows Server Failover Clustering interface. All of the management functions normally available in DataKeeper will be disabled on any volume that is under cluster control. Instead, the DataKeeper Volume cluster resource will control the mirror direction, so when a DataKeeper Volume comes online on a node, that node becomes the source of the mirror. The properties of the DataKeeper Volume cluster resource also display basic mirroring information such as the source, target, type and state of the mirror.

Troubleshooting

Use the following resources to help troubleshoot issues:

  • Troubleshooting issues section
  • For customers with a support contract – http://us.sios.com/support/overview/
  • For evaluation customers only – Pre-sales support

Additional Resources:

Step-by-Step: Configuring a 2-Node Multi-Site Cluster on Windows Server 2008 R2 – Part 1 — http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-%E2%80%93-part-1/

Step-by-Step: Configuring a 2-Node Multi-Site Cluster on Windows Server 2008 R2 – Part 3 — http://clusteringformeremortals.com/2009/10/07/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-%E2%80%93-part-3/

Filed Under: Blog posts, Clustering Simplified, Datakeeper Tagged With: #SANLess Clusters for SQL Server Environments, #SANLess Clusters for Windows Environments, disaster recovery, ECS, High Availability, Huawei Cloud, SQL Server Failover Cluster

High Availability and DR for S/4HANA and other SAP platforms

April 28, 2020 by Jason Aw 1 Comment

High Availability and DR for S/4HANA and other SAP platforms

High Availability and DR for S/4HANA and other SAP platforms

SAP is the market leader in enterprise application software. Over the span of many years, SAP had helped companies of all sizes and in all industries run efficiently and effectively. As a result of their hard work, they have built an ecosystem of enterprises heavily reliant on its platform. 77% of the world’s transaction revenue touches an SAP system.

SAP application touches many critical parts of a company such as its’ ERP, manufacturing, business processes, customer service etc. It has become the lifeline of many enterprises that depends on it for their business to operate properly. As such, high-availability has became one of the top concerns of company managements when it comes to their SAP systems.

In this article, we will discuss at a high-level what is HANA system replication and how it works. What are the limitations when it comes to high-availability, and how we can overcome them. We will also discuss about the options for HANA’s high-availability and the key differences.

To select the right solution to use for HA, ask yourselves at the end of the day

  • Meet Recovery Time Objectives (RTO)

—– How long can SAP be down before you recover?

  • Meet Recovery Point Objectives (RPO)

—–  How old can your data be when service is restored

  • Meet Availability Service Level Agreements (SLA)

—– How much uptime do you need?

SAP HANA system replication

SAP HANA System Replication is a reliable data protection and disaster recovery solution that provides continuous synchronization of a HANA database to a secondary location either in the same data center, remote site or in the cloud.

System Replication is a standard SAP HANA feature that comes with the software. Using this feature, all data is replicated to the secondary site and data is pre-loaded into memory on the secondary site which helps to reduce the recovery time objective (RTO) significantly. So in case of a failover, the secondary site will be able to take over without even performing a HANA DB (re)start and will work as primary DB instantaneously upon failover. However, the failover has to be triggered manually by the admin using the sr_takeover command. For the replication to be reversed, or failback to primary, separate commands will need to be issued as well.

HANA System Replication failover high-availability and DR
Figure 1: HANA System Replication failover high-availability and DR

Below are some key points of the HANA system replication method for HA and DR:

  • Redundant Servers / Nodes
  • In-memory database replicated by HANA system replication (in “log replay” mode)
  • Multiple replication options: sync, sync-mem, async
  • Supports active-active (read-only on secondary)
  • Setup and admin through HANA cockpit, HANA studio or command line

Limitations

  • No monitoring of application process or replication failures and automated failover
  • Failover, reverse replication and failback has to be performed manually – many manual steps are needed
  • No virtual IP
  • No integrated HA failover orchestration together with SAP ASCS etc. components

As you can probably deduce from the above points by now, HANA system replication is designed to protect against data loss. Such that when an issue happens with the primary node, an admin can manually run a “sr_takeover” command, so that a problem with the primary system will not take down the entire SAP setup which depends on the HANA database for the prolonged period of downtime. However, a lot of this work has to happen manually and depends on human manual intervention, which although is good enough for DR, it does not make an ideal situation for HA (where downtime needs to be prevented).

SIOS High Availability Clustering

SIOS high availability software for SAP lets you protect SAP S/4HANA in any configuration (or combination) of physical, virtual, cloud (public, private, and hybrid) and high performance flash storage environments. SIOS software provides easy and flexible configuration, fast replication, and comprehensive monitoring and protection of the entire SAP S/4HANA environment.

Specifically for SAP S/4HANA and the HANA database. SIOS can be used to complement what SAP is already doing with the HANA system replication. SIOS adds on to what SAP has to provide true high-availability – automated monitoring of key HANA application processes, and provide automated failover, failback, including virtual IP(s), even if you have multi-instance within a single HANA node.

SIOS HANA System Replication failover high-availability and DR
Figure 2: SIOS HANA System Replication failover high-availability and DR

Below are some key points of the SIOS Protection Suite for SAP HANA HA and DR:

  • Works in the cloud cross AZ and AR
  • Provides automated failure detection and failover for key SAP HANA DB components:
    — SAP HANA Host Agent
    — SAP HANA sapstartsrv
    — SAP HANA Replication
  • Enables automated SAP HANA replication takeover, switchback
  • Automatically reverse replication
  • Verifies and monitors that the HANA DB is running
  • Provides Virtual IP
  • “Full stack” failover orchestration with ASCS etc. SAP components

Four steps to install and configure HA for HANA database

We will not discuss the specific steps of how to configure SAP HANA, since there are already many on-line resources that cover those steps. But at a high-level, what you need to do are 4 basic steps:

  1. Install SAP HANA
  2. Configure HANA system Replication
    See – https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.02/en-US/676844172c2442f0bf6c8b080db05ae7.html
  3. Install SIOS protection suite
    See – http://docs.us.sios.com/spslinux/9.4.1/en/topic/sios-protection-suite-for-linux-installation-guide
  4. Use HANA recovery kit (wizard) in GUI to protect HANA
    See – http://docs.us.sios.com/spslinux/9.4.1/en/topic/sap-hana-recovery-kit

The installation process flow are similar for other SAP components (ASCS, ERS, PAS, Web Dispatcher etc.) as well.

With the HANA recovery kit included in the SIOS protection suite software, you can basically use a wizard in the SIOS Lifekeeper management GUI, to quickly protect a HANA database instance. You can also assign the virtual IP address for clients to connect to it, and manage the entire stack from it. Build a multi-instance environment and the solution will manage all the instances, virtual IPs etc. within the a fully integrated GUI, which makes it very easy to configure, manage the entire SAP landscape that is on SIOS HA.

SIOS Lifekeeper Management GUI for SAP HANA ASCS and ERS
Figure 3: SIOS Lifekeeper Management GUI for SAP HANA ASCS and ERS

Comprehensive HA/DR stack for SAP –

Other than HANA database, SIOS Protection Suite also provides protection for key SAP services and supporting applications, all of which can be managed from the same GUI :

  • Primary Application Server (PAS)
  • ABAP SAP Central Service (ASCS)
  • SAP Central Services (SCS)
  • Enqueue and message servers
  • Enqueue Replication Server (ERS)
  • Database (Oracle, Sybase, MaxDB, HANA, etc)
  • Shared and/or Replicated File Systems
  • Logical Volumes (LVM)
  • NFS Mounts and Exports
  • Virtual IPs

Clustering in the cloud

When moving SAP to the cloud, one of the key challenges is how to protect the SAP database, as well as the SAP applications stack in a SAP supported architecture. SIOS has been forefront of this move and are designed, certified and supported by SAP as well as all the major cloud providers.

The diagram below is a high-level design of how a pair of S/4HANA system can be deployed across different availability zones, or even regions. In cloud environments, as the providers do have very low latencies between AZs, it is entirely possible to use synchronous replication across the AZs, thereby creating a pair of highly available S/4HANA system, not just for HA but also for DR at the same time. This is because AZs are geographically separate datacenters, much like how on-premise DR datacenters are, which highly redundant high-speed network connectivity between them.

SIOS Protection Suite for SAP S/4HANA cloud architecture
Figure 4: SIOS Protection Suite for SAP S/4HANA cloud architecture

Why use SIOS over open-source HA for SAP?

This question will invariably come up in people’s mind, since some Linux vendors already provide their HA extensions (HAE) or clustering, why would anyone want to use a commercial 3rd party HA solution like SIOS?

  1. Open-source HA is being offered as part of certain OS flavors “enterprise SAP” extensions subscription – it comes at a cost, it’s definitely not free, and not all Linux flavors are supported. SIOS supports all the major Linux flavors including Redhat, SUSE, Centos and Oracle Linux. For customers who want to run Windows for their ASCS or Content Server etc. SIOS also has Windows based solution with Windows clustering support, making it a one-stop-shop for the entire SAP landscape regardless of platform.
  2. Commercial HA support – OS vendors depend on open-source community for bug fixes, which can be a problem if the bug requires a longer time to get solved by a less active contributor. SIOS provides commercial support with dedicated support and development team just for its high-availability solution. It has immediate 24×7 support resolution, which would give customers much more confidence when there are issues that may develop.
  3. Complex setup and admin via command line is needed by open-source tools. They are made up of different components like Pacemaker, Corosync etc. maintained by different open-source initiatives. SIOS provides all-in-one GUI for wizards-based setup and admin. It allows one to deploy SAP HA in a matter of hours instead of weeks/months.
  4. SIOS provide pre-built application monitoring and failover orchestration for all SAP and cloud components requiring HA through a wizard in the GUI, as opposed to using HA extensions that still requires a lot of manual configuration.
  5. Automatically ensures SAP ERS is always running in opposite node of ASCS – SIOS provides the intelligence even in a multi-node ASCS setup, if a failover occured and ASCS failsover to the node with the running ERS, when the original ASCS node recovers, ERS gets automatically switched across so that the locks are always getting the redundancy needed. Opensource solution requires this to be done manually, hence impacts reliability and availability especially in times of multiple failures and recovery.
  6. SIOS reduces implementation/management time and costs, the lesser time you spend implementing and maintaining HA, the more time you will have for other more important tasks.
  7. Open-source use its STONITH mechanism which had been hardly reliable especially in cloud environments, SIOS provides multi-throng approach to prevent false failover and split-brain – quorum witness, multiple comm. path (heartbeat) which has been proven for over 20 years to be highly reliable in many scenarios.

Summary

SAP HANA system replication feature comes as part of the software and works well to protect the database from dataloss in case a problem arise from hardware or system failures. However if high-availability is the requirement, it would still need a 3rd party solution in order to get some of the automated monitoring, failover orchestration, virtual IP and so on. While there are opensource options in the form of enterprise Linux OS subscriptions for SAP, they certainly do not come free, and technical support is still limited as they purely relying on opensource community to maintain the Pacemaker, Corosync etc. projects. and to get support from contributors. There are also limitations in the native System Replication, opensource HAE which can be overcome by a commercial software solution vendor like SIOS.

Hence, SIOS as a reliable 3rd party high-availability solution provider can help to ensure enterprise customers get the reliability and high-availability that they need in their mission critical SAP systems operations. For a peace of mind, SIOS proves to be a very viable complementary solution to SAP HANA system replication, which is also fully supported by SAP and all the major OS and platform vendors.

Author:

Jason Aw SIOS Technology
Jason Aw
An IT professional who has been focused on high-availability and disaster recovery for over 20 years. Currently employed at SIOS Technology Corp. as Strategic Business Development for APAC.

Filed Under: Blog posts, Clustering Simplified

Managing Alert-Stress for AWS EC2 with SIOS AppKeeper

April 7, 2020 by Jason Aw Leave a Comment

Managing Alert-Stress for AWS EC2 with SIOS AppKeeper

Managing Alert-Stress for AWS EC2 with SIOS AppKeeperHas this ever happened to you? You receive an alert about an application issue when you are out of the office, and you don’t have the information you need to address it? And you either need to access your cloud management console from an inconvenient location or pass the information on to another colleague to address? Or you are investigating an alert when another one comes in requiring your attention? Research has shown it can take the average person 23 minutes to recover from unexpected interruptions.

With companies moving to the cloud and having to manage more complex computing environments, this “alert stress” is starting to take a toll on workers’ productivity and mental health. Cloud monitoring solutions are trying to give you more information so you can resolve issues faster, but the depth of information they provide and the volume of alerts can be overwhelming.

Is Application Performance Management for AWS Enough?

Migrating to an AWS cloud infrastructure means that you often have to adopt new ways of managing and monitoring your applications. You can take advantage of AWS’s native cloud management functionality for your EC2 environment. But many companies quickly outgrow the functionality of these tools and deploy commercial Application Performance Management (APM) solutions for wider coverage and deeper insights.

But here’s the thing. These sophisticated APM solutions can be creating more work for you.  Yes, they often come with alert notification workflows to put the right information into the right person’s hands quickly.  But they do very little to fix the situation without manual intervention. The result: lots of stress-inducing alerts needing your immediate attention.

That’s why we created SIOS AppKeeper. It is the industry’s first out-of-the-box solution to automatically respond to service outages on Amazon EC2 instances. AppKeeper allows companies to protect applications from service interruptions and downtime while eliminating the need for costly and time-consuming manual intervention.

AppKeeper Automatically Restarts Failed Services in AWS EC2

SIOS AppKeeper not only identifies and sends notifications for failures. But it will also automatically attempt to restart failed services or reboot the instance if necessary. Our users have found that AppKeeper automatically addresses almost 85% of the application service failures that occur.  Without having to disrupt you, your I.T. or Development team or third-parties.

SIOS customers and partners in Japan have been using SIOS AppKeeper since 2017 to protect their AWS environments. ForgeVision is an AWS Advanced Consulting partner, integrates AppKeeper into its cloud management console. It has been allowing it to monitor and recover customers’ failures more cost-effectively. And AppKeeper is allowing Hobby Japan, a publishing company in Tokyo, to create a maintenance-free, low-cost environment.

We invite you to learn more about SIOS AppKeeper by watching this short video or by signing up to use AppKeeper for free until June 30th.

Then you can see for yourself what it’s like to have systems failures in AWS EC2 automatically addressed.

– Daisuke Yoshioka, Manager, Business Development for SIOS AppKeeper.

 

Reproduced from SIOS

Filed Under: Blog posts Tagged With: Amazon AWS, AppKeeper, Application availability, application monitoring

Thoughts on COVID-19 and Assistance for Remote IT

March 27, 2020 by Jason Aw Leave a Comment

Thoughts on COVID-19 and Assistance for Remote IT

JFK assassination. 9/11. And now COVID-19. Life-changing events that forever stick in our memories, forever change us. Yet when these life situations occur it can bring us together, and make us rethink what really matters; family, friends, colleagues, neighbors, and even those we’ve never met, because in each of us there is innate compassion for our fellow human beings. These events show us what we’re made of as individuals, as a nation, and now as a world.

As we adapt to life with the current pandemic, for many the new norm is working from home, Zoom meetings, and hoping we’re not off mute when the dog goes berserk because his buddy is walking by and he wants to go out and play. That timing never seems to work out. But we take it in stride, because we’re all in very similar boats, and it is what it is. We’re all trying to make the best of a complex situation.

Working From Home Adds Strain to IT Teams

Working from home not only puts added pressure on those doing it, but it also adds a load of pressure on the systems that are supporting our remote IT operations and, of course, our IT teams. It’s challenging when critical systems are down when everyone is together in the office, but it can be exponentially worse when everyone is working remotely, relying on even those not-so-critical systems to maintain productivity.

How SIOS Can Help

To help companies manage these new remote IT challenges and help keep these systems operational, we are offering the use of SIOS AppKeeper at no cost until June 30, 2020. Please feel free to use AppKeeper to help keep your AWS workloads up and running and, hopefully, alleviate some of your stress and worry during these difficult times.

We’ll get through this. We always do. And we’ll do it together.

Be safe. Be careful. Be healthy.

-Michael Bilancieri SIOS SVP, Products and Marketing

Reproduced from SIOS

Filed Under: Blog posts Tagged With: covid-19, remote IT

SIOS Product Update: What’s New in SIOS Protection Suite and DataKeeper Cluster Edition – Windows

March 26, 2020 by Jason Aw Leave a Comment

SIOS Product Update: What’s New in SIOS Protection Suite and DataKeeper Cluster Edition – Windows

SIOS is pleased to announce the release of version 8.7.1 of our SIOS Protection Suite-Windows and DataKeeper Cluster Edition-Windows products. The new release broadens support and adds new features to meet our customers’ needs for easy, cost-optimized high availability.

The following features and additional support are being introduced as part of this update for DataKeeper and SIOS Protection Suite:

  • Public Cloud:

    • In Azure:
      • Additional support for multiple virtual IP addresses using the Azure Load Balancer Multiple Frontends function, allows easier configuration and management of SIOS Protection Suite.
    • In AWS:
      • A wide range of instance types are now supported, including AWS Nitro System instances that enable high performance, high availability, high security, and bare metal capabilities to eliminate virtualization overhead.
  • Database:

    • EDB Postgres Advanced Server
      • Continuing our expansion of key databases, we can now protect EDB Postgres Advanced Server, an open-source database management system used as an alternative to Oracle.
    • SQL Server 2019
      • Now tested and supported on both SIOS Protection Suite – Windows and DataKeeper Cluster Edition – Windows on all Windows Server platforms 2016 and later (Released to the market in November 2019)

What’s next? Let us know what you’d like to see and check back for more updates!

Reproduced from SIOS

Filed Under: Blog posts Tagged With: DataKeeper Cluster Edition, sios protection suite

  • 1
  • 2
  • 3
  • …
  • 7
  • Next Page »

Recent Posts

  • Streamlining External Communication for Emergency Procedures
  • Avoiding the Disaster You Don’t See Coming: Building a Resilient DR Plan
  • The Best Rolling Upgrade Strategy to Enhance Business Continuity
  • How to Patch Without the Pause: Near-Zero Downtime with HA
  • SIOS LifeKeeper Demo: How Rolling Updates and Failover Protect PostgreSQL in AWS

Most Popular Posts

Maximise replication performance for Linux Clustering with Fusion-io
Failover Clustering with VMware High Availability
create A 2-Node MySQL Cluster Without Shared Storage
create A 2-Node MySQL Cluster Without Shared Storage
SAP for High Availability Solutions For Linux
Bandwidth To Support Real-Time Replication
The Availability Equation – High Availability Solutions.jpg
Choosing Platforms To Replicate Data - Host-Based Or Storage-Based?
Guide To Connect To An iSCSI Target Using Open-iSCSI Initiator Software
Best Practices to Eliminate SPoF In Cluster Architecture
Step-By-Step How To Configure A Linux Failover Cluster In Microsoft Azure IaaS Without Shared Storage azure sanless
Take Action Before SQL Server 20082008 R2 Support Expires
How To Cluster MaxDB On Windows In The Cloud

Join Our Mailing List

Copyright © 2025 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in