Questa pagina è stata tradotta dall'API Cloud Translation.

Guida alla configurazione manuale 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 ad 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 solo nodo su Linux, contatta l'assistenza clienti.

Questa guida è destinata agli utenti esperti di SAP MaxDB che hanno familiarità con le configurazioni HA di Linux per i sistemi SAP.

Il sistema che viene implementato da questa guida

Questa guida include i passaggi per:

Configurazione di un bilanciatore del carico di rete passthrough interno per reindirizzare il traffico in caso di errore
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.
Gestore delle risorse del cluster ad alta disponibilità Pacemaker.
Un meccanismo di isolamento STONITH.

L'installazione ad alta disponibilità di SAP NetWeaver non è trattata in questa guida.

Prerequisiti

Prima di creare il cluster ad alta disponibilità SAP MaxDB, 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 hai creato un progetto per il deployment di SAP MaxDB.
Se vuoi che il tuo carico di lavoro SAP venga eseguito 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 Controlli di conformità e sovranità per SAP su Google Cloud.
Se OS Login è attivato nei metadati del progetto, devi disattivarlo temporaneamente finché il deployment non è completato. Ai fini del deployment, questa procedura configura le chiavi SSH nei metadati dell'istanza. Quando OS Login è abilitato, le configurazioni delle chiavi SSH basate su metadati sono disattivate e questo deployment non va a buon fine. Una volta completato il deployment, puoi riattivare l'accesso al sistema operativo.

Per ulteriori informazioni, vedi:
- Attivazione o disattivazione di OS Login
- Aggiungi 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 metodocontrollo dell'accessoo.

Se il tuo progetto ha una rete VPC predefinita, non utilizzarla. Crea invece una rete VPC personalizzata in modo che le uniche regole firewall in vigore siano quelle che crei esplicitamente.

Durante il deployment, le istanze Compute Engine in genere richiedono l'accesso a internet per scaricare l'agente per SAP di Google Cloud. Se utilizzi una delle immagini Linux con certificazione SAP disponibili da Google Cloud, l'istanza di calcolo 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 tag di rete VM supporta questo accesso, anche se le istanze di computing 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 subnet.
3. Per 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.
  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.
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à 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 saperne di più, consulta 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 che hai creato 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 nella rete. Tieni presente che ogni subnet e i relativi intervalli IP interni sono mappati a una singola regione.
(Facoltativo) 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 la conversione degli indirizzi di rete (NAT) per consentire alle VM di accedere a internet. Utilizza Cloud NAT, un servizio gestito Google Cloud distribuito e software-defined che consente alle VM di inviare pacchetti in uscita a internet e ricevere i pacchetti di risposta in entrata 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 tue istanze VM possono accedere in modo sicuro a internet senza un indirizzo IP pubblico.

aggiungi regole firewall

Per impostazione predefinita, una regola firewall implicita blocca le connessioni in entrata provenienti dall'esterno della tua rete Virtual Private Cloud (VPC). Per consentire le connessioni in entrata, configura una regola firewall per la tua VM. Una volta stabilita una connessione in entrata con una VM, il traffico è consentito in entrambe le direzioni su quella 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 delle norme 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 dal tuo ambiente di rete aziendale alla tua istanza VM di Compute Engine. Se non sai 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 su Google Cloud a cui si applica questa regola. Ad esempio, specifica Tutte le istanze nella rete. oppure per limitare la regola a istanze specifiche su Google Cloud, inserisci i tag in Tag di destinazione 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 subnet specifica. Specifica il nome della subnet nel campo Subnet. Puoi utilizzare questa opzione per consentire l'accesso tra le VM in una configurazione a tre livelli o di scalabilità orizzontale.
- 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

Deployment delle VM e installazione di MaxDB

Prima di iniziare a configurare il cluster HA, definisci ed esegui il deployment delle istanze VM e dei sistemi SAP MaxDB che fungono da nodi primari e secondari nel cluster HA.

Crea una VM per il deployment di MaxDB

Nell'ambito del deployment HA, dovranno essere create due VM di Compute Engine. Google Cloud Puoi fare riferimento alla guida Crea e avvia un'istanza Compute Engine.

Tieni presente che il disco permanente regionale supporta solo l'utilizzo dei tipi di macchine E2, N1, N2 e N2D. Per ulteriori dettagli, consulta la guida ai dischi permanenti a livello di regione.

Consulta la nota SAP 2456432 - SAP applications on Google Cloud: Supported products and Google Cloud machine types per selezionare il tipo di macchina giusto in base al dimensionamento.

Crea le due VM in zone separate per ottenere la resilienza zonale, con i seguenti requisiti minimi:

Dettagli VM:
- Instance Name
- Zone - La tua zona preferita
- Machine Type - In base alle dimensioni
- Subnet: il nome della subnet creata per questa regione
Service account con ambito di accesso almeno 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

Crea 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 regionale 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 specifici del sistema operativo. Segui le linee guida riportate nella nota SAP: 2772999 - Red Hat Enterprise Linux 8.x: Installation and Configuration .

