Guida alla configurazione manuale dei cluster ad alta disponibilità per SAP NetWeaver su RHEL

Questa guida mostra come eseguire il deployment e configurare un cluster ad alta disponibilità (HA) Red Hat Enterprise Linux (RHEL) ad alta disponibilità (HA) ottimizzato per le prestazioni per il sistema SAP NetWeaver.

Questa guida include i passaggi per:

Questa guida include anche i passaggi per configurare il sistema SAP NetWeaver per l'alta disponibilità, ma fai riferimento alla documentazione SAP per le istruzioni definitive.

Per informazioni sul deployment delle VM di Compute Engine per SAP NetWeaver non specifiche per l'alta disponibilità, consulta la guida al deployment di SAP NetWeaver specifica per il tuo sistema operativo.

Per configurare un cluster ad alta disponibilità per SAP NetWeaver su SUSE Linux Enterprise Server (SLES), consulta la guida alla configurazione manuale dei cluster ad alta disponibilità per SAP NetWeaver su SLES.

Questa guida è rivolta agli utenti avanzati di SAP NetWeaver che hanno familiarità con le configurazioni Linux ad alta disponibilità per SAP NetWeaver.

Il sistema di cui viene eseguito il deployment in questa guida

Seguendo questa guida, eseguirai il deployment di due istanze SAP NetWeaver e configurerai un cluster ad alta disponibilità su RHEL. Il deployment di ogni istanza SAP NetWeaver su una VM di Compute Engine si trova in una zona diversa all'interno della stessa regione. Un'installazione ad alta disponibilità del database sottostante non è trattata in questa guida.

Panoramica di un cluster Linux ad alta disponibilità per un sistema SAP NetWeaver a nodo singolo

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

  • Due VM host, una per l'istanza ASCS attiva e una per l'istanza attiva di ENSA2 Enqueue Replicator o ENSA1 Enqueue Replication Server (ENSA1). Entrambe le istanze ENSA2 ed ENSA1 sono definite ERS.
  • Il gestore delle risorse del cluster ad alta disponibilità di Pacemaker.
  • Un meccanismo di recinzione STONITH.
  • Riavvio automatico dell'istanza non riuscita come nuova istanza secondaria.
Questa guida illustra l'utilizzo dei modelli di Cloud Deployment Manager forniti da Google Cloud per eseguire il deployment delle macchine virtuali (VM) di Compute Engine, in modo che le VM soddisfino i requisiti di supportabilità SAP e siano conformi alle best practice attuali.

Per utilizzare Terraform per automatizzare il deployment dei sistemi SAP NetWeaver ad alta disponibilità, consulta Terraform: guida alla configurazione dei cluster ad alta disponibilità per SAP NetWeaver su RHEL.

Prerequisiti

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

Salvo laddove richiesto per l'ambiente Google Cloud, le informazioni contenute in questa guida sono coerenti con le seguenti guide correlate di Red Hat e SAP:

Creare una rete

Per motivi di sicurezza, crea una nuova rete. Puoi controllare chi ha accesso aggiungendo regole firewall o utilizzando un altro metodo di controllo dell'accesso.

Se il progetto ha una rete VPC predefinita, non utilizzarla. Crea invece la tua rete VPC in modo che le uniche regole firewall in vigore siano quelle create in modo esplicito.

Durante il deployment, le istanze VM richiedono in genere l'accesso a internet per scaricare l'agente di Google Cloud per SAP. Se utilizzi una delle immagini Linux certificate per SAP disponibili in Google Cloud, l'istanza VM richiede anche l'accesso a internet per poter registrare la licenza e accedere ai repository dei fornitori di sistemi operativi. Una configurazione con un gateway NAT e con tag di rete VM supporta questo accesso, anche se le VM di destinazione non hanno IP esterni.

Per configurare il networking:

Console

  1. Nella console Google Cloud, vai alla pagina Reti VPC.

    Vai a Reti VPC

  2. Fai clic su Crea rete VPC.
  3. 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.

  4. In Modalità di creazione subnet, scegli Personalizzata.
  5. Nella sezione Nuova subnet, specifica i seguenti parametri di configurazione per una subnet:
    1. Inserisci un nome per la subnet.
    2. In Regione, seleziona la regione di Compute Engine in cui vuoi creare la subnet.
    3. Per il Tipo di stack IP, seleziona IPv4 (stack singolo), quindi 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 a ciascuna 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.
  6. Per aggiungere altre subnet, fai clic su Aggiungi subnet e ripeti i passaggi precedenti. Dopo aver creato la rete, puoi aggiungere altre subnet alla rete.
  7. Fai clic su Crea.

gcloud

  1. Vai a Cloud Shell.

    Vai a Cloud Shell

  2. 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 ulteriori informazioni, consulta la sezione Modalità di creazione delle subnet.

  3. 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 che venga creata 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.

  4. Se vuoi, ripeti il passaggio precedente e aggiungi altre subnet.

Configurazione di un gateway NAT

Se devi creare una o più VM senza indirizzi IP pubblici, devi utilizzare Network Address Translation (NAT) per consentire alle VM di accedere a internet. Utilizza Cloud NAT, un servizio gestito software-defined distribuito e software-defined di Google Cloud che consente alle VM di inviare pacchetti in uscita a internet e ricevere i pacchetti di risposta in entrata stabiliti corrispondenti. In alternativa, puoi configurare una VM separata come gateway NAT.

Per creare un'istanza Cloud NAT per il progetto, consulta Utilizzo di Cloud NAT.

Dopo aver configurato Cloud NAT per il tuo progetto, le istanze VM possono accedere in modo sicuro a internet senza un indirizzo IP pubblico.

aggiungi regole firewall

Per impostazione predefinita, le connessioni in entrata dall'esterno della rete Google Cloud sono bloccate. Per consentire le connessioni in entrata, configura una regola firewall per la tua VM. Le regole firewall regolano solo le nuove connessioni in entrata a una VM. Dopo aver stabilito una connessione con una VM, il traffico è consentito in entrambe le direzioni su quella connessione.

Puoi creare una regola firewall per consentire l'accesso alle porte specificate o per consentire l'accesso tra VM nella stessa subnet.

Crea regole firewall per consentire l'accesso a:

  • Le porte predefinite utilizzate da SAP NetWeaver, come documentato in Porte TCP/IP di tutti i prodotti SAP.
  • Connessioni dal tuo computer o dal tuo ambiente di rete aziendale all'istanza VM di Compute Engine. Se hai dubbi su quale indirizzo IP usare, rivolgiti all'amministratore di rete della tua azienda.
  • Comunicazione tra VM in una configurazione a 3 livelli, con scale out o ad alta disponibilità. Ad esempio, se esegui il deployment di un sistema a tre livelli, avrai almeno due VM nella tua subnet: la VM per SAP NetWeaver e un'altra VM per il server di database. Per abilitare la comunicazione tra le due VM, devi creare una regola firewall per consentire il traffico che ha origine dalla subnet.
  • Controlli di integrità di Cloud Load Balancing. Per maggiori informazioni, consulta Creare una regola firewall per i controlli di integrità.

Per creare una regola firewall:

  1. Nella console Google Cloud, vai alla pagina Firewall della rete VPC.

    Vai a Firewall

  2. Nella parte superiore della pagina, fai clic su Crea regola firewall.

    • Nel campo Rete, seleziona la rete in cui si trova la VM.
    • Nel campo Destinazioni, seleziona Tutte le istanze nella rete.
    • Nel campo Filtro di origine, seleziona una delle seguenti opzioni:
      • Intervalli IP per consentire il traffico in entrata da indirizzi IP specifici. Specifica l'intervallo di indirizzi IP nel campo Intervalli IP di origine.
      • Subnet per consentire il traffico in entrata da una determinata subnet. Specifica il nome della subnet nei seguenti campi di subnet. Puoi utilizzare questa opzione per consentire l'accesso tra le VM in una configurazione a 3 livelli o con scale out.
    • Nella sezione Protocolli e porte, seleziona Protocolli e porte specificati e specifica tcp:PORT_NUMBER;.
  3. Fai clic su Crea per creare la regola firewall.

Deployment delle VM per SAP NetWeaver

Prima di iniziare a configurare il cluster ad alta disponibilità, definisci ed esegui il deployment delle istanze VM che serviranno come nodi primari e secondari nel cluster ad alta disponibilità.

Per definire ed eseguire il deployment delle VM, utilizza lo stesso modello di Cloud Deployment Manager che utilizzi per eseguire il deployment di una VM per un sistema SAP NetWeaver in Deployment automatico delle VM per SAP NetWeaver su Linux.

Tuttavia, per eseguire il deployment di due VM anziché una, devi aggiungere al file di configurazione la definizione della seconda VM copiando e incollando la definizione della prima VM. Dopo aver creato la seconda definizione, devi modificare i nomi delle risorse e delle istanze nella seconda definizione. Per evitare errori a livello di zona, specifica una zona diversa nella stessa regione. Tutti gli altri valori delle proprietà nelle due definizioni rimangono invariati.

Una volta eseguito il deployment delle VM, devi installare SAP NetWeaver e definire e configurare il cluster ad alta disponibilità.

Le istruzioni seguenti utilizzano Cloud Shell, ma sono generalmente applicabili a Google Cloud CLI.

  1. Apri Cloud Shell.

    Vai a Cloud Shell

  2. Scarica il modello del file di configurazione YAML, template.yaml, nella tua directory di lavoro:

    wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/template.yaml

  3. Se vuoi, rinomina il file template.yaml per identificare la configurazione che definisce. Ad esempio, nw-ha-rhel-8-4.yaml.

  4. Apri il file di configurazione YAML nell'editor di codice Cloud Shell facendo clic sull'icona a forma di matita () nell'angolo in alto a destra della finestra del terminale Cloud Shell per avviare l'editor.

  5. Nel modello del file di configurazione YAML, definisci la prima istanza VM. La seconda istanza VM verrà definita nel passaggio successivo dopo la tabella seguente.

    Specifica i valori delle proprietà sostituendo le parentesi e i relativi contenuti con i valori per l'installazione. Le proprietà sono descritte nella tabella seguente. Per un esempio di file di configurazione completo, consulta Esempio di file di configurazione YAML completo.

    Proprietà Tipo di dati Descrizione
    name Stringa Un nome arbitrario che identifica la risorsa di deployment definita dal seguente insieme di proprietà.
    type Stringa

    Specifica la posizione, il tipo e la versione del modello di Deployment Manager da utilizzare durante il deployment.

    Il file YAML include due specifiche type, una delle quali è commentata. La specifica type attiva per impostazione predefinita specifica la versione del modello come latest. La specifica type commentata specifica una versione specifica del modello con un timestamp.

    Se vuoi che tutti i deployment utilizzino la stessa versione del modello, utilizza la specifica type che include il timestamp.

    instanceName Stringa Il nome dell'istanza VM che stai definendo. Specifica nomi diversi nelle definizioni delle VM principali e secondarie. Valuta la possibilità di utilizzare nomi che identificano le istanze come appartenenti allo stesso cluster ad alta disponibilità.

    I nomi delle istanze devono contenere al massimo 13 caratteri ed essere specificati in lettere minuscole, numeri o trattini. Utilizza un nome univoco all'interno del progetto.

    instanceType Stringa Il tipo di VM di Compute Engine di cui hai bisogno. Specifica lo stesso tipo di istanza per le VM primarie e secondarie.

    Se hai bisogno di un tipo di VM personalizzata, specifica un tipo di VM predefinita di dimensioni ridotte e, dopo il completamento del deployment, personalizza la VM in base alle tue esigenze.

    zone Stringa La zona Google Cloud in cui eseguire il deployment dell'istanza VM che stai definendo. Specifica zone diverse nella stessa regione per le definizioni delle VM primarie e secondarie. Le zone devono trovarsi nella stessa regione selezionata per la subnet.
    subnetwork Stringa Il nome della subnet che hai creato in un passaggio precedente. Se esegui il deployment in un VPC condiviso, specifica questo valore come SHAREDVPC_PROJECT/SUBNETWORK. Ad esempio, myproject/network1.
    linuxImage Stringa Il nome dell'immagine o della famiglia di immagini del sistema operativo Linux che utilizzi con SAP NetWeaver. Per specificare una famiglia di immagini, aggiungi il prefisso family/ al nome della famiglia. Ad esempio, family/rhel-8-4-sap-ha. Per l'elenco delle famiglie di immagini disponibili, consulta la pagina Immagini nella console Google Cloud.
    linuxImageProject Stringa Il progetto Google Cloud che contiene l'immagine che utilizzerai. Può trattarsi del tuo progetto o del progetto di immagini Google Cloud rhel-sap-cloud. Per un elenco dei progetti di immagine di Google Cloud, consulta la pagina Immagini nella documentazione di Compute Engine.
    usrsapSize Numero intero La dimensione del disco /usr/sap. La dimensione minima è 8 GB.
    sapmntSize Numero intero La dimensione del disco /sapmnt. La dimensione minima è 8 GB.
    swapSize Numero intero Le dimensioni del volume di scambio. La dimensione minima è 1 GB.
    networkTag Stringa

    Facoltativo. Uno o più tag di rete separati da virgole che rappresentano l'istanza VM a scopo di firewall o di routing.

    Per le configurazioni ad alta disponibilità, specifica un tag di rete da utilizzare per una regola firewall che consente la comunicazione tra i nodi del cluster e un tag di rete da utilizzare in una regola firewall che consente ai controlli di integrità di Cloud Load Balancing di accedere ai nodi cluster.

    Se specifichi publicIP: No e non specifichi un tag di rete, assicurati di fornire un altro mezzo per accedere a internet.

    serviceAccount Stringa

    Facoltativo. Specifica un account di servizio personalizzato da utilizzare per la VM di cui è stato eseguito il deployment. L'account di servizio deve includere le autorizzazioni necessarie durante il deployment per configurare la VM per SAP.

    Se serviceAccount non è specificato, viene utilizzato l'account di servizio Compute Engine predefinito.

    Specifica l'indirizzo completo dell'account di servizio. Ad esempio: sap-ha-example@example-project-123456.iam.gserviceaccount.com

    publicIP Booleano Facoltativo. Determina se un indirizzo IP pubblico viene aggiunto all'istanza VM. Il valore predefinito è Yes.
    sap_deployment_debug Booleano Facoltativo. Se questo valore è impostato su Yes, il deployment genera log di deployment dettagliati. Non attivare questa impostazione a meno che un tecnico del servizio di assistenza Google non ti chieda di abilitare il debug.
  6. Nel file di configurazione YAML, crea la definizione della seconda VM copiando la definizione della prima VM e incollando la copia dopo la prima definizione. Per un esempio, consulta Esempio di file di configurazione YAML completo.

  7. Nella definizione della seconda VM, specifica valori diversi per le seguenti proprietà rispetto a quelli specificati nella prima definizione:

    • name
    • instanceName
    • zone
  8. Crea le istanze VM:

    gcloud deployment-manager deployments create DEPLOYMENT_NAME --config TEMPLATE_NAME.yaml

    dove:

    • DEPLOYMENT_NAME rappresenta il nome del deployment.
    • TEMPLATE_NAME rappresenta il nome del file di configurazione YAML.

    Il comando precedente richiama Deployment Manager, che esegue il deployment delle VM in base alle specifiche nel file di configurazione YAML.

    L'elaborazione del deployment prevede due fasi. Nella prima fase, Deployment Manager scrive il proprio stato nella console. Nella seconda fase, gli script di deployment scrivono il proprio stato in Cloud Logging.

