Delen via

SAP-werkbelastingconfiguraties met Azure-beschikbaarheidszones

  • Artikel

Implementatie van de verschillende SAP-architectuurlagen in Azure Beschikbaarheidszones is de aanbevolen architectuur voor SAP-workloadimplementaties in Azure. Een Azure-beschikbaarheidszone wordt gedefinieerd als: 'Unieke fysieke locaties binnen een regio. Elke zone bestaat uit een of meer datacenters die zijn uitgerust met onafhankelijke voeding, koeling en netwerken". Azure Beschikbaarheidszones zijn niet beschikbaar in alle regio's. Voor Azure-regio's die Beschikbaarheidszones bieden, controleert u de kaart van de Azure-regio. In het artikel wordt vermeld welke regio's Beschikbaarheidszones bieden. De meeste Azure-regio's die zijn uitgerust om een grotere SAP-workload te hosten, bieden Beschikbaarheidszones. Nieuwe Azure-regio's bieden vanaf het begin Beschikbaarheidszones. Sommige oudere regio's waren of zijn in het proces aan het worden aangepast met Beschikbaarheidszones.

Vanaf de typische SAP NetWeaver- of S/4HANA-architectuur moet u drie verschillende lagen beveiligen:

  • De SAP-toepassingslaag, die één tot een paar dozijn virtuele machines (VM) kan zijn. U wilt de kans minimaliseren dat VM's worden geïmplementeerd op dezelfde hostserver. U wilt ook dat deze VM's zich in een acceptabele nabijheid van de databaselaag bevinden om netwerklatentie in een acceptabel venster te behouden
  • De SAP ASCS/SCS-laag die een single point of failure vertegenwoordigt in de SAP NetWeaver- en S/4HANA-architectuur. Meestal kijkt u naar twee VM's die u wilt behandelen met een failoverframework. Daarom moeten deze VM's worden toegewezen in verschillende foutdomeinen van de infrastructuur
  • De SAP-databaselaag, die ook een single point of failure vertegenwoordigt. In de gebruikelijke gevallen bestaat het uit twee VM's die worden gedekt door een failoverframework. Daarom moeten deze VM's worden toegewezen in verschillende infrastructuurfoutdomeinen. Uitzonderingen zijn uitschaalimplementaties van SAP HANA waarbij meer dan twee VM's kunnen worden gebruikt

De belangrijkste verschillen tussen het implementeren van uw kritieke VM's via beschikbaarheidssets of Beschikbaarheidszones zijn:

  • Implementeren met een beschikbaarheidsset is het instellen van de VM's binnen de set in één zone of datacenter (wat ook van toepassing is op de specifieke regio). Als gevolg hiervan wordt de implementatie via de beschikbaarheidsset niet beschermd door stroom-, koel- of netwerkproblemen die van invloed zijn op de datacenters van de zone als geheel. Met beschikbaarheidssets is er ook geen geforceerde uitlijning tussen een VIRTUELE machine en de bijbehorende schijven. Betekent dat de schijven zich in elk datacenter van de Azure-regio bevinden, onafhankelijk van de zonegebonden structuur van de regio. Aan de pluszijde worden de VM's uitgelijnd met update- en foutdomeinen binnen die zone of datacenter. Specifiek voor de SAP ASCS- of databaselaag waar we twee VM's per beschikbaarheidsset beveiligen, voorkomt de uitlijning met foutdomeinen dat beide VM's op dezelfde hosthardware terechtkomen.
  • Bij het implementeren van VM's via Azure Beschikbaarheidszones en het kiezen van verschillende zones (maximaal drie mogelijk), worden de VM's geïmplementeerd op de verschillende fysieke locaties en worden hiermee beveiliging toegevoegd tegen stroom-, koelings- of netwerkproblemen die van invloed zijn op de datacenters van de zone als geheel. VM's en de bijbehorende schijven bevinden zich ook in dezelfde beschikbaarheidszone. Als u echter meerdere VM's van dezelfde VM-familie in dezelfde beschikbaarheidszone implementeert, is er geen beveiliging tegen deze VM's die eindigen op dezelfde host of hetzelfde foutdomein. Als gevolg hiervan is de implementatie via Beschikbaarheidszones ideaal voor de SAP ASCS- en databaselaag, waarbij we meestal twee VIRTUELE machines bekijken. Voor de SAP-toepassingslaag, die aanzienlijk meer dan twee VM's kan zijn, moet u mogelijk terugvallen op een ander implementatiemodel (zie later).

Uw motivatie voor een implementatie in Azure Beschikbaarheidszones moet zijn dat u, naast het dekken van fouten van één kritieke VM of de mogelijkheid om downtime voor softwarepatching binnen een kritieke machine te verminderen, bescherming wilt bieden tegen grotere infrastructuurproblemen die van invloed kunnen zijn op de beschikbaarheid van een of meerdere Azure-datacenters.

Als een andere tolerantie-implementatiefunctionaliteit heeft Azure virtuele-machineschaalsets geïntroduceerd met flexibele indeling voor SAP-werkbelasting. Virtuele-machineschaalset biedt logische groepering van door het platform beheerde virtuele machines. De flexibele indeling van virtuele-machineschaalsets biedt de mogelijkheid om de schaalset in een regio te maken of deze over meerdere beschikbaarheidszones te verdelen. Bij het maken wordt de flexibele schaalset binnen een regio met platformFaultDomainCount>1 (FD>1) gedistribueerd over een bepaald aantal foutdomeinen in dezelfde regio. Aan de andere kant, het maken van de flexibele schaalset in beschikbaarheidszones met platformFaultDomainCount=1 (FD=1) zou de virtuele machines over verschillende zones verdelen en de schaalset zou ook VM's verdelen over verschillende foutdomeinen binnen elke zone op basis van de beste inspanning. Voor SAP-werkbelasting wordt alleen flexibele schaalset met FD=1 ondersteund. Het voordeel van het gebruik van flexibele schaalsets met FD=1 voor zoneoverschrijdende implementatie, in plaats van traditionele implementatie van beschikbaarheidszones is dat de VM's die met de schaalset zijn geïmplementeerd, op een optimale manier over verschillende foutdomeinen binnen de zone worden verdeeld. Zie de implementatiehandleiding voor flexibele schaalsets voor SAP-werkbelasting voor meer informatie.

Overwegingen voor de implementatie in Beschikbaarheidszones

Houd rekening met het volgende wanneer u Beschikbaarheidszones gebruikt:

  • Meer informatie over Azure Beschikbaarheidszones wordt weergegeven in het document Regio's en beschikbaarheidszones.
  • De ervaren netwerk roundtriplatentie is niet noodzakelijkerwijs indicatief voor de werkelijke geografische afstand van de datacenters die de verschillende zones vormen. De netwerk roundtriplatentie wordt ook beïnvloed door de kabelverbindingen en de routering van de kabels tussen deze verschillende datacenters.
  • Als u Beschikbaarheidszones als oplossing voor dr op kleine afstand gebruikt, moet u er rekening mee houden dat er natuurrampen zijn opgetreden die wijdverspreide schade veroorzaken in verschillende regio's van de wereld, waaronder zware en wijdverspreide schade aan energie-infrastructuren. De afstanden tussen verschillende zones zijn mogelijk niet altijd groot genoeg om dergelijke grotere natuurrampen te compenseren.
  • De netwerklatentie in Beschikbaarheidszones is niet hetzelfde in alle Azure-regio's. Zelfs binnen een Azure-regio kunnen de netwerklatenties tussen de verschillende zones variëren. Hoewel zelfs in het ergste geval synchrone replicatie op databaseniveau op basis van HANA-systeemreplicatie of SQL Server AlwaysOn zal werken zonder dat dit van invloed is op de schaalbaarheid van de workload.
  • Bij het bepalen waar Beschikbaarheidszones moet worden gebruikt, moet u uw beslissing baseren op de netwerklatentie tussen de zones. Netwerklatentie speelt een belangrijke rol in twee gebieden:
    • Latentie tussen de twee database-exemplaren die synchrone replicatie moeten hebben. Op basis van zeer succesvolle bewerkingen van de grootste NetWeaver- en S/4HANA-systemen tussen zones met hogere netwerklatenties (minder dan 1,5 milliseconden), kan deze overweging worden genegeerd
    • Het verschil in netwerklatentie tussen een VIRTUELE machine met een SAP-dialoogvensterexemplaren in de zone met het actieve database-exemplaar en een vergelijkbare VM in een andere zone. Naarmate dit verschil toeneemt, neemt de invloed op de uitvoeringstijd van bedrijfsprocessen en batchtaken ook toe, afhankelijk van of ze in de zone met de database of in een andere zone worden uitgevoerd (zie verderop in dit artikel).
  • De netwerklatentie met Azure Beschikbaarheidszones, zelfs in de grootste zones, is voldoende laag om SAP-bedrijfsprocessen uit te voeren. Tot nu toe hebben we slechts enkele uitzonderlijke gevallen gezien waarbij klanten de SAP-toepassingslaag en -databaselaag moesten plaatsen onder één ruggengraat van het datacenternetwerk.

Wanneer u Azure-VM's implementeert in Beschikbaarheidszones en failoveroplossingen in dezelfde Azure-regio tot stand brengt, gelden enkele beperkingen:

  • U moet Azure Managed Disks gebruiken wanneer u implementeert in Azure Beschikbaarheidszones.
  • De toewijzing van zone-inventarisaties aan de fysieke zones is opgelost op basis van een Azure-abonnement. Als u verschillende abonnementen gebruikt om uw SAP-systemen te implementeren, moet u de ideale zones voor elk abonnement definiëren. Als u de logische toewijzing van uw verschillende abonnementen wilt vergelijken, kunt u het Avzone-Mapping-script overwegen.
  • U kunt Azure-beschikbaarheidssets niet implementeren binnen een Azure-beschikbaarheidszone, tenzij u de Azure Proximity-plaatsingsgroep gebruikt. De manier waarop u de SAP-databaselaag en de centrale services in zones kunt implementeren en tegelijkertijd de SAP-toepassingslaag kunt implementeren met behulp van beschikbaarheidssets en nog steeds de nabijheid van de VM's kunt bereiken, wordt beschreven in het artikel Azure Proximity-plaatsingsgroepen voor optimale netwerklatentie met SAP-toepassingen. Als u geen azure-nabijheidsplaatsingsgroepen gebruikt, moet u een of de andere kiezen als een implementatieframework voor virtuele machines.
  • U kunt geen Azure Basic Load Balancer gebruiken om failoverclusteroplossingen te maken op basis van Windows Server Failover Clustering of Linux Pacemaker. In plaats daarvan moet u de Azure Standard Load Balancer-SKU gebruiken.
  • U moet zonegebonden versie van ExpressRoute Gateway, VPN Gateway en Standaard openbare IP-adressen implementeren om de zonegebonden bescherming te krijgen die u wenst.

De ideale Beschikbaarheidszones combinatie

Tenzij u de toewijzing van bedrijfsprocessen configureert met SAP-functies zoals Aanmeldingsgroepen, RFC-servergroepen, Batch-servergroepen en vergelijkbare, kunnen bedrijfsprocessen worden uitgevoerd in de verschillende toepassingsexemplaren in uw SAP-toepassingslaag. Het neveneffect van dit feit is dat batchtaken kunnen worden uitgevoerd door sap-toepassingsexemplaren, onafhankelijk van of deze worden uitgevoerd in dezelfde zone met het actieve database-exemplaar of niet. Als het verschil in netwerklatentie tussen de verschilzones klein is in vergelijking met de netwerklatentie binnen een zone, is het verschil in uitvoeringstijden van batchtaken mogelijk niet significant. Hoe groter het verschil tussen netwerklatentie binnen een zone, vergeleken met het netwerkverkeer in de zone, is dat de uitvoeringstijd van batchtaken meer kan worden beïnvloed als de taak is uitgevoerd in een zone waar het database-exemplaar niet actief is. Het is aan u als klant om te bepalen wat acceptabele verschillen in runtime zijn. En daarmee is de toelaatbare netwerklatentie voor verkeer tussen zones voor uw workload. Vanuit technisch oogpunt werken de netwerklatenties tussen Azure Beschikbaarheidszones binnen een Azure-regio voor de architectuur van NetWeaver, S/4HANA of andere SAP-toepassingen. Het is ook op u als klant mogelijk om dergelijke verschillen te beperken met behulp van de SAP-concepten van aanmeldingsgroepen, RFC-servergroepen, Batch-servergroepen en vergelijkbaar wanneer u besluit voor een van de implementatieconcepten die we in dit artikel introduceren.

Als u een SAP NetWeaver- of S/4HANA-systeem tussen zones wilt implementeren, zijn er twee architectuurpatronen die u kunt implementeren:

  • Actief/actief: het paar virtuele machines waarop ASCS/SCS wordt uitgevoerd en het paar virtuele machines waarop de databaselaag wordt uitgevoerd, worden verdeeld over twee zones. De VM's waarop de SAP-toepassingslaag wordt uitgevoerd, worden geïmplementeerd in even getallen in dezelfde twee zones. Als een failover van een database of ASCS/SCS-VM wordt uitgevoerd, kunnen sommige geopende en actieve transacties worden teruggedraaid. Maar gebruikers blijven aangemeld. Het maakt niet echt uit in welke zones de actieve database-VM en de toepassingsexemplaren worden uitgevoerd. Deze architectuur is de voorkeursarchitectuur voor implementatie in meerdere zones. In gevallen waarin netwerklatenties tussen zones grotere verschillen veroorzaken bij het uitvoeren van bedrijfsprocessen, kunt u functies zoals SAP-aanmeldingsgroepen, RFC-servergroepen, Batch-servergroepen en vergelijkbaar zijn met het routeren van de uitvoering van de bedrijfsprocessen naar specifieke dialoogvensterexemplaren die zich in dezelfde zone bevinden met het actieve database-exemplaar
  • Actief/passief: het paar virtuele machines waarop ASCS/SCS wordt uitgevoerd en het paar virtuele machines waarop de databaselaag wordt uitgevoerd, worden verdeeld over twee zones. De VM's waarop de SAP-toepassingslaag wordt uitgevoerd, worden geïmplementeerd in een van de Beschikbaarheidszones. U voert de toepassingslaag uit in dezelfde zone als het actieve ASCS/SCS- en database-exemplaar. U kunt deze implementatiearchitectuur gebruiken als u de netwerklatentie in de verschillende zones beschouwt als te hoog. En met dat tot onverdraaglijke verschillen in de runtime van uw bedrijfsprocessen. Of als u implementaties van beschikbaarheidszones wilt gebruiken als implementaties voor herstel na noodgevallen op korte afstand. de zones. Als een failover van een ASCS/SCS- of database-VM naar de secundaire zone wordt uitgevoerd, kan er een hogere netwerklatentie optreden en daarmee een vermindering van de doorvoer. En u moet een failback uitvoeren van de eerder uitgevoerde VM zo snel mogelijk om terug te gaan naar de vorige doorvoerniveaus. Als er sprake is van een zonegebonden storing, moet de toepassingslaag worden overgeschakeld naar de secundaire zone. Een activiteit die gebruikers ervaren als volledig afsluiten van het systeem.

Dus voordat u besluit hoe u Beschikbaarheidszones gebruikt, moet u het volgende bepalen:

  • De netwerklatentie tussen de drie zones van een Azure-regio. Als u de netwerklatentie tussen de zones van een regio kent, kunt u de zones kiezen met de minste netwerklatentie in netwerkverkeer tussen meerdere zones.
  • Het verschil tussen vm-naar-VM-latentie binnen een van de zones, van uw keuze, en de netwerklatentie tussen twee zones van uw keuze.
  • Bepaal of de VM-typen die u moet implementeren, beschikbaar zijn in de twee zones die u hebt geselecteerd. Met sommige VM-SKU's kunt u situaties tegenkomen waarin sommige SKU's beschikbaar zijn in slechts twee van de drie zones.

Netwerklatentie tussen en binnen zones

Als u de latentie tussen de verschillende zones wilt bepalen, moet u het volgende doen:

  • Implementeer de VM-SKU die u wilt gebruiken voor uw database-exemplaar in alle drie de zones. Zorg ervoor dat Versneld netwerken van Azure is ingeschakeld wanneer u deze meting uitvoert. Versneld netwerken is de standaardinstelling sinds een paar jaar. Controleer echter of deze is ingeschakeld en werkt
  • Wanneer u de twee zones met de minste netwerklatentie vindt, implementeert u nog eens drie VM's van de VM-SKU die u wilt gebruiken als de VM op de toepassingslaag in de drie Beschikbaarheidszones. Meet de netwerklatentie ten opzichte van de twee database-VM's in de twee zones die u hebt geselecteerd.
  • Als niping meethulpmiddel gebruiken. Dit hulpprogramma, van SAP, wordt beschreven in sap-ondersteuningsopmerkingen #500235 en #1100926. Behandel de netwerklatentieclassificatie in SAP Note #1100926 als ruwe richtlijnen. Netwerklatenties die groter zijn dan 0,7 milliseconden betekenen niet dat het systeem technisch niet gaat werken of dat bedrijfsprocessen niet voldoen aan uw afzonderlijke SLA's. De opmerking is niet bedoeld om aan te geven wat wordt ondersteund of niet wordt ondersteund door SAP en/of Microsoft. Richt u op de opdrachten die zijn gedocumenteerd voor latentiemetingen. Omdat ping niet werkt via de codepaden voor versneld netwerken van Azure, raden we u niet aan deze te gebruiken.

U hoeft deze tests niet handmatig uit te voeren. U vindt een PowerShell-procedure latentietest voor beschikbaarheidszones waarmee de beschreven latentietests worden geautomatiseerd.

Op basis van uw metingen en de beschikbaarheid van uw VM-SKU's in de Beschikbaarheidszones moet u enkele beslissingen nemen:

  • Definieer de ideale zones voor de databaselaag.
  • Bepaal of u de actieve SAP-toepassingslaag wilt distribueren over één, twee of alle drie zones, op basis van verschillen in netwerklatentie in zone versus tussen zones.
  • Bepaal of u een actieve/passieve configuratie of een actieve/actieve configuratie wilt implementeren vanuit een toepassingspunt. (Deze configuraties worden verderop in dit artikel uitgelegd.)

Belangrijk

De metingen en beslissingen die u neemt, zijn geldig voor het Azure-abonnement dat u hebt gebruikt bij het uitvoeren van de metingen. Als u een ander Azure-abonnement gebruikt, kan de toewijzing van opgesomde zones afwijken voor een ander Azure-abonnement. Als gevolg hiervan moet u de metingen herhalen of de toewijzing van het nieuwe abonnement vaststellen aan het oude abonnement, het hulpprogramma Avzone-Mapping-script.

Belangrijk

Er wordt verwacht dat de metingen die eerder zijn beschreven, verschillende resultaten bieden in elke Azure-regio die ondersteuning biedt voor Beschikbaarheidszones. Zelfs als uw netwerklatentievereisten hetzelfde zijn, moet u mogelijk verschillende implementatiestrategieën in verschillende Azure-regio's gebruiken, omdat de netwerklatentie tussen zones anders kan zijn. In sommige Azure-regio's kan de netwerklatentie tussen de drie verschillende zones enorm verschillen. In andere regio's is de netwerklatentie tussen de drie verschillende zones mogelijk uniformer. De claim dat er altijd een netwerklatentie tussen 1 en 2 milliseconden is niet juist. De netwerklatentie tussen Beschikbaarheidszones in Azure-regio's kan niet worden gegeneraliseerd.

Actieve/actieve implementatie

Deze implementatiearchitectuur wordt actief/actief genoemd omdat u uw actieve SAP-toepassingsservers in twee of drie zones implementeert. Het SAP Central Services-exemplaar dat gebruikmaakt van replicatie in de wachtrij, wordt tussen twee zones geïmplementeerd. Hetzelfde geldt voor de databaselaag, die wordt geïmplementeerd in dezelfde zones als SAP Central Service. Wanneer u deze configuratie overweegt, moet u de twee Beschikbaarheidszones in uw regio vinden die netwerklatentie tussen zones bieden die acceptabel zijn voor uw workload. U wilt er ook voor zorgen dat de verschillen tussen netwerklatentie binnen de geselecteerde zones en de netwerklatentie tussen zones acceptabel is voor uw workload.

Een vereenvoudigd schema van een actieve/actieve implementatie in twee zones kan er als volgt uitzien:

Implementatie van actieve/actieve zone

De volgende overwegingen zijn van toepassing op deze configuratie:

  • Niet met behulp van de Azure Proximity-plaatsingsgroep behandelt u de Azure-Beschikbaarheidszones als foutdomeinen voor alle VM's, omdat beschikbaarheidssets niet kunnen worden geïmplementeerd in Azure Beschikbaarheidszones.
  • Als u zonegebonden implementaties wilt combineren voor de databaselaag en centrale services, maar Azure-beschikbaarheidssets wilt gebruiken voor de toepassingslaag, moet u Azure-nabijheidsgroepen gebruiken, zoals beschreven in het artikel Azure Proximity Placement Groups voor optimale netwerklatentie met SAP-toepassingen.
  • Voor de load balancers van de failoverclusters van SAP Central Services en de databaselaag moet u de Standard SKU Azure Load Balancer gebruiken. De Basic Load Balancer werkt niet tussen zones.
  • U moet zonegebonden versie van ExpressRoute Gateway, VPN Gateway en Standaard openbare IP-adressen implementeren om de zonegebonden bescherming te krijgen die u wenst.
  • Het virtuele Azure-netwerk dat u hebt geïmplementeerd om het SAP-systeem te hosten, samen met de bijbehorende subnetten, wordt verdeeld over zones. U hebt geen afzonderlijke virtuele netwerken en subnetten nodig voor elke zone.
  • Voor alle virtuele machines die u implementeert, moet u Azure Managed Disks gebruiken. Niet-beheerde schijven worden niet ondersteund voor zonegebonden implementaties.
  • Azure Premium SSD v2, Ultra SSD-opslag of Azure NetApp Files biedt geen ondersteuning voor synchrone opslagreplicatie tussen zones. Voor database-implementaties zijn we afhankelijk van databasemethoden voor het repliceren van gegevens tussen zones.
  • Premium SSD v1 die synchrone zonegebonden replicatie ondersteunt in Beschikbaarheidszones niet is getest met sap-databaseworkload. Daarom moet de zonegebonden synchrone replicatie van Azure Premium SSD v1 worden beschouwd als niet ondersteund voor SAP-databaseworkloads.
  • Voor SMB- en NFS-shares op basis van Azure Premium Files wordt zonegebonden redundantie met synchrone replicatie aangeboden. Raadpleeg dit document voor beschikbaarheid van ZRS voor Azure Premium Files in de regio waarin u wilt implementeren. Het gebruik van zonegebonden gerepliceerde NFS- en SMB-shares wordt volledig ondersteund met implementaties van SAP-toepassingslagen en failoverclusters met hoge beschikbaarheid voor NetWeaver- of S/4HANA-centralesservices. Documenten die betrekking hebben op deze zaken zijn:
  • De derde zone wordt gebruikt om het SBD-apparaat te hosten als u een SUSE Linux Pacemaker-cluster bouwt en SBD-apparaten gebruikt in plaats van de Azure Fencing Agent. Of voor meer toepassingsexemplaren.
  • Als u runtimeconsistentie wilt bereiken voor kritieke bedrijfsprocessen, kunt u proberen bepaalde batchtaken en gebruikers om te leiden naar toepassingsexemplaren die zich in de zone bevinden met het actieve database-exemplaar met behulp van SAP Batch-servergroepen, SAP-aanmeldingsgroepen of RFC-groepen. In het zonegebonden failoverproces moet u deze groepen echter handmatig verplaatsen naar exemplaren die worden uitgevoerd op VM's die zich in de zone bevinden met de actieve DATABASE-VM.
  • Mogelijk wilt u slapende dialoogvensterexemplaren in elk van de zones implementeren.

Belangrijk

In dit actieve/actieve scenario worden kosten in rekening gebracht voor verkeer tussen zones. Controleer de prijsinformatie voor de bandbreedte van het document. De gegevensoverdracht tussen de SAP-toepassingslaag en de SAP-databaselaag is behoorlijk intensief. Daarom kan het actieve/actieve scenario bijdragen aan kosten.

Actieve/passieve implementatie

Als u geen configuratie kunt vinden die de potentiële verschillen in runtime van SAP-bedrijfsprocessen beperkt of als u een configuratie voor herstel na noodgevallen op korte afstand wilt implementeren, kunt u een architectuur met een actief/passief teken implementeren vanuit het oogpunt van de SAP-toepassingslaag. U definieert een actieve zone, de zone waar u de volledige toepassingslaag implementeert en waar u zowel het actieve database-exemplaar als het SAP Central Services-exemplaar probeert uit te voeren. Met een dergelijke configuratie moet u ervoor zorgen dat u geen extreme uitvoeringstijdvariaties hebt, afhankelijk van of een taak in de zone wordt uitgevoerd met het actieve database-exemplaar of niet, in zakelijke transacties en batchtaken.

De basisindeling van de architectuur ziet er als volgt uit:

Implementatie van actieve/passieve zone

De volgende overwegingen zijn van toepassing op deze configuratie:

  • Beschikbaarheidssets kunnen niet worden geïmplementeerd in Azure Beschikbaarheidszones. Als u dit wilt beperken, kunt u Azure-nabijheidsplaatsingsgroepen gebruiken, zoals beschreven in het artikel Azure Proximity Placement Groups voor optimale netwerklatentie met SAP-toepassingen.
  • Wanneer u deze architectuur gebruikt, moet u de status nauwkeurig controleren en proberen het actieve database-exemplaar en SAP Central Services-exemplaren in dezelfde zone te houden als de geïmplementeerde toepassingslaag. Als er een failover van de SAP Central-service of het database-exemplaar is, moet u ervoor zorgen dat u handmatig een failback naar de zone kunt uitvoeren met de SAP-toepassingslaag die zo snel mogelijk is geïmplementeerd.
  • Voor de load balancers van de failoverclusters van SAP Central Services en de databaselaag moet u de Standard SKU Azure Load Balancer gebruiken. De Basic Load Balancer werkt niet tussen zones.
  • U moet zonegebonden versie van ExpressRoute Gateway, VPN Gateway en Standaard openbare IP-adressen implementeren om de zonegebonden bescherming te krijgen die u wenst.
  • Het virtuele Azure-netwerk dat u hebt geïmplementeerd om het SAP-systeem te hosten, samen met de bijbehorende subnetten, wordt verdeeld over zones. U hebt geen afzonderlijke virtuele netwerken nodig voor elke zone.
  • Voor alle virtuele machines die u implementeert, moet u Azure Managed Disks gebruiken. Niet-beheerde schijven worden niet ondersteund voor zonegebonden implementaties.
  • Azure Premium SSD v2, Ultra SSD-opslag of Azure NetApp Files biedt geen ondersteuning voor synchrone opslagreplicatie tussen zones. Voor database-implementaties zijn we afhankelijk van databasemethoden voor het repliceren van gegevens tussen zones.
  • Premium SSD v1 die synchrone zonegebonden replicatie ondersteunt in Beschikbaarheidszones niet is getest met sap-databaseworkload. Daarom moet de configureerbare zonegebonden synchrone replicatie van Azure Premium SSD v1 worden beschouwd als niet ondersteund voor SAP-databaseworkloads.
  • Voor SMB- en NFS-shares op basis van Azure Premium Files wordt zonegebonden redundantie met synchrone replicatie aangeboden. Raadpleeg dit document voor beschikbaarheid van ZRS voor Azure Premium Files in de regio waarin u wilt implementeren. Het gebruik van zonegebonden gerepliceerde NFS- en SMB-shares wordt volledig ondersteund met implementaties van SAP-toepassingslagen en failoverclusters met hoge beschikbaarheid voor NetWeaver- of S/4HANA-centralesservices. Documenten die betrekking hebben op deze zaken zijn:
  • De derde zone wordt gebruikt om het SBD-apparaat te hosten als u een SUSE Linux Pacemaker-cluster bouwt en SBD-apparaten gebruikt in plaats van de Azure Fencing Agent. Of voor extra toepassingsexemplaren.
  • U moet actieve VM's implementeren in de passieve zone (vanuit een databasepunt) zodat u toepassingsbronnen kunt starten voor het geval van een zonefout. Een andere mogelijkheid is om Azure Site Recovery te gebruiken, waardoor actieve VM's kunnen worden gerepliceerd naar niet-actieve VM's tussen zones.
  • U moet investeren in automatisering waarmee u de SAP-toepassingslaag in de tweede zone automatisch kunt starten als er sprake is van een zonegebonden storing.

Gecombineerde configuratie voor hoge beschikbaarheid en herstel na noodgevallen

Microsoft deelt geen informatie over geografische afstanden tussen de faciliteiten die verschillende Azure-Beschikbaarheidszones hosten in een Azure-regio. Toch gebruiken sommige klanten zones voor een gecombineerde configuratie voor hoge beschikbaarheid en herstel na noodgevallen (korte dr) die een beoogde herstelpunt (RPO) van nul belooft. Een RPO van nul betekent dat u geen vastgelegde databasetransacties kwijtraakt, zelfs in gevallen van noodherstel.

Notitie

Als u Beschikbaarheidszones als oplossing voor dr op kleine afstand gebruikt, moet u er rekening mee houden dat er natuurrampen zijn opgetreden die wijdverspreide schade veroorzaken in de regio's van de wereld, waaronder zware en wijdverspreide schade aan energie-infrastructuren. De afstanden tussen verschillende zones zijn mogelijk niet altijd groot genoeg om dergelijke grotere natuurrampen te compenseren.

Hier volgt een voorbeeld van hoe een dergelijke configuratie eruit kan zien:

Gecombineerde herstel na noodgevallen met hoge beschikbaarheid in zones

De volgende overwegingen zijn van toepassing op deze configuratie:

  • U gaat ervan uit dat er een aanzienlijke afstand is tussen de faciliteiten die als host fungeren voor een beschikbaarheidszone. Of u wordt gedwongen om binnen een bepaalde Azure-regio te blijven. Beschikbaarheidssets kunnen niet worden geïmplementeerd in Azure Beschikbaarheidszones. Om dit te compenseren, kunt u Azure-nabijheidsplaatsingsgroepen gebruiken, zoals beschreven in het artikel Azure Proximity-plaatsingsgroepen voor optimale netwerklatentie met SAP-toepassingen.
  • Wanneer u deze architectuur gebruikt, moet u de status nauwkeurig controleren en proberen om het actieve database-exemplaar en SAP Central Services-exemplaren in dezelfde zone te houden als de geïmplementeerde toepassingslaag. Als er een failover van de SAP Central-service of het database-exemplaar is, moet u ervoor zorgen dat u handmatig een failback naar de zone kunt uitvoeren met de SAP-toepassingslaag die zo snel mogelijk is geïmplementeerd.
  • U moet productietoepassingsexemplaren vooraf hebben geïnstalleerd op de VM's waarop de actieve QA-toepassingsexemplaren worden uitgevoerd.
  • Sluit in een zonegebonden fout de QA-toepassingsexemplaren af en start in plaats daarvan de productie-exemplaren. U moet virtuele namen voor de toepassingsexemplaren gebruiken om dit te laten werken.
  • Voor de load balancers van de failoverclusters van SAP Central Services en de databaselaag moet u de Standard SKU Azure Load Balancer gebruiken. De Basic Load Balancer werkt niet tussen zones.
  • U moet zonegebonden versie van ExpressRoute Gateway, VPN Gateway en Standaard openbare IP-adressen implementeren om de zonegebonden bescherming te krijgen die u wenst.
  • Het virtuele Azure-netwerk dat u hebt geïmplementeerd om het SAP-systeem te hosten, samen met de bijbehorende subnetten, wordt verdeeld over zones. U hebt geen afzonderlijke virtuele netwerken nodig voor elke zone.
  • Voor alle virtuele machines die u implementeert, moet u Azure Managed Disks gebruiken. Niet-beheerde schijven worden niet ondersteund voor zonegebonden implementaties.
  • Azure Premium SSD v2, Ultra SSD-opslag of Azure NetApp Files biedt geen ondersteuning voor synchrone opslagreplicatie tussen zones. Voor database-implementaties zijn we afhankelijk van databasemethoden voor het repliceren van gegevens tussen zones.
  • Premium SSD v1 die synchrone zonegebonden replicatie ondersteunt in Beschikbaarheidszones niet is getest met sap-databaseworkload. Daarom moet de configureerbare zonegebonden synchrone replicatie van Azure Premium SSD v1 worden beschouwd als niet ondersteund voor SAP-databaseworkloads.
  • Voor SMB- en NFS-shares op basis van Azure Premium Files wordt zonegebonden redundantie met synchrone replicatie aangeboden. Raadpleeg dit document voor beschikbaarheid van ZRS voor Azure Premium Files in de regio waarin u wilt implementeren. Het gebruik van zonegebonden gerepliceerde NFS- en SMB-shares wordt volledig ondersteund met implementaties van SAP-toepassingslagen en failoverclusters met hoge beschikbaarheid voor NetWeaver- of S/4HANA-centralesservices. Documenten die betrekking hebben op deze zaken zijn:
  • De derde zone wordt gebruikt om het SBD-apparaat te hosten als u een SUSE Linux Pacemaker-cluster bouwt en SBD-apparaten gebruikt in plaats van de Azure Fencing Agent.

Volgende stappen

Hier volgen enkele volgende stappen voor het implementeren in Azure Beschikbaarheidszones: