Introduction

This paper provides best practices for operating SAP HANA systems that have been deployed on Amazon Web Services (AWS).

Administration

This section provides guidance on common administrative tasks required to operate an SAP HANA system, including information about starting, stopping, and cloning systems.

1- Starting and Stopping EC2 Instances Running SAP HANA Hosts

• You can stop one or multiple SAP HANA hosts.
• Before stopping the EC2 instance of an SAP HANA host, first stop SAP HANA on that instance.
• You also have the option of using the EC2 Scheduler to schedule starts and stops of your EC2 instances.

2- Tagging SAP Resources on AWS

• Tagging your SAP resources on AWS can significantly simplify identification, security, manageability, and billing of those resources.
• You can tag your resources using the AWS Management Console or by using the create-tags functionality of the AWS Command Line Interface (AWS CLI).
• After you have tagged your resources, you can then apply specific security restrictions to them, for example, access control, based on the tag values.

3- Monitoring
There are various AWS, SAP, and third-party solutions that you can leverage for monitoring your SAP workloads. Here are some of the core AWS monitoring services:

• Amazon CloudWatch - CloudWatch is a monitoring service for AWS resources. It’s critical for SAP workloads where it’s used to collect resource utilization logs and create alarms to automatically react to changes in AWS resources.
• AWS CloudTrail - CloudTrail keeps track of all API calls made within your AWS account. It captures key metrics about the API calls and can be useful for automating trail creation for your SAP resources.
• Configuring CloudWatch detailed monitoring for SAP resources is mandatory for getting AWS and SAP support.

4- Automation

• AWS offers multiple options for programmatically scripting your resources to operate or scale them in a predictable and repeatable manner.
• You can leverage AWS CloudFormation to automate and operate SAP systems on AWS.

5- Patching
There are two ways for you to patch your SAP HANA database with alternatives for minimizing cost and/or downtime.

• Patch an existing server - This method may be most appropriate if you have a well-defined patching process and are satisfied with your current downtime and costs. With this method you must use the correct OS update process and tools for your Linux distribution.
• Provision and patch a new server - This method may be most appropriate if you are looking for higher degrees of automation to enable these goals and are comfortable with the trade¬offs. This method is more complex and has a many more options to fit your requirements. Certain options are not exclusive and can be used together.

Backup and Recovery

This section provides an overview of the AWS services used in the backup and recovery of SAP HANA systems.

1- Creating an Image of an SAP HANA System

• You can use the AWS Management Console or the command line to create your own AMI based on an existing instance.46 For more information, see the AWS documentation.
• You can use an AMI of your SAP HANA instance for the following purposes: o To create a full offline system backup. o To move a HANA system from one Region to another. o To clone an SAP HANA system.

Tip: The SAP HANA system should be in a consistent state before you create an AMI. To do this, stop the SAP HANA instance before creating the AMI.

2- AWS Services and Components for Backup Solutions
AWS provides a number of services and options for storage and backup, including Amazon Simple Storage Service (Amazon S3), AWS Identity and Access Management (IAM), and Amazon Glacier.

2-1 Amazon S3

• Amazon S3 is the center of any SAP backup and recovery solution on AWS.
• See the Amazon S3 documentation for detailed instructions on how to create and configure an S3 bucket to store your SAP HANA backup files. AWS IAM
• With IAM, you can securely control access to AWS services and resources for your users.
• You can create and manage AWS users and groups and use permissions to grant user access to AWS resources.
• You can create roles in IAM and manage permissions to control which operations can be performed by the entity, or AWS service, that assumes the role.
• You can also define which entity is allowed to assume the role.

2-2 Amazon Glacier

• Amazon Glacier is an extremely low-cost service that provides secure and durable storage for data archiving and backup.
• Amazon Glacier is optimized for data that is infrequently accessed and provides multiple options like expedited, standard, and bulk methods for data retrieval.
• You can use lifecycle policies, as explained in the Amazon S3 Developer Guide, to push SAP HANA backups to Amazon Glacier for long-term archiving.

3- Backup Destination

• The primary difference between backing up SAP systems on AWS compared with traditional on-premises infrastructure is the backup destination.
• Tape is the typical backup destination used with on-premises infrastructure.
• On AWS, backups are stored in Amazon S3.
• Amazon S3 has many benefits over tape, including the ability to automatically store backups “offsite” from the source system, since data in Amazon S3 is replicated across multiple facilities within the AWS Region.
• SAP HANA systems provisioned with a set of EBS volumes to be used as an initial local backup destination. HANA backups are first stored on these local EBS volumes and then copied to Amazon S3 for long-term storage.
• Some third-party backup tools like Commvault, NetBackup, and TSM are integrated with Amazon S3 capabilities and can be used to trigger and save SAP HANA backups directly into Amazon S3 without needing to store the backups on EBS volumes first.

4- Scheduling and Executing Backups Remotely

• The Amazon EC2 Systems Manager Run Command, along with Amazon CloudWatch Events, can be leveraged to schedule backups for your HANA SAP system remotely with the need to log in to the EC2 instances.
• You can also leverage cron or any other instance-level scheduling mechanism To schedule remote backups, here are the high-level steps:
• Install and configure the Systems Manager agent on the EC2 instance. For detailed installation steps, please see Working with SSM Agent.
• Provide SSM access to the EC2 instance role that is assigned to the SAP HANA instance. For detailed information on how to assign SSM access to a role, please see What is AWS Systems Manager?.
• Create an SAP HANA backup script.
• At this point you can test an one-time backup by executing an ssm command directly:
• Using CloudWatch Events, you can schedule backups remotely at any desired frequency.

5- Restoring SAP HANA Backups and Snapshots

