Questa pagina è stata tradotta dall'API Cloud Translation.

Guida alla configurazione del cluster ad alta disponibilità per SAP MaxDB su RHEL

Questa guida mostra come eseguire il deployment di un sistema SAP MaxDB in un cluster di alta disponibilità Red Hat Enterprise Linux (RHEL) su Google Cloud, con configurazione del cluster attivo/passivo.

Per eseguire il deployment di un sistema SAP MaxDB a un nodo su Linux, utilizza la guida al deployment di SAP MaxDB.

Questa guida è rivolta agli utenti avanzati di SAP MaxDB che hanno dimestichezza con le configurazioni Linux HA per i sistemi SAP.

Il sistema di cui questa guida illustra il deployment

Questa guida include i passaggi per:

Configurazione di un bilanciatore del carico di rete passthrough interno per reindirizzare il traffico in caso di guasto
Configurazione di un cluster Pacemaker su RHEL per gestire i sistemi SAP e altre risorse durante un failover

Il cluster di cui è stato eseguito il deployment include le seguenti funzioni e funzionalità:

Due VM Compute Engine in zone diverse, in grado di eseguire un'istanza di SAP MaxDB
Un disco permanente regionale per l'installazione di SAP MaxDB.
Il gestore delle risorse del cluster ad alta disponibilità Pacemaker.
Un meccanismo di isolamento STONITH.

Questa guida non tratta l'installazione ad alta disponibilità di SAP NetWeaver.

Prerequisiti

Prima di creare il cluster SAP MaxDB ad alta disponibilità, assicurati che siano soddisfatti i seguenti prerequisiti:

Hai letto la guida alla pianificazione di SAP MaxDB.
Hai un abbonamento Red Hat.
Tu o la tua organizzazione avete un account Google Cloud e avete creato un progetto per il deployment di SAP MaxDB.
Se vuoi che il tuo carico di lavoro SAP venga eseguito in conformità con la residenza dei dati, controllo dell'accesso, il personale di assistenza o i requisiti normativi, devi creare la cartella Assured Workloads richiesta. Per ulteriori informazioni, consulta Controlli di conformità e sovranità per SAP su Google Cloud.
Se OS Login è abilitato nei metadati del 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 va a buon fine. Al termine del deployment, puoi riattivare l'accesso al sistema operativo.

Per ulteriori informazioni, vedi:
- Attivare o disattivare OS Login
- Aggiungere chiavi SSH alle VM che utilizzano chiavi SSH basate su metadati

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 una tua rete VPC in modo che le uniche regole firewall in vigore siano quelle che crei esplicitamente.

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 da SAP disponibili su Google Cloud, l'istanza VM richiede anche l'accesso a internet per registrare la licenza e accedere ai repository del fornitore del sistema operativo. Una configurazione con un gateway NAT e con i tag di rete VM supporta questo accesso, anche se le VM di destinazione non hanno IP esterni.

Per configurare la rete:

Console

Nella console Google Cloud, vai alla pagina Reti VPC.
Vai a 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:
1. Inserisci un nome per la subnet.
2. Per Regione, seleziona la regione Compute Engine in cui vuoi creare la sottorete.
3. In Tipo di stack IP, seleziona IPv4 (stack singolo) e poi inserisci un intervallo di indirizzi IP nel formato CIDR, ad esempio 10.1.0.0/24.
  Si tratta dell'intervallo IPv4 principale per la subnet. Se prevedi di aggiungere più di una subnet, assegni intervalli IP CIDR non sovrapposti per ogni subnet della rete. Tieni presente che ogni subnet e i relativi intervalli IP interni sono mappati a una singola regione.
4. 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 averla creata.
Fai clic su Crea.

gcloud

Vai a Cloud Shell.
Vai a Cloud Shell
Per creare una nuova rete in modalità di 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 Compute Engine. Per ulteriori informazioni, consulta la sezione 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 subnet
- NETWORK_NAME: il nome della rete creata nel passaggio precedente
- REGION: la regione in cui vuoi la subnet
- RANGE: l'intervallo di indirizzi IP, specificato in formato CIDR, ad esempio 10.1.0.0/24
  Se prevedi di aggiungere più di una subnet, assegna intervalli IP CIDR non sovrapposti per ogni subnet della 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 sottoreti.

Configurazione di un gateway NAT

Se devi creare una o più VM senza indirizzi IP pubblici, devi utilizzare la Network Address Translation (NAT) per consentire alle VM di accedere a internet. Utilizza Cloud NAT, un servizio gestito software-defined distribuito di Google Cloud che consente alle VM di inviare pacchetti in uscita a internet e di ricevere eventuali 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 progetto, le istanze VM possono accedere in sicurezza a internet senza un indirizzo IP pubblico.

aggiungi regole firewall

Per impostazione predefinita, una regola del firewall implicita blocca le connessioni in entrata dall'esterno della rete Virtual Private Cloud (VPC). Per consentire le connessioni in entrata, configura una regola firewall per la tua VM. Dopo aver stabilito una connessione in entrata con una VM, il traffico è consentito in entrambe le direzioni tramite la connessione.

Puoi anche creare una regola firewall per consentire l'accesso esterno a porte specifiche o per limitare l'accesso tra le VM sulla stessa rete. Se viene utilizzato il tipo di rete VPC default, vengono applicate anche alcune regole predefinite aggiuntive, come la regola default-allow-internal, che consente la connettività tra le VM sulla stessa rete su tutte le porte.

A seconda dei criteri IT applicabili al tuo ambiente, potresti dover isolare o limitare in altro modo la connettività all'host del database, cosa che puoi fare creando regole firewall.

A seconda dello scenario, puoi creare regole firewall per consentire l'accesso per:

Le porte SAP predefinite elencate in TCP/IP di tutti i prodotti SAP.
Connessioni dal tuo computer o dall'ambiente di rete aziendale all'istanza VM Compute Engine. Se hai dubbi su quale indirizzo IP utilizzare, rivolgiti all'amministratore di rete della tua azienda.

Per creare una regola firewall:

Console

Nella console Google Cloud, vai alla pagina Firewall di Compute Engine.

Vai a Firewall
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, specifica le risorse di Google Cloud a cui si applica questa regola. Ad esempio, specifica Tutte le istanze nella rete. In alternativa, per limitare la regola a istanze specifiche su Google Cloud, inserisci i tag in Tag target specificati.
- Nel campo Filtro 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 Subnet. Puoi utilizzare questa opzione per consentire l'accesso tra le VM in una configurazione a 3 livelli o scalabile.
- Nella sezione Protocolli e porte, seleziona Protocolli e porte specificati e inserisci tcp:PORT_NUMBER.
Fai clic su Crea per creare la regola firewall.

