Research, development and sale of oral health products
SAP ECC 6 (ERP) migration to AWS
Products and services
SAP ECC, AWS
“Thanks to 3Hold’s experience with SAP systems, we have been able to migrate our SAP on premise to AWS in a totally transparent way for users.”
It is important to have technicians who have assimilated the advanced SAP concepts included in a correct design of the SAP application map in AWS.
For example, you must decide when to use the security measures included in the AWS platform itself and when to use those of the application itself.
The SAP infrastructure has different types of instances and the solution that guarantees high availability is different for each of them:
Regarding the database servers for SAP environments the AWS platform’s fault tolerance does not provide the necessary guarantees by default to ensure that no data is lost. In AWS, it is not possible to use multicast on your network, thus disabling a cluster-based solution. In this sense, it is the cloud architect who is responsible for establishing the high availability and/or Disaster Recovery strategy for the database.
In our case, we opted for the configuration of two database servers, one in each AWS availability area, within the same region, configured with the SAP HADR solution Synchronous Data Replication with the SAP Replication Server option (Hot Standby), which guarantees and automates the balancing of a secondary server of the DB in case of failure of the main server. This technology allows to balance automatically in both directions between the database servers.
SAP Central Services instances
Together with the database, the SAP Central Service Instances (ASCS and SCS) are the critical points of the SAP technology platform. A failure in these servers directly affects the system availability.
The central service instances were deployed in an Auto Scaling group across multiple Availability Zones, with a maximum and minimum of one active instance. In this way, the AWS platform itself will monitor that there is only one active instance in any of the availability zones included in the group.
To control this possible movement of instances across availability zones, the AWS Route 53 (DNS) service is used, resolving by name the active instance at each moment.
Additional Application Servers (Dialog instances)
If the availability of the database and the central services instances is guaranteed with the solutions explained above, the next point to be resolved was the availability of the SAP application servers. To solve this, we relied on SAP logon groups that guarantee that, if there is at least one active application server, the user will be able to access the system.
This last requirement was achieved thanks to the use of ScaleSAP, a 3Hold Technologies’ product that is capable of automatically scaling the dialog instances according to the demand, always having at least one application server at disposal.
ScaleSAP was configured in an Auto Scaling group across multiple Availability Zones with a minimum of 2, and a maximum of 4 instances. In this way, the platform was given the necessary scalability, without the risk of high increasing costs.
ScaleSAP also requires a central application server that can be replicated during the Auto Scaling process. This central server was configured to handle neither user nor system requests, and it was hosted on the same subnet as the central services instances.