5-1 Restoring SAP Backups
To restore your SAP HANA database from a backup, perform the following steps:

1. If the backup files are not already available in the /backup file system but are in Amazon S3, restore the files from Amazon S3 by using the aws s3 cp command.
2. Recover the SAP HANA database by using the Recovery Wizard as outlined in the SAP HANA Administration Guide. Specify File as the Destination Type and enter the correct Backup Prefix.
3. When the recovery is complete, you can resume normal operations and clean up backup files from the /backup//* directories.

5-2 Restoring EBS/AMI Snapshots
To restore EBS snapshots, perform the following steps:

1. Create a new volume from the snapshot:
2. Attach the newly created volume to your EC2 host:
3. Mount the logical volume associated with SAP HANA data on the host.
4. Start your SAP HANA instance.

5-3 Restoring AMI Snapshots

• You can restore your HANA SAP AMI snapshots through the AWS Management Console.
• On the EC2 Dashboard, select AMIs in the left-hand navigation. Choose the AMI that you want to restore, expand Actions, and select Launch.

Networking

• SAP HANA components communicate over the following logical network zones: • Client zone • Internal zone • Storage zone
• Separating network zones for SAP HANA is considered both an AWS and an SAP best practice to isolate the traffic required for each communication channel.
• Amazon EBS-optimized instances can also be used for further isolation for storage I/O.

1- EBS-Optimized Instances

• Many newer Amazon EC2 instance types such as the X1 use an optimized configuration stack and provide additional, dedicated capacity for Amazon EBS I/O. These are called EBS-optimized instances.
• This optimization provides the best performance for your EBS volumes by minimizing contention between Amazon EBS I/O and other traffic from your instance.

2- Elastic Network Interfaces (ENIs)

• An ENI is a virtual network interface that you can attach to an EC2 instance in an Amazon Virtual Private Cloud (Amazon VPC).
• With ENIs, you can create different logical networks by specifying multiple private IP addresses for your instances.

3- Security Groups

• A security group acts as a virtual firewall that controls the traffic for one or more instances.
• When you launch an instance, you associate one or more security groups with the instance.
• You can add and modify rules to each security group that allow traffic to or from its associated instances.

4- Configuration Steps for Logical Network Separation
To configure your logical network for SAP HANA, follow these steps:

1. Create new security groups to allow for isolation of client, internal communication, and, if applicable, SAP HSR network traffic
2. Use Secure Shell (SSH) to connect to your EC2 instance at the OS level.
3. Create new ENIs from the AWS Management Console or through the AWS CLI.
4. Attach the ENIs you created to your EC2 instance where SAP HANA is installed.
5. Create virtual host names and map them to the IP addresses associated with client, internal, and replication network interfaces.
6. For scale-out deployments, configure SAP HANA inter-service communication to let SAP HANA communicate over the internal network.
7. Configure SAP HANA hostname resolution to let SAP HANA communicate over the replication network for SAP HSR.

SAP Support Access

• In some situations, it may be necessary to allow an SAP support engineer to access your SAP HANA systems on AWS.
• A few steps are required to configure proper connectivity to SAP. These steps differ depending on whether you want to use an existing remote network connection to SAP or you are setting up a new connection directly with SAP from systems on AWS.

1- Support Channel Setup with SAProuter on AWS
When setting up a direct support connection to SAP from AWS, consider the following steps:

1. For the SAProuter instance, create and configure a specific SAProuter security group, which only allows the required inbound and outbound access to the SAP support network. This should be limited to a specific IP address that SAP gives you to connect to, along with TCP port 3299.
2. Launch the instance that the SAProuter software will be installed on into a public subnet of the Amazon VPC and assign it an Elastic IP address (EIP).
3. Install the SAProuter software and create a saprouttab file that allows access from SAP to your SAP HANA system on AWS.
4. Set up the connection with SAP. For your internet connection, use Secure Network Communication (SNC).
5. Modify the existing SAP HANA security groups to trust the new SAProuter security group you have created.

Tip: For added security, Shut down the EC2 instance that hosts the SAProuter service when it is not needed for support purposes.

2- Support Channel Setup with SAProuter On-Premises

• In many cases, you may already have a support connection configured between your data center and SAP. This can easily be extended to support SAP systems on AWS.
• You can extend this connectivity as follows:
• Ensure that the proper saprouttab entries exist to allow access from SAP to resources in the Amazon VPC.
• Modify the SAP HANA security groups to allow access from the on premises SAProuter IP address.
• Ensure that the proper firewall ports are open on your gateway to allow traffic to pass over TCP port 3299.

Security

• Here are additional AWS security resources to help you achieve the level of security you require for your SAP HANA environment on AWS:

1- OS Hardening

• You may want to lock down the OS configuration further, for example, to avoid providing a DB administrator with root credentials when logging into an instance.

2- Disabling HANA Services

• HANA services such as HANA XS are optional and should be deactivated if they are not needed.

3- API Call Logging

• AWS CloudTrail is a web service that records AWS API calls for your account and delivers log files to you.
• The recorded information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters, and the response elements returned by the AWS service.

4- Notifications on Access

• You can use Amazon Simple Notification Service (Amazon SNS) or third-party applications to set up notifications on SSH login to your email address or mobile phone.

High Availability and Disaster Recovery

For details and best practices for high availability and disaster recovery of SAP HANA systems running on AWS, see High Availability and Disaster Recovery Options for SAP HANA on AWS.

Conclusion

This whitepaper discusses best practices for the operation of SAP HANA systems on the AWS cloud. The best practices provided in this paper will help you efficiently manage and achieve maximum benefits from running your SAP HANA systems on the AWS Cloud.

The Original AWS White Paper: SAP HANA on AWS Operations Overview Guide.