Esempio di file di configurazione YAML completo

L'esempio seguente mostra un file di configurazione YAML completo che esegue il deployment di due istanze VM per una configurazione ad alta disponibilità per SAP NetWeaver utilizzando la versione più recente dei modelli di Deployment Manager. L'esempio omette i commenti contenuti nel modello quando lo scarichi per la prima volta.

Il file contiene le definizioni di due risorse di cui eseguire il deployment: sap_nw_node_1 e sap_nw_node_2. Ogni definizione di risorsa contiene le definizioni di una VM.

La definizione della risorsa sap_nw_node_2 è stata creata copiando e incollando la prima definizione e poi modificando i valori delle proprietà name, instanceName e zone. Tutti gli altri valori delle proprietà nelle due definizioni di risorsa sono gli stessi.

Le proprietà networkTag e serviceAccount provengono dalla sezione Opzioni avanzate del modello del file di configurazione.

resources:
- name: sap_nw_node_1
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/sap_nw.py
  properties:
    instanceName: nw-ha-vm-1
    instanceType: n2-standard-4
    zone: us-central1-b
    subnetwork: example-sub-network-sap
    linuxImage: family/rhel-8-4-sap-ha
    linuxImageProject: rhel-sap-cloud
    usrsapSize: 15
    sapmntSize: 15
    swapSize: 24
    networkTag: cluster-ntwk-tag,allow-health-check
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com
- name: sap_nw_node_2
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/sap_nw.py
  properties:
    instanceName: nw-ha-vm-2
    instanceType: n2-standard-4
    zone: us-central1-c
    subnetwork: example-sub-network-sap
    linuxImage: family/rhel-8-4-sap-ha
    linuxImageProject: rhel-sap-cloud
    usrsapSize: 15
    sapmntSize: 15
    swapSize: 24
    networkTag: cluster-ntwk-tag,allow-health-check
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com

Creare regole firewall che consentono l'accesso alle VM host

Se non lo hai già fatto, crea regole firewall che consentano l'accesso a ogni VM host dalle seguenti origini:

  • Ai fini della configurazione, la workstation locale, un bastion host o un jump server
  • Per l'accesso tra i nodi del cluster, le altre VM host nel cluster ad alta disponibilità
  • I controlli di integrità utilizzati da Cloud Load Balancing, come descritto nel passaggio successivo Creare una regola firewall per i controlli di integrità.

Quando crei regole firewall VPC, specifichi i tag di rete definiti nel file di configurazione template.yaml per designare le VM host come destinazione per la regola.

Per verificare il deployment, definisci una regola per consentire le connessioni SSH sulla porta 22 da un bastion host o dalla tua workstation locale.

Per l'accesso tra i nodi cluster, aggiungi una regola firewall che consenta tutti i tipi di connessione su qualsiasi porta da altre VM nella stessa subnet.

Assicurati che vengano create le regole firewall per verificare il deployment e per la comunicazione tra cluster prima di passare alla sezione successiva. Per le istruzioni, vedi Aggiunta delle regole firewall.

verifica del deployment delle VM

Prima di installare SAP NetWeaver o di iniziare a configurare il cluster ad alta disponibilità, verifica che il deployment delle VM sia stato eseguito correttamente controllando i log e la mappatura dell'archiviazione del sistema operativo.

Controlla i log

  1. Nella console Google Cloud, apri Cloud Logging per monitorare l'avanzamento dell'installazione e verificare l'eventuale presenza di errori.

    Vai a Cloud Logging

  2. Filtra i log:

    Esplora log

    1. Nella pagina Esplora log, vai al riquadro Query.

    2. Nel menu a discesa Risorsa, seleziona Globale e fai clic su Aggiungi.

      Se non vedi l'opzione Globale, inserisci la seguente query nell'Editor query:

      resource.type="global"
      "Deployment"
      
    3. Fai clic su Esegui query.

    Visualizzatore log legacy

    • Nella pagina Visualizzatore log legacy, dal menu del selettore di base, seleziona Globale come risorsa di logging.
  3. Analizza i log filtrati:

    • Se viene visualizzato "--- Finished", l'elaborazione del deployment è completata e puoi andare al passaggio successivo.
    • Se viene visualizzato un errore di quota:

      1. Nella pagina Quote di IAM e amministrazione, aumenta le quote che non soddisfano i requisiti di SAP NetWeaver elencati nella guida alla pianificazione di SAP NetWeaver.

      2. Nella pagina Deployment di Deployment Manager, elimina il deployment per ripulire le VM e i dischi permanenti dall'installazione non riuscita.

      3. Esegui nuovamente il deployment.

Controlla la configurazione delle VM

  1. Dopo il deployment delle istanze VM, connettiti alle VM utilizzando ssh.

    1. Se non l'hai ancora fatto, crea una regola firewall per consentire una connessione SSH sulla porta 22.
    2. Vai alla pagina Istanze VM.

      Vai a Istanze VM

    3. Connettiti a ogni istanza VM facendo clic sul pulsante SSH nella voce di ogni istanza VM oppure puoi utilizzare il tuo metodo SSH preferito.

      Pulsante SSH nella pagina delle istanze VM di Compute Engine.

  2. Visualizza il file system:

    ~> df -h

    Assicurati che venga visualizzato un output simile al seguente:

    Filesystem                 Size  Used Avail Use% Mounted on
    devtmpfs                    32G  8.0K   32G   1% /dev
    tmpfs                       48G     0   48G   0% /dev/shm
    tmpfs                       32G  402M   32G   2% /run
    tmpfs                       32G     0   32G   0% /sys/fs/cgroup
    /dev/sda3                   30G  3.4G   27G  12% /
    /dev/sda2                   20M  3.7M   17M  19% /boot/efi
    /dev/mapper/vg_usrsap-vol   15G   48M   15G   1% /usr/sap
    /dev/mapper/vg_sapmnt-vol   15G   48M   15G   1% /sapmnt
    tmpfs                      6.3G     0  6.3G   0% /run/user/1002
    tmpfs                      6.3G     0  6.3G   0% /run/user/0
  3. Verifica che lo spazio di scambio sia stato creato:

    ~> cat /proc/meminfo | grep Swap

    Vedrai risultati simili al seguente esempio:

    SwapCached:            0 kB
    SwapTotal:      25161724 kB
    SwapFree:       25161724 kB

Se uno dei passaggi di convalida indica che l'installazione non è riuscita:

  1. Correggi l'errore.
  2. Nella pagina Deployment elimina il deployment per pulire le VM e i dischi permanenti dall'installazione non riuscita.
  3. Esegui nuovamente il deployment.

Abilita la comunicazione back-end del bilanciatore del carico tra le VM

Dopo aver verificato che le VM di cui è stato eseguito il deployment correttamente, abilita la comunicazione di backend tra le VM che serviranno da nodi nel cluster ad alta disponibilità.

Puoi abilitare la comunicazione di backend tra le VM modificando la configurazione di google-guest-agent, inclusa nell'ambiente guest Linux per tutte le immagini pubbliche Linux fornite da Google Cloud.

Per abilitare le comunicazioni backend del bilanciatore del carico, esegui questi passaggi su ogni VM che fa parte del cluster:

  1. Interrompi l'agente:

    sudo service google-guest-agent stop
  2. Apri o crea il file /etc/default/instance_configs.cfg per la modifica. Ad esempio:

    sudo vi /etc/default/instance_configs.cfg
  3. Nel file /etc/default/instance_configs.cfg, specifica le seguenti proprietà di configurazione come mostrato. Se le sezioni non esistono, creale. In particolare, assicurati che entrambe le proprietà target_instance_ips e ip_forwarding siano impostate su false:

    [IpForwarding]
    ethernet_proto_id = 66
    ip_aliases = true
    target_instance_ips = false
    
    [NetworkInterfaces]
    dhclient_script = /sbin/google-dhclient-script
    dhcp_command =
    ip_forwarding = false
    setup = true
    
  4. Avvia il servizio di agente ospite:

    sudo service google-guest-agent start

La configurazione del controllo di integrità del bilanciatore del carico richiede una porta target di ascolto per il controllo di integrità e l'assegnazione dell'IP virtuale a un'interfaccia. Per maggiori informazioni, consulta Testare la configurazione del bilanciatore del carico.

Configura le chiavi SSH sulle VM primarie e secondarie

Per consentire la copia dei file tra gli host nel cluster ad alta disponibilità, i passaggi descritti in questa sezione consentono di creare connessioni SSH radice tra i due host.

I modelli di Deployment Manager forniti da Google Cloud generano una chiave per te, ma puoi sostituirla con una chiave generata da te, se necessario.

È probabile che la tua organizzazione disponga di linee guida che regolano le comunicazioni di rete interne. Se necessario, al termine del deployment, puoi rimuovere i metadati dalle VM e le chiavi dalla directory authorized_keys.

Se la configurazione di connessioni SSH dirette non è conforme alle linee guida della tua organizzazione, puoi trasferire i file utilizzando altri metodi, ad esempio:

Per abilitare le connessioni SSH tra le istanze principali e secondarie, segui questi passaggi. I passaggi presuppongono che utilizzi la chiave SSH generata dai modelli di Deployment Manager per SAP.

  1. Sulla VM host principale:

    1. Connettiti alla VM tramite SSH.

    2. Passa alla directory principale:

      $ sudo su -
    3. Verifica che la chiave SSH esista:

      # ls -l /root/.ssh/

      Dovresti vedere i file della chiave id_rsa come nell'esempio seguente:

      -rw-r--r-- 1 root root  569 May  4 23:07 authorized_keys
      -rw------- 1 root root 2459 May  4 23:07 id_rsa
      -rw-r--r-- 1 root root  569 May  4 23:07 id_rsa.pub
    4. Aggiornare i metadati della VM principale con informazioni sulla chiave SSH per la VM secondaria.

      # gcloud compute instances add-metadata SECONDARY_VM_NAME \
      --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \
      --zone SECONDARY_VM_ZONE
    5. Verifica che le chiavi SSH siano configurate correttamente aprendo una connessione SSH dal sistema principale al sistema secondario:

      # ssh SECONDARY_VM_NAME
  2. Sulla VM host secondaria:

    1. SSH nella VM.

    2. Passa alla directory principale:

      $ sudo su -
    3. Verifica che la chiave SSH esista:

      # ls -l /root/.ssh/

      Dovresti vedere i file della chiave id_rsa come nell'esempio seguente:

      -rw-r--r-- 1 root root  569 May  4 23:07 authorized_keys
      -rw------- 1 root root 2459 May  4 23:07 id_rsa
      -rw-r--r-- 1 root root  569 May  4 23:07 id_rsa.pub
    4. Aggiornare i metadati della VM secondaria con informazioni sulla chiave SSH per la VM principale.

      # gcloud compute instances add-metadata PRIMARY_VM_NAME \
      --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \
      --zone PRIMARY_VM_ZONE
      # cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
    5. Verifica che le chiavi SSH siano configurate correttamente aprendo una connessione SSH dal sistema secondario al sistema principale.

      # ssh PRIMARY_VM_NAME

Configura l'archiviazione file condivisa e configura le directory condivise

Devi configurare una soluzione di condivisione file NFS che fornisca archiviazione di file condivisa a disponibilità elevata a cui possono accedere entrambi i nodi del cluster ad alta disponibilità. Successivamente, creerai directory su entrambi i nodi che corrispondono all'archiviazione dei file condivisa. Il software del cluster assicura che le directory appropriate vengano montate solo nelle istanze corrette.

L'impostazione di una soluzione di condivisione file non è trattata in questa guida. Per istruzioni sulla configurazione del sistema di condivisione file, consulta le istruzioni fornite dal fornitore della soluzione selezionata. Se scegli di utilizzare Filestore per la tua soluzione di condivisione file, ti consigliamo di utilizzare il livello Enterprise di Filestore. Per scoprire come creare un'istanza Filestore, consulta Creazione di istanze.

Per informazioni sulle soluzioni di condivisione file disponibili in Google Cloud, consulta Opzioni di archiviazione condivisa per sistemi SAP ad alta disponibilità su Google Cloud.

Per configurare le directory condivise:

  1. Se non hai già configurato una soluzione di archiviazione di file condivisa NFS a disponibilità elevata, fallo ora.

  2. Monta l'archiviazione condivisa NFS su entrambi i server per la configurazione iniziale.

    ~> sudo mkdir /mnt/nfs
    ~> sudo mount -t nfs NFS_PATH /mnt/nfs

    Sostituisci NFS_PATH con il percorso della soluzione di condivisione file NFS. Ad esempio, 10.49.153.26:/nfs_share_nw_ha.

  3. Da entrambi i server, crea le directory per sapmnt, la directory di trasporto centrale e la directory specifica dell'istanza. Se utilizzi uno stack Java, sostituisci "ASCS" con "SCS" prima di utilizzare i comandi seguenti e qualsiasi altro comando di esempio:

    ~> sudo mkdir /mnt/nfs/sapmntSID
    ~> sudo mkdir /mnt/nfs/usrsap{trans,SIDASCSASCS_INSTANCE_NUMBER,SIDERSERS_INSTANCE_NUMBER}

    Sostituisci quanto segue:

    • SID: l'ID sistema SAP (SID). Usa le maiuscole per tutte le lettere. Ad esempio, AHA.
    • ASCS_INSTANCE_NUMBER: il numero di istanza del sistema ASCS. Ad esempio, 00.
    • ERS_INSTANCE_NUMBER: il numero di istanza del sistema ERS. Ad esempio, 10.
  4. Su entrambi i server, crea i punti di montaggio necessari:

    ~> sudo mkdir -p /sapmnt/SID
    ~> sudo mkdir -p /usr/sap/trans
    ~> sudo mkdir -p /usr/sap/SID/ASCSASCS_INSTANCE_NUMBER
    ~> sudo mkdir -p /usr/sap/SID/ERSERS_INSTANCE_NUMBER
  5. Configura autofs per montare le directory dei file condivise comuni al primo accesso alle directory dei file. Il montaggio delle directory ASCSASCS_INSTANCE_NUMBER e ERSERS_INSTANCE_NUMBER è gestito dal software del cluster, che configurerai in un passaggio successivo.

    Regola le opzioni NFS nei comandi in base alle esigenze della tua soluzione di condivisione file.

    Su entrambi i server, configura autofs:

    ~> echo "/- /etc/auto.sap" | sudo tee -a /etc/auto.master
    ~> NFS_OPTS="-rw,relatime,vers=3,hard,proto=tcp,timeo=600,retrans=2,mountvers=3,mountport=2050,mountproto=tcp"
    ~> echo "/sapmnt/SID ${NFS_OPTS} NFS_PATH/sapmntSID" | sudo tee -a /etc/auto.sap
    ~> echo "/usr/sap/trans ${NFS_OPTS} NFS_PATH/usrsaptrans" | sudo tee -a /etc/auto.sap

    Per maggiori informazioni su autofs, consulta la pagina autofs - come funziona.

  6. Su entrambi i server, avvia il servizio autofs:

    ~> sudo systemctl enable autofs
    ~> sudo systemctl restart autofs
    ~> sudo automount -v
  7. Attiva autofs per montare le directory condivise accedendo a ogni directory utilizzando il comando cd. Ad esempio:

    ~> cd /sapmnt/SID
    ~> cd /usr/sap/trans
    
  8. Dopo aver eseguito l'accesso a tutte le directory, esegui il comando df -Th per confermare che le directory siano montate.

    ~> df -Th | grep FILE_SHARE_NAME

    Sostituisci FILE_SHARE_NAME con il nome della tua soluzione di condivisione file NFS. Ad esempio, nfs_share_nw_ha.

    Dovresti vedere i punti di montaggio e le directory simili a quanto segue:

    10.49.153.26:/nfs_share_nw_ha              nfs      1007G   76M  956G   1% /mnt/nfs
    10.49.153.26:/nfs_share_nw_ha/usrsaptrans  nfs      1007G   76M  956G   1% /usr/sap/trans
    10.49.153.26:/nfs_share_nw_ha/sapmntAHA    nfs      1007G   76M  956G   1% /sapmnt/AHA

Configura il supporto del failover di Cloud Load Balancing

Il servizio Bilanciatore del carico di rete passthrough interno con supporto del failover instrada il traffico ASCS e ERS alle istanze attive di ciascuna in un cluster SAP NetWeaver. I bilanciatori del carico di rete passthrough interni utilizzano indirizzi IP virtuali, servizi di backend, gruppi di istanze e controlli di integrità per instradare il traffico in modo appropriato.

Prenota gli indirizzi IP per gli IP virtuali

Per un cluster SAP NetWeaver ad alta disponibilità, crei due VIP, a volte indicati come indirizzi IP mobili. Un VIP segue l'istanza attiva di SAP Central Services (SCS) e l'altro segue l'istanza ERS (Enqueue Replication Server). Il bilanciatore del carico instrada il traffico inviato a ogni VIP alla VM che ospita l'istanza attiva del componente ASCS o ERS del VIP.

  1. Apri Cloud Shell:

    Vai a Cloud Shell

  2. Prenotare un indirizzo IP per l'IP virtuale dell'ASCS e per il VIP dell'ERS. Per ASCS, l'indirizzo IP è l'indirizzo IP utilizzato dalle applicazioni per accedere a SAP NetWeaver. Per ERS, l'indirizzo IP è l'indirizzo IP utilizzato per la replica del server di enqueue. Se ometti il flag --addresses, viene scelto automaticamente un indirizzo IP nella subnet specificata:

    ~ gcloud compute addresses create ASCS_VIP_NAME \
      --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
      --addresses ASCS_VIP_ADDRESS
    
    ~ gcloud compute addresses create ERS_VIP_NAME \
      --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
      --addresses ERS_VIP_ADDRESS

    Sostituisci quanto segue:

    • ASCS_VIP_NAME: specifica un nome per l'indirizzo IP virtuale dell'istanza ASCS. Ad esempio, ascs-aha-vip.
    • CLUSTER_REGION: specifica la regione Google Cloud in cui si trova il cluster. Ad esempio, us-central1
    • CLUSTER_SUBNET: specifica la subnet che utilizzi con il cluster. Ad esempio, example-sub-network-sap.
    • ASCS_VIP_ADDRESS: facoltativamente, specifica un indirizzo IP per l'IP virtuale ASCS in notazione CIDR. Ad esempio, 10.1.0.2.
    • ERS_VIP_NAME: specifica un nome per l'indirizzo IP virtuale dell'istanza ERS. Ad esempio, ers-aha-vip.
    • ERS_VIP_ADDRESS: facoltativamente, specifica un indirizzo IP per l'IP virtuale ERS in notazione CIDR. Ad esempio, 10.1.0.4.

    Per saperne di più sulla prenotazione di un IP statico, consulta Prenotare un indirizzo IP interno statico.

  3. Conferma prenotazione indirizzo IP:

    ~ gcloud compute addresses describe VIP_NAME \
      --region CLUSTER_REGION

    Dovresti vedere un output simile al seguente esempio:

    address: 10.1.0.2
    addressType: INTERNAL
    creationTimestamp: '2022-04-04T15:04:25.872-07:00'
    description: ''
    id: '555067171183973766'
    kind: compute#address
    name: ascs-aha-vip
    networkTier: PREMIUM
    purpose: GCE_ENDPOINT
    region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1
    selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/addresses/ascs-aha-vip
    status: RESERVED
    subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-sub-network-sap

Definisci i nomi host per l'indirizzo VIP in /etc/hosts

Definisci un nome host per ogni indirizzo VIP, quindi aggiungi gli indirizzi IP e i nomi host sia per le VM che per i VIP al file /etc/hosts su ogni VM.

I nomi host VIP non sono noti al di fuori delle VM, a meno che non li aggiungi anche al servizio DNS. L'aggiunta di queste voci al file /etc/hosts locale protegge il cluster da eventuali interruzioni del servizio DNS.

Gli aggiornamenti al file /etc/hosts dovrebbero avere un aspetto simile al seguente esempio:

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.1.0.113 nw-ha-vm-2.us-central1-c.c.example-project-123456.internal nw-ha-vm-2
10.1.0.2   ascs-aha-vip
10.1.0.4   ers-aha-vip
10.1.0.114 nw-ha-vm-1.us-central1-b.c.example-project-123456.internal nw-ha-vm-1  # Added by Google
169.254.169.254 metadata.google.internal  # Added by Google

crea i controlli di integrità di Cloud Load Balancing

Crea i controlli di integrità: uno per l'istanza ASCS attiva e uno per l'ERS attivo.

  1. In Cloud Shell, crea i controlli di integrità. Per evitare conflitti con altri servizi, designa i numeri di porta per le istanze ASCS ed ERS nell'intervallo privato 49152-65535. I valori di controllo dell'intervallo e di timeout nei comandi seguenti sono leggermente più lunghi dei valori predefiniti in modo da aumentare la tolleranza di failover durante gli eventi di migrazione live di Compute Engine. Se necessario, puoi modificare i valori:

    1. ~ gcloud compute health-checks create tcp ASCS_HEALTH_CHECK_NAME \
      --port=ASCS_HEALTHCHECK_PORT_NUM --proxy-header=NONE --check-interval=10 --timeout=10 \
      --unhealthy-threshold=2 --healthy-threshold=2
    2. ~ gcloud compute health-checks create tcp ERS_HEALTH_CHECK_NAME \
      --port=ERS_HEALTHCHECK_PORT_NUM --proxy-header=NONE --check-interval=10 --timeout=10 \
      --unhealthy-threshold=2 --healthy-threshold=2
  2. Conferma la creazione di ciascun controllo di integrità:

    ~ gcloud compute health-checks describe HEALTH_CHECK_NAME

    Dovresti vedere un output simile al seguente esempio:

    checkIntervalSec: 10
    creationTimestamp: '2021-05-12T15:12:21.892-07:00'
    healthyThreshold: 2
    id: '1981070199800065066'
    kind: compute#healthCheck
    name: ascs-aha-health-check-name
    selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/scs-aha-health-check-name
    tcpHealthCheck:
      port: 60000
      portSpecification: USE_FIXED_PORT
      proxyHeader: NONE
    timeoutSec: 10
    type: TCP
    unhealthyThreshold: 2

