Dela via

Hög tillgänglighet för SAP HANA-uppskalning med Azure NetApp Files i SUSE Enterprise Linux

  • Artikel

Den här artikeln beskriver hur du konfigurerar SAP HANA-systemreplikering i uppskalningsdistribution när HANA-filsystemen monteras via NFS med hjälp av Azure NetApp Files. I exempelkonfigurationer och installationskommandon används instansnummer 03 och HANA System ID HN1. SAP HANA-replikering består av en primär nod och minst en sekundär nod.

När stegen i det här dokumentet markeras med följande prefix betyder de:

  • [A]: Steget gäller för alla noder.
  • [1]: Steget gäller endast för node1.
  • [2]: Steget gäller endast för node2.

Läs följande SAP-anteckningar och dokument först:

Kommentar

Den här artikeln innehåller referenser till en term som Microsoft inte längre använder. När termen tas bort från programvaran tar vi bort den från den här artikeln.

Översikt

I en uppskalningsmiljö monteras traditionellt alla filsystem för SAP HANA från lokal lagring. Konfigurera HA för SAP HANA-systemreplikering på SUSE Enterprise Linux publiceras i Konfigurera SAP HANA-systemreplikering på SLES.

För att uppnå SAP HANA HA för ett uppskalningssystem på Azure NetApp Files NFS-resurser behöver vi extra resurskonfiguration i klustret. Den här konfigurationen behövs så att HANA-resurser kan återställas när en nod förlorar åtkomsten till NFS-resurserna i Azure NetApp Files.

Diagram that shows SAP HANA HA scale-up on Azure NetApp Files.

SAP HANA-filsystem monteras på NFS-resurser med hjälp av Azure NetApp Files på varje nod. Filsystemen /hana/data, /hana/log och /hana/shared är unika för varje nod.

Monterad på node1 (hanadb1):

  • 10.3.1.4:/hanadb1-data-mnt00001 på /hana/data
  • 10.3.1.4:/hanadb1-log-mnt00001 på /hana/log
  • 10.3.1.4:/hanadb1-shared-mnt00001 på /hana/shared

Monterad på node2 (hanadb2):

  • 10.3.1.4:/hanadb2-data-mnt00001 på /hana/data
  • 10.3.1.4:/hanadb2-log-mnt00001 på /hana/log
  • 10.3.1.4:/hanadb2-shared-mnt0001 på /hana/shared

Kommentar

Filsystemen /hana/shared, /hana/data och /hana/log delas inte mellan de två noderna. Varje klusternod har egna separata filsystem.

SAP HA HANA-systemreplikeringskonfigurationen använder ett dedikerat virtuellt värdnamn och virtuella IP-adresser. I Azure krävs en lastbalanserare för att använda en virtuell IP-adress. Den presenterade konfigurationen visar en lastbalanserare med:

  • IP-adress för klientdelskonfiguration: 10.3.0.50 för hn1-db
  • Avsökningsport: 62503

Konfigurera Azure NetApp Files-infrastrukturen

Innan du fortsätter med konfigurationen för Azure NetApp Files-infrastrukturen bör du bekanta dig med Dokumentationen om Azure NetApp Files.

Azure NetApp Files är tillgängligt i flera Azure-regioner. Kontrollera om den valda Azure-regionen erbjuder Azure NetApp Files.

Information om tillgängligheten för Azure NetApp Files per Azure-region finns i Tillgänglighet för Azure NetApp Files per Azure-region.

Viktigt!

När du skapar dina Azure NetApp Files for SAP HANA-uppskalningssystem bör du vara medveten om de viktiga överväganden som beskrivs i NFS v4.1-volymer på Azure NetApp Files för SAP HANA.

Storleksändring av HANA-databas på Azure NetApp Files

Dataflödet för en Azure NetApp Files-volym är en funktion av volymstorleken och tjänstnivån, enligt beskrivningen i Tjänstnivå för Azure NetApp Files.

När du utformar infrastrukturen för SAP HANA i Azure med Azure NetApp Files bör du vara medveten om rekommendationerna i NFS v4.1-volymer på Azure NetApp Files för SAP HANA.

Konfigurationen i den här artikeln visas med enkla Azure NetApp Files-volymer.

Viktigt!

För produktionssystem, där prestanda är nyckeln, rekommenderar vi att du utvärderar och överväger att använda Azure NetApp Files-programvolymgruppen för SAP HANA.

Alla kommandon för att montera /hana/delas i den här artikeln visas för NFSv4.1 /hana/delade volymer. Om du har distribuerat volymerna /hana/shared som NFSv3-volymer ska du inte glömma att justera monteringskommandona för /hana/shared för NFSv3.

Distribuera Azure NetApp Files-resurser

Följande instruktioner förutsätter att du redan har distribuerat ditt virtuella Azure-nätverk. Azure NetApp Files-resurser och virtuella datorer, där Azure NetApp Files-resurserna monteras, måste distribueras i samma virtuella Azure-nätverk eller i peerkopplade virtuella Azure-nätverk.

  1. Skapa ett NetApp-konto i din valda Azure-region genom att följa anvisningarna i Skapa ett NetApp-konto.

  2. Konfigurera en Azure NetApp Files-kapacitetspool genom att följa anvisningarna i Konfigurera en Azure NetApp Files-kapacitetspool.

    HANA-arkitekturen som presenteras i den här artikeln använder en enda Kapacitetspool för Azure NetApp Files på Ultra-tjänstnivå. För HANA-arbetsbelastningar i Azure rekommenderar vi att du använder Azure NetApp Files Ultra- eller Premium-tjänstnivån.

  3. Delegera ett undernät till Azure NetApp Files enligt anvisningarna i Delegera ett undernät till Azure NetApp Files.

  4. Distribuera Azure NetApp Files-volymer genom att följa anvisningarna i Skapa en NFS-volym för Azure NetApp Files.

    När du distribuerar volymerna måste du välja NFSv4.1-versionen. Distribuera volymerna i det avsedda Azure NetApp Files-undernätet. IP-adresserna för Azure NetApp Files-volymerna tilldelas automatiskt.

    Azure NetApp Files-resurserna och de virtuella Azure-datorerna måste finnas i samma virtuella Azure-nätverk eller i peerkopplade virtuella Azure-nätverk. Till exempel hanadb1-data-mnt00001, hanadb1-log-mnt00001 och så vidare är volymnamnen och nfs://10.3.1.4/hanadb1-data-mnt00001, nfs://10.3.1.4/hanadb1-log-mnt00001 och så vidare är filsökvägarna för Azure NetApp Files-volymerna.

    På hanadb1:

    • Volym hanadb1-data-mnt00001 (nfs://10.3.1.4:/hanadb1-data-mnt00001)
    • Volym hanadb1-log-mnt00001 (nfs://10.3.1.4:/hanadb1-log-mnt00001)
    • Volym hanadb1-shared-mnt00001 (nfs://10.3.1.4:/hanadb1-shared-mnt00001)

    På hanadb2:

    • Volym hanadb2-data-mnt00001 (nfs://10.3.1.4:/hanadb2-data-mnt00001)
    • Volym hanadb2-log-mnt00001 (nfs://10.3.1.4:/hanadb2-log-mnt00001)
    • Volym hanadb2-shared-mnt00001 (nfs://10.3.1.4:/hanadb2-shared-mnt00001)

Förbered infrastrukturen

Resursagenten för SAP HANA ingår i SUSE Linux Enterprise Server för SAP-program. En avbildning för SUSE Linux Enterprise Server för SAP-program 12 eller 15 finns på Azure Marketplace. Du kan använda avbildningen för att distribuera nya virtuella datorer.

Distribuera virtuella Linux-datorer manuellt via Azure-portalen

Det här dokumentet förutsätter att du redan har distribuerat en resursgrupp, Azure Virtual Network och undernät.

Distribuera virtuella datorer för SAP HANA. Välj en lämplig SLES-avbildning som stöds för HANA-systemet. Du kan distribuera en virtuell dator i något av tillgänglighetsalternativen: VM-skalningsuppsättning, tillgänglighetszon eller tillgänglighetsuppsättning.

Viktigt!

Kontrollera att operativsystemet du väljer är SAP-certifierat för SAP HANA för de specifika VM-typer som du planerar att använda i distributionen. Du kan leta upp SAP HANA-certifierade VM-typer och deras OS-versioner i SAP HANA-certifierade IaaS-plattformar. Se till att du tittar på informationen om vm-typen för att få en fullständig lista över SAP HANA-versioner som stöds av operativsystemet för den specifika typen av virtuell dator.

Konfigurera Azure Load Balancer

Under konfigurationen av den virtuella datorn kan du skapa eller välja den befintliga lastbalanseraren i nätverksavsnittet. Följ nästa steg för att konfigurera en standardlastbalanserare för HA-konfiguration av HANA-databasen.

Följ stegen i Skapa lastbalanserare för att konfigurera en standardlastbalanserare för ett SAP-system med hög tillgänglighet med hjälp av Azure-portalen. Tänk på följande under installationen av lastbalanseraren:

  1. IP-konfiguration för klientdelen: Skapa en klientdels-IP-adress. Välj samma virtuella nätverk och undernätsnamn som dina virtuella databasdatorer.
  2. Serverdelspool: Skapa en serverdelspool och lägg till virtuella databasdatorer.
  3. Regler för inkommande trafik: Skapa en belastningsutjämningsregel. Följ samma steg för båda belastningsutjämningsreglerna.
    • Klientdels-IP-adress: Välj en klientdels-IP-adress.
    • Serverdelspool: Välj en serverdelspool.
    • Portar med hög tillgänglighet: Välj det här alternativet.
    • Protokoll: Välj TCP.
    • Hälsoavsökning: Skapa en hälsoavsökning med följande information:
      • Protokoll: Välj TCP.
      • Port: Till exempel 625<instans-no.>.
      • Intervall: Ange 5.
      • Tröskelvärde för avsökning: Ange 2.
    • Tidsgräns för inaktivitet (minuter): Ange 30.
    • Aktivera flytande IP: Välj det här alternativet.

Kommentar

Konfigurationsegenskapen numberOfProbesför hälsoavsökningen , även kallad Tröskelvärde för fel i portalen, respekteras inte. Om du vill kontrollera antalet lyckade eller misslyckade efterföljande avsökningar anger du egenskapen probeThreshold till 2. Det går för närvarande inte att ange den här egenskapen med hjälp av Azure-portalen, så använd antingen Azure CLI eller PowerShell-kommandot .

Mer information om de portar som krävs för SAP HANA finns i kapitlet Anslut ions till klientdatabaser i guiden FÖR SAP HANA-klientdatabaser eller SAP Note 2388694.

Viktigt!

Flytande IP stöds inte på en sekundär IP-konfiguration för nätverkskort i belastningsutjämningsscenarier. Mer information finns i Begränsningar för Azure Load Balancer. Om du behöver fler IP-adresser för den virtuella datorn distribuerar du ett andra nätverkskort.

När virtuella datorer utan offentliga IP-adresser placeras i serverdelspoolen för intern (ingen offentlig IP-adress) Standard Azure Load Balancer finns det ingen utgående Internetanslutning om inte mer konfiguration utförs för att tillåta routning till offentliga slutpunkter. Mer information om hur du uppnår utgående anslutning finns i Offentlig slutpunktsanslutning för virtuella datorer som använder Azure Standard Load Balancer i SAP-scenarier med hög tillgänglighet.

Viktigt!

  • Aktivera inte TCP-tidsstämplar på virtuella Azure-datorer som placerats bakom Load Balancer. Om du aktiverar TCP-tidsstämplar misslyckas hälsoavsökningarna. Ange parametern net.ipv4.tcp_timestamps till 0. Mer information finns i Load Balancer-hälsoavsökningar och SAP Note 2382421.
  • Om du vill förhindra att saptune ändrar det manuellt inställda net.ipv4.tcp_timestamps värdet från 0 tillbaka till 1uppdaterar du saptune-versionen till 3.1.1 eller senare. Mer information finns i saptune 3.1.1 – Behöver jag uppdatera?.

Montera Azure NetApp Files-volymen

  1. [A] Skapa monteringspunkter för HANA-databasvolymerna.

    sudo mkdir -p /hana/data/HN1/mnt00001
sudo mkdir -p /hana/log/HN1/mnt00001
sudo mkdir -p /hana/shared/HN1

  2. [A] Verifiera NFS-domäninställningen. Kontrollera att domänen är konfigurerad som standarddomänen för Azure NetApp Files, det vill defaultv4iddomain.com och att mappningen inte är inställd på någon.

    sudo cat /etc/idmapd.conf

    Exempel på utdata>

    [General]
Domain = defaultv4iddomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody

    Viktigt!

    Se till att ange NFS-domänen i /etc/idmapd.conf på den virtuella datorn så att den matchar standarddomänkonfigurationen på Azure NetApp Files: defaultv4iddomain.com. Om det finns ett matchningsfel mellan domänkonfigurationen på NFS-klienten (dvs. den virtuella datorn) och NFS-servern (dvs. Azure NetApp Files-konfigurationen) visas behörigheterna för filer på Azure NetApp Files-volymer som är monterade på de virtuella datorerna som ingen.

  3. [A] Redigera /etc/fstab på båda noderna för att permanent montera de volymer som är relevanta för varje nod. I följande exempel visas hur du monterar volymerna permanent.

    sudo vi /etc/fstab

    Lägg till följande poster i /etc/fstab på båda noderna.

    Exempel på hanadb1:

    10.3.1.4:/hanadb1-data-mnt00001 /hana/data/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
10.3.1.4:/hanadb1-log-mnt00001 /hana/log/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
10.3.1.4:/hanadb1-shared-mnt00001 /hana/shared/HN1  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0

    Exempel på hanadb2:

    10.3.1.4:/hanadb2-data-mnt00001 /hana/data/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
10.3.1.4:/hanadb2-log-mnt00001 /hana/log/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
10.3.1.4:/hanadb2-shared-mnt00001 /hana/shared/HN1  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0

    Montera alla volymer.

    sudo mount -a

    För arbetsbelastningar som kräver högre dataflöde bör du överväga att använda monteringsalternativet enligt beskrivningen nconnect i NFS v4.1-volymer på Azure NetApp Files för SAP HANA. Kontrollera om nconnect stöds av Azure NetApp Files i Linux-versionen.

  4. [A] Kontrollera att alla HANA-volymer är monterade med NFS-protokollversionen NFSv4.

    sudo nfsstat -m

    Kontrollera att flaggan vers är inställd på 4.1.

    Exempel från hanadb1:

    /hana/log/HN1/mnt00001 from 10.3.1.4:/hanadb1-log-mnt00001
Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.3.0.4,local_lock=none,addr=10.3.1.4
/hana/data/HN1/mnt00001 from 10.3.1.4:/hanadb1-data-mnt00001
Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.3.0.4,local_lock=none,addr=10.3.1.4
/hana/shared/HN1 from 10.3.1.4:/hanadb1-shared-mnt00001
Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.3.0.4,local_lock=none,addr=10.3.1.4

  5. [A] Kontrollera nfs4_disable_idmapping. Den ska vara inställd på Y. Kör monteringskommandot för att skapa katalogstrukturen där nfs4_disable_idmapping finns. Du kommer inte att kunna skapa katalogen manuellt under /sys/modules eftersom åtkomst är reserverad för kerneln/drivrutinerna.

    #Check nfs4_disable_idmapping
sudo cat /sys/module/nfs/parameters/nfs4_disable_idmapping

#If you need to set nfs4_disable_idmapping to Y
sudo echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping

#Make the configuration permanent
sudo echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf

SAP HANA-installation

  1. [A] Konfigurera värdnamnsmatchning för alla värdar.

    Du kan antingen använda en DNS-server eller ändra /etc/hosts filen på alla noder. Det här exemplet visar hur du /etc/hosts använder filen. Ersätt IP-adressen och värdnamnet i följande kommandon:

    sudo vi /etc/hosts

    Infoga följande rader i /etc/hosts filen. Ändra IP-adressen och värdnamnet så att de matchar din miljö.

    10.3.0.4   hanadb1
10.3.0.5   hanadb2

  2. [A] Förbered operativsystemet för att köra SAP HANA på Azure NetApp med NFS, enligt beskrivningen i SAP Note 3024346 – Linux Kernel Inställningar för NetApp NFS. Skapa konfigurationsfilen /etc/sysctl.d/91-NetApp-HANA.conf för NetApp-konfigurationsinställningarna.

    sudo vi /etc/sysctl.d/91-NetApp-HANA.conf

    Lägg till följande poster i konfigurationsfilen:

    net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
net.core.netdev_max_backlog = 300000
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1

  3. [A] Skapa konfigurationsfilen /etc/sysctl.d/ms-az.conf med fler optimeringsinställningar.

    sudo vi /etc/sysctl.d/ms-az.conf

    Lägg till följande poster i konfigurationsfilen:

    net.ipv6.conf.all.disable_ipv6 = 1
net.ipv4.tcp_max_syn_backlog = 16348
net.ipv4.conf.all.rp_filter = 0
sunrpc.tcp_slot_table_entries = 128
vm.swappiness=10

    Dricks

    Undvik att ange net.ipv4.ip_local_port_range och net.ipv4.ip_local_reserved_ports uttryckligen i sysctl-konfigurationsfilerna så att SAP-värdagenten kan hantera portintervallen. Mer information finns i SAP Note 2382421.

  4. [A] Justera inställningarna enligt rekommendationerna sunrpc i SAP Note 3024346 – Linux Kernel Inställningar för NetApp NFS.

    sudo vi /etc/modprobe.d/sunrpc.conf

    Infoga följande rad:

    options sunrpc tcp_max_slot_table_entries=128

  5. [A] Konfigurera SLES för HANA.

    Konfigurera SLES enligt beskrivningen i följande SAP-anteckningar baserat på din SLES-version:

  6. [A] Installera SAP HANA.

    Från och med HANA 2.0 SPS 01 är MDC (Multitenant Database Containers) standardalternativet. När du installerar HANA-systemet skapas SYSTEMDB och en klientorganisation med samma SID tillsammans. I vissa fall vill du inte ha standardklientorganisationen. Om du inte vill skapa den första klientorganisationen tillsammans med installationen följer du anvisningarna i SAP Note 2629711.

    1. Starta programmet hdblcm från programkatalogen för HANA-installation.

      ./hdblcm

    2. Ange följande värden i prompten:

      • För Välj installation: Ange 1 (för installation).
      • För Välj ytterligare komponenter för installation: Ange 1.
      • För Ange installationssökväg [/hana/delad]: Tryck på Retur för att acceptera standardinställningen.
      • För Ange lokalt värdnamn [..]: Tryck på Retur för att acceptera standardvärdet.
      • Under Vill du lägga till ytterligare värdar i systemet? (y/n) [n]: Välj n.
      • För Ange SAP HANA-system-ID: Ange HN1.
      • För Ange instansnummer [00]: Ange 03.
      • För Välj databasläge/Ange index [1]: Tryck på Retur för att acceptera standardvärdet.
      • För Välj systemanvändning/Ange index [4]: Ange 4 (för anpassad).
      • För Ange plats för datavolymer [/hana/data]: Tryck på Retur för att acceptera standardvärdet.
      • För Ange plats för loggvolymer [/hana/log]: Tryck på Retur för att acceptera standardvärdet.
      • För Begränsa maximal minnesallokering? [n]: Tryck på Retur för att acceptera standardvärdet.
      • För Ange certifikatvärdnamn för värden '...' [...]: Tryck på Retur för att acceptera standardvärdet.
      • För Ange sapadm-lösenord (SAP Host Agent User): Ange användarlösenordet för värdagenten.
      • För Bekräfta SAP-värdagentens användarlösenord (sapadm): Ange värdagentens användarlösenord igen för att bekräfta.
      • För Ange systemadministratörslösenord (hn1adm): Ange systemadministratörslösenordet.
      • För Bekräfta systemadministratörslösenord (hn1adm): Ange systemadministratörslösenordet igen för att bekräfta.
      • För Enter System Administrator Home Directory [/usr/sap/HN1/home]: Tryck på Retur för att acceptera standardvärdet.
      • För Ange systemadministratörsinloggningsgränssnittet [/bin/sh]: Tryck på Retur för att acceptera standardvärdet.
      • För Ange systemadministratörsanvändar-ID [1001]: Tryck på Retur för att acceptera standardvärdet.
      • För Ange ID för användargrupp (sapsys) [79]: Tryck på Retur för att acceptera standardvärdet.
      • För Ange lösenord för databasanvändare (SYSTEM): Ange databasanvändarlösenordet.
      • För Bekräfta databasanvändarens (SYSTEM) lösenord: Ange databasanvändarlösenordet igen för att bekräfta.
      • För Starta om systemet efter omstart av datorn? [n]: Tryck på Retur för att acceptera standardvärdet.
      • För Vill du fortsätta? (y/n): Verifiera sammanfattningen. Ange y för att fortsätta.

  7. [A] Uppgradera SAP-värdagenten.

    Ladda ned det senaste SAP-värdagentarkivet från SAP Software Center och kör följande kommando för att uppgradera agenten. Ersätt sökvägen till arkivet för att peka på filen som du laddade ned.

    sudo /usr/sap/hostctrl/exe/saphostexec -upgrade -archive <path to SAP Host Agent SAR>

Konfigurera SAP HANA-systemreplikering

Följ stegen i SAP HANA-systemreplikering för att konfigurera SAP HANA-systemreplikering.

Klusterkonfiguration

I det här avsnittet beskrivs de steg som krävs för att klustret ska fungera sömlöst när SAP HANA installeras på NFS-resurser med hjälp av Azure NetApp Files.

Skapa ett Pacemaker-kluster

Följ stegen i Konfigurera Pacemaker på SUSE Enterprise Linux i Azure för att skapa ett grundläggande Pacemaker-kluster för den här HANA-servern.

Implementera HANA-krokar SAPHanaSR och susChkSrv

Det här viktiga steget optimerar integreringen med klustret och förbättrar identifieringen när ett kluster behöver redundans. Vi rekommenderar starkt att du konfigurerar både SAPHanaSR- och susChkSrv Python-krokar. Följ stegen i Implementera Python-systemreplikeringskrokar SAPHanaSR och susChkSrv.

Konfigurera SAP HANA-klusterresurser

I det här avsnittet beskrivs de steg som krävs för att konfigurera SAP HANA-klusterresurserna.

Skapa SAP HANA-klusterresurser

Följ stegen i Skapa SAP HANA-klusterresurser för att skapa klusterresurserna för HANA-servern. När resurserna har skapats bör du se status för klustret med följande kommando:

sudo crm_mon -r

Exempel på utdata>

# Online: [ hn1-db-0 hn1-db-1 ]
# Full list of resources:
# stonith-sbd     (stonith:external/sbd): Started hn1-db-0
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hn1-db-0 hn1-db-1 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hn1-db-0 ]
#     Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

Skapa filsystemresurser

Skapa en dummyfilsystemklusterresurs. Den övervakar och rapporterar fel om det uppstår problem med att komma åt det NFS-monterade filsystemet /hana/shared. Det gör att klustret kan utlösa redundans om det uppstår problem med att komma åt /hana/shared. Mer information finns i Hantera misslyckad NFS-resurs i SUSE HA-kluster för HANA-systemreplikering.

  1. [A] Skapa katalogstrukturen på båda noderna.

    sudo mkdir -p /hana/shared/HN1/check
sudo mkdir -p /hana/shared/check

  2. [1] Konfigurera klustret för att lägga till katalogstrukturen för övervakning.

    sudo crm configure primitive rsc_fs_check_HN1_HDB03 Filesystem params \
    device="/hana/shared/HN1/check/" \
    directory="/hana/shared/check/" fstype=nfs  \
    options="bind,defaults,rw,hard,rsize=262144,wsize=262144,proto=tcp,noatime,_netdev,nfsvers=4.1,lock,sec=sys" \
    op monitor interval=120 timeout=120 on-fail=fence \
    op_params OCF_CHECK_LEVEL=20 \
    op start interval=0 timeout=120 \
    op stop interval=0 timeout=120

  3. [1] Klona och kontrollera den nyligen konfigurerade volymen i klustret.

    sudo crm configure clone cln_fs_check_HN1_HDB03 rsc_fs_check_HN1_HDB03 meta clone-node-max=1 interleave=true

    Exempel på utdata>

    sudo crm status

# Cluster Summary:
# Stack: corosync
# Current DC: hanadb1 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
# Last updated: Tue Nov  2 17:57:39 2021
# Last change:  Tue Nov  2 17:57:38 2021 by root via crm_attribute on hanadb1
# 2 nodes configured
# 11 resource instances configured

# Node List:
# Online: [ hanadb1 hanadb2 ]

# Full List of Resources:
# Clone Set: cln_azure-events [rsc_azure-events]:
#  Started: [ hanadb1 hanadb2 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
#  rsc_SAPHanaTopology_HN1_HDB03     (ocf::suse:SAPHanaTopology):     Started hanadb1 (Monitoring)
#  rsc_SAPHanaTopology_HN1_HDB03     (ocf::suse:SAPHanaTopology):     Started hanadb2 (Monitoring)
# Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
#  rsc_SAPHana_HN1_HDB03     (ocf::suse:SAPHana):     Master hanadb1 (Monitoring)
#  Slaves: [ hanadb2 ]
# Resource Group: g_ip_HN1_HDB03:
#  rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb1
#  rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb1
# rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
# Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
#  Started: [ hanadb1 hanadb2 ]

    Attributet OCF_CHECK_LEVEL=20 läggs till i övervakningsåtgärden så att övervakningsåtgärder utför ett läs-/skrivtest i filsystemet. Utan det här attributet verifierar övervakningsåtgärden endast att filsystemet är monterat. Detta kan vara ett problem eftersom filsystemet kan förbli monterat när anslutningen går förlorad, trots att den inte är tillgänglig.

    Attributet on-fail=fence läggs också till i övervakningsåtgärden. Med det här alternativet stängs den noden omedelbart om övervakningsåtgärden misslyckas på en nod.

Viktigt!

Tidsgränser i föregående konfiguration kan behöva anpassas till den specifika HANA-installationen för att undvika onödiga stängselåtgärder. Ställ inte in tidsgränsvärdena för lågt. Tänk på att filsystemövervakaren inte är relaterad till HANA-systemreplikeringen. Mer information finns i SUSE-dokumentationen.

Testa klusterkonfigurationen

I det här avsnittet beskrivs hur du kan testa konfigurationen.

  1. Innan du startar ett test kontrollerar du att Pacemaker inte har någon misslyckad åtgärd (via crm-status) och inga oväntade platsbegränsningar (till exempel rester av ett migreringstest). Se också till att HANA-systemreplikeringen är i synkroniseringstillstånd, till exempel med systemReplicationStatus.

    sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"

  2. Kontrollera statusen för HANA-resurserna med hjälp av det här kommandot:

    SAPHanaSR-showAttr

# You should see something like below
# hanadb1:~ SAPHanaSR-showAttr
# Global cib-time                 maintenance
# --------------------------------------------
# global Mon Nov  8 22:50:30 2021 false
# Sites srHook
# -------------
# SITE1 PRIM
# SITE2 SOK
# Site2 SOK
# Hosts   clone_state lpa_hn1_lpt node_state op_mode   remoteHost roles                            score site  srmode sync_state version                vhost
# --------------------------------------------------------------------------------------------------------------------------------------------------------------
# hanadb1 PROMOTED    1636411810  online     logreplay hanadb2    4:P:master1:master:worker:master 150   SITE1 sync   PRIM       2.00.058.00.1634122452 hanadb1
# hanadb2 DEMOTED     30          online     logreplay hanadb1    4:S:master1:master:worker:master 100   SITE2 sync   SOK        2.00.058.00.1634122452 hanadb2

  3. Kontrollera klusterkonfigurationen för ett felscenario när en nod stängs av. I följande exempel visas hur du stänger av noden 1:

    sudo crm status
sudo crm resource move msl_SAPHana_HN1_HDB03 hanadb2 force
sudo crm resource cleanup

    Exempel på utdata>

    sudo crm status

#Cluster Summary:
# Stack: corosync
# Current DC: hanadb2 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
# Last updated: Mon Nov  8 23:25:36 2021
# Last change:  Mon Nov  8 23:25:19 2021 by root via crm_attribute on hanadb2
# 2 nodes configured
# 11 resource instances configured

# Node List:
# Online: [ hanadb1 hanadb2 ]
# Full List of Resources:
# Clone Set: cln_azure-events [rsc_azure-events]:
#  Started: [ hanadb1 hanadb2 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
#  Started: [ hanadb1 hanadb2 ]
# Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
#  Masters: [ hanadb2 ]
#  Stopped: [ hanadb1 ]
# Resource Group: g_ip_HN1_HDB03:
#  rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb2
#  rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb2
# rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
# Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
#  Started: [ hanadb1 hanadb2 ]

    Stoppa HANA på Node1:

    sudo su - hn1adm
sapcontrol -nr 03 -function StopWait 600 10

    Registrera nod 1 som sekundär nod och kontrollera status:

    hdbnsutil -sr_register --remoteHost=hanadb2 --remoteInstance=03 --replicationMode=sync --name=SITE1 --operationMode=logreplay

    Exempel på utdata>

    #adding site ...
#nameserver hanadb1:30301 not responding.
#collecting information ...
#updating local ini files ...
#done.

    sudo crm status

    sudo SAPHanaSR-showAttr

  4. Kontrollera klusterkonfigurationen för ett felscenario när en nod förlorar åtkomsten till NFS-resursen (/hana/delad).

    SAP HANA-resursagenterna är beroende av binärfiler som lagras på /hana/shared för att utföra åtgärder under redundansväxlingen. Filsystemet /hana/shared monteras över NFS i det presenterade scenariot.

    Det är svårt att simulera ett fel, där en av servrarna förlorar åtkomsten till NFS-resursen. Som ett test kan du återmontera filsystemet som skrivskyddat. Den här metoden verifierar att klustret kan redundansväxla om åtkomsten till /hana/shared går förlorad på den aktiva noden.

    Förväntat resultat: När du gör /hana/shared som ett skrivskyddat filsystem OCF_CHECK_LEVEL misslyckas attributet för resursen hana_shared1, som utför läs-/skrivåtgärder i filsystemet. Det misslyckas eftersom det inte kan skriva något i filsystemet och utför en HANA-resursredundans. Samma resultat förväntas när HANA-noden förlorar åtkomsten till NFS-resurserna.

    Resurstillstånd innan testet startas:

    sudo crm  status

#Cluster Summary:
 # Stack: corosync
 # Current DC: hanadb2 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
 # Last updated: Mon Nov  8 23:01:27 2021
 # Last change:  Mon Nov  8 23:00:46 2021 by root via crm_attribute on hanadb1
 # 2 nodes configured
 # 11 resource instances configured

 #Node List:
 # Online: [ hanadb1 hanadb2 ]

 #Full List of Resources:
 # Clone Set: cln_azure-events [rsc_azure-events]:
   # Started: [ hanadb1 hanadb2 ]
 # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
   # Started: [ hanadb1 hanadb2 ]
 # Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
   # Masters: [ hanadb1 ]
   # Slaves: [ hanadb2 ]
 # Resource Group: g_ip_HN1_HDB03:
   # rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb1
   # rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb1
 # rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
 # Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
   # Started: [ hanadb1 hanadb2 ]

    Du kan placera /hana/shared i skrivskyddat läge på den aktiva klusternoden med hjälp av det här kommandot:

    sudo mount -o ro 10.3.1.4:/hanadb1-shared-mnt00001 /hana/sharedb

    Servern hanadb1 startar om eller stänger av baserat på åtgärdsuppsättningen. När servern hanadb1 är nere flyttas HANA-resursen till hanadb2. Du kan kontrollera status för klustret från hanadb2.

    sudo crm status

#Cluster Summary:
 # Stack: corosync
 # Current DC: hanadb2 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
 # Last updated: Wed Nov 10 22:00:27 2021
 # Last change:  Wed Nov 10 21:59:47 2021 by root via crm_attribute on hanadb2
 # 2 nodes configured
 # 11 resource instances configured

 #Node List:
 # Online: [ hanadb1 hanadb2 ]

 #Full List of Resources:
 # Clone Set: cln_azure-events [rsc_azure-events]:
   # Started: [ hanadb1 hanadb2 ]
 # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
   # Started: [ hanadb1 hanadb2 ]
 # Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
   # Masters: [ hanadb2 ]
   # Stopped: [ hanadb1 ]
 # Resource Group: g_ip_HN1_HDB03:
      # rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb2
   # rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb2
 # rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
 # Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
   # Started: [ hanadb1 hanadb2 ]

    Vi rekommenderar att du testar konfigurationen av SAP HANA-klustret noggrant genom att utföra de tester som beskrivs i SAP HANA-systemreplikeringen.

Nästa steg