Questa attività deve essere eseguita su entrambi i nodi.

Creare file system

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 per 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 di Logical Volume Management (LVM) in modo che il gruppo di volumi (VG) condiviso sia sempre collegato e accessibile solo da un nodo.

Per farlo, esegui questi passaggi su entrambi i nodi:

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

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 gruppi di volumi gestiti dal cluster quando un nodo viene riavviato, mantieni il seguente parametro nel file di configurazione /etc/lvm/lvm.conf con i nomi completi dei gruppi di volumi separati da virgole che non sono gestiti dal cluster.

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

Ad esempio, quando usrsap è un nome VG non gestito dal cluster:
```
auto_activation_volume_list = [ usrsap ]
```
Quando non sono presenti gruppi di volumi non gestiti dal cluster, ad esempio, 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. MaxDB viene in genere installato con il prodotto SAP con cui è integrato.

Tieni presente che l'installazione verrà eseguita una sola volta, in quella a cui hai collegato il disco Persistent Disk regionale.

Per installare SAP MaxDB sulla tua VM:

Stabilisci una connessione SSH alla tua VM basata su Linux.
Scarica SAP Software Provisioning Manager (SWPM), i supporti di installazione del prodotto SAP e i supporti di installazione di MaxDB in base alle guide all'installazione SAP.
Installa il prodotto SAP e il database SAP MaxDB in base alle guide all'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.

Una volta completata l'installazione, esegui le seguenti convalide:

In qualità di 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 le attività 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 ed esegui il backup del nuovo database SAP MaxDB.

Per ulteriori informazioni, consulta SAP MaxDB Database Administration.

Dopo il deployment riuscito dei sistemi SAP MaxDB, definisci e configura il cluster HA.

Configura il supporto del failover di Cloud Load Balancing

Il servizio di 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 instrada il traffico inviato al 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. Questo è l'indirizzo IP che le applicazioni utilizzano 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 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 compresa nell'intervallo privato 49152-65535 per evitare conflitti con altri servizi. I valori di intervallo di controllo e timeout sono leggermente più lunghi rispetto ai valori 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 tue VM host dagli intervalli IP utilizzati dai controlli di integrità di Compute Engine, 35.191.0.0/16 e 130.211.0.0/22. Per saperne di più, consulta Creazione di regole firewall per i controlli di integrità.

Se non ne hai già uno, aggiungi un tag di rete alle tue 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 secondario di failover 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 affidabilità, 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 un secondo momento, puoi testare la configurazione del bilanciatore del carico configurando un listener che risponda ai controlli di integrità. Dopo aver configurato un listener, se il bilanciatore del carico è configurato correttamente, lo stato dei gruppi di istanza di backend cambia in Integro.

Le seguenti sezioni 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 la porta del 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 alcuni secondi che il controllo di integrità rilevi il listener, controlla l'integrità dei gruppiistanza di backendd:

$ 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à per utilizzare la porta 22, che ha 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, modifica il numero di porta in 22.
Fai clic su Salva e attendi un minuto o due.

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à originale.

Configura Pacemaker

La seguente procedura 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 affidabilità, 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 root, installa i componenti 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 ti viene 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 eseguito 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 nel 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 da Red Hat sulla configurazione del file /etc/hosts sui nodi del cluster RHEL, vedi https://access.redhat.com/solutions/81123.

Crea il cluster

Come root su uno dei nodi, autorizza l'utente hacluster. Fai clic sulla scheda relativa 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 che hai impostato 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 agli errori del cluster HA su Google Cloud.

Su uno dei due host, utilizza l'editor di testo che preferisci per aprire il file /etc/corosync/corosync.conf per la modifica:
```
# /etc/corosync/corosync.conf
```
Se /etc/corosync/corosync.conf è un nuovo file o è vuoto, puoi controllare la directory /etc/corosync/ per 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 l'avvio automatico del cluster:

# 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 l'isolamento

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

Per garantire la sequenza corretta di eventi dopo un'azione di isolamento, configura il sistema operativo in modo da ritardare il riavvio di Corosync dopo l'isolamento di una VM. Puoi anche regolare 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 fence_gce -h.

Crea le risorse del dispositivo di isolamento

Sull'host principale come root:

Crea un dispositivo di isolamento 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

Sull'host principale come root, testa il dispositivo di isolamento secondario:
1. Arresta la VM host secondaria:
```
# fence_gce -o off -n secondary-host-name --zone=secondary-host-zone
```
  Se il comando ha esito positivo, perdi la connettività alla VM host secondaria, che viene visualizzata come arrestata nella pagina Istanze VM della 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
```
Sull'host secondario come root, testa il dispositivo di isolamento principale ripetendo i passaggi precedenti utilizzando i valori dell'host principale nei comandi.

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

# pcs status

Le risorse di isolamento 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 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 isolata:
```
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 drop-in sia stato creato:

service corosync status

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

