SAP-werkbelastingconfiguraties met Azure-beschikbaarheidszones

  • Artikel

Naast de implementatie van de verschillende SAP-architectuurlagen in Azure-beschikbaarheidssets, kan Azure Beschikbaarheidszones ook worden gebruikt voor SAP-workloadimplementaties. 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. Op deze kaart ziet u welke regio's bieden of worden aangekondigd om Beschikbaarheidszones te bieden.

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

  • SAP-toepassingslaag, die één tot enkele tientallen VM's 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 DBMS-laag bevinden om netwerklatentie in een acceptabel venster te behouden
  • 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
  • SAP DBMS-laag, 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 beveiligd door stroom-, koel- of netwerkproblemen die van invloed zijn op de dataceter(s) van de zone als geheel. Aan de pluszijde worden de VM's uitgelijnd met update- en foutdomeinen binnen die zone of datacenter. Specifiek voor de SAP ASCS- of DBMS-laag 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 op de verschillende fysieke locaties geïmplementeerd en worden hiermee beveiliging toegevoegd tegen stroom-, koelings- of netwerkproblemen die van invloed zijn op de gegevensceter(s) van de zone als geheel. 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 implementatie via Beschikbaarheidszones ideaal voor de SAP ASCS- en DBMS-laag waar we meestal twee VM's elk 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 het opgegeven 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:

  • De maximale netwerkrondelatentie tussen Azure Beschikbaarheidszones wordt vermeld in de documentregio'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.
  • Beschikbaarheidszones geen ideale DR-oplossing zijn. Natuurrampen kunnen grote schade veroorzaken in de wereldregio's, waaronder zware schade aan energie-infrastructuren. De afstanden tussen verschillende zones zijn mogelijk niet groot genoeg om een juiste DR-oplossing te vormen.
  • De netwerklatentie in Beschikbaarheidszones is niet hetzelfde in alle Azure-regio's. In sommige gevallen kunt u de SAP-toepassingslaag implementeren en uitvoeren op verschillende zones, omdat de netwerklatentie van één zone naar de actieve DBMS-VM acceptabel is. Maar in sommige Azure-regio's is de latentie tussen de actieve DBMS-VM en het SAP-toepassingsexemplaren, wanneer deze in verschillende zones wordt geïmplementeerd, mogelijk niet acceptabel voor SAP-bedrijfsprocessen. In deze gevallen moet de implementatiearchitectuur verschillen, met een actieve/actieve architectuur voor de toepassing of een actieve/passieve architectuur waarbij netwerklatentie tussen zones te hoog is.
  • 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 DBMS-exemplaren die synchrone replicatie moeten hebben. Hoe hoger de netwerklatentie, hoe waarschijnlijker dit van invloed is op de schaalbaarheid van uw workload.
    • Het verschil in netwerklatentie tussen een VIRTUELE machine waarop een SAP-dialoogvensterexemplaren in de zone wordt uitgevoerd met het actieve DBMS-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 worden uitgevoerd met dbms of in een andere zone.

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 DBMS-laag en de centrale services tussen 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.

De ideale Beschikbaarheidszones combinatie

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 VMS waarop de DBMS-laag wordt uitgevoerd, worden verdeeld over twee zones. Het aantal vm's waarop de SAP-toepassingslaag wordt uitgevoerd, worden geïmplementeerd in even getallen in dezelfde twee zones. Als een FAILOVER van een DBMS- 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 DBMS-VM en de toepassingsexemplaren worden uitgevoerd. Deze architectuur is de voorkeursarchitectuur voor implementatie in meerdere zones.
  • Actief/passief: het paar virtuele machines waarop ASCS/SCS wordt uitgevoerd en het paar VMS waarop de DBMS-laag wordt uitgevoerd, worden verdeeld over twee zones. Het aantal 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 DBMS-exemplaar. U gebruikt deze implementatiearchitectuur als de netwerklatentie in de verschillende zones te hoog is om de toepassingslaag uit te voeren die over de zones is verdeeld. In plaats daarvan moet de SAP-toepassingslaag worden uitgevoerd in dezelfde zone als het actieve ASCS/SCS- en/of DBMS-exemplaar. Als een FAILOVER van een ASCS/SCS- of DBMS-VM naar de secundaire zone wordt uitgevoerd, kan er sprake zijn van een hogere netwerklatentie 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. In sommige Azure-regio's is deze architectuur de enige levensvatbare architectuur wanneer u Beschikbaarheidszones wilt gebruiken. Als u de mogelijke impact van een ASCS/SCS- of DBMS-VMS-failover naar de secundaire zone niet kunt accepteren, is het wellicht beter om te blijven werken met implementaties van beschikbaarheidssets

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 DBMS-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 DBMS-VM's in de twee DBMS-zones die u hebt geselecteerd.
  • Als niping meethulpmiddel gebruiken. Dit hulpprogramma, van SAP, wordt beschreven in sap-ondersteuningsopmerkingen #500235 en #1100926. 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 DBMS-laag.
  • 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.)

Houd bij het nemen van deze beslissingen ook rekening met de aanbevelingen voor netwerklatentie van SAP, zoals beschreven in SAP-opmerking #1100926.

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 opleveren 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 geïmplementeerd tussen twee zones. Hetzelfde geldt voor de DBMS-laag, 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 is voor uw workload en uw synchrone DBMS-replicatie. U wilt er ook voor zorgen dat de verschillen tussen netwerklatentie binnen de geselecteerde zones en de netwerklatentie tussen meerdere zones niet te groot is.

