Achieve zero RPO for your SAP ASE (Sybase) databases with Amazon FSx for NetApp ONTAP

Today, users working with SAP ASE databases are navigating the path of rehosting and refactoring to AWS. The catalyst for considering this transition is heightened due to several factors, such as the end of mainstream support announcements by SAP. Although the advantages and benefits of refactoring to open-source databases are compelling, it may require a significant time investment, making it a medium to longer-term strategy. In contrast, the rehosting strategy offers an interim solution to quickly realize the benefits and agility of the AWS cloud by leveraging existing compute and storage solutions.

Given the mission-critical nature of SAP ASE workloads, users are seeking assurance that their systems can withstand unforeseen disruptions, minimize downtime, and swiftly restore operations to normalcy. As part of the rehosting strategy, SAP ASE users place an emphasis on the need for field-proven storage solutions. These storage solutions are essential pillars to ensuring data integrity and providing the ability to conduct rapid recovery of their critical business applications in failure scenarios.

Amazon FSx for NetApp ONTAP provides fully managed, shared storage in the AWS Cloud with the popular data access and management capabilities of ONTAP. This post serves as a guide for achieving a Zero Recovery Point Objective (RPO) solution utilizing FSx for ONTAP to safeguard against data loss in scenarios where there are failures of your SAP ASE implementations. We walk you through the step-by-step process of setting up SAP ASE databases, such as Linux block storage configuration and client-based multi-pathing. We also demonstrate the zero-RPO capability by simulating a failure that requires a failover. FSx for ONTAP is supported for SAP ASE version 16.0.

FSx for ONTAP presents a powerful capability to achieve the necessary RPO with notable benefits. This managed solution provides a robust foundation for data storage and management, enabling organizations to establish a zero RPO by minimizing data loss during disruptions. The combination of FSx for ONTAP’s advanced data replication features and its integration with SAP ASE workloads ensures reliable and seamless data synchronization. This results include improved business continuity, reduced downtime, and enhanced regulatory compliance.

In this post, we cover the solution overview and the required implementation steps.

Solution overview

In this example (Figure 1), we show how to leverage FSx for ONTAP with SAP ASE (Sybase) Database Server running on Amazon Elastic Compute Cloud (Amazon EC2) to achieve the required zero RPO solution. FSx for ONTAP is a fully managed service that provides highly reliable, scalable, high-performing, and feature-rich file storage built on NetApp’s popular ONTAP file system.

You can use FSx for ONTAP as the primary storage solution for SAP ASE (Sybase) data, log, sapdiag, saptmp, and backup volumes. In this scenario, we present these volumes as iSCSI LUNs (based on SAP recommendations in OSS Note 409367 — requires SAP Portal Access) to the SAP ASE (Sybase) instance running on Amazon EC2.

This architecture includes an SAP ASE (Sybase) Primary server in one Availability Zone (AZ) and another standby server in a different AZ. The FSx for ONTAP file system deployment type is Multi-AZ (multiple availability zones) and replicates the data synchronously to the standby AZ. This means that as transactions are committed to SAP ASE, they are synchronously replicated to the Standby AZ before the acknowledgment is sent back to the clients.

Figure 1 – SAP ASE Primary and Disaster Recovery (DR) with FSx for ONTAP Multi AZ file system

Prerequisites

The following prerequisites are required to implement this solution:

• This post assumes that the reader understands SAP ASE (Sybase) Databases, Linux configuration and mounting of iSCSI LUNs, and has familiarity with FSx for ONTAP. To create a similar deployment in your environment, you must have an AWS account with access to Amazon EC2 and FSx for ONTAP, and meet the ONTAP Prerequisites for attaching a Linux client.
• You must install the SAP ASE as per the instructions provided by SAP. You can select the relevant guide from the SAP Documentation – Sybase Installation and upgrade guides.
• For a complete list of supported EC2 instances for SAP ASE, see SAP Note 1656099 – SAP Applications on Amazon EC2: Supported DB/OS and Amazon EC2 products (requires SAP portal access).
• Access to both the SAP ASE (Sybase) Database Servers and FSx for ONTAP file systems via AWS Command Line Interface (AWS CLI) in both Primary and Standby environments.
• Intermediate SAP ASE skills as an SAP ASE (Sybase) Administrator.
• FSx for ONTAP (Multi-AZ) deployed in the same subnets (preferred and standby) as the SAP ASE servers, one LUN per volume, with suitable storage requirement (SSD Performance tier) and throughput capacity (minimum 512MBps).
• iSCSI multipathing configured on the SAP ASE Servers as per FSx for ONTAP iSCSI guide.

Walkthrough

The following is a detailed walkthrough of the steps required to perform the end-to-end process of setting up the SAP ASE (Sybase) Database environment in the preceding architecture diagram (Figure 1), along with steps to test failover. By following this process you can achieve the zero RPO solution required for regulatory compliance.

At a high level, the process is as follows:

1. Configure and present the FSx for ONTAP storage devices.
2. Configure the SAP ASE (Sybase) Database Servers storage.
3. Install and configure the SAP ASE database environment.
4. Demonstrate a live failure scenario and the steps to be followed after a failure to resume database operations (recovery of SAP ASE (Sybase) database services without loss of data, in other words zero RPO).

Figure 2 – SAP ASE primary server storage mount point set up

Follow these steps to implement the preceding process.

1. Configure and present the FSx for ONTAP storage devices.

A. In the FSx for ONTAP file system CLI Console of FSx API, create one volume per mount point required (directory layout as per the preceding diagram or as per your design). Follow this guide to create the volumes. Set the volume snapshot-policy option to none, and the Capacity pool tiering policy to none.FSX ONTAP Guide – Configuring Volumes

B. Create the individual LUN per mount point (each volume has one LUN), with the ostype option set to linux.FSX ONTAP Guide – Create iSCSI LUN

C. Create an initiator group in ONTAP to manage access to the LUNs. Require the IQN of both Primary and Standby server, which can be gathered from the contents of /etc/iscsi/initiatorname.iscsi). Save the IQN addresses of both the Primary and Standby Servers, as these are used during the failover process.FSX ONTAP Guide – Mount the iSCSI LUNS (Linux)

2. Configure the SAP ASE (Sybase) Database Servers storage.

A. In the Linux console, input the following tuning parameters into the /etc/iscsi/iscsid.conf file, as per NetApp Technical report for Sybase ASE.

iscsid.startup = /etc/rc.d/init.d/iscsid force-start
node.leading_login = No
node.session.timeo.replacement_timeout = 120
node.conn[0].timeo.login_timeout = 15
node.conn[0].timeo.logout_timeout = 15
node.conn[0].timeo.noop_out_interval = 5
node.conn[0].timeo.noop_out_timeout = 5
node.session.err_timeo.abort_timeout = 15
node.session.err_timeo.lu_reset_timeout = 30
node.session.err_timeo.tgt_reset_timeout = 30
node.session.initial_login_retry_max = 8
node.session.cmds_max = 128
node.session.queue_depth = 32
node.session.xmit_thread_priority = -20
node.session.iscsi.InitialR2T = No
node.session.iscsi.ImmediateData = Yes
node.session.iscsi.FirstBurstLength = 262144
node.session.iscsi.MaxBurstLength = 16776192
node.conn[0].iscsi.MaxRecvDataSegmentLength = 262144
node.conn[0].iscsi.MaxXmitDataSegmentLength = 0
discovery.sendtargets.iscsi.MaxRecvDataSegmentLength = 32768
node.conn[0].iscsi.HeaderDigest = None
node.session.iscsi.FastAbort = Yes node.startup = automatic
node.session.nr_sessions = 8

B. As root user, create the following mount point directories on your SAP ASE (Sybase) servers. Then change ownership (chown) and group (chgrp) of the directories to be the Sybase user/group.

mkdir -p /sybasebin
mkdir -p /sybasebackup
mkdir -p /sapdata_1
mkdir -p /saplog
mkdir -p /saptmp
mkdir -p /sapdiag

C. These mount points and their purposes are described as follows:

WARNING: you MUST make sure MPIO is setup correctly in order for Sybase to fail over, for the scenario of file system failure/unavailability.

D. Install and configure the iSCSI client on the Primary and Standby SAP ASE Server covering both client daemon and also multipathing software as per the install and configure iSCSI guide for FSx for ONTAP. On the Primary SAP ASE Server, discover the LUNs and partition them (in this post we are using ext4 as the default file system), then mount the LUNs to the directory mount points created earlier, following the mount an iSCSI LUN on your Linux client guide.Make sure that you have the mount commands in the /etc/fstab configuration file to make sure of persistence at the time of reboot.

E. On the Standby SAP ASE server, make sure that the LUNs are visible, but do not mount them. This can be achieved by checking the dmesg output to see if new disk messages appear.

3. Install and configure the SAP ASE database environment.
In this section, we install and configure SAP ASE to use the allocated FSx for ONTAP storage. For this post, we assume installation of a new custom SAP ASE. For details on installation and configuration of SAP ASE itself, refer to the SAP ASE installation guide for your version and platform (for example, for version 16, see the version specific guide).

1. After mounting the storage allocated from FSx for ONTAP, creating additional symlinks for database devices is highly recommended. These offer an enhanced level of flexibility for managing operations such as renaming devices or relocation. For example, symlinks were created within the $SYBASE/devices directory, specifically directed to the exported mount points, that is, $SYBASE/devices/data01 -> /sapdata_1 etc.
2. Following the setup of file system, the SAP ASE binaries and associated files were installed and configured using the utility setup.bin via a response file. In the response file, USER_INSTALL_DIR was specified as /sybasebin.
3. The response file also specified the configuration of an SAP ASE server named, server1. Additionally, the system devices and databases were specified using the previously created symlinks.
4. Evaluate your storage options for temporary devices. Note that the Multi-AZ option involves synchronous writing to another AZ, but this isn’t required for tempdb since it gets recreated after a database restart. Consider the cost and performance objectives to select your storage (this is for temporary storage only). Options include Amazon Elastic Block Store (Amazon EBS) volumes (gp2, gp3,io1, io2, FSx for ONTAP, etc.) and also NVMe instance based store. For the purposes of this post, we opted for a single-AZ deployment of FSx for ONTAP.
5. Create a user database named “mydb“. This database hosts the transactions for this demonstration. The data and log devices for this user database are set up in the designated storage mount points via the symlinks: /sapdata_1 and /saplog. The following Figure 3 illustrates the setup.

Figure 3 – SAP ASE database and devices

F. Provision a second instance in another AZ being the Standby instance, and configure it to “see” the same FSx for ONTAP storage. This storage must only be mounted during a failover. It is critical that the storage is only mounted by one instance at any given time. It is crucial to perform checks to make sure that an instance with the right role can only have the capability to mount the filesystems. Automating this process is a potential enhancement. However, for the purpose of this post, the verification is conducted manually.

G. The following are some extra configuration considerations for the Standby host:

1. 1. 1. The mount points should be recreated exactly as per the Primary instance.
      2. Make sure the unix user and group, owning the directories (commonly referred as “sybase user”) on the primary and standby instance are the same name and ID. If the IDs are different, then use the unix command usermod and groupmod to change and match them. For example, usermod -u 1782 sybase.
      3. If the “sybase user” home directory is not created in /sybasebin, then it must be synchronized as the changes are not visible to both instances.

H. For application connectivity further considerations are required both on the client and server. The recommended solution is a DNS CNAME record for resolution. This provides both flexibility and control to coordinate the change during the failover. It is a seamless process during failover, as no changes are required for both client and servers during a failover. For this post, Amazon Route 53 was used with the following configuration steps.

1. 1. 1. A private hosted zone “example.com” was created in the VPC of the instances.
      2. A CNAME record created with the record name being mysybaseinstance.example.com with a TTL (Time To Live) of 30 seconds.
      3. After this mysybaseinstance.example.com resolves to the current primary. During the failover this record requires updating prior to starting the Sybase instance.

4. Demonstrate a live failure scenario and the steps to be followed after a failure to resume database operations (recovery of SAP ASE (Sybase) database services without loss of data, in other words zero RPO). At this point, we have the storage allocated and the SAP ASE (Sybase) database up and running. In this section, we simulate a fault and illustrate failing over the database without data loss (zero RPO).

A simple Python application continuously writes transactions into a table called mydb..zeroRPOtest. zeroRPOtest table has two columns: the ID column with identity datatype, and the second column being a bigdatetime, storing the time in milliseconds when the row is written.

A. The following output shows that as the Python application writes transactions to zeroRPOtest, it emits the last committed transaction ID and time:

Figure 4 – Application committing database transactions

B. Although the Python application is writing the transactions, a failure scenario was simulated by abruptly shutting down the Primary instance. The last transaction ID and date and time is shown as 38 and was committed 2023-10-11 06:35:03.453000.

Figure 5 – Simulated database failure

C. At this stage the primary has failed while writing transactions. As part of service restoration, a decision is made to promote the Standby’s role to primary. Currently, the storage is available to be mounted, but not yet mounted on the Standby server. The following steps demonstrate the manual failover process (these steps can be automated and orchestrated to reduce the time for service resumption).

a.(optional) In the case of a planned failover, we recommend shutting down the database and unmounting the directories on the primary. This option may not be possible during a failure scenario. The following commands are run on the primary:

umount /sybasebin
umount /sybasebackup
umount /sapdata_1
umount /saplog
umount /sapdiag
umount /saptmp

b. All further commands are run on the Standby server, as the Primary is assumed to be unavailable in a failure scenario.

c. Remove the Primary server IQN from the FSx for ONTAP iGROUP (to prevent a possible split-brain scenario):ssh fsxadmin@<MGMT endpoint> igroup remove -igroup igroup_name -initiator <Primary server IQN address> -force

d. Mount the LUNs to the SAP ASE directories.

mount -t ext4 /dev/mapper/3600a09806c5742304f5d564d35797472 /sybasebin
mount -t ext4 /dev/mapper/3600a09806c5742304f5d564d3579746a1 /sybasebackup
mount -t ext4 /dev/mapper/3600a09806c5742304f5d564d3579746b1 /sapdata_1
mount -t ext4 /dev/mapper/3600a09806c5742304f5d564d3579746c1 /saplog
mount -t ext4 /dev/mapper/3600a09806c5742304f5d564d3579746e1 /sapdiag
mount -t ext4 /dev/mapper/3600a09806c5742304f5d564d3579746d1 /saptmp

e. Check that the directories are present (in other words, running df -h).

f. Update DNS CNAME record to the newly promoted primary instance.

g. Restart the SAP ASE, make sure the database has recovered with no errors in the database logs, and connect to the database to check that all databases are online.

D. Now check the database to verify that the last transaction record written, as reported by the Python application, is present in the secondary.

Figure 6 – Zero data loss: All transactions available post-database failover

E. The preceding output confirms that transaction ID 38 and all other preceding transaction IDs are present in the standby database. This confirms that we have demonstrated that FSx for ONTAP provides SAP ASE database with a performant, and highly available zero RPO storage solution.

Cleaning up

To remove all the components created by this solution and avoid future charges, complete the following steps:

1. Sign in to the AWS Management Console.
2. On the Amazon EC2 console, choose Instances.
3. Select the Sybase ASE (Sybase) instances and choose Terminate.
4. In the FSx for ONTAP CLI console, delete all LUNs and volumes.
5. In the Console, navigate to the FSx console.
6. Select the SVMs created and delete, then select the File System and delete.

Conclusion

In this post, we demonstrated how to achieve zero RPO for SAP ASE (Sybase) databases with Amazon FSx for NetApp ONTAP file systems. By leveraging FSx for ONTAP, you can meet your regulatory high availability/disaster recovery (HA/DR) requirements.

This post showed you the example configuration of the SAP ASE (Sybase) databases with Amazon Elastic Compute Cloud (Amazon EC2) and the required configurations to achieve the preceding results, along with fault simulation overview.

For further information about FSx for ONTAP, visit the product page. To learn more about SAP ASE (Sybase) with Amazon FSx, visit the SAP on AWS technical documentation page.