Installa i listener e crea una risorsa di controllo di integrità

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

Installare un listener

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

Come root su entrambi gli host, installa un listener TCP. Queste istruzioni installano e utilizzano HAProxy come listener.
```
# yum install haproxy
```

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

# vi /etc/haproxy/haproxy.cfg

Nella sezione defaults di haproxy.cfg, imposta mode su tcplog.

Dopo la sezione defaults, crea una nuova sezione aggiungendo:

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

La porta di binding è la stessa che hai utilizzato quando hai creato 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 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 Bilanciamento del carico

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

In un secondo momento, quando il controllo di integrità viene configurato, il cluster riavvia il listener sul nodo attivo.

Crea la risorsa di controllo di integrità

Su uno degli host come root, crea una risorsa del 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 del 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.

Nello stato, la sezione delle risorse dovrebbe essere simile all'esempio seguente:
```
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 la persistenza per determinare il numero di failover da tentare prima dell'errore e per impostare il sistema in modo che tenti il riavvio sull'host corrente. Questa impostazione deve essere configurata su un solo nodo per essere applicata al cluster.

Come root su uno degli host, imposta i valori predefiniti delle risorse:
```
# 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 nella posizione in cui si trova. Valori più alti rendono il servizio più persistente. Un valore di 1000 significa che il servizio è molto coinvolgente.

La proprietà migration-threshold specifica il numero di errori che devono verificarsi prima che un servizio esegua il failover su un altro host. Un valore di 5000 è sufficientemente alto per impedire il failover per situazioni di errore di breve durata.

Puoi controllare i valori predefiniti delle risorse inserendo pcs resource defaults.
Imposta i valori predefiniti del timeout dell'operazione della risorsa:
```
# pcs resource op defaults timeout=600s
```
Puoi controllare i valori predefiniti dell'opzione di risorsa 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 proprietà con pcs property list.

Crea risorse MaxDB nel cluster

Prima di eseguire questi passaggi, assicurati che MaxDB e x_server siano arrestati e che il file system /sapdb sia 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 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 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 root su uno dei 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 montarla su un altro nodo durante l'operazione di failover.

Crea la risorsa del file system utilizzando il seguente comando come root su uno dei 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 abilitare 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 all'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. Allo stesso modo, 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 archiviati 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 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. SAP Host Agent richiede la creazione di xuser voci per il monitoraggio e il controllo riusciti di MAXDB utilizzando saphostctrl. Per ulteriori informazioni, consulta la nota SAP 2435938 - SAP Host Agent SAP MaxDB: DBCredentials for DB connect.

Come root, esegui questo 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 è arrestato 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 dall'installazione di MaxDB e quindi, per preparare il secondo nodo ora, sposterai SAPMaxDB_group su maxdb-node-b.

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

Osserva 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 eseguite:
```
watch pcs status
```

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

Come root, esegui il seguente comando per impostare 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
```

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

Crea 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 del 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 cluster finali 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

Testa il 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 rilasciare il sistema per l'uso.

Esegui il backup del sistema prima del test.

Puoi simulare un errore in vari modi, tra cui:

Arresta manualmente MaxDB o x_server
Termina 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 di 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 che il fencing. Nel caso in cui le tue istanze abbiano più interfacce di rete definite, utilizzi 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 all'host principale.

Sull'host attivo, come 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 passivo precedente ora ha il disco permanente regionale collegato ed esegue i servizi MaxDB. Il riavvio automatico è abilitato nel cluster, quindi l'host arrestato verrà riavviato 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.

Richiedere 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 diagnostiche richieste e contatta l'assistenza clienti Google Cloud. Per saperne di più, consulta Informazioni diagnostiche sui cluster ad alta disponibilità su RHEL.

Guida alla configurazione manuale del cluster ad alta disponibilità per SAP MaxDB su RHEL Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Il sistema che viene implementato da questa guida

Prerequisiti

Creare una rete

Console

gcloud

Configurazione di un gateway NAT

aggiungi regole firewall

Console

gcloud

Deployment delle VM e installazione di MaxDB

Crea una VM per il deployment di MaxDB

Crea un singolo disco regionale per SAP MaxDB

Prepara il sistema operativo RHEL per l'installazione di SAP

Creare file system

Modifica la configurazione LVM

Installazione del database e dell'agente host SAP

Eseguire le attività post-installazione

Configura 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

Configura 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 l'isolamento

Crea le risorse del dispositivo di isolamento

Imposta un ritardo per il riavvio di Corosync

Installa i listener e crea una risorsa di controllo di integrità

Installare un listener

Crea la risorsa di controllo di integrità

Impostare i valori predefiniti del cluster

Crea risorse MaxDB nel cluster

Crea la risorsa gcp-pd-move

Crea risorsa LVM

Crea la risorsa del file system

Preparativi per il gruppo di risorse MaxDB

Crea una risorsa per SAP MaxDB

Testa il failover

Risoluzione dei problemi

Richiedere assistenza per SAP HANA su RHEL

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

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