Een SAP ASCS/SCS-exemplaar clusteren op een Windows-failovercluster met behulp van een gedeelde schijf in Azure

  • Artikel

Windows OS Windows

Windows Server Failover Clustering (WSFC) is de basis van een SAP ASCS/SCS-installatie en databasebeheersystemen (DBMSs) met hoge beschikbaarheid (HA) in Windows.

Een failovercluster is een groep van 1+n onafhankelijke servers (knooppunten) die samenwerken om de beschikbaarheid van toepassingen en services te vergroten. Als er een knooppuntfout optreedt, berekent WSFC het aantal fouten dat kan optreden en onderhoudt u nog steeds een gezond cluster om toepassingen en services te leveren. U kunt kiezen uit verschillende quorummodi om failoverclustering te bereiken.

Vereisten

Voordat u met de taken in dit artikel begint, raadpleegt u het artikel Architectuur met hoge beschikbaarheid en scenario's voor SAP NetWeaver.

Windows Server-failoverclustering in Azure

Voor WSFC met virtuele Azure-machines (VM's) zijn aanvullende configuratiestappen vereist. Wanneer u een cluster bouwt, moet u verschillende IP-adressen en virtuele hostnamen instellen voor het SAP ASCS/SCS-exemplaar.

Naamomzetting in Azure en de naam van de virtuele clusterhost

Het Azure-cloudplatform biedt geen optie voor het configureren van virtuele IP-adressen, zoals zwevende IP-adressen. U hebt een alternatieve oplossing nodig om een virtueel IP-adres in te stellen om de clusterresource in de cloud te bereiken.

De Azure Load Balancer-service biedt een interne load balancer voor Azure. Met de interne load balancer bereiken clients het cluster via het virtuele IP-adres van het cluster.

Implementeer de interne load balancer in de resourcegroep die de clusterknooppunten bevat. Configureer vervolgens alle benodigde regels voor port-forwarding met behulp van de testpoorten van de interne load balancer. Clients kunnen verbinding maken via de naam van de virtuele host. De DNS-server lost het IP-adres van het cluster op en de interne load balancer verwerkt poort doorsturen naar het actieve knooppunt van het cluster.

Belangrijk

Zwevende IP-adressen worden niet ondersteund in een secundaire IP-configuratie voor een netwerkadapter (NIC) in scenario's voor taakverdeling. Zie Azure Load Balancer-beperkingen voor meer informatie. Als u een extra IP-adres voor de virtuele machine nodig hebt, implementeert u een tweede NIC.

Diagram of a Windows Server Failover Clustering configuration in Azure without a shared disk.

SAP ASCS/SCS HA met gedeelde clusterschijven

In Windows bevat een SAP ASCS/SCS-exemplaar SAP-centrale services, de SAP-berichtserver, serverprocessen en sap-algemene hostbestanden. Algemene SAP-hostbestanden slaan centrale bestanden op voor het hele SAP-systeem.

Een SAP ASCS/SCS-exemplaar heeft de volgende onderdelen:

  • SAP Central-services:

    • Twee processen (voor een berichtserver en een wachtrijserver) en een virtuele ASCS/SCS-hostnaam die wordt gebruikt voor toegang tot de twee processen
    • Bestandsstructuur: S:\usr\sap\<SID>\ASCS/SCS-exemplaarnummer<>

  • Algemene SAP-hostbestanden:

    • Bestandsstructuur: S:\usr\sap\<SID>\SYS...

    • De sapmnt-bestandsshare , waarmee u toegang hebt tot deze algemene S:\usr\sap\<SID>\SYS... -bestanden met behulp van het volgende UNC-pad:

      \\<ASCS/SCS virtual host name>\sapmnt\<SID>\SYS...

Diagram of processes, file structure, and global host file share of an SAP ASCS/SCS instance.

In een instelling voor hoge beschikbaarheid clustert u SAP ASCS/SCS-exemplaren. U gebruikt gedeelde clusterschijven (station S in het voorbeeld van dit artikel) om de SAP ASCS/SCS- en SAP Global Host-bestanden te plaatsen.

Diagram that shows an SAP ASCS/SCS high-availability architecture with shared disks.

Met een ERS1-architectuur (Enqueue Replication Server 1):

  • Dezelfde naam van de virtuele ASCS/SCS-host wordt gebruikt voor toegang tot de SAP-berichtserver en het in de wachtrij plaatsen van serverprocessen, naast de algemene SAP-hostbestanden via de sapmnt-bestandsshare .
  • Dezelfde gedeelde clusterschijf (station S) wordt ertussen gedeeld.

Met de ERS2-architectuur (Replicatieserver 2) in de wachtrij:

  • Dezelfde naam van de virtuele ASCS/SCS-host wordt gebruikt voor toegang tot het SAP-berichtserverproces, naast de algemene SAP-hostbestanden via de sapmnt-bestandsshare .
  • Dezelfde gedeelde clusterschijf (station S) wordt ertussen gedeeld.
  • Er is een afzonderlijke virtuele ERS-hostnaam voor toegang tot het proces van de enqueue-server.

Diagram of an SAP ASCS/SCS high-availability architecture with a shared disk.

Gedeelde schijven en replicatieserver in de wachtrij

Gedeelde schijven worden ondersteund met een ERS1-architectuur, waarbij het ERS1-exemplaar:

  • Is niet geclusterd.
  • Gebruikt een localhost naam.
  • Wordt geïmplementeerd op lokale schijven op elk van de clusterknooppunten.

Gedeelde schijven worden ook ondersteund met een ERS2-architectuur, waarbij het ERS2-exemplaar:

  • Is geclusterd.
  • Maakt gebruik van een toegewezen virtuele of netwerkhostnaam.
  • Het IP-adres van de virtuele ERS-hostnaam moet worden geconfigureerd op een interne Azure-load balancer, naast het (A)SCS IP-adres.
  • Wordt geïmplementeerd op lokale schijven op elk van de geclusterde knooppunten, dus er is geen gedeelde schijf nodig.

Zie Replicatieserver in een Microsoft-failovercluster en nieuwe replicator in failoverclusters op de SAP-website voor meer informatie over ERS1 en ERS2.

Opties voor gedeelde schijven in Azure voor SAP-workloads

Er zijn twee opties voor gedeelde schijven in een Windows-failovercluster in Azure:

Wanneer u de technologie voor gedeelde schijven selecteert, moet u rekening houden met de volgende overwegingen over gedeelde Azure-schijven voor SAP-workloads:

  • Het gebruik van gedeelde Azure-schijven met Azure Premium SSD-schijven wordt ondersteund voor SAP-implementatie in beschikbaarheidssets en beschikbaarheidszones.
  • Azure Ultra Disk Storage-schijven en Azure Standard SSD-schijven worden niet ondersteund als gedeelde Azure-schijven voor SAP-workloads.
  • Zorg ervoor dat u Azure Premium SSD-schijven inricht met een minimale schijfgrootte, zoals opgegeven in Premium SSD-bereiken, om tegelijkertijd aan het vereiste aantal VIRTUELE machines te kunnen koppelen. Doorgaans hebt u twee VM's nodig voor SAP ASCS Windows-failoverclusters.

Houd rekening met de volgende overwegingen over SIOS:

  • De SIOS-oplossing biedt realtime synchrone gegevensreplicatie tussen twee schijven.
  • Met de SIOS-oplossing werkt u met twee beheerde schijven. Als u beschikbaarheidssets of beschikbaarheidszones gebruikt, bevinden de beheerde schijven zich in verschillende opslagclusters.
  • Implementatie in beschikbaarheidszones wordt ondersteund.
  • Voor de SIOS-oplossing moet software van derden worden geïnstalleerd en uitgevoerd, die u afzonderlijk moet aanschaffen.

Gedeelde Azure-schijven

U kunt SAP ASCS/SCS HA implementeren met gedeelde Azure-schijven.

Vereisten en beperkingen

Op dit moment kunt u Azure Premium SSD-schijven gebruiken als gedeelde Azure-schijven voor het SAP ASCS/SCS-exemplaar. De volgende beperkingen gelden momenteel:

Raadpleeg de sectie Beperkingen van de documentatie voor gedeelde Azure-schijven voor meer informatie.

Belangrijke overwegingen voor gedeelde Premium SSD-schijven

Houd rekening met deze belangrijke punten over gedeelde Schijven van Azure Premium SSD:

  • LRS voor gedeelde Premium SSD-schijven:

    • SAP-implementatie met LRS voor Premium SSD-gedeelde schijven werkt met één gedeelde Azure-schijf op één opslagcluster. Als er een probleem is met het opslagcluster waarin de gedeelde Azure-schijf is geïmplementeerd, is dit van invloed op uw SAP ASCS/SCS-exemplaar.

  • ZRS voor gedeelde Premium SSD-schijven:

    • Schrijflatentie voor ZRS is hoger dan die van LRS vanwege kruislings kopiëren van gegevens.
    • De afstand tussen beschikbaarheidszones in verschillende regio's varieert en zorgt er dus voor ZRS-schijflatentie in beschikbaarheidszones. Benchmark uw schijven om de latentie van ZRS-schijven in uw regio te identificeren.
    • ZRS voor Gedeelde Schijven met Premium SSD repliceert synchroon gegevens over drie beschikbaarheidszones in de regio. Als er een probleem is in een van de opslagclusters, blijft uw SAP ASCS/SCS-exemplaar actief omdat de opslagfailover transparant is voor de toepassingslaag.
    • Raadpleeg de sectie Beperkingen van de documentatie over ZRS voor beheerde schijven voor meer informatie.

Bekijk een SAP-implementatie en implementeer een SAP-implementatie in Azure- en Azure Storage-typen voor SAP-workloads voor andere belangrijke overwegingen over het plannen van uw SAP-implementatie.

Ondersteunde besturingssysteemversies

Windows Server 2016, 2019 en hoger worden ondersteund. Gebruik de nieuwste datacenterinstallatiekopieën.

We raden u ten zeerste aan om ten minste Windows Server 2019 Datacenter te gebruiken om deze redenen:

  • WSFC in Windows Server 2019 is op de hoogte van Azure.
  • Windows Server 2019 Datacenter omvat integratie en bewustzijn van azure-hostonderhoud en verbeterde ervaring door te controleren op geplande Azure-gebeurtenissen.
  • U kunt gedistribueerde netwerknamen gebruiken. (Dit is de standaardoptie.) U hoeft geen toegewezen IP-adres te hebben voor de naam van het clusternetwerk. U hoeft ook geen IP-adres te configureren op een interne Load Balancer van Azure.

Gedeelde schijven in Azure met SIOS DataKeeper

Een andere optie voor gedeelde schijven is het gebruik van SIOS DataKeeper Cluster Edition om een gespiegelde opslag te maken die gedeelde clusteropslag simuleert. De SIOS-oplossing biedt realtime synchrone gegevensreplicatie.

Een gedeelde schijfresource voor een cluster maken:

  1. Koppel een extra schijf aan elk van de virtuele machines in een Windows-clusterconfiguratie.
  2. Voer SIOS DataKeeper Cluster Edition uit op beide virtuele-machineknooppunten.
  3. Configureer SIOS DataKeeper Cluster Edition zodat deze de inhoud van het extra schijf gekoppelde volume van de bron-VM spiegelt naar het extra volume dat is gekoppeld aan de schijf van de virtuele doelmachine. SIOS DataKeeper abstraheert de bron- en doelvolumes en presenteert deze vervolgens als één gedeelde schijf aan WSFC.

Diagram of a Windows Server Failover Clustering configuration in Azure with SIOS DataKeeper.

Notitie

U hebt geen gedeelde schijven nodig voor hoge beschikbaarheid met sommige DBMS-producten, zoals SQL Server. SQL Server Always On repliceert DBMS-gegevens en logboekbestanden van de lokale schijf van het ene clusterknooppunt naar de lokale schijf van een ander clusterknooppunt. In dit geval heeft de configuratie van het Windows-cluster geen gedeelde schijf nodig.

Optionele configuraties

In de volgende diagrammen ziet u meerdere SAP-exemplaren op Azure-VM's waarop Windows Server-failoverclustering wordt uitgevoerd om het totale aantal VM's te verminderen.

Deze configuratie kan lokale SAP-toepassingsservers zijn op een SAP ASCS/SCS-cluster of een SAP ASCS/SCS-clusterrol op Microsoft SQL Server AlwaysOn-knooppunten.

Belangrijk

Het installeren van een lokale SAP-toepassingsserver op een AlwaysOn-knooppunt van SQL Server wordt niet ondersteund.

Sap ASCS/SCS en de Microsoft SQL Server-database zijn SPOF's (Single Points of Failure). WSFC helpt deze SPOFs te beveiligen in een Windows-omgeving.

Hoewel het resourceverbruik van de SAP ASCS/SCS vrij klein is, raden we u aan de geheugenconfiguratie voor SQL Server of de SAP-toepassingsserver met 2 GB te verminderen.

Dit diagram illustreert SAP-toepassingsservers op WSFC-knooppunten met behulp van SIOS DataKeeper:

Diagram of a Windows Server Failover Clustering configuration in Azure with SIOS DataKeeper and locally installed SAP application servers.

Omdat de SAP-toepassingsservers lokaal zijn geïnstalleerd, hoeft u geen synchronisatie in te stellen.

Dit diagram illustreert SAP ASCS/SCS op SQL Server AlwaysOn-knooppunten met behulp van SIOS DataKeeper:

Diagram of SAP ASCS/SCS on SQL Server Always On nodes with SIOS DataKeeper.

Zie de volgende bronnen voor meer informatie over andere configuraties:

Volgende stappen