SIOS SANless clusters - Page 33 of 188 - SIOS SANless clusters High-availability Machine Learning monitoring

October 6, 2022	The Generic Application Recovery Kit The Generic Application Recovery Kit The SIOS Protection Suite for Linux comes with an array of handy Application Recovery Kits covering major databases such as SAP HANA and Oracle, IP, File Systems and NAS or NFS shares and exports. Every SIOS supplied ARK has restore(start), remove(stop), quickcheck and recover scripts – these are not readily configurable beyond any options asked for during configuration and addition into a protected hierarchy. These ARKs are developed, maintained, quality checked and in some cases “support certified” by the application vendors themselves. What do you do if you have an application or service that’s not covered by an existing SIOS ARK? Enter the generic ARK. The generic ARK can be added into a hierarchy and configured in a similar manner to other SIOS ARKs; the special thing about the generic ARK is that it requires you to provide a restore, remove and quickCheck script and optionally a recover script. You can use any configured scripting language to create your scripts (BASH or Perl are common), lets investigate these scripts a little further: restore: This is the script that is used to start your service or application remove: This is the script used to stop your service or application quickCheck: This script is used to determine whether your application or service is functioning as you would expect it to recover: This script would be used to attempt a recovery following a failure, certain applications and services lend themselves to being restarted or certain commands being run to try to recover from a failure scenario By default, the quickCheck script runs every 180 seconds. If the quickCheck script detects a failure of the application it calls the recover script. The recover script tries to restart the application on the current node. Should the recover script fail to restart the application, or a recover script is not provided, the remove script is then executed. This initiates a failover to the standby node. Templates for the Generic Application Kit SIOS provides example templates for the Generic Application Kit. These examples are installed with the lifekeeper software and can be found here: quickCheck, remove and restore /opt/Lifekeeper/lkadm/subsys/gen/app/templates/actions/ recovery /opt/Lifekeeper/lkadm/subsys/gen/app/templates/recovery There are examples for quickCheck, remove and restore in both BASH (.sh) and Perl (.pl) languages. The example scripts are self documented with comments throughout the script. Assuming that you’re familiar with either BASH or Perl then you will be able to understand what the scripts are doing.. A return code of 0 indicates a successful run, other values indicate a failure. The results of a script will trigger the next action that LifeKeeper takes. Setup within Lifekeeper After you have created your scripts you can create a Generic Application by clicking the green plus sign to create a new resource. Choose “Generic Application” to launch the configuration wizard. Add a resource and select Generic Application Select the Restore script Select the Remove script start from here Select the QuickCheck script Select the Recovery script (none in this example) The Application Info is a way to pass in information to the GenAPP scripts. For example, in our GenAPP for the generic load balancer we use this field to pass the port that the load-balancer is listening on. Select whether or not you want to bring the GenAPP online once it’s created, sometimes you want to leave the GenAPP offline so that you can create any dependencies that might be required. Give the resource that will be created a name Once you have entered all the information, the resource will be created So you can see that creating a GenAPP to protect almost any application is straightforward and easy. A GenAPP allows you to protect ANY application, even custom applications that are built inhouse. If you would like to learn more about how SIOS can help you keep your business critical applications available please contact us! Reproduced with permission by SIOS
October 4, 2022	AWS Summit Singapore – SILVER SPONSOR AWS Summit Singapore – SILVER SPONSOR October 6 @ 8:00 am – 5:00 pm SIOS is pleased to be a Silver sponsor at AWS Summit Singapore this year. Discover how public sector organizations of all sizes are using AWS to innovate rapidly, improve citizens’ lives, and transform their operations. Hear from peers and subject matter experts from across the globe who have successfully built solutions on AWS.
October 2, 2022	How to convert from SIOS NFS resources to EFS How to convert from SIOS NFS resources to EFS As many customers look into migrating their SAP solutions into AWS, they may also want to convert existing network file shares (NFS) shares for /sapmnt or /usr/sap/<SID> file systems into elastic file system (EFS) shares. EFS shares are hosted as cloud file storage that can be managed the same as any local file system. In this case any data that is placed in an EFS share will have much higher protection due to the high availability and durability provided. Steps for Converting an Existing SAP Hierarchy using NFS to EFS Companies who are currently using SIOS LifeKeeper for Linux clusters to protect SAP on premises can easily convert their SAP hierarchy from NFS to EFS using the following straightforward steps. The process should only take about 20 minutes. In this example, the SIOS LifeKeeper Linux solution is protecting an NFS export share /exports/sapmnt/EDM with local mount point /sapmnt/EDM (i.e. 12.1.4.10:/exports/sapmnt/EDM /sapmnt/EDM) (Figure 1). Create the EFS share reference: https://docs.aws.amazon.com/efs/latest/ug/gs-step-two-create-efs-resources.html Make sure to update the security group to the one your instances are using, this has to be done to be able to mount. IP address of filesystem can be found under the networking tab. Mount the EFS share on the primary (ISP) node to a temporary location (i.e. /sapmnttmp) mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport <ipaddress-filesystem>:/ /sapmnttmp Add SAP_NFS_CHECK_IGNORE=1 to the /etc/default/LifeKeeper on both nodes At this point there are mounted entries for the EFS filesystem. Before this check is set LifeKeeper is checking the NFS mounts that have already been there, Since, we know that we have mounted an efs filesystem it is safe to enable this check to ignore the nfs warning due to this new fiesystem being currently unrecognizable. Use LifeKeeper lkbackup tool to create a backup copy of the LifeKeeper configuration a. /opt/LifeKeeper/bin/lkbackup -c -n Use LifeKeeper GUI or CLI to stop the SAP resources (perform an Out-of-Service) (Figure 2) a. /opt/LifeKeeper/bin/perform_action -t SAP-EDM_ASCS00 -a remove 6. Stop any remaining sapstartsrv, SAP ERS or saposcol and saphostexec processes on the standby and primary nodesa. lsof -c sap i. kill <pid> 7. Copy NFS data from the NFS export to the new EFS location a. cp -pra /exports/sapmnt /sapmnttmp b. cp -pra /exports/usr/sap/EDM/ASCS00 /sapmnttmp 8. Take hanfs resources osu a. /opt/LifeKeeper/bin/perform_action -t hanfs-/exports/sapmnt/EDM -a remove (Figure 3) b. /opt/LifeKeeper/bin/perform_action -t hanfs-/exports/usr/sap/EDM/ASCS00 -a remove (Figure 4) 9. Use umount to unmount the existing /sapmnt and other NFS local mounts. a. umount/exports/sapmnt/EDM b. umount /exports/usr/sap/EDM/ASCS00 10. Use LifeKeeper GUI or CLI to take associated datarep-sapmnt resources OSU a. */opt/LifeKeeper/bin/perform_action -t datarep-EDM -a remove* (Figure 5) */opt/LifeKeeper/bin/perform_action -t datarep-ASCS00 -a remove* (Figure 6) Add mount entries for EFS into /etc/fstab on node 1 a. Replace sap exports mounts with efs i. :/sapmnt/EDM /sapmnt/EDM nfs nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport 0 0 ii. :/ASCS00 /usr/sap/EDM/ASCS00 nfs nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport 0 0 Use the umount command to unmount the temporary /sapmnttmp mount point on node 1 a. umount /sapmnttmp Unmount the sap mounts a. umount -l /sapmnt/EDM b. umount -l /usr/sap/EDM/ASCS00 Use mount command to remount EFS file systems on node 1 a. mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport :/sapmnt/EDM /sapmnt/EDM b. mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport :/ASCS00 /usr/sap/EDM/ASCS00 Now you are ready to delete the dependency between the SAP resources and the old SIOS HANFS and NFS resources. Use GUI to delete the dependencies between SAP resources and HANFS and NFS resources a. Delete the nfs-/exports/dependencies from SAP-EDM_ASCS00 b. Delete the hanfs-/ child dependencies from ip-12.1.4.10 c. Delete the child dependency, ip-12.1.4.10, from nfs-/export/ filesystems d. Use LifeKeeper GUI or CLI to start the SAP resources (bring the SAP resource in-service) e. The new hierarchies will look similar to the following (Figure 7): f. Remove hanfs-/exports and nfs-/exports hierachies (Figure 8) Add mount entries for EFS into /etc/fstab on node 2. a. :/sapmnt/EDM /sapmnt/EDM nfs nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport 0 0 b. :/ASCS00 /usr/sap/EDM/ASCS00 nfs nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport 0 0 Use mount command to remount EFS file systems on node 2, refer to step 13 before adding entries. a. mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport 10.0.147.83:/sapmnt /sapmnt b. mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport 10.0.147.83:/ASCS00 /usr/sap/EDM/ASCS00 Verify SAP resources are started properly including IP and EC2 resources Use the LK GUI to perform a switchover to the target (or standby node) Done Conclusion Converting an NFS filesystem to EFS is a sure-fire way to provide much more protection to your data and take advantage of AWS cloud resources. It also simplifies the resource hierarchies making your filesystems easier to read and manage. The steps provided above will enable a much faster and smoother transition of your data stored in the cloud. Reproduced with permission from SIOS
September 28, 2022	What’s new in SIOS LifeKeeper for Linux v 9.6.2? What’s new in SIOS LifeKeeper for Linux v 9.6.2? SIOS LifeKeeper for Linux version 9.6.2 is now available! This new version supports v 8.6 of leading Linux distributions, supports Azure Shared Disk, and provides added protection from split brain scenarios that can occur when the network connection between cluster nodes fails. New in SIOS LifeKeeper Linux, Version 9.6.2 SIOS LifeKeeper Linux, version 9.6.2 takes advantage of the latest bug fixes, security updates, and application support critical to their infrastructures and adds support for Miracle Linux v 8.4 for the first time as well as support for the following operating system versions: Red Hat Enterprise Linux (RHEL)8.6 Oracle Linux 8.6 Rocky Linux 8.6 New Support for Azure Shared Disk LifeKeeper for Linux v 9.6.2 is now certified for use with Azure shared disk, enabling customers to build a Linux HA cluster in Azure that leverages the new Azure shared disk resource. Standby Node Write Protection LifeKeeper can now use the new Standby Node Health Check feature to lock the standby node against attempted writes to a protected shared storage device, protecting against data corruption that can result from loss of network connection between cluster nodes. LifeKeeper Load Balancer Health Check Application Recovery Kit (ARK) SIOS LifeKeeper for Linux comes with Application Recovery Kits (ARKs) that add application-specific intelligence, enabling automation of cluster configuration and orchestration of failover in compliance with application best practices. The latest version of SIOS LifeKeeper includes a new ARK that makes it easier for the user to install, find and use Load Balancer functionality in AWS EC2. Contact SIOS here for purchasing information. Reproduced with permission from SIOS
September 24, 2022	New Options for High Availability Clusters, SIOS Cements its Support for Microsoft Azure Shared Disk New Options for High Availability Clusters, SIOS Cements its Support for Microsoft Azure Shared Disk Microsoft introduced Azure Shared Disk in Q1 of 2022. Shared Disk allows you to attach a managed disk to more than one host. Effectively this means that Azure now has the equivalent of SAN storage, enabling Highly Available clusters to use shared disk in the cloud! A major advantage of using Azure Shared Disk with a SIOS Lifekeeper cluster hierarchy is that you will no longer be required to have either a storage quorum or witness node to avoid so called split-brain – which occurs when the communication between nodes is lost and several nodes are potentially changing data simultaneously. Fewer nodes means less cost and complexity. SIOS has introduced an Application Recovery Kit (ARK) for our LifeKeeper for Linux product; called LifeKeeper SCSI-3 Persistent Reservations (SCSI3) Recovery Kit that allows Azure Shared Disks to be used in conjunction with SCSI-3 reservations. This ARK guarantees that a shared disk is only writable from the node that currently holds the SCSI-3 reservations on that disk. When installing SIOS Lifekeeper, the installer will detect that it’s running in Microsoft Azure EC2 and automatically install the LifeKeeper SCSI-3 Persistent Reservations (SCSI3) Recovery Kit to enable support for Azure Shared Disk. Resource creation within Lifekeeper is straightforward and simple (Figure 1). Once locally mounted, the Azure Shared Disk is simply added into Lifekeeper as a file-system type resource. Lifekeeper will assign it an ID (Figure 2) and manage the SCSI-3 locking automatically. Figure 1] Creation of /sapinst within Lifekeeper. Figure 2] /sapinst created and extended to both cluster nodes. SCSI-3 reservations guarantee that Azure Shared Disk is only writable on the node that holds the reservations (Figure 3). In a scenario where cluster nodes lose communication with each other the standby server will come online, causing a potential split-brain situation. However, because of the SCSI-3 reservations only one node can access the disk at a time, which prevents an actual split-brain scenario. Only one system will hold the reservation and it will either become the new active node (in this case the other will reboot) or remain the active node. Nodes that do not hold the Azure Shared Disk reservation will simply end up with the resource in an “Standby State” state because they cannot acquire the reservation. Figure 3] Output from Lifekeeper logs when trying to mount a disk that is already reserved. Link to Microsoft’s definition of Azure Shared Disks https://docs.microsoft.com/en-us/azure/virtual-machines/disks-shared At present SIOS supports Locally-redundant Storage (LRS) and we’re working with Microsoft to test and support Zone-Redundant Storage (ZRS). Ideally we’d like to know when there is a ZRS failure so that we can fail-over the resource hierarchy to the most local node to the active storage. At present SIOS is expecting the Azure Shared Disk support to arrive in its next release of Lifekeeper 9.6.2 for Linux, Q3 2022. Reproduced with permission from SIOS