Crea una regola firewall per i controlli di integrità

Se non l'hai ancora fatto, definisci una regola firewall per una porta nell'intervallo privato che consenta l'accesso alle VM host dagli intervalli IP utilizzati dai controlli di integrità di Cloud Load Balancing, 35.191.0.0/16 e 130.211.0.0/22. Per ulteriori informazioni sulle regole firewall per i bilanciatori del carico, consulta Creazione di regole firewall per i controlli di integrità.

  1. Se non ne hai già uno, aggiungi un tag di rete alle VM host. Questo tag di rete è utilizzato dalla regola firewall per i controlli di integrità.

  2. Crea una regola firewall che utilizzi il tag di rete per consentire i controlli di integrità:

    ~ gcloud compute firewall-rules create  RULE_NAME \
      --network=NETWORK_NAME \
      --action=ALLOW \
      --direction=INGRESS \
      --source-ranges=35.191.0.0/16,130.211.0.0/22 \
      --target-tags=NETWORK_TAGS \
      --rules=tcp:ASCS_HEALTHCHECK_PORT_NUM,tcp:ERS_HEALTHCHECK_PORT_NUM

    Ad esempio:

    gcloud compute firewall-rules create  nw-ha-cluster-health-checks \
    --network=example-network \
    --action=ALLOW \
    --direction=INGRESS \
    --source-ranges=35.191.0.0/16,130.211.0.0/22 \
    --target-tags=allow-health-check \
    --rules=tcp:60000,tcp:60010

crea gruppi di istanze Compute Engine

Devi creare un gruppo di istanze in ogni zona che contiene una VM con nodo cluster e aggiungere la VM in quella zona al gruppo di istanze.

  1. In Cloud Shell, crea il gruppo di istanze principale e aggiungi al suo interno la VM principale:

    1. ~ gcloud compute instance-groups unmanaged create PRIMARY_IG_NAME \
      --zone=PRIMARY_ZONE
    2. ~ gcloud compute instance-groups unmanaged add-instances PRIMARY_IG_NAME \
      --zone=PRIMARY_ZONE \
      --instances=PRIMARY_VM_NAME
  2. In Cloud Shell, crea il gruppo di istanze secondarie e aggiungi la VM secondaria:

    1. ~ gcloud compute instance-groups unmanaged create SECONDARY_IG_NAME \
      --zone=SECONDARY_ZONE
    2. ~ gcloud compute instance-groups unmanaged add-instances SECONDARY_IG_NAME \
      --zone=SECONDARY_ZONE \
      --instances=SECONDARY_VM_NAME
  3. 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
    sap-aha-primary-instance-group    us-central1-b  example-network-sap  example-project-123456  No       1
    sap-aha-secondary-instance-group  us-central1-c  example-network-sap  example-project-123456  No       1
    

Configura i servizi di backend

Crea due servizi di backend, uno per ASCS e uno per ERS. Aggiungi entrambi i gruppi di istanze a ogni servizio di backend, designando il gruppo di istanze opposto come gruppo di istanze di failover in ogni servizio di backend. Infine, crea regole di forwarding dai VIP ai servizi di backend.

  1. In Cloud Shell, crea il servizio di backend e il gruppo di failover per ASCS:

    1. Crea il servizio di backend per ASCS:

      ~ gcloud compute backend-services create ASCS_BACKEND_SERVICE_NAME \
         --load-balancing-scheme internal \
         --health-checks ASCS_HEALTH_CHECK_NAME \
         --no-connection-drain-on-failover \
         --drop-traffic-if-unhealthy \
         --failover-ratio 1.0 \
         --region CLUSTER_REGION \
         --global-health-checks
    2. Aggiungi il gruppo di istanze principale al servizio di backend ASCS:

      ~ gcloud compute backend-services add-backend ASCS_BACKEND_SERVICE_NAME \
        --instance-group PRIMARY_IG_NAME \
        --instance-group-zone PRIMARY_ZONE \
        --region CLUSTER_REGION
    3. Aggiungi il gruppo di istanze secondarie come gruppo di istanze di failover per il servizio di backend ASCS:

      ~ gcloud compute backend-services add-backend ASCS_BACKEND_SERVICE_NAME \
        --instance-group SECONDARY_IG_NAME \
        --instance-group-zone SECONDARY_ZONE \
        --failover \
        --region CLUSTER_REGION
  2. In Cloud Shell, crea il servizio di backend e il gruppo di failover per ERS:

    1. Crea il servizio di backend per ERS:

      ~ gcloud compute backend-services create ERS_BACKEND_SERVICE_NAME \
      --load-balancing-scheme internal \
      --health-checks ERS_HEALTH_CHECK_NAME \
      --no-connection-drain-on-failover \
      --drop-traffic-if-unhealthy \
      --failover-ratio 1.0 \
      --region CLUSTER_REGION \
      --global-health-checks
    2. Aggiungi il gruppo di istanze secondarie al servizio di backend ERS:

      ~ gcloud compute backend-services add-backend ERS_BACKEND_SERVICE_NAME \
        --instance-group SECONDARY_IG_NAME \
        --instance-group-zone SECONDARY_ZONE \
        --region CLUSTER_REGION
    3. Aggiungi il gruppo di istanze principale come gruppo di istanze di failover per il servizio di backend ERS:

      ~ gcloud compute backend-services add-backend ERS_BACKEND_SERVICE_NAME \
        --instance-group PRIMARY_IG_NAME \
        --instance-group-zone PRIMARY_ZONE \
        --failover \
        --region CLUSTER_REGION
  3. Facoltativamente, verifica che i servizi di backend contengano i gruppi di istanze come previsto:

    ~ gcloud compute backend-services describe BACKEND_SERVICE_NAME \
     --region=CLUSTER_REGION

    Dovresti vedere un output simile all'esempio seguente per il servizio di backend ASCS. Per ERS, verrebbe visualizzato failover: true nel gruppo di istanze principale:

    backends:
    - balancingMode: CONNECTION
      group: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group
    - balancingMode: CONNECTION
      failover: true
      group: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group
    connectionDraining:
      drainingTimeoutSec: 0
    creationTimestamp: '2022-04-06T10:58:37.744-07:00'
    description: ''
    failoverPolicy:
      disableConnectionDrainOnFailover: true
      dropTrafficIfUnhealthy: true
      failoverRatio: 1.0
    fingerprint: s4qMEAyhrV0=
    healthChecks:
    - https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/ascs-aha-health-check-name
    id: '6695034709671438882'
    kind: compute#backendService
    loadBalancingScheme: INTERNAL
    name: ascs-aha-backend-service-name
    protocol: TCP
    region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1
    selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/backendServices/ascs-aha-backend-service-name
    sessionAffinity: NONE
    timeoutSec: 30
  4. In Cloud Shell, crea regole di forwarding per i servizi di backend ASCS ed ERS:

    1. Crea la regola di forwarding dal VIP ASCS al servizio di backend ASCS:

      ~ gcloud compute forwarding-rules create ASCS_FORWARDING_RULE_NAME \
      --load-balancing-scheme internal \
      --address ASCS_VIP_ADDRESS \
      --subnet CLUSTER_SUBNET \
      --region CLUSTER_REGION \
      --backend-service ASCS_BACKEND_SERVICE_NAME \
      --ports ALL
    2. Crea la regola di forwarding dal VIP ERS al servizio di backend ERS:

      ~ gcloud compute forwarding-rules create ERS_FORWARDING_RULE_NAME \
      --load-balancing-scheme internal \
      --address ERS_VIP_ADDRESS \
      --subnet CLUSTER_SUBNET \
      --region CLUSTER_REGION \
      --backend-service ERS_BACKEND_SERVICE_NAME \
      --ports ALL

Testa la configurazione del bilanciatore del carico

Anche se i gruppi di istanza di backend non si registrano come integri fino a dopo, puoi testare la configurazione del bilanciatore del carico impostando 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 diventa integro.

Le seguenti sezioni illustrano diversi metodi che puoi utilizzare per testare la configurazione.

Test del bilanciatore del carico con l'utilità socat

Puoi utilizzare l'utilità socat per rimanere temporaneamente in ascolto su una porta per il controllo di integrità.

  1. Su entrambe le VM host, installa l'utilità socat:

    $ sudo yum install socat

  2. Sulla VM principale, assegna temporaneamente il VIP alla scheda di rete eth0:

    ip addr add VIP_ADDRESS dev eth0
  3. Sulla VM principale, avvia un processo socat per rimanere in ascolto per 60 secondi sulla porta per il controllo di integrità ASCS:

    $ timeout 60s socat - TCP-LISTEN:ASCS_HEALTHCHECK_PORT_NUM,fork

  4. In Cloud Shell, dopo aver atteso alcuni secondi affinché il controllo di integrità rilevasse il listener, controlla l'integrità del gruppo di istanza di backend ASCS:

    ~ gcloud compute backend-services get-health ASCS_BACKEND_SERVICE_NAME \
      --region CLUSTER_REGION

    Dovresti vedere un output simile al seguente esempio per ASCS:

    backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group
    status:
      healthStatus:
      - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
        forwardingRuleIp: 10.1.0.90
        healthState: HEALTHY
        instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instances/nw-ha-vm-1
        ipAddress: 10.1.0.89
        port: 80
      kind: compute#backendServiceGroupHealth
    ---
    backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group
    status:
      healthStatus:
      - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
        forwardingRuleIp: 10.1.0.90
        healthState: UNHEALTHY
        instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/nw-ha-vm-2
        ipAddress: 10.1.0.88
        port: 80
      kind: compute#backendServiceGroupHealth
  5. Rimuovi il VIP dall'interfaccia eth0:

    ip addr del VIP_ADDRESS dev eth0
  6. Ripeti i passaggi per l'ERS, sostituendo i valori della variabile ASCS con i valori ERS.

Test del bilanciatore del carico utilizzando la porta 22

Se la porta 22 è aperta per le connessioni SSH sulle VM host, puoi modificare temporaneamente il controllo di integrità in modo da utilizzare la porta 22, che ha un listener in grado di rispondere al controllo di integrità.

Per utilizzare temporaneamente la porta 22, svolgi i seguenti passaggi:

  1. Nella console Google Cloud, vai alla pagina Controlli di integrità di Compute Engine:

    Vai a Controlli di integrità

  2. Fai clic sul nome del controllo di integrità.

  3. Fai clic su Modifica.

  4. Nel campo Porta, imposta il numero di porta su 22.

  5. Fai clic su Salva e attendi un paio di minuti.

  6. In Cloud Shell, dopo aver atteso alcuni secondi affinché il controllo di integrità rilevasse il listener, controlla l'integrità dei gruppi di istanza di backend:

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

    Dovresti vedere un output simile al seguente:

    backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group
    status:
      healthStatus:
      - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
        forwardingRuleIp: 10.1.0.85
        healthState: HEALTHY
        instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instances/nw-ha-vm-1
        ipAddress: 10.1.0.79
        port: 80
      kind: compute#backendServiceGroupHealth
    ---
    backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group
    status:
      healthStatus:
      - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
        forwardingRuleIp: 10.1.0.85
        healthState: HEALTHY
        instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/nw-ha-vm-2
        ipAddress: 10.1.0.78
        port: 80
      kind: compute#backendServiceGroupHealth
  7. Al termine, ripristina il numero di porta originale per il controllo di integrità.

Installa listener per i controlli di integrità

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

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