gcloud

Crea una regola firewall utilizzando il seguente comando:

$ gcloud compute firewall-rules create firewall-name
--direction=INGRESS --priority=1000 \
--network=network-name --action=ALLOW --rules=protocol:port \
--source-ranges ip-range --target-tags=network-tags

Esegui il deployment delle VM e installa MaxDB

Prima di iniziare a configurare il cluster HA, devi definire ed eseguire il deployment delle istanze VM e dei sistemi SAP MaxDB che fungono da nodi principali e secondari nel cluster HA.

Crea una VM per il deployment di MaxDB

Nell'ambito del deployment HA, è necessario creare due VM Google Cloud Compute Engine. Puoi consultare la guida Creare e avviare un'istanza Compute Engine.

Tieni presente che i dischi permanenti regionali supportano solo l'utilizzo dei tipi di macchine E2, N1, N2 e N2D. Scopri di più nella guida ai dischi permanenti a livello di regione.

Consulta la nota SAP 2456432 - Applicazioni SAP su Google Cloud: prodotti supportati e tipi di macchine Google Cloud per selezionare il tipo di macchina giusto in base alle dimensioni.

Crea le due VM in zone separate per ottenere la resilienza a livello di zona, con i seguenti requisiti minimi:

Dettagli della VM:
- Instance Name
- Zone - La tua zona preferita
- Machine Type - In base alle dimensioni
- Subnet - Nome della subnet creata per questa regione
Account di servizio con almeno l'ambito di accesso alle seguenti API:
- https://www.googleapis.com/auth/compute
- https://www.googleapis.com/auth/servicecontrol
- https://www.googleapis.com/auth/service.management.readonly
- https://www.googleapis.com/auth/logging.write
- https://www.googleapis.com/auth/monitoring.write
- https://www.googleapis.com/auth/trace.append
- https://www.googleapis.com/auth/devstorage.read_write
Disco aggiuntivo su ogni VM con un minimo di 20 GB da utilizzare per /usr/sap

Creare un singolo disco regionale per SAP MaxDB

Per questo deployment, verrà utilizzato un disco regionale per contenere i file MaxDB all'interno della directory /sapdb.

Crea il disco, assicurandoti che le zone di replica per il disco a livello di regione corrispondano alle zone in cui hai creato le due VM.

Collega il disco regionale a una delle VM in cui eseguirai l'installazione e le attività di configurazione di MaxDB.

Prepara il sistema operativo RHEL per l'installazione di SAP

Il prodotto SAP richiede l'installazione di impostazioni e pacchetti del sistema operativo specifici. Segui le linee guida riportate nella Nota SAP: 2772999 - Red Hat Enterprise Linux 8.x: installazione e configurazione .

Questa operazione deve essere eseguita su entrambi i nodi.

Creare filesystem

Connettiti a entrambe le istanze utilizzando SSH e crea i punti di montaggio /usr/sap/SID e /sapdb.
```
# sudo mkdir -p /usr/sap/SID
# sudo mkdir -p /sapdb
```
Crea i file system nei due dischi aggiuntivi collegati alle VM utilizzando mkfs.

Tieni presente che al momento il disco regionale verrà collegato solo a una delle VM, pertanto la creazione del file system /sapdb verrà eseguita una sola volta.
Modifica il file /etc/fstab in modo da montare sempre /usr/sap/SID al riavvio su entrambi i nodi.
Monta manualmente il file system /sapdb nel nodo in cui eseguirai l'installazione di MaxDB.

Per ulteriori informazioni sulla creazione e sul montaggio dei file system, consulta la guida Formattare e montare un disco non di avvio su una VM Linux.

Modifica la configurazione LVM

Devi modificare la configurazione della gestione dei volumi logici (LVM) in modo che il gruppo di volumi condivisi (VG) sia sempre collegato e accessibile da un solo nodo.

Per farlo, segui questi passaggi su entrambi i nodi:

Come utente root, modifica il file /etc/lvm/lvm.conf e modifica il valore system_id_source in uname da none

Controlla i risultati:

# grep -i system_id_source /etc/lvm/lvm.conf

Dovresti vedere un output simile al seguente:

# Configuration option global/system_id_source.
        system_id_source = "uname"

Inoltre, per impedire alle VM di attivare i Vg gestiti dal cluster al riavvio di un nodo, mantieni il seguente parametro nel file di configurazione/etc/lvm/lvm.conf con i nomi completi dei Vg separati da virgole che non sono gestiti dal cluster.

Nota: per impostazione predefinita, in questo file non viene mantenuto alcun valore, quindi devi andare alla sezione che descrive l'utilizzo del parametro auto_activation_volume_list e aggiungerlo manualmente.

Ad esempio, quando usrsap è il nome di un gruppo virtuale non gestito dal cluster:
```
auto_activation_volume_list = [ usrsap ]
```
Ad esempio, se non sono presenti VG non gestiti dal cluster, questo parametro deve essere aggiunto con valori vuoti:
```
auto_activation_volume_list = [  ]
```

Installazione del database e dell'agente host SAP

Ora che il sistema operativo è configurato, puoi installare il database SAP MaxDB e SAP Host Agent. In genere, MaxDB viene installato con il prodotto SAP con cui è integrato.

Tieni presente che l'installazione verrà eseguita una sola volta, nella regione in cui hai collegato il disco permanente regionale.

Per installare SAP MaxDB sulla VM:

Stabilisci una connessione SSH alla VM basata su Linux.
Scarica SAP Software Provisioning Manager (SWPM), i file multimediali per l'installazione del prodotto SAP e i file multimediali per l'installazione di MaxDB in base alle guide di installazione SAP.
Installa il prodotto SAP e il database SAP MaxDB in base alle guide di installazione SAP per il tuo prodotto SAP. Per ulteriori indicazioni, consulta la documentazione di SAP MaxDB.

SAP fornisce ulteriori informazioni sull'installazione nella nota SAP 1020175 - Domande frequenti: installazione, upgrade o applicazione di una patch di SAP MaxDB.

Al termine dell'installazione, esegui le seguenti convalide:

Come utente sidadm, controlla lo stato di MaxDB.

# dbmcli -d  SID -u control,password db_state

Dovresti vedere un output simile al seguente esempio:

>dbmcli -d  MDB -u control, my_p4$$w0rd db_state
OK
State
ONLINE

Controlla anche lo stato di x_server:

# x_server

Dovresti vedere un output simile al seguente esempio:

>x_server
2024-10-23 19:01:43 11968 19744 INF  12916          Found running XServer on port 7200
2024-10-23 19:01:43 11968 19744 INF  13011            version 'U64/LIX86 7.9.10   Build 004-123-265-969'
2024-10-23 19:01:43 11968 19744 INF  13010            installation MDB  - path: /sapdb/MDB/db
2024-10-23 19:01:45 11971 13344 INF  12916          Found running sdbgloballistener on port 7210
2024-10-23 19:01:45 11971 13344 INF  13011            version 'U64/LIX86 7.9.10   Build 004-123-265-969'

Verifica se l'agente host SAP è in esecuzione:

# ps -ef | grep -i hostctrl

Dovresti vedere un output simile al seguente esempio:

>ps -ef | grep -i hostctrl
root      1543     1  0 Oct18 ?        00:00:15 /usr/sap/hostctrl/exe/saphostexec pf=/usr/sap/hostctrl/exe/host_profile
sapadm    1550     1  0 Oct18 ?        00:03:00 /usr/sap/hostctrl/exe/sapstartsrv pf=/usr/sap/hostctrl/exe/host_profile -D
root      1618     1  0 Oct18 ?        00:03:48 /usr/sap/hostctrl/exe/saposcol -l -w60 pf=/usr/sap/hostctrl/exe/host_profile
mdbadm   12751 11261  0 19:03 pts/0    00:00:00 grep --color=auto -i hostctrl

Una volta verificata l'installazione, arresta l'istanza MaxDB e x_server.

# dbmcli -d SID -u control, and password db_offline
# x_server stop

Eseguire attività di post-installazione

Prima di utilizzare l'istanza SAP MaxDB, ti consigliamo di eseguire i seguenti passaggi post-deployment:

Aggiorna il software SAP MaxDB con le patch più recenti, se disponibili.
Installa eventuali componenti aggiuntivi.
Configura e esegui il backup del nuovo database SAP MaxDB.

Per ulteriori informazioni, consulta Amministrazione del database SAP MaxDB.

Dopo aver eseguito correttamente il deployment dei sistemi SAP MaxDB, definisci e configura il cluster HA.

Configurare il supporto del failover di Cloud Load Balancing

Il servizio bilanciatore del carico di rete passthrough interno con supporto del failover instrada il traffico all'host attivo in un cluster SAP MaxDB in base a un servizio di controllo di integrità.

Prenota un indirizzo IP per l'IP virtuale

L'indirizzo IP virtuale (VIP), a volte indicato come indirizzo IP mobile, segue il sistema SAP MaxDB attivo. Il bilanciatore del carico indirizza il traffico inviato all'indirizzo VIP alla VM che ospita il sistema SAP MaxDB attivo.

Apri Cloud Shell:

Vai a Cloud Shell
Prenota un indirizzo IP per l'IP virtuale. Si tratta dell'indirizzo IP utilizzato dalle applicazioni per accedere a SAP MaxDB. Se ometti il flag --addresses, viene scelto per te un indirizzo IP nella subnet specificata:
```
$ gcloud compute addresses create VIP_NAME \
  --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
  --addresses VIP_ADDRESS
```
Per saperne di più sulla prenotazione di un indirizzo IP statico, consulta Prenotazione di un indirizzo IP interno statico.

Conferma la prenotazione dell'indirizzo IP:

$ gcloud compute addresses describe VIP_NAME \
  --region CLUSTER_REGION

Dovresti vedere un output simile al seguente esempio:

address: 10.0.0.19
addressType: INTERNAL
creationTimestamp: '2024-10-23T14:19:03.109-07:00'
description: ''
id: '8961491304398200872'
kind: compute#address
name: vip-for-maxdb-ha
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/vip-for-maxdb-ha
status: RESERVED
subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-subnet-us-central1

Crea gruppi di istanze per le VM host

In Cloud Shell, crea due gruppi di istanze non gestite e assegna la VM host principale a uno e la VM host secondaria all'altro:

$ 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_HOST_NAME
$ 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_HOST_NAME

Conferma la creazione dei gruppi di istanze:

$ gcloud compute instance-groups unmanaged list

Dovresti vedere un output simile al seguente esempio:

NAME          ZONE           NETWORK          NETWORK_PROJECT        MANAGED  INSTANCES
maxdb-ha-ig-1  us-central1-a  example-network  example-project-123456 No       1
maxdb-ha-ig-2  us-central1-c  example-network  example-project-123456 No       1

Crea un controllo di integrità Compute Engine

In Cloud Shell, crea il controllo di integrità. Per la porta utilizzata dal controllo di integrità, scegli una porta nell'intervallo privato, 49152-65535, per evitare conflitti con altri servizi. I valori di intervallo di controllo e timeout sono leggermente più lunghi di quelli predefiniti per aumentare la tolleranza al failover durante gli eventi di migrazione live di Compute Engine. Se necessario, puoi modificare i valori:
```
$ gcloud compute health-checks create tcp HEALTH_CHECK_NAME --port=HEALTHCHECK_PORT_NUM \
  --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \
  --healthy-threshold=2
```

Conferma la creazione del controllo di integrità:

$ gcloud compute health-checks describe HEALTH_CHECK_NAME

Dovresti vedere un output simile al seguente esempio:

checkIntervalSec: 10
creationTimestamp: '2023-10-23T21:03:06.924-07:00'
healthyThreshold: 2
id: '4963070308818371477'
kind: compute#healthCheck
name: maxdb-health-check
selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/maxdb-health-check
tcpHealthCheck:
 port: 60000
 portSpecification: USE_FIXED_PORT
 proxyHeader: NONE
timeoutSec: 10
type: TCP
unhealthyThreshold: 2

Crea una regola firewall per i controlli di integrità

Definisci una regola firewall per una porta nell'intervallo privato che consenta l'accesso alle VM host dagli intervalli IP utilizzati dai controlli di salute di Compute Engine, 35.191.0.0/16 e 130.211.0.0/22. Per saperne di più, consulta Creare 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_HOST_NAME \
  --tags NETWORK_TAGS \
  --zone PRIMARY_ZONE
$ gcloud compute instances add-tags SECONDARY_HOST_NAME \
  --tags NETWORK_TAGS \
  --zone SECONDARY_ZONE

Se non ne hai già una, crea una regola firewall 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:HLTH_CHK_PORT_NUM

Ad esempio:

gcloud compute firewall-rules create  fw-allow-health-checks \
--network example-network \
--action ALLOW \
--direction INGRESS \
--source-ranges 35.191.0.0/16,130.211.0.0/22 \
--target-tags cluster-ntwk-tag \
--rules tcp:60000

Configura il bilanciatore del carico e il gruppo di failover

Crea il servizio di backend del bilanciatore del carico:

$ gcloud compute backend-services create BACKEND_SERVICE_NAME \
  --load-balancing-scheme internal \
  --health-checks HEALTH_CHECK_NAME \
  --no-connection-drain-on-failover \
  --drop-traffic-if-unhealthy \
  --failover-ratio 1.0 \
  --region CLUSTER_REGION \
  --global-health-checks

Aggiungi il gruppo di istanze principale al servizio di backend:

$ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --instance-group PRIMARY_IG_NAME \
  --instance-group-zone PRIMARY_ZONE \
  --region CLUSTER_REGION

Aggiungi il gruppo di istanze di failover secondario al servizio di backend:

$ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --instance-group SECONDARY_IG_NAME \
  --instance-group-zone SECONDARY_ZONE \
  --failover \
  --region CLUSTER_REGION

Creare una regola di forwarding. Per l'indirizzo IP, specifica l'indirizzo IP che hai riservato per il VIP. Se devi accedere al sistema SAP MaxDB dall'esterno della regione specificata di seguito, includi il flag --allow-global-access nella definizione:
```
$ gcloud compute forwarding-rules create RULE_NAME \
  --load-balancing-scheme internal \
  --address VIP_ADDRESS \
  --subnet CLUSTER_SUBNET \
  --region CLUSTER_REGION \
  --backend-service BACKEND_SERVICE_NAME \
  --ports ALL
```
Per saperne di più sull'accesso tra regioni al sistema SAP MaxDB ad alta disponibilità, consulta Bilanciamento del carico TCP/UDP interno.

Testa la configurazione del bilanciatore del carico

Anche se i gruppi di istanza di backend non verranno registrati come integri fino a più tardi, puoi testare la configurazione del bilanciatore del carico impostando un listener per rispondere ai controlli di integrità. Dopo aver configurato un ascoltatore, se il bilanciatore del carico è configurato correttamente, lo stato dei gruppi di istanza di backend diventa Stabile.

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 sulla porta di controllo di integrità.

Su entrambe le VM host, installa l'utilità socat:
```
$ sudo yum install -y socat
```
Avvia un processo socat per ascoltare per 60 secondi sulla porta di controllo di integrità:
```
$ sudo timeout 60s socat - TCP-LISTEN:HLTH_CHK_PORT_NUM,fork
```

In Cloud Shell, dopo aver atteso qualche secondo affinché il controllo di integrità rilevi il listener, controlla lo stato dei gruppi di istanza di backend:

$ gcloud compute backend-services get-health BACKEND_SERVICE_NAME \
  --region CLUSTER_REGION

Dovresti vedere un output simile al seguente:

---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/maxdb-ha-ig-1
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/maxdb-ha-vm-1
   ipAddress: 10.0.0.35
   port: 80
 kind: compute#backendServiceGroupHealth
---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/maxdb-ha-ig-2
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/maxdb-ha-vm-2
   ipAddress: 10.0.0.34
   port: 80
 kind: compute#backendServiceGroupHealth

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 che utilizzi la porta 22, che dispone di un listener in grado di rispondere al controllo di integrità.

Per utilizzare temporaneamente la porta 22:

Fai clic sul controllo di integrità nella console:

Vai alla pagina Controlli di integrità
Fai clic su Modifica.
Nel campo Porta, imposta il numero di porta su 22.
Fai clic su Salva e attendi un paio di minuti.

In Cloud Shell, controlla lo stato dei gruppi di istanza di backend:

$ gcloud compute backend-services get-health BACKEND_SERVICE_NAME \
  --region CLUSTER_REGION

Dovresti vedere un output simile al seguente:

---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/maxdb-ha-ig-1
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/maxdb-ha-vm-1
   ipAddress: 10.0.0.35
   port: 80
 kind: compute#backendServiceGroupHealth
---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/maxdb-ha-ig-2
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/maxdb-ha-vm-2
   ipAddress: 10.0.0.34
   port: 80
 kind: compute#backendServiceGroupHealth

Al termine, ripristina il numero di porta del controllo di integrità.

Configurare Pacemaker

La procedura seguente configura l'implementazione Red Hat di un cluster Pacemaker su VM Compute Engine per SAP MaxDB.

La procedura si basa sulla documentazione di Red Hat per la configurazione di cluster ad alta disponibilità, tra cui:

Installazione e configurazione di un cluster ad alta disponibilità Red Hat Enterprise Linux 7.6 (e versioni successive) su Google Cloud

Installa gli agenti del cluster su entrambi i nodi

Completa i seguenti passaggi su entrambi i nodi.

Come utente root, installa i componenti di Pacemaker:
```
# yum -y install pcs pacemaker fence-agents-gce resource-agents-gcp resource-agents-sap-hana
# yum update -y
```
Se utilizzi un'immagine RHEL per SAP fornita da Google, questi pacchetti sono già installati, ma potrebbero essere necessari alcuni aggiornamenti.
Imposta la password per l'utente hacluster, che viene installato come parte dei pacchetti:
```
# passwd hacluster
```
Specifica 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 per consentire il traffico ad alta disponibilità:
```
# firewall-cmd --permanent --add-service=high-availability
```
```
# firewall-cmd --reload
```
Avvia il servizio pcs e configuralo in modo che venga avviato all'avvio:
```
# systemctl start pcsd.service
# systemctl enable pcsd.service
```

Controlla lo stato del servizio pcs:

# systemctl status pcsd.service

Dovresti 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 2023-10-23 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
Oct 23 21:17:03 maxdb-ha-vm-1 systemd[1]: Starting PCS GUI and remote configuration interface...
Oct 23 21:17:05 maxdb-ha-vm-1 systemd[1]: Started PCS GUI and remote configuration interface.

Assicurati che tutti i servizi HA richiesti siano abilitati e in esecuzione su entrambi i nodi.
```
# systemctl enable pcsd.service pacemaker.service corosync.service
```

Nel file /etc/hosts, aggiungi il nome host completo e gli indirizzi IP interni di entrambi gli host del cluster. Ad esempio:

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.0.0.40 maxdb-ha-vm-1.us-central1-a.c.example-project-123456.internal maxdb-ha-vm-1  # Added by Google
10.0.0.41 maxdb-ha-vm-2.us-central1-c.c.example-project-123456.internal maxdb-ha-vm-2
169.254.169.254 metadata.google.internal  # Added by Google

Per ulteriori informazioni di Red Hat sulla configurazione del file /etc/hosts sui nodi del cluster RHEL, visita la pagina https://access.redhat.com/solutions/81123.

Crea il cluster

Con i privilegi di root su entrambi i nodi, autorizza l'utente hacluster. Fai clic sulla scheda corrispondente alla tua versione di RHEL per visualizzare il comando:
RHEL 8 e versioni successive
```
# pcs host auth primary-host-name secondary-host-name
```
RHEL 7
```
# pcs cluster auth primary-host-name secondary-host-name
```
Quando richiesto, inserisci il nome utente hacluster e la password impostata per l'utente hacluster.

Crea il cluster:

RHEL 8 e versioni successive

# pcs cluster setup cluster-name primary-host-name secondary-host-name

RHEL 7

# pcs cluster setup --name cluster-name primary-host-name secondary-host-name

Modifica le impostazioni predefinite di corosync.conf

Modifica il file /etc/corosync/corosync.conf sull'host principale per impostare un punto di partenza più appropriato per testare la tolleranza ai guasti del cluster HA su Google Cloud.

Su entrambi gli host, utilizza il tuo editor di testo preferito per aprire il /etc/corosync/corosync.conf file per la modifica:
```
# /etc/corosync/corosync.conf
```
Se /etc/corosync/corosync.conf è un nuovo file o è vuoto, puoi controllare la directory /etc/corosync/ per trovare un file di esempio da utilizzare come base per il file corosync.
Nella sezione totem del file corosync.conf, aggiungi le seguenti proprietà con i valori suggeriti come mostrato per la tua versione di RHEL:
RHEL 8 e versioni successive
- transport: knet
- token: 20000
- token_retransmits_before_loss_const: 10
- join: 60
- max_messages: 20
Ad esempio:
```
totem {
version: 2
cluster_name: hacluster
secauth: off
transport: knet
token: 20000
token_retransmits_before_loss_const: 10
join: 60
max_messages: 20
}
...
```
RHEL 7
- transport: udpu
- token: 20000
- token_retransmits_before_loss_const: 10
- join: 60
- max_messages: 20
Ad esempio:
```
totem {
version: 2
cluster_name: hacluster
secauth: off
transport: udpu
token: 20000
token_retransmits_before_loss_const: 10
join: 60
max_messages: 20
}
...
```
Dall'host che contiene il file corosync.conf modificato, sincronizza la configurazione di corosync nel cluster:
RHEL 8 e versioni successive
```
# pcs cluster sync corosync
```
RHEL 7
```
# pcs cluster sync
```
Imposta il cluster in modo che si avvii automaticamente:
```
# pcs cluster enable --all
```
```
# pcs cluster start --all
```
Verifica che le nuove impostazioni di corosync siano attive nel cluster utilizzando l'utilità corosync-cmapctl:
```
# corosync-cmapctl
```

Configurare la recinzione

Le immagini RHEL fornite da Google Cloud includono un agente di fence_gce fencing specifico per Google Cloud. Utilizza fence_gce per creare dispositivi di recinzione per ogni VM host.

Per garantire la sequenza corretta degli eventi dopo un'azione di recinzione, configura il sistema operativo in modo da ritardare il riavvio di Corosync dopo la recinzione di una VM. Modifica anche il timeout di Pacemaker per i riavvii in modo da tenere conto del ritardo.

Per visualizzare tutte le opzioni disponibili con l'agente di recinzione fence_gce, esegui il comando fence_gce -h.

Crea le risorse del dispositivo di recinzione

Nell'host principale come utente root:

Crea un dispositivo di recinzione per ogni VM host:

# pcs stonith create primary-fence-name fence_gce \
  port=primary-host-name \
  zone=primary-host-zone \
  project=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"
# pcs stonith create secondary-fence-name fence_gce \
  port=secondary-host-name \
  zone=secondary-host-zone \
  project=project-id \
  pcmk_reboot_timeout=300 pcmk_monitor_retries=4 \
  op monitor interval="300s" timeout="120s" \
  op start interval="0" timeout="60s"

Limita ogni dispositivo di recinzione all'altra VM host:

# pcs constraint location primary-fence-name avoids primary-host-name
# pcs constraint location secondary-fence-name avoids secondary-host-name

Nell'host principale come utente root, testa il dispositivo di recinzione secondario:
1. Arresta la VM host secondaria:
```
# fence_gce -o off -n secondary-host-name --zone=secondary-host-zone
```
  Se il comando va a buon fine, perdi la connettività con la VM host secondaria e questa viene visualizzata come interrotta nella pagina Istanze VM nella console Google Cloud. Potresti dover aggiornare la pagina.
2. Riavvia la VM host secondaria:
```
# fence_gce -o on -n secondary-host-name --zone=secondary-host-zone
```
Nell'host secondario, come utente root, testa il dispositivo di recinzione principale ripetendo i passaggi precedenti utilizzando i valori per l'host principale nei comandi.

Su uno degli host come utente root, controlla lo stato del cluster:

# pcs status

Le risorse di recinzione vengono visualizzate nella sezione delle risorse dello stato del cluster, in modo simile all'esempio seguente:

[root@maxdb-ha-vm-2 ~]# pcs status
Cluster name: maxdb-ha-cluster
Stack: corosync
Current DC: maxdb-ha-vm-1 (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
Last updated: Mon Jun 15 17:19:07 2020
Last change: Mon Jun 15 17:18:33 2020 by root via cibadmin on maxdb-ha-vm-1

2 nodes configured
2 resources configured

Online: [ maxdb-ha-vm-1 maxdb-ha-vm-2 ]

Full list of resources:

 STONITH-maxdb-ha-vm-1   (stonith:fence_gce):    Started maxdb-ha-vm-2
 STONITH-maxdb-ha-vm-2   (stonith:fence_gce):    Started maxdb-ha-vm-1

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

Imposta un ritardo per il riavvio di Corosync

Su entrambi gli host, come utente root, crea un file drop-in systemd che ritarda l'avvio di Corosync per garantire la sequenza corretta di eventi dopo il riavvio di una VM con recinzione:
```
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 del gestore systemd.
```
systemctl daemon-reload
```

Verifica che il file plug-in sia stato creato:

service corosync status

Dovresti vedere una riga per il file plug-in, come 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

Installa gli ascoltatori e crea una risorsa di controllo di integrità

Per configurare una risorsa di controllo di integrità, devi prima installare i listener.

Installa un listener

Il bilanciatore del carico utilizza un listener sulla porta del controllo di integrità di ciascun host per determinare dove è in esecuzione l'istanza MaxDB.

Come utente root su entrambi gli host, installa un listener TCP. Queste istruzioni descrivono come installare e utilizzare HAProxy come listener.
```
# yum install haproxy
```

Apri il file di configurazione haproxy.cfg per la modifica:

# vi /etc/haproxy/haproxy.cfg

Nella sezione defaults del file haproxy.cfg, cambia mode in tcplog.

Dopo la sezione predefiniti, crea una nuova sezione aggiungendo:

#---------------------------------------------------------------------
# Health check listener port for SAP MaxDB HA cluster
#---------------------------------------------------------------------
listen healthcheck
  bind *:healthcheck-port-num

La porta di associazione è la stessa utilizzata per creare il controllo di integrità.

Al termine, gli aggiornamenti dovrebbero essere simili al seguente esempio:

#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
  mode                    tcp
  log                     global
  option                  tcplog
  option                  dontlognull
  option http-server-close
  # option forwardfor       except 127.0.0.0/8
  option                  redispatch
  retries                 3
  timeout http-request    10s
  timeout queue           1m
  timeout connect         10s
  timeout client          1m
  timeout server          1m
  timeout http-keep-alive 10s
  timeout check           10s
  maxconn                 3000

#---------------------------------------------------------------------
# Set up health check listener for SAP MaxDB HA cluster
#---------------------------------------------------------------------
listen healthcheck
 bind *:60000

Su ogni host, come utente root, avvia il servizio per verificare che sia configurato correttamente:
```
# systemctl start haproxy.service
```
Nella pagina Bilanciatore del carico della console Google Cloud, fai clic sulla voce del bilanciatore del carico:

Pagina di bilanciamento del carico

Nella sezione Backend della pagina Dettagli bilanciatore del carico, se il servizio HAProxy è attivo su entrambi gli host, nella colonna Intatto di ogni voce del gruppo di istanze viene visualizzato 1/1.
Su ogni host, interrompi il servizio HAProxy:
```
# systemctl stop haproxy.service
```
Dopo aver interrotto il servizio HAProxy su ogni host, nella colonna Intatto di ogni gruppo di istanze viene visualizzato 0/1.

In seguito, quando il controllo di integrità è configurato, il cluster riavvia il listener sul nodo attivo.

Crea la risorsa di controllo di integrità

Su entrambi gli host come utente root, crea una risorsa di controllo di integrità per il servizio HAProxy:

# pcs resource create healthcheck_resource_name service:haproxy op monitor interval=10s timeout=20s —-group SAPMaxDB_Group

Verifica che il servizio di controllo di integrità sia attivo sullo stesso host dell'istanza SAP MaxDB:
```
# pcs status
```
Se la risorsa di controllo di integrità non si trova sullo stesso host di MaxDB, spostala con il seguente comando:
```
# pcs resource move healthcheck_resource_name target_host_name
# pcs resource clear healthcheck_resource_name
```
Il comando pcs resource clear lascia la risorsa nella nuova posizione, ma rimuove il vincolo di località indesiderato creato dal comando pcs resource move.

Nella sezione dello stato, la sezione delle risorse dovrebbe avere un aspetto simile all'esempio riportato di seguito:
```
Full list of resources:

STONITH-maxdb-ha-vm-1   (stonith:fence_gce):    Started maxdb-ha-vm-2
STONITH-maxdb-ha-vm-2   (stonith:fence_gce):    Started maxdb-ha-vm-1

Resource Group: SAPMaxDB_Group
  rsc_healthcheck_MDB    (service:haproxy):      Started maxdb-ha-vm-1
```

Impostare i valori predefiniti del cluster

Configura le soglie di migrazione e l'aderenza per determinare il numero di passaggi di failover da tentare prima del fallimento e per impostare il sistema in modo che provi prima a riavviare sull'host corrente. Questo valore deve essere impostato su un solo nodo per essere applicato al cluster.

Come utente root su entrambi gli host, imposta i valori predefiniti della risorsa:
```
# pcs resource defaults resource-stickiness=1000
# pcs resource defaults migration-threshold=5000
```
La proprietà resource-stickiness controlla la probabilità che un servizio rimanga in esecuzione dove si trova. I valori più elevati rendono il servizio più stabile. Un valore 1000 indica che il servizio è molto stabile.

La proprietà migration-threshold specifica il numero di errori che devono verificarsi prima che un servizio venga eseguito in un altro host. Un valore di 5000 è sufficientemente elevato per evitare il failover per situazioni di errore di durata più breve.

Puoi controllare i valori predefiniti della risorsa inserendo pcs resource defaults.
Imposta i valori predefiniti per il timeout delle operazioni sulle risorse:
```
# pcs resource op defaults timeout=600s
```
Puoi controllare i valori predefiniti delle operazioni sulle risorse inserendo pcs resource op defaults.
Imposta le seguenti proprietà del cluster:
```
# pcs property set stonith-enabled="true"
# pcs property set stonith-timeout="300s"
```
Puoi controllare le impostazioni della tua proprietà con pcs property list.

Creare risorse MaxDB nel cluster

Prima di eseguire questi passaggi, assicurati che MaxDB e x_server siano stati arrestati e che il file system /sapdb sia stato smontato.

Crea la risorsa gcp-pd-move

La risorsa gcp-pd-move è un agente di risorse utilizzato per spostare il disco permanente da un nodo all'altro durante un failover del cluster.

Crea la risorsa utilizzando il seguente comando come utente root su uno dei nodi:

# pcs resource create pd_move_resource_name gcp-pd-move \
  disk_name=regional_pd_name mode="READ_WRITE" disk_scope=regional \
  op monitor interval=10s timeout=15s \
  op start interval=0s timeout=300s \
  op stop interval=0s timeout=15s \
  --group SAPMaxDB_Group

Crea una risorsa LVM

Un agente di risorse attivato da LVM viene utilizzato per attivare LVM dopo che il disco è stato spostato nell'altro nodo.

Crea la risorsa LVM utilizzando il seguente comando come utente root su entrambi i nodi:

# pcs resource create lvm_resource_name LVM-activate \
  vgname=vgname_for_maxdb \
  vg_access_mode=system_id activation_mode=exclusive \
  --group SAPMaxDB_Group

Ad esempio:

# pcs resource create sapdb_lvm LVM-activate \
  vgname=sapdb vg_access_mode=system_id \
  activation_mode=exclusive \
  --group SAPMaxDB_Group

Crea la risorsa del file system

La risorsa del file system viene utilizzata nel cluster per smontare /sapdb e montarlo su un altro nodo durante l'operazione di failover.

Crea la risorsa del file system utilizzando il seguente comando come utente root su entrambi i nodi:

# pcs resource create fs_resource_name Filesystem \
  device=filesystem directory=/sapdb fstype=fs_type \
  --group SAPMaxDB_Group

Ad esempio:

# pcs resource create sapdb_FS Filesystem \
  device=/dev/mapper/sapdb-sapdblv directory=/sapdb fstype=ext4 \
  --group SAPMaxDB_Group

Preparativi per il gruppo di risorse MaxDB

Per attivare il gruppo di risorse MaxDB, devi eseguire i seguenti passaggi.

Sincronizza gli utenti e i gruppi dal nodo su cui hai eseguito l'installazione di MaxDB con l'altro nodo.
1. Gli utenti SAP MaxDB devono essere sincronizzati tra i nodi copiando le voci in /etc/passwd, ad esempio:
```
 sdb:x:1002:1003:MaxDB User:/home/sdb:/bin/false
 madbadm:x:1003:1005:SAP System Administrator:/home/mdbadm:/bin/csh
```
2. Analogamente, anche i gruppi SAP devono essere sincronizzati copiando le voci in /etc/group da un nodo all'altro, ad esempio:
```
 dba:x:1003:mdbadm
 sapsys:x:1005:
```

Sincronizza i file specifici di MaxDB che vengono memorizzati nelle directory del sistema operativo. Come utente root, esegui i seguenti comandi:

# rsync -av /etc/services target_host:/etc/services
# rsync -av /home/* target_host:/home
# rsync -av --exclude=sapservices /usr/sap/* target_host:/usr/sap
# rsync -av --ignore-existing /usr/sap/sapservicestarget_host:/usr/sap/sapservices
# rsync -av /etc/init.d/sapinittarget_host:/etc/init.d/

# MaxDB specific files
# rsync -av /etc/opttarget_host:/etc
# rsync -av /var/lib/sdbtarget_host:/var/lib

Per gli utenti del sistema operativo SAP sul secondo nodo, rinomina i seguenti file di ambiente per utilizzare il rispettivo nome host nelle relative directory home, ad esempio:

mv .sapenv_maxdb-ha-vm-1.sh .sapenv_maxdb-ha-vm-2.sh
mv .sapenv_maxdb-ha-vm-1.csh .sapenv_maxdb-ha-vm-2.csh
mv .sapsrc_maxdb-ha-vm-1.sh  .sapsrc_maxdb-ha-vm-2.sh
mv .sapsrc_maxdb-ha-vm-1.csh  .sapsrc_maxdb-ha-vm-2.csh
mv .dbenv_maxdb-ha-vm-1.sh .sapenv_maxdb-ha-vm-2.sh
mv .dbenv_maxdb-ha-vm-1.csh .dbenv_maxdb-ha-vm-2.csh

L'agente di risorse SAPDatabase non utilizza comandi specifici del database per arrestare o avviare il database, ma si basa sui comandi saphostctrl per eseguire la stessa operazione. L'agente host SAP richiede la creazione di voci xuser per il monitoraggio e il controllo di MAXDB utilizzando saphostctrl. Per ulteriori informazioni, consulta la nota SAP 2435938 - SAP Host Agent SAP MaxDB: DBCredentials for DB connect.

Come utente root, esegui il seguente comando per SetDatabaseProperty sul nodo attivo:

/usr/sap/hostctrl/exe/saphostctrl -host primary-host-name -user sapadm password \
  -dbname SID -dbtype ada -function SetDatabaseProperty DBCredentials=SET \
  -dboption User=SUPERDBA -dboption Password=password

Testa le voci utilizzando il seguente comando, anche se il database è fermo. Il comando dovrebbe essere in grado di ripristinare lo stato:

/usr/sap/hostctrl/exe/saphostctrl -host secondary-host-name -dbname SID \
  -dbtype ada -function GetDatabaseStatus

Il comando dell'agente saphostctrl utilizza il programma xuser dell'installazione di MaxDB e quindi, per preparare il secondo nodo, dovrai spostare SAPMaxDB_group in maxdb-node-b.

Su qualsiasi nodo, esegui il seguente comando come root:
```
pcs resource move SAPMaxDB_group
```

Nota che le quattro risorse create, Controllo di integrità, gcp-pd-move, LVM e File System, sono state migrate e avviate correttamente sul secondo nodo.

Puoi utilizzare il seguente comando su qualsiasi nodo per monitorare le azioni in esecuzione:
```
watch pcs status
```

Una volta avviate correttamente tutte e quattro le risorse sul secondo nodo, esegui il comando saphostctrl.

Come utente root, esegui il seguente comando per SetDatabaseProperty sul nodo ora attivo:

/usr/sap/hostctrl/exe/saphostctrl -host secondary-host-name -user sapadm password \
  -dbname SID -dbtype ada -function SetDatabaseProperty DBCredentials=SET \
  -dboption User=SUPERDBA -dboption Password=password

Sul nodo B, avvia manualmente MaxDB e x_server per verificare se possono essere avviati correttamente:
```
# dbmcli -d SID -u control, and password db_online
# x_server start
```

Vai al passaggio successivo per creare una risorsa per il database SAP. Se a questo punto vengono rilevati errori, non creare la risorsa database.

Creare una risorsa per SAP MaxDB

RHEL Pacemaker utilizza l'agente di risorse del database SAP per monitorare e controllare il database SAP.

Crea la risorsa database sul nodo in cui è attivo SAPMaxDB_group utilizzando il seguente comando:

# pcs resource create SAPDatabase_resource_name SAPDatabase \
  DBTYPE="ADA" SID="SID" STRICT_MONITORING="TRUE" \
  MONITOR_SERVICES="Database|x_server" AUTOMATIC_RECOVER="TRUE"
  --group SAPMaxDB_Group

Le risorse finali del cluster possono essere visualizzate utilizzando pcs status e il risultato previsto è il seguente:

# pcs status
  Cluster name: maxdb-cluster
  Stack: corosync
  Current DC: maxdb-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
  Last updated: Wed Oct 23 02:04:32 2024
  Last change: Wed Oct 23 02:01:41 2024 by hacluster via crmd on maxdb-ha-vm-1

  2 nodes configured
  7 resource instances configured

  Online: [ maxdb-ha-vm-1 maxdb-ha-vm-2 ]

  Full list of resources:

  STONITH-maxdb-ha-vm-1  (stonith:fence_gce):    Started maxdb-ha-vm-2
  STONITH-maxdb-ha-vm-2  (stonith:fence_gce):    Started maxdb-ha-vm-1
  Resource Group: SAPMaxDB_Group
     healthcheck_maxdb  (service:haproxy):      Started maxdb-ha-vm-1
     sapdb_regpd        (ocf::heartbeat:gcp-pd-move):   Started maxdb-ha-vm-1
     lvm_sapdb  (ocf::heartbeat:LVM-activate):  Started maxdb-ha-vm-1
     sapdb_fs   (ocf::heartbeat:Filesystem):    Started maxdb-ha-vm-1
     MDB_SAPMaxDB       (ocf::heartbeat:SAPDatabase):   Started maxdb-ha-vm-1

  Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

Test del failover

Testa il cluster simulando un errore sull'host attivo. Utilizza un sistema di test o esegui il test sul sistema di produzione prima di rilasciarlo per l'utilizzo.

Esegui il backup del sistema prima del test.

Puoi simulare un errore in diversi modi, ad esempio:

Interrompi manualmente MaxDB o x_server
Interrompi il processo MaxDB o x_server
reboot (sul nodo attivo)
ip link set eth0 down per le istanze con una singola interfaccia di rete
iptables ... DROP per le istanze con più interfacce di rete
echo c > /proc/sysrq-trigger

Queste istruzioni utilizzano ip link set eth0 down o iptables per simulare un'interruzione della rete tra i due host del cluster. Utilizza il comando ip link su un'istanza con una singola interfaccia di rete e il comando iptables su istanze con una o più interfacce di rete. Il test convalida sia il failover sia il fencing. Se le tue istanze hanno più interfacce di rete definite, utilizza il comando iptables sull'host secondario per eliminare il traffico in entrata e in uscita in base all'IP utilizzato dall'host principale per la comunicazione del cluster, simulando così una perdita di connessione di rete con l'host principale.

Nell'host attivo, come utente root, metti offline l'interfaccia di rete:
```
# ip link set eth0 down
```
Riconnettiti a uno degli host utilizzando SSH e passa all'utente root.

Inserisci pcs status per confermare che l'host precedentemente passivo ora ha il disco permanente regionale collegato e sta eseguendo i servizi MaxDB. Il riavvio automatico è abilitato nel cluster, pertanto l'host fermato si riavvierà e assumerà il ruolo di host passivo, come mostrato nell'esempio seguente:

Cluster name: maxdb-ha-cluster
Stack: corosync
Current DC: maxdb-ha-vm-2 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
Last updated: Wed Oct 23 02:01:45 2024
Last change: Wed Oct 23 02:01:41 2024 by hacluster via crmdon maxdb-ha-vm-2

2 nodes configured
7 resources configured

Online: [ maxdb-ha-vm-1 maxdb-ha-vm-2 ]

Full list of resources:

STONITH-maxdb-ha-vm-1   (stonith:fence_gce):    Started maxdb-ha-vm-2
STONITH-maxdb-ha-vm-2   (stonith:fence_gce):    Started maxdb-ha-vm-1

Resource Group: SAPMaxDB_Group
 healthcheck_maxdb  (service:haproxy):      Started maxdb-ha-vm-2
 sapdb_regpd        (ocf::heartbeat:gcp-pd-move):   Started maxdb-ha-vm-2
 lvm_sapdb  (ocf::heartbeat:LVM-activate):  Started maxdb-ha-vm-2
 sapdb_fs   (ocf::heartbeat:Filesystem):    Started maxdb-ha-vm-2
 MDB_SAPMaxDB       (ocf::heartbeat:SAPDatabase):   Started maxdb-ha-vm-2

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enabled

Risoluzione dei problemi

Per risolvere i problemi relativi alle configurazioni ad alta disponibilità per i sistemi SAP su RHEL, consulta Risoluzione dei problemi relativi alle configurazioni ad alta disponibilità per SAP.

Ricevi assistenza per SAP HANA su RHEL

Se hai bisogno di aiuto per risolvere un problema con i cluster ad alta disponibilità per SAP HANA su RHEL, raccogli le informazioni di diagnostica necessarie e contatta l'assistenza clienti Google Cloud. Per ulteriori informazioni, consulta Informazioni diagnostiche sui cluster ad alta disponibilità su RHEL.

Guida alla configurazione del cluster ad alta disponibilità per SAP MaxDB su RHEL

Il sistema di cui questa guida illustra il deployment

Prerequisiti

Creare una rete

Console

gcloud

Configurazione di un gateway NAT

aggiungi regole firewall

Console

gcloud

Esegui il deployment delle VM e installa MaxDB

Crea una VM per il deployment di MaxDB

Creare un singolo disco regionale per SAP MaxDB

Prepara il sistema operativo RHEL per l'installazione di SAP

Creare filesystem

Modifica la configurazione LVM

Installazione del database e dell'agente host SAP

Eseguire attività di post-installazione

Configurare il supporto del failover di Cloud Load Balancing

Prenota un indirizzo IP per l'IP virtuale

Crea gruppi di istanze per le VM host

Crea un controllo di integrità Compute Engine

Crea una regola firewall per i controlli di integrità

Configura il bilanciatore del carico e il gruppo di failover

Testa la configurazione del bilanciatore del carico

Test del bilanciatore del carico con l'utilità socat

Test del bilanciatore del carico utilizzando la porta 22

Configurare Pacemaker

Installa gli agenti del cluster su entrambi i nodi

Crea il cluster

RHEL 8 e versioni successive

RHEL 7

RHEL 8 e versioni successive

RHEL 7

Modifica le impostazioni predefinite di corosync.conf

RHEL 8 e versioni successive

RHEL 7

RHEL 8 e versioni successive

RHEL 7

Configurare la recinzione

Crea le risorse del dispositivo di recinzione

Imposta un ritardo per il riavvio di Corosync

Installa gli ascoltatori e crea una risorsa di controllo di integrità

Installa un listener

Crea la risorsa di controllo di integrità

Impostare i valori predefiniti del cluster

Creare risorse MaxDB nel cluster

Crea la risorsa gcp-pd-move

Crea una risorsa LVM

Crea la risorsa del file system

Preparativi per il gruppo di risorse MaxDB

Creare una risorsa per SAP MaxDB

Test del failover

Risoluzione dei problemi

Ricevi assistenza per SAP HANA su RHEL

Test del bilanciatore del carico con l'utilità `socat`