De aard van de SAP-architectuur is dat, tenzij u deze anders configureert, gebruikers en batchtaken kunnen worden uitgevoerd in de verschillende toepassingsexemplaren. Het neveneffect van dit feit met de actieve/actieve implementatie is dat batchtaken kunnen worden uitgevoerd door sap-toepassingsexemplaren, onafhankelijk van of deze worden uitgevoerd in dezelfde zone met de actieve DBMS 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 DBMS-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.

Azure-regio's waar een dergelijke actieve/actieve implementatie mogelijk is zonder aanzienlijke grote verschillen in runtime en doorvoer binnen de toepassingslaag die is geïmplementeerd in verschillende Beschikbaarheidszones, zoals:

  • Australië - oost (twee van de drie zones)
  • Brazilië - zuid (alle drie de zones)
  • India - centraal (alle drie de zones)
  • VS - centraal (alle drie de zones)
  • Azië - oost (alle drie de zones)
  • VS - oost (twee van de drie zones)
  • VS - oost2 (alle drie de zones)
  • Duitsland - west-centraal (alle drie de zones)
  • Israël - centraal (alle drie de zones)
  • Italië - noord (twee van de drie zones)
  • Korea - centraal (alle drie de zones)
  • Polen - centraal (alle drie de zones)
  • Qatar Central (alle drie de zones)
  • Europa - noord (alle drie de zones)
  • Noorwegen - oost (twee van de drie zones)
  • Zuid-Afrika - noord (twee van de drie)
  • VS - zuid-centraal (alle drie de zones)
  • Azië - zuidoost (alle drie de zones)
  • Zweden - centraal (alle drie de zones)
  • Zwitserland - noord (alle drie de zones)
  • UAE - noord (alle drie de zones)
  • VK - zuid (twee van de drie zones)
  • Europa - west (twee van de drie zones)
  • VS - west2 (alle drie de zones)
  • VS - west3 (alle drie de zones)

De opgegeven regiolijst biedt u als klant geen hulp om uw workload te testen om te bepalen of een actieve/actieve implementatiearchitectuur mogelijk is.

Azure-regio's waarin de actieve/actieve SAP-implementatiearchitectuur tussen zones mogelijk niet mogelijk is, zoals:

  • Canada - midden
  • Frankrijk - centraal
  • Japan East

Hoewel het voor uw afzonderlijke workload kan werken. Daarom moet u testen voordat u een architectuur kiest. Azure werkt voortdurend aan het verbeteren van de kwaliteit en latentie van de netwerken. Metingen die jaren terug worden uitgevoerd, weerspiegelen mogelijk niet meer de huidige omstandigheden.

Afhankelijk van wat u bereid bent om te tolereren bij runtimeverschillen, kunnen andere regio's die niet worden vermeld, ook in aanmerking komen.

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

Active/Active zone deployment

De volgende overwegingen zijn van toepassing op deze configuratie:

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 DBMS-laag is behoorlijk intensief. Daarom kan het actieve/actieve scenario bijdragen aan kosten.

Actieve/passieve implementatie

Als u geen acceptabele delta kunt vinden tussen de netwerklatentie binnen één zone en de latentie van netwerkverkeer tussen zones, 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 de actieve DBMS 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 DBMS-exemplaar of niet, in zakelijke transacties en batchtaken.

Azure-regio's waar dit type implementatiearchitectuur in verschillende zones de voorkeur kan hebben:

  • Canada - midden
  • Frankrijk - centraal
  • Japan East
  • Noorwegen - oost
  • Zuid-Afrika - noord

De basisindeling van de architectuur ziet er als volgt uit:

Active/Passive zone deployment

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 de actieve DBMS- 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 DBMS-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 DBMS-laag moet u de Standard SKU Azure Load Balancer gebruiken. De Basic Load Balancer werkt niet tussen zones.
  • 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 Storage, Ultra SSD-opslag of ANF bieden geen ondersteuning voor replicatie van opslag tussen zones. Voor DBMS-implementaties zijn we afhankelijk van databasemethoden voor het repliceren van gegevens tussen zones
  • 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 DBMS-oogpunt) 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 die een RPO (Recovery Point Objective) van nul belooft. Een RPO van nul betekent dat u geen vastgelegde databasetransacties kwijtraakt, zelfs in gevallen van noodherstel.

Notitie

We raden u aan om een configuratie zoals deze alleen in bepaalde omstandigheden te gebruiken. U kunt deze bijvoorbeeld gebruiken wanneer gegevens de Azure-regio niet om beveiligings- of nalevingsredenen kunnen verlaten.

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

Combined high-availability DR 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 dat u gedwongen bent 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 de actieve DBMS- 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 DBMS-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 DBMS-laag moet u de Standard SKU Azure Load Balancer gebruiken. De Basic Load Balancer werkt niet tussen zones.
  • 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 Storage, Ultra SSD-opslag of ANF bieden geen ondersteuning voor replicatie van opslag tussen zones. Voor DBMS-implementaties zijn we afhankelijk van databasemethoden voor het repliceren van gegevens tussen zones
  • 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: