Gebruik het opnieuw opstarten van azure-infrastructuur-VM's om een 'hogere beschikbaarheid' van een SAP-systeem te bereiken

  • Artikel

Deze sectie is van toepassing op:

Windows logo. Windows en Linux logo. Linux

Als u besluit geen functionaliteiten te gebruiken, zoals Windows Server Failover Clustering (WSFC) of Pacemaker op Linux (momenteel alleen ondersteund voor SUSE Linux Enterprise Server [SLES] 12 en hoger), wordt opnieuw opstarten van azure-VM gebruikt. Het beveiligt SAP-systemen tegen geplande en ongeplande downtime van de fysieke Azure-serverinfrastructuur en het algehele onderliggende Azure-platform.

Notitie

Azure VM opnieuw opstarten beveiligt voornamelijk VM's en niet toepassingen. Hoewel het opnieuw opstarten van vm's geen hoge beschikbaarheid biedt voor SAP-toepassingen, biedt het wel een bepaald niveau van beschikbaarheid van de infrastructuur. Het biedt ook indirect "hogere beschikbaarheid" van SAP-systemen. Er is ook geen SLA voor de tijd die nodig is om een VIRTUELE machine opnieuw op te starten na een geplande of niet-geplande hoststoring, waardoor deze methode van hoge beschikbaarheid ongeschikt is voor de kritieke onderdelen van een SAP-systeem. Voorbeelden van kritieke onderdelen zijn mogelijk een ASCS/SCS-exemplaar of een databasebeheersysteem (DBMS).

Een ander belangrijk infrastructuurelement voor hoge beschikbaarheid is opslag. De SLA voor Azure Storage is bijvoorbeeld 99,9% beschikbaarheid. Als u alle VM's en de bijbehorende schijven in één Azure-opslagaccount implementeert, zorgt mogelijke niet-beschikbaarheid van Azure Storage ervoor dat alle VM's die in dat opslagaccount worden geplaatst en alle SAP-onderdelen die binnen de VM's worden uitgevoerd, niet beschikbaar zijn.

In plaats van alle VM's in één Azure-opslagaccount te plaatsen, kunt u toegewezen opslagaccounts voor elke virtuele machine gebruiken. Door meerdere onafhankelijke Azure-opslagaccounts te gebruiken, verhoogt u de algehele beschikbaarheid van VM's en SAP-toepassingen.

Azure Managed Disks worden automatisch in het foutdomein geplaatst van de virtuele machine waaraan ze zijn gekoppeld. Als u twee virtuele machines in een beschikbaarheidsset plaatst en beheerde schijven gebruikt, zorgt het platform er ook voor dat de beheerde schijven worden gedistribueerd naar verschillende foutdomeinen. Als u van plan bent een Premium Storage-account te gebruiken, raden we u ten zeerste aan beheerde schijven te gebruiken.

Een voorbeeldarchitectuur van een SAP NetWeaver-systeem dat gebruikmaakt van hoge beschikbaarheid van Azure-infrastructuur en opslagaccounts, kan er als volgt uitzien:

Diagram that shows the architecture of an SAP NetWeaver system that uses Azure infrastructure high availability and storage accounts.

Een voorbeeldarchitectuur van een SAP NetWeaver-systeem dat gebruikmaakt van hoge beschikbaarheid van azure-infrastructuur en beheerde schijven kan er als volgt uitzien:

Utilize Azure infrastructure high availability to achieve SAP application “higher availability

Voor essentiële SAP-onderdelen hebt u tot nu toe het volgende bereikt:

  • Hoge beschikbaarheid van SAP-toepassingsservers

    SAP-toepassingsserverexemplaren zijn redundante onderdelen. Elk EXEMPLAAR van de SAP-toepassingsserver wordt geïmplementeerd op een eigen VM, die wordt uitgevoerd in een ander Azure-fout- en upgradedomein. Zie de secties Foutdomeinen en Update-domeinen voor meer informatie.

    U kunt deze configuratie controleren met behulp van Azure-beschikbaarheidssets. Zie de sectie Azure-beschikbaarheidssets voor meer informatie.

    Mogelijke geplande of niet-geplande niet-beschikbaarheid van een Azure-fout of upgradedomein zorgt ervoor dat een beperkt aantal VM's met hun SAP-toepassingsserverexemplaren niet beschikbaar is.

    Elk SAP-toepassingsserverexemplaren wordt in een eigen Azure-opslagaccount geplaatst. De mogelijke onbeschikbaarheid van één Azure-opslagaccount zorgt ervoor dat slechts één VIRTUELE machine met het SAP-toepassingsserverexemplaren niet beschikbaar is. Houd er echter rekening mee dat er een limiet is voor het aantal Azure-opslagaccounts binnen één Azure-abonnement. Als u ervoor wilt zorgen dat een ASCS/SCS-exemplaar automatisch wordt gestart nadat de VM opnieuw is opgestart, stelt u de parameter AutoStart in het startprofiel van het ASCS/SCS-exemplaar in.

    Zie Hoge beschikbaarheid voor SAP-toepassingsservers voor meer informatie.

    Zelfs als u beheerde schijven gebruikt, worden de schijven opgeslagen in een Azure-opslagaccount en zijn ze mogelijk niet beschikbaar in het geval van een opslagstoring.

  • Hogere beschikbaarheid van SAP ASCS/SCS-exemplaren

    In dit scenario gebruikt u azure VM opnieuw opstarten om de VIRTUELE machine te beveiligen met het geïnstalleerde SAP ASCS/SCS-exemplaar. In het geval van geplande of ongeplande downtime van Azure-servers, worden VM's opnieuw opgestart op een andere beschikbare server. Zoals eerder vermeld, beveiligt Azure VM opnieuw opstarten voornamelijk VM's en niet toepassingen, in dit geval de ASCS/SCS-instantie. Door het opnieuw opstarten van de VIRTUELE machine bereikt u indirect een hogere beschikbaarheid van het SAP ASCS/SCS-exemplaar.

    Als u ervoor wilt zorgen dat het ASCS/SCS-exemplaar automatisch wordt gestart nadat de VM opnieuw is opgestart, stelt u de parameter AutoStart in het startprofiel van het ASCS/SCS-exemplaar in. Deze instelling betekent dat het ASCS/SCS-exemplaar als een single point of failure (SPOF) dat wordt uitgevoerd op één VIRTUELE machine, de beschikbaarheid van het hele SAP-landschap bepaalt.

  • Hogere beschikbaarheid van de DBMS-server

    Net als in het voorgaande gebruiksscenario voor SAP ASCS/SCS-exemplaren gebruikt u het opnieuw opstarten van azure-VM's om de VIRTUELE machine te beveiligen met geïnstalleerde DBMS-software en bereikt u 'hogere beschikbaarheid' van DBMS-software door VM opnieuw op te starten.

    Een DBMS die wordt uitgevoerd op één VIRTUELE machine is ook een SPOF en het is de bepalende factor voor de beschikbaarheid van het hele SAP-landschap.

Autostart gebruiken voor SAP-exemplaren

SAP biedt een instelling waarmee u SAP-exemplaren direct na het starten van het besturingssysteem binnen de VIRTUELE machine kunt starten. De instructies worden beschreven in het SAP Knowledge Base-artikel 1909114. Sap raadt het gebruik van de instelling echter niet meer aan, omdat hiermee de controle over de volgorde van het opnieuw opstarten van exemplaren niet is toegestaan als er meerdere VM's worden beïnvloed of als er meerdere exemplaren per VM worden uitgevoerd.

Ervan uitgaande dat een typisch Azure-scenario van één SAP-toepassingsserverexemplaren in een VIRTUELE machine en één VM uiteindelijk opnieuw wordt opgestart, is Autostart niet essentieel. U kunt deze echter inschakelen door de volgende parameter toe te voegen aan het beginprofiel van het ABAP-exemplaar (SAP Advanced Business Application Programming) of Java-exemplaar:

Autostart = 1

Notitie

De parameter Autostart heeft ook bepaalde tekortkomingen. Met name de parameter activeert het begin van een SAP ABAP- of Java-exemplaar wanneer de gerelateerde Windows- of Linux-service van het exemplaar wordt gestart. Deze volgorde vindt plaats wanneer het besturingssysteem wordt opgestart. Het opnieuw opstarten van SAP-services is echter ook gebruikelijk voor sap-softwarelevenscyclusbeheerfunctionaliteit, zoals Software Update Manger (SUM) of andere updates of upgrades. Deze functies verwachten niet dat een exemplaar automatisch opnieuw wordt opgestart. Daarom moet de parameter Autostart worden uitgeschakeld voordat u dergelijke taken uitvoert. De parameter Autostart mag ook niet worden gebruikt voor SAP-exemplaren die zijn geclusterd, zoals ASCS/SCS/CI.

Zie de volgende artikelen voor meer informatie over Autostart voor SAP-exemplaren:

Volgende stappen

Zie hoge beschikbaarheid van SAP-toepassingen in Azure IaaS voor informatie over volledige hoge beschikbaarheid van SAP NetWeaver-toepassingen.