SAP-werkbelastingconfiguraties met Azure-beschikbaarheidszones

Naast de implementatie van de verschillende SAP-architectuurlagen in Azure-beschikbaarheidssets, kan de recenter geïntroduceerde 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 in alle regio's beschikbaar. Voor Azure-regio's die een Beschikbaarheidszones, controleert u de kaart met Azure-regio's. Deze kaart laat zien welke regio's u bieden of worden aangekondigd om uw Beschikbaarheidszones.

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

• SAP-toepassingslaag, die een tot enkele tientallen VM's kan zijn. U wilt de kans minimaliseren dat VM's op dezelfde hostserver worden geïmplementeerd. U wilt ook dat deze VM's zich in een acceptabele nabijheid van de DBMS-laag bevinden om netwerklatentie binnen een acceptabel venster te houden
• SAP ASCS/SCS-laag die een single point of failure vertegenwoordigt in de SAP NetWeaver- en S/4HANA-architectuur. Meestal bekijkt u twee VM's die u wilt behandelen met een failover-framework. Daarom moeten deze VM's worden toegewezen in verschillende infrastructuurfout- en updatedomeinen
• SAP DBMS-laag, die ook één storingspunt vertegenwoordigt. In de gebruikelijke gevallen bestaat het uit twee VM's die worden gedekt door een failover-framework. Daarom moeten deze VM's worden toegewezen in verschillende infrastructuurfout- en updatedomeinen. Uitzonderingen zijn SAP HANA uitschalen van implementaties 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 de VM's binnen de set in één zone of datacenter (wat van toepassing is op de specifieke regio). Als gevolg hiervan wordt de implementatie via de beschikbaarheidsset niet beveiligd door problemen met voeding, koeling of netwerken 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 het datacenter. Met name voor de SAP ASCS- of DBMS-laag waarbij we twee VM's per beschikbaarheidsset beveiligen, voorkomt de afstemming met fout- en updatedomeinen dat beide VM's op dezelfde hosthardware eindigen
• Als u VM's implementeert via een Azure-beschikbaarheidszones en verschillende zones kiest (maximaal drie tot nu toe mogelijk), worden de VM's geïmplementeerd op de verschillende fysieke locaties en wordt daarmee extra bescherming tegen stroom-, koelings- of netwerkproblemen die van invloed zijn op de datter(s) van de zone als geheel. Als u echter meer dan één VM van dezelfde VM-familie implementeert in dezelfde beschikbaarheidszone, is er geen beveiliging tegen deze VM's die op dezelfde host eindigen. Als gevolg hiervan is het implementeren via Beschikbaarheidszones ideaal voor de SAP ASCS- en DBMS-laag, waarbij we meestal naar twee VM's kijken. Voor de SAP-toepassingslaag, die drastisch 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 niet alleen het uitvallen van één kritieke VM, of de mogelijkheid om downtime voor softwarepatching binnen een kritieke softwarepatch te verminderen, wilt beschermen tegen grotere infrastructuurproblemen die van invloed kunnen zijn op de beschikbaarheid van een of meer Azure-datacenters.

Overwegingen voor implementatie in Beschikbaarheidszones

Houd rekening met het volgende wanneer u Beschikbaarheidszones:

• Er zijn geen garanties met betrekking tot de afstanden tussen verschillende Beschikbaarheidszones binnen een Azure-regio.
• Beschikbaarheidszones zijn geen ideale dr-oplossing. Natuurrampen kunnen wijdverbreide schade veroorzaken in wereldregio's, waaronder zware schade aan energie-infrastructuren. De afstanden tussen verschillende zones zijn mogelijk niet groot genoeg om een goede dr-oplossing te vormen.
• De netwerklatentie tussen Beschikbaarheidszones is niet hetzelfde in alle Azure-regio's. In sommige gevallen kunt u de SAP-toepassingslaag implementeren en uitvoeren in verschillende zones, omdat de netwerklatentie van de ene 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-toepassingsin exemplaar, wanneer deze is geïmplementeerd in verschillende zones, mogelijk niet acceptabel voor SAP-bedrijfsprocessen. In dergelijke gevallen moet de implementatiearchitectuur anders zijn, met een actief/actief-architectuur voor de toepassing of een actief/passief-architectuur waarbij de netwerklatentie tussen zones te hoog is.
• Bij het bepalen waar u Beschikbaarheidszones gebruiken, moet u uw beslissing baseren op de netwerklatentie tussen de zones. Netwerklatentie speelt een belangrijke rol op twee gebieden:
  • Latentie tussen de twee DBMS-exemplaren die synchrone replicatie moeten hebben. Hoe hoger de netwerklatentie, hoe groter de kans dat deze van invloed is op de schaalbaarheid van uw workload.
  • Het verschil in netwerklatentie tussen een VM met een SAP-dialoogvenster-exemplaar in de zone met het actieve DBMS-exemplaar en een vergelijkbare VM in een andere zone. Naarmate dit verschil toeneemt, neemt ook de invloed op de lopende tijd van bedrijfsprocessen en batchtaken toe, afhankelijk van of ze worden uitgevoerd in de zone met de DBMS of in een andere zone.

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

• U moet Azure Managed Disks gebruiken wanneer u implementeert in Azure-beschikbaarheidszones.
• De toewijzing van zone-inventarisaties aan de fysieke zones wordt vastgelegd 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.
• U kunt geen Azure-beschikbaarheidssets implementeren binnen een Azure-beschikbaarheidszone, tenzij u Azure Proximity Placement Group gebruikt. De manier waarop u de SAP DBMS-laag en de centrale services in zones kunt implementeren en tegelijkertijd de SAP-toepassingslaag kunt implementeren met behulp van beschikbaarheidssets en nog steeds dicht bij de VM's kunt komen, wordt beschreven in het artikel Azure Proximity Placement Groups for optimal network latency with SAP applications (Azure Proximity Placement Groups voor optimale netwerklatentiemet SAP-toepassingen). Als u geen Azure-nabijheidsplaatsingsgroepen gebruikt, moet u een van de twee kiezen als implementatie-framework voor virtuele machines.
• U kunt geen Azure Basic-Load Balancer 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 wilt implementeren in zones, zijn er twee belangrijke architecturen die u kunt implementeren:

• Actief/actief: Het paar VM's met ASCS/SCS en het paar VM's met de DBMS-laag worden verdeeld over twee zones. Het aantal VM's met de SAP-toepassingslaag wordt geïmplementeerd op even getallen in dezelfde twee zones. Als voor een DBMS- of ASCS/SCS-VM een fout wordt gebruikt, kunnen sommige van de geopende en actieve transacties worden teruggedraaid. Maar gebruikers blijven aangemeld. Het maakt niet echt uit in welke zones de actieve DBMS-VM en de toepassings-exemplaren worden uitgevoerd. Deze architectuur is de voorkeursarchitectuur voor implementatie in meerdere zones.
• Actief/passief: Het paar VM's met ASCS/SCS en het paar VM's met de DBMS-laag worden verdeeld over twee zones. Het aantal VM's met de SAP-toepassingslaag wordt geïmplementeerd in een van de Beschikbaarheidszones. U kunt de toepassingslaag uitvoeren 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 voor een ASCS/SCS- of DBMS-VM een fout naar de secundaire zone wordt overgezet, kan er een hogere netwerklatentie zijn en daarmee de doorvoer worden verlaagd. En u moet zo snel mogelijk een failback van de eerder mislukte VM maken om terug te gaan naar de vorige doorvoerniveaus. Als er een zone-uitval optreedt, moet voor de toepassingslaag een failed over worden uitgevoerd 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 deze wilt Beschikbaarheidszones. Als u de mogelijke impact van een ASCS-/SCS- of DBMS-VM die een failing overzet naar de secundaire zone niet kunt accepteren, is het wellicht beter om bij de implementaties van beschikbaarheidssets te blijven

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

• De netwerklatentie tussen de drie zones van een Azure-regio. Als u weet wat de netwerklatentie tussen de zones van een regio is, kunt u de zones kiezen met de minste netwerklatentie in netwerkverkeer tussen zones.
• Het verschil tussen VM-naar-VM-latentie binnen een van de zones naar keuze en de netwerklatentie in twee zones van uw keuze.
• Bepalen of de VM-typen die u moet implementeren, beschikbaar zijn in de twee zones die u hebt geselecteerd. Bij sommige VM's, met name VM's uit de M-serie, kunnen er situaties ontstaan waarin sommige SKU's slechts in twee van de drie zones beschikbaar zijn.

Netwerklatentie tussen en binnen zones

Om de latentie tussen de verschillende zones te 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 neemt.
• 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 toepassingslaag-VM voor de drie Beschikbaarheidszones. Meet de netwerklatentie ten opzichte van de twee DBMS-VM's in de twee DBMS-zones die u hebt geselecteerd.
• Gebruiken niping als meethulpprogramma. Dit hulpprogramma van SAP wordt beschreven in SAP-ondersteuningsnotities #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 aan deze niet te gebruiken.

U hoeft deze tests niet handmatig uit te voeren. U vindt een PowerShell-procedure Beschikbaarheidszonelatentietest die de beschreven latentietests automatiseert.

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 uw actieve SAP-toepassingslaag wilt distribueren over één, twee of alle drie zones, op basis van verschillen in netwerklatentie in de zone versus tussen zones.
• Bepaal of u een actief/passief-configuratie of een actief/actief-configuratie wilt implementeren vanuit het oogpunt van de toepassing. (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-notitie #1100926.

Actieve/actieve implementatie

Deze implementatiearchitectuur wordt actief/actief genoemd omdat u uw actieve SAP-toepassingsservers implementeert in twee of drie zones. Het SAP Central Services-exemplaar dat gebruikmaakt van enqueue-replicatie 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 zijn voor uw workload en uw synchrone DBMS-replicatie. U wilt er ook zeker van zijn dat de delta tussen netwerklatentie binnen de zones die u hebt geselecteerd en de netwerklatentie tussen 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 toepassingsinstellingen. Het neveneffect van dit feit met de actieve/actieve implementatie is dat batchtaken kunnen worden uitgevoerd door alle exemplaren van SAP-toepassingen, onafhankelijk van het feit 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 netwerklatentie binnen een zone, is het verschil in run times van batchtaken mogelijk niet significant. Hoe groter het verschil in netwerklatentie binnen een zone in vergelijking met het netwerkverkeer in de zone is, kan de uitvoering van batchtaken echter meer 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 run time zijn. En daarmee is de toegestane netwerklatentie voor verkeer in verschillende zones.

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

• VS - west 2 (alle drie zones)
• VS - oost 2 (alle drie zones)
• VS - centraal (alle drie zones)
• Europa - noord (alle drie zones)
• Europa - west (twee van de drie zones)
• VS - oost (twee van de drie zones)
• VS - zuid-centraal (twee van de drie zones)
• VK - zuid (twee van de drie zones)
• Azië - zuidoost

Azure-regio's waar deze SAP-implementatiearchitectuur tussen zones niet wordt aanbevolen, zijn:

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

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

Een vereenvoudigd schema van een actief/actief-implementatie in twee zones kan er als volgende uitzien:

De volgende overwegingen zijn van toepassing op deze configuratie:

• Als u geen Azure-nabijheidsplaatsingsgroep gebruikt, behandelt u de Azure-beschikbaarheidszones als fout- en updatedomeinen voor alle VM's, omdat beschikbaarheidssets niet kunnen worden geïmplementeerd in Azure-beschikbaarheidszones.
• Als u de meest geografische implementaties voor de DBMS-laag en centrale services wilt combineren, maar azure-beschikbaarheidssets wilt gebruiken voor de toepassingslaag, moet u Azure-nabijheidsgroepen gebruiken zoals beschreven in het artikel Azure Proximity Placement Groups for optimal network latency with SAP applications (Azure-nabijheidsplaatsingsgroepenvoor optimale netwerklatentie met SAP-toepassingen).
• Voor de load balancers van de failoverclusters van SAP Central Services en de DBMS-laag moet u de Standard-SKU gebruiken Azure Load Balancer. De Basic Load Balancer werkt niet in meerdere zones.
• Het virtuele Azure-netwerk dat u hebt geïmplementeerd voor het hosten van het SAP-systeem, samen met de subnetten ervan, is verspreid over zones. U hebt geen afzonderlijke virtuele netwerken voor elke zone nodig.
• Voor alle virtuele machines die u implementeert, moet u Azure Managed Disks. Niet-beheerde schijven worden niet ondersteund voornale implementaties.
• Azure Premium Storage, Ultra - SSD opslagof ANF bieden geen ondersteuning voor opslagreplicatie tussen zones. De toepassing (DBMS of SAP Central Services) moet belangrijke gegevens repliceren.
• Hetzelfde geldt voor de gedeelde sapmnt-map, een gedeelde schijf (Windows), een CIFS-share (Windows) of een NFS-share (Linux). U moet een technologie gebruiken die deze gedeelde schijven of shares repliceert tussen de zones. Deze technologieën worden ondersteund:

  • Bijvoorbeeld Windows een clusteroplossing die gebruikmaakt van SIOS DataKeeper, zoals beschreven in Cluster an SAP ASCS/SCS instance on a Windows failover cluster by using a cluster shared disk in Azure (Een SAP ASCS/SCS-exemplaar op een Windows-failoverclusterclusteren met behulp van een gedeelde clusterschijf in Azure).

  • Voor SUSE Linux is een NFS-share die is gebouwd zoals beschreven in Hoge beschikbaarheid voor NFS op Azure-VM's op SUSE Linux Enterprise Server.

    Op dit moment wordt de oplossing die gebruikmaakt van Microsoft Scale-Out-bestandsserver, zoals beschreven in Azure-infrastructuur voorbereiden voor hoge beschikbaarheid van SAP met behulp van een Windows-failovercluster en een bestands share voor SAP ASCS/SCS-exemplaren,niet ondersteund in verschillende zones.

• 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 toepassings instances.
• Als u run time-consistentie wilt bereiken voor kritieke bedrijfsprocessen, kunt u proberen om bepaalde batchtaken en gebruikers door te sturen naar toepassingsprocessen die zich in de zone met het actieve DBMS-exemplaar bevindt met behulp van SAP Batch-servergroepen, SAP-aanmeldingsgroepen of RFC-groepen. In het geval van een zonelijke failover moet u deze groepen echter handmatig verplaatsen naar exemplaren die worden uitgevoerd op VM's die zich in de zone met de actieve db-VM bevindt.
• Mogelijk wilt u in elk van de zones in een inactief dialoogvenster implementeren.

Actieve/passieve implementatie

Als u geen acceptabele delta kunt vinden tussen de netwerklatentie binnen één zone en de latentie van netwerkverkeer tussen meerdere zones, kunt u een architectuur implementeren met een actief/passief-teken vanuit het oogpunt van de SAP-toepassingslaag. U definieert een actieve zone. Dit is de zone waar u de volledige toepassingslaag implementeert en waar u zowel het actieve DBMS als het SAP Central Services-exemplaar probeert uit te voeren. Met een dergelijke configuratie moet u ervoor zorgen dat er geen extreme run time-variaties zijn, 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 mogelijk de voorkeur heeft, zijn:

• Australië - oost
• Brazilië - zuid
• Duitsland - west-centraal
• Zuid-Afrika - noord
• Frankrijk - centraal
• Canada - midden
• Japan - oost

De basisindeling van de architectuur ziet er als volgende uit:

De volgende overwegingen zijn van toepassing op deze configuratie:

• Beschikbaarheidssets kunnen niet worden geïmplementeerd in Azure-beschikbaarheidszones. Ter compensatie hiervoor kunt u Azure-nabijheidsplaatsingsgroepen gebruiken, zoals beschreven in het artikel Azure Proximity Placement Groups (Nabijheidsplaatsingsgroepen) voor optimale netwerklatentie met SAP-toepassingen.

• Wanneer u deze architectuur gebruikt, moet u de status nauwkeurig bewaken en de actieve DBMS- en SAP Central Services-instanties in dezelfde zone houden als de geïmplementeerde toepassingslaag. In het geval van een failover van de SAP Central-service of het DBMS-exemplaar, moet u ervoor zorgen dat u handmatig een failback naar de zone kunt toepassen terwijl de SAP-toepassingslaag 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 gebruiken Azure Load Balancer. De Basic Load Balancer werkt niet in meerdere zones.

• Het virtuele Azure-netwerk dat u hebt geïmplementeerd voor het hosten van het SAP-systeem, samen met de subnetten ervan, is verspreid over zones. U hebt geen afzonderlijke virtuele netwerken voor elke zone nodig.

• Voor alle virtuele machines die u implementeert, moet u Azure Managed Disks. Niet-beheerde schijven worden niet ondersteund voornale implementaties.

• Azure Premium Storage, Ultra - SSD opslagof ANF bieden geen ondersteuning voor opslagreplicatie tussen zones. De toepassing (DBMS of SAP Central Services) moet belangrijke gegevens repliceren.

• Hetzelfde geldt voor de gedeelde sapmnt-map, een gedeelde schijf (Windows), een CIFS-share (Windows) of een NFS-share (Linux). U moet een technologie gebruiken die deze gedeelde schijven of shares repliceert tussen de zones. Deze technologieën worden ondersteund:

  • Bijvoorbeeld Windows een clusteroplossing die gebruikmaakt van SIOS DataKeeper, zoals beschreven in Cluster an SAP ASCS/SCS instance on a Windows failover cluster by using a cluster shared disk in Azure (Een SAP ASCS/SCS-exemplaar op een Windows-failoverclusterclusteren met behulp van een gedeelde clusterschijf in Azure).
  • Voor SUSE Linux is een NFS-share die is gebouwd zoals beschreven in Hoge beschikbaarheid voor NFS op Azure-VM's op SUSE Linux Enterprise Server.

  Op dit moment wordt de oplossing die gebruikmaakt van Microsoft Scale-Out-bestandsserver, zoals beschreven in Azure-infrastructuur voorbereiden voor hoge beschikbaarheid van SAP met behulp van een Windows-failovercluster en een bestands share voor SAP ASCS/SCS-exemplaren,niet ondersteund in verschillende zones.

• 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 toepassings instances.

• U moet actieve VM's implementeren in de passieve zone (vanuit het oogpunt van DBMS), zodat u toepassingsresources kunt starten voor het geval van een zonefout.

  • Azure Site Recovery kan momenteel geen actieve VM's repliceren naar niet-actieve VM's tussen zones.

• U moet investeren in automatisering waarmee u automatisch de SAP-toepassingslaag in de tweede zone kunt starten als er een zone-uitval optreedt.

Gecombineerde configuratie voor hoge beschikbaarheid en herstel na noodherstel

Microsoft deelt geen informatie over geografische afstanden tussen de faciliteiten die verschillende locaties Azure-beschikbaarheidszones in een Azure-regio. Toch gebruiken sommige klanten zones voor een gecombineerde ha- en DR-configuratie die een RPO (Recovery Point Objective) van nul belooft. Een RPO van nul betekent dat u geen vastgelegde databasetransacties mag verliezen, zelfs niet in het geval van herstel na noodgeval.

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

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 voor een beschikbaarheidszone worden gebruikt, of u bent gedwongen om binnen een bepaalde Azure-regio te blijven. Beschikbaarheidssets kunnen niet worden geïmplementeerd in Azure-beschikbaarheidszones. Ter compensatie hiervoor kunt u Azure-nabijheidsplaatsingsgroepen gebruiken, zoals beschreven in het artikel Azure Proximity Placement Groups (Nabijheidsplaatsingsgroepen) voor optimale netwerklatentie met SAP-toepassingen.

• Wanneer u deze architectuur gebruikt, moet u de status nauwkeurig bewaken en de actieve DBMS- en SAP Central Services-instanties in dezelfde zone houden als de geïmplementeerde toepassingslaag. In het geval van een failover van de SAP Central-service of het DBMS-exemplaar, moet u ervoor zorgen dat u handmatig een failback naar de zone kunt toepassen terwijl de SAP-toepassingslaag zo snel mogelijk is geïmplementeerd.

• U moet exemplaren van productie-toepassingen vooraf hebben geïnstalleerd in de VM's die de actieve QA-toepassingsprocessen uitvoeren.

• Sluit in een geval van een 'nale fout' de EXEMPLAREN van de QA-toepassing af en start in plaats daarvan de productie-exemplaren. U moet virtuele namen gebruiken voor de exemplaren van de toepassing 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 gebruiken Azure Load Balancer. De Basic Load Balancer werkt niet in meerdere zones.

• Het virtuele Azure-netwerk dat u hebt geïmplementeerd voor het hosten van het SAP-systeem, samen met de subnetten ervan, is verspreid over zones. U hebt geen afzonderlijke virtuele netwerken nodig voor elke zone.

• Voor alle virtuele machines die u implementeert, moet u Azure Managed Disks. Niet-beheerde schijven worden niet ondersteund voornale implementaties.

• Azure Premium Storage en Ultra - SSD bieden geen ondersteuning voor opslagreplicatie tussen zones. De toepassing (DBMS of SAP Central Services) moet belangrijke gegevens repliceren.

• Hetzelfde geldt voor de gedeelde sapmnt-map, een gedeelde schijf (Windows), een CIFS-share (Windows) of een NFS-share (Linux). U moet een technologie gebruiken die deze gedeelde schijven of shares repliceert tussen de zones. Deze technologieën worden ondersteund:

  • Bijvoorbeeld Windows een clusteroplossing die gebruikmaakt van SIOS DataKeeper, zoals beschreven in Cluster an SAP ASCS/SCS instance on a Windows failover cluster by using a cluster shared disk in Azure (Een SAP ASCS/SCS-exemplaar op een Windows-failoverclusterclusteren met behulp van een gedeelde clusterschijf in Azure).
  • Voor SUSE Linux is een NFS-share gebouwd zoals beschreven in Hoge beschikbaarheid voor NFSop Virtuele Azure-SUSE Linux Enterprise Server.

  Op dit moment wordt de oplossing die gebruikmaakt van Microsoft Scale-Out-bestandsserver, zoals beschreven in Azure-infrastructuur voorbereiden voor hoge beschikbaarheid van SAP met behulp van een Windows-failovercluster en een bestands share voor SAP ASCS/SCS-exemplaren,niet ondersteund in meerdere zones.

• 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:

• Een SAP ASCS/SCS-exemplaar clusteren op een Windows failovercluster met behulp van een gedeelde clusterschijf in Azure
• Azure-infrastructuur voorbereiden voor sap met hoge beschikbaarheid met behulp van een Windows failovercluster en bestands share voor SAP ASCS/SCS-exemplaren