Examine a sample functional workflow
This workflow illustrates how a user request flows through an SAP landscape built on high-performance Azure virtual machines and an in-memory HANA database running on HANA Large Instances for scalability and performance. This system takes advantage of OS clustering for database performance, high availability using HANA system replication, and a full disaster recovery (DR) configuration for guaranteed system availability.
- In this example, an on-premises SAP user executes a sales order via Fiori interface, custom interface, or other.
- Azure high-speed ExpressRoute Gateway is used to connect to Azure virtual machines.
- The request flows into highly available ABAP SAP Central Services (ASCS) and then through application servers running on Azure virtual machines in an availability set offering a 99.95% uptime SLA.
- The request is sent from App Server to SAP HANA running on primary Large Instance blades.
- Primary and secondary blades are clustered at OS level for 99.99% availability, and data replication is handled through HANA System Replication in synchronous mode (HSR) from primary to secondary, enabling zero RPO.
- In-memory data of SAP HANA is persisted to high-performance NFS storage.
- Data from NFS storage is periodically backed up in seconds, using built-in storage snapshots on the local storage, without effect on database performance.
- Persistent data volume on secondary storage is replicated to dedicated DR system through a dedicated backbone network for HANA storage replication.
- The Large Instance on the DR side can be used for non-production to save costs, by mounting both the QA storage and DR replicated volume (read-only). At the disaster recovery (DR) site, the HLI unit is used for the Quality Assurance (QA) instance. Production operations run from the primary site. During DR failover (or failover test), the QA instance at the DR site is taken down.