PAS-C01 · Question #70
A company runs its SAP Business Suite on SAP HANA systems on AWS. The company's production SAP ERP Central Component (SAP ECC) system uses an x1e.32xlarge (memory optimized) Amazon EC2 instance and is
The correct answer is C. Launch a new EC2 High Memory instance. Install and configure SAP HANA on the new instance. u- (High Memory) instances are bare-metal instances that cannot be resized in-place from x1e instances - they belong to a different instance family and require launching new instances. The fastest approach with minimum downtime is to launch a new u- instance, install and configur
Question
A company runs its SAP Business Suite on SAP HANA systems on AWS. The company's production SAP ERP Central Component (SAP ECC) system uses an x1e.32xlarge (memory optimized) Amazon EC2 instance and is 3.5 TB in size. Because of expected future growth, the company needs to resize the production system to use a u-* EC2 High Memory instance. The company must resize the system as quickly as possible and must minimize downtime during the resize activities. Which solution will meet these requirements?
Options
- AResize the instance by using the AWS Management Console or the AWS CLI.
- BCreate an AMI of the source system Launch a new EC2 High Memory instance that is based on
- CLaunch a new EC2 High Memory instance. Install and configure SAP HANA on the new instance
- DLaunch a new EC2 High Memory instance. Install and configure SAP HANA on the new instance
How the community answered
(27 responses)- A4% (1)
- B11% (3)
- C78% (21)
- D7% (2)
Explanation
u-* (High Memory) instances are bare-metal instances that cannot be resized in-place from x1e instances - they belong to a different instance family and require launching new instances. The fastest approach with minimum downtime is to launch a new u-* instance, install and configure SAP HANA on it, and then use SAP HANA System Replication to continuously replicate data from the source system to the target. System Replication keeps the secondary in sync, enabling a near-zero-downtime cutover (seconds to minutes). Simple in-console resize (A) is impossible for cross-family changes involving u-* instances. Creating an AMI and launching from it (B) requires a full backup/restore of 3.5 TB and extended downtime. Option D likely involves a traditional backup/restore method, which for a 3.5 TB database would require significantly more downtime than System Replication-based cutover.
Topics
Community Discussion
No community discussion yet for this question.