SIOS SANless clusters High-availability Machine Learning monitoring
While downtime in business-critical systems, databases, and applications imposes costs on every organization, different industries have different consequences associated with unplanned downtime.
In this tech brief, we explore high availability (HA) use cases and SIOS customer success stories in the financial services, healthcare, manufacturing, and education industries.
BMS solutions are central to the building or campus they manage, so they need to be protected from unscheduled downtime and disaster-related outages. Indeed, given that they control a building’s most vital safety services, a BMS must remain operational and accessible, particularly in an emergency. The challenge is, how do you configure a BMS solution to operate at such a high level of availability without adding unnecessary cost and complexity?
Fill in your details to download your copy of White Paper: Building Management Systems and the Need for High Availability
Reproduced with permission from SIOS
In the last decade, cloud computing has emerged as a major platform for computing deployments. Both AWS and Microsoft claim that large swaths of the Fortune 500 use their services, and both Google and Oracle have compelling cloud offerings as well. This has led many organizations, whether by design or by accident, to have workloads running in multiple clouds. Learn about Multicloud, its use-cases, risks and best practices for maintaining high availability.
Reproduced with permission from SIOS
In this blog, I will discuss the Generic Load-Balancer Application Recovery Kit (ARK) for SIOS Lifekeeper for Linux and specifically how to configure it on Microsoft Azure. I will use a two node NFS cluster and the NFS exports they provide will ultimately be accessed via the load-balancer.
SIOS has created this ARK to facilitate client redirection in LifeKeeper clusters running in Azure.
Since Azure does not support gratuitous ARP, clients cannot connect directly to traditional cluster virtual IP addresses. Instead, clients must connect to a load balancer and the load balancer redirects traffic to the active cluster node. . Azure implements a load-balancer solution that operates on layer 4 (TCP, UDP), the Load-Balancer can be configured to have private or public frontend IP(s), a health-probe that can determine which node is active, a series of backend IP addresses (for each node in a cluster) and incoming/outgoing network traffic rules.
Traditionally the health probe would monitor the active port on an application and determine which node that application is active on, The SIOS generic load-balancer ARK is configured to have the active node listen on a user defined port. This port is then configured in the Azure Load-balancer as the Health Probe Port. This allows the active cluster node to respond to TCP health check probes, enabling automatic client redirection..
Within the Azure portal, select load-balancing
Create a load-balancer, you will select the resource group where you want this to be deployed as well as the name, I like to use a name that lines up with the cluster type that I’m using the load balancer with for example IMA-NFS-LB will sit in front of both IMA-NFS nodes.
You can determine whether this will be a public or private LB. In this case I’m configuring a private Load-Balancer to front my NFS server for use only within this resource group.
Once you determine what the name, resource group etc will be then you will be asked to assign a Name, Virtual network, subnet and an IP for the load-balancer. The IP address should be the same IP address that you will create in LifeKeeper as a virtual IP address.
Once the basic information is entered for the load-balancer you will need to define which machines are to be configured in the backend to serve the load-balancer, in my case this backend pool will consist of the two nodes that I’m using for my NFS server.
You will require a load-balancing rule, this is how the load-balancer will determine what traffic to route to the active node. – The port number configured here will be used in SPS-L when you configure the generic application to support the Load-balancer. In this example we are using “HA Ports”, which will route all traffic to the active node. If you want to limit what traffic to route you can specify a specific application port.
The frontend IP should be the load-balancer IP, the backend pool should be the nodes that you configured to be the resources used by the load-balancer. Ensure that the “HA Ports” button is selected and “Floated IP” is enabled. “TCP reset” can be left disabled.
When you create the health probe, make sure you note the port that you configure here as it will be used when we create the generic application within the SIOS Protection Suite. You can use the standard values for “interval” and “Unhealthy threshold”. These can be changed at a later time if you have application specific requirements.
Now the load balancing rule should be complete with a health probe. Select “Add”
Once we select “add” then Azure will start the deployment of the Load Balancer, this can take several minutes and once complete then the configuration moves on to the SIOS Protection Suite.
NOTE: Once the backend machines are configured behind a load-balancer they will lose access to the internet gateway so things like system updates will not work. You can remove the machines from the backend resource group to allow internet access again.
For this blog I have configured three NFS exports to be protected using SPS-L, the three exports are configured to use the same IP as the Azure load balancer’s frontend IP. I’m using Datakeeper to replicate the data stored on the exports.
First step is to obtain the scripts, the simplest way is to use wget but you can also download the entire package and upload the rpm directly to the nodes using winscp or a similar tool. You need to install the Hotfix on all nodes in the Lifekeeper cluster.
The entire recovery kit can be obtained here: http://ftp.us.sios.com/pickup/LifeKeeper_Linux_Core_en_9.5.1/patches/Gen-LB-PL-7172-9.5.1
The parts can be found here with wget:
wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/Gen-LB-readme.txt
Once downloaded, verify the MD5 sum against the value recorded on the FTP site.
Install the RPM as follows:
rpm -ivh steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm
Check that the install was successful by running:
rpm -qa | grep steeleye-lkHOTFIX-Gen-LB-PL-7172
Should you need to remove the RPM for some reason, this can be done by running:
rpm -e steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64
Below is the GUI showing my three NFS exports that I’ve already configured:
What we need to do within the SIOS Protection Suite is define the Load Balancer using the Hotfix scripts provided by SIOS.
First we create a new resource hierarchy, we select Generic Application from the drop down
Define the restore.pl script located in /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/
Define the remove.pl script located in /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/
Define the quickCheck script located in /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/
There is no local recovery script, so make sure you clear this input
When asked for Application Info, we want to enter the same port number as we configured in the Health Probe configuration e.g. 54321
We will choose to bring the service into service once it’s created.
Resource Tag is the name that we will see displayed in the SPS-L GUI, I like to use something that makes it easy to identify.
If everything is configured correctly you will see “END successful restore”, we can then extend this to the other node so that the resource can be hosted on either node.
This shows the completed Load Balancer configuration following extension to both nodes.
The last step for this cluster is to create child dependencies for the three NFS exports, this means that all the NFS exports complete with Datakeeper mirrors and IPs will rely on the Load Balancer. Should a serious issue occur on the active node then all these resources will fail-over to the other functioning node.
Above, the completed hierarchy in the Lifekeeper GUI. Below shows the expanded GUI view showing the NFS exports, IP, Filesystems and DataKeeper replicated volumes as children of the Load Balancer resource.
This is just one example of how you can use SIOS LifeKeeper in Azure to protect a simple NFS cluster. The same concept applies to any business critical application you need to protect. You simply need to leverage the Load Balancer ARK supplied by SIOS to allow the Azure Load Balancer (Internal or External) to determine which node is currently hosting the application.
SIOS SAN and SANless clustering software provides comprehensive SAP certified protection for your applications and data, including high availability, data replication, and disaster recovery in an easy, cost-efficient solution.
SIOS software lets you protect SAP and HANA 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 application environment.
SAN and SANless Clusters You can use SIOS LifeKeeper software to build a traditional SAN-based cluster or build a SIOS SANless cluster by synchronizing local storage on the active SAP Server with local storage on a standby server using SIOS real time, block-level replication. Replication can operate in either synchronous or asynchronous mode.
Unlike traditional clustering software that only checks that the server is alive, SIOS LifeKeeper software monitors the health of the entire SAP environment and provides application-aware high availability to ensure maximum uptime. SIOS software verifies that SAP is running, file shares or NFS exports are available, databases are mounted and available, and clients are able to connect. SIOS software actively monitors: servers, operating systems, SAP Primary Application Server (PAS) Instance, ABAP SAP Central Service (ASCS) Instance, back-end databases (Oracle, DB2, MaxDB, MySQL and PostgreSQL), the SAP Central Services Instance (SCS), volumes or file systems, file shares or NFS mounts, IP and virtual IP, Enqueue and message servers,and Logical Volumes (LVM).
In the event of a failure on the active server, SIOS software moves SAP operation to the standby server. SIOS software lets you configure standby servers that are either local or remote over a LAN or WAN. Real-time replication ensures immediate recovery from a local system failure and allows you to create multiple real-time copies through one-to-many replication.
SIOS clusters can also stop and restart the application both locally and on another cluster server at either the same site or at another geographic location. When the SIOS software detects a problem, it automatically initiates one of three configurable recovery actions that will maximize uptime and protection for applications and data: it may attempt a restart on the same server; switchover to a standby server; or alert a system administrator. It performs both local recovery or complete failover quickly and easily.
The SIOS software makes DR testing easy by allowing administrators to move SAP to the DR site for testing and to move it back to the primary site when testing is done. It also lets you leave SAP in service in the primary site while completing DR testing with no impact to your production network by unlocking the target data, bringing SAP into service on the backup system to verify recovery.
• Protects your entire SAP stack with high availability clustering, continuous data replication, and disaster recovery functionality
• Enables single- and multi-site clusters using existing servers and storage
• Supports both JAVA and ABAP versions of SAP servers running on Red Hat Enterprise Linux, SUSE Linux Enterprise Server, or Windows and accommodates a wide range of storage architectures.
• Intuitive, wizard-driven GUI simplifies installation, configuration and management
• Supports physical, virtual or cloud environments and a wide range of storage architectures
• Reduces data transfer costs in cloud environments • Efficient replication engine minimizes network traffic— without hardware accelerators or compression devices. • Saves labor cost by automating data replication tasks using an intuitive management console
Reproduced with permission from SIOS