Disponibilità elevata per SAP NetWeaver in macchine virtuali Azure su SUSE Linux Enterprise Server per applicazioni SAP multi-SID

Questo articolo descrive come distribuire più sistemi SAP NetWeaver o S/4HANA a disponibilità elevata (multi-SID) in un cluster a due nodi in Azure macchine virtuali con SUSE Linux Enterprise Server per applicazioni SAP. Il clustering multi-SID consente di eseguire più istanze SAP con identificatori di sistema diversi nello stesso cluster Pacemaker, ottimizzando l'utilizzo delle risorse mantenendo la disponibilità elevata.

Nelle configurazioni di esempio, i comandi di installazione e così via, tre sistemi SAP NetWeaver 7.50 vengono distribuiti in un singolo cluster a disponibilità elevata a due nodi. I SID dei sistemi SAP sono:

NW1: numero di istanza ASCS 00 e nome host virtuale msnw1ascs; numero di istanza ERS 02 e nome host virtuale msnw1ers.
NW2: numero di istanza ASCS 10 e nome host virtuale msnw2ascs; numero di istanza ERS 12 e nome host virtuale msnw2ers.
NW3: numero di istanza ASCS 20 e nome host virtuale msnw3ascs; numero di istanza ERS 22 e nome host virtuale msnw3ers.

L'articolo non tratta il livello del database e la distribuzione delle condivisioni SAP NFS. Negli esempi di questo articolo vengono usati nomi virtuali nw2-nfs per le condivisioni NFS NW2 e nw3-nfs per le condivisioni NFS NW3 , presupponendo che sia stato distribuito un cluster NFS.

Prima di iniziare, fare riferimento alle note e ai documenti SAP seguenti:

Nota SAP 1928533, contenente:
- Elenco delle dimensioni Azure vm supportate per la distribuzione del software SAP
- Informazioni importanti sulla capacità per le dimensioni delle macchine virtuali di Azure
- Software SAP, sistema operativo (OS) supportati e combinazioni di database
- Versione del kernel SAP necessaria per Windows e Linux in Microsoft Azure
Nota SAP 2015553 include i prerequisiti per le distribuzioni software SAP supportate da SAP in Azure.
Nota SAP 2205917 include le impostazioni del sistema operativo consigliate per SUSE Linux Enterprise Server for SAP Applications.
La nota SAP 1944799 include linee guida SAP HANA per SUSE Linux Enterprise Server per le applicazioni SAP.
Nota SAP 2178632 contiene informazioni dettagliate su tutte le metriche di monitoraggio segnalate per SAP in Azure.
Nota SAP 2191498 include la versione richiesta dell'agente host SAP per Linux in Azure.
Nota SAP 2243692 contiene informazioni sulle licenze SAP in Linux in Azure.
La nota SAP 1984787 contiene informazioni generali su SUSE Linux Enterprise Server 12.
Nota SAP 1999351 include altre informazioni sulla risoluzione dei problemi per l'estensione di monitoraggio avanzato Azure per SAP.
Community WIKI SAP contiene tutte le note su SAP necessarie per Linux.
Pianificazione e implementazione di macchine virtuali Azure per SAP su Linux.
distribuzione Azure Virtual Machines per SAP su Linux.
Azure Virtual Machines implementazione DBMS per SAP su Linux
Guide relative alle procedure consigliate di SUSE SAP HA: le guide contengono tutte le informazioni necessarie per configurare la replica di sistema Netweaver HA e SAP HANA in locale. Usare le guide come indicazioni di base generali. Forniscono informazioni molto più dettagliate.
Note sulla versione dell'estensione SUSE a disponibilità elevata 12 SP3.
Guida al cluster SUSE multi-SID per SLES 12 e SLES 15.
App licazioni SAP di NetApp su Microsoft Azure utilizzando Azure NetApp Files.

Panoramica

Le macchine virtuali che partecipano al cluster devono essere ridimensionate per poter eseguire tutte le risorse, nel caso in cui si verifichi il failover. Ogni SID SAP può eseguire il failover in modo indipendente nel cluster a disponibilità elevata multi-SID. Se si usa l'isolamento SBD, i dispositivi SBD possono essere condivisi tra più cluster.

Per ottenere la disponibilità elevata, SAP NetWeaver richiede condivisioni NFS a disponibilità elevata. In questo esempio si presuppone che le condivisioni SAP NFS siano ospitate in file server NFS a disponibilità elevata, che più sistemi SAP possono usare. In alternativa, le condivisioni vengono implementate sui volumi Azure NetApp Files NFS.

Diagramma di un cluster Pacemaker con informazioni dettagliate su due cluster multi-SID.

Importante

Il supporto per il clustering multi-SID di SAP ASCS/ERS con SUSE Linux come sistema operativo guest nelle macchine virtuali Azure è limitato a five (5) SID SAP nello stesso cluster. Ogni nuovo SID aumenta la complessità. Una combinazione di SAP Enqueue Replication Server 1 e Enqueue Replication Server 2 nello stesso cluster non è supportata. Il clustering multi SID descrive l'installazione di più istanze di SAP ASCS/ERS con SID diversi in un cluster Pacemaker. Attualmente il clustering multi SID è supportato solo per ASCS/ERS.

Suggerimento

Il clustering multi SID di SAP ASCS/ERS è una soluzione con maggiore complessità. È più complesso implementarlo. Comporta anche un impegno amministrativo più elevato, quando si eseguono attività di manutenzione, ad esempio l'applicazione di patch al sistema operativo. Prima di avviare l'implementazione effettiva, pianificate attentamente la distribuzione e tutti i componenti coinvolti, come le macchine virtuali, i montaggi NFS, gli indirizzi IP virtuali (VIP), le configurazioni del bilanciamento del carico e così via.

Il server NFS, SAP NetWeaver ASCS, SAP NetWeaver SCS, SAP NetWeaver ERS e il database SAP HANA usano nomi host virtuali e indirizzi IP virtuali. In Azure, per usare un indirizzo IP virtuale è necessario un servizio di bilanciamento del carico. È consigliabile usare Load Balancer Standard.

La configurazione presentata per questo esempio di cluster multi SID con tre sistemi SAP mostra un servizio di bilanciamento del carico con:

Indirizzi IP frontend per ASCS: 10.3.1.14 (NW1), 10.3.1.16 (NW2) e 10.3.1.13 (NW3)
Indirizzi IP front-end per ERS: 10.3.1.15 (NW1), 10.3.1.17 (NW2) e 10.3.1.19 (NW3)
Porta probe 62000 per NW1 ASCS, 62010 per NW2 ASCS e 62020 per NW3 ASCS
Porta probe 62102 per NW1 ASCS, 62112 per NW2 ASCS e 62122 per NW3 ASCS

Nota

Quando le macchine virtuali senza indirizzi IP pubblici vengono aggiunte al pool back-end di un Azure Load Balancer Standard interno, non dispone della connettività Internet in uscita. È necessaria un'ulteriore configurazione per abilitare il routing agli endpoint pubblici. Per informazioni dettagliate su come ottenere la connettività in uscita, vedere Connettività degli endpoint pubblici per le macchine virtuali usando Load Balancer Standard di Azure negli scenari a disponibilità elevata SAP.

Importante

Non abilitare timestamp TCP nelle macchine virtuali Azure posizionate dietro Azure Load Balancer. L'abilitazione dei timestamp TCP causa l'esito negativo dei probe di integrità. Impostare il parametro net.ipv4.tcp_timestamps su 0. Per informazioni dettagliate, vedere sonde di integrità del Load Balancer.
Per impedire a saptune di modificare il valore net.ipv4.tcp_timestamps impostato manualmente da 0 a 1, è consigliabile aggiornare la versione saptune alla versione 3.1.1 o successive. Per altre informazioni, vedere Saptune 3.1.1 – Do I Need to Update?.

Condivisioni SAP NFS

SAP NetWeaver richiede un'archiviazione condivisa per la directory di trasporto e del profilo e simili. Per il sistema SAP a disponibilità elevata, è importante avere condivisioni NFS a disponibilità elevata. È necessario decidere l'architettura per le condivisioni SAP NFS. Un'opzione consiste nel creare un NFS altamente disponibile su Azure VMs su SUSE Linux Enterprise Server, che può essere condiviso tra più sistemi SAP.

Un'altra opzione consiste nel distribuire le condivisioni nei volumi Azure NetApp Files NFS. Con Azure NetApp Files, si otterrebbe una disponibilità elevata predefinita per le condivisioni SAP NFS.

Distribuire il primo sistema SAP nel cluster

In base all'architettura per le condivisioni SAP NFS, distribuire il primo sistema SAP nel cluster, seguendo la documentazione corrispondente.

Se si utilizza un server NFS ad alta disponibilità, seguire Alta disponibilità per SAP NetWeaver su macchine virtuali Azure su SUSE Linux Enterprise Server per applicazioni SAP.
Se si usano i volumi NFS di Azure NetApp Files, seguire Disponibilità elevata per SAP NetWeaver nelle macchine virtuali di Azure in SUSE Linux Enterprise Server con Azure NetApp Files per applicazioni SAP.

Gli articoli di riferimento illustrano i passaggi per preparare le infrastrutture necessarie, compilare il cluster e preparare il sistema operativo per l'esecuzione dell'applicazione SAP.

Suggerimento

Testare sempre la funzionalità di failover del cluster dopo la distribuzione del primo sistema e prima di aggiungere altri SID SAP al cluster. Il test è fondamentale per sapere che la funzionalità del cluster funziona prima di aggiungere la complessità di sistemi SAP aggiuntivi al cluster.

Distribuire più sistemi SAP nel cluster

In questo esempio si presuppone che il sistema NW1 sia già stato distribuito nel cluster. Viene inoltre illustrato come distribuire i sistemi SAP NW2 e NW3 nel cluster.

Gli elementi seguenti sono preceduti da uno degli elementi seguenti:

[A] - applicabile a tutti i nodi
[1] - applicabile solo al nodo 1
[2] - applicabile solo al nodo 2

Prerequisiti

Importante

Prima di seguire le istruzioni per distribuire più sistemi SAP nel cluster, seguire le istruzioni per distribuire il primo sistema SAP nel cluster, perché sono necessari solo durante la prima distribuzione del sistema.

Questa documentazione presuppone che:

Il cluster Pacemaker è già configurato e in esecuzione.
Almeno un sistema SAP (istanza ASCS/ERS) sia già distribuito e in esecuzione nel cluster.
Viene testata la funzionalità di failover del cluster.
Siano distribuite le condivisioni NFS per tutti i sistemi SAP.

Preparare l'installazione di SAP NetWeaver

Aggiungere la configurazione per il sistema appena distribuito (NW2 e NW3) al Azure Load Balancer esistente, seguendo le istruzioni configurare Azure Load Balancer manualmente tramite il portale di Azure. Modifica gli indirizzi IP, le porte dei controlli di integrità, le regole di bilanciamento del carico per la tua configurazione.

[A] Configurare la risoluzione dei nomi per gli altri sistemi SAP. È possibile usare il server DNS o modificare /etc/hosts in tutti i nodi. In questo esempio viene illustrato come usare il file /etc/hosts. Adattare gli indirizzi IP e i nomi host all'ambiente.

sudo vi /etc/hosts

# IP address of the load balancer frontend configuration for NW2 ASCS
10.3.1.16 msnw2ascs

# IP address of the load balancer frontend configuration for NW3 ASCS
10.3.1.13 msnw3ascs

# IP address of the load balancer frontend configuration for NW2 ERS
10.3.1.17 msnw2ers

# IP address of the load balancer frontend configuration for NW3 ERS
10.3.1.19 msnw3ers

# IP address for virtual host name for the NFS server for NW2
10.3.1.31 nw2-nfs

# IP address for virtual host name for the NFS server for NW3
10.3.1.32 nw3-nfs

[A] Creare le directory condivise per i sistemi SAP NW2 e NW3 da distribuire nel cluster.

sudo mkdir -p /sapmnt/NW2
sudo mkdir -p /usr/sap/NW2/SYS
sudo mkdir -p /usr/sap/NW2/ASCS10
sudo mkdir -p /usr/sap/NW2/ERS12
sudo mkdir -p /sapmnt/NW3
sudo mkdir -p /usr/sap/NW3/SYS
sudo mkdir -p /usr/sap/NW3/ASCS20
sudo mkdir -p /usr/sap/NW3/ERS22

sudo chattr +i /sapmnt/NW2
sudo chattr +i /usr/sap/NW2/SYS
sudo chattr +i /usr/sap/NW2/ASCS10
sudo chattr +i /usr/sap/NW2/ERS12
sudo chattr +i /sapmnt/NW3
sudo chattr +i /usr/sap/NW3/SYS
sudo chattr +i /usr/sap/NW3/ASCS20
sudo chattr +i /usr/sap/NW3/ERS22

[A] Configurare autofs per montare i file system /sapmnt/SID e /usr/sap/SID/SYS per gli altri sistemi SAP che si distribuiscono nel cluster. In questo esempio, sono NW2 ed NW3.

Aggiornare il file /etc/auto.direct con i file system per gli altri sistemi SAP da distribuire nel cluster.
- Se si usa il file server NFS, seguire le istruzioni nella pagina Alta disponibilità delle macchine virtuali Azure per SAP NetWeaver su SLES
- Se si usa Azure NetApp Files, seguire le istruzioni nella pagina Alta disponibilità delle macchine virtuali per SAP NW in SLES con Azure NetApp Files
È necessario riavviare il servizio autofs per montare le condivisioni appena aggiunte.

Installare ASCS/ERS

Creare le risorse del cluster IP virtuale e probe di integrità per l'istanza ASCS dell'altro sistema SAP che si distribuisce nel cluster. L'esempio illustrato è per NW2 e NW3 ASCS, usando un server NFS a disponibilità elevata.
Importante

I test recenti hanno rivelato situazioni in cui netcat smette di rispondere alle richieste a causa del backlog e della relativa limitazione della gestione di una sola connessione. La risorsa netcat smette di ascoltare le richieste del servizio di bilanciamento del carico Azure e l'indirizzo IP fluttuante diventa non disponibile. Per i cluster Pacemaker esistenti, in passato è consigliabile sostituire netcat con socat. Attualmente è consigliabile usare l'agente azure-lb di risorse, che fa parte di package resource-agents, con i requisiti di versione del pacchetto seguenti:
- Per SLES 12 SP4/SP5 la versione deve essere almeno resource-agents-4.3.018.a7fb5035-3.30.1.
- Per SLES 15/15 SP1 la versione deve essere almeno resource-agents-4.3.0184.6ee15eb2-4.13.1.
La modifica richiede tempi di inattività brevi. Per i cluster Pacemaker esistenti, se la configurazione è già stata modificata per usare socat come descritto in Protezione avanzata del rilevamento del servizio di bilanciamento del carico di Azure, non è necessario passare immediatamente all'agente risorse azure-lb.
```
sudo crm configure primitive fs_NW2_ASCS Filesystem device='nw2-nfs:/NW2/ASCS' directory='/usr/sap/NW2/ASCS10' fstype='nfs4' \
   op start timeout=60s interval=0 \
   op stop timeout=60s interval=0 \
   op monitor interval=20s timeout=40s

sudo crm configure primitive vip_NW2_ASCS IPaddr2 \
    params ip=10.3.1.16 \
    op monitor interval=10 timeout=20

sudo crm configure primitive nc_NW2_ASCS azure-lb port=62010 \
    op monitor timeout=20s interval=10

sudo crm configure group g-NW2_ASCS fs_NW2_ASCS nc_NW2_ASCS vip_NW2_ASCS \
     meta resource-stickiness=3000

sudo crm configure primitive fs_NW3_ASCS Filesystem device='nw3-nfs:/NW3/ASCS' directory='/usr/sap/NW3/ASCS20' fstype='nfs4' \
    op start timeout=60s interval=0 \
    op stop timeout=60s interval=0 \
    op monitor interval=20s timeout=40s

sudo crm configure primitive vip_NW3_ASCS IPaddr2 \
   params ip=10.3.1.13 \
   op monitor interval=10 timeout=20

sudo crm configure primitive nc_NW3_ASCS azure-lb port=62020 \
   op monitor timeout=20s interval=10

sudo crm configure group g-NW3_ASCS fs_NW3_ASCS nc_NW3_ASCS vip_NW3_ASCS \
    meta resource-stickiness=3000
```
Mentre crei le risorse, potrebbero essere assegnate a risorse cluster diverse. Quando si raggruppano, viene eseguita la migrazione a uno dei nodi del cluster. Assicurarsi che lo stato del cluster sia ok e che tutte le risorse siano avviate. Non è importante il nodo su cui sono in esecuzione le risorse.
[1] Installare SAP NetWeaver ASCS

Installare SAP NetWeaver ASCS come utente root, usando un nome host virtuale mappato all'indirizzo IP del front-end del Load Balancer per ASCS. Ad esempio, per il sistema NW2, il nome host virtuale è msnw2ascs, 10.3.1.16 e il numero di istanza usato per il probe del servizio di bilanciamento del carico, ad esempio 10. Per il sistema NW3, il nome host virtuale è msnw3ascs, l'indirizzo IP è 10.3.1.13, e il numero di istanza usato per il probe del bilanciatore di carico è, ad esempio, 20.

È possibile usare il parametro sapinst SAPINST_REMOTE_ACCESS_USER per consentire a un utente non ROOT di connettersi a sapinst. È possibile usare il parametro SAPINST_USE_HOSTNAME per installare SAP usando il nome host virtuale.
```
sudo swpm/sapinst SAPINST_REMOTE_ACCESS_USER=sapadmin SAPINST_USE_HOSTNAME=virtual_hostname
```
Se l'installazione non riesce a creare una sottocartella in /usr/sap/SID/ASCSIstanza n., provare a impostare il proprietario su sidadm e il gruppo su sapsys dell'istanza ASCSInstance# e riprovare.

[1] Creare un indirizzo IP virtuale e risorse del cluster probe di integrità per l'istanza ERS dell’altro sistema SAP che si sta distribuendo nel cluster. L'esempio illustrato è per NW2 e NW3 ERS, usando un server NFS a disponibilità elevata.

sudo crm configure primitive fs_NW2_ERS Filesystem device='nw2-nfs:/NW2/ASCSERS' directory='/usr/sap/NW2/ERS12' fstype='nfs4' \
 op start timeout=60s interval=0 \
 op stop timeout=60s interval=0 \
 op monitor interval=20s timeout=40s

sudo crm configure primitive vip_NW2_ERS IPaddr2 \
 params ip=10.3.1.17 \
 op monitor interval=10 timeout=20

sudo crm configure primitive nc_NW2_ERS azure-lb port=62112 \
 op monitor timeout=20s interval=10

sudo crm configure group g-NW2_ERS fs_NW2_ERS nc_NW2_ERS vip_NW2_ERS

sudo crm configure primitive fs_NW3_ERS Filesystem device='nw3-nfs:/NW3/ASCSERS' directory='/usr/sap/NW3/ERS22' fstype='nfs4' \
 op start timeout=60s interval=0 \
 op stop timeout=60s interval=0 \
 op monitor interval=20s timeout=40s

sudo crm configure primitive vip_NW3_ERS IPaddr2 \
 params ip=10.3.1.19 \
 op monitor interval=10 timeout=20

sudo crm configure primitive nc_NW3_ERS azure-lb port=62122 \
 op monitor timeout=20s interval=10

sudo crm configure group g-NW3_ERS fs_NW3_ERS nc_NW3_ERS vip_NW3_ERS

Mentre stai creando le risorse, queste possono essere assegnate a nodi diversi del cluster. Quando si raggruppano, viene eseguita la migrazione a uno dei nodi del cluster. Assicurarsi che lo stato del cluster sia ok e che tutte le risorse siano avviate.

Assicurarsi quindi che le risorse del gruppo ERS appena creato siano in esecuzione nel nodo del cluster, opposto al nodo del cluster in cui è stata installata l'istanza ASCS per lo stesso sistema SAP. Ad esempio, se NW2 ASCS è stato installato in slesmsscl1, verificare che il gruppo NW2 ERS sia in esecuzione in slesmsscl2. È possibile eseguire la migrazione del gruppo NW2 ERS a slesmsscl2 eseguendo il comando seguente:

crm resource migrate g-NW2_ERS slesmsscl2 force

[2] Installare SAP NetWeaver ERS

Installare SAP NetWeaver ERS come utente root nel nodo secondario, usando un nome host virtuale mappato all'indirizzo IP della configurazione frontend del bilanciatore di carico per ERS. Ad esempio, per il sistema NW2, il nome host virtuale è msnw2ers, l'indirizzo IP è 10.3.1.17, e il numero di istanza utilizzato per la verifica del bilanciamento del carico è, ad esempio, 12. Per il sistema NW3, il nome host virtuale msnw3ers, 10.3.1.19 e il numero di istanza usato per la sonda del servizio di bilanciamento del carico, ad esempio 22.

È possibile usare il parametro sapinst SAPINST_REMOTE_ACCESS_USER per consentire a un utente non ROOT di connettersi a sapinst. È possibile usare il parametro SAPINST_USE_HOSTNAME per installare SAP usando il nome host virtuale.
```
sudo swpm/sapinst SAPINST_REMOTE_ACCESS_USER=sapadmin SAPINST_USE_HOSTNAME=virtual_hostname
```
Nota

Usare SWPM SP 20 PL 05 o versione successiva. Le versioni precedenti non impostano correttamente le autorizzazioni causando l'esito negativo dell'installazione.

Se l'installazione non riesce a creare una sottocartella in /usr/sap/NW2/ERSInstance#, provare a impostare il proprietario su sidadm e il gruppo sapsys nella cartella ERSInstance# e riprovare.

Se è necessario eseguire la migrazione del gruppo ERS del sistema SAP appena distribuito in un nodo del cluster diverso, non dimenticare di rimuovere il vincolo di posizione per il gruppo ERS. È possibile rimuovere il vincolo eseguendo il comando seguente (l'esempio viene fornito per i sistemi SAP NW2 ed NW3).
```
crm resource unmigrate g-NW2_ERS
crm resource unmigrate g-NW3_ERS
```

[1] Adattare i profili di istanza ASCS/SCS e ERS per uno o più sistemi SAP appena installati. L'esempio illustrato è per NW2. È necessario adattare i profili ASCS/SCS ed ERS per tutte le istanze SAP aggiunte al cluster.

Profilo ASCS/SCS

sudo vi /sapmnt/NW2/profile/NW2_ASCS10_msnw2ascs

# Change the restart command to a start command
#Restart_Program_01 = local $(_EN) pf=$(_PF)
Start_Program_01 = local $(_EN) pf=$(_PF)

# Add the following lines
service/halib = $(DIR_EXECUTABLE)/saphascriptco.so
service/halib_cluster_connector = /usr/bin/sap_suse_cluster_connector

# Add the keep alive parameter, if using ENSA1
enque/encni/set_so_keepalive = TRUE

Sia per ENSA1 che per ENSA2, assicurarsi che i parametri del sistema operativo keepalive siano impostati come descritto nella nota SAP 1410736.

Profilo ERS

sudo vi /sapmnt/NW2/profile/NW2_ERS12_msnw2ers

# Change the restart command to a start command
#Restart_Program_00 = local $(_ER) pf=$(_PFL) NR=$(SCSID)
Start_Program_00 = local $(_ER) pf=$(_PFL) NR=$(SCSID)

# Add the following lines
service/halib = $(DIR_EXECUTABLE)/saphascriptco.so
service/halib_cluster_connector = /usr/bin/sap_suse_cluster_connector

# remove Autostart from ERS profile
# Autostart = 1

[A] Configurare gli utenti SAP per il sistema SAP appena distribuito, in questo esempio NW2 ed NW3.

# Add sidadm to the haclient group
sudo usermod -aG haclient nw2adm
sudo usermod -aG haclient nw3adm

Aggiungere i servizi SAP ASCS ed ERS per il sistema SAP appena installato al file sapservice. L'esempio illustrato è relativo ai sistemi SAP NW2 e NW3.

Aggiungi la voce del servizio ASCS al secondo nodo e copia la voce del servizio ERS nel primo nodo. Eseguire i comandi per ogni sistema SAP nel nodo, in cui è stata installata l'istanza ASCS per il sistema SAP.

# Execute the following commands on slesmsscl1,assuming the NW2 ASCS instance was installed on slesmsscl1
cat /usr/sap/sapservices | grep ASCS10 | sudo ssh slesmsscl2 "cat >>/usr/sap/sapservices"
sudo ssh slesmsscl2 "cat /usr/sap/sapservices" | grep ERS12 | sudo tee -a /usr/sap/sapservices

# Execute the following commands on slesmsscl2, assuming the NW3 ASCS instance was installed on slesmsscl2
cat /usr/sap/sapservices | grep ASCS20 | sudo ssh slesmsscl1 "cat >>/usr/sap/sapservices"
sudo ssh slesmsscl1 "cat /usr/sap/sapservices" | grep ERS22 | sudo tee -a /usr/sap/sapservices

[A] Disabilitazione dei servizi systemd delle istanze SAP ASCS e ERS. Questo passaggio è applicabile solo se systemd gestisce il framework di avvio SAP in base alla nota SAP 3115048.

Nota

Quando si gestiscono istanze SAP come SAP ASCS e SAP ERS usando la configurazione del cluster SLES, è necessario apportare altre modifiche per integrare il cluster con il framework di avvio SAP nativo basato su sistema per garantire che le procedure di manutenzione non compromettereno la stabilità del cluster. Dopo l'installazione o il passaggio del framework di avvio SAP alla configurazione abilitata per systemd in base alla nota SAP 3115048, è necessario disabilitare i servizi systemd per le istanze di SAP ASCS e ERS.
```
# Stop all ASCS and ERS instances using <sid>adm
sapcontrol -nr 10 -function Stop
sapcontrol -nr 10 -function StopService

sapcontrol -nr 12 -function Stop
sapcontrol -nr 12 -function StopService

# Execute below command on VM where you have performed ASCS instance installation for each SAP system (e.g. slesmsscl1)
sudo systemctl disable SAPNW2_10
sudo systemctl disable SAPNW3_20
# Execute below command on VM where you have performed ERS instance installation for each SAP system (e.g. slesmsscl2)
sudo systemctl disable SAPNW2_12
sudo systemctl disable SAPNW2_22
```

[1] Creare le risorse del cluster SAP per il sistema SAP appena installato.

A seconda che si esegua un sistema ENSA1 o ENSA2, selezionare la rispettiva scheda per definire le risorse per i sistemi NW2 e NW3 . SAP ha introdotto il supporto per ENSA2, inclusa la replica, in SAP NetWeaver 7.52. A partire da ABAP Platform 1809, ENSA2 viene installato per impostazione predefinita. Per il supporto di ENSA2, vedere la nota SAP 2630416.

ENSA1
ENSA2

sudo crm configure property maintenance-mode="true"

sudo crm configure primitive rsc_sap_NW2_ASCS10 SAPInstance \
  operations \$id=rsc_sap_NW2_ASCS10-operations \
  op monitor interval=11 timeout=60 on-fail=restart \
  params InstanceName=NW2_ASCS10_msnw2ascs START_PROFILE="/sapmnt/NW2/profile/NW2_ASCS10_msnw2ascs" \
  AUTOMATIC_RECOVER=false \
  meta resource-stickiness=5000 failure-timeout=60 migration-threshold=1 priority=10

sudo crm configure primitive rsc_sap_NW2_ERS12 SAPInstance \
  operations \$id=rsc_sap_NW2_ERS12-operations \
  op monitor interval=11 timeout=60 on-fail=restart \
  params InstanceName=NW2_ERS12_msnw2ers START_PROFILE="/sapmnt/NW2/profile/NW2_ERS12_msnw2ers" AUTOMATIC_RECOVER=false IS_ERS=true \
  meta priority=1000

sudo crm configure modgroup g-NW2_ASCS add rsc_sap_NW2_ASCS10
sudo crm configure modgroup g-NW2_ERS add rsc_sap_NW2_ERS12

sudo crm configure colocation col_sap_NW2_no_both -5000: g-NW2_ERS g-NW2_ASCS
sudo crm configure location loc_sap_NW2_failover_to_ers rsc_sap_NW2_ASCS10 rule 2000: runs_ers_NW2 eq 1
sudo crm configure order ord_sap_NW2_first_start_ascs Optional: rsc_sap_NW2_ASCS10:start rsc_sap_NW2_ERS12:stop symmetrical=false

sudo crm configure primitive rsc_sap_NW3_ASCS20 SAPInstance \
  operations \$id=rsc_sap_NW3_ASCS20-operations \
  op monitor interval=11 timeout=60 on-fail=restart \
  params InstanceName=NW3_ASCS10_msnw3ascs START_PROFILE="/sapmnt/NW3/profile/NW3_ASCS20_msnw3ascs" \
  AUTOMATIC_RECOVER=false \
  meta resource-stickiness=5000 failure-timeout=60 migration-threshold=1 priority=10

sudo crm configure primitive rsc_sap_NW3_ERS22 SAPInstance \
  operations \$id=rsc_sap_NW3_ERS22-operations \
  op monitor interval=11 timeout=60 on-fail=restart \
  params InstanceName=NW3_ERS22_msnw3ers START_PROFILE="/sapmnt/NW3/profile/NW3_ERS22_msnw2ers" AUTOMATIC_RECOVER=false IS_ERS=true \
  meta priority=1000

sudo crm configure modgroup g-NW3_ASCS add rsc_sap_NW3_ASCS20
sudo crm configure modgroup g-NW3_ERS add rsc_sap_NW3_ERS22

sudo crm configure colocation col_sap_NW3_no_both -5000: g-NW3_ERS g-NW3_ASCS
sudo crm configure location loc_sap_NW3_failover_to_ers rsc_sap_NW3_ASCS10 rule 2000: runs_ers_NW3 eq 1
sudo crm configure order ord_sap_NW3_first_start_ascs Optional: rsc_sap_NW3_ASCS20:start rsc_sap_NW3_ERS22:stop symmetrical=false
sudo crm configure property maintenance-mode="false"

sudo crm configure property maintenance-mode="true"

sudo crm configure primitive rsc_sap_NW2_ASCS10 SAPInstance \
  operations \$id=rsc_sap_NW2_ASCS10-operations \
  op monitor interval=11 timeout=60 on-fail=restart \
  params InstanceName=NW2_ASCS10_msnw2ascs START_PROFILE="/sapmnt/NW2/profile/NW2_ASCS10_msnw2ascs" \
  AUTOMATIC_RECOVER=false \
  meta resource-stickiness=5000

sudo crm configure primitive rsc_sap_NW2_ERS12 SAPInstance \
  operations \$id=rsc_sap_NW2_ERS12-operations \
  op monitor interval=11 timeout=60 on-fail=restart \
  params InstanceName=NW2_ERS12_msnw2ers START_PROFILE="/sapmnt/NW2/profile/NW2_ERS12_msnw2ers" AUTOMATIC_RECOVER=false IS_ERS=true

sudo crm configure modgroup g-NW2_ASCS add rsc_sap_NW2_ASCS10
sudo crm configure modgroup g-NW2_ERS add rsc_sap_NW2_ERS12

sudo crm configure colocation col_sap_NW2_no_both -5000: g-NW2_ERS g-NW2_ASCS
sudo crm configure order ord_sap_NW2_first_start_ascs Optional: rsc_sap_NW2_ASCS10:start rsc_sap_NW2_ERS12:stop symmetrical=false

sudo crm configure primitive rsc_sap_NW3_ASCS20 SAPInstance \
  operations \$id=rsc_sap_NW3_ASCS20-operations \
  op monitor interval=11 timeout=60 on-fail=restart \
  params InstanceName=NW3_ASCS10_msnw3ascs START_PROFILE="/sapmnt/NW3/profile/NW3_ASCS20_msnw3ascs" \
  AUTOMATIC_RECOVER=false \
  meta resource-stickiness=5000

sudo crm configure primitive rsc_sap_NW3_ERS22 SAPInstance \
  operations \$id=rsc_sap_NW3_ERS22-operations \
  op monitor interval=11 timeout=60 on-fail=restart \
  params InstanceName=NW3_ERS22_msnw3ers START_PROFILE="/sapmnt/NW3/profile/NW3_ERS22_msnw2ers" AUTOMATIC_RECOVER=false IS_ERS=true

sudo crm configure modgroup g-NW3_ASCS add rsc_sap_NW3_ASCS20
sudo crm configure modgroup g-NW3_ERS add rsc_sap_NW3_ERS22

sudo crm configure colocation col_sap_NW3_no_both -5000: g-NW3_ERS g-NW3_ASCS
sudo crm configure order ord_sap_NW3_first_start_ascs Optional: rsc_sap_NW3_ASCS20:start rsc_sap_NW3_ERS22:stop symmetrical=false
sudo crm configure property maintenance-mode="false"

Se si effettua l'aggiornamento da una versione precedente e si passa al server di accodamento 2, consulta la nota SAP 2641019.

Assicurarsi che lo stato del cluster sia OK e che tutte le risorse vengano avviate. Non è importante il nodo su cui sono in esecuzione le risorse.

Nell'esempio seguente viene illustrato lo stato delle risorse del cluster, dopo che i sistemi SAP NW2 ed NW3 sono stati aggiunti al cluster.

sudo crm_mon -r

# Online: [ slesmsscl1 slesmsscl2 ]

#Full list of resources:

#stonith-sbd     (stonith:external/sbd): Started slesmsscl1
# Resource Group: g-NW1_ASCS
#     fs_NW1_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl2
#     nc_NW1_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl2
#     vip_NW1_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl2
#     rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance):   Started slesmsscl2
# Resource Group: g-NW1_ERS
#     fs_NW1_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
#     nc_NW1_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
#     vip_NW1_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
#     rsc_sap_NW1_ERS02  (ocf::heartbeat:SAPInstance):   Started slesmsscl1
# Resource Group: g-NW2_ASCS
#     fs_NW2_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
#     nc_NW2_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
#     vip_NW2_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
#     rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
# Resource Group: g-NW2_ERS
#     fs_NW2_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl2
#     nc_NW2_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl2
#     vip_NW2_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl2
#     rsc_sap_NW2_ERS12  (ocf::heartbeat:SAPInstance):   Started slesmsscl2
# Resource Group: g-NW3_ASCS
#     fs_NW3_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
#     nc_NW3_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
#     vip_NW3_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
#     rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
# Resource Group: g-NW3_ERS
#     fs_NW3_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl2
#     nc_NW3_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl2
#     vip_NW3_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl2
#     rsc_sap_NW3_ERS22  (ocf::heartbeat:SAPInstance):   Started slesmsscl2

L'immagine seguente mostra l'aspetto delle risorse in Konsole Web a disponibilità elevata (HAWK), con le risorse per il sistema SAP NW2 espanse.

Procedere con l'installazione di SAP

Completare l'installazione di SAP tramite:

Preparazione dei server applicazioni SAP NetWeaver
Installazione di un'istanza di DBMS
Installazione di un server applicazioni SAP primario
Installazione di istanze di applicazioni SAP aggiuntive

Testare l'impostazione del cluster multi-SID

I test seguenti sono un subset dei test case nelle guide alle procedure consigliate di SUSE. Sono inclusi per comodità. Per l'elenco completo dei test del cluster, vedere la documentazione seguente:

Se si utilizza un server NFS ad alta disponibilità, seguire Alta disponibilità per SAP NetWeaver su macchine virtuali Azure su SUSE Linux Enterprise Server per applicazioni SAP.
Se si usano i volumi NFS di Azure NetApp Files, seguire Disponibilità elevata per SAP NetWeaver nelle macchine virtuali di Azure in SUSE Linux Enterprise Server con Azure NetApp Files per applicazioni SAP

Leggere sempre le guide alle procedure consigliate di SUSE ed eseguire tutti i test in base alle esigenze. I test presentati si trovano in un cluster a due nodi multi-SID con tre sistemi SAP installati.

Testare HAGetFailoverConfig e HACheckFailoverConfig

Eseguire i comandi seguenti come <sapsid>adm nel nodo di cui è in esecuzione l'istanza di ASCS. Se sono presenti trattini nel nome host, i comandi potrebbero non riuscire con FAIL: Memoria insufficiente (un problema noto). SUSE ha intenzione di correggerlo nel pacchetto sap-suse-cluster-connector.

 slesmsscl1:nw1adm 57> sapcontrol -nr 00 -function HAGetFailoverConfig

# 10.12.2019 21:33:08
# HAGetFailoverConfig
# OK
# HAActive: TRUE
# HAProductVersion: SUSE Linux Enterprise Server for SAP Applications 12 SP4
# HASAPInterfaceVersion: SUSE Linux Enterprise Server for SAP Applications 12 SP4 (sap_suse_cluster_connector 3.1.0)
# HADocumentation: https://www.suse.com/products/sles-for-sap/resource-library/sap-best-practices/
# HAActiveNode: slesmsscl1
# HANodes: slesmsscl1, slesmsscl2

slesmsscl1:nw1adm 53> sapcontrol -nr 00 -function HACheckFailoverConfig

# 19.12.2019 21:19:58
# HACheckFailoverConfig
# OK
# state, category, description, comment
# SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version, SAPInstance includes is-ers patch

slesmsscl2:nw2adm 35> sapcontrol -nr 10 -function HAGetFailoverConfig

# 10.12.2019 21:37:09
# HAGetFailoverConfig
# OK
# HAActive: TRUE
# HAProductVersion: SUSE Linux Enterprise Server for SAP Applications 12 SP4
# HASAPInterfaceVersion: SUSE Linux Enterprise Server for SAP Applications 12 SP4 (sap_suse_cluster_connector 3.1.0)
# HADocumentation: https://www.suse.com/products/sles-for-sap/resource-library/sap-best-practices/
# HAActiveNode: slesmsscl2
# HANodes: slesmsscl2, slesmsscl1

slesmsscl2:nw2adm 52> sapcontrol -nr 10 -function HACheckFailoverConfig

# 19.12.2019 21:17:39
# HACheckFailoverConfig
# OK
# state, category, description, comment
# SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version, SAPInstance includes is-ers patch

slesmsscl1:nw3adm 49> sapcontrol -nr 20 -function HAGetFailoverConfig

# 10.12.2019 23:35:36
# HAGetFailoverConfig
# OK
# HAActive: TRUE
# HAProductVersion: SUSE Linux Enterprise Server for SAP Applications 12 SP4
# HASAPInterfaceVersion: SUSE Linux Enterprise Server for SAP Applications 12 SP4 (sap_suse_cluster_connector 3.1.0)
# HADocumentation: https://www.suse.com/products/sles-for-sap/resource-library/sap-best-practices/
# HAActiveNode: slesmsscl1
# HANodes: slesmsscl1, slesmsscl2

slesmsscl1:nw3adm 52> sapcontrol -nr 20 -function HACheckFailoverConfig

# 19.12.2019 21:10:42
# HACheckFailoverConfig
# OK
# state, category, description, comment
# SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version, SAPInstance includes is-ers patch

Eseguire la migrazione manuale dell'istanza ASCS. L'esempio mostra la migrazione dell'istanza ASCS per il sistema SAP NW2.

Stato delle risorse prima dell'avvio del test:

 Full list of resources:
 stonith-sbd     (stonith:external/sbd): Started slesmsscl1
  Resource Group: g-NW1_ASCS
      fs_NW1_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW1_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW1_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW1_ERS
      fs_NW1_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW1_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW1_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW1_ERS02  (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW2_ASCS
      fs_NW2_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW2_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW2_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW2_ERS
      fs_NW2_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW2_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW2_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW2_ERS12  (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW3_ASCS
      fs_NW3_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW3_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW3_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW3_ERS
      fs_NW3_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW3_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW3_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW3_ERS22  (ocf::heartbeat:SAPInstance):   Started slesmsscl1

Eseguire i seguenti comandi come utente root per migrare l'istanza NW2 ASCS.

 crm resource migrate rsc_sap_NW2_ASCS10 force
 # INFO: Move constraint created for rsc_sap_NW2_ASCS10

 crm resource unmigrate rsc_sap_NW2_ASCS10
 # INFO: Removed migration constraints for rsc_sap_NW2_ASCS10

 # Remove failed actions for the ERS that occurred as part of the migration
 crm resource cleanup rsc_sap_NW2_ERS12

Stato delle risorse dopo il test:

 Full list of resources:
 stonith-sbd     (stonith:external/sbd): Started slesmsscl1
  Resource Group: g-NW1_ASCS
      fs_NW1_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW1_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW1_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW1_ERS
      fs_NW1_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW1_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW1_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW1_ERS02  (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW2_ASCS
      fs_NW2_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW2_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW2_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW2_ERS
      fs_NW2_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW2_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW2_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW2_ERS12  (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW3_ASCS
      fs_NW3_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW3_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW3_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW3_ERS
      fs_NW3_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW3_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW3_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW3_ERS22  (ocf::heartbeat:SAPInstance):   Started slesmsscl1

Eseguire il test HAFailoverToNode. Il test presentato qui mostra la migrazione dell'istanza ASCS per il sistema SAP NW2.

Stato delle risorse prima dell'avvio del test:

 Full list of resources:
 stonith-sbd     (stonith:external/sbd): Started slesmsscl1
  Resource Group: g-NW1_ASCS
      fs_NW1_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW1_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW1_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW1_ERS
      fs_NW1_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW1_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW1_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW1_ERS02  (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW2_ASCS
      fs_NW2_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW2_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW2_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW2_ERS
      fs_NW2_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW2_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW2_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW2_ERS12  (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW3_ASCS
      fs_NW3_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW3_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW3_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW3_ERS
      fs_NW3_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW3_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW3_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW3_ERS22  (ocf::heartbeat:SAPInstance):   Started slesmsscl1

Eseguire i comandi seguenti come nw2adm per eseguire la migrazione dell'istanza di ASCS NW2.

slesmsscl2:nw2adm 53> sapcontrol -nr 10 -host msnw2ascs -user nw2adm password -function HAFailoverToNode ""

# run as root
# Remove failed actions for the ERS that occurred as part of the migration
crm resource cleanup rsc_sap_NW2_ERS12

# Remove migration constraints
crm resource clear rsc_sap_NW2_ASCS10

#INFO: Removed migration constraints for rsc_sap_NW2_ASCS10

Stato delle risorse dopo il test:

 Full list of resources:
 stonith-sbd     (stonith:external/sbd): Started slesmsscl1
  Resource Group: g-NW1_ASCS
      fs_NW1_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW1_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW1_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW1_ERS
      fs_NW1_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW1_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW1_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW1_ERS02  (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW2_ASCS
      fs_NW2_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW2_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW2_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW2_ERS
      fs_NW2_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW2_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW2_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW2_ERS12  (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW3_ASCS
      fs_NW3_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW3_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW3_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW3_ERS
      fs_NW3_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW3_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW3_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW3_ERS22  (ocf::heartbeat:SAPInstance):   Started slesmsscl1

Simulare il crash del nodo

Stato delle risorse prima dell'avvio del test:

 Full list of resources:
 stonith-sbd     (stonith:external/sbd): Started slesmsscl1
  Resource Group: g-NW1_ASCS
      fs_NW1_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW1_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW1_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW1_ERS
      fs_NW1_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW1_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW1_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW1_ERS02  (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW2_ASCS
      fs_NW2_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW2_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW2_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW2_ERS
      fs_NW2_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW2_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW2_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW2_ERS12  (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW3_ASCS
      fs_NW3_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW3_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW3_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW3_ERS
      fs_NW3_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW3_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW3_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW3_ERS22  (ocf::heartbeat:SAPInstance):   Started slesmsscl1

Eseguire il comando seguente come radice nel nodo in cui è in esecuzione almeno un'istanza ASCS. In questo esempio è stato eseguito il comando in slesmsscl2, in cui sono in esecuzione le istanze ASCS per NW1 ed NW3.

slesmsscl2:~ # echo b > /proc/sysrq-trigger

Se si usa SBD, Pacemaker non deve essere avviato automaticamente nel nodo terminato. Lo stato dopo il riavvio del nodo dovrebbe essere simile al seguente.

 Online: [ slesmsscl1 ]
 OFFLINE: [ slesmsscl2 ]
 Full list of resources:

 stonith-sbd     (stonith:external/sbd): Started slesmsscl1
  Resource Group: g-NW1_ASCS
      fs_NW1_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW1_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW1_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW1_ERS
      fs_NW1_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW1_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW1_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW1_ERS02  (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW2_ASCS
      fs_NW2_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW2_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW2_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW2_ERS
      fs_NW2_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW2_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW2_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW2_ERS12  (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW3_ASCS
      fs_NW3_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW3_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW3_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW3_ERS
      fs_NW3_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW3_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW3_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW3_ERS22  (ocf::heartbeat:SAPInstance):   Started slesmsscl1

 Failed Resource Actions:
 * rsc_sap_NW1_ERS02_monitor_11000 on slesmsscl1 'not running' (7): call=125, status=complete, exitreason='',
     last-rc-change='Fri Dec 13 19:32:10 2019', queued=0ms, exec=0ms
 * rsc_sap_NW2_ERS12_monitor_11000 on slesmsscl1 'not running' (7): call=126, status=complete, exitreason='',
     last-rc-change='Fri Dec 13 19:32:10 2019', queued=0ms, exec=0ms
 * rsc_sap_NW3_ERS22_monitor_11000 on slesmsscl1 'not running' (7): call=127, status=complete, exitreason='',
     last-rc-change='Fri Dec 13 19:32:10 2019', queued=0ms, exec=0ms

Usare i comandi seguenti per avviare Pacemaker nel nodo terminato, pulire i messaggi SBD, quindi pulire la risorsa per la quale si è verificato un errore.

# run as root
# list the SBD device(s)
cat /etc/sysconfig/sbd | grep SBD_DEVICE=

# output is like:
# SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"

sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message slesmsscl2 clear

systemctl start pacemaker
crm resource cleanup rsc_sap_NW1_ERS02
crm resource cleanup rsc_sap_NW2_ERS12
crm resource cleanup rsc_sap_NW3_ERS22

Stato delle risorse dopo il test:

 Full list of resources:
 stonith-sbd     (stonith:external/sbd): Started slesmsscl1
  Resource Group: g-NW1_ASCS
      fs_NW1_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW1_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW1_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW1_ERS
      fs_NW1_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW1_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW1_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW1_ERS02  (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW2_ASCS
      fs_NW2_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW2_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW2_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW2_ERS
      fs_NW2_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW2_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW2_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW2_ERS12  (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW3_ASCS
      fs_NW3_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW3_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW3_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW3_ERS
      fs_NW3_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW3_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW3_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW3_ERS22  (ocf::heartbeat:SAPInstance):   Started slesmsscl2

Passaggi successivi

Pianificazione e implementazione delle Macchine Virtuali Azure per SAP
implementazione delle Macchine Virtuali di Azure per SAP
Azure Virtual Machines implementazione DBMS per SAP
Per informazioni su come stabilire la disponibilità elevata e pianificare il ripristino di emergenza di SAP HANA su macchine virtuali di Azure, vedere Alta Disponibilità di SAP HANA su Macchine Virtuali di Azure (VM)

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-03-11

Condividi tramite

Disponibilità elevata per SAP NetWeaver in macchine virtuali Azure su SUSE Linux Enterprise Server per applicazioni SAP multi-SID

Panoramica

Condivisioni SAP NFS

Distribuire il primo sistema SAP nel cluster

Distribuire più sistemi SAP nel cluster

Prerequisiti

Preparare l'installazione di SAP NetWeaver

Installare ASCS/ERS

Procedere con l'installazione di SAP

Testare l'impostazione del cluster multi-SID

Passaggi successivi

Commenti e suggerimenti

Risorse aggiuntive