Questa guida mostra come eseguire il deployment e configurare un cluster ad alta disponibilità (HA) Red Hat Enterprise Linux (RHEL) ottimizzato per le prestazioni per il sistema SAP NetWeaver.
Questa guida illustra i passaggi per:- Configurazione di un bilanciatore del carico di rete passthrough interno per reinstradare il traffico in caso di errore
- La configurazione di un cluster Pacemaker su RHEL per gestire i sistemi SAP e altre risorse durante un failover
Questa guida include anche i passaggi per configurare il sistema SAP NetWeaver per l'alta disponibilità, ma fai riferimento alla documentazione SAP per le istruzioni definitive.
Per informazioni sul deployment delle VM di Compute Engine per SAP NetWeaver che non sono specifiche per l'alta disponibilità, consulta la guida al deployment di SAP NetWeaver specifica per il tuo sistema operativo.
Per configurare un cluster ad alta disponibilità per SAP NetWeaver su SUSE Linux Enterprise Server (SLES), consulta la guida alla configurazione manuale dei cluster ad alta disponibilità per SAP NetWeaver su SLES.
Questa guida è destinata agli utenti avanzati di SAP NetWeaver che hanno familiarità con le configurazioni Linux ad alta disponibilità per SAP NetWeaver.
Il sistema implementato da questa guida
Seguendo questa guida, eseguirai il deployment di due istanze SAP NetWeaver e configurerai un cluster ad alta disponibilità su RHEL. Esegui il deployment di ogni istanza SAP NetWeaver su una VM di Compute Engine in una zona diversa all'interno della stessa regione. Un'installazione ad alta disponibilità del database sottostante non è trattata in questa guida.
Il cluster di cui è stato eseguito il deployment include le seguenti funzioni e caratteristiche:
- Due VM host, una per l'istanza ASCS attiva e una per l'istanza attiva del replicatore di accodamento ENSA2 o del server di replica di accodamento ENSA1 (ENSA1). Entrambe le istanze ENSA2 e ENSA1 sono chiamate ERS.
- Gestore delle risorse del cluster ad alta disponibilità Pacemaker.
- Un meccanismo di scherma STONITH.
- Riavvio automatico dell'istanza non riuscita come nuova istanza secondaria.
Per utilizzare Terraform per automatizzare il deployment di sistemi SAP NetWeaver ad alta disponibilità, consulta Terraform: guida alla configurazione dei cluster ad alta disponibilità per SAP NetWeaver su RHEL.
Prerequisiti
Prima di creare il cluster SAP NetWeaver ad alta disponibilità, assicurati che siano soddisfatti i seguenti prerequisiti:
- Hai letto la guida alla pianificazione di SAP NetWeaver e la guida alla pianificazione dell'alta disponibilità per SAP NetWeaver su Google Cloud.
- Tu o la tua organizzazione disponete di un account Google Cloud e avete creato un progetto per il deployment di SAP NetWeaver. Per informazioni sulla creazione di account e progetti Google Cloud, consulta Creazione di un progetto nella Guida al deployment di SAP NetWeaver per Linux.
- Se richiedi l'esecuzione del carico di lavoro SAP in conformità con i requisiti di residenza dei dati, controllo dell'accesso, personale di assistenza o normativi, devi creare la cartella Assured Workloads richiesta. Per ulteriori informazioni, consulta la pagina Conformità e controlli di sovranità per SAP su Google Cloud.
Se utilizzi DNS interno VPC, il valore della variabile
vmDnsSetting
nei metadati di progetto deve essereGlobalOnly
oZonalPreferred
per abilitare la risoluzione dei nomi dei nodi tra le zone. L'impostazione predefinita divmDnsSetting
èZonalOnly
. Per ulteriori informazioni, consulta:Hai configurato una condivisione file utilizzando una soluzione di archiviazione file condivisa NFS, come Filestore Enterprise.
Se OS Login è abilitato nei metadati di progetto, devi disattivarlo temporaneamente fino al completamento del deployment. Ai fini del deployment, questa procedura configura le chiavi SSH nei metadati dell'istanza. Quando l'accesso al sistema operativo è abilitato, le configurazioni delle chiavi SSH basate su metadati vengono disabilitate e questo deployment non riesce. Al termine del deployment, puoi abilitare di nuovo OS Login.
Per ulteriori informazioni, consulta:
Informazioni correlate da RHEL
Ad eccezione di dove richiesto per l'ambiente Google Cloud, le informazioni contenute in questa guida sono coerenti con le seguenti guide correlate di Red Hat e SAP:
- Configura SAP NetWeaver ASCS/ERS ENSA1 con risorse autonome in RHEL 7.5 e versioni successive e RHEL 8
- Configura SAP S/4HANA ASCS/ERS con accodamento autonomo 2 (ENSA2) in Pacemaker
- SAP Note 2002167 - Red Hat Enterprise Linux 7.x: Installazione e upgrade
- SAP Note 2772999 - Red Hat Enterprise Linux 8.x: Installazione e configurazione
- SAP Note 3108316 - Red Hat Enterprise Linux 9.x: installazione e configurazione
- SAP Note 2641322 - Installazione di ENSA2 e aggiornamento da ENSA1 a ENSA2 quando si utilizzano le soluzioni Red Hat HA per SAP
Creare una rete
Per motivi di sicurezza, crea una nuova rete. Puoi controllare chi ha accesso aggiungendo regole firewall o utilizzando un altro metodo di controllo dell'accesso.
Se il progetto ha una rete VPC predefinita, non utilizzarla. Crea invece la tua rete VPC in modo che le uniche regole firewall in vigore siano quelle create in modo esplicito.
Durante il deployment, le istanze VM in genere richiedono l'accesso a internet per scaricare l'agente di Google Cloud per SAP. Se utilizzi una delle immagini Linux certificate SAP disponibili su Google Cloud, l'istanza VM richiede anche l'accesso a internet per registrare la licenza e accedere ai repository dei fornitori di sistemi operativi. Questo accesso è supportato da una configurazione con un gateway NAT e tag di rete VM, anche se le VM di destinazione non hanno IP esterni.
Per configurare il networking:
Console
- Nella console Google Cloud, vai alla pagina Reti VPC.
- Fai clic su Crea rete VPC.
- Inserisci un nome per la rete.
Il nome deve rispettare la convenzione di denominazione. Le reti VPC utilizzano la convenzione di denominazione di Compute Engine.
- In Modalità di creazione subnet, scegli Personalizzata.
- Nella sezione Nuova subnet, specifica i seguenti parametri di configurazione per una
subnet:
- Inserisci un nome per la subnet.
- In Regione, seleziona la regione di Compute Engine in cui vuoi creare la subnet.
- Per Tipo di stack IP, seleziona IPv4 (stack singolo) e inserisci un intervallo di indirizzi IP nel formato CIDR, ad esempio
10.1.0.0/24
.Questo è l'intervallo IPv4 principale per la subnet. Se prevedi di aggiungere più di una subnet, assegna intervalli IP CIDR non sovrapposti per ogni subnet nella rete. Tieni presente che ogni subnet e i relativi intervalli IP interni sono mappati a una singola regione.
- Fai clic su Fine.
- Per aggiungere altre subnet, fai clic su Aggiungi subnet e ripeti i passaggi precedenti. Puoi aggiungere altre subnet alla rete dopo aver creato la rete.
- Fai clic su Crea.
gcloud
- Vai a Cloud Shell.
- Per creare una nuova rete in modalità subnet personalizzate, esegui:
gcloud compute networks create NETWORK_NAME --subnet-mode custom
Sostituisci
NETWORK_NAME
con il nome della nuova rete. Il nome deve rispettare la convenzione di denominazione. Le reti VPC utilizzano la convenzione di denominazione di Compute Engine.Specifica
--subnet-mode custom
per evitare di utilizzare la modalità automatica predefinita, che crea automaticamente una subnet in ogni regione di Compute Engine. Per maggiori informazioni, vedi Modalità di creazione subnet. - Crea una subnet e specifica la regione e l'intervallo IP:
gcloud compute networks subnets create SUBNETWORK_NAME \ --network NETWORK_NAME --region REGION --range RANGE
Sostituisci quanto segue:
SUBNETWORK_NAME
: il nome della nuova subnetNETWORK_NAME
: il nome della rete che hai creato nel passaggio precedenteREGION
: la regione in cui vuoi la subnetRANGE
: l'intervallo di indirizzi IP, specificato in formato CIDR, ad esempio10.1.0.0/24
Se prevedi di aggiungere più di una subnet, assegna intervalli IP CIDR non sovrapposti per ogni subnet nella rete. Tieni presente che ogni subnet e i relativi intervalli IP interni sono mappati a una singola regione.
- Se vuoi, ripeti il passaggio precedente e aggiungi altre subnet.
Configurazione di un gateway NAT
Se devi creare una o più VM senza indirizzi IP pubblici, devi utilizzare Network Address Translation (NAT) per consentire alle VM di accedere a internet. Utilizza Cloud NAT, un servizio gestito distribuito e software-defined di Google Cloud, che consente alle VM di inviare pacchetti in uscita a internet e ricevere tutti i pacchetti di risposta in entrata stabiliti corrispondenti. In alternativa, puoi configurare una VM separata come gateway NAT.
Per creare un'istanza Cloud NAT per il tuo progetto, consulta Utilizzo di Cloud NAT.
Dopo aver configurato Cloud NAT per il tuo progetto, le istanze VM possono accedere in modo sicuro a internet senza un indirizzo IP pubblico.
aggiungi regole firewall
Per impostazione predefinita, le connessioni in entrata dall'esterno della rete Google Cloud sono bloccate. Per consentire le connessioni in entrata, configura una regola firewall per la VM. Le regole firewall regolano solo le nuove connessioni in entrata a una VM. Dopo aver stabilito una connessione con una VM, il traffico viene consentito in entrambe le direzioni su questa connessione.
Puoi creare una regola firewall per consentire l'accesso a porte specifiche o per consentire l'accesso tra VM nella stessa subnet.
Crea regole firewall per consentire l'accesso a:
- Le porte predefinite utilizzate da SAP NetWeaver, come documentato in Porte TCP/IP di tutti i prodotti SAP.
- Connessioni dal computer o dall'ambiente di rete aziendale alla tua istanza VM di Compute Engine. Se hai dubbi in merito all'indirizzo IP da usare, rivolgiti all'amministratore di rete della tua azienda.
- Comunicazione tra le VM in una configurazione a 3 livelli, con scale out o ad alta disponibilità. Ad esempio, se esegui il deployment di un sistema a 3 livelli, avrai almeno due VM nella tua subnet: la VM per SAP NetWeaver e un'altra VM per il server di database. Per abilitare la comunicazione tra le due VM, devi creare una regola firewall per consentire il traffico proveniente dalla subnet.
- Controlli di integrità di Cloud Load Balancing. Per maggiori informazioni, consulta Creare una regola firewall per i controlli di integrità.
Per creare una regola firewall:
Nella console Google Cloud, vai alla pagina Firewall della rete VPC.
Nella parte superiore della pagina, fai clic su Crea regola firewall.
- Nel campo Rete, seleziona la rete in cui si trova la VM.
- Nel campo Destinazioni, seleziona Tutte le istanze nella rete.
- Nel campo Filtro di origine, seleziona una delle seguenti opzioni:
- Intervalli IP per consentire il traffico in entrata da indirizzi IP specifici. Specifica l'intervallo di indirizzi IP nel campo Intervalli IP di origine.
- Subnet per consentire il traffico in entrata da una determinata subnet. Specifica il nome della subnet nel seguente campo delle subnet. Puoi utilizzare questa opzione per consentire l'accesso tra le VM in una configurazione a 3 livelli o con scale out.
- Nella sezione Protocolli e porte, seleziona Protocolli e porte specificati e specifica
tcp:PORT_NUMBER;
.
Fai clic su Crea per creare la regola firewall.
Deployment delle VM per SAP NetWeaver
Prima di iniziare a configurare il cluster ad alta disponibilità, devi definire ed eseguire il deployment delle istanze VM che verranno utilizzate come nodi primari e secondari nel cluster ad alta disponibilità.
Per definire ed eseguire il deployment delle VM, utilizza lo stesso modello di Cloud Deployment Manager utilizzato per eseguire il deployment di una VM per un sistema SAP NetWeaver in Deployment automatico delle VM per SAP NetWeaver su Linux.
Tuttavia, per eseguire il deployment di due VM anziché una, devi aggiungere al file di configurazione la definizione della seconda VM copiandola e incollandola. Dopo aver creato la seconda definizione, devi modificare i nomi delle risorse e delle istanze nella seconda definizione. Per evitare un errore a livello di zona, specifica una zona diversa nella stessa regione. Tutti gli altri valori di proprietà nelle due definizioni rimangono invariati.
Una volta eseguito il deployment delle VM, devi installare SAP NetWeaver e definire e configurare il cluster ad alta disponibilità.
Le seguenti istruzioni utilizzano Cloud Shell, ma sono generalmente applicabili a Google Cloud CLI.
Apri Cloud Shell.
Scarica il modello del file di configurazione YAML,
template.yaml
, nella tua directory di lavoro:wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/template.yaml
Facoltativamente, rinomina il file
template.yaml
per identificare la configurazione che definisce. Ad esempio,nw-ha-rhel-8-4.yaml
.Apri il file di configurazione YAML nell'editor di codice di Cloud Shell facendo clic sull'icona a forma di matita (edit) nell'angolo in alto a destra della finestra del terminale Cloud Shell per avviare l'editor.
Nel modello del file di configurazione YAML, definisci la prima istanza VM. Definirai la seconda istanza VM nel passaggio successivo dopo la tabella seguente.
Specifica i valori delle proprietà sostituendo le parentesi e i relativi contenuti con i valori relativi alla tua installazione. Le proprietà sono descritte nella tabella seguente. Per un esempio di un file di configurazione completato, vedi Esempio di un file di configurazione YAML completo.
Proprietà Tipo di dati Descrizione name
String Un nome arbitrario che identifica la risorsa di deployment definita dal seguente insieme di proprietà. type
String Specifica la località, il tipo e la versione del modello di Deployment Manager da utilizzare durante il deployment.
Il file YAML include due specifiche
type
, una delle quali è commentata. La specificatype
attiva per impostazione predefinita specifica la versione del modello comelatest
. La specificatype
che viene commentata specifica una versione specifica del modello con un timestamp.Se vuoi che tutti i tuoi deployment utilizzino la stessa versione del modello, usa la specifica
type
che include il timestamp.instanceName
String Il nome dell'istanza VM che stai definendo. Specifica nomi diversi nelle definizioni della VM primaria e secondaria. Valuta la possibilità di utilizzare nomi che identificano le istanze come appartenenti allo stesso cluster ad alta disponibilità. I nomi delle istanze devono contenere al massimo 13 caratteri ed essere specificati in lettere minuscole, numeri o trattini. Utilizza un nome univoco all'interno del progetto.
instanceType
String Il tipo di VM di Compute Engine di cui hai bisogno. Specifica lo stesso tipo di istanza per la VM principale e quella secondaria. Se hai bisogno di un tipo di VM personalizzata, specifica un tipo di VM predefinito di piccole dimensioni e, al termine del deployment, personalizza la VM in base alle tue esigenze.
zone
String La zona Google Cloud in cui eseguire il deployment dell'istanza VM che stai definendo. Specifica zone diverse nella stessa regione per le definizioni della VM principale e secondaria. Le zone devono trovarsi nella stessa regione selezionata per la subnet. subnetwork
String Il nome della subnet che hai creato in un passaggio precedente. Se esegui il deployment in un VPC condiviso, specifica questo valore come SHAREDVPC_PROJECT/SUBNETWORK
. Ad esempio,myproject/network1
.linuxImage
String Il nome dell'immagine o della famiglia di immagini del sistema operativo Linux che utilizzi con SAP NetWeaver. Per specificare una famiglia di immagini, aggiungi il prefisso family/
al cognome. Ad esempio,family/rhel-8-4-sap-ha
. Per l'elenco delle famiglie di immagini disponibili, consulta la pagina Immagini nella console Google Cloud.linuxImageProject
String Il progetto Google Cloud che contiene l'immagine che utilizzerai. Questo progetto potrebbe essere tuo o il progetto immagine Google Cloud rhel-sap-cloud
. Per un elenco dei progetti immagine di Google Cloud, consulta la pagina Immagini nella documentazione di Compute Engine.usrsapSize
Integer Le dimensioni del disco /usr/sap
. La dimensione minima è 8 GB.sapmntSize
Integer Le dimensioni del disco /sapmnt
. La dimensione minima è 8 GB.swapSize
Integer La dimensione del volume di scambio. La dimensione minima è 1 GB. networkTag
String Facoltativo. Uno o più tag di rete separati da virgole che rappresentano l'istanza VM ai fini del firewall o del routing.
Per le configurazioni ad alta disponibilità, specifica un tag di rete da utilizzare per una regola firewall che consenta la comunicazione tra i nodi del cluster e un tag di rete da utilizzare in una regola firewall che consenta ai controlli di integrità di Cloud Load Balancing di accedere ai nodi del cluster.
Se specifichi
publicIP: No
e non specifichi un tag di rete, assicurati di fornire un altro mezzo di accesso a internet.serviceAccount
String Facoltativo. Specifica un account di servizio personalizzato da utilizzare per la VM di cui è stato eseguito il deployment. L'account di servizio deve includere le autorizzazioni necessarie durante il deployment per configurare la VM per SAP.
Se
serviceAccount
non è specificato, viene utilizzato l'account di servizio Compute Engine predefinito.Specifica l'indirizzo completo dell'account di servizio. Ad esempio,
sap-ha-example@example-project-123456.iam.gserviceaccount.com
publicIP
Booleano Facoltativo. Determina se un indirizzo IP pubblico viene aggiunto alla tua istanza VM. Il valore predefinito è Yes
.sap_deployment_debug
Booleano Facoltativo. Se questo valore è impostato su Yes
, il deployment genera log di deployment dettagliati. Non attivare questa impostazione a meno che un tecnico del servizio di assistenza Google non ti chieda di abilitare il debug.Nel file di configurazione YAML, crea la definizione della seconda VM copiando la definizione della prima VM e incollandola dopo la prima. Per un esempio, consulta Esempio di file di configurazione YAML completo.
Nella definizione della seconda VM, specifica valori diversi per le proprietà seguenti rispetto a quelli specificati nella prima definizione:
name
instanceName
zone
Crea le istanze VM:
gcloud deployment-manager deployments create DEPLOYMENT_NAME --config TEMPLATE_NAME.yaml
dove:
DEPLOYMENT_NAME
rappresenta il nome del tuo deployment.TEMPLATE_NAME
rappresenta il nome del file di configurazione YAML.
Il comando precedente richiama Deployment Manager, che esegue il deployment delle VM in base alle specifiche nel file di configurazione YAML.
L'elaborazione del deployment prevede due fasi. Nella prima fase, Deployment Manager scrive il proprio stato nella console. Nella seconda fase, gli script di deployment scrivono il proprio stato in Cloud Logging.
Esempio di un file di configurazione YAML completo
L'esempio seguente mostra un file di configurazione YAML completato che esegue il deployment di due istanze VM per una configurazione ad alta disponibilità per SAP NetWeaver utilizzando la versione più recente dei modelli di Deployment Manager. Nell'esempio vengono omessi i commenti contenuti nel modello quando viene scaricato per la prima volta.
Il file contiene le definizioni di due risorse di cui eseguire il deployment:
sap_nw_node_1
e sap_nw_node_2
. Ogni definizione di risorsa contiene
le definizioni di una VM.
La definizione della risorsa sap_nw_node_2
è stata creata copiando e incollando
la prima definizione, poi modificando i valori delle proprietà name
,
instanceName
e zone
. Tutti gli altri valori delle proprietà
nelle due definizioni della risorsa sono uguali.
Le proprietà networkTag
e serviceAccount
provengono dalla sezione Opzioni
avanzate del modello di file di configurazione.
resources: - name: sap_nw_node_1 type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/sap_nw.py properties: instanceName: nw-ha-vm-1 instanceType: n2-standard-4 zone: us-central1-b subnetwork: example-sub-network-sap linuxImage: family/rhel-8-4-sap-ha linuxImageProject: rhel-sap-cloud usrsapSize: 15 sapmntSize: 15 swapSize: 24 networkTag: cluster-ntwk-tag,allow-health-check serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com - name: sap_nw_node_2 type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/sap_nw.py properties: instanceName: nw-ha-vm-2 instanceType: n2-standard-4 zone: us-central1-c subnetwork: example-sub-network-sap linuxImage: family/rhel-8-4-sap-ha linuxImageProject: rhel-sap-cloud usrsapSize: 15 sapmntSize: 15 swapSize: 24 networkTag: cluster-ntwk-tag,allow-health-check serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com
Crea regole firewall che consentano l'accesso alle VM host
Se non lo hai già fatto, crea regole firewall che consentano l'accesso a ogni VM host dalle seguenti origini:
- Ai fini della configurazione, la tua workstation locale, un bastion host o un jump server
- Per l'accesso tra i nodi del cluster, le altre VM host nel cluster ad alta disponibilità
- I controlli di integrità utilizzati da Cloud Load Balancing, come descritto nel passaggio successivo Creare una regola firewall per i controlli di integrità.
Quando crei regole firewall VPC, specifichi i tag di rete definiti nel file di configurazione template.yaml
per designare le VM host come target della regola.
Per verificare il deployment, definisci una regola per consentire le connessioni SSH sulla porta 22 da un bastion host o dalla tua workstation locale.
Per l'accesso tra i nodi del cluster, aggiungi una regola firewall che consenta tutti i tipi di connessioni su qualsiasi porta da altre VM nella stessa subnet.
Assicurati che le regole firewall per la verifica del deployment e per la comunicazione intra-cluster vengano create prima di passare alla sezione successiva. Per le istruzioni, consulta Aggiungere regole firewall.
Verifica del deployment delle VM
Prima di installare SAP NetWeaver o di iniziare a configurare il cluster ad alta disponibilità, verifica che il deployment delle VM sia stato eseguito correttamente controllando i log e il mapping dello spazio di archiviazione del sistema operativo.
Controlla i log
Nella console Google Cloud, apri Cloud Logging per monitorare l'avanzamento dell'installazione e verificare la presenza di errori.
Filtra i log:
Esplora log
Nella pagina Esplora log, vai al riquadro Query.
Nel menu a discesa Risorsa, seleziona Globale, quindi fai clic su Aggiungi.
Se non vedi l'opzione Globale, inserisci la query seguente nell'editor di query:
resource.type="global" "Deployment"
Fai clic su Esegui query.
Visualizzatore log legacy
- Nella pagina Visualizzatore log legacy, dal menu del selettore di base, seleziona Globale come risorsa di logging.
Analizza i log filtrati:
- Se viene visualizzato
"--- Finished"
, l'elaborazione del deployment è completa e puoi passare al passaggio successivo. Se visualizzi un errore di quota:
Nella pagina Quote di IAM e amministrazione, aumenta le quote che non soddisfano i requisiti di SAP NetWeaver elencati nella guida alla pianificazione di SAP NetWeaver.
Nella pagina Deployment di Deployment Manager, elimina il deployment per ripulire le VM e i dischi permanenti dall'installazione non riuscita.
Esegui di nuovo il deployment.
- Se viene visualizzato
Controlla la configurazione delle VM
Dopo il deployment delle istanze VM, connettiti alle VM utilizzando
ssh
.- Se non l'hai ancora fatto, crea una regola firewall per consentire una connessione SSH sulla porta
22
. Vai alla pagina Istanze VM.
Connettiti a ciascuna istanza VM facendo clic sul pulsante SSH sulla voce di ogni istanza VM oppure puoi utilizzare il tuo metodo SSH preferito.
- Se non l'hai ancora fatto, crea una regola firewall per consentire una connessione SSH sulla porta
Visualizza il file system:
~>
df -hAssicurati che venga visualizzato un output simile al seguente:
Filesystem Size Used Avail Use% Mounted on devtmpfs 32G 8.0K 32G 1% /dev tmpfs 48G 0 48G 0% /dev/shm tmpfs 32G 402M 32G 2% /run tmpfs 32G 0 32G 0% /sys/fs/cgroup /dev/sda3 30G 3.4G 27G 12% / /dev/sda2 20M 3.7M 17M 19% /boot/efi /dev/mapper/vg_usrsap-vol 15G 48M 15G 1% /usr/sap /dev/mapper/vg_sapmnt-vol 15G 48M 15G 1% /sapmnt tmpfs 6.3G 0 6.3G 0% /run/user/1002 tmpfs 6.3G 0 6.3G 0% /run/user/0
Verifica che lo spazio di scambio sia stato creato:
~>
cat /proc/meminfo | grep SwapVedrai risultati simili all'esempio seguente:
SwapCached: 0 kB SwapTotal: 25161724 kB SwapFree: 25161724 kB
Se uno dei passaggi di convalida indica che l'installazione non è riuscita:
- Correggi l'errore.
- Nella pagina Deployment, elimina il deployment per pulire le VM e i dischi permanenti dall'installazione non riuscita.
- Esegui di nuovo il deployment.
Abilita la comunicazione back-end del bilanciatore del carico tra le VM
Dopo aver confermato che il deployment delle VM è stato eseguito correttamente, abilita la comunicazione backend tra le VM che verranno utilizzate come nodi nel cluster ad alta disponibilità.
Puoi abilitare la comunicazione backend tra le VM modificando la
configurazione dell'google-guest-agent
, che è incluso nell'ambiente guest Linux
per tutte le immagini pubbliche Linux fornite da Google Cloud.
Per abilitare le comunicazioni back-end del bilanciatore del carico, segui questi passaggi su ogni VM che fa parte del tuo cluster:
Interrompi l'agente:
sudo service google-guest-agent stop
Apri o crea il file
/etc/default/instance_configs.cfg
per la modifica. Ad esempio:sudo vi /etc/default/instance_configs.cfg
Nel file
/etc/default/instance_configs.cfg
, specifica le seguenti proprietà di configurazione come mostrato. Se le sezioni non esistono, creale. In particolare, assicurati che entrambe le proprietàtarget_instance_ips
eip_forwarding
siano impostate sufalse
:[IpForwarding] ethernet_proto_id = 66 ip_aliases = true target_instance_ips = false [NetworkInterfaces] dhclient_script = /sbin/google-dhclient-script dhcp_command = ip_forwarding = false setup = true
Avvia il servizio di agente ospite:
sudo service google-guest-agent start
La configurazione del controllo di integrità del bilanciatore del carico richiede sia una porta di destinazione di ascolto per il controllo di integrità sia l'assegnazione dell'IP virtuale a un'interfaccia. Per saperne di più, consulta Testare la configurazione del bilanciatore del carico.
Configura le chiavi SSH sulla VM principale e su quella secondaria
Per consentire la copia dei file tra gli host nel cluster ad alta disponibilità, i passaggi di questa sezione creano connessioni SSH radice tra i due host.
I modelli di Deployment Manager forniti da Google Cloud generano una chiave per te, ma puoi sostituirla con una chiave generata da te, se necessario.
È probabile che la tua organizzazione abbia stabilito linee guida che disciplinano le comunicazioni di rete interne. Se necessario, al termine del deployment puoi rimuovere
i metadati dalle VM e le chiavi dalla directory authorized_keys
.
Se la configurazione di connessioni SSH dirette non è conforme alle linee guida della tua organizzazione, puoi trasferire i file utilizzando altri metodi, ad esempio:
- Trasferisci file più piccoli attraverso la tua workstation locale utilizzando le opzioni dei menu Carica file e Scarica file di Cloud Shell. Vedi Gestire i file con Cloud Shell.
- Scambiare file utilizzando un bucket Cloud Storage. Vedi Caricamenti e download.
- Usa una soluzione di archiviazione file come Filestore o NetApp Cloud Volumes Service per creare una cartella condivisa. Vedi Soluzioni per la condivisione di file.
Per abilitare le connessioni SSH tra le istanze principali e secondarie, segui questi passaggi. I passaggi presuppongono che utilizzi la chiave SSH generata dai modelli di Deployment Manager per SAP.
Sulla VM host principale:
Connettiti alla VM tramite SSH.
Passa alla directory principale:
$
sudo su -Verifica che la chiave SSH esista:
#
ls -l /root/.ssh/Dovresti vedere i file chiave id_rsa come nell'esempio seguente:
-rw-r--r-- 1 root root 569 May 4 23:07 authorized_keys -rw------- 1 root root 2459 May 4 23:07 id_rsa -rw-r--r-- 1 root root 569 May 4 23:07 id_rsa.pub
Aggiorna i metadati della VM principale con informazioni sulla chiave SSH per la VM secondaria.
#
gcloud compute instances add-metadata SECONDARY_VM_NAME \ --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \ --zone SECONDARY_VM_ZONEVerifica che le chiavi SSH siano configurate correttamente aprendo una connessione SSH dal sistema principale al sistema secondario:
#
ssh SECONDARY_VM_NAME
Sulla VM host secondaria:
Accedi tramite SSH alla VM.
Passa alla directory principale:
$
sudo su -Verifica che la chiave SSH esista:
#
ls -l /root/.ssh/Dovresti vedere i file chiave id_rsa come nell'esempio seguente:
-rw-r--r-- 1 root root 569 May 4 23:07 authorized_keys -rw------- 1 root root 2459 May 4 23:07 id_rsa -rw-r--r-- 1 root root 569 May 4 23:07 id_rsa.pub
Aggiorna i metadati della VM secondaria con informazioni sulla chiave SSH per la VM principale.
#
gcloud compute instances add-metadata PRIMARY_VM_NAME \ --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \ --zone PRIMARY_VM_ZONE#
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keysVerifica che le chiavi SSH siano configurate correttamente aprendo una connessione SSH dal sistema secondario al sistema principale.
#
ssh PRIMARY_VM_NAME
Imposta l'archiviazione condivisa dei file e configura le directory condivise
Devi configurare una soluzione di condivisione file NFS che fornisca spazio di archiviazione condiviso ad alta disponibilità a cui possono accedere entrambi i nodi del tuo cluster ad alta disponibilità. Quindi, puoi creare directory su entrambi i nodi che vengono mappate allo spazio di archiviazione dei file condiviso. Il software cluster garantisce che le directory appropriate siano montate solo sulle istanze corrette.
La configurazione di una soluzione di condivisione file non è trattata in questa guida. Per istruzioni su come configurare il sistema di condivisione file, consulta le istruzioni fornite dal fornitore della soluzione selezionata. Se scegli di utilizzare Filestore per la tua soluzione di condivisione file, ti consigliamo di utilizzare il livello Enterprise di Filestore. Per informazioni su come creare un'istanza Filestore, consulta Creazione di istanze.
Per informazioni sulle soluzioni di condivisione file disponibili su Google Cloud, vedi Opzioni di archiviazione condivisa per sistemi SAP ad alta disponibilità su Google Cloud.
Per configurare le directory condivise:
Se non hai già configurato una soluzione di archiviazione file condivisa NFS ad alta disponibilità, fallo ora.
Monta l'archiviazione condivisa NFS su entrambi i server per la configurazione iniziale.
~>
sudo mkdir /mnt/nfs~>
sudo mount -t nfs NFS_PATH /mnt/nfsSostituisci
NFS_PATH
con il percorso della soluzione di condivisione file NFS. Ad esempio,10.49.153.26:/nfs_share_nw_ha
.Da entrambi i server, crea le directory per
sapmnt
, la directory centrale di trasporto e la directory specifica dell'istanza. Se utilizzi uno stack Java, sostituisci "ASCS" con "SCS" prima di utilizzare i seguenti e qualsiasi altro comando di esempio:~>
sudo mkdir /mnt/nfs/sapmntSID~>
sudo mkdir /mnt/nfs/usrsap{trans,SIDASCSASCS_INSTANCE_NUMBER,SIDERSERS_INSTANCE_NUMBER}Sostituisci quanto segue:
SID
: l'ID sistema SAP (SID). Utilizza lettere maiuscole per tutte le lettere. Ad esempio,AHA
.ASCS_INSTANCE_NUMBER
: il numero di istanza del sistema ASCS. Ad esempio,00
.ERS_INSTANCE_NUMBER
: il numero di istanza del sistema ERS. Ad esempio,10
.
Crea i punti di montaggio necessari su entrambi i server:
~>
sudo mkdir -p /sapmnt/SID~>
sudo mkdir -p /usr/sap/trans~>
sudo mkdir -p /usr/sap/SID/ASCSASCS_INSTANCE_NUMBER~>
sudo mkdir -p /usr/sap/SID/ERSERS_INSTANCE_NUMBERConfigura
autofs
per montare le directory comuni dei file condivisi al primo accesso alle directory dei file. Il montaggio delle directoryASCSASCS_INSTANCE_NUMBER
eERSERS_INSTANCE_NUMBER
è gestito dal software del cluster, che configurerai in un passaggio successivo.Modifica le opzioni NFS nei comandi in base alle esigenze della tua soluzione di condivisione file.
Configura
autofs
su entrambi i server:~>
echo "/- /etc/auto.sap" | sudo tee -a /etc/auto.master~>
NFS_OPTS="-rw,relatime,vers=3,hard,proto=tcp,timeo=600,retrans=2,mountvers=3,mountport=2050,mountproto=tcp"~>
echo "/sapmnt/SID ${NFS_OPTS} NFS_PATH/sapmntSID" | sudo tee -a /etc/auto.sap~>
echo "/usr/sap/trans ${NFS_OPTS} NFS_PATH/usrsaptrans" | sudo tee -a /etc/auto.sapPer ulteriori informazioni su
autofs
, consulta l'articolo Autofs - Come funziona.Avvia il servizio
autofs
su entrambi i server:~>
sudo systemctl enable autofs~>
sudo systemctl restart autofs~>
sudo automount -vAttiva
autofs
per montare le directory condivise accedendo a ciascuna directory con il comandocd
. Ad esempio:~>
cd /sapmnt/SID~>
cd /usr/sap/transDopo aver eseguito l'accesso a tutte le directory, esegui il comando
df -Th
per verificare che le directory siano montate.~>
df -Th | grep FILE_SHARE_NAMESostituisci
FILE_SHARE_NAME
con il nome della tua soluzione per la condivisione file NFS. Ad esempio,nfs_share_nw_ha
.Dovresti vedere punti di montaggio e directory simili a quanto segue:
10.49.153.26:/nfs_share_nw_ha nfs 1007G 76M 956G 1% /mnt/nfs 10.49.153.26:/nfs_share_nw_ha/usrsaptrans nfs 1007G 76M 956G 1% /usr/sap/trans 10.49.153.26:/nfs_share_nw_ha/sapmntAHA nfs 1007G 76M 956G 1% /sapmnt/AHA
Configurare il supporto per il failover di Cloud Load Balancing
Il servizio bilanciatore del carico di rete passthrough interno con supporto del failover instrada il traffico ASCS ed ERS alle istanze attive di ciascuna in un cluster SAP NetWeaver. I bilanciatori del carico di rete passthrough interni utilizzano indirizzi IP virtuali (VIP), servizi di backend, gruppi di istanze e controlli di integrità per instradare il traffico in modo appropriato.
Prenota gli indirizzi IP per gli IP virtuali
Per un cluster SAP NetWeaver ad alta disponibilità, puoi creare due VIP, a volte chiamati indirizzi IP fluttuanti. Un VIP segue l'istanza di SAP Central Services (SCS) attiva e l'altro segue l'istanza ERS (Enqueue Replication Server). Il bilanciatore del carico instrada il traffico inviato a ogni VIP alla VM che attualmente ospita l'istanza attiva del componente ASCS o ERS del VIP.
Apri Cloud Shell:
Prenota un indirizzo IP per l'IP virtuale dell'ASCS e per il VIP dell'ERS. Per ASCS, l'indirizzo IP è l'indirizzo IP utilizzato dalle applicazioni per accedere a SAP NetWeaver. Per ERS, l'indirizzo IP è l'indirizzo IP utilizzato per la replica del server di coda. Se ometti il flag
--addresses
, verrà scelto un indirizzo IP nella subnet specificata:~
gcloud compute addresses create ASCS_VIP_NAME \ --region CLUSTER_REGION --subnet CLUSTER_SUBNET \ --addresses ASCS_VIP_ADDRESS~
gcloud compute addresses create ERS_VIP_NAME \ --region CLUSTER_REGION --subnet CLUSTER_SUBNET \ --addresses ERS_VIP_ADDRESSSostituisci quanto segue:
ASCS_VIP_NAME
: specifica un nome per l'indirizzo IP virtuale dell'istanza ASCS. Ad esempio,ascs-aha-vip
.CLUSTER_REGION
: specifica la regione Google Cloud in cui si trova il cluster. Ad esempio,us-central1
CLUSTER_SUBNET
: specifica la subnet che utilizzi con il cluster. Ad esempio,example-sub-network-sap
.ASCS_VIP_ADDRESS
: facoltativamente, specifica un indirizzo IP per l'IP virtuale ASCS in notazione CIDR. Ad esempio,10.1.0.2
.ERS_VIP_NAME
: specifica un nome per l'indirizzo IP virtuale dell'istanza ERS. Ad esempio,ers-aha-vip
.ERS_VIP_ADDRESS
: se vuoi, specifica un indirizzo IP per l'IP virtuale ERS in notazione CIDR. Ad esempio,10.1.0.4
.
Per ulteriori informazioni sulla prenotazione di un IP statico, vedi Prenotare un indirizzo IP interno statico.
Conferma prenotazione dell'indirizzo IP:
~
gcloud compute addresses describe VIP_NAME \ --region CLUSTER_REGIONDovresti vedere un output simile all'esempio seguente:
address: 10.1.0.2 addressType: INTERNAL creationTimestamp: '2022-04-04T15:04:25.872-07:00' description: '' id: '555067171183973766' kind: compute#address name: ascs-aha-vip networkTier: PREMIUM purpose: GCE_ENDPOINT region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1 selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/addresses/ascs-aha-vip status: RESERVED subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-sub-network-sap
Definisci i nomi host per l'indirizzo VIP in /etc/hosts
Definisci un nome host per ogni indirizzo VIP, quindi aggiungi gli indirizzi IP e i nomi host sia per le VM che per i VIP al file /etc/hosts
su ogni VM.
I nomi host VIP non sono noti all'esterno delle VM, a meno che non li aggiunga anche al
servizio DNS. L'aggiunta di queste voci al file /etc/hosts
locale protegge il cluster da eventuali interruzioni del servizio DNS.
Gli aggiornamenti al file /etc/hosts
dovrebbero essere simili al seguente
esempio:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 10.1.0.113 nw-ha-vm-2.us-central1-c.c.example-project-123456.internal nw-ha-vm-2 10.1.0.2 ascs-aha-vip 10.1.0.4 ers-aha-vip 10.1.0.114 nw-ha-vm-1.us-central1-b.c.example-project-123456.internal nw-ha-vm-1 # Added by Google 169.254.169.254 metadata.google.internal # Added by Google
crea i controlli di integrità di Cloud Load Balancing
Crea i controlli di integrità: uno per l'istanza ASCS attiva e uno per l'ERS attiva.
In Cloud Shell, crea i controlli di integrità. Per evitare conflitti con altri servizi, indica i numeri di porta per le istanze ASCS ed ERS nell'intervallo privato, 49152-65535. I valori di intervallo di controllo e timeout nei seguenti comandi sono leggermente più lunghi rispetto ai valori predefiniti, in modo da aumentare la tolleranza di failover durante gli eventi di migrazione dal vivo di Compute Engine. Se necessario, puoi modificare i valori:
~
gcloud compute health-checks create tcp ASCS_HEALTH_CHECK_NAME \ --port=ASCS_HEALTHCHECK_PORT_NUM --proxy-header=NONE --check-interval=10 --timeout=10 \ --unhealthy-threshold=2 --healthy-threshold=2~
gcloud compute health-checks create tcp ERS_HEALTH_CHECK_NAME \ --port=ERS_HEALTHCHECK_PORT_NUM --proxy-header=NONE --check-interval=10 --timeout=10 \ --unhealthy-threshold=2 --healthy-threshold=2
Conferma la creazione di ogni controllo di integrità:
~
gcloud compute health-checks describe HEALTH_CHECK_NAMEDovresti vedere un output simile all'esempio seguente:
checkIntervalSec: 10 creationTimestamp: '2021-05-12T15:12:21.892-07:00' healthyThreshold: 2 id: '1981070199800065066' kind: compute#healthCheck name: ascs-aha-health-check-name selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/scs-aha-health-check-name tcpHealthCheck: port: 60000 portSpecification: USE_FIXED_PORT proxyHeader: NONE timeoutSec: 10 type: TCP unhealthyThreshold: 2
Crea una regola firewall per i controlli di integrità
Se non lo hai già fatto, definisci una regola firewall per una porta nell'intervallo privato che consenta l'accesso alle VM host dagli intervalli IP utilizzati dai controlli di integrità di Cloud Load Balancing, 35.191.0.0/16
e 130.211.0.0/22
. Per saperne di più sulle regole firewall per i bilanciatori del carico, consulta Creazione di regole firewall per i controlli di integrità.
Se non ne hai già uno, aggiungi un tag di rete alle VM host. Questo tag di rete viene utilizzato dalla regola firewall per i controlli di integrità.
~
gcloud compute instances add-tags PRIMARY_VM_NAME \ --zone=PRIMARY_ZONE \ --tags NETWORK_TAGS~
gcloud compute instances add-tags SECONDARY_VM_NAME \ --zone=SECONDARY_ZONE \ --tags NETWORK_TAGS
Crea una regola firewall che utilizzi il tag di rete per consentire i controlli di integrità:
~
gcloud compute firewall-rules create RULE_NAME \ --network=NETWORK_NAME \ --action=ALLOW \ --direction=INGRESS \ --source-ranges=35.191.0.0/16,130.211.0.0/22 \ --target-tags=NETWORK_TAGS \ --rules=tcp:ASCS_HEALTHCHECK_PORT_NUM,tcp:ERS_HEALTHCHECK_PORT_NUMAd esempio:
gcloud compute firewall-rules create nw-ha-cluster-health-checks \ --network=example-network \ --action=ALLOW \ --direction=INGRESS \ --source-ranges=35.191.0.0/16,130.211.0.0/22 \ --target-tags=allow-health-check \ --rules=tcp:60000,tcp:60010
crea gruppi di istanze Compute Engine
Devi creare un gruppo di istanze in ogni zona che contiene una VM con nodo cluster e aggiungere la VM in quella zona al gruppo di istanze.
In Cloud Shell, crea il gruppo di istanze principali e aggiungi al suo interno la VM principale:
~
gcloud compute instance-groups unmanaged create PRIMARY_IG_NAME \ --zone=PRIMARY_ZONE~
gcloud compute instance-groups unmanaged add-instances PRIMARY_IG_NAME \ --zone=PRIMARY_ZONE \ --instances=PRIMARY_VM_NAME
In Cloud Shell, crea il gruppo di istanze secondarie e aggiungi al suo interno la VM secondaria:
~
gcloud compute instance-groups unmanaged create SECONDARY_IG_NAME \ --zone=SECONDARY_ZONE~
gcloud compute instance-groups unmanaged add-instances SECONDARY_IG_NAME \ --zone=SECONDARY_ZONE \ --instances=SECONDARY_VM_NAME
Conferma la creazione dei gruppi di istanze:
~
gcloud compute instance-groups unmanaged listDovresti vedere un output simile all'esempio seguente:
NAME ZONE NETWORK NETWORK_PROJECT MANAGED INSTANCES sap-aha-primary-instance-group us-central1-b example-network-sap example-project-123456 No 1 sap-aha-secondary-instance-group us-central1-c example-network-sap example-project-123456 No 1
Configura i servizi di backend
Crea due servizi di backend, uno per ASCS e uno per ERS. Aggiungi entrambi i gruppi di istanze a ogni servizio di backend, designando il gruppo opposto come gruppo di istanze di failover in ogni servizio di backend. Infine, crea le regole di forwarding dai VIP ai servizi di backend.
In Cloud Shell, crea il servizio di backend e il gruppo di failover per ASCS:
Crea il servizio di backend per ASCS:
~
gcloud compute backend-services create ASCS_BACKEND_SERVICE_NAME \ --load-balancing-scheme internal \ --health-checks ASCS_HEALTH_CHECK_NAME \ --no-connection-drain-on-failover \ --drop-traffic-if-unhealthy \ --failover-ratio 1.0 \ --region CLUSTER_REGION \ --global-health-checksAggiungi il gruppo di istanze principali al servizio di backend ASCS:
~
gcloud compute backend-services add-backend ASCS_BACKEND_SERVICE_NAME \ --instance-group PRIMARY_IG_NAME \ --instance-group-zone PRIMARY_ZONE \ --region CLUSTER_REGIONAggiungi il gruppo di istanze secondarie come gruppo di istanze di failover per il servizio di backend ASCS:
~
gcloud compute backend-services add-backend ASCS_BACKEND_SERVICE_NAME \ --instance-group SECONDARY_IG_NAME \ --instance-group-zone SECONDARY_ZONE \ --failover \ --region CLUSTER_REGION
In Cloud Shell, crea il servizio di backend e il gruppo di failover per ERS:
Crea il servizio di backend per ERS:
~
gcloud compute backend-services create ERS_BACKEND_SERVICE_NAME \ --load-balancing-scheme internal \ --health-checks ERS_HEALTH_CHECK_NAME \ --no-connection-drain-on-failover \ --drop-traffic-if-unhealthy \ --failover-ratio 1.0 \ --region CLUSTER_REGION \ --global-health-checksAggiungi il gruppo di istanze secondarie al servizio di backend ERS:
~
gcloud compute backend-services add-backend ERS_BACKEND_SERVICE_NAME \ --instance-group SECONDARY_IG_NAME \ --instance-group-zone SECONDARY_ZONE \ --region CLUSTER_REGIONAggiungi il gruppo di istanze principali come gruppo di istanze di failover per il servizio di backend ERS:
~
gcloud compute backend-services add-backend ERS_BACKEND_SERVICE_NAME \ --instance-group PRIMARY_IG_NAME \ --instance-group-zone PRIMARY_ZONE \ --failover \ --region CLUSTER_REGION
Facoltativamente, verifica che i servizi di backend contengano i gruppi di istanze come previsto:
~
gcloud compute backend-services describe BACKEND_SERVICE_NAME \ --region=CLUSTER_REGIONDovresti vedere un output simile all'esempio seguente per il servizio di backend ASCS. Per ERS,
failover: true
verrebbe visualizzato nel gruppo di istanze principale:backends: - balancingMode: CONNECTION group: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group - balancingMode: CONNECTION failover: true group: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group connectionDraining: drainingTimeoutSec: 0 creationTimestamp: '2022-04-06T10:58:37.744-07:00' description: '' failoverPolicy: disableConnectionDrainOnFailover: true dropTrafficIfUnhealthy: true failoverRatio: 1.0 fingerprint: s4qMEAyhrV0= healthChecks: - https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/ascs-aha-health-check-name id: '6695034709671438882' kind: compute#backendService loadBalancingScheme: INTERNAL name: ascs-aha-backend-service-name protocol: TCP region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1 selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/backendServices/ascs-aha-backend-service-name sessionAffinity: NONE timeoutSec: 30
In Cloud Shell, crea le regole di forwarding per i servizi di backend ASCS ed ERS:
Crea la regola di forwarding dal VIP ASCS al servizio di backend ASCS:
~
gcloud compute forwarding-rules create ASCS_FORWARDING_RULE_NAME \ --load-balancing-scheme internal \ --address ASCS_VIP_ADDRESS \ --subnet CLUSTER_SUBNET \ --region CLUSTER_REGION \ --backend-service ASCS_BACKEND_SERVICE_NAME \ --ports ALLCrea la regola di forwarding dal VIP ERS al servizio di backend ERS:
~
gcloud compute forwarding-rules create ERS_FORWARDING_RULE_NAME \ --load-balancing-scheme internal \ --address ERS_VIP_ADDRESS \ --subnet CLUSTER_SUBNET \ --region CLUSTER_REGION \ --backend-service ERS_BACKEND_SERVICE_NAME \ --ports ALL
Testa la configurazione del bilanciatore del carico
Anche se i gruppi di istanza di backend non verranno registrati come integri fino a un momento successivo, puoi testare la configurazione del bilanciatore del carico impostando un listener che risponda ai controlli di integrità. Dopo aver impostato un listener, se il bilanciatore del carico è configurato correttamente, lo stato dei gruppi di istanza di backend diventa integro.
Le sezioni seguenti presentano diversi metodi che puoi utilizzare per testare la configurazione.
Test del bilanciatore del carico con l'utilità socat
Puoi utilizzare l'utilità socat
per ascoltare temporaneamente una porta del controllo di integrità.
Su entrambe le VM host, installa l'utilità
socat
:$
sudo yum install socatSulla VM principale, assegna temporaneamente il VIP alla scheda di rete eth0:
ip addr add VIP_ADDRESS dev eth0
Sulla VM principale, avvia un processo
socat
in ascolto per 60 secondi sulla porta per il controllo di integrità ASCS:$
timeout 60s socat - TCP-LISTEN:ASCS_HEALTHCHECK_PORT_NUM,forkIn Cloud Shell, dopo aver atteso alcuni secondi che il controllo di integrità rilevasse il listener, controlla l'integrità del gruppo di istanza di backend ASCS:
~
gcloud compute backend-services get-health ASCS_BACKEND_SERVICE_NAME \ --region CLUSTER_REGIONDovresti vedere un output simile al seguente esempio per ASCS:
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group status: healthStatus: - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule forwardingRuleIp: 10.1.0.90 healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instances/nw-ha-vm-1 ipAddress: 10.1.0.89 port: 80 kind: compute#backendServiceGroupHealth --- backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group status: healthStatus: - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule forwardingRuleIp: 10.1.0.90 healthState: UNHEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/nw-ha-vm-2 ipAddress: 10.1.0.88 port: 80 kind: compute#backendServiceGroupHealth
Rimuovi il VIP dall'interfaccia eth0:
ip addr del VIP_ADDRESS dev eth0
Ripeti i passaggi per l'ERS, sostituendo i valori delle variabili ASCS con i valori ERS.
Test del bilanciatore del carico utilizzando la porta 22
Se la porta 22
è aperta per le connessioni SSH sulle VM host, puoi
modificare temporaneamente il controllo di integrità in modo da utilizzare la porta 22
, che dispone di un listener
in grado di rispondere al controllo di integrità.
Per utilizzare temporaneamente la porta 22
:
Nella console Google Cloud, vai alla pagina Controlli di integrità di Compute Engine:
Fai clic sul nome del controllo di integrità.
Fai clic su Modifica.
Nel campo Porta, imposta il numero di porta su 22.
Fai clic su Salva e attendi un minuto o due.
In Cloud Shell, dopo aver atteso alcuni secondi che il controllo di integrità rilevasse il listener, controlla l'integrità dei gruppi di istanza di backend:
~
gcloud compute backend-services get-health BACKEND_SERVICE_NAME \ --region CLUSTER_REGIONDovresti vedere un output simile al seguente:
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group status: healthStatus: - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule forwardingRuleIp: 10.1.0.85 healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instances/nw-ha-vm-1 ipAddress: 10.1.0.79 port: 80 kind: compute#backendServiceGroupHealth --- backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group status: healthStatus: - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule forwardingRuleIp: 10.1.0.85 healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/nw-ha-vm-2 ipAddress: 10.1.0.78 port: 80 kind: compute#backendServiceGroupHealth
Al termine, reimposta il numero di porta del controllo di integrità originale.
Installa listener per i controlli di integrità
Per configurare una risorsa per il controllo di integrità, devi prima installare i listener.
Il bilanciatore del carico utilizza un listener sulla porta per il controllo di integrità di ciascun host per determinare dove è in esecuzione l'istanza principale del cluster SAP HANA.
Installa un listener su ogni host del cluster completando questi passaggi:
Come root, installa un semplice listener TCP. Queste istruzioni installano e utilizzano HAProxy come listener.
#
yum install haproxyCopia e rinomina il file di configurazione
haproxy.cfg
predefinito per renderlo un file modello per le diverse istanze haproxy:#
cp /usr/lib/systemd/system/haproxy.service \ /etc/systemd/system/haproxy@.serviceModifica le sezioni
[Unit]
e[Service]
del filehaproxy@.service
per includere il parametro dell'istanza%i
, come mostrato nell'esempio seguente:[Unit] Description=HAProxy Load Balancer %i After=network-online.target Wants=network-online.target [Service] Environment="CONFIG=/etc/haproxy/haproxy-%i.cfg" "PIDFILE=/run/haproxy-%i.pid" ...
Per ulteriori informazioni da Red Hat sui modelli di unità
systemd
, consulta Utilizzo delle unità create con un'istanza.Crea un file di configurazione
haproxy.cfg
per l'istanza ASCS. Ad esempio:#
vi /etc/haproxy/haproxy-SIDscs.cfgSostituisci
SID
con l'ID di sistema SAP (SID). Usa le maiuscole per le lettere. Ad esempio,AHA
.Nel file di configurazione ASCS
haproxy-SIDscs.cfg
, inserisci la configurazione seguente e sostituisciASCS_HEALTHCHECK_PORT_NUM
con il numero di porta specificato al momento della creazione precedente del controllo di integrità di Compute Engine per ASCS:global chroot /var/lib/haproxy pidfile /var/run/haproxy-%i.pid user haproxy group haproxy daemon defaults mode tcp log global option dontlognull option redispatch retries 3 timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout check 10s maxconn 3000 # Listener for SAP healthcheck listen healthcheck bind *:ASCS_HEALTHCHECK_PORT_NUM
Crea un file di configurazione
haproxy.cfg
per l'istanza ERS. Ad esempio:#
vi /etc/haproxy/haproxy-SIDers.cfgNel file di configurazione ERS di
haproxy-SIDers.cfg
, inserisci la configurazione seguente e sostituisciERS_HEALTHCHECK_PORT_NUM
con il numero di porta specificato al momento della creazione precedente del controllo di integrità di Compute Engine per ERS:global chroot /var/lib/haproxy pidfile /var/run/haproxy-%i.pid user haproxy group haproxy daemon defaults mode tcp log global option dontlognull option redispatch retries 3 timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout check 10s maxconn 3000 # Listener for SAP healthcheck listen healthcheck bind *:ERS_HEALTHCHECK_PORT_NUM
Ricarica i servizi
systemd
:#
systemctl daemon-reloadVerifica che il servizio haproxy sia configurato correttamente:
#
systemctl start haproxy#
systemctl status haproxy#
systemctl | grep haproxyLo stato restituito dovrebbe mostrare
haproxy.service
comeactive (running)
.● haproxy.service - HAProxy Load Balancer Loaded: loaded (/usr/lib/systemd/system/haproxy.service; enabled; vendor preset: disabled) Active: active (running) since Sun 2022-04-10 16:48:10 UTC; 2 days ago Main PID: 1079 (haproxy) Tasks: 2 (limit: 100996) Memory: 5.1M CGroup: /system.slice/haproxy.service ├─1079 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid └─1083 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid Apr 10 16:48:10 dru-hanw-ascs systemd[1]: Starting HAProxy Load Balancer... Apr 10 16:48:10 dru-hanw-ascs systemd[1]: Started HAProxy Load Balancer.
Ripeti i passaggi precedenti su ciascun host nel cluster.
Configura Pacemaker
La seguente procedura configura l'implementazione RHEL di un cluster Pacemaker sulle VM di Compute Engine per SAP NetWeaver.
La procedura si basa sulla documentazione di Red Hat per la configurazione di cluster ad alta disponibilità, incluse le seguenti pubblicazioni (è necessario un abbonamento a Red Hat):
- Configurazione di SAP NetWeaver ASCS/ERS ENSA1 con risorse autonome in RHEL 7.5 e versioni successive e RHEL 8
- Configurazione di SAP S/4HANA ASCS/ERS con server accodamento autonomo 2 (ENSA2) in Pacemaker
Per informazioni da SAP sull'installazione e la configurazione di RHEL, consulta:
- SAP Note 3108316 - Red Hat Enterprise Linux 9.x: installazione e configurazione
- SAP Note 2772999 - Red Hat Enterprise Linux 8.x: Installazione e configurazione
- SAP Note 2002167 - Red Hat Enterprise Linux 7.x: Installazione e upgrade
Configura i pacchetti cluster e il firewall del sistema operativo richiesti su entrambi gli host
Come root sia sull'host primario che su quello secondario, installa e aggiorna i pacchetti cluster richiesti, configura hacluster
e configura il servizio firewall del sistema operativo.
Installa i seguenti pacchetti di cluster richiesti:
#
yum install pcs pacemaker#
yum install fence-agents-gce#
yum install resource-agents-gcp#
yum install resource-agents-sap#
yum install sap-cluster-connectorAggiorna i pacchetti installati:
#
yum update -yImposta la password per l'utente
hacluster
, che viene installato come parte dei pacchetti cluster:#
passwd haclusterSpecifica una password per
hacluster
quando richiesto.Nelle immagini RHEL fornite da Google Cloud, il servizio firewall del sistema operativo è attivo per impostazione predefinita. Configura il servizio firewall in modo da consentire il traffico ad alta disponibilità:
#
firewall-cmd --permanent --add-service=high-availability#
firewall-cmd --reloadAvvia il servizio PC e configuralo in modo che venga avviato al momento dell'avvio:
#
systemctl start pcsd.service#
systemctl enable pcsd.serviceControlla lo stato del servizio PC:
#
systemctl status pcsd.serviceDovresti vedere un output simile al seguente:
● pcsd.service - PCS GUI and remote configuration interface Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled) Active: active (running) since Sat 2020-06-13 21:17:05 UTC; 25s ago Docs: man:pcsd(8) man:pcs(8) Main PID: 31627 (pcsd) CGroup: /system.slice/pcsd.service └─31627 /usr/bin/ruby /usr/lib/pcsd/pcsd Jun 13 21:17:03 hana-ha-vm-1 systemd[1]: Starting PCS GUI and remote configuration interface... Jun 13 21:17:05 hana-ha-vm-1 systemd[1]: Started PCS GUI and remote configuration interface.
Crea il cluster
Come utente root su uno dei due nodi, autorizza l'utente
hacluster
. Fai clic sulla scheda relativa alla tua versione RHEL per visualizzare il comando:RHEL 8 e versioni successive
#
pcs host auth PRIMARY_VM_NAME SECONDARY_VM_NAMERHEL 7
#
pcs cluster auth PRIMARY_VM_NAME SECONDARY_VM_NAMEAl prompt, inserisci il nome utente
hacluster
e la password che hai impostato per l'utentehacluster
.Crea il cluster:
RHEL 8 e versioni successive
#
pcs cluster setup CLUSTER_NAME PRIMARY_VM_NAME SECONDARY_VM_NAMERHEL 7
#
pcs cluster setup --name CLUSTER_NAME PRIMARY_VM_NAME SECONDARY_VM_NAME
Aggiorna i file di configurazione di Corosync
I passaggi seguenti impostano i valori consigliati del cluster per Corosync.
Se il file di configurazione di Corosync, /etc/corosync/corosync.conf
,
non esiste ancora o è vuoto, puoi utilizzare il file di esempio nella
directory /etc/corosync/
come base per la tua configurazione.
Apri il file
corosync.conf
per la modifica:#
vi /etc/corosync/corosync.confNella sezione
totem
del filecorosync.conf
, imposta i parametri del seguente esempio estratto sui valori visualizzati. È possibile che alcuni parametri siano già impostati sui valori corretti:RHEL 8
totem { ... transport: knet token: 20000 token_retransmits_before_loss_const: 10 join: 60 max_messages: 20 ... }
RHEL 7
totem { ... transport: udpu token: 20000 token_retransmits_before_loss_const: 10 join: 60 max_messages: 20 ... }
Sincronizza la configurazione sul secondo server:
RHEL 8 e versioni successive
#
pcs cluster sync corosyncRHEL 7
#
pcs cluster syncDalla VM principale, abilita e avvia il cluster
#
pcs cluster enable --all#
pcs cluster start --allVerifica che le nuove impostazioni Corosync siano attive nel cluster utilizzando l'utilità corosync-cmapctl:
#
corosync-cmapctlControlla lo stato del cluster:
#
pcs statusDovresti vedere un output simile all'esempio seguente:
Cluster name: nwha WARNINGS: No stonith devices and stonith-enabled is not false Cluster Summary: * Stack: corosync * Current DC: nw-ha-vm-2 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum * 2 nodes configured * 0 resource instances configured Node List: * Online: [ nw-ha-vm-1 nw-ha-vm-2 ] Full List of Resources: * No resources Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled
Configura le risorse del cluster per l'infrastruttura
Devi definire le risorse Pacemaker per la seguente infrastruttura del cluster:
- Il dispositivo di recinzione, che previene gli scenari di tipo "cervello spaccato"
- Directory ASCS ed ERS nel file system condiviso
- I controlli di integrità
- VIP
- Componenti ASCS ed ERS
Devi prima definire le risorse per il dispositivo di recinzione, il file system condiviso, i controlli di integrità e i VIP. Quindi installerai SAP NetWeaver. Dopo l'installazione di SAP NetWeaver, potrai definire le risorse del cluster per i componenti ASCS ed ERS.
Allestisci recinzioni
Per configurare la fencing devi definire una risorsa cluster con l'agente fence_gce
per ogni VM host.
Per garantire la corretta sequenza di eventi dopo un'azione di fencing, devi anche configurare il sistema operativo in modo da ritardare il riavvio di Corosync dopo il recinto di una VM. Puoi anche regolare il timeout del pacemaker per i riavvii in base al ritardo.
Crea le risorse del dispositivo di recinzione
Per ogni VM nel cluster, crea una risorsa cluster per il dispositivo di recinzione, in modo che il cluster possa riavviare la VM. Il dispositivo di fencing per una VM deve essere eseguito su una VM diversa, quindi configuri la località della risorsa del cluster in modo che venga eseguita su qualsiasi VM, ad eccezione della VM in cui può riavviarsi.
Nell'host principale come root, crea una risorsa cluster per un dispositivo di scherma per la VM principale:
#
pcs stonith create FENCING_RESOURCE_PRIMARY_VM fence_gce \ port="PRIMARY_VM_NAME" \ zone="PRIMARY_ZONE" \ project="CLUSTER_PROJECT_ID" \ pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s"Configura la località del dispositivo di scherma per la VM principale in modo che sia attivo solo sulla VM secondaria:
#
pcs constraint location FENCING_RESOURCE_PRIMARY_VM avoids PRIMARY_VM_NAMESull'host secondario come root, crea una risorsa cluster per un dispositivo di recinzione per la VM secondaria:
#
pcs stonith create FENCING_RESOURCE_SECONDARY_VM fence_gce \ port="SECONDARY_VM_NAME" \ zone="SECONDARY_ZONE" \ project="CLUSTER_PROJECT_ID" \ pcmk_reboot_timeout=300 pcmk_monitor_retries=4 \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s"Configura la località del dispositivo di scherma per la VM secondaria in modo che sia attivo solo sulla VM principale:
#
pcs constraint location FENCING_RESOURCE_SECONDARY_VM avoids SECONDARY_VM_NAME
Imposta un ritardo per il riavvio di Corosync
Su entrambi gli host come root, crea un file drop-in
systemd
che ritarda l'avvio di Corosync per garantire la sequenza corretta degli eventi dopo il riavvio di una VM protetta:systemctl edit corosync.service
Aggiungi le seguenti righe al file:
[Service] ExecStartPre=/bin/sleep 60
Salva il file ed esci dall'editor.
Ricarica la configurazione dell'amministratore di sistema.
systemctl daemon-reload
Verifica che il file di inserimento sia stato creato:
service corosync status
Dovresti vedere una riga per il file di inserimento, come mostrato nell'esempio seguente:
● corosync.service - Corosync Cluster Engine Loaded: loaded (/usr/lib/systemd/system/corosync.service; disabled; vendor preset: disabled) Drop-In: /etc/systemd/system/corosync.service.d └─override.conf Active: active (running) since Tue 2021-07-20 23:45:52 UTC; 2 days ago
crea le risorse del file system
Definisci le risorse del cluster per le directory ASCS ed ERS nel file system condiviso.
Configura una risorsa del file system per la directory ASCS.
#
pcs resource create ASCS_FILE_SYSTEM_RESOURCE Filesystem \ device="NFS_PATH/usrsapSIDASCSASCS_INSTANCE_NUMBER" \ directory="/usr/sap/SID/ASCSASCS_INSTANCE_NUMBER" \ fstype=nfs force_unmount=safe \ --group ASCS_RESOURCE_GROUP \ op start interval=0 timeout=60 \ op stop interval=0 timeout=120 \ op monitor interval=200 timeout=40Sostituisci quanto segue:
ASCS_FILE_SYSTEM_RESOURCE
: specifica un nome per la risorsa cluster del file system ASCS.NFS_PATH
: specifica il percorso della directory del file system NFS.SID
: specifica l'ID di sistema (SID). Utilizza le maiuscole per tutte le lettere.ASCS_INSTANCE_NUMBER
: specifica il numero dell'istanza ASCS.ASCS_RESOURCE_GROUP
: specifica un nome univoco del gruppo per le risorse del cluster ASCS. Puoi garantire l'univocità utilizzando una convenzione come "SID_ASCSinstance_number_group". Ad esempio,nw8_ASCS00_group
.Poiché un gruppo non esiste ancora, Pacemaker lo crea ora. Quando crei altre risorse ASCS, le aggiungi a questo gruppo.
Configura una risorsa del file system per la directory ERS.
#
pcs resource create ERS_FILE_SYSTEM_RESOURCE Filesystem \ device="NFS_PATH/usrsapSIDERSERS_INSTANCE_NUMBER" \ directory="/usr/sap/SID/ERSERS_INSTANCE_NUMBER" \ fstype=nfs force_unmount=safe \ --group ERS_RESOURCE_GROUP \ op start interval=0 timeout=60 \ op stop interval=0 timeout=120 \ op monitor interval=200 timeout=40Sostituisci quanto segue:
ERS_FILE_SYSTEM_RESOURCE
: specifica un nome per la risorsa del file system.NFS_PATH
: specifica il percorso della directory del file system NFS.SID
: specifica l'ID di sistema (SID). Utilizza le maiuscole per tutte le lettere.ERS_INSTANCE_NUMBER
: specifica il numero dell'istanza ERS.ERS_RESOURCE_GROUP
: specifica un nome di gruppo univoco per le risorse del cluster ERS. Puoi garantire l'univocità utilizzando una convenzione come "SID_ERSinstance_number_group". Ad esempio,nw8_ERS10_group
.Poiché un gruppo non esiste ancora, Pacemaker lo crea ora. Quando crei altre risorse ERS, le aggiungi a questo gruppo.
Crea una risorsa di indirizzo IP virtuale
Definisci le risorse del cluster per gli indirizzi VIP.
Per cercare l'indirizzo VIP, puoi utilizzare:
gcloud compute addresses describe ASCS_VIP_NAME
--region=CLUSTER_REGION --format="value(address)"gcloud compute addresses describe ERS_VIP_NAME
--region=CLUSTER_REGION --format="value(address)"
Crea le risorse del cluster per i VIP ASCS ed ERS.
#
pcs resource create ASCS_VIP_RESOURCE IPaddr2 \ ip=ASCS_VIP_ADDRESS cidr_netmask=32 nic=eth0 \ op monitor interval=3600 timeout=60 \ --group ASCS_RESOURCE_GROUP#
pcs resource create ERS_VIP_RESOURCE IPaddr2 \ ip=ERS_VIP_ADDRESS cidr_netmask=32 nic=eth0 \ op monitor interval=3600 timeout=60 \ --group ERS_RESOURCE_GROUP
crea le risorse per il controllo di integrità
Configura la risorsa del cluster per il controllo di integrità ASCS:
#
pcs resource create _HEALTHCHECK_SCS service:haproxy@SIDascs \ op monitor interval=10s timeout=20s \ --group ASCS_RESOURCE_GROUPConfigura la risorsa del cluster per il controllo di integrità ERS:
#
pcs resource create _HEALTHCHECK_ERS service:haproxy@SIDers \ op monitor interval=10s timeout=20s \ --group ERS_RESOURCE_GROUP
Configura impostazioni predefinite aggiuntive per il cluster
Imposta proprietà aggiuntive del cluster:
#
pcs resource defaults resource-stickiness=1#
pcs resource defaults migration-threshold=3
Visualizza le risorse definite
Visualizza le risorse del cluster che hai definito finora per assicurarti che siano corrette.
Visualizza lo stato del cluster:
#
pcs statusDovresti vedere un output simile all'esempio seguente:
Cluster name: nwha Cluster Summary: * Stack: corosync * Current DC: nw-ha-vm-1 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum * 2 nodes configured * 8 resource instances configured Node List: * Online: [ nw-ha-vm-1 nw-ha-vm-2 ] Full List of Resources: * fence-nw-ha-vm-2 (stonith:fence_gce): Started nw-ha-vm-1 * fence-nw-ha-vm-1 (stonith:fence_gce): Started nw-ha-vm-2 * Resource Group: nw8_ascs00_group: * nw8_vip_ascs00 (ocf::heartbeat:IPaddr2): Started nw-ha-vm-1 * nw8_healthcheck_scs (service:haproxy@nw8scs): Started nw-ha-vm-1 * nw8_fs_ascs00 (ocf::heartbeat:Filesystem): Started nw-ha-vm-1 * Resource Group: nw8_ers10_group: * nw8_vip_ers10 (ocf::heartbeat:IPaddr2): Started nw-ha-vm-2 * nw8_healthcheck_ers (service:haproxy@nw8ers): Started nw-ha-vm-2 * nw8_fs_ers10 (ocf::heartbeat:Filesystem): Started nw-ha-vm-2 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled
Installare ASCS ed ERS
La seguente sezione copre solo i requisiti e i suggerimenti specifici per l'installazione di SAP NetWeaver su Google Cloud.
Per le istruzioni di installazione complete, consulta la documentazione di SAP NetWeaver.
Prepararsi all'installazione
Per garantire coerenza in tutto il cluster e semplificare l'installazione, prima di installare i componenti SAP NetWeaver ASCS ed ERS, definisci gli utenti, i gruppi e le autorizzazioni e metti il server secondario in modalità standby.
Disattiva la modalità di manutenzione del cluster:
#
sudo pcs property set maintenance-mode="false"Su entrambi i server come root, inserisci i comandi seguenti, specificando gli ID utente e gruppo appropriati per il tuo ambiente:
#
groupadd -g GID_SAPINST sapinst#
groupadd -g GID_SAPSYS sapsys#
useradd -u UID_SIDADM SID_LCadm -g sapsys#
usermod -a -G sapinst SID_LCadm#
useradd -u UID_SAPADM sapadm -g sapinst#
chown SID_LCadm:sapsys /usr/sap/SID/SYS#
chown SID_LCadm:sapsys /sapmnt/SID -R#
chown SID_LCadm:sapsys /usr/sap/trans -R#
chown SID_LCadm:sapsys /usr/sap/SID/SYS -R#
chown SID_LCadm:sapsys /usr/sap/SID -RSostituisci quanto segue:
GID_SAPINST
: specifica l'ID gruppo Linux per lo strumento di provisioning SAP.GID_SAPSYS
: specifica l'ID gruppo Linux per l'utente SAPSYS.UID_SIDADM
: specifica l'ID utente Linux per l'amministratore del sistema SAP (SID).SID_LC
: specifica l'ID di sistema (SID). Utilizza il minuscolo per ogni lettera.UID_SAPADM
: specifica l'ID utente per l'agente host SAP.SID
: specifica l'ID di sistema (SID). Utilizza le maiuscole per tutte le lettere.
Ad esempio, quanto segue mostra uno schema di numerazione GID e UID pratico:
Group sapinst 1001 Group sapsys 1002 Group dbhshm 1003 User en2adm 2001 User sapadm 2002 User dbhadm 2003
Installazione del componente ASCS
Sul server secondario, inserisci questo comando per mettere il server secondario in modalità standby:
#
pcs node standbySe metti il server secondario in modalità standby, tutte le risorse cluster vengono consolidate sul server principale, semplificando l'installazione.
Verifica che il server secondario sia in modalità standby:
#
pcs statusDovresti vedere un output simile all'esempio seguente:
Cluster name: nwha Cluster Summary: * Stack: corosync * Current DC: nw-ha-vm-1 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum * 2 nodes configured * 8 resource instances configured Node List: * Online: [ nw-ha-vm-1 nw-ha-vm-2 ] Full List of Resources: * fence-nw-ha-vm-2 (stonith:fence_gce): Started nw-ha-vm-1 * fence-nw-ha-vm-1 (stonith:fence_gce): Stopped * Resource Group: nw8_ascs00_group: * nw8_vip_ascs00 (ocf::heartbeat:IPaddr2): Started nw-ha-vm-1 * nw8_healthcheck_scs (service:haproxy@nw8scs): Started nw-ha-vm-1 * nw8_fs_ascs00 (ocf::heartbeat:Filesystem): Started nw-ha-vm-1 * Resource Group: nw8_ers10_group: * nw8_vip_ers10 (ocf::heartbeat:IPaddr2): Started nw-ha-vm-1 * nw8_healthcheck_ers (service:haproxy@nw8ers): Started nw-ha-vm-1 * nw8_fs_ers10 (ocf::heartbeat:Filesystem): Started nw-ha-vm-1 Daemon Status: corosync: active/enabled
Sul server principale come utente root, modifica la directory in una directory di installazione temporanea, ad esempio
/tmp
, per installare l'istanza ASCS eseguendo SAP Software Provisioning Manager (SWPM).Per accedere all'interfaccia web di SWPM, è necessaria la password dell'utente
root
. Se il tuo criterio IT non consente all'amministratore SAP di avere accesso alla password root, puoi utilizzareSAPINST_REMOTE_ACCESS_USER
.Quando avvii SWPM, utilizza il parametro
SAPINST_USE_HOSTNAME
per specificare il nome dell'host virtuale definito per l'indirizzo VIP ASCS nel file/etc/hosts
.Ad esempio:
cd /tmp; /mnt/nfs/install/SWPM/sapinst SAPINST_USE_HOSTNAME=vh-aha-scs
Nella pagina di conferma finale di SWPM, assicurati che il nome host virtuale sia corretto.
Al termine della configurazione, disattiva la modalità standby della VM secondaria:
#
pcs node unstandby
Installazione del componente ERS
Sul server principale come root o
SID_LCadm
, interrompi il servizio ASCS.#
su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function Stop"#
su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function StopService"Sul server principale, inserisci questo comando per mettere il server principale in modalità standby:
#
pcs node standbySe metti il server principale in modalità standby, tutte le risorse cluster vengono consolidate sul server secondario, semplificando l'installazione.
Verifica che il server principale sia in modalità standby:
#
pcs statusSul server secondario come utente root, modifica la directory in una directory di installazione temporanea, ad esempio
/tmp
, per installare l'istanza ERS eseguendo SAP Software Provisioning Manager (SWPM).Per accedere a SWPM, utilizza lo stesso utente e la stessa password che hai utilizzato per l'installazione del componente ASCS.
Quando avvii SWPM, utilizza il parametro
SAPINST_USE_HOSTNAME
per specificare il nome dell'host virtuale definito per l'indirizzo VIP ERS nel file/etc/hosts
.Ad esempio:
cd /tmp; /mnt/nfs/install/SWPM/sapinst SAPINST_USE_HOSTNAME=vh-aha-ers
Nella pagina di conferma finale di SWPM, assicurati che il nome host virtuale sia corretto.
Disattiva la VM principale per avere entrambe attive:
#
pcs node unstandby
Configura i servizi SAP
Devi verificare che i servizi siano configurati correttamente, controllare le impostazioni nei profili ASCS ed ERS e aggiungere l'utente SID_LCadm
al gruppo di utenti haclient
.
Conferma le voci di servizio SAP
Su entrambi i server, verifica che il file
/usr/sap/sapservices
contenga le voci dei servizi ASCS ed ERS. Per farlo, puoi utilizzare l'integrazionesystemV
osystemd
.Puoi aggiungere eventuali voci mancanti utilizzando il comando
sapstartsrv
con le opzionipf=PROFILE_OF_THE_SAP_INSTANCE
e-reg
.Per ulteriori informazioni su queste integrazioni, consulta le seguenti note SAP:
systemV
Di seguito è riportato un esempio delle voci per i servizi ASCS ed ERS nel file
/usr/sap/sapservices
se utilizzi l'integrazionesystemV
:#
LD_LIBRARY_PATH=/usr/sap/hostctrl/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH /usr/sap/hostctrl/exe/sapstartsrv \ pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \ -D -u SID_LCadm /usr/sap/hostctrl/exe/sapstartsrv \ pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \ -D -u SID_LCadmsystemd
Verifica che il file
/usr/sap/sapservices
contenga le voci per i servizi ASCS ed ERS. Di seguito è riportato un esempio di come queste voci vengono visualizzate nel file/usr/sap/sapservices
quando utilizzi l'integrazionesystemd
:systemctl --no-ask-password start SAPSID_ASCS_INSTANCE_NUMBER # sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_SID_LCascs systemctl --no-ask-password start SAPSID_ERS_INSTANCE_NUMBER # sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_SID_LCers
Disabilita l'integrazione
systemd
nelle istanze ASCS e ERS:#
systemctl disable SAPSID_ASCS_INSTANCE_NUMBER.service#
systemctl stop SAPSID_ASCS_INSTANCE_NUMBER.service#
systemctl disable SAPSID_ERS_INSTANCE_NUMBER.service#
systemctl stop SAPSID_ERS_INSTANCE_NUMBER.serviceVerifica che l'integrazione di
systemd
sia disabilitata:#
systemctl list-unit-files | grep sapUn output simile all'esempio seguente indica che l'integrazione
systemd
è disabilitata. Tieni presente che alcuni servizi, comesaphostagent
esaptune
, sono abilitati, mentre altri sono disabilitati.SAPSID_ASCS_INSTANCE_NUMBER.service disabled SAPSID_ERS_INSTANCE_NUMBER.service disabled saphostagent.service enabled sapinit.service generated saprouter.service disabled saptune.service enabled
Arresta i servizi SAP
Sul server secondario, interrompi il servizio ERS:
#
su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function Stop"#
su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function StopService"Su ciascun server, verifica che tutti i servizi siano arrestati:
#
su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function GetSystemInstanceList"#
su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function GetSystemInstanceList"Dovresti vedere un output simile all'esempio seguente:
GetSystemInstanceList FAIL: NIECONN_REFUSED (Connection refused), NiRawConnect failed in plugin_fopen()
Disabilita il riavvio automatico del servizio in SAP
Poiché il software del cluster gestisce il riavvio dei servizi SAP durante un failover, per evitare conflitti, disabilita la possibilità del software SAP di riavviare automaticamente i servizi.
Su entrambi i nodi, modifica il file
/usr/sap/sapservices
per disabilitare il riavvio automatico nel software SAP aggiungendo un carattere di commento#
all'inizio del comandosapstartsrv
per entrambi i componenti ASCS ed ERS.Ad esempio:
#!/bin/sh #LD_LIBRARY_PATH=/usr/sap/SID/ASCSASCS_INSTANCE_NUMBER/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/SID/ASCSASCS_INSTANCE_NUMBER/exe/sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME -D -u SID_LCadm #LD_LIBRARY_PATH=/usr/sap/SID/ERSERS_INSTANCE_NUMBER/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/SID/ERSERS_INSTANCE_NUMBER/exe/sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME -D -u SID_LCadm
Modificare i profili ASCS ed ERS
Su entrambi i server, passa alla directory del profilo utilizzando uno dei seguenti comandi:
#
cd /usr/sap/SID/SYS/profile#
cd /sapmnt/SID/profileSe necessario, puoi trovare i nomi dei file dei profili ASCS ed ERS elencarli nella directory del profilo oppure utilizzare i seguenti formati:
SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME
SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME
Se utilizzi ENSA1, abilita la funzione keepalive impostando quanto segue nel profilo ASCS:
enque/encni/set_so_keepalive = true
Per ulteriori informazioni, consulta la Nota SAP 1410736 - TCP/IP: impostazione dell'intervallo keepalive.
Se necessario, modifica i profili ASCS ed ERS per cambiare il comportamento di avvio del server di accodamento e del server di replica di accodamento.
ENSA1
Nella sezione "Avvia server di accodamento SAP" del profilo ASCS, se vedi
Restart_Program_NN
, cambia "Restart
" in "Start
", come mostrato nell'esempio seguente.Start_Program_01 = local $(_EN) pf=$(_PF)
Nella sezione "Avvia accodamento del server di replica" del profilo ERS, se vedi
Restart_Program_NN
, cambia "Restart
" in "Start
", come mostrato nell'esempio seguente.Start_Program_00 = local $(_ER) pf=$(_PFL) NR=$(SCSID)
ENSA2
Nella sezione "Avvia server di accodamento SAP" del profilo ASCS, se vedi
Restart_Program_NN
, cambia "Restart
" in "Start
", come mostrato nell'esempio seguente.Start_Program_01 = local $(_ENQ) pf=$(_PF)
Nella sezione "Avvia accodamento del replicatore" del profilo ERS, se vedi
Restart_Program_NN
, cambia "Restart
" in "Start
", come mostrato nell'esempio seguente.Start_Program_00 = local $(_ENQR) pf=$(_PF) ...
Configura le risorse del cluster per ASCS ed ERS
Come root di entrambi i server, imposta il cluster in modalità di manutenzione:
#
pcs property set maintenance-mode="true"Verifica che il cluster sia in modalità di manutenzione:
#
pcs statusCrea le risorse del cluster per i servizi ASCS ed ERS:
ENSA1
Crea la risorsa cluster per l'istanza ASCS. Il valore di
InstanceName
è il nome del profilo dell'istanza che SWPM ha generato quando hai installato ASCS.#
pcs resource create ASCS_INSTANCE_RESOURCE SAPInstance \ InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \ START_PROFILE=/sapmnt/SID/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \ AUTOMATIC_RECOVER=false meta resource-stickiness=5000 migration-threshold=1 \ failure-timeout=60 --group ASCS_RESOURCE_GROUP \ op monitor interval=20 on-fail=restart timeout=60 \ op start interval=0 timeout=600 \ op stop interval=0 timeout=600#
pcs resource meta ASCS_RESOURCE_GROUP resource-stickiness=3000Crea la risorsa cluster per l'istanza ERS. Il valore di
InstanceName
è il nome del profilo dell'istanza che SWPM ha generato quando hai installato ERS. Il parametroIS_ERS=true
indica a Pacemaker di impostare il flagrunsersSID
su1
sul nodo in cui è attivo l'ERS.#
pcs resource create ERS_INSTANCE_RESOURCE SAPInstance \ InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \ START_PROFILE=/sapmnt/SID/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \ AUTOMATIC_RECOVER=false IS_ERS=true --group ERS_RESOURCE_GROUP \ op monitor interval=20 on-fail=restart timeout=60 \ op start interval=0 timeout=600 \ op stop interval=0 timeout=600
ENSA2
Crea la risorsa cluster per l'istanza ASCS. Il valore di
InstanceName
è il nome del profilo dell'istanza che SWPM ha generato quando hai installato ASCS.#
pcs resource create ASCS_INSTANCE_RESOURCE SAPInstance \ InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \ START_PROFILE=/sapmnt/SID/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \ AUTOMATIC_RECOVER=false meta resource-stickiness=5000 \ --group ASCS_RESOURCE_GROUP \ op monitor interval=20 on-fail=restart timeout=60 \ op start interval=0 timeout=600 \ op stop interval=0 timeout=600#
pcs resource meta ASCS_RESOURCE_GROUP resource-stickiness=3000Crea la risorsa cluster per l'istanza ERS. Il valore di
InstanceName
è il nome del profilo dell'istanza che SWPM ha generato quando hai installato ERS.#
pcs resource create ERS_INSTANCE_RESOURCE SAPInstance \ InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \ START_PROFILE=/sapmnt/SID/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \ AUTOMATIC_RECOVER=false IS_ERS=true --group ERS_RESOURCE_GROUP \ op monitor interval=20 on-fail=restart timeout=60 \ op start interval=0 timeout=600 \ op stop interval=0 timeout=600
configura i vincoli di località e ordinamento
I vincoli vengono creati per definire i servizi che devono essere avviati per primi e quelli che devono essere eseguiti insieme sullo stesso host. Ad esempio, l'indirizzo IP deve trovarsi sullo stesso host dell'istanza SAP Central Services principale.
- Definisci il vincolo dell'ordine iniziale:
ENSA1
Crea un vincolo di colocation che impedisce alle risorse ASCS di essere eseguite sullo stesso server delle risorse ERS:
#
pcs constraint colocation add ERS_RESOURCE_GROUP with \ ASCS_RESOURCE_GROUP -5000Configura ASCS per il failover al server su cui è in esecuzione l'ERS, come determinato dal flag
runsersSID
uguale a1
:#
pcs constraint location ASCS_INSTANCE \ rule score=2000 runs_ers_SID eq 1Configura ASCS in modo che inizi prima che l'ERS venga trasferito all'altro server dopo un failover:
#
pcs constraint order start ASCS_RESOURCE_GROUP then \ stop ERS_RESOURCE_GROUP symmetrical=false kind=Optional
ENSA2
Crea un vincolo di colocation che impedisce alle risorse ASCS di essere eseguite sullo stesso server delle risorse ERS:
#
pcs constraint colocation add ERS_RESOURCE_GROUP with \ ASCS_RESOURCE_GROUP -5000Configura ASCS in modo che inizi prima che l'ERS venga trasferito all'altro server dopo un failover:
#
pcs constraint order start ASCS_RESOURCE_GROUP then \ stop ERS_RESOURCE_GROUP symmetrical=false kind=Optional
Controlla i vincoli:
#
pcs constraintDovresti vedere un output simile al seguente:
Location Constraints: Resource: ascs-aha-instance Constraint: location-ascs-instance Rule: score=2000 Expression: runs_ers_HKN eq 1 Resource: fence-nw-ha-vm-1 Disabled on: nw-ha-vm-1 (score:-INFINITY) Resource: fence-nw-ha-vm-2 Disabled on: nw-ha-vm-2 (score:-INFINITY) Ordering Constraints: start ascs-group then stop ers-group (kind:Optional) (non-symmetrical) Colocation Constraints: ascs-group with ers-group (score:-5000) Ticket Constraints:
Come root di uno dei due server, disabilita la modalità di manutenzione del cluster:
#
pcs property set maintenance-mode="false"
Configura il connettore di cluster Red Hat per SAP
Su ciascun host nel cluster, configura SAP Start Service sapstartsrv
in modo che comunichi con il software del cluster Pacemaker tramite l'interfaccia ad alta disponibilità.
Aggiungi l'utente amministrativo SAP al gruppo
haclient
:usermod -a -G haclient SID_LCadm
Modifica i profili di istanza SAP aggiungendo le righe seguenti alla fine di ogni profilo. I profili sono disponibili nella directory
/sapmnt/SID/profiles
.service/halib = $(DIR_CT_RUN)/saphascriptco.so service/halib_cluster_connector = /usr/bin/sap_cluster_connector
Se le risorse ASCS ed ERS dell'istanza sono attualmente in esecuzione nel cluster, disabilitale:
pcs resource disable ERS_INSTANCE_RESOURCE pcs resource disable ASCS_INSTANCE_RESOURCE
Interrompi i servizi nell'host ASCS:
sapcontrol -nr ASCS_INSTANCE_NUMBER -function StopService
Interrompi i servizi sull'host ERS:
sapcontrol -nr ERS_INSTANCE_NUMBER -function StopService
Abilita le risorse:
pcs resource enable ERS_INSTANCE_RESOURCE pcs resource enable ASCS_INSTANCE_RESOURCE
Ripeti i passaggi precedenti su ciascun host nel cluster.
Per ulteriori informazioni da Red Hat, consulta l'articolo Come configurare SAP halib
per le risorse SAPInstance
su RHEL 7 e 8.
Installa il database e i server delle applicazioni su host esterni al cluster
Nella configurazione ad alta disponibilità, consigliamo di installare il database e i server delle applicazioni su host diversi rispetto agli host ASCS ed ERS nel cluster.
Utilizzando host separati per ogni server, riduci la complessità, riduci il rischio di un errore che colpisca più server e puoi personalizzare le dimensioni di ogni Compute Engine in base al tipo di server.
In questo modo puoi scegliere la dimensione della macchina certificata più appropriata, evitare errori e ridurre la complessità.
L'installazione del database e dei server delle applicazioni non è trattata in questa guida.
Per informazioni sull'installazione dei server di database, vedi:
- SAP HANA su Google Cloud
- SAP ASE su Google Cloud
- SAP MaxDB su Google Cloud
- IBM Db2 per SAP su Google Cloud
convalida e testa il cluster
Questa sezione mostra come eseguire i seguenti test:
- Verificare la presenza di errori di configurazione
- Verifica che le risorse ASCS ed ERS cambino server correttamente durante i failover
- Verificare che le serrature vengano mantenute
- Simula un evento di manutenzione di Compute Engine per assicurarti che la migrazione live non attivi
Controlla la configurazione del cluster
Come root su entrambi i server, controlla su quali nodi sono in esecuzione le tue risorse:
#
pcs statusNell'esempio seguente, le risorse ASCS sono in esecuzione sul server
nw-ha-vm-2
, mentre le risorse ERS sono in esecuzione sul servernw-ha-vm-1
.Stack: corosync Current DC: nw-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum Last updated: Wed Apr 13 05:21:21 2022 Last change: Wed Apr 13 05:21:18 2022 by hacluster via crmd on nw-ha-vm-2 2 nodes configured 10 resource instances configured Online: [ nw-ha-vm-1 nw-ha-vm-2 ] Full list of resources: fence-nw-ha-vm-1 (stonith:fence_gce): Started nw-ha-vm-2 fence-nw-ha-vm-2 (stonith:fence_gce): Started nw-ha-vm-1 Resource Group: ascs-group ascs-file-system (ocf::heartbeat:Filesystem): Started nw-ha-vm-2 ascs-vip (ocf::heartbeat:IPaddr2): Started nw-ha-vm-2 ascs-healthcheck (service:haproxy@AHAascs): Started nw-ha-vm-2 ascs-aha-instance (ocf::heartbeat:SAPInstance): Started nw-ha-vm-2 Resource Group: ers-group ers-file-system (ocf::heartbeat:Filesystem): Started nw-ha-vm-1 ers-vip (ocf::heartbeat:IPaddr2): Started nw-ha-vm-1 ers-healthcheck (service:haproxy@AHAers): Started nw-ha-vm-1 ers-aha-instance (ocf::heartbeat:SAPInstance): Started nw-ha-vm-1 Migration Summary: * Node nw-ha-vm-1: * Node nw-ha-vm-2:
Passa all'utente
SID_LCadm
:#
su - SID_LCadmControlla la configurazione del cluster. Per
INSTANCE_NUMBER
, specifica il numero di istanza dell'istanza ASCS o ERS attiva sul server in cui stai inserendo il comando:>
sapcontrol -nr INSTANCE_NUMBER -function HAGetFailoverConfigHAActive
deve essereTRUE
, come mostrato nell'esempio seguente:HAGetFailoverConfig 14.04.2022 17:25:45 HAGetFailoverConfig OK HAActive: TRUE HAProductVersion: Pacemaker HASAPInterfaceVersion: sap_cluster_connector HADocumentation: https://github.com/ClusterLabs/sap_cluster_connector HAActiveNode: HANodes:
Come
SID_LCadm
, verifica la presenza di errori nella configurazione:>
sapcontrol -nr INSTANCE_NUMBER -function HACheckConfigDovresti vedere un output simile all'esempio seguente:
14.04.2022 21:43:39 HACheckConfig OK state, category, description, comment SUCCESS, SAP CONFIGURATION, Redundant ABAP instance configuration, 0 ABAP instances detected SUCCESS, SAP CONFIGURATION, Enqueue separation, All Enqueue server separated from application server SUCCESS, SAP CONFIGURATION, MessageServer separation, All MessageServer separated from application server SUCCESS, SAP STATE, SCS instance running, SCS instance status ok SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version (vip-ascs_NWT_00), SAPInstance includes is-ers patch SUCCESS, SAP CONFIGURATION, Enqueue replication (vip-ascs_NWT_00), Enqueue replication enabled SUCCESS, SAP STATE, Enqueue replication state (vip-ascs_NWT_00), Enqueue replication active SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version (vip-ers_NWT_10), SAPInstance includes is-ers patch
Sul server in cui è attivo ASCS, come
SID_LCadm
, simula un failover:>
sapcontrol -nr ASCS_INSTANCE_NUMBER -function HAFailoverToNode ""Come root, se segui il failover utilizzando
crm_mon
, dovresti vedere che l'ASCS viene spostato sull'altro server, l'ERS si arresta su quel server e quindi l'ERS viene spostato sul server su cui era in esecuzione l'ASCS.
Simula un failover
Testa il cluster simulando un errore sull'host principale. Utilizza un sistema di test o esegui il test sul tuo sistema di produzione prima di rilasciare il sistema per l'uso.
Puoi simulare un errore in diversi modi, tra cui:
shutdown -r
(sul nodo attivo)ip link set eth0 down
echo c > /proc/sysrq-trigger
Queste istruzioni utilizzano ip link set eth0 down
per rendere offline l'interfaccia di rete, poiché convalida sia il failover sia la fencing.
Esegui il backup del sistema.
Come root sull'host con l'istanza SCS attiva, metti offline l'interfaccia di rete:
$
ip link set eth0 downRiconnettiti a uno dei due host tramite SSH e passa all'utente root.
Inserisci
pcs status
per confermare che ora l'host principale è attivo sulla VM che conteneva l'host secondario. Il riavvio automatico è abilitato nel cluster, quindi l'host interrotto si riavvierà e assumerà il ruolo di host secondario, come mostrato nell'esempio seguente.Stack: corosync Current DC: nw-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum Last updated: Wed Apr 13 05:21:21 2022 Last change: Wed Apr 13 05:21:18 2022 by hacluster via crmd on nw-ha-vm-2 2 nodes configured 10 resource instances configured Online: [ nw-ha-vm-1 nw-ha-vm-2 ] Full list of resources: fence-nw-ha-vm-1 (stonith:fence_gce): Started nw-ha-vm-2 fence-nw-ha-vm-2 (stonith:fence_gce): Started nw-ha-vm-1 Resource Group: ascs-group ascs-file-system (ocf::heartbeat:Filesystem): Started nw-ha-vm-1 ascs-vip (ocf::heartbeat:IPaddr2): Started nw-ha-vm-1 ascs-healthcheck (service:haproxy@AHAascs): Started nw-ha-vm-1 ascs-aha-instance (ocf::heartbeat:SAPInstance): Started nw-ha-vm-1 Resource Group: ers-group ers-file-system (ocf::heartbeat:Filesystem): Started nw-ha-vm-2 ers-vip (ocf::heartbeat:IPaddr2): Started nw-ha-vm-2 ers-healthcheck (service:haproxy@AHAers): Started nw-ha-vm-2 ers-aha-instance (ocf::heartbeat:SAPInstance): Started nw-ha-vm-2 Migration Summary: * Node nw-ha-vm-1: * Node nw-ha-vm-2:
Conferma che le voci di blocco vengono conservate
Per verificare che le voci di blocco vengano mantenute durante un failover, seleziona prima la scheda relativa alla tua versione del server di accodamento e segui la procedura per generare voci di blocco, simulare un failover e confermare che le voci di blocco vengano conservate dopo la nuova attivazione di ASCS.
ENSA1
Come
SID_LCadm
, sul server in cui è attiva l'ERS, genera voci di blocco utilizzando il programmaenqt
:>
enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 11 NUMBER_OF_LOCKSCome
SID_LCadm
, sul server in cui è attivo ASCS, verifica che le voci di blocco siano registrate:>
sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_nowSe hai creato 10 blocchi, dovresti vedere un output simile al seguente esempio:
locks_now: 10
Come
SID_LCadm
, sul server in cui l'ERS è attiva, avvia la funzione di monitoraggio,OpCode=20
, del programmaenqt
:>
enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 20 1 1 9999Ad esempio:
>
enqt pf=/sapmnt/AHA/profile/AHA_ERS10_vh-ers-aha 20 1 1 9999Se ASCS è attivo, riavvia il server.
Sul server di monitoraggio, quando Pacemaker interrompe l'ERS per spostarlo sull'altro server, dovresti vedere un output simile al seguente.
Number of selected entries: 10 Number of selected entries: 10 Number of selected entries: 10 Number of selected entries: 10 Number of selected entries: 10
Quando il monitor
enqt
si arresta, esci dal monitor inserendoCtrl + c
.Facoltativamente, come root su uno dei due server, monitora il failover del cluster:
#
crm_monCome
SID_LCadm
, dopo aver confermato che i blocchi sono stati mantenuti, rilasciali:>
enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 12 NUMBER_OF_LOCKSCome
SID_LCadm
, sul server in cui è attivo ASCS, verifica che le voci di blocco vengano rimosse:>
sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now
ENSA2
Come
SID_LCadm
, sul server in cui è attivo ASCS, genera voci di blocco utilizzando il programmaenq_adm
:>
enq_admin --set_locks=NUMBER_OF_LOCKS:X:DIAG::TAB:%u pf=/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAMECome
SID_LCadm
, sul server in cui è attivo ASCS, verifica che le voci di blocco siano registrate:>
sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_nowSe hai creato 10 blocchi, dovresti vedere un output simile al seguente esempio:
locks_now: 10
Quando l'ERS è attiva, verifica che le voci di blocco siano state replicate:
>
sapcontrol -nr ERS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_nowIl numero di blocchi restituiti deve essere uguale a quello dell'istanza ASCS.
Se ASCS è attivo, riavvia il server.
Facoltativamente, come root su uno dei due server, monitora il failover del cluster:
#
crm_monCome
SID_LCadm
, sul server in cui è stato riavviato ASCS, verifica che le voci di blocco siano state conservate:>
sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_nowCome
SID_LCadm
, sul server su cui è attivo l'ERS, dopo aver confermato che i blocchi sono stati mantenuti, rilasciali:>
enq_admin --release_locks=NUMBER_OF_LOCKS:X:DIAG::TAB:%u pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAMECome
SID_LCadm
, sul server in cui è attivo ASCS, verifica che le voci di blocco vengano rimosse:>
sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_nowDovresti vedere un output simile al seguente esempio:
locks_now: 0
Simula un evento di manutenzione di Compute Engine
Simula un evento di manutenzione di Compute Engine per assicurarti che la migrazione live non attivi un failover.
I valori di timeout e di intervallo utilizzati in queste istruzioni tengono conto della durata delle migrazioni live. Se utilizzi valori più brevi nella configurazione del cluster, il rischio che la migrazione live attivi un failover è maggiore.
Per testare la tolleranza del tuo cluster per la migrazione live:
Sul nodo primario, attiva un evento di manutenzione simulato utilizzando il seguente comando gcloud CLI:
$
gcloud compute instances simulate-maintenance-event PRIMARY_VM_NAMEVerifica che il nodo primario non cambi:
$
pcs status
Valuta il carico di lavoro SAP NetWeaver
Per automatizzare i controlli di convalida continui per i carichi di lavoro ad alta disponibilità di SAP NetWeaver in esecuzione su Google Cloud, puoi utilizzare Workload Manager.
Workload Manager consente di analizzare e valutare automaticamente i carichi di lavoro ad alta disponibilità di SAP NetWeaver rispetto alle best practice dei fornitori SAP, Google Cloud e sistemi operativi. Ciò consente di migliorare la qualità, le prestazioni e l'affidabilità dei carichi di lavoro.
Per informazioni sulle best practice supportate da Workload Manager per la valutazione dei carichi di lavoro ad alta disponibilità di SAP NetWeaver in esecuzione su Google Cloud, consulta Best practice di Workload Manager per SAP. Per informazioni su come creare ed eseguire una valutazione utilizzando Gestore carichi di lavoro, consulta Creare ed eseguire una valutazione.
Risoluzione dei problemi
Per risolvere i problemi relativi alle configurazioni ad alta disponibilità per SAP NetWeaver, consulta Risoluzione dei problemi relativi alle configurazioni ad alta disponibilità per SAP.
Raccogli informazioni diagnostiche per i cluster SAP NetWeaver ad alta disponibilità
Se hai bisogno di aiuto per risolvere un problema con i cluster ad alta disponibilità per SAP NetWeaver, raccogli le informazioni diagnostiche richieste e contatta l'assistenza clienti Google Cloud.
Per raccogliere informazioni diagnostiche, vedi Cluster ad alta disponibilità con informazioni diagnostiche RHEL.Assistenza
In caso di problemi con l'infrastruttura o i servizi Google Cloud, contatta l'assistenza clienti. Puoi trovare le informazioni di contatto nella pagina Panoramica dell'assistenza della console Google Cloud. Se l'assistenza clienti determina che un problema si verifica nei tuoi sistemi SAP, viene indirizzato al supporto SAP.
Per problemi relativi ai prodotti SAP, registra la richiesta di assistenza con
l'assistenza SAP.
SAP valuta il ticket di assistenza e, se risulta che si tratti di un problema di infrastruttura Google Cloud, SAP trasferisce il ticket al componente Google Cloud appropriato nel suo sistema: BC-OP-LNX-GOOGLE
o BC-OP-NT-GOOGLE
.
Requisiti di assistenza
Prima di poter ricevere assistenza per sistemi SAP e per l'infrastruttura e i servizi Google Cloud che utilizzano, devi soddisfare i requisiti minimi del piano di assistenza.
Per ulteriori informazioni sui requisiti minimi di assistenza per SAP su Google Cloud, consulta:
- Ricevi assistenza per SAP su Google Cloud
- SAP Note 2456406 - SAP on Google Cloud Platform: Support Prerequisiti (È richiesto un account utente SAP)
Esecuzione di attività post-deployment
Prima di utilizzare il sistema SAP NetWeaver, ti consigliamo di eseguire il backup del nuovo sistema SAP NetWeaver HA.
Per ulteriori informazioni, consulta la guida alle operazioni di SAP NetWeaver.
Passaggi successivi
Per ulteriori informazioni sull'alta disponibilità, su SAP NetWeaver e Google Cloud, consulta le seguenti risorse:
Guida alla pianificazione dell'alta disponibilità per SAP NetWeaver su Google Cloud
Per ulteriori informazioni sull'amministrazione e sul monitoraggio delle VM, consulta la Guida operativa di SAP NetWeaver