SIOS SANless clusters - Page 38 of 192 - SIOS SANless clusters High-availability Machine Learning monitoring

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
September 20, 2022	Webinar: Disaster Recovery for SQL Server on Public Clouds Webinar: Disaster Recovery for SQL Server on Public Clouds Register for the On-Demand Webinar Running your SQL Server instances to any of the major public cloud platforms requires solid strategies for disaster recovery and high availability. Learn how to plan for disaster recovery and high availability and how to decide what’s best for your environment. Register for the On-Demand Webinar Reproduced with permission from SIOS
September 17, 2022	Webinar: Understanding the Availability Chain and its Impact on SQL Server Webinar: Understanding the Availability Chain and its Impact on SQL Server Register for the On-Demand Webinar There are many factors to consider when evaluating the efficacy of your SQL Server availability. In this webinar, SIOS Technical Evangelist and Microsoft Cloud and Datacenter MVP, Dave Bermingham, outlines the key components that make access to your application possible. He discusses the chain of availability and how to determine your risk of downtime and failure for each link – and how to protect your most critical business applications. Register for the On-Demand Webinar Reproduced with permission from SIOS