Architectuur en scenario's voor hoge beschikbaarheid voor SAP NetWeaver
Terminologiedefinities
Hoge beschikbaarheid: verwijst naar een set technologieën die IT-onderbrekingen minimaliseren door bedrijfscontinuïteit van IT-services te bieden via redundante, fouttolerante of met failover beveiligde onderdelen binnen hetzelfde datacenter. In ons geval bevindt het datacenter zich binnen één Azure-regio.
Herstel na noodherstel: verwijst ook naar het minimaliseren van onderbrekingen van IT-services en hun herstel, maar in verschillende datacenters die mogelijk op honderden kilometers van elkaar zijn verwijderd. In ons geval bevinden de datacenters zich mogelijk in verschillende Azure-regio's binnen dezelfde geopolitieke regio of op locaties die door u als klant zijn ingesteld.
Overzicht van hoge beschikbaarheid
Sap hoge beschikbaarheid in Azure kan worden gescheiden in drie typen:
Hoge beschikbaarheid van Azure-infrastructuur:
Een hoge beschikbaarheid kan bijvoorbeeld rekenkracht (VM's), netwerk of opslag omvatten en de voordelen ervan voor het vergroten van de beschikbaarheid van SAP-toepassingen.
Gebruik van het opnieuw opstarten van de Azure-infrastructuur-VM om een hogere beschikbaarheid van SAP-toepassingen te bereiken:
Als u besluit geen gebruik te maken van functies zoals Windows Server Failover Clustering (WSFC) of Pacemaker op Linux, wordt opnieuw opstarten van azure-VM's gebruikt. Het beschermt SAP-systemen tegen geplande en ongeplande downtime van de fysieke Server-infrastructuur van Azure en het algehele onderliggende Azure-platform.
Hoge beschikbaarheid van SAP-toepassing:
Voor een volledige hoge beschikbaarheid van het SAP-systeem moet u alle kritieke SAP-systeemonderdelen beveiligen. Bijvoorbeeld:
- Redundante SAP-toepassingsservers.
- Unieke onderdelen. Een voorbeeld hiervan is een SPOF-onderdeel (Single Point of Failure), zoals een SAP ASCS/SCS-exemplaar of een DATABASE Management System (DBMS).
Hoge beschikbaarheid van SAP in Azure wijkt af van SAP hoge beschikbaarheid in een on-premises fysieke of virtuele omgeving. In het volgende document SAP NetWeaver hoge beschikbaarheid en bedrijfscontinuïteit in virtuele omgevingen met VMware en Hyper-V op Microsoft Windows worden standaardconfiguraties voor SAP-hoge beschikbaarheid in gevirtualiseerde omgevingen op Windows.
Er is geen sapinst-geïntegreerde SAP-configuratie voor hoge beschikbaarheid voor Linux, aangezien er voor Windows. Zie Partnerinformatie voor hoge beschikbaarheid voor informatie over SAP hoge beschikbaarheid on-premises voorLinux.
Hoge beschikbaarheid van Azure-infrastructuur
SLA voor virtuele machines met één exemplaar
Er is momenteel een SLA voor één VM van 99,9% met Premium-opslag. Als u een idee wilt krijgen van de beschikbaarheid van één VM, kunt u het product bouwen van de verschillende beschikbare Azure Service Level Agreements.
De basis voor de berekening is 30 dagen per maand of 43.200 minuten. Een downtime van 0,05% komt bijvoorbeeld overeen met 21,6 minuten. Zoals gebruikelijk wordt de beschikbaarheid van de verschillende services op de volgende manier berekend:
(Availability Service #1/100) * (Availability Service #2/100) * (Availability Service #3/100) * ...
Bijvoorbeeld:
(99,95/100) * (99,9/100) * (99,9/100) = 0,9975 of een algemene beschikbaarheid van 99,75%.
Meerdere exemplaren van virtuele machines in dezelfde beschikbaarheidsset
Voor alle virtuele machines met twee of meer exemplaren die zijn geïmplementeerd in dezelfde beschikbaarheidsset, garanderen we dat u ten minste 99,95% van de tijd verbinding hebt met een virtuele machine met ten minste één exemplaar.
Wanneer twee of meer VM's deel uitmaken van dezelfde beschikbaarheidsset, wordt aan elke virtuele machine in de beschikbaarheidsset een updatedomein en een foutdomein toegewezen door het onderliggende Azure-platform.
Updatedomeinen garanderen dat meerdere VM's niet tegelijkertijd opnieuw worden opgestart tijdens het geplande onderhoud van een Azure-infrastructuur. Er wordt slechts één VM tegelijk opnieuw opgestart.
Foutdomeinen garanderen dat VM's worden geïmplementeerd op hardwareonderdelen die geen gemeenschappelijke voedingsbron en netwerks switch delen. Wanneer servers, een netwerks switch of een voedingsbron een ongeplande downtime ondergaan, wordt slechts één VM beïnvloed.
Zie Manage the availability of Windows virtual machines in Azure (De beschikbaarheid van virtuele machines in Azure beheren) voor meer informatie.
Een beschikbaarheidsset wordt gebruikt voor het bereiken van hoge beschikbaarheid van:
- Redundante SAP-toepassingsservers.
- Clusters met twee of meer knooppunten (bijvoorbeeld VM's) die SPOF's beveiligen, zoals een SAP ASCS/SCS-exemplaar of een DBMS.
Azure-beschikbaarheidszones
Azure is bezig met het uitrollen van concepten van Azure-beschikbaarheidszones in verschillende Azure-regio's. In Azure-regio'Beschikbaarheidszones worden aangeboden, hebben de Azure-regio's meerdere datacenters, die onafhankelijk zijn van de voeding, koeling en het netwerk. De reden voor het aanbieden van verschillende zones binnen één Azure-regio is dat u toepassingen kunt implementeren op twee of drie Beschikbaarheidszones aangeboden. Ervan uitgaande dat problemen in energiebronnen en/of het netwerk alleen van invloed zijn op één infrastructuur van de beschikbaarheidszone, is de implementatie van uw toepassing in een Azure-regio nog steeds volledig functioneel. Uiteindelijk met een beperkte capaciteit, omdat sommige VM's in één zone verloren kunnen gaan. Maar VM's in de andere twee zones zijn nog steeds actief. De Azure-regio's met zones worden vermeld in Azure-beschikbaarheidszones.
Met Beschikbaarheidszones zijn er een aantal dingen om rekening mee te houden. De lijst met overwegingen is als:
- U kunt Azure-beschikbaarheidssets niet implementeren binnen een beschikbaarheidszone. U moet een beschikbaarheidszone of een beschikbaarheidsset kiezen als implementatieframe voor een VM.
- U kunt de Basic-Load Balancer gebruiken om failoverclusteroplossingen te maken op basis van Windows failoverclusterservices of Linux Pacemaker. In plaats daarvan moet u de Azure Standard Load Balancer SKU gebruiken
- Azure-beschikbaarheidszones geven geen garanties voor een bepaalde afstand tussen de verschillende zones binnen één regio
- De netwerklatentie tussen verschillende Azure-beschikbaarheidszones binnen de verschillende Azure-regio's kan per Azure-regio verschillen. Er zijn gevallen waarin u als klant de SAP-toepassingslaag die is geïmplementeerd in verschillende zones redelijk kan uitvoeren, omdat de netwerklatentie van de ene zone naar de actieve DBMS-VM nog steeds acceptabel is als het gaat om het bedrijfsproces. Terwijl er klantscenario's zijn waarbij de latentie tussen de actieve DBMS-VM in de ene zone en een EXEMPLAAR van een SAP-toepassing in een VM in een andere zone te ingrijpende en niet acceptabel kan zijn voor de SAP-bedrijfsprocessen. Als gevolg hiervan moeten de implementatiearchitectarchitectuur verschillen met een actief/actief-architectuur voor de toepassing of een actieve/passieve architectuur als de latentie te hoog is.
- Het gebruik van beheerde Azure-schijven is verplicht voor implementatie in Azure-beschikbaarheidszones
Gepland en ongepland onderhoud van virtuele machines
Twee typen gebeurtenissen van het Azure-platform kunnen van invloed zijn op de beschikbaarheid van uw virtuele machines:
Geplande onderhoudsgebeurtenissen zijn periodieke updates die door Microsoft worden uitgevoerd op het onderliggende Azure-platform. De updates verbeteren de algehele betrouwbaarheid, prestaties en beveiliging van de platforminfrastructuur waarop uw virtuele machines worden uitgevoerd.
Niet-geplande onderhoudsgebeurtenissen treden op wanneer de hardware of fysieke infrastructuur die onderliggend is op uw virtuele machine, op een of andere manier is mislukt. Het kan gaan om lokale netwerkfouten, lokale schijffouten of andere storingen op rackniveau. Wanneer een dergelijke fout wordt gedetecteerd, migreert het Azure-platform uw virtuele machine automatisch van de slechte fysieke server die als host voor uw virtuele machine wordt gebruikt, naar een gezonde fysieke server. Dergelijke gebeurtenissen zijn zeldzaam, maar ze kunnen er ook toe leiden dat uw virtuele machine opnieuw wordt opgestart.
Zie Manage the availability of Windows virtual machines in Azure (De beschikbaarheid van virtuele machines in Azure beheren) voor meer informatie.
Azure Storage-redundantie
De gegevens in uw opslagaccount worden altijd gerepliceerd om duurzaamheid en hoge beschikbaarheid te garanderen, en voldoen aan de Azure Storage SLA, zelfs bij tijdelijke hardwarefouten.
Omdat Azure Storage standaard drie afbeeldingen van de gegevens bewaart, is het gebruik van RAID 5 of RAID 1 op meerdere Azure-schijven niet nodig.
Zie Azure Storage-replicatie voor meer informatie.
Azure Managed Disks
Managed Disks is een resourcetype in Azure Resource Manager dat wordt aanbevolen om te worden gebruikt in plaats van virtuele harde schijven (VHD's) die zijn opgeslagen in Azure-opslagaccounts. Beheerde schijven worden automatisch uitgelijnd met een Azure-beschikbaarheidsset van de virtuele machine waar ze aan zijn gekoppeld. Ze verhogen de beschikbaarheid van uw virtuele machine en de services die erop worden uitgevoerd.
Zie Overzicht van Azure Managed Disks voor meer informatie.
U wordt aangeraden beheerde schijven te gebruiken omdat deze de implementatie en het beheer van uw virtuele machines vereenvoudigen.
Hoge beschikbaarheid van Azure-infrastructuur gebruiken om een hogere beschikbaarheid van SAP-toepassingen te bereiken
Als u besluit geen gebruik te maken van functies zoals WSFC of Pacemaker op Linux (momenteel alleen ondersteund voor SUSE Linux Enterprise Server [SLES] 12 en hoger), wordt opnieuw opstarten van azure-VM's gebruikt. Het beschermt SAP-systemen tegen geplande en ongeplande downtime van de fysieke Server-infrastructuur van Azure en het algehele onderliggende Azure-platform.
Zie Voor meer informatie over deze methode, zie Het opnieuw opstarten van de Azure-infrastructuur-VM gebruiken om een hogere beschikbaarheid van het SAP-systeem te bereiken.
Hoge beschikbaarheid van SAP-toepassingen in Azure IaaS
Voor een volledige hoge beschikbaarheid van het SAP-systeem moet u alle kritieke SAP-systeemonderdelen beveiligen. Bijvoorbeeld:
- Redundante SAP-toepassingsservers.
- Unieke onderdelen. Een voorbeeld hiervan is een SPOF-onderdeel (Single Point of Failure), zoals een SAP ASCS/SCS-exemplaar of een DATABASE Management System (DBMS).
In de volgende secties wordt besproken hoe u hoge beschikbaarheid bereikt voor alle drie kritieke SAP-systeemonderdelen.
Architectuur met hoge beschikbaarheid voor SAP-toepassingsservers
Deze sectie is van toepassing op:
Windows en
Linux
Meestal hebt u geen specifieke oplossing voor hoge beschikbaarheid nodig voor de SAP-toepassingsserver en dialoogvensters. U bereikt hoge beschikbaarheid door redundantie en u configureert meerdere dialoogvensters in verschillende exemplaren van virtuele Azure-machines. U moet ten minste twee exemplaren van sap-toepassingen hebben geïnstalleerd in twee exemplaren van virtuele Azure-machines.
Afbeelding 1: SAP-toepassingsserver met hoge beschikbaarheid
U moet alle virtuele machines die exemplaren van SAP-toepassingsservers hosten, in dezelfde Azure-beschikbaarheidsset plaatsen. Een Azure-beschikbaarheidsset zorgt ervoor dat:
Alle virtuele machines maken geen deel uit van hetzelfde updatedomein.
Een updatedomein zorgt ervoor dat de virtuele machines niet tegelijkertijd worden bijgewerkt tijdens de geplande onderhoudsuitvaltijd.De basisfunctionaliteit, die is gebaseerd op verschillende update- en foutdomeinen binnen een Azure-schaaleenheid, is al geïntroduceerd in de sectie updatedomeinen.
Alle virtuele machines maken geen deel uit van hetzelfde foutdomein.
Een foutdomein zorgt ervoor dat virtuele machines worden geïmplementeerd, zodat geen enkel storingspunt van invloed is op de beschikbaarheid van alle virtuele machines.
Het aantal update- en foutdomeinen dat kan worden gebruikt door een Azure-beschikbaarheidsset binnen een Azure-schaaleenheid is eindig. Als u VM's blijft toevoegen aan één beschikbaarheidsset, komen twee of meer VM's uiteindelijk in hetzelfde fout- of updatedomein.
Als u enkele exemplaren van de SAP-toepassingsserver implementeert in hun toegewezen VM's, ervan uitgaande dat we vijf updatedomeinen hebben, ziet u de volgende afbeelding. Het werkelijke maximum aantal update- en foutdomeinen binnen een beschikbaarheidsset kan in de toekomst veranderen:
in een Azure-beschikbaarheidsset
Zie de sectie Azure-beschikbaarheidssets van het document Planning en implementatie van virtuele Azure-machines voor SAP NetWeaver voor meer informatie.
Alleen onmanagede schijven: Omdat het Azure-opslagaccount een potentieel single point of failure is, is het belangrijk om ten minste twee Azure-opslagaccounts te hebben, waarin ten minste twee virtuele machines worden gedistribueerd. In een ideale configuratie worden de schijven van elke virtuele machine met een SAP-dialoogvenster geïmplementeerd in een ander opslagaccount.
Belangrijk
We raden u ten zeerste aan beheerde Azure-schijven te gebruiken voor uw SAP-installaties met hoge beschikbaarheid. Omdat beheerde schijven automatisch worden uitgelijnd met de beschikbaarheidsset van de virtuele machine waar ze aan zijn gekoppeld, verhogen ze de beschikbaarheid van uw virtuele machine en de services die erop worden uitgevoerd.
Architectuur met hoge beschikbaarheid voor een SAP ASCS/SCS-exemplaar op Windows
U kunt een WSFC-oplossing gebruiken om het SAP ASCS/SCS-exemplaar te beveiligen. De oplossing heeft twee varianten:
Het SAP ASCS/SCS-exemplaar clusteren met behulp van geclusterde gedeelde schijven: zie Cluster an SAP ASCS/SCS instance on a Windows failover cluster by using a cluster shared disk (Een SAP ASCS/SCS-exemplaarclusteren op een Windows-failovercluster met behulp van een gedeelde clusterschijf) voor meer informatie over deze architectuur.
Het SAP ASCS/SCS-exemplaar clusteren met behulp van een bestands share : zie Cluster an SAP ASCS/SCS instance on a Windows failover cluster by using file share (Een SAP ASCS/SCS-exemplaarclusteren op een Windows-failovercluster met behulp van bestands share) voor meer informatie over deze architectuur.
Het SAP ASCS/SCS-exemplaar clusteren met anf SMB-share: zie Cluster an SAP ASCS/SCS instance on a Windows failover cluster by using ANF SMB file share (Clusteren van een SAP ASCS/SCS-exemplaar op een Windows-failovercluster met behulp van ANF SMB-bestands share)voor meer informatie over deze architectuur.
Architectuur met hoge beschikbaarheid voor een SAP ASCS/SCS-exemplaar in Linux
Zie Hoge beschikbaarheid voor SAP NetWeaver op azure-VM'sop SUSE Linux Enterprise Server voor SAP-toepassingen voor meer informatie over het clusteren van het SAP ASCS/SCS-exemplaar met behulp van het SLES-cluster framework. Zie handleiding voor hoge beschikbaarheid voor SAP NetWeaver op SUSE Linux Enterprise Server met Azure NetApp Files voor SAP-toepassingen voor alternatieve ha-architectuurop SLES, waarvoor geen NFS met hoge beschikbaarheid is vereist.
Zie Hoge beschikbaarheid van Azure Virtual Machines voor SAP NetWeaver op de Red Hat Enterprise Linux voor meer informatie over het clusteren van het SAP ASCS/SCS-exemplaar met behulp van het Red Hat-cluster framework Red Hat Enterprise Linux
SAP NetWeaver-configuratie met meerdere SID's voor een geclusterd SAP ASCS/SCS-exemplaar
Multi-SID wordt ondersteund met WSFC, met behulp van bestands share en gedeelde schijf.
Zie voor meer informatie over architectuur voor hoge beschikbaarheid met meerdere SID'Windows:
Multi-SID-clustering wordt ondersteund in Linux Pacemaker-clusters voor SAP ASCS/ERS, beperkt tot vijf SAP-SID's op hetzelfde cluster. Zie voor meer informatie over architectuur voor hoge beschikbaarheid met meerdere SID's in Linux:
- Handleiding ha for SAP NW on Azure VMs on SLES for SAP applications multi-SID (Ha voor SAP NW op azure-VM's op SLES voor SAP-toepassingen met meerdere SID's)
- Handleiding ha for SAP NW on Azure VMs on RHEL for SAP applications multi-SID (Ha voor SAP NW op Azure-VM's op RHEL voor SAP-toepassingen met meerdere SID's)
DBMS-exemplaar met hoge beschikbaarheid
De DBMS is ook een enkel contactpunt in een SAP-systeem. U moet deze beveiligen met behulp van een oplossing voor hoge beschikbaarheid. In de volgende afbeelding ziet u een SQL Server AlwaysOn-oplossing met hoge beschikbaarheid in Azure, met Windows Server Failover Clustering en de interne azure-load balancer. SQL Server AlwaysOn repliceert DBMS-gegevens en logboekbestanden met behulp van een eigen DBMS-replicatie. In dit geval hebt u geen gedeelde clusterschijf nodig, waardoor de hele installatie wordt vereenvoudigd.
Afbeelding 3: Voorbeeld van een SAP DBMS met hoge beschikbaarheid, met SQL Server AlwaysOn
Zie de volgende artikelen voor meer informatie SQL Server clustering van DBMS in Azure met behulp van het Azure Resource Manager-implementatiemodel:
Zie Hoge beschikbaarheid van SAP HANA op virtuele Azure-machines (VM's)voor meer informatie over het clusteren van SAP HANA DBMS in Azure met behulp van het Azure Resource Manager-implementatiemodel.