Oplossingsidee
Als u wilt dat we dit artikel uitbreiden met meer informatie, zoals mogelijke use cases, alternatieve services, implementatieoverwegingen of prijsinformatie, laat het ons dan weten met GitHub Feedback!
Deze oplossingsarchitectuur laat zien hoe een gebruikersaanvraag door een SAP-landschap loopt dat is gebouwd op krachtige Azure Virtual Machines en een in-memory HANA-database die wordt uitgevoerd op grote HANA-instanties voor ongeëvenaarde schaalbaarheid en prestaties. Dit systeem maakt gebruik van clustering van besturingssystemen voor databaseprestaties, hoge beschikbaarheid met behulp van HANA-systeemreplicatie en een configuratie voor volledig herstel na noodherstel (DR) voor gegarandeerde beschikbaarheid van het systeem.
Architectuur
Download een SVG van deze architectuur.
Gegevensstroom
- In dit voorbeeld voert een on-premises SAP-gebruiker een verkooporder uit via de Fiori-interface, een aangepaste interface of een andere.
- De Snelle ExpressRoute-gateway van Azure wordt gebruikt om verbinding te maken met Azure Virtual Machines.
- Aanvragen stromen naar maximaal beschikbare ABAP SAP Central Services (ASCS) en vervolgens via toepassingsservers die worden uitgevoerd op Azure Virtual Machines in een beschikbaarheidsset met een SLA voor een uptime van 99,95 procent.
- De aanvraag wordt verzonden van App Server naar SAP HANA uitgevoerd op de blades van het primaire grote exemplaar.
- Primaire en secundaire blades worden geclusterd op besturingssysteemniveau voor een beschikbaarheid van 99,99 procent en gegevensreplicatie wordt verwerkt via HANA-systeemreplicatie in de synchrone modus (HSR) van de primaire naar de secundaire database, waardoor geen RPO mogelijk is.
- Gegevens in het geheugen van SAP HANA worden opgeslagen in NFS-opslag met hoge prestaties.
- Van gegevens uit NFS-opslag wordt periodiek in enkele seconden een back-up gemaakt met behulp van ingebouwde opslagmomentopnamen op de lokale opslag, zonder dat dit van invloed is op de prestaties van de database.
- Permanent gegevensvolume op secundaire opslag wordt gerepliceerd naar toegewezen DR-systeem via een toegewezen backbone-netwerk voor HANA-opslagreplicatie.
- Grote instanties aan de dr-zijde kunnen worden gebruikt voor niet-productie om kosten te besparen door zowel de QA-opslag als het gerepliceerde dr-volume (alleen-lezen) te monteren.
Onderdelen
- SAP HANA op groteAzure-exemplaren: SAP HANA in Azure (grote exemplaren) worden uitgevoerd op toegewezen bladeservers in een Microsoft Azure Datacenter. Dit is specifiek voor de databaseserver.
- NFS-opslagvoor grote azure HANA-exemplaren: het NFS-opslagsysteem met hoge prestaties van Azure biedt de niet-overeenkomende mogelijkheid om momentopnameback-ups en replicatie naar secundaire opslag uit te voeren. Bovendien is HANA Large Instance de enige cloudinfrastructuur die opslagvolumeversleuteling biedt.
- SAP on Azure moet u uw SAP-workloads uitvoeren op gecertificeerde Microsoft Azure Virtual Machines. SAP vereist ten minste twee vCPU's en een verhouding van 6:1 tussen geheugen en vCPU.
- Microsoft Azure Premium Storage verbeterde doorvoer en minder variabiliteit in I/O-latentie. Voor verbeterde prestaties gebruikt Premium Storage SSD (Solid State Disk) in Azure Storage-knooppunten en leescache die wordt gebruikt door de lokale SSD van een Azure-rekenknooppunt.
- ExpressRoute (front-end): Azure ExpressRoute die wordt gebruikt in de front-end (zie diagram) biedt een veilige verbinding met hoge bandbreedte om betrouwbare verbindingen tot stand te brengen tussen uw netwerk en Microsoft Azure netwerk.
- ExpressRoute (back-end): Azure ExpressRoute gebruikt op de back-end (zie diagram) kunt u communiceren tussen uw Azure-onderdelen in het Azure-datacenter en uw SAP HANA op Azure-systemen (large instance). De kosten van de back-end ExpressRoute zijn opgenomen in uw SAP HANA in Azure (large instance).