AWS sap documentation change
Summary
Reorganized content structure, removed 'Disaster recovery mock exercise guidance' section, updated failure scenario table formatting, fixed markdown links, and adjusted HA/DR testing guidance ordering.
Security assessment
Changes primarily involve structural reorganization and documentation improvements. While 'malicious activities' are mentioned in disaster recovery scenarios, this is part of existing content restructuring rather than addressing a new security vulnerability or adding security features. No concrete evidence of security vulnerability remediation or new security guidance introduction.
Diff
diff --git a/sap/latest/sap-hana/hana-ops-ha-dr-testing.md b/sap/latest/sap-hana/hana-ops-ha-dr-testing.md index 8fa610f7d..1c4355c59 100644 --- a//sap/latest/sap-hana/hana-ops-ha-dr-testing.md +++ b//sap/latest/sap-hana/hana-ops-ha-dr-testing.md @@ -5 +5 @@ -Failure scenarios for backup and recommendationsTesting guidance and considerationsDisaster recovery mock exercise guidance +Failure scenarios for backup and recommendationsTesting guidance and considerations @@ -17,2 +16,0 @@ This section covers failure scenarios for backup, testing guidance and considera - * Disaster recovery mock exercise guidance - @@ -30,3 +28,4 @@ The following table provides an overview of different failures scenarios for the -Availability Zone/network failure | Low | ~o (uncommitted transactions) | Time to detect failure and failover (automated) | Region | Core service failure -Low | o | Dependent on failure | Region | **Disaster recovery** | Corruption/accidental deletion/malicious activities/faulty code deployment -Low | Last consistent restore point before failure | Time to detect failure and failover (manual) | Cross-Region | Region failure | Very low +**High availability** | Availability Zone/network failure | Low | ~o (uncommitted transactions) | Time to detect failure and failover (automated) | Region +**High availability** | Core service failure | Low | o | Dependent on failure | Region +**Disaster recovery** | Corruption/accidental deletion/malicious activities/faulty code deployment | Low | Last consistent restore point before failure | Time to detect failure and failover (manual) | Cross-Region +**Disaster recovery** | Region failure | Very low | Replication delay | Time to detect failure and make a decision to invoke disaster recovery and takeover | Cross-Region @@ -36 +35 @@ For SAP HANA systems without high availability implementation, the core critical - * Use Amazon EC2 automatic recovery or host recovery to bring the SAP HANA system up on new host. For more information, see {https---docs-aws-amazon-com-sap-latest-sap-hana-hana-ops-ha-dr-html-ec2-recovery-hana-hadr}[Amazon EC2 recovery options]. + * Use Amazon EC2 automatic recovery or host recovery to bring the SAP HANA system up on new host. For more information, see [Amazon EC2 recovery options](https://docs.aws.amazon.com/sap/latest/sap-hana/hana-ops-ha-dr.html#ec2-recovery-hana-hadr). @@ -42 +40,0 @@ For SAP HANA systems without high availability implementation, the core critical -You can resize or upgrade your Amazon EC2 instance to support a greater number of CPU cores or instance memory size. For more information, see [Change the instance type](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-resize.html). @@ -45,0 +44 @@ You can resize or upgrade your Amazon EC2 instance to support a greater number o +You can resize or upgrade your Amazon EC2 instance to support a greater number of CPU cores or instance memory size. For more information, see [Change the instance type](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-resize.html). @@ -81 +79,0 @@ High availability cluster solutions constantly monitor the configured resources, -Large SAP HANA databases take more time to start and stop. If they are hosted on AWS bare-metal instances, the time taken to reboot can be longer. As these factors can impact the cluster behavior, the cluster timeout values have to be tuned accordingly. @@ -83 +80,0 @@ Large SAP HANA databases take more time to start and stop. If they are hosted on - * An SAP Application can have many single point of failures, and SAP HANA database is one of them. The availability of an SAP application is dependent on all single point of failures being resilient to failure situations. Include single point of failures in overall testing. For example, validate an AWS Availability Zone failure where both SAP Application/NetWeaver stack component (ASCS) and SAP HANA database are deployed in the same Availability Zone. The cluster solution must be able to failover pre-configured resources and the SAP application must be restored on the target Availability Zone. @@ -85 +81,0 @@ Large SAP HANA databases take more time to start and stop. If they are hosted on - * Test cases that comprise of planned and unplanned downtimes should be tested as a minimum validation. You can also include scenarios where single point of failures was observed in the past. For instance, a year-end consolidation jobs testing the instance memory limits, leading to database crashes. @@ -87 +83 @@ Large SAP HANA databases take more time to start and stop. If they are hosted on -For SAP HANA high availability deployment with pacemaker cluster on **SLES** on AWS test cases, see [Testing the cluster](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-hana-on-aws-testing-the-cluster-sles.html). +Large SAP HANA databases take more time to start and stop. If they are hosted on AWS bare-metal instances, the time taken to reboot can be longer. As these factors can impact the cluster behavior, the cluster timeout values have to be tuned accordingly. @@ -89 +85 @@ For SAP HANA high availability deployment with pacemaker cluster on **SLES** on -For SAP HANA high availability deployment with pacemaker cluster on **RHEL** on AWS test cases, see [Testing the cluster](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-hana-on-aws-testing-the-cluster-1-rhel.html). + * An SAP Application can have many single point of failures, and SAP HANA database is one of them. The availability of an SAP application is dependent on all single point of failures being resilient to failure situations. Include single point of failures in overall testing. For example, validate an AWS Availability Zone failure where both SAP Application/NetWeaver stack component (ASCS) and SAP HANA database are deployed in the same Availability Zone. The cluster solution must be able to failover pre-configured resources and the SAP application must be restored on the target Availability Zone. @@ -91 +87 @@ For SAP HANA high availability deployment with pacemaker cluster on **RHEL** on - * Pacemaker cluster solution require virtual IP address configuration for client connections. With virtual IP addresses, the actual hardware where the SAP workloads run remain transparent to client applications. There is a seamless failover of connections in the event of a failure. You must verify that all the intended SAP or third-party interfaces are able to connect to the target SAP application post failover. + * Test cases that comprise of planned and unplanned downtimes should be tested as a minimum validation. You can also include scenarios where single point of failures was observed in the past. For instance, a year-end consolidation jobs testing the instance memory limits, leading to database crashes. @@ -93 +88,0 @@ For SAP HANA high availability deployment with pacemaker cluster on **RHEL** on -You can start by preparing a client connections or interfaces list that includes all critical connections to the target SAP system. Identify the modifications required in your connection configuration to point to a virtual IP address or load balancing mechanism. During testing, each connection must be validated for connectivity, time taken to detect new connection, and loss of locks set by the application, before the cluster performs a failover. For more information, see {https---docs-aws-amazon-com-sap-latest-sap-hana-hana-ops-ha-dr-hsr-html-hsr-client-redirect}[Client redirect options]. @@ -95 +89,0 @@ You can start by preparing a client connections or interfaces list that includes - * If you have high availability and disaster recovery on your SAP HANA workloads, you must take additional steps to perform cluster validations. A pacemaker cluster only has visibility into its cluster members(primary and secondary). The cluster software does not control disaster recovery operations (tier-3/tertiary). @@ -97 +90,0 @@ You can start by preparing a client connections or interfaces list that includes -When a failover is triggered in a multi-tier SAP HANA system replication setup and the secondary database takes over the role of primary, the replication continues on the tertiary system. However, once the fault with the original primary system is rectified and the system is made available again, manual intervention are be required to complete the reverse replication requirements from the new primary SAP HANA database to the original primary. These manual steps are needed for SAP HANA databases that do not support (lower than SAP HANA 2.0) multi-target replication. For more information, see {https---docs-aws-amazon-com-sap-latest-sap-hana-hana-ops-ha-dr-hsr-html-hsr-multi-target}[SAP HANA multi-target replication]. @@ -99 +92 @@ When a failover is triggered in a multi-tier SAP HANA system replication setup a -After performing failback to the original primary, some manual steps have to be performed to re-enable the replication on the tertiary site. It is very important to validate the flow of these steps and the time taken for services to startup during each testing scenario before releasing the systems for productive usage. +For SAP HANA high availability deployment with pacemaker cluster on **SLES** on AWS test cases, see [Testing the cluster](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-hana-pacemaker-sles-testing.html). @@ -101 +94 @@ After performing failback to the original primary, some manual steps have to be - * SAP HANA system replication can be configured in an Active/Active configuration. This configuration utilizes the secondary hardware for read-only purpose. The supported products include SAP S/4 HANA, BW on HANA, and BW4/HANA. +For SAP HANA high availability deployment with pacemaker cluster on **RHEL** on AWS test cases, see [Testing the cluster](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-hana-pacemaker-rhel-testing.html). @@ -103 +96 @@ After performing failback to the original primary, some manual steps have to be -SLES and RHEL support an Active/Active SAP HANA system replication setup using pacemaker cluster. Depending on the operating system version, additional steps may be required to set up an Active/Active configuration using the pacemaker cluster. + * Pacemaker cluster solution require virtual IP address configuration for client connections. With virtual IP addresses, the actual hardware where the SAP workloads run remain transparent to client applications. There is a seamless failover of connections in the event of a failure. You must verify that all the intended SAP or third-party interfaces are able to connect to the target SAP application post failover. @@ -105 +97,0 @@ SLES and RHEL support an Active/Active SAP HANA system replication setup using p -The testing scenarios will vary to incorporate additional validation of failover and failback behavior of read-only virtual IP and the respective client connections being able to connect post failover and failback. @@ -108,0 +101 @@ The testing scenarios will vary to incorporate additional validation of failover +You can start by preparing a client connections or interfaces list that includes all critical connections to the target SAP system. Identify the modifications required in your connection configuration to point to a virtual IP address or load balancing mechanism. During testing, each connection must be validated for connectivity, time taken to detect new connection, and loss of locks set by the application, before the cluster performs a failover. For more information, see [Client redirect options](https://docs.aws.amazon.com/sap/latest/sap-hana/hana-ops-ha-dr-hsr.html#hsr-client-redirect). @@ -110 +103 @@ The testing scenarios will vary to incorporate additional validation of failover -## Disaster recovery mock exercise guidance + * If you have high availability and disaster recovery on your SAP HANA workloads, you must take additional steps to perform cluster validations. A pacemaker cluster only has visibility into its cluster members(primary and secondary). The cluster software does not control disaster recovery operations (tier-3/tertiary). @@ -112 +104,0 @@ The testing scenarios will vary to incorporate additional validation of failover -Your disaster recovery setup must be validated by performing a manual mock exercise. With a mock disaster recovery exercise, you can verify the recovery point and time objectives and the steps for invoking a disaster recovery. You can also identify ownership and tasks for various teams involved, and make a detailed plan of routing client connections as well as establishing connections to hub systems and third-party connections. @@ -114 +105,0 @@ Your disaster recovery setup must be validated by performing a manual mock exerc -Invoking a disaster recovery system requires detailed planning and support from other teams, such as a dedicated network operations team. It also needs agreement on the performance requirements once these systems are started in the disaster recovery Region. @@ -116 +106,0 @@ Invoking a disaster recovery system requires detailed planning and support from -Disaster recovery mock exercise also involves validating cross-Region replication of Amazon EFS, Amazon S3, and other AWS services that are part of the overall disaster recovery plan. Any sync jobs scheduled for cross-Region replication of these services (for instance, Amazon EFS) must be adapted or paused. They tend to overwrite any new content created on the disaster recovery site. You might also have to perform tasks on the networking layer for SAP and third-party systems to inter-communicate in the disaster recovery Region, and for client connectivity. Post-recovery tasks, such as applying for new licenses must also be performed. End-user communication requirements along with guidance on how to connect to SAP HANA systems on a disaster recovery site must also be considered. @@ -118 +108 @@ Disaster recovery mock exercise also involves validating cross-Region replicatio -An in-depth disaster recovery mock exercise also involves testing the steps to resume SAP HANA systems on the original site (primary Region or Availability Zone). This task must be planned carefully to avoid any data loss. The steps for replication vary on a two-tier and multi-tier SAP HANA system replication setup. It requires an async replication mode. +When a failover is triggered in a multi-tier SAP HANA system replication setup and the secondary database takes over the role of primary, the replication continues on the tertiary system. However, once the fault with the original primary system is rectified and the system is made available again, manual intervention are be required to complete the reverse replication requirements from the new primary SAP HANA database to the original primary. These manual steps are needed for SAP HANA databases that do not support (lower than SAP HANA 2.0) multi-target replication. For more information, see [SAP HANA multi-target replication](https://docs.aws.amazon.com/sap/latest/sap-hana/hana-ops-ha-dr-hsr.html#hsr-multi-target). @@ -120 +110 @@ An in-depth disaster recovery mock exercise also involves testing the steps to r -Functional and technical teams must verify the SAP HANA systems for potential data loss before invoking a disaster recovery and failing back to the original site. With a mock disaster recovery exercise, you can also prepare standard operating procedures for business continuity, saving time during a real disaster and minimizing possible data loss. +After performing failback to the original primary, some manual steps have to be performed to re-enable the replication on the tertiary site. It is very important to validate the flow of these steps and the time taken for services to startup during each testing scenario before releasing the systems for productive usage.