# Oracle for SAP NetWeaver on Amazon Deployment and Operations Guide for Linux *SAP specialists, Amazon Web Services* *December 2021* This guide is part of a content series that provides detailed information about hosting, configuring, and using SAP technologies in the Amazon Web Services Cloud. For more information, see [SAP on Amazon Technical Documentation](https://www.amazonaws.cn/sap/docs/). ## Overview The purpose of this guide is to provide an overview of how to implement and operate Oracle database for SAP NetWeaver applications on Amazon Elastic Compute Cloud ([Amazon EC2](https://www.amazonaws.cn/ec2/?ec2-whats-new.sort-by=item.additionalFields.postDateTime&ec2-whats-new.sort-order=desc)). It is for users who are responsible for planning, architecting, and deploying Oracle database for SAP NetWeaver applications on Amazon. You should have a good understanding of Amazon services, general network concepts, Oracle Enterprise Linux (OEL) OS, and Oracle database administration. This guide provides guidance to successfully launch and configure the resources required for Oracle database on Amazon. It doesn’t provide guidance on how to setup network and security components like Amazon Virtual Private Cloud ([Amazon VPC](https://www.amazonaws.cn/vpc/)), subnets, route tables, ACLs, NAT gateway, Amazon Identity and Access Management ([IAM](https://www.amazonaws.cn/iam/)) roles, and Amazon security groups. It focuses on how to configure and maintain the compute, storage, and OS components for the Oracle database on Linux on Amazon. It is not intended to replace the standard installation and administration guides from SAP or Oracle. # Prerequisites We recommend familiarizing yourself with these guides: + [SAP on Amazon Overview and Planning](https://docs.amazonaws.cn/sap/latest/general/sap-on-aws-overview.html) + [Getting Started with Architecting SAP on the Amazon Cloud](https://www.amazonaws.cn/blogs/awsforsap/getting-started-with-architecting-sap-on-the-aws-cloud/) + [Best practices for Amazon EC2](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/ec2-best-practices.html) + [Migrating Oracle Database Workloads to Oracle Linux on Amazon](https://d1.awsstatic.com/whitepapers/migrating-oracle-database-workloads-to-oracle-linux-on-aws.pdf) + [Determining the IOPS Needs for Oracle Database on Amazon](https://docs.amazonaws.cn/whitepapers/latest/determining-iops-needs-oracle-db-on-aws/determining-iops-needs-oracle-db-on-aws.html) + [SAP Note 2606828 - Oracle Database Roadmap for SAP NetWeaver](https://me.sap.com/notes/2606828) (SAP portal access required) ## Technical requirements Before you begin deploying Oracle database for SAP applications on Amazon, ensure that you meet the following requirements: + If necessary, request a service limit increase by creating a support ticket. This is to ensure that the Amazon services required for Oracle database deployment are not constrained by the default limit. For more information, see [Amazon service quotas](https://docs.amazonaws.cn/general/latest/gr/aws_service_limits.html). For example, you may have to increase the Amazon EC2 instance limit before your Oracle deployment. + You will need the following information for your existing resources while running the Amazon CLI commands to create Amazon EC2 and Amazon Elastic Block Store [(Amazon EBS)](https://www.amazonaws.cn/ebs/) resources. **Information** | | | | --- |--- | | **Information** | **Description** | | Amazon Region | Region where you want to deploy your Amazon resources. | | Availability Zone (AZ) | Availability Zone within your target Region where you want to deploy your resources. | | Amazon VPC id | Amazon VPC where you want to deploy your Amazon EC2 instances for SAP installation. | | VPS subnet id | Subnet where you want to deploy your Amazon EC2 instances. | | Linux AMI id | Amazon Machine Image (AMI) that will be used to launch your Amazon EC2 instances. You can find the latest Linux AMIs on [Amazon Marketplace](https://www.amazonaws.cn/marketplace). | | Key pair | Make sure that you have generated the key pair in your target Region and that you have access to the private key. | | Security group id | Name of the security group that you want to assign to your Amazon EC2 instances. | | Access key ID | Access key for your Amazon account that will be used with Amazon CLI tools. | | Secret access key | Secret key for your Amazon account that will be used with Amazon CLI tools. | + Create security groups and open ports to enable communication. For existing security groups, ensure that the required ports are open. For a list of ports, refer to [TCP/IP ports of all SAP products](https://help.sap.com/viewer/ports) and [Managing Oracle Database Port Numbers](https://docs.oracle.com/database/121/SSDBI/app_port.htm#SSDBI7924). + Ensure that you have installed and configured Amazon CLI with required credentials, if you plan to use it to launch instances. For more information, see [Installing the Amazon CLI](https://docs.amazonaws.cn/cli/latest/userguide/cli-chap-install.html). + If you plan to use the Amazon Management Console, ensure that you have the essential credentials and permissions to launch and configure Amazon services. For more information, see [Access management for Amazon resources](https://docs.amazonaws.cn/IAM/latest/UserGuide/access.html). + Ensure that you have the software files required for installation readily available. You can stage these in [Amazon S3](https://www.amazonaws.cn/s3/) or [Amazon Elastic File System](https://www.amazonaws.cn/efs/) (Amazon EFS). Amazon EFS can be easily shared on all of your installation hosts. For more information, see [Create your Amazon EFS file system](https://docs.amazonaws.cn/efs/latest/ug/gs-step-two-create-efs-resources.html). + Oracle for SAP on Amazon is supported on an OEL OS. For more information, see [SAP Note 1656099](https://me.sap.com/notes/1656099) and [SAP Note 2358420](https://me.sap.com/notes/2358420) (login required). If you are currently using a different OS, you can procure licenses and perform a migration. For more information, see [Migrating Oracle Database Workloads](https://d1.awsstatic.com/whitepapers/migrating-oracle-database-workloads-to-oracle-linux-on-aws.pdf). To use AMIs published by Oracle, see [Launch an Oracle Linux instance in Amazon](https://community.oracle.com/tech/apps-infra/discussion/4417739/launch-an-oracle-linux-instance-in-aws). # Planning Plan your SAP system landscape according to the SAP Master Guide for your version of SAP NetWeaver for Linux OS and Oracle database. + [Deployment options](deploy-options-orc-sap-nw-lx.md) + [Sizing](sizing-orc-sap-nw-lx.md) + [Amazon Machine Image (AMI)](ami-orc-sap-nw-lx.md) + [Security and compliance](sec-orc-sap-nw-lx.md) + [Storage for Oracle](storeorc-orc-sap-nw-lx.md) # Deployment options To install Oracle for SAP NetWeaver, you have four deployment options: ## Standalone deployment In standalone deployment (also known as single host installation), all components of the SAP NetWevaer, ABAP SAP Central Services (ASCS), and database Primary Application Server (PAS) run on one Amazon EC2 instance. One Amazon EC2 instance in a single Availability Zone in a single Region runs the Oracle database. This option can be optimal for non-production workloads. You can use [Amazon EC2 auto recovery](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/ec2-instance-recover.html) feature to protect your instance against infrastructure issues like loss of network connectivity or system power. However, this solution is not database state aware and does not protect your database against storage failure, OS issues, Availability Zone or Region failure. ![\[SAP on Oracle standalone deployment\]](http://docs.amazonaws.cn/en_us/sap/latest/sap-netweaver/images/fig1_std-dep-orc-sap-nw-lx.png) ## Distributed deployment In distributed deployment, every instance of SAP NetWeaver (ASCS/SCS, database, PAS, and optionally AAS) can run on a separate Amazon EC2 instance. This system also deploys Oracle database in a single Availability Zone. You can use [Amazon EC2 auto recovery](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/ec2-instance-recover.html) feature to protect your instance against infrastructure issues like loss of network connectivity or system power. ![\[SAP on Oracle distributed deployment\]](http://docs.amazonaws.cn/en_us/sap/latest/sap-netweaver/images/fig2_dis-dep-orc-sap-nw-lx.png) ## High availability deployment In high availability deployment, you deploy two Amazon EC2 instances across two Availability Zones within a Region, and the Oracle database with Oracle Data Guard or a third-party high availability solution. **Note** When using native Oracle with SAP and Amazon features, the design must be a subset of supported features, as described in [SAP Note 105047](https://me.sap.com/notes/105047) and [SAP Note 2358420](https://me.sap.com/notes/2358420). **Option 1: high availability with Oracle Data Guard** Oracle Data Guard is a feature of the Oracle database enterprise edition. It provides a set of tools to manage one or more Oracle standby databases for high availability and disaster recovery. To create an Oracle standby database, replicate the Oracle primary database to a secondary server by backup/restore or RMAN duplicate method. When the standby database is set up, any changes to the primary database are replicated on the standby database. This ensures that both the databases are in sync. The following table describes the replication methods associated with the Oracle Data Guard protection modes. **Oracle Data Guard protection modes** | | | | | --- |--- |--- | | **Protection mode** | **Replication** | **Behavior** | | Maximum performance | Asynchronous | Primary database is not affected by any delays in writing redo data to the standby database. | | Maximum availability | Synchronous | Commit occurs when all the redo data needed to recover transactions has been written to the online redo log and to at least one synchronized standby database. If Data Guard is not able to write to the standby database, the behavior will be similar to the maximum performance protection mode. | | Maximum protection | Synchronous | Changes must be written to both, the online redo log and to the standby database for every transaction. If Data Guard is unable to write the redo stream to at least one standby, it will shut down the primary database. | All Availability Zones within an Amazon Region are connected with high-bandwidth over fully redundant and dedicated metro fiber, providing high-throughput and low-latency networking between Availability Zones. For a high availability configuration, you can set up a primary and standby relationship between two Oracle databases with synchronous replication, running on Amazon EC2 instances in different Availability Zones within the same Region. The maximum protection mode can cause a shutdown of the primary database in case of a standby database failure. Unless you need to meet a compliance requirement, we recommend using the maximum availability option for high availability. ![\[SAP on Oracle deployment in multi-AZ with high availability\]](http://docs.amazonaws.cn/en_us/sap/latest/sap-netweaver/images/fig3_hasys-dep-orc-sap-nw-lx.png) You can use manual failover or switchover to the standby database by following the steps in the [Data Guard Broker Switchover and Failover Operations](https://docs.oracle.com/database/121/DGBKR/sofo.htm#DGBKR330). Alternatively, you can automate this process. For more information, see [Oracle Data Guard Fast-Start Failover](https://www.oracle.com/technical-resources/articles/smiley-fsfo.html). To reconnect the SAP applications after the failover is complete, refer to the Reconnect SAP instance to database section in the https://www.sap.com/documents/2016/12/a67bac51-9a7c-0010-82c7-eda71af511fa.html. **Option 2: high availability using third-party products** You can use third-party products to achieve Oracle database high availability in your SAP on Amazon environment. Here are two examples: + [Using SIOS to Protect your Critical Core on Amazon](https://www.amazonaws.cn/blogs/awsforsap/using-sios-to-protect-your-critical-core-on-aws/) + [High Availability Configuration in Amazon Cloud using InfoScale Enterprise](https://www.veritas.com/support/en_US/doc/ka6j000000009eOAAQ) *For a complete list of certified partners, see the [SAP wiki](https://wiki.scn.sap.com/wiki/display/SI/Certified+HA-Interface+Partners).* These products provide end-to-end high availability for SAP applications and databases. They also detect failures and perform automatic failovers, making them a good option for production environments with low recovery time objective. Using a virtual IP address makes the user or application redirection automatic in case of failover. For more information, see the vendor documentation. Both of the preceding mentioned third-party examples are using their own storage (Data Keeper for SIOS and Veritas Volume Replicator for Veritas) and not database native replication. In option 1, the database is replicated using the Oracle Data Guard. The Guard supports SIOS but is not controlled by the SIOS application recovery kits, that is, a database failover is handled by the Guard. The Guard also supports Veritas, you can replicate using either the Guard or the Veritas Volume Replicator. ## Disaster recovery deployment With disaster recovery deployment of your SAP systems on Amazon Cloud, you can achieve business continuity. Based on recovery time objective, recovery point objective, and cost, you can set up disaster recovery deployment with one of the following three scenarios: + backup and restore + pilot light + hot standby To setup disaster recovery across Amazon Regions, setup additional Amazon EC2 instances in a secondary Region for standby Oracle database. Also, configure Oracle Data Guard or a third-part solution for data replication across Amazon Regions. **Option 1:**disaster recovery using Oracle Data Guard Using Oracle Data Guard, you can set up pilot light or hot standby DR deployment in your Amazon Region. The maximum performance (asynchronous copy) option must be used in Data Guard. Hot standby Amazon EC2 instance is of the same size as your production Amazon EC2 instance. This makes it more efficient to switch over during a DR test or event. Alternatively, you can use a pilot light approach wherein a smaller size Amazon EC2 instance is running in the Amazon DR Region as the target of data replication. This Amazon EC2 instance should have enough resources to take over the load of data replication. This option costs less than hot standby. However, during a DR test or event, you have to perform an additional step of resizing the Amazon EC2 instance. Before switchover, you must resize the DR Amazon EC2 instance to the same size as production, so that it can take over the production workloads. This step increases the time required to switchover to DR. You must also factor in the latency of running a non-production environment in another Region. Pilot light option can run a non-production environment that is the same size as production in the DR Region. This ensures availability of Amazon EC2 instance in case of a DR event. ![\[Oracle DB instance deployment in multi-AZ with Oracle Data Guard\]](http://docs.amazonaws.cn/en_us/sap/latest/sap-netweaver/images/fig4_disrec-dep-orc-sap-nw-lx.1.png) **Option 2:**passive disaster recovery using backup and recovery This option uses Oracle database backup and recovery feature to set up your DR. You can store your database backups in Amazon Simple Storage Service (Amazon S3) and use the Amazon S3 Cross-region replication (CRR) to replicate your backup to your target Region. It enables automatic, asynchronous copying of objects across buckets in different Amazon Regions. You can install and configure Oracle database on an Amazon EC2 instance in your target DR Region and shut down the instance to save cost. You can then restart it and perform database restore and recovery as needed. Alternatively, you can use automation such as Amazon CloudFormation or Cloud Development Kit or third-party automation tools to launch an Amazon EC2 instance and install and configure SAP applications Oracle database when needed. Any automation must be created and tested in advance and we recommend performing frequent DR drills. This helps you save cost for Amazon EC2 instances and Amazon EBS volumes. Note that the time to recover your database is dependent on the size of database. Any log files that were not copied to the DR Regions are lost and cannot be used for recovery. This option typically has higher RTO and RPO as compared to other options that use data replication technologies. However, it offers lower TCO in comparison to other options. ![\[SAP on Oracle with disaster recovery using backup and restore\]](http://docs.amazonaws.cn/en_us/sap/latest/sap-netweaver/images/fig5_disrec-dep-orc-sap-nw-lx.2.png) *You can choose to deploy high availability and disaster recovery for the same production database instance.* **If you want to use Oracle Data Guard for HA and DR, see [Multiple Standby Databases Best Practices](https://www.oracle.com/cn/a/tech/docs/technical-resources/maa10gr2multiplestandbybp-1.pdf) **. # Sizing Sizing applies to three key areas - compute, network, and storage. ## Compute Amazon has certified multiple instance families with different sizes to run SAP workloads. For more details, see [Amazon EC2 Instance Types for SAP](https://www.amazonaws.cn/sap/instance-types/). To provision instances based on your requirements, you can use the [Right sizing](https://docs.amazonaws.cn/whitepapers/latest/cost-optimization-right-sizing/cost-optimization-right-sizing.html#introduction-section) process. This process can help you optimize costs. Although it is ideal to use the right sizing approach when you move your SAP workloads to Amazon Cloud, it is an [ongoing process](https://docs.amazonaws.cn/whitepapers/latest/cost-optimization-right-sizing/right-sizing-ongoing-process.html). We recommend you to use the latest generation of your selected instance family. For a greenfield (new) deployment of SAP workloads, you can use the [Quick Sizer tool](https://help.sap.com/viewer/22bbe89ef68b4d0e98d05f0d56a7f6c8/2020.000/en-US/067579ee1f7f4ffba00c4abd9bc6f832.html) to calculate the compute requirement in SAPS. This helps you to select the closest matching Amazon EC2 instance for a price that is most economical for you. Before completing your selection, ensure that the selected Amazon EC2 instance provides enough Amazon EBS and overall network throughput to meet your application requirements. For migrations, you can use any of the following data sources to decide the right size of your instance: + Source system utilization and workload patterns, such as EarlyWatch alert reports. + Source system specification: CPU, memory, storage size \$1 throughput \$1 IOPS, network. + Source system SAPS rating. For more details, see [Compute & storage](compstore-orc-sap-nw-lx.md). ## Network Network performance is often not explicitly stated as a requirement in SAP sizing. Amazon enables you to check the network performance of all [Amazon EC2 Instance Types](https://www.amazonaws.cn/ec2/instance-types/). Ensure that you have your network components setup to deploy resources related to your SAP workload. If you haven’t already setup network components like Amazon VPC, subnets, route tables etc., you can use the, [Amazon Quick Start Modular and Scalable VPC Architecture](https://www.amazonaws.cn/quickstart/architecture/vpc/) to most effectively deploy scalable Amazon VPC architecture in minutes. After setting up your Amazon VPC, you must set up Amazon EC2 instances within the Amazon VPC for your SAP workloads. You also must set up a secured network connection between the corporate data center and the Amazon VPC along with the appropriate route table configuration, if it isn’t already configured. ## Storage Deploying SAP workloads on Amazon required a minimum storage size and layout, based on your choice of OS/DB platform. For further details, refer to the relevant SAP documentation. You need to create Amazon EBS volumes that match these requirements. You must check that the storage required is enough to provide sufficient I/O performance. The new `gp3` volume is ideal for Oracle workloads that require smaller volume size. With `gp3`, the storage throughput and IOPS are decoupled from the size and can scale independently. The io2 volume is well-suited for I/O-intensive database workloads that require sustained IOPS performance or more than 16,000 IOPS. The `io2 Block Express` is another provisioned IOPS SSD volume for workloads that require sub-millisecond latency, sustained IOPS performance, and more than 64,000 IOPS or 1,000 MiB/s of throughput. For more details, see [Storage for Oracle](storeorc-orc-sap-nw-lx.md). # Amazon Machine Image (AMI) You can deploy your SAP Oracle workload on Oracle Enterprise Linux 6.4 or later. A base AMI is required to launch an Amazon EC2 instance. You can create your own AMIs or obtain an Oracle Linux AMI from Oracle. For using AMIs from Oracle, see [Launch an Oracle Linux instance in Amazon](https://community.oracle.com/tech/apps-infra/discussion/4417739/launch-an-oracle-linux-instance-in-aws). You can create your own Oracle Enterprise Linux image or use other images available at Amazon Marketplace. # Security and compliance The following are additional Amazon security resources to help you achieve the optimum level of security for your SAP NetWeaver environment on Amazon: + [Amazon Cloud Security](https://www.amazonaws.cn/security/) + [CIS Amazon Foundations Benchmark](https://docs.amazonaws.cn/securityhub/latest/userguide/cis-aws-foundations-benchmark.html) + [Amazon Well-Architected Framework](https://docs.amazonaws.cn/wellarchitected/latest/security-pillar/welcome.html) ## OS Hardening Check the following resources to strengthen the security of your workloads. You must have access to the SAP portal to view the SAP Notes. + Refer to [Security in Amazon EC2](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/ec2-security.html). + Use [Amazon Inspector](https://www.amazonaws.cn/inspector/). + [SAP Note 1635808](https://me.sap.com/notes/1635808) + [SAP Note 2069760](https://me.sap.com/notes/2069760) + [SAP Note 2936683](https://me.sap.com/notes/2936683) + [SAP Note 1565179](https://me.sap.com/notes/1565179) To follow the CIS Benchmarks, see [Securing Oracle Linux](https://www.cisecurity.org/benchmark/oracle_linux/). ## Encryption The important aspect of securing your workloads is encrypting your data, both at rest and in transit. For more details, refer to the following: + [Amazon EBS encryption](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/EBSEncryption.html) + [Data encryption in Amazon EFS](https://docs.amazonaws.cn/efs/latest/ug/encryption.html) + [Data encryption in Amazon S3](https://docs.amazonaws.cn/AmazonS3/latest/userguide/UsingEncryption.html) In addition to Amazon encryption features, you can also use Oracle Transparent Data Encryption, as described in [SAP Note 974876](https://me.sap.com/notes/974876). ## Security group A [security group](https://docs.amazonaws.cn/vpc/latest/userguide/VPC_SecurityGroups.html) acts as a virtual firewall for your instance to control inbound and outbound traffic. Security groups act at the instance level, not the subnet level. Customers often separate the SAP system into multiple subnets, with the database in a separate subnet to the application servers, and other components, such as a web dispatcher in another subnet, possibly with external access. If workloads are scaled horizontally, or high availability is necessary, you may choose to include multiple, functionally similar, Amazon EC2 instances in the same security group. In this case, you must add a rule to your security groups. If Linux is used, some configuration changes may be necessary in the security groups, route tables, and network ACLs. For more information, see [Security group rules for different use cases](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/security-group-rules-reference.html). ## Network ACL A [network access control list (ACL)](https://docs.amazonaws.cn/vpc/latest/userguide/vpc-network-acls.html) is an optional layer of security for your Amazon VPC that acts as a firewall for controlling traffic in and out of one or more subnets (they’re stateless firewalls at the subnet level). You may set up network ACLs with rules similar to your security groups in order to add an additional layer of security to your Amazon VPC. See [Amazon VPC Subnet Zoning Patterns for SAP on Amazon](https://www.amazonaws.cn/blogs/awsforsap/vpc-subnet-zoning-patterns-for-sap-on-aws/) to understand the network considerations for SAP workloads. ## API call logging Amazon CloudTrail is a web service that records Amazon API calls for your account and delivers log files to you. The recorded information includes the identity of the caller, time of the call, source IP address, request parameters, and response elements returned by the Amazon service. With CloudTrail, you can get a history of Amazon API calls for your account, including API calls made via Amazon Management Console, Amazon SDKs, command line tools, and higher-level Amazon services (such as, Amazon CloudFormation). The Amazon API call history produced by CloudTrail enables security analysis, resource change tracking, and compliance auditing. ## Notification on access You can use [Amazon SNS](https://www.amazonaws.cn/sns) or any third-party application to set up notifications on SSH login to your email address or mobile phone. # Storage for Oracle This section describes the key considerations for designing storage layout of Oracle for SAP NetWeaver on Amazon. Before defining the layout, we recommend familiarizing yourself with IOPS and throughput offered by [Amazon EBS volume types](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/ebs-volume-types.html) and learning to calculate the baseline and burstable IOPS and throughput for these volumes. Amazon EC2 instances also have IOPS and throughput limits. For more details, see [Amazon EBS-optimized instances](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/ebs-optimized.html). ## Amazon FSx for NetApp ONTAP FSx for ONTAP is certified for Oracle databases on SAP NetWeaver. For more information, see [SAP Note 1656250 - SAP on Amazon: Support prerequisites](https://me.sap.com/notes/1656250) (portal access required). ## File system The file system structure for SAP Oracle deployment may differ with the database version. Refer to the following SAP Notes for individual Oracle database versions: + [SAP Note 2660017](https://me.sap.com/notes/2660017) + [SAP Note 1915301](https://me.sap.com/notes/1915301) + [SAP Note 1524205](https://me.sap.com/notes/1524205) The directory structure for database installation requires several file systems. This section only focuses on the storage layout of the file systems mentioned in the following table. The other file systems (used for storing Oracle software binaries, trace, and log files) are critical for operations but do not have heavy performance requirements as compared to the following files. | | | | --- |--- | | **Description** | **File system** | | Database data files | / oracle// sapdata(1,2…​.n) | | Database online redo logs | / oracle// origlog(A,B…​) | | Database mirror redo logs | / oracle// mirrlog(A,B…​) | | Database offline redo logs | / oracle// oraarch | You can calculate the capacity requirements from your existing database for migrations or using the SAP Quick Sizer tool for new implementations. ## Calculate the IOPS The most efficient way to estimate the actual IOPS that is necessary for your database is to query the system tables over a period of time and find the peak IOPS usage of your existing database. To perform this task, measure IOPS over a period of time and select the highest value. You can access this information from the GV\$1SYSSTAT dynamic performance view, a special view in the Oracle database that provides performance information. The view is continuously updated while the database is open and in use. Oracle Enterprise Manager and Automatic Workload Repository reports access this view to gather data. Alternatively, you can use the native storage tools to calculate the IOPS requirements. If storage tools are not available, you can use a script. For more information, see [Determining the IOPS Needs for Oracle Database on Amazon](https://docs.amazonaws.cn/whitepapers/latest/determining-iops-needs-oracle-db-on-aws/determining-iops-needs-oracle-db-on-aws.html). ## Amazon EBS volume types Amazon has multiple options for database storage, based on your throughput and IOPS requirements. **Two options for general purpose SSD**: + `gp3` volumes deliver a consistent baseline rate of 3,000 IOPS and 125 MiB/s, included with the price of storage. You can provision additional IOPS (up to 16,000) and throughput (up to 1,000 MiB/s) for an additional cost. + `gp2` volumes deliver performance linked to the size of the volume. We recommend new customers to use `gp3` volumes. Existing `gp2` users can migrate to `gp3` easily with [Amazon EBS Elastic Volumes](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/ebs-modify-volume.html). It enables modification of volume types, IOPS or throughput of your existing Amazon EBS volumes without interrupting the Amazon EC2 instances. **Three options for provisioned IOPS SSD**: + `io1` is designed to deliver a consistent baseline performance of up to 50 IOPS/GB to a maximum of 64,000 IOPS, and provide up to 1,000 MiB/s of throughput per volume. + `io2` is designed to deliver a consistent baseline performance of up to 500 IOPS/GB to a maximum of 64,000 IOPS, and provide up to 1,000 MiB/s of throughput per volume. + `io2 Block Express` is designed for workloads that require sub-millisecond latency, sustained IOPS performance, more than 64,000 IOPS, and 1,000 MiB/s of throughput per volume. **Comparisons** *Choosing between general purpose and provisioned IOPS SSD* We recommend using `gp3` on Oracle for SAP on Amazon workloads. It provides a better option for price over performance. You can dynamically switch from one volume type to another, if needed. *Choosing between ` io1 ` and ` io2 ` * We recommend you to use `io2` for provisioned IOPS use case. It provides lower annual failure rate and higher configurable IOPS per GB. *Choosing between ` gp3 ` and ` io2 ` * `io2` provides lower annual failure rate and higher maximum IOPS per volume but costs more than `gp3`. You can decide to use either of the two based your requirements regarding failure rate, IOPS, and cost. *Choosing between ` io2 ` and ` io2 Block Express ` * `io2 Block Express` should be chosen over `io2` for workloads that require sub-millisecond latency and more than 64,000 IOPS and 1,000 MiB/s of throughput from a single volume. If `io2 Block Express` doesn’t support your Amazon EC2 instance and Amazon EBS volume, use `io2`. **Note** Check the [Amazon EBS volume types](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/ebs-volume-types.html) to ensure that your chosen volume supports the Amazon EC2 instance in use. ## Best practices Follow these best practices for maximizing your database performance and storage resilience: + Use [Amazon EBS-optimized instances](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/ebs-optimized.html) for database storage. They have a dedicated path between Amazon EC2 and Amazon EBS volumes. + To achieve higher IOPS and throughput, you can use Linux Volume Manager (LVM) to create Linux file systems with striping across multiple Amazon EBS volumes or Oracle [Automatic Storage Management](https://help.sap.com/doc/saphelp_nw73ehp1/7.31.19/en-US/f6/9d54b0698c446588f18c071d68ae9e/content.htm?no_cache=true). For Automatic Storage Management, you can use multiple Amazon EBS volumes for creating disk groups, as recommended in the SAP installation guide for Oracle database. + In case of backup to local file system, overall data throughput of the Amazon EBS volumes used to create the file system is crucial for backup performance.In Amazon, you can use throughput optimized (`st1`) type Amazon EBS volumes for database backups to local file system. For larger file systems, `st1` type volumes have higher maximum throughput per volume at a lower cost when compared with `gp3` or `io1/io2`. Other volume types can be considered if `st1` doesn’t meet your requirement. Ensure that the backup storage window can meet the required backup window available for database backups. + When running SAP NetWeaver on Oracle database, you are required to have the `/sapmnt/[SID]` directory mounted on the database server. We recommend that you use Amazon EFS to host the `/sapmnt` directory and mount this on all SAP servers using the NFS protocol. + Data and log files should be on separate volumes. + Origlog and mirrlog should be on separate volumes. + Copies of control files should be stored on file systems that are created on separate volumes. + Redo log files are written sequentially by the Oracle database instance Log Writer (LGWR) process. Log file systems must be designed to support such I/O activity. ## Example configuration You need to set up the Oracle database with the following requirements: + Data file system with 48,000 peak IOPS, 3,000 MiB/s throughput and 12 TB capacity + Each of the archive log, online and mirror redo log files with 3,800 peak IOPS and 25 GB capacity + Oracle based file system for all other directories under `/oracle` with 300 GB capacity The following is an example storage design to achieve the previously mentioned performance and capacity requirements. **Data file system with provisioned IOPS using `gp3` or `io2` and without LVM:** Create one Amazon EBS volume for each file system size and use provisioned IOPS and throughput, as per the individual file system requirements. For data volumes, higher size and IOPS can be assigned to application tablespace volumes as needed. Since size, type, and IOPS can be changed dynamically, you can adjust these parameters with changing requirements. This is a simpler approach and doesn’t require any volume striping using Linux LVM or similar technology. However, with this approach, you are still limited by the maximum size and IOPS supported by individual Amazon EBS volumes. ![\[File system layout without LVM striping\]](http://docs.amazonaws.cn/en_us/sap/latest/sap-netweaver/images/fig6_egconf-storeorc-orc-sap-nw-lx.1.png) **Data file system with provisioned IOPS using `gp3` or `io2` and with LVM:** Create a single data volume group using stripping and four Amazon EBS volumes of 3 TB/each. This provides 12 TB of file system capacity. Each data volume can be configured with 12,000 IOPS and 750 MiB/s throughput to provide combined IOPS of 48,000 and throughput of 3,000 MiB/s. Multiple `sapdata` logical volumes and file systems can be created under this volume group. You can also create multiple volume groups for data file systems alone. Creating volume groups increases the recovery time, in case one of the underlying Amazon EBS volumes becomes unusable. In this case, many data files residing on this volume group may be impacted as all `sapdata` file systems are stripped across all Amazon EBS volumes. The benefit of using this approach is that you don’t need to have the IOPS and throughput requirements of individual `sapdata` file systems. The requirements of the Oracle database data file system are sufficient. Also, `sapdata` shares the IOPS and throughput, leading to better utilization of baseline performance when using `gp3` volumes. **Online redo logs** Use 25 GB `gp3` Amazon EBS volumes with 3,800 provisioned IOPS. ![\[File system layout with LVM striping\]](http://docs.amazonaws.cn/en_us/sap/latest/sap-netweaver/images/fig7_egconf-storeorc-orc-sap-nw-lx.2.png) # Deployment + [Standalone deployment](standalone-dep-orc-sap-nw-lx.md) + [HA/DR deployment](ha-dr-dep-orc-sap-nw-lx.md) # Standalone deployment In this example, we set up a sample environment for installation. It includes a public subnet for RDP and SSH access via the internet. We use Amazon Launch Wizard for SAP in a single Availability Zone deployment to create the Amazon VPC, subnets, security groups, and IAM roles. You can refer to this example set up but should also follow your own network layout and comply with security standards, such as the following: + Using a Landing Zone solution like [Amazon Control Tower](https://www.amazonaws.cn/controltower/). + Working with a cloud team like Cloud Center of Excellence to use existing standards. ## Step 1: Prepare your Amazon account Check the Region where you want to deploy your Amazon resources: + You pick your region for deployment during the planning phase. + Display the Amazon Command Line Interface configuration data: ``` $ aws configure list ``` Ensure that the default region listed in the command output is the same as the target region where you want to deploy your Amazon resources and install SAP workloads. In this deployment, we provision an Amazon EC2 instance. **Note** In this section, the syntax used for the Amazon CLI and Linux commands is specific to the scope of this document. Each command supports many additional options. To learn more, use the `aws help` command. ## Step 2: Create a `JSON` file for Amazon EBS storage Create a JSON file containing the storage requirements for SAP Oracle database server volumes. The following is an example `JSON` file with two Amazon EBS volumes for swap and installation directories. You can add more volumes as per your storage design. ``` [ { "DeviceName": "/dev/sdh", "Ebs": { "VolumeSize": 32, "VolumeType": "gp3", "DeleteOnTermination": true } }, { "DeviceName": "/dev/sdg", "Ebs": { "VolumeSize": 50, "VolumeType": "gp3", "DeleteOnTermination": true } } ] ``` In the preceding example, the device name `/dev/shd` is for non-nitro based hypervisors. On Nitro-based instances, Amazon EBS volumes are presented as NVME block devices. You need to perform additional mapping when configuring these volumes. For more information, see [Operating system and storage configuration](https://docs.amazonaws.cn/sap/latest/sap-hana/operating-system-and-storage-configuration.html). ## Step 3: Launch the Amazon EC2 instance Launch the Amazon EC2 instance for the SAP Oracle database installation in your target region, using the information gathered in Step 1. You must create the required storage volumes and attach them to the Amazon EC2 instance for the SAP installation, based on the `JSON` file you created in the Amazon EBS storage (Step 2). ``` $ aws ec2 run-instances \ --image-id \ --count \ --instance-type \ --key-name= --security-group-ids \ --subnet-id \ --block-device-mappings file://C:\Users\.json \ --region ``` Use this command in a single line format, as shown in the following example. ``` aws ec2 run-instances --image-id ami-xxxxxxxxxxxxxxx --count 1 --instance-type m5.large --key-name=my_key --security-group-ids sg-xxxxxxxx --subnet-id subnet-xxxxxx --block-device-mappings file://C:\Users\.json ``` You can also launch Amazon EC2 instances using the Amazon Management Console. For more information, see [Launch an instance](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-launch-instance). ## Step 4: Prepare the Oracle Linux OS Before starting the installation, you need to perform Oracle Enterprise Linux specific prerequisite tasks. For more information, refer to SAP Notes [1635808](https://me.sap.com/notes/1635808), [2069760](https://me.sap.com/notes/2069760), and [2936683](https://me.sap.com/notes/2936683) (login required). ## Step 5: Prepare each Amazon EC2 instance for SAP Oracle installation Download the SAP installation media as per the SAP installation guide, for the version of SAP NetWeaver you want to install on your Amazon EBS volumes. Locate your installation guide on the [Guide Finder for SAP NetWeaver](https://help.sap.com/viewer/nwguidefinder). If you choose to install the SAP Oracle database with high availability deployment across two Availability Zones, repeat the preceding steps for Oracle database standby HA instance in the second Availability Zone. If you choose to install SAP Oracle database with high availability and disaster recovery deployment across two Amazon Regions, repeat the preceding steps in the second Amazon Region in which you want to run the Oracle database standby DR instance. ## Step 6: Installing SAP Oracle on Amazon EC2 instances You are now ready to install the SAP Oracle software on your Amazon EC2 instances. For more information, see the Oracle Database Software Installation section of your SAP NetWeaver installation guide. Locate your installation guide on the [Guide Finder for SAP NetWeaver](https://help.sap.com/viewer/nwguidefinder). Instructions are available for all supported Oracle database versions. # HA/DR deployment ## Installing SAP Oracle on Amazon EC2 instances and configuring HA/DR Create an additional Amazon EC2 instance and perform the installation in a secondary Availability Zone. The steps for creating a HA or DR instance in a secondary Availability Zone are the same as described in Standalone deployment. You can simplify this step by using the following methods. + If you have built any automation using Amazon CloudFormation or other tools to create the primary Amazon EC2 instance and install database software, you can use the same automation to build the HA instance. + You can create an [Amazon Machine Image](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/AMIs.html) of the primary Amazon EC2 instance and launch another instance in the secondary Availability Zone. + For cross-regional deployments, configure [Amazon VPC peering](https://docs.amazonaws.cn/vpc/latest/peering/what-is-vpc-peering.html) or [Transit Gateway](https://www.amazonaws.cn/transit-gateway/) to enable SAP Oracle asynchronous replication between the two Regions. ## SAP documentation For information about supported Oracle functions and Data Guard configuration options in the SAP environment, refer to the following SAP documentation. + [SAP Note: 105047 - Support for Oracle functions in the SAP environment](https://me.sap.com/notes/105047) + [SAP Note: 1552925 - Linux: High Availability Cluster Solutions](https://me.sap.com/notes/1552925) You must have SAP portal access for reading all SAP Notes. To perform a manual failover or switchover, see [HA/DR operations](hadrops-orc-sap-nw-lx.md). # Operations ## Tagging Amazon resources A tag is a label that you assign to an Amazon resource. Each tag consists of a key and an optional value, both defined by you. Adding tags to various Amazon resources will make managing SAP environments more efficient, and help you search for resources quickly. Many Amazon EC2 API calls can be used in conjunction with a special tag filter. For more information, see [Tagging Amazon resources](https://docs.amazonaws.cn/general/latest/gr/aws_tagging.html). The following are some examples of how you can use tags for your operational needs. + You can tag your Amazon EBS volumes to identify their environment and use the same tags to create backup policies. For instance, Environment=DEV/QAS/PRD. + You can use similar tags (DEV/QAS/PRD) for Amazon EC2 instances and use them for patching your OS or running scripts to stop/start applications or Amazon EC2 instances. ## Monitoring Amazon provides multiple native services to monitor and manage your SAP environment. [CloudWatch](https://www.amazonaws.cn/cloudwatch/) and [CloudTrail](https://www.amazonaws.cn/cloudtrail/) can be used to monitor your underlying infrastructure and APIs. CloudWatch provides ready-to-use KPIs for CPU, disk utilization, and enables you to create custom metrics for KPIs that you want to monitor. CloudTrail allows you to log the API calls made to your Amazon infrastructure components. ## Operating system maintenance In general, operating system maintenance across large estates of Amazon EC2 instances can be managed by using: + Tools specific to the operating system, like Oracle Enterprise Manager + Third-party products, such as those available on Amazon Marketplace. + Amazon Systems Manager *The following are some key operating system maintenance tasks* **Patching** You can follow SAP recommended patching process to update your landscape on Amazon. With [Amazon Systems Manager Patch Manager](https://docs.amazonaws.cn/systems-manager/latest/userguide/systems-manager-patch.html), you can roll out OS patches according to your corporate policies. It has multiple benefits: + Scheduling based on tags + Defining patch baselines + Auto-approving patches with lists of approved and rejected patches Amazon Systems Patch Manager integrates with IAM, CloudTrail, and CloudWatch Events to provide a secure patching experience that includes event notifications and the ability to audit usage. For details about the process, see [How Patch Manager operations work](https://docs.amazonaws.cn/systems-manager/latest/userguide/patch-manager-how-it-works.html). Third-party products are available on [Amazon Marketplace](https://www.amazonaws.cn/marketplace). **Maintenance Windows** [Amazon Systems Manager Maintenance Windows](https://docs.amazonaws.cn/systems-manager/latest/userguide/systems-manager-maintenance.html) lets you define a schedule to perform potentially disruptive actions on your instances, such as patching an operating system, updating drivers, installing software or patches. **Administrator access** For administrative purposes, you can access the backend of your SAP systems via SSH or Amazon Systems Manager Session Manager. ## Automation Amazon Systems Manager Automation simplifies common maintenance and deployment tasks of Amazon EC2 instances and other Amazon resources. For more information, see [Amazon Systems Manager Automation](https://docs.amazonaws.cn/systems-manager/latest/userguide/systems-manager-automation.html). **Automation using Infrastructure-as-Code with Amazon CloudFormation** We recommend following the principle of Infrastructure-as-Code (IaC) for automating and maintaining your workloads on Amazon. [Amazon CloudFormation](https://www.amazonaws.cn/cloudformation/) provides a common language for you to describe and provision all the infrastructure resources in your cloud environment in a repeatable and automated manner. ## Cost optimization We recommend cost optimization as an ongoing process. There are many Amazon services that help with budgeting, cost control and optimization. For more details, see [Cost Optimization Pillar - Amazon Well-Architected Framework](https://docs.amazonaws.cn/wellarchitected/latest/cost-optimization-pillar/welcome.html) # Compute & storage ## Compute Amazon EBS volumes are exposed as NVMe block devices on [Nitro-based instances](https://docs.amazonaws.cn/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances). When changing Amazon EC2 instance types from a previous generation to a Nitro generation, NVMe device IDs associated with the volume can change. To avoid mount errors during change of instance type or instance reboots, you need to create a label for your file systems and mount it by the label, *and not* the NVMe IDs. For more details, see [support article](https://www.amazonaws.cn/premiumsupport/knowledge-center/boot-error-linux-nitro-instance/). Aside from operating system maintenance, you should consider maintenance for your Amazon EC2 instances. It can be driven by using [Automation runbook](https://docs.amazonaws.cn/systems-manager/latest/userguide/automation-documents.html). The following are some examples. + Use ` Amazon-StopEC2InstanceWithApproval` to request one or more IAM users approve the instance stop action. After the approval is received, runbook stops the instance. + Use ` Amazon-StopEC2Instance` to automatically stop instances on a schedule, using CloudWatch Events or a Maintenance Window task. For example, you can configure an Automation workflow to stop instances every Friday evening and restart on Monday mornings. Note that this automation will only stop and start the Amazon EC2 instance. You must create additional document to gracefully stop and start SAP applications and database and then use the Amazon Systems Manager to run such automations. + Use ` Amazon-UpdateCloudFormationStackWithApproval` to update resources that were deployed using Amazon CloudFormation template. The update applies a new template. You can configure the Automation to request approval by one or more IAM users before the update begins. You can also use [Amazon Instance Scheduler](https://www.amazonaws.cn/solutions/implementations/instance-scheduler/) to configure custom start and stop schedules for Amazon EC2 and Amazon RDS instances. ## Storage The following are the storage services used across this guide. + Amazon EBS provides persistent storage for SAP applications and database. Amazon EBS volumes can be resized and even have the volume type changed without disrupting the applications. For more details, see [Amazon EBS Elastic Volumes](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/ebs-modify-volume.html). After modifying the Amazon EBS volume, you need to extend the file system to match the extended volume size. For more details, see [Extend a Windows file system after resizing a volume](https://docs.amazonaws.cn/AWSEC2/latest/WindowsGuide/recognize-expanded-volume-windows.html). + Amazon EFS does not require you to explicitly provision storage, you pay only for your usage. It is built to scale on demand, without disrupting applications, growing and shrinking automatically as you add and remove files. This ensures that your applications have the required storage. + Amazon S3 also does not require you to explicitly provision storage, you pay only for your usage. You can use Object lifecycle management to set rules that define when objects are transitioned or archived to colder storage (Amazon S3 IA or S3 Glacier) and when they expire. For more information, see [Managing your storage lifecycle](https://docs.amazonaws.cn/AmazonS3/latest/userguide/object-lifecycle-mgmt.html). # Backup & restore ## Snapshots and AMIs A common approach for backing up your SAP NetWeaver application servers is using snapshots and AMIs. The SAP application data is stored on Amazon EBS volumes attached to the SAP NetWeaver application servers. You can backup the data on these volumes to Amazon S3 by taking point-in-time snapshots. Snapshots are incremental backups of Amazon EBS volumes, which means that only the blocks on the device that have changed after your most recent snapshot are saved. For more information, see [Create Amazon EBS snapshots](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html). An Amazon Machine Image (AMI) provides the information required to launch an instance along with a block device mapping of all Amazon EBS volumes attached to it. Amazon EC2 powers down the instance before creating the AMI to ensure that everything on the instance is stopped and in a consistent state during the creation process. If you’re confident that your instance is in a consistent state appropriate for AMI creation, you can check the *No Reboot* option. You can use [Amazon Backup](https://www.amazonaws.cn/backup) to centrally configure backup policies and monitor backup activity for these snapshots. Once you have completed the SAP installation and post installation steps, create an image of the instance. \$1 ``` aws ec2 create-image --instance-id i-1234567890abcdef0 --name "My server" --description "An AMI for my server" ``` Amazon provides a very simple and quick way to copy an SAP system. You can use the Amazon Console Home or the Amazon CLI to create a new AMI of an existing SAP system. You can then launch exact copies of the original system from the new AMI. For more details, see [Amazon Machine Images (AMI)](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/AMIs.html). ## Backup to Amazon S3 You can perform traditional file-based backup to Amazon S3 from your Amazon EBS volumes. One way to take backup is to use Amazon CLI and initiate it by using Amazon Systems Manager `Run` command, so that you can centrally manage the backups. ## Backup with third-party products There are many third-party products for Amazon services, including a number that have been certified by SAP. Go to [SAP Partner Services and Solutions Directory](http://aws-sap-partners.s3-website-us-east-1.amazonaws.com/), select **ISV Solutions** in *Service/Solution Type*, then **Backup and Recovery** in *Software Solution*. ## Amazon EFS backup Using Amazon Backup, you can centrally configure backup policies and monitor backup activity for Amazon resources, including Amazon EFS file systems. Alternatively, you can perform a file-level backup of your Amazon EFS file system to Amazon S3. You can do this by running a file-level copy to Amazon S3 from any Amazon EC2 instance running in the same region. This can be automated and scheduled using [Amazon Systems Manager Run Command](https://docs.amazonaws.cn/systems-manager/latest/userguide/execute-remote-commands.html) in combination with CloudWatch Events. ## Backup and restore for Oracle database You must to regularly backup your operating system and database to recover them in case of any failure. Amazon Cloud provides various services and tools that you can use to backup your Oracle database. **Storage snapshots** You can backup your Amazon EBS volumes to Amazon S3 by taking point-in-time snapshots. Snapshots are incremental backups, which means that only blocks on the device that have changed after your most recent snapshot are saved. Snapshots of Amazon EBS volumes can be created for backup of Oracle database file systems like Oracle home and stage directories. For complete Oracle database file backups using snapshots, you can use the Storage Snapshots Optimization feature by Oracle, supported from version 12c. For more details, see [Making Backups with Third-Party Snapshot Technologies](https://docs.oracle.com/database/121/BRADV/osbackup.htm#BRADV90019). Amazon customers can use this feature in combination with [Amazon EBS snapshots](https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/EBSSnapshots.html) to perform Oracle database backups. Using snapshot backups may reduce the backup window as compared to the full database backup approach. To set up snapshot-based based database backup, you can use sample scripts and steps published in the blog [Improving Oracle backup and recovery performance with Amazon EBS multi-volume crash-consistent snapshots](https://www.amazonaws.cn/blogs/database/improving-oracle-backup-and-recovery-performance-with-amazon-ebs-multi-volume-crash-consistent-snapshots/). **Oracle database backups** Any one of the following methods can be used for Oracle database backup. + Oracle database native tools (BRTOOLS) can be used to take backups on local storage. Once the backup is complete on local storage, it can be moved to Amazon S3 bucket via scripts. + Oracle Secure Backup Cloud Module to backup your database directly to Amazon S3 using RMAN. For setup, see [Oracle Database Backup To Cloud: Amazon Simple Storage Service (S3)](https://www.oracle.com/technetwork/database/features/availability/twp-oracledbcloudbackup-130129.pdf). For licence requirements, see [Oracle Secure Backup Licensing Information](https://docs.oracle.com/cd/E55822_01/OBLIC/E21478-04.pdf). + You can backup your Amazon EBS volumes to Amazon S3 by taking point-in-time snapshots. For more information, see the preceding Storage snapshots section. + There are many third-party tools from partner like Commvault, NetBackup, etc. that use the SAP backint interface and have Oracle database agents, with the capability to backup the database directly to Amazon S3. To configure and tune backups for your Oracle database, see [SAP on Oracle – Backup and Recovery](https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=448466928) and [Database Backup and Recovery User’s Guide - Tuning RMAN Performance](https://docs.oracle.com/database/121/BRADV/rcmtunin.htm#BRADV011). # HA/DR operations ## Oracle Data Guard You can use manual failover or switchover to the standby database using steps described in the [Switchover and Failover Operations](https://docs.oracle.com/en/database/oracle/oracle-database/19/dgbkr/using-data-guard-broker-to-manage-switchovers-failovers.html#GUID-44E7A982-7CD4-4A51-B00E-62C0698C5CD6). You can also automate this process by following the steps in [Oracle Data Guard Fast-Start Failover](https://www.oracle.com/technetwork/articles/smiley-fsfo-084973.html). When using this feature with the observer node, you must place the observer node in the third Availability Zone. Ensure that you have the license to use the fast-start failover, it may not be included with the Data Guard. You can also use supported third-party products that provide automatic failover operation with the Data Guard. To reconnect the SAP applications post-failover, see the *Reconnect SAP instance to database* section-premises in https://www.sap.com/documents/2016/12/a67bac51-9a7c-0010-82c7-eda71af511fa.html. ![\[Data Guard Broker switch over\]](http://docs.amazonaws.cn/en_us/sap/latest/sap-netweaver/images/fig8_odg-hadrops-orc-sap-nw-lx.png) ## Perform a DNS change In case of manual failover, you may install SAP application servers using a virtual hostname and perform a DNS change to direct the SAP application servers to the new primary database server. For a DNS resolution in Amazon, you can use any of the following options. + [Amazon Route 53](https://docs.amazonaws.cn/Route53/latest/DeveloperGuide/dns-configuring.html) enables you to create a private hosted zone for your environment and an A record for the virtual hostname used for Oracle database. Initially, this A record is mapped to the IP address of the primary Oracle database instance. + You can maintain your own DNS server on-premise or on your Amazon EC2 instances. You can create an A record there for your virtual hostname used for Oracle database. Initially, this A record is mapped to the IP address of the primary Oracle database instance. + With the [Amazon Directory Service](https://www.amazonaws.cn/directoryservice/), you can create an A record for the virtual hostname used for Oracle database. With any of the previously mentioned options, you can change the A record to a private IP address of the primary database instance in case of a failover. This DNS change can also be automated using Amazon services and scripts. # Resources SAP on Amazon customers have the flexibility to deploy SAP Oracle database on the scalable, on-demand Amazon EC2 platform in a highly available manner. They don’t have to invest in costly capital expenditures for the underlying infrastructure. By combining the Amazon platform flexibility and SAP installation techniques, our customers greatly improve the availability of their deployments. For more details, see [SAP on Amazon Case Studies](https://www.amazonaws.cn/sap/case-studies/). ## Support Amazon offers two levels of support. [Amazon Business Support](https://www.amazonaws.cn/premiumsupport/plans/business/) provides resources and technical support for customers running SAP workloads on Amazon. [Amazon Enterprise Support](https://www.amazonaws.cn/premiumsupport/plans/enterprise/) offers support to customers running mission critical SAP production workloads on Amazon. # Document revisions | Date | Change | | --- | --- | | December 2021 | Initial publication |