Su ogni host del cluster, installa un listener completando questi passaggi:

  1. Come root, installa un semplice listener TCP. Queste istruzioni installano e utilizzano HAProxy come listener.

    # yum install haproxy
  2. Copia e rinomina il file di configurazione haproxy.cfg predefinito per renderlo un file modello per più istanze haproxy:

    # cp /usr/lib/systemd/system/haproxy.service \
        /etc/systemd/system/haproxy@.service
    
  3. Modifica le sezioni [Unit] e [Service] del file haproxy@.service in modo da includere il parametro dell'istanza %i, come mostrato nell'esempio seguente:

    [Unit]
    Description=HAProxy Load Balancer %i
    After=network-online.target
    Wants=network-online.target
    
    [Service]
    Environment="CONFIG=/etc/haproxy/haproxy-%i.cfg" "PIDFILE=/run/haproxy-%i.pid"
    ...
    

    Per maggiori informazioni da Red Hat sui modelli di unità systemd, consulta Utilizzo delle unità per cui è stata creata un'istanza.

  4. Crea un file di configurazione haproxy.cfg per l'istanza ASCS. Ad esempio:

    # vi /etc/haproxy/haproxy-SIDscs.cfg

    Sostituisci SID con l'ID sistema SAP (SID). Utilizza le maiuscole per tutte le lettere. Ad esempio, AHA.

  5. Nel file di configurazione ASCS haproxy-SIDscs.cfg, inserisci la configurazione seguente e sostituisci ASCS_HEALTHCHECK_PORT_NUM con il numero di porta specificato al momento della creazione del controllo di integrità di Compute Engine per ASCS in precedenza:

    global
        chroot      /var/lib/haproxy
        pidfile     /var/run/haproxy-%i.pid
        user        haproxy
        group       haproxy
        daemon
    defaults
        mode                    tcp
        log                     global
        option                  dontlognull
        option                  redispatch
        retries                 3
        timeout queue           1m
        timeout connect         10s
        timeout client          1m
        timeout server          1m
        timeout check           10s
        maxconn                 3000
    
    # Listener for SAP healthcheck
    listen healthcheck
       bind *:ASCS_HEALTHCHECK_PORT_NUM
  6. Crea un file di configurazione haproxy.cfg per l'istanza ERS. Ad esempio:

    # vi /etc/haproxy/haproxy-SIDers.cfg
  7. Nel file di configurazione ERS di haproxy-SIDers.cfg, inserisci la configurazione seguente e sostituisci ERS_HEALTHCHECK_PORT_NUM con il numero di porta specificato al momento della creazione precedente del controllo di integrità per ERS di Compute Engine:

    global
        chroot      /var/lib/haproxy
        pidfile     /var/run/haproxy-%i.pid
        user        haproxy
        group       haproxy
        daemon
    defaults
        mode                    tcp
        log                     global
        option                  dontlognull
        option                  redispatch
        retries                 3
        timeout queue           1m
        timeout connect         10s
        timeout client          1m
        timeout server          1m
        timeout check           10s
        maxconn                 3000
    
    # Listener for SAP healthcheck
    listen healthcheck
       bind *:ERS_HEALTHCHECK_PORT_NUM
  8. Ricarica i servizi systemd:

    # systemctl daemon-reload
  9. Verifica che il servizio haproxy sia configurato correttamente:

     # systemctl start haproxy
     # systemctl status haproxy
     # systemctl | grep haproxy

    Lo stato restituito dovrebbe mostrare haproxy.service come active (running).

    ● haproxy.service - HAProxy Load Balancer
       Loaded: loaded (/usr/lib/systemd/system/haproxy.service; enabled; vendor preset: disabled)
       Active: active (running) since Sun 2022-04-10 16:48:10 UTC; 2 days ago
     Main PID: 1079 (haproxy)
        Tasks: 2 (limit: 100996)
       Memory: 5.1M
       CGroup: /system.slice/haproxy.service
               ├─1079 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
               └─1083 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
    
    Apr 10 16:48:10 dru-hanw-ascs systemd[1]: Starting HAProxy Load Balancer...
    Apr 10 16:48:10 dru-hanw-ascs systemd[1]: Started HAProxy Load Balancer.
  10. Ripeti i passaggi precedenti su ciascun host nel cluster.

Configurazione di pacemaker

La seguente procedura configura l'implementazione RHEL di un cluster Pacemaker sulle VM di Compute Engine per SAP NetWeaver.

La procedura si basa sulla documentazione di Red Hat per la configurazione di cluster ad alta disponibilità, tra cui le seguenti pubblicazioni (è richiesto un abbonamento a Red Hat):

Per informazioni di SAP sull'installazione e sulla configurazione di RHEL, consulta:

Configura i pacchetti di cluster e il firewall del sistema operativo richiesti su entrambi gli host

Come root sia sull'host principale che su quello secondario, installa e aggiorna i pacchetti di cluster richiesti, configura hacluster e configura il servizio firewall del sistema operativo.

  1. Installa i seguenti pacchetti di cluster obbligatori:

    # yum install pcs pacemaker
    # yum install fence-agents-gce
    # yum install resource-agents-gcp
    # yum install resource-agents-sap
    # yum install sap-cluster-connector
  2. Aggiorna i pacchetti installati:

    # yum update -y
  3. Imposta la password per l'utente hacluster, che viene installato come parte dei pacchetti cluster:

    # passwd hacluster
  4. Specifica una password per hacluster quando richiesto.

  5. 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
  6. Avvia il servizio PC e configuralo in modo che venga avviato al momento dell'avvio:

    # systemctl start pcsd.service
    # systemctl enable pcsd.service
  7. Controlla lo stato del servizio PC:

    # 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 2020-06-13 21:17:05 UTC; 25s ago
        Docs: man:pcsd(8)
              man:pcs(8)
    Main PID: 31627 (pcsd)
      CGroup: /system.slice/pcsd.service
              └─31627 /usr/bin/ruby /usr/lib/pcsd/pcsd
    Jun 13 21:17:03 hana-ha-vm-1 systemd[1]: Starting PCS GUI and remote configuration interface...
    Jun 13 21:17:05 hana-ha-vm-1 systemd[1]: Started PCS GUI and remote configuration interface.

Crea il cluster

  1. Come root su entrambi i nodi, autorizza l'utente hacluster. Fai clic sulla scheda relativa alla tua versione RHEL per visualizzare il comando:

    RHEL 8 e versioni successive

    # pcs host auth PRIMARY_VM_NAME SECONDARY_VM_NAME

    RHEL 7

    # pcs cluster auth PRIMARY_VM_NAME SECONDARY_VM_NAME
  2. Nei prompt, inserisci il nome utente hacluster e la password che hai impostato per l'utente hacluster.

  3. Crea il cluster:

    RHEL 8 e versioni successive

    # pcs cluster setup CLUSTER_NAME PRIMARY_VM_NAME SECONDARY_VM_NAME

    RHEL 7

    # pcs cluster setup --name CLUSTER_NAME PRIMARY_VM_NAME SECONDARY_VM_NAME

Aggiorna i file di configurazione di Corosync

I passaggi seguenti impostano i valori consigliati del cluster per Corosync. Se il file di configurazione di Corosync, /etc/corosync/corosync.conf, non esiste ancora o è vuoto, puoi utilizzare il file di esempio nella directory /etc/corosync/ come base per la configurazione.

  1. Apri il file corosync.conf per la modifica:

    # vi /etc/corosync/corosync.conf
  2. Nella sezione totem del file corosync.conf, imposta i parametri dell'esempio estratto che segue sui valori che vengono mostrati. Alcuni parametri potrebbero essere già impostati sui valori corretti:

    RHEL 8

    totem {
    ...
      transport: knet
      token: 20000
      token_retransmits_before_loss_const: 10
      join: 60
      max_messages: 20
    ...
    }

    RHEL 7

    totem {
    ...
      transport: udpu
      token: 20000
      token_retransmits_before_loss_const: 10
      join: 60
      max_messages: 20
    ...
    }
  3. Sincronizza la configurazione con il secondo server:

    RHEL 8 e versioni successive

    # pcs cluster sync corosync

    RHEL 7

    # pcs cluster sync
  4. Dalla VM principale, abilita e avvia il cluster

    # pcs cluster enable --all
    # pcs cluster start --all
  5. Conferma che le nuove impostazioni di corosync siano attive nel cluster utilizzando l'utilità corosync-cmapctl:

    # corosync-cmapctl
  6. Controlla lo stato del cluster:

    # pcs status

    Dovresti vedere un output simile al seguente esempio:

    Cluster name: nwha
    
    WARNINGS:
    No stonith devices and stonith-enabled is not false
    
    Cluster Summary:
    * Stack: corosync
    * Current DC: nw-ha-vm-2 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum
    * 2 nodes configured
    * 0 resource instances configured
    
    Node List:
    * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
    
    Full List of Resources:
    * No resources
    
    Daemon Status:
    corosync: active/enabled
    pacemaker: active/enabled
    pcsd: active/enabled

Configura le risorse del cluster per l'infrastruttura

Devi definire le risorse Pacemaker per la seguente infrastruttura del cluster:

  • Il dispositivo di recinzione, che previene le spaccature cerebrali
  • Le directory ASCS ed ERS nel file system condiviso
  • I controlli di integrità
  • I VIP
  • I componenti ASCS ed ERS

Devi definire innanzitutto le risorse per il dispositivo di recinzione, il file system condiviso, i controlli di integrità e i VIP. quindi installerai SAP NetWeaver. Dopo l'installazione di SAP NetWeaver, definisci infine le risorse del cluster per i componenti ASCS ed ERS.

Configurazione della recinzione

Puoi configurare la fencing definendo una risorsa cluster con l'agente fence_gce per ogni VM host.

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

Creare le risorse per i dispositivi di recinzione

Per ogni VM nel cluster, crea una risorsa cluster per il dispositivo di recinzione in modo che il cluster possa riavviare la VM. Il dispositivo di recinzione per una VM deve essere eseguito su una VM diversa, quindi devi configurare la località della risorsa cluster in modo che venga eseguita su qualsiasi VM tranne la VM che può essere riavviata.

  1. Nell'host principale come root, crea una risorsa cluster per un dispositivo di recinzione per la VM principale:

    # pcs stonith create FENCING_RESOURCE_PRIMARY_VM fence_gce \
        port="PRIMARY_VM_NAME" \
        zone="PRIMARY_ZONE" \
        project="CLUSTER_PROJECT_ID" \
        pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
        op monitor interval="300s" timeout="120s" \
        op start interval="0" timeout="60s"
  2. Configura la posizione del dispositivo di recinzione per la VM principale in modo che sia attiva solo sulla VM secondaria:

    # pcs constraint location FENCING_RESOURCE_PRIMARY_VM avoids PRIMARY_VM_NAME
  3. Nell'host principale come root, crea una risorsa cluster per un dispositivo di recinzione per la VM secondaria:

    # pcs stonith create FENCING_RESOURCE_SECONDARY_VM fence_gce \
        port="SECONDARY_VM_NAME" \
        zone="SECONDARY_ZONE" \
        project="CLUSTER_PROJECT_ID" \
        pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
        op monitor interval="300s" timeout="120s" \
        op start interval="0" timeout="60s"
  4. Configura la posizione del dispositivo di recinzione per la VM secondaria in modo che sia attiva solo sulla VM principale:

    # pcs constraint location FENCING_RESOURCE_SECONDARY_VM avoids SECONDARY_VM_NAME

Imposta un ritardo per il riavvio di Corosync

  1. Su entrambi gli host come root, crea un file drop-in systemd che ritarda l'avvio di Corosync per garantire la corretta sequenza di eventi dopo il riavvio di una VM protetta:

    systemctl edit corosync.service
  2. Aggiungi le seguenti righe al file:

    [Service]
    ExecStartPre=/bin/sleep 60
  3. Salva il file e esci dall'editor.

  4. Ricarica la configurazione di Systemd Manager.

    systemctl daemon-reload
  5. Verifica la creazione del file dell'accesso:

    service corosync status

    Dovresti visualizzare una riga per il file personale, come mostrato nell'esempio seguente:

    ● corosync.service - Corosync Cluster Engine
       Loaded: loaded (/usr/lib/systemd/system/corosync.service; disabled; vendor preset: disabled)
      Drop-In: /etc/systemd/system/corosync.service.d
               └─override.conf
       Active: active (running) since Tue 2021-07-20 23:45:52 UTC; 2 days ago

crea le risorse del file system

Definisci le risorse del cluster per le directory ASCS ed ERS nel file system condiviso.

  1. Configura una risorsa del file system per la directory ASCS.

    # pcs resource create ASCS_FILE_SYSTEM_RESOURCE Filesystem \
        device="NFS_PATH/usrsapSIDASCSASCS_INSTANCE_NUMBER" \
        directory="/usr/sap/SID/ASCSASCS_INSTANCE_NUMBER" \
        fstype=nfs force_unmount=safe \
        --group ASCS_RESOURCE_GROUP \
        op start interval=0 timeout=60 \
        op stop interval=0 timeout=120 \
        op monitor interval=200 timeout=40

    Sostituisci quanto segue:

    • ASCS_FILE_SYSTEM_RESOURCE: specifica un nome per la risorsa cluster per il file system ASCS.
    • NFS_PATH: specifica il percorso directory del file system NFS.
    • SID: specifica l'ID sistema (SID). Usa lettere maiuscole per tutte le lettere.
    • ASCS_INSTANCE_NUMBER: specifica il numero di istanza ASCS.
    • ASCS_RESOURCE_GROUP: specifica un nome di gruppo univoco per le risorse del cluster ASCS. Puoi garantire l'unicità utilizzando una convenzione come "SID_ASCSinstance_number_group". Ad esempio, nw8_ASCS00_group.

      Poiché un gruppo non esiste ancora, Pacemaker lo crea ora. Man mano che crei altre risorse ASCS, le aggiungi a questo gruppo.

  2. Configura una risorsa del file system per la directory ERS.

    # pcs resource create ERS_FILE_SYSTEM_RESOURCE Filesystem \
        device="NFS_PATH/usrsapSIDERSERS_INSTANCE_NUMBER" \
        directory="/usr/sap/SID/ERSERS_INSTANCE_NUMBER" \
        fstype=nfs force_unmount=safe \
        --group ERS_RESOURCE_GROUP \
        op start interval=0 timeout=60 \
        op stop interval=0 timeout=120 \
        op monitor interval=200 timeout=40

    Sostituisci quanto segue:

    • ERS_FILE_SYSTEM_RESOURCE: specifica un nome per la risorsa del file system.
    • NFS_PATH: specifica il percorso directory del file system NFS.
    • SID: specifica l'ID sistema (SID). Usa lettere maiuscole per tutte le lettere.
    • ERS_INSTANCE_NUMBER: specifica il numero di istanza ERS.
    • ERS_RESOURCE_GROUP: specifica un nome di gruppo univoco per le risorse del cluster ERS. Puoi garantire l'unicità utilizzando una convenzione come "SID_ERSinstance_number_group". Ad esempio, nw8_ERS10_group.

      Poiché un gruppo non esiste ancora, Pacemaker lo crea ora. Man mano che crei altre risorse ERS, le aggiungi a questo gruppo.

Crea una risorsa di indirizzo IP virtuale

Definisci le risorse del cluster per gli indirizzi VIP.

  1. Se hai bisogno di cercare l'indirizzo VIP, puoi utilizzare:

    • gcloud compute addresses describe ASCS_VIP_NAME
      --region=CLUSTER_REGION --format="value(address)"
    • gcloud compute addresses describe ERS_VIP_NAME
      --region=CLUSTER_REGION --format="value(address)"
  2. Creare le risorse del cluster per i VIP ASCS ed ERS.

    # pcs resource create ASCS_VIP_RESOURCE IPaddr2 \
        ip=ASCS_VIP_ADDRESS cidr_netmask=32 nic=eth0 \
        op monitor interval=3600 timeout=60 \
        --group ASCS_RESOURCE_GROUP
    # pcs resource create ERS_VIP_RESOURCE IPaddr2 \
        ip=ERS_VIP_ADDRESS cidr_netmask=32 nic=eth0 \
        op monitor interval=3600 timeout=60 \
        --group ERS_RESOURCE_GROUP

crea le risorse per il controllo di integrità

  1. Configura la risorsa cluster per il controllo di integrità ASCS:

    # pcs resource create _HEALTHCHECK_SCS service:haproxy@SIDascs \
       op monitor interval=10s timeout=20s \
       --group ASCS_RESOURCE_GROUP
  2. Configura la risorsa del cluster per il controllo di integrità ERS:

    # pcs resource create _HEALTHCHECK_ERS service:haproxy@SIDers \
       op monitor interval=10s timeout=20s \
       --group ERS_RESOURCE_GROUP

Configura valori predefiniti aggiuntivi per il cluster

  1. Imposta proprietà aggiuntive del cluster:

    # pcs resource defaults resource-stickiness=1
    # pcs resource defaults migration-threshold=3

Visualizza le risorse definite

Visualizza le risorse del cluster che hai definito finora per assicurarti che siano corrette.

  1. Visualizza lo stato del cluster:

    # pcs status

    Dovresti vedere un output simile al seguente esempio:

    Cluster name: nwha
    Cluster Summary:
      * Stack: corosync
      * Current DC: nw-ha-vm-1 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum
      * 2 nodes configured
      * 8 resource instances configured
    
    Node List:
      * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
    
    Full List of Resources:
      * fence-nw-ha-vm-2    (stonith:fence_gce):     Started nw-ha-vm-1
      * fence-nw-ha-vm-1    (stonith:fence_gce):     Started nw-ha-vm-2
      * Resource Group: nw8_ascs00_group:
        * nw8_vip_ascs00    (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-1
        * nw8_healthcheck_scs   (service:haproxy@nw8scs):    Started nw-ha-vm-1
        * nw8_fs_ascs00 (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
      * Resource Group: nw8_ers10_group:
        * nw8_vip_ers10 (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-2
        * nw8_healthcheck_ers   (service:haproxy@nw8ers):    Started nw-ha-vm-2
        * nw8_fs_ers10  (ocf::heartbeat:Filesystem):     Started nw-ha-vm-2
    
    Daemon Status:
      corosync: active/enabled
      pacemaker: active/enabled
      pcsd: active/enabled
    

Installare ASCS ed ERS

La seguente sezione illustra solo i requisiti e i suggerimenti specifici per l'installazione di SAP NetWeaver su Google Cloud.

Per istruzioni di installazione complete, consulta la documentazione di SAP NetWeaver.

Prepararsi all'installazione

Per garantire la coerenza in tutto il cluster e semplificare l'installazione, prima di installare i componenti SAP NetWeaver ASCS ed ERS, definisci gli utenti, i gruppi e le autorizzazioni e imposta il server secondario in modalità standby.

  1. Esci dalla modalità di manutenzione del cluster:

    # sudo pcs property set maintenance-mode="false"

  2. Su entrambi i server come root, inserisci i comandi seguenti, specificando gli ID utente e gruppo appropriati per il tuo ambiente:

    # groupadd -g GID_SAPINST sapinst
    # groupadd -g GID_SAPSYS sapsys
    # useradd -u UID_SIDADM SID_LCadm -g sapsys
    # usermod -a -G sapinst SID_LCadm
    # useradd -u UID_SAPADM sapadm -g sapinst
    
    # chown SID_LCadm:sapsys /usr/sap/SID/SYS
    # chown SID_LCadm:sapsys /sapmnt/SID -R
    # chown SID_LCadm:sapsys /usr/sap/trans -R
    # chown SID_LCadm:sapsys /usr/sap/SID/SYS -R
    # chown SID_LCadm:sapsys /usr/sap/SID -R

    Sostituisci quanto segue:

    • GID_SAPINST: specifica l'ID gruppo Linux per lo strumento di provisioning SAP.
    • GID_SAPSYS: specifica l'ID gruppo Linux per l'utente SAPSYS.
    • UID_SIDADM: specifica l'ID utente Linux per l'amministratore del sistema SAP (SID).
    • SID_LC: specifica l'ID sistema (SID). Utilizza minuscolo per tutte le lettere.
    • UID_SAPADM: specifica l'ID utente per l'agente host SAP.
    • SID: specifica l'ID sistema (SID). Usa lettere maiuscole per tutte le lettere.

    Ad esempio, quanto riportato di seguito mostra uno schema di numerazione GID e UID pratico:

    Group sapinst      1001
    Group sapsys       1002
    Group dbhshm       1003
    
    User  en2adm       2001
    User  sapadm       2002
    User  dbhadm       2003

Installa il componente ASCS

  1. Sul server secondario, inserisci il comando seguente per attivare la modalità standby del server secondario:

    # pcs node standby

    L'attivazione della modalità standby del server secondario consolida tutte le risorse del cluster sul server principale, semplificando l'installazione.

  2. Verifica che il server secondario sia in modalità standby:

    # pcs status

    Dovresti vedere un output simile al seguente esempio:

    Cluster name: nwha
       Cluster Summary:
         * Stack: corosync
         * Current DC: nw-ha-vm-1 (version 2.0.5-9.el8_4.3-ba59be7122) - partition with quorum
         * 2 nodes configured
         * 8 resource instances configured
    
       Node List:
         * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
    
       Full List of Resources:
         * fence-nw-ha-vm-2  (stonith:fence_gce):     Started nw-ha-vm-1
         * fence-nw-ha-vm-1  (stonith:fence_gce):     Stopped
         * Resource Group: nw8_ascs00_group:
           * nw8_vip_ascs00  (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-1
           * nw8_healthcheck_scs (service:haproxy@nw8scs):    Started nw-ha-vm-1
           * nw8_fs_ascs00   (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
         * Resource Group: nw8_ers10_group:
           * nw8_vip_ers10   (ocf::heartbeat:IPaddr2):    Started nw-ha-vm-1
           * nw8_healthcheck_ers (service:haproxy@nw8ers):    Started nw-ha-vm-1
           * nw8_fs_ers10    (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
    
       Daemon Status:
         corosync: active/enabled
    
  3. Sul server principale in qualità di utente root, imposta una directory di installazione temporanea, ad esempio /tmp, per installare l'istanza ASCS eseguendo SAP Software Provisioning Manager (SWPM).

    • Per accedere all'interfaccia web di SWPM, è necessaria la password dell'utente root. Se il criterio IT non consente all'amministratore SAP di accedere alla password root, puoi utilizzare SAPINST_REMOTE_ACCESS_USER.

    • Quando avvii SWPM, utilizza il parametro SAPINST_USE_HOSTNAME per specificare il nome dell'host virtuale definito per l'indirizzo VIP ASCS nel file /etc/hosts.

      Ad esempio:

      cd /tmp; /mnt/nfs/install/SWPM/sapinst SAPINST_USE_HOSTNAME=vh-aha-scs
    • Nella pagina finale di conferma di SWPM, assicurati che il nome host virtuale sia corretto.

  4. Al termine della configurazione, disattiva la modalità standby della VM secondaria:

    # pcs node unstandby

Installare il componente ERS

  1. Sul server principale come root o SID_LCadm, interrompi il servizio ASCS.

    # su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function Stop"
    # su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function StopService"
  2. Sul server principale, inserisci questo comando per attivare la modalità standby del server principale:

    # pcs node standby

    L'attivazione della modalità standby del server principale consolida tutte le risorse del cluster sul server secondario, semplificando l'installazione.

  3. Verifica che il server principale sia in modalità standby:

    # pcs status

  4. Sul server secondario in qualità di utente root, modifica la directory in una directory di installazione temporanea, ad esempio /tmp, per installare l'istanza ERS eseguendo il SAP Software Provisioning Manager (SWPM).

    • Utilizza lo stesso utente e la stessa password per accedere a SWPM che hai utilizzato quando hai installato il componente ASCS.

    • Quando avvii SWPM, utilizza il parametro SAPINST_USE_HOSTNAME per specificare il nome host virtuale definito per l'indirizzo VIP ERS nel file /etc/hosts.

      Ad esempio:

      cd /tmp; /mnt/nfs/install/SWPM/sapinst SAPINST_USE_HOSTNAME=vh-aha-ers
    • Nella pagina finale di conferma di SWPM, assicurati che il nome host virtuale sia corretto.

  5. Disattiva la VM principale dalla modalità standby per attivarle entrambe:

    # pcs node unstandby

Configurare i servizi SAP

Devi confermare che i servizi sono configurati correttamente, controllare le impostazioni nei profili ASCS ed ERS e aggiungere l'utente SID_LCadm al gruppo di utenti haclient.

Conferma le voci del servizio SAP

  1. Su entrambi i server, verifica che il file /usr/sap/sapservices contenga voci per i servizi ASCS e ERS. A questo scopo, puoi utilizzare l'integrazione systemV o systemd.

    Puoi aggiungere le voci mancanti utilizzando il comando sapstartsrv con le opzioni pf=PROFILE_OF_THE_SAP_INSTANCE e -reg.

    Per ulteriori informazioni su queste integrazioni, consulta le seguenti note SAP:

    systemV

    Di seguito è riportato un esempio delle voci per i servizi ASCS ed ERS nel file /usr/sap/sapservices quando utilizzi l'integrazione systemV:

    # LD_LIBRARY_PATH=/usr/sap/hostctrl/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH
    /usr/sap/hostctrl/exe/sapstartsrv \
    pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
    -D -u SID_LCadm
    /usr/sap/hostctrl/exe/sapstartsrv \
    pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
    -D -u SID_LCadm

    systemd

    1. Verifica che il file /usr/sap/sapservices contenga le voci per i servizi ASCS e ERS. Di seguito è riportato un esempio di come queste voci vengono visualizzate nel file /usr/sap/sapservices quando utilizzi l'integrazione systemd:

      systemctl --no-ask-password start SAPSID_ASCS_INSTANCE_NUMBER # sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_SID_LCascs
      systemctl --no-ask-password start SAPSID_ERS_INSTANCE_NUMBER # sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_SID_LCers
    2. Disabilita l'integrazione di systemd sulle istanze ASCS e ERS:

      # systemctl disable SAPSID_ASCS_INSTANCE_NUMBER.service
      # systemctl stop SAPSID_ASCS_INSTANCE_NUMBER.service
      # systemctl disable SAPSID_ERS_INSTANCE_NUMBER.service
      # systemctl stop SAPSID_ERS_INSTANCE_NUMBER.service
      
    3. Verifica che l'integrazione di systemd sia disabilitata:

      # systemctl list-unit-files | grep sap

      Un output simile all'esempio seguente indica che l'integrazione systemd è disabilitata. Tieni presente che alcuni servizi, come saphostagent e saptune, sono abilitati, mentre altri sono disabilitati.

      SAPSID_ASCS_INSTANCE_NUMBER.service disabled
      SAPSID_ERS_INSTANCE_NUMBER.service disabled
      saphostagent.service enabled
      sapinit.service generated
      saprouter.service disabled
      saptune.service enabled

Arresta i servizi SAP

  1. Sul server secondario, interrompi il servizio ERS:

    # su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function Stop"
    # su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function StopService"
  2. Verifica che tutti i servizi siano arrestati su ogni server:

    # su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function GetSystemInstanceList"
    # su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function GetSystemInstanceList"

    Dovresti vedere un output simile al seguente esempio:

    GetSystemInstanceList
    FAIL: NIECONN_REFUSED (Connection refused), NiRawConnect failed in plugin_fopen()

Disabilita il riavvio automatico del servizio in SAP

Poiché il software del cluster gestisce il riavvio dei servizi SAP durante un failover, per evitare conflitti, disabilita la capacità del software SAP di riavviare automaticamente i servizi.

  1. Su entrambi i nodi, modifica il file /usr/sap/sapservices per disabilitare il riavvio automatico nel software SAP aggiungendo un carattere di commento, # all'inizio del comando sapstartsrv per i componenti ASCS e ERS.

    Ad esempio:

    #!/bin/sh
    
     #LD_LIBRARY_PATH=/usr/sap/SID/ASCSASCS_INSTANCE_NUMBER/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/SID/ASCSASCS_INSTANCE_NUMBER/exe/sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME -D -u SID_LCadm
     #LD_LIBRARY_PATH=/usr/sap/SID/ERSERS_INSTANCE_NUMBER/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/SID/ERSERS_INSTANCE_NUMBER/exe/sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME -D -u SID_LCadm
     

Modifica i profili ASCS ed ERS

  1. In entrambi i server, passa alla directory del profilo utilizzando uno dei seguenti comandi:

    # cd /usr/sap/SID/SYS/profile
    # cd /sapmnt/SID/profile
  2. Se necessario, puoi trovare i nomi dei file dei tuoi profili ASCS ed ERS elencando i file nella directory del profilo o utilizzando i seguenti formati:

    SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME
    SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME
  3. Se utilizzi ENSA1, abilita la funzione keepalive impostando quanto segue nel profilo ASCS:

    enque/encni/set_so_keepalive = true

    Per ulteriori informazioni, consulta la nota SAP 1410736 - TCP/IP: impostazione dell'intervallo keepalive.

  4. Se necessario, modifica i profili ASCS ed ERS per cambiare il comportamento di avvio del server di enqueue e del server di replica di enqueue.

    ENSA1

    Nella sezione "Avvia server di accoda SAP" del profilo ASCS, se vedi Restart_Program_NN, cambia "Restart" in "Start", come mostrato nell'esempio che segue.

    Start_Program_01 = local $(_EN) pf=$(_PF)

    Nella sezione "Avvia server di replica accodato" del profilo ERS, se vedi Restart_Program_NN, modifica "Restart" in "Start", come mostrato nell'esempio che segue.

    Start_Program_00 = local $(_ER) pf=$(_PFL) NR=$(SCSID)

    ENSA2

    Nella sezione "Avvia server di accoda SAP" del profilo ASCS, se vedi Restart_Program_NN, cambia "Restart" in "Start", come mostrato nell'esempio che segue.

    Start_Program_01 = local $(_ENQ) pf=$(_PF)

    Nella sezione "Start enqueue replicator" (Avvia replicatore in coda) del profilo ERS, se vedi Restart_Program_NN, modifica "Restart" in "Start", come mostrato nell'esempio che segue.

    Start_Program_00 = local $(_ENQR) pf=$(_PF) ...

Configura le risorse del cluster per ASCS ed ERS

  1. Come root di entrambi i server, imposta il cluster in modalità di manutenzione:

    # pcs property set maintenance-mode="true"
  2. Verifica che il custer sia in modalità di manutenzione:

    # pcs status
  3. Crea le risorse del cluster per i servizi ASCS ed ERS:

    ENSA1

    • Crea la risorsa cluster per l'istanza ASCS. Il valore di InstanceName è il nome del profilo di istanza generato da SWPM quando hai installato ASCS.

      # pcs resource create ASCS_INSTANCE_RESOURCE SAPInstance \
          InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
          START_PROFILE=/sapmnt/SID/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
          AUTOMATIC_RECOVER=false meta resource-stickiness=5000 migration-threshold=1 \
          failure-timeout=60  --group ASCS_RESOURCE_GROUP \
          op monitor interval=20 on-fail=restart timeout=60 \
          op start interval=0 timeout=600 \
          op stop interval=0 timeout=600
      
      # pcs resource meta ASCS_RESOURCE_GROUP resource-stickiness=3000
      
    • Creare la risorsa cluster per l'istanza ERS. Il valore di InstanceName è il nome del profilo di istanza generato da SWPM quando hai installato ERS. Il parametro IS_ERS=true indica a Pacemaker di impostare il flag runsersSID su 1 sul nodo in cui l'ERS è attiva.

      # pcs resource create ERS_INSTANCE_RESOURCE SAPInstance \
          InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
          START_PROFILE=/sapmnt/SID/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
          AUTOMATIC_RECOVER=false IS_ERS=true --group ERS_RESOURCE_GROUP \
          op monitor interval=20 on-fail=restart timeout=60 \
          op start interval=0 timeout=600 \
          op stop interval=0 timeout=600
      

    ENSA2

    • Crea la risorsa cluster per l'istanza ASCS. Il valore di InstanceName è il nome del profilo di istanza generato da SWPM quando hai installato ASCS.

      # pcs resource create ASCS_INSTANCE_RESOURCE SAPInstance \
          InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
          START_PROFILE=/sapmnt/SID/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
          AUTOMATIC_RECOVER=false meta resource-stickiness=5000 \
          --group ASCS_RESOURCE_GROUP \
          op monitor interval=20 on-fail=restart timeout=60 \
          op start interval=0 timeout=600 \
          op stop interval=0 timeout=600
      
      # pcs resource meta ASCS_RESOURCE_GROUP resource-stickiness=3000
      
    • Creare la risorsa cluster per l'istanza ERS. Il valore di InstanceName è il nome del profilo di istanza generato da SWPM quando hai installato ERS.

      # pcs resource create ERS_INSTANCE_RESOURCE SAPInstance \
          InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
          START_PROFILE=/sapmnt/SID/profile/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
          AUTOMATIC_RECOVER=false IS_ERS=true --group ERS_RESOURCE_GROUP \
          op monitor interval=20 on-fail=restart timeout=60 \
          op start interval=0 timeout=600 \
          op stop interval=0 timeout=600
      

Configurare i vincoli di località e ordinamento

Puoi creare vincoli per definire quali servizi devono essere avviati per primi e quali devono essere eseguiti insieme sullo stesso host. Ad esempio, l'indirizzo IP deve trovarsi sullo stesso host dell'istanza principale di SAP Central Services.

  1. Definisci il vincolo dell'ordine di inizio:

ENSA1

  1. Crea un vincolo di colocation che impedisca l'esecuzione delle risorse ASCS sullo stesso server delle risorse ERS:

    # pcs constraint colocation add ERS_RESOURCE_GROUP with \
        ASCS_RESOURCE_GROUP -5000
    
  2. Configura l'ASCS per il failover al server su cui è in esecuzione l'ERS, in base al flag runsersSID uguale a 1:

    # pcs constraint location ASCS_INSTANCE \
        rule score=2000 runs_ers_SID eq 1
  3. Configura ASCS in modo che inizi prima che ERS passi all'altro server dopo un failover:

    # pcs constraint order start ASCS_RESOURCE_GROUP then \
        stop ERS_RESOURCE_GROUP symmetrical=false kind=Optional
    

ENSA2

  1. Crea un vincolo di colocation che impedisca l'esecuzione delle risorse ASCS sullo stesso server delle risorse ERS:

    # pcs constraint colocation add ERS_RESOURCE_GROUP  with \
        ASCS_RESOURCE_GROUP -5000
    
  2. Configura ASCS in modo che inizi prima che ERS passi all'altro server dopo un failover:

    # pcs constraint order start ASCS_RESOURCE_GROUP then \
        stop ERS_RESOURCE_GROUP symmetrical=false kind=Optional
    
  1. Controlla i vincoli:

    # pcs constraint

    Dovresti vedere un output simile al seguente:

    Location Constraints:
      Resource: ascs-aha-instance
        Constraint: location-ascs-instance
          Rule: score=2000
            Expression: runs_ers_HKN eq 1
      Resource: fence-nw-ha-vm-1
        Disabled on: nw-ha-vm-1 (score:-INFINITY)
      Resource: fence-nw-ha-vm-2
        Disabled on: nw-ha-vm-2 (score:-INFINITY)
    Ordering Constraints:
      start ascs-group then stop ers-group (kind:Optional) (non-symmetrical)
    Colocation Constraints:
      ascs-group with ers-group (score:-5000)
    Ticket Constraints:
  2. Come root da uno dei server, disabilita la modalità di manutenzione del cluster:

    # pcs property set maintenance-mode="false"

Configura il connettore del cluster Red Hat per SAP

Su ogni host del cluster, configura SAP Start Service sapstartsrv in modo che comunichi con il software del cluster pacemaker tramite l'interfaccia ad alta disponibilità.

  1. Aggiungi l'utente amministrativo SAP al gruppo haclient:

    usermod -a -G haclient SID_LCadm
  2. Modifica i profili dell'istanza SAP aggiungendo le seguenti righe alla fine di ogni profilo. I profili sono disponibili nella directory /sapmnt/SID/profiles.

    service/halib = $(DIR_CT_RUN)/saphascriptco.so
    service/halib_cluster_connector = /usr/bin/sap_cluster_connector
  3. Se le risorse dell'istanza ASCS ed ERS sono attualmente in esecuzione nel cluster, disabilitale:

    pcs resource disable ERS_INSTANCE_RESOURCE
    pcs resource disable ASCS_INSTANCE_RESOURCE
  4. Arresta i servizi sull'host ASCS:

    sapcontrol -nr ASCS_INSTANCE_NUMBER -function StopService
  5. Interrompi i servizi sull'host ERS:

    sapcontrol -nr ERS_INSTANCE_NUMBER -function StopService
  6. Abilita le risorse:

    pcs resource enable ERS_INSTANCE_RESOURCE
    pcs resource enable ASCS_INSTANCE_RESOURCE
  7. Ripeti i passaggi precedenti su ciascun host nel cluster.

Per maggiori informazioni da Red Hat, consulta Come configurare SAP halib per SAPInstance risorse su RHEL 7 e 8.

Installa database e server delle applicazioni su host esterni al cluster

Nella configurazione ad alta disponibilità, consigliamo di installare i server del database e delle applicazioni su host diversi rispetto agli host ASCS e ERS nel cluster.

Utilizzando host separati per ogni server, riduci la complessità, riduci il rischio che un errore interessi più server e puoi personalizzare le dimensioni di ogni Compute Engine in base al tipo di server.

Questo consente di scegliere le dimensioni della macchina certificate più appropriate, evitare errori e ridurre la complessità.

L'installazione del database e dei server delle applicazioni non è trattata in questa guida.

Per informazioni sull'installazione dei server di database, vedi:

Convalida e testa il cluster

Questa sezione mostra come eseguire i seguenti test:

  • Verifica la presenza di errori di configurazione
  • Conferma che le risorse ASCS ed ERS passino correttamente ai server durante i failover
  • Conferma che le serrature vengono conservate
  • Simula un evento di manutenzione di Compute Engine per assicurarti che la migrazione live non attivi un failover

Controlla la configurazione del cluster

  1. Come root su entrambi i server, controlla su quali nodi sono in esecuzione le tue risorse:

    # pcs status

    Nell'esempio seguente, le risorse ASCS sono in esecuzione sul server nw-ha-vm-2 e le risorse ERS sono in esecuzione sul server nw-ha-vm-1.

    Stack: corosync
      Current DC: nw-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
      Last updated: Wed Apr 13 05:21:21 2022
      Last change: Wed Apr 13 05:21:18 2022 by hacluster via crmd on nw-ha-vm-2
    
      2 nodes configured
      10 resource instances configured
    
      Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
    
      Full list of resources:
    
      fence-nw-ha-vm-1     (stonith:fence_gce):    Started nw-ha-vm-2
      fence-nw-ha-vm-2     (stonith:fence_gce):    Started nw-ha-vm-1
       Resource Group: ascs-group
           ascs-file-system   (ocf::heartbeat:Filesystem):    Started nw-ha-vm-2
           ascs-vip   (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-2
           ascs-healthcheck   (service:haproxy@AHAascs):      Started nw-ha-vm-2
           ascs-aha-instance      (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-2
       Resource Group: ers-group
           ers-file-system    (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
           ers-vip    (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
           ers-healthcheck    (service:haproxy@AHAers):       Started nw-ha-vm-1
           ers-aha-instance       (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-1
    
      Migration Summary:
      * Node nw-ha-vm-1:
      * Node nw-ha-vm-2:
  2. Passa all'utente SID_LCadm:

    # su - SID_LCadm
  3. Controlla la configurazione del cluster. Per INSTANCE_NUMBER, specifica il numero di istanza dell'istanza ASCS o ERS attiva sul server in cui inserisci il comando:

    > sapcontrol -nr INSTANCE_NUMBER -function HAGetFailoverConfig

    HAActive deve essere TRUE, come mostrato nell'esempio seguente:

    HAGetFailoverConfig
    
    14.04.2022 17:25:45
    HAGetFailoverConfig
    OK
    HAActive: TRUE
    HAProductVersion: Pacemaker
    HASAPInterfaceVersion: sap_cluster_connector
    HADocumentation: https://github.com/ClusterLabs/sap_cluster_connector
    HAActiveNode:
    HANodes:

  4. In qualità di SID_LCadm, verifica la presenza di errori nella configurazione:

    > sapcontrol -nr INSTANCE_NUMBER -function HACheckConfig

    Dovresti vedere un output simile al seguente esempio:

    14.04.2022 21:43:39
    HACheckConfig
    OK
    state, category, description, comment
    SUCCESS, SAP CONFIGURATION, Redundant ABAP instance configuration, 0 ABAP instances detected
    SUCCESS, SAP CONFIGURATION, Enqueue separation, All Enqueue server separated from application server
    SUCCESS, SAP CONFIGURATION, MessageServer separation, All MessageServer separated from application server
    SUCCESS, SAP STATE, SCS instance running, SCS instance status ok
    SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version (vip-ascs_NWT_00), SAPInstance includes is-ers patch
    SUCCESS, SAP CONFIGURATION, Enqueue replication (vip-ascs_NWT_00), Enqueue replication enabled
    SUCCESS, SAP STATE, Enqueue replication state (vip-ascs_NWT_00), Enqueue replication active
    SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version (vip-ers_NWT_10), SAPInstance includes is-ers patch

  5. Sul server in cui è attivo l'ASCS, ad esempio SID_LCadm, simula un failover:

    > sapcontrol -nr ASCS_INSTANCE_NUMBER -function HAFailoverToNode ""
  6. Come root, se segui il failover utilizzando crm_mon, dovresti vedere che l'ASCS viene spostato sull'altro server, l'ERS si arresta sul server in questione, quindi l'ERS passa al server su cui era in esecuzione l'ASCS.

Simulare un failover

Testa il cluster simulando un errore sull'host principale. Utilizza un sistema di test o esegui il test sul tuo sistema di produzione prima di rilasciare il sistema per l'uso.

Puoi simulare un errore in diversi modi, tra cui:

  • shutdown -r (sul nodo attivo)
  • ip link set eth0 down
  • echo c > /proc/sysrq-trigger

Queste istruzioni utilizzano ip link set eth0 down per mettere offline l'interfaccia di rete, perché convalida sia il failover sia la recinzione.

  1. Esegui il backup del sistema.

  2. Come root sull'host con l'istanza SCS attiva, porta l'interfaccia di rete offline:

    $ ip link set eth0 down
  3. Riconnettiti a uno degli host tramite SSH e passa all'utente root.

  4. Inserisci pcs status per confermare che l'host principale sia ora attivo sulla VM che conteneva l'host secondario. Il riavvio automatico è abilitato nel cluster, pertanto l'host interrotto verrà riavviato e assumerà il ruolo di host secondario, come mostrato nell'esempio seguente.

     Stack: corosync
      Current DC: nw-ha-vm-1 (version 1.1.23-1.el7_9.1-9acf116022) - partition with quorum
      Last updated: Wed Apr 13 05:21:21 2022
      Last change: Wed Apr 13 05:21:18 2022 by hacluster via crmd on nw-ha-vm-2
    
      2 nodes configured
      10 resource instances configured
    
      Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
    
      Full list of resources:
    
      fence-nw-ha-vm-1     (stonith:fence_gce):    Started nw-ha-vm-2
      fence-nw-ha-vm-2     (stonith:fence_gce):    Started nw-ha-vm-1
       Resource Group: ascs-group
           ascs-file-system   (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
           ascs-vip   (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
           ascs-healthcheck   (service:haproxy@AHAascs):      Started nw-ha-vm-1
           ascs-aha-instance      (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-1
       Resource Group: ers-group
           ers-file-system    (ocf::heartbeat:Filesystem):    Started nw-ha-vm-2
           ers-vip    (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-2
           ers-healthcheck    (service:haproxy@AHAers):       Started nw-ha-vm-2
           ers-aha-instance       (ocf::heartbeat:SAPInstance):   Started nw-ha-vm-2
    
      Migration Summary:
      * Node nw-ha-vm-1:
      * Node nw-ha-vm-2:

Conferma che le voci di blocco vengono conservate

Per confermare che le voci di blocco vengano mantenute durante un failover, seleziona innanzitutto la scheda della tua versione del server di enqueue e segui la procedura per generare voci di blocco, simulare un failover e confermare che le voci di blocco vengano conservate dopo la nuova attivazione di ASCS.

ENSA1

  1. Come SID_LCadm, sul server in cui ERS è attiva, genera voci di blocco utilizzando il programma enqt:

    > enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 11 NUMBER_OF_LOCKS
  2. In qualità di SID_LCadm, sul server in cui ASCS è attivo, verifica che siano registrate le voci di blocco:

    > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

    Se hai creato 10 blocchi, dovresti vedere un output simile al seguente esempio:

    locks_now: 10
  3. Come SID_LCadm, sul server in cui ERS è attiva, avvia la funzione di monitoraggio OpCode=20 del programma enqt:

    > enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 20 1 1 9999

    Ad esempio:

    > enqt pf=/sapmnt/AHA/profile/AHA_ERS10_vh-ers-aha 20 1 1 9999
  4. Se ASCS è attivo, riavvia il server.

    Sul server di monitoraggio, quando Pacemaker interrompe l'ERS per spostarlo sull'altro server, dovresti vedere un output simile al seguente.

    Number of selected entries: 10
    Number of selected entries: 10
    Number of selected entries: 10
    Number of selected entries: 10
    Number of selected entries: 10
  5. Quando il monitor enqt si arresta, esci dal monitor inserendo Ctrl + c.

  6. Facoltativamente, come root su entrambi i server, monitora il failover del cluster:

    # crm_mon
  7. Come SID_LCadm, dopo aver confermato che le serrature sono state conservate, rilasciale:

    > enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 12 NUMBER_OF_LOCKS
  8. In qualità di SID_LCadm, sul server in cui ASCS è attivo, verifica che le voci di blocco vengano rimosse:

    > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

ENSA2

  1. Come SID_LCadm, sul server in cui ASCS è attivo, genera voci di blocco utilizzando il programma enq_adm:

    > enq_admin --set_locks=NUMBER_OF_LOCKS:X:DIAG::TAB:%u pf=/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME
  2. In qualità di SID_LCadm, sul server in cui ASCS è attivo, verifica che siano registrate le voci di blocco:

    > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

    Se hai creato 10 blocchi, dovresti vedere un output simile al seguente esempio:

    locks_now: 10
  3. Se la ERS è attiva, verifica che le voci di blocco siano state replicate:

    > sapcontrol -nr ERS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

    Il numero di blocchi restituiti deve essere uguale a quello dell'istanza ASCS.

  4. Se ASCS è attivo, riavvia il server.

  5. Facoltativamente, come root su entrambi i server, monitora il failover del cluster:

    # crm_mon
  6. Come SID_LCadm, sul server in cui è stato riavviato ASCS, verifica che le voci di blocco siano state conservate:

    > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now
  7. Come SID_LCadm, sul server su cui ERS è attiva, dopo aver confermato che i blocchi sono stati conservati, rilasciali:

    > enq_admin --release_locks=NUMBER_OF_LOCKS:X:DIAG::TAB:%u pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME
  8. In qualità di SID_LCadm, sul server in cui ASCS è attivo, verifica che le voci di blocco vengano rimosse:

    > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

    Dovresti vedere un output simile al seguente esempio:

    locks_now: 0

Simula un evento di manutenzione di Compute Engine

Simula un evento di manutenzione di Compute Engine per assicurarti che la migrazione live non attivi un failover.

I valori di timeout e intervallo utilizzati in queste istruzioni tengono conto della durata delle migrazioni live. Se utilizzi valori più brevi nella configurazione del cluster, il rischio che la migrazione live possa attivare un failover è maggiore.

Per testare la tolleranza del tuo cluster per la migrazione live:

  1. Sul nodo primario, attiva un evento di manutenzione simulato utilizzando il seguente comando gcloud CLI:

    $ gcloud compute instances simulate-maintenance-event PRIMARY_VM_NAME
  2. Conferma che il nodo primario non cambi:

    $ pcs status

Valutazione del carico di lavoro SAP NetWeaver

Per automatizzare i controlli di convalida continua dei carichi di lavoro ad alta disponibilità SAP NetWeaver in esecuzione su Google Cloud, puoi utilizzare Workload Manager.

Workload Manager consente di analizzare e valutare automaticamente i carichi di lavoro ad alta disponibilità di SAP NetWeaver in base alle best practice dei fornitori di SAP, Google Cloud e di sistemi operativi. Ciò consente di migliorare qualità, prestazioni e affidabilità dei carichi di lavoro.

Per informazioni sulle best practice supportate da Workload Manager per la valutazione dei carichi di lavoro ad alta disponibilità di SAP NetWeaver in esecuzione su Google Cloud, consulta Best practice di Workload Manager per SAP. Per informazioni sulla creazione e sull'esecuzione di una valutazione utilizzando Gestore carichi di lavoro, consulta Creare ed eseguire una valutazione.

Risoluzione dei problemi

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

Raccogli informazioni diagnostiche per i cluster ad alta disponibilità SAP NetWeaver

Se hai bisogno di aiuto per risolvere un problema con i cluster ad alta disponibilità per SAP NetWeaver, raccogli le informazioni di diagnostica richieste e contatta l'assistenza clienti Google Cloud.

Per raccogliere informazioni diagnostiche, vedi Cluster ad alta disponibilità su informazioni diagnostiche RHEL.

Assistenza

In caso di problemi con l'infrastruttura o i servizi Google Cloud, contatta l'assistenza clienti. Puoi trovare le informazioni di contatto nella pagina Panoramica dell'assistenza nella console Google Cloud. Se l'assistenza clienti stabilisce che un problema risiede nei tuoi sistemi SAP, ti indirizzerà all'assistenza SAP.

Per problemi relativi ai prodotti SAP, registra la tua richiesta di assistenza con l'assistenza SAP. SAP valuta il ticket di assistenza e, se sembra trattarsi di un problema dell'infrastruttura di Google Cloud, lo trasferisce al componente Google Cloud BC-OP-LNX-GOOGLE o BC-OP-NT-GOOGLE.

Requisiti per l'assistenza

Prima di poter ricevere assistenza per i sistemi SAP, nonché per l'infrastruttura e i servizi Google Cloud che utilizzano, devi soddisfare i requisiti minimi del piano di assistenza.

Per ulteriori informazioni sui requisiti minimi di assistenza per SAP su Google Cloud, consulta:

Esecuzione di attività post-deployment

Prima di utilizzare il sistema SAP NetWeaver, ti consigliamo di eseguire il backup del nuovo sistema SAP NetWeaver ad alta disponibilità.

Per ulteriori informazioni, consulta la guida alle operazioni di SAP NetWeaver.

Passaggi successivi

Per ulteriori informazioni sull'alta disponibilità, su SAP NetWeaver e Google Cloud, consulta le seguenti risorse: