Guida alla configurazione del cluster ad alta disponibilità per SAP NetWeaver su SLES

Questa guida illustra come eseguire il deployment e configurare un cluster ad alta disponibilità (SLES) Linux ad alte prestazioni SUSE Linux Enterprise Server per sistema SAP NetWeaver.

Ad eccezione delle procedure specifiche dell'ENSA2 (ENSA2) Server autonomo 2, disponibile solo in ABAP, questa guida si applica agli stack ABAP e Java SAP NetWeaver.

A meno che non sia indicato un'eccezione nella guida, gli esempi che utilizzano "ASCS" sono validi sia per ABAP SAP Central Services (ASCS) sia per Java SAP Central Services (SCS).

Se utilizzi uno stack Java, prima di utilizzare i comandi o gli esempi riportati in questa guida, sostituisci le istanze "&CS" con "SCS".

Questa guida illustra i passaggi per:

• Configurazione del bilanciamento del carico TCP/UDP interno per reindirizzare il traffico in caso di errore.
• Configurazione di un cluster PaceMaker su SLES per gestire i sistemi SAP e altre risorse durante un failover

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

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

Per configurare un cluster ad alta disponibilità per SAP HANA su Red Hat Enterprise Linux (RHEL), consulta la guida alla configurazione del cluster ad alta disponibilità per SAP NetWeaver su RHEL.

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

Il sistema di cui viene eseguito il deployment di questa guida

Seguendo questa guida, eseguirai il deployment di due istanze SAP NetWeaver e configurerai un cluster ad alta disponibilità su SLES. Esegui il deployment di ogni istanza SAP NetWeaver su una VM di Compute Engine in una zona diversa all'interno della stessa area geografica. Questa guida non tratta di un'installazione ad alta disponibilità.

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 della replica ENSA2 ENSA2 o del server di replica ENSA1 ENSA1. Le istanze ENSA2 ed ENSA1 sono indicate come ERS.
• Il gestore di risorse cluster ad alta disponibilità Pacemaker.
• Meccanismo di recinzione STONITH.
• Riavvio automatico dell'istanza non riuscita come nuova istanza secondaria.

In questa guida vengono utilizzati i modelli di Cloud Deployment Manager forniti da Google Cloud per eseguire il deployment delle macchine virtuali (VM) di Compute Engine, che garantiscono che le VM soddisfino i requisiti di supporto per SAP e siano conformi alle best practice attuali.

Prerequisiti

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

• Tu o la tua organizzazione avete un account Google Cloud e avete creato un progetto per il deployment SAP NetWeaver. Per informazioni sulla creazione di account e progetti Google Cloud, consulta la sezione relativa alla creazione di un progetto nella guida all'implementazione di SAP NetWeaver per Linux.

• Se utilizzi il DNS interno VPC, il valore della variabile VmDnsSetting nei metadati del progetto deve essere GlobalOnly o ZonalPreferred per consentire la risoluzione dei nomi dei nodi nelle zone. L'impostazione predefinita di VmDnsSetting è ZonalOnly. Per ulteriori informazioni, consulta:

  • Configurazione dei nomi DNS per il tuo progetto o le tue istanze
  • Esecuzione di query sui metadati personalizzati
  • Impostare i metadati personalizzati a livello di progetto

• Hai configurato una condivisione file utilizzando una soluzione di archiviazione file condivisa NFS, come Filestore Enterprise.

• Se OS Login è abilitato nei metadati del progetto, devi disabilitare temporaneamente l'accesso al sistema operativo fino al completamento del deployment. Ai fini del deployment, questa procedura configura le chiavi SSH nei metadati dell'istanza. Se l'accesso al sistema operativo è abilitato, le configurazioni delle chiavi SSH basate su metadati vengono disabilitate e il deployment non riesce. Al termine del deployment, potrai riabilitare OS Login.

  Per ulteriori informazioni, vedi:

  • Attivazione o disattivazione di OS Login
  • Aggiungere chiavi SSH alle VM che utilizzano chiavi SSH basate su metadati

Per evitare di esporre involontariamente la tua istanza VM a Internet, segui questi suggerimenti:

• Utilizza un gateway NAT.
• Crea regole firewall che blocchino tutti gli accessi esterni di cui non hai bisogno.
• Quando crei le tue VM:
  • Specifica un tag di rete per ogni VM da utilizzare nelle regole di routing e firewall. Se utilizzi i modelli Deployment Manager forniti da Google Cloud, specifica un tag con networkTag: [TAG].
  • Crea le VM senza un IP esterno. Se utilizzi i modelli di Deployment Manager forniti da Google Cloud, specifica publicIP: No.

Informazioni correlate di SUSE

Ad eccezione di dove è richiesto per l'ambiente Google Cloud, le informazioni in questa guida sono coerenti con le seguenti guide correlate di SUSE:

• Replica di coda SAP WeWever Enqueue 1 - Cluster ad alta disponibilità - Guida alla configurazione per SAP NetWeaver 7.40 e 7.50 | SUSE Linux Enterprise Server per SAP Applications 12
• Replica di coda SAP WeWeNet Enqueue 1 - Cluster ad alta disponibilità - Guida alla configurazione per SAP NetWeaver 7.40 e 7.50 | SUSE Linux Enterprise Server per SAP Applications 15
• SAP S/4 HANA - Enqueue Replication 2 High Cluster - Guida alla configurazione | SUSE Linux Enterprise Server per SAP Applications 12
• SAP S/4 HANA - Enqueue Replication 2 High Cluster - Guida alla configurazione | SUSE Linux Enterprise Server per applicazioni SAP 15

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 tuo 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 che crei in modo esplicito.

Durante il deployment, le istanze VM in genere richiedono l'accesso a Internet per scaricare l'agente di monitoraggio di Google. Se utilizzi una delle immagini Linux con certificazione SAP disponibili da Google Cloud, l'istanza VM richiede anche l'accesso a Internet per registrare la licenza e accedere ai repository dei fornitori di sistema operativo. 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 la rete:

console

1. Nella console, vai alla pagina Reti VPC.

   Vai alle 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. Per Area geografica, seleziona l'area geografica di Compute Engine in cui vuoi creare la subnet.
   3. Per 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 della subnet. Se prevedi di aggiungere più di una subnet, assegna gli 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 area geografica.

   4. Fai clic su Fine.
6. Per aggiungere altre subnet, fai clic su Aggiungi subnet e ripeti i passaggi precedenti. Puoi aggiungere altre subnet alla rete dopo averla creata.
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 il comando seguente:

   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 area geografica di Compute Engine. Per ulteriori informazioni, consulta la sezione Modalità di creazione delle subnet.

3. Crea una subnet e specifica l'area geografica 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: l'area geografica in cui vuoi che 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 area geografica.

4. Facoltativamente, ripeti il passaggio precedente e aggiungi ulteriori subnet.

Configurazione di un gateway NAT

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

Punto chiave: quando configuri Cloud NAT, specifica almeno 160 come numero minimo di porte per VM. Alcuni aggiornamenti del sistema operativo eseguono processi simultanei che potrebbero superare l'impostazione predefinita di Cloud NAT per il numero di porte, il che può causare errori di attivazione o download.

Quando crei un'istanza Cloud NAT, specifica il numero di porte nel campo Numero minimo di porte per VM nella sezione Configurazioni avanzate della pagina Crea un gateway NAT nella console.

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

Dopo aver configurato Cloud NAT per il tuo progetto, le istanze VM possono accedere in modo sicuro a Internet senza indirizzi IP pubblici.

Aggiunta di regole firewall

Per impostazione predefinita, le connessioni in entrata dall'esterno della rete Google Cloud sono bloccate. Per consentire le connessioni in entrata, configura una regola firewall per la VM. Le regole firewall regolano solo le nuove connessioni in entrata a una VM. Una volta stabilita 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 le VM nella stessa subnet.

Creare 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 dall'ambiente di rete aziendale all'istanza VM di Compute Engine. Se non sai con certezza quale indirizzo utilizzare, rivolgiti all'amministratore di rete della tua azienda.
• Comunicazione tra VM in configurazione a tre livelli, scale out o ad alta disponibilità. Ad esempio, se stai eseguendo il deployment di un sistema a tre livelli, avrai almeno 2 VM nella subnet: la VM per SAP NetWeaver e un'altra VM per il server del database. Per abilitare la comunicazione tra le due VM, devi creare una regola firewall per consentire il traffico proveniente dalla subnet.
• Controlli di integrità di Cloud Load Balancing. Per ulteriori informazioni, vedi Creare una regola firewall per i controlli di integrità.

Nota: la procedura seguente è una versione semplificata delle istruzioni per la creazione di regole firewall. Per istruzioni più dettagliate, consulta la documentazione sul Virtual Private Cloud.

Per creare una regola firewall:

1. Nella console, vai alla pagina Regole firewall.

   Apri la pagina Regole 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 Target, seleziona Tutte le istanze nella rete.
   • Nel campo Filtro di origine, seleziona una delle seguenti opzioni:
     • Intervalli IP per consentire il traffico in entrata da indirizzi IP specifici. Specifica l'intervallo di indirizzi IP nel campo Intervalli IP di origine.
     • Subnet per consentire il traffico in entrata da una determinata subnet. Specifica il nome della subnet nel seguente campo subnet. Puoi utilizzare questa opzione per consentire l'accesso tra le VM in una configurazione a tre livelli o 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 fungono da nodi primari e secondari nel tuo cluster ad alta disponibilità.

Per definire e sottoporre a deployment le VM, utilizza lo stesso modello di Cloud Deployment Manager che utilizzi per il deployment di una VM per un sistema SAP NetWeaver nella pagina relativa al deployment automatico delle VM per SAP NetWeaver su Linux.

Tuttavia, per eseguire il deployment di due VM invece di una, devi aggiungere la definizione della seconda VM al file di configurazione copiando e incollando la definizione della prima VM. Dopo aver creato la seconda definizione, devi cambiare i nomi della risorsa e dell'istanza nella seconda definizione. Per proteggerti da un errore di zona, specifica una zona diversa nella stessa area geografica. Tutti gli altri valori delle proprietà nelle due definizioni rimangono invariati.

Dopo il deployment delle VM, installerai SAP NetWeaver e definirai e configurerai il cluster ad alta disponibilità.

Le istruzioni seguenti utilizzano Cloud Shell, ma in genere sono applicabili all'interfaccia a riga di comando di Google Cloud.

1. Apri Cloud Shell.

   Vai a Cloud Shell

2. Scarica il modello di 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. Facoltativamente, rinomina il file template.yaml per identificare la configurazione definita. Ad esempio, nw-ha-sles15sp3.yaml.

4. Apri il file YAML di configurazione 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 di file di configurazione YAML, definisci la prima istanza VM. Devi definire la seconda istanza VM nel passaggio successivo dopo la tabella seguente.

   Specifica i valori delle proprietà sostituendo le parentesi e i relativi contenuti con i valori dell'installazione. Le proprietà sono descritte nella tabella seguente. Per un esempio di file di configurazione completo, vedi 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 località, il tipo e la versione del modello di Deployment Manager da utilizzare durante il deployment. Il file YAML include due specifiche type, una delle quali commentato. 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 di VM principale e secondaria. Potresti usare nomi che identificano le istanze come appartenenti allo stesso cluster ad alta disponibilità. I nomi delle istanze devono avere una lunghezza massima di 13 caratteri e devono 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 principali e secondarie. Se ti serve un tipo di VM personalizzato, specifica un piccolo tipo di VM predefinito e, al termine del deployment, personalizza la VM in base alle esigenze.
   zone	Stringa	La zona Google Cloud in cui eseguire il deployment dell'istanza VM che definisci. Specifica zone diverse nella stessa area geografica per le definizioni di VM principali e secondarie. Le zone devono trovarsi nella stessa area geografica 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/sles-15-sp3-sap. Per l'elenco di famiglie di immagini disponibili, consulta la pagina Immagini nella console.
   linuxImageProject	Stringa	Il progetto Google Cloud che contiene l'immagine che utilizzerai. Questo progetto potrebbe essere il tuo o il progetto immagine di Google Cloud suse-sap-cloud. Per un elenco dei progetti di immagini di Google Cloud, consulta la pagina relativa alle 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	La dimensione del volume di scambio. La dimensione minima è di 1 GB.
   networkTag	Stringa	(Facoltativo) Uno o più tag di rete separati da virgole che rappresentano l'istanza VM a scopo di firewall o routing. Per le configurazioni ad alta disponibilità, specifica un tag di rete da utilizzare per una regola firewall che consenta la comunicazione tra i nodi del cluster e un tag di rete da utilizzare in una regola firewall che consenta ai controlli di integrità di Cloud Load Balancing di accedere ai nodi del cluster. Se specifichi publicIP: No e non specifichi un tag di rete, assicurati di fornire un altro mezzo di accesso a Internet.
   serviceAccount	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 predefinito di Compute Engine. Specifica l'indirizzo completo dell'account di servizio. Ad esempio, [e-mail]
   publicIP	Booleano	(Facoltativo) Determina se un indirizzo IP pubblico viene aggiunto alla tua istanza VM. Il valore predefinito è Yes. Nota: non specificare No solo se hai un gateway NAT configurato con un tag di rete definito per la VM o se non hai fornito alla VM un'altra route per Internet. In assenza di percorso a Internet, l'installazione non riesce.
   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 dell'Assistenza Google ti chieda di attivare il debug.

6. Nel file di configurazione YAML, crea la definizione della seconda VM copiando la definizione della prima e incollando la copia dopo la prima definizione. Per un esempio, vedi 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 tuo deployment.
   • TEMPLATE_NAME rappresenta il nome del file di configurazione YAML.

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

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

Esempio di file di configurazione YAML completo

L'esempio seguente mostra un file di configurazione YAML completato che esegue il deployment di due istanze VM per una configurazione ad alta disponibilità per SAP NetWeaver utilizzando l'ultima versione dei modelli di Deployment Manager. Nell'esempio vengono omessi 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 modificando i valori delle proprietà name, instanceName e zone. Tutti gli altri valori delle proprietà nelle due definizioni delle risorse sono uguali.

Le proprietà networkTag e serviceAccount si trovano nella sezione Opzioni avanzate del modello di file di configurazione.

resources:
- name: sap_nw_node_1
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/sap_nw.py
  properties:
    instanceName: nw-ha-vm-1
    instanceType: n2-standard-4
    zone: us-central1-b
    subnetwork: example-sub-network-sap
    linuxImage: family/sles-15-sp3-sap
    linuxImageProject: suse-sap-cloud
    usrsapSize: 15
    sapmntSize: 15
    swapSize: 24
    networkTag: cluster-ntwk-tag,allow-health-check
    serviceAccount: [e-mail]
- 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/sles-15-sp3-sap
    linuxImageProject: suse-sap-cloud
    usrsapSize: 15
    sapmntSize: 15
    swapSize: 24
    networkTag: cluster-ntwk-tag,allow-health-check
    serviceAccount: [e-mail]

Crea regole firewall che consentano l'accesso alle VM host

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

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

Quando crei regole firewall VPC, devi specificare i tag di rete definiti nel file di configurazione template.yaml per designare le VM host come target 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 del cluster, aggiungi una regola firewall che consenta tutti i tipi di connessione su qualsiasi porta da altre VM nella stessa subnet.

Assicurati che le regole firewall per la verifica del deployment e per la comunicazione intracluster siano create prima di procedere alla sezione successiva. Per le istruzioni, vedi Aggiungere regole firewall.

Verifica del deployment delle VM

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

Controlla i log

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

   Nota: quando completi questo passaggio in Cloud Logging, potresti incorrere in costi. Per ulteriori informazioni, consulta i prezzi di Cloud Logging.

   Vai a Cloud Logging

2. Filtra i log:

   Esplora log

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

   2. Dal menu a discesa Resource (Risorsa), seleziona Global (Globale) e fai clic su Aggiungi.

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

      resource.type="global"
      "Deployment"
      

   3. Fai clic su Esegui query.

   Visualizzatore log legacy

   • Nella pagina del visualizzatore di log legacy, dal menu di selezione di base, seleziona Globale come risorsa di logging.

3. Analizza i log filtrati:

   • Se viene visualizzato "--- Finished", l'elaborazione di Deployment Manager è completata e puoi procedere al passaggio successivo.

   • Se viene visualizzato un errore di quota:

     1. Nella pagina IAM &Quote di amministrazione, aumenta una qualsiasi delle tue 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 pulire le VM e i dischi permanenti dall'installazione non riuscita.

     3. Esegui di nuovo Deployment Manager.

Controlla la configurazione delle VM

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

   1. Se non lo hai già fatto, crea una regola firewall per consentire una connessione SSH sulla porta 22.

   2. Vai alla pagina Istanze VM.

      Vai alle istanze VM

   3. Connettiti a ogni istanza VM facendo clic sul pulsante SSH nella voce per ogni istanza VM. In alternativa, puoi utilizzare il tuo metodo SSH preferito.

      

2. Visualizza il file system:

   ~> df -h

   Assicurati di visualizzare 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

   Puoi vedere risultati simili al seguente esempio:

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

Se uno dei passaggi di convalida mostra 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 di nuovo il deployment.

Aggiorna l'interfaccia a riga di comando di Google Cloud

Il modello di Deployment Manager ha installato l'interfaccia a riga di comando di Google Cloud sulle VM durante il deployment. Aggiorna l'interfaccia a riga di comando gcloud per assicurarti che includa tutti gli ultimi aggiornamenti.

1. SSH nella VM principale.

2. Aggiorna l'interfaccia a riga di comando gcloud:

   ~>  sudo gcloud components update

3. Segui le istruzioni.

4. Ripeti i passaggi sulla VM secondaria.

Abilita la comunicazione di backend del bilanciatore del carico tra le VM

Dopo aver confermato il corretto deployment delle VM, abilita la comunicazione del backend tra le VM che fungeranno 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 di Linux fornite da Google Cloud.

Per abilitare le comunicazioni di backend del bilanciatore del carico, esegui i passaggi seguenti 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 modificarlo. 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 dello user agent:

   sudo service google-guest-agent start

La configurazione del controllo di integrità del bilanciatore del carico richiede sia una porta di destinazione di ascolto per il controllo di integrità che un'assegnazione dell'IP virtuale a un'interfaccia. Per ulteriori informazioni, consulta la sezione Testare la configurazione del bilanciatore del carico.

Configura le chiavi SSH nella VM principale e in quella secondaria

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

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

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

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

• Trasferisci file più piccoli attraverso la tua workstation locale utilizzando le opzioni del menu Carica file e Scarica file di Cloud Shell. Vedi Gestire i file con Cloud Shell.
• Scambiare file utilizzando un bucket Cloud Storage. Consulta la pagina Utilizzo degli oggetti.
• Usa una soluzione di archiviazione file come Filestore o NetApp Cloud Volumes per creare una cartella condivisa. Vedi Soluzioni di condivisione dei file.

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

1. Nella VM host principale:

   1. Connettiti alla VM tramite SSH.

   2. Passa a root:

      $ sudo su -

   3. Verifica che la chiave SSH esista:

      # ls -l /root/.ssh/

      Dovresti vedere i file della chiave id_rsa 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. Aggiorna i metadati della VM principale con informazioni sulla chiave SSH per la VM secondaria.

      # gcloud compute instances add-metadata SECONDARY_VM_NAME \
      --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \
      --zone SECONDARY_VM_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. Nella VM host secondaria:

   1. SSH nella VM.

   2. Passa a root:

      $ sudo su -

   3. Verifica che la chiave SSH esista:

      # ls -l /root/.ssh/

      Dovresti vedere i file della chiave id_rsa 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. Aggiorna i metadati della VM secondaria con informazioni sulla chiave SSH della 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. Per verificare che le chiavi SSH siano configurate correttamente, apri una connessione SSH dal sistema secondario al sistema principale.

      # ssh PRIMARY_VM_NAME

Imposta l'archiviazione di file condivisi e configura le directory condivise

Devi configurare una soluzione di condivisione file NFS che fornisca uno spazio di archiviazione per i file condiviso a disponibilità elevata a cui possono accedere entrambi i nodi del tuo cluster ad alta disponibilità. Poi creerai directory su entrambi i nodi che vengono mappati all'archiviazione di file condivisa. Il software del cluster garantisce che le directory appropriate vengano montate solo sulle istanze corrette.

Questa guida non comprende la configurazione di una soluzione per la condivisione di file. 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 soluzione di condivisione file, ti consigliamo di utilizzare il livello aziendale di Filestore. Per informazioni su come creare un'istanza Filestore, consulta Creazione di istanze.

Per informazioni sulle soluzioni di condivisione file disponibili su Google Cloud, consulta la sezione Opzioni di archiviazione condivise per i sistemi SAP ad alta disponibilità su Google Cloud.

Per configurare le directory condivise:

1. Se non hai ancora configurato una soluzione di archiviazione di file condivisa NFS ad alta disponibilità, fallo ora.

2. Monta lo spazio di archiviazione condiviso 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 uno dei due server, crea directory per sapmnt, la directory di trasporto centrale, la directory di sistema e la directory specifica dell'istanza. Se utilizzi uno stack Java, sostituisci "ASCS" con "SCS" prima di utilizzare i comandi seguenti e qualsiasi altro esempio:

   ~> sudo mkdir /mnt/nfs/sapmntSID_UC
   ~> sudo mkdir /mnt/nfs/usrsap{trans,SID_UCSYS,SID_UCASCSASCS_INSTANCE_NUMBER,SID_UCERSERS_INSTANCE_NUMBER}

   Sostituisci quanto segue:

   • SID_UC: l'ID di sistema SAP (SID) con lettere maiuscole. 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_UC
   ~> sudo mkdir -p /usr/sap/trans
   ~> sudo mkdir -p /usr/sap/SID_UC/SYS
   ~> sudo mkdir -p /usr/sap/SID_UC/ASCSASCS_INSTANCE_NUMBER
   ~> sudo mkdir -p /usr/sap/SID_UC/ERSERS_INSTANCE_NUMBER

5. Configura autofs per montare le directory di file condivise comuni quando accedono per la prima volta. Il montaggio delle directory ASCSASCS_INSTANCE_NUMBER e ERSERS_INSTANCE_NUMBER viene gestito dal software del cluster, che configuri in un passaggio successivo.

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

   Configura autofs su entrambi i server:

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

   Per ulteriori informazioni su autofs, consulta la sezione 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_UC
   ~> cd /usr/sap/trans
   ~> cd /usr/sap/SID_UC/SYS
   

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 alla seguente:

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

Configurare il supporto per il failover di Cloud Load Balancing

Il servizio di bilanciamento del carico TCP/UDP interno con supporto di failover instrada il traffico ASCS e ERS alle istanze attive di ciascuna in un cluster SAP NetWeaver. Il bilanciamento del carico TCP/UDP interno utilizza indirizzi IP virtuali (VIP), servizi di backend, gruppi di istanze e controlli di integrità per instradare il traffico in modo appropriato.

Prenota indirizzi IP per gli IP virtuali

Per un cluster SAP NetWeaver ad alta disponibilità, puoi creare due VIP, talvolta chiamati indirizzi IP sospesi. un VIP segue l'istanza attiva di SAP Central Services (SCS) e l'altro segue l'istanza Enqueue Replication Server (ERS). Il bilanciatore del carico instrada il traffico inviato a ciascun VIP alla VM che ospita attualmente l'istanza attiva del componente ASCS o ERS del VIP.

1. Apri Cloud Shell:

   Vai a Cloud Shell

2. Prenota un indirizzo IP per l'IP virtuale dell'ASCS e per il VIP dell'ERS. Per ASCS, l'indirizzo IP è l'indirizzo IP che le applicazioni utilizzano per accedere a SAP NetWeaver. Per ERS, l'indirizzo IP è l'indirizzo IP utilizzato per la replica di Enqueue Server. Se ometti il flag --addresses, verrà scelto un indirizzo IP nella subnet specificata:

   ~ gcloud compute addresses create ASCS_VIP_NAME \
     --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
     --addresses ASCS_VIP_ADDRESS
   
   ~ gcloud compute addresses create ERS_VIP_NAME \
     --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
     --addresses ERS_VIP_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 l'area geografica di Google Cloud in cui si trova il cluster. Ad esempio, us-central1
   • CLUSTER_SUBNET: specifica la subnet che stai utilizzando con il cluster. Ad esempio, example-sub-network-sap.
   • ASCS_VIP_ADDRESS: se vuoi, specifica un indirizzo IP per l'IP virtuale ASCS nella notazione CIDR. Ad esempio, 10.1.0.2.
   • ERS_VIP_NAME: specifica un nome per l'indirizzo IP virtuale dell'istanza ERS. Ad esempio, ers-aha-vip.
   • ERS_VIP_ADDRESS: se vuoi, specifica un indirizzo IP per l'IP virtuale ERS nella notazione CIDR. Ad esempio, 10.1.0.4.

   Per ulteriori informazioni sulla prenotazione di un IP statico, vedi Prenotare un indirizzo IP interno statico.

3. Conferma la prenotazione dell'indirizzo IP:

   ~ gcloud compute addresses describe VIP_NAME \
     --region CLUSTER_REGION

   Dovresti vedere un output simile all'esempio seguente:

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

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

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

I nomi host VIP non sono noti all'esterno delle VM, a meno che non li 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 per il file /etc/hosts dovrebbero essere simili al seguente esempio:

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

Creare i controlli di integrità di Cloud Load Balancing

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

1. In Cloud Shell, crea i controlli di integrità. Per evitare conflitti con altri servizi, indica i numeri di porta per le istanze ASCS e ERS nell'intervallo privato 49152-65535. I valori di controllo tra intervalli di timeout e timeout nei comandi riportati di seguito sono leggermente più lunghi delle impostazioni predefinite, 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 ogni controllo di integrità:

   ~ gcloud compute health-checks describe HEALTH_CHECK_NAME

   Dovresti vedere un output simile all'esempio seguente:

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

Crea una regola firewall per i controlli di integrità

Se non l'hai già fatto, definisci una regola firewall per una porta nell'intervallo privato che consenta l'accesso alle VM host dagli intervalli IP utilizzati dai controlli di integrità di Cloud Load Balancing, 35.191.0.0/16 e 130.211.0.0/22. Per ulteriori informazioni sulle regole firewall per i bilanciatori del carico, consulta la sezione 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 viene utilizzato dalla regola firewall per i controlli di integrità.

   • ~ gcloud compute instances add-tags  PRIMARY_VM_NAME \
     --zone=PRIMARY_ZONE \
     --tags NETWORK_TAGS

   • ~ gcloud compute instances add-tags  SECONDARY_VM_NAME \
     --zone=SECONDARY_ZONE \
     --tags NETWORK_TAGS

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 di nodi cluster e aggiungere la VM in quella zona al gruppo di istanze.

1. In Cloud Shell, crea il gruppo di istanze primarie e aggiungi 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 all'esempio seguente:

   NAME                              ZONE           NETWORK              NETWORK_PROJECT        MANAGED  INSTANCES
   sap-aha-primary-instance-group    us-central1-b  example-network-sap  example-project-123456  No       1
   sap-aha-secondary-instance-group  us-central1-c  example-network-sap  example-project-123456  No       1
   

Configura i servizi di backend

Crea due servizi di backend, uno per ASCS e uno per ERS. Aggiungi entrambi i gruppi di istanze a ogni servizio di backend, designando il gruppo di istanze opposte 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 gruppo di servizio di backend e 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 primari 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 l'ERS, l'elemento failover: true verrebbe visualizzato nel gruppo di istanze principale:

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

4. In Cloud Shell, crea regole di forwarding per i servizi di backend ASCS e 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

Nota: i tuoi gruppi di istanze di backend non verranno registrati come integri finché non avrai completato la configurazione del cluster Pacemaker.

Testa la configurazione del bilanciatore del carico

Anche se i gruppi di istanze di backend non si registrano come integri fino a un momento successivo, puoi testare la configurazione del bilanciatore del carico configurando un listener per rispondere ai controlli di integrità. Dopo aver configurato un listener, se il bilanciatore del carico è configurato correttamente, lo stato dei gruppi di istanze di backend passa a Integro.

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

Test del bilanciatore del carico con utilità socat

Puoi utilizzare l'utilità socat per ascoltare temporaneamente su una porta del controllo di integrità. Devi comunque installare l'socatutilità, perché ti servirà in un secondo momento per la configurazione delle risorse del cluster.

1. Installa l'utilità socat su entrambe le VM host come root:

   # zypper install socat

2. Nella 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 del controllo di integrità ASCS:

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

4. In Cloud Shell, dopo aver atteso alcuni secondi per consentire al controllo di integrità di rilevare il listener, controlla l'integrità del gruppo di istanze di backend ASCS:

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

   Dovresti vedere un output simile all'esempio seguente 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 delle variabili ASCS con i valori ERS.

Test del bilanciatore del carico tramite la porta 22

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

Per utilizzare temporaneamente la porta 22:

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

   Vai a Controlli di integrità

2. Fai clic sul nome del tuo 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 per consentire al controllo di integrità di rilevare il listener, controlla l'integrità dei gruppi di istanze 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, reimposta il numero di porta del controllo di integrità su quello originale.

Configura pacemaker

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

Per ulteriori informazioni sulla configurazione dei cluster ad alta disponibilità su SLES, consulta la documentazione dell'estensione SUSE Linux Enterprise High Availability per la tua versione di SLES.

Installa i pacchetti di cluster richiesti

1. Come root negli host principali e secondari, scarica i seguenti pacchetti di cluster obbligatori:

   • Il pattern ha_sles:

     # zypper install -t pattern ha_sles

   • Il pacchetto sap-suse-cluster-connector:

     # zypper install -y sap-suse-cluster-connector

   • Se non lo hai già installato, l'utilità socat:

     # zypper install -y socat

2. Verifica che siano caricati gli ultimi agenti disponibili:

   # zypper se -t patch SUSE-SLE-HA

Inizializza, configura e avvia il cluster sulla VM principale

Devi inizializzare il cluster utilizzando lo script ha-cluster-init SUSE. Dovrai quindi modificare il file di configurazione Corosync e sincronizzarlo con il nodo secondario. Dopo aver avviato il cluster, imposti le proprietà e i valori predefiniti del cluster utilizzando i comandi crm.

Potresti ricevere i seguenti avvisi durante l'inizializzazione o l'iscrizione al cluster:

• Nessun firewall rilevato: questo avviso indica che il processo di inizializzazione del cluster non è riuscito a trovare o aggiornare il firewall del sistema operativo. Se utilizzi un firewall del sistema operativo, devi consentire l'accesso a queste porte. Devi anche creare una regola firewall VPC che consenta l'accesso a queste porte e a quelle utilizzate dall'applicazione SAP.
• Nessun dispositivo watchdog trovato: puoi ignorare questo messaggio. Queste istruzioni non utilizzano SBD.
• Dovresti cambiare la password "hacluster": cambia la password dopo aver completato le istruzioni.

Creare i file di configurazione Corosync

1. Crea un file di configurazione Corosync nell'host principale:

   1. Utilizzando l'editor di testo che preferisci, crea il seguente file:

      /etc/corosync/corosync.conf

   2. Nel file corosync.conf nell'host principale, aggiungi la seguente configurazione, sostituendo il testo della variabile corsivo con i tuoi valori:

      totem {
       version: 2
       secauth: off
       crypto_hash: sha1
       crypto_cipher: aes256
       cluster_name: hacluster
       clear_node_high_bit: yes
       token: 20000
       token_retransmits_before_loss_const: 10
       join: 60
       max_messages:  20
       transport: udpu
       interface {
         ringnumber: 0
         Bindnetaddr: STATIC_IP_OF_THIS_HOST
         mcastport: 5405
         ttl: 1
       }
      }
      logging {
       fileline:  off
       to_stderr: no
       to_logfile: no
       logfile: /var/log/cluster/corosync.log
       to_syslog: yes
       debug: off
       timestamp: on
       logger_subsys {
         subsys: QUORUM
         debug: off
       }
      }
      nodelist {
       node {
         ring0_addr: THIS_HOST_NAME
         nodeid: 1
       }
       node {
         ring0_addr: OTHER_HOST_NAME
         nodeid: 2
       }
      }
      quorum {
       provider: corosync_votequorum
       expected_votes: 2
       two_node: 1
      }

   Sostituisci quanto segue:

   • STATIC_IP_OF_THIS_HOST: specifica l'indirizzo IP interno statico statico di questa VM, come mostrato in Interfacce di rete nella console o come visualizzato da gcloud compute instances describe VM_NAME.
   • THIS_HOST_NAME: specifica il nome host di questa VM.
   • OTHER_HOST_NAME: specifica il nome host dell'altra VM nel cluster.

2. Crea un file di configurazione Corosync nell'host secondario ripetendo gli stessi passaggi utilizzati per l'host principale. Ad eccezione dell'IP statico dell'HDB nella proprietà Bindnetaddr e dell'ordine dei nomi host in nodelist, i valori delle proprietà del file di configurazione sono uguali per ogni host.

Inizializza il cluster

Per inizializzare il cluster:

1. Nell'host principale come root, inizializza il cluster utilizzando lo script ha-cluster-initSUSE. I seguenti comandi assegnano un nome al cluster e creano il file di configurazione corosync.conf:configuralo, quindi imposta la sincronizzazione tra i nodi del cluster.

   # ha-cluster-init --name CLUSTER_NAME --yes --interface eth0 csync2
   # ha-cluster-init --name CLUSTER_NAME --yes --interface eth0 corosync

Imposta le proprietà aggiuntive del cluster

1. Imposta le proprietà generali del cluster:

   # crm configure property stonith-timeout="300s"
   # crm configure property stonith-enabled="true"
   # crm configure rsc_defaults resource-stickiness="1"
   # crm configure rsc_defaults migration-threshold="3"
   # crm configure op_defaults timeout="600"

   Quando definisci le singole risorse del cluster, i valori che hai impostato per resource-stickiness e migration-threshold sostituiscono i valori predefiniti impostati qui.

   Per visualizzare le impostazioni predefinite e i valori delle risorse definite, inserisci crm config show.

2. Avvia pacemaker nell'host principale:

   # systemctl enable pacemaker
   # systemctl start pacemaker

Entra nella VM secondaria nel cluster

Dal terminale aperto sulla VM principale, partecipa e avvia il cluster sulla VM secondaria tramite SSH.

1. Nella VM principale, esegui le seguenti opzioni di script ha-cluster-join sulla VM secondaria tramite SSH. Se hai configurato il tuo cluster HA come descritto da queste istruzioni, puoi ignorare gli avvisi sul dispositivo watchdog.

   1. Esegui l'opzione --interface eth0 csync2:

      # ssh SECONDARY_VM_NAME 'ha-cluster-join --cluster-node PRIMARY_VM_NAME --yes --interface eth0 csync2'

   2. Esegui l'opzione ssh_merge:

      # ssh SECONDARY_VM_NAME 'ha-cluster-join --cluster-node PRIMARY_VM_NAME --yes ssh_merge'

   3. Esegui l'opzione cluster:

      # ssh SECONDARY_VM_NAME 'ha-cluster-join --cluster-node PRIMARY_VM_NAME --yes cluster'

2. Avvia pacemaker nell'host secondario:

   1. Abilita pacemaker:

      # ssh SECONDARY_VM_NAME systemctl enable pacemaker

   2. Avvia pacemaker:

      # ssh SECONDARY_VM_NAME systemctl start pacemaker

3. In entrambi gli host come root, verifica che il cluster mostri entrambi i nodi:

   # crm_mon -s

   Dovresti vedere un output simile al seguente:

   CLUSTER OK: 2 nodes online, 0 resource instances configured

Configura le risorse cluster per l'infrastruttura

Tu definisci le risorse gestite da Pacemaker in un cluster ad alta disponibilità. Devi definire le risorse per i seguenti componenti del cluster:

• Il dispositivo di scherma, che impedisce gli scenari cerebrali suddivisi
• Le directory ASCS e ERS nel file system condiviso
• I controlli di integrità
• I VIP
• I componenti ASCS e ERS

Tu definisci le risorse per i componenti ASCS e ERS in seguito rispetto alle altre risorse, poiché devi prima installare SAP NetWeaver.

Attiva modalità di manutenzione

1. In entrambi gli host come root, attiva il cluster in modalità di manutenzione:

   # crm configure property maintenance-mode="true"

2. Conferma modalità di manutenzione:

   # crm status

   L'output dovrebbe indicare che la gestione delle risorse è disabilitata, come illustrato nell'esempio seguente:

   Cluster Summary:
   * Stack: corosync
   * Current DC: nw-ha-vm-1 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum
   * Last updated: Fri May 14 15:26:08 2021
   * Last change:  Thu May 13 19:02:33 2021 by root via cibadmin on nw-ha-vm-1
   * 2 nodes configured
   * 0 resource instances configured
   
               *** Resource management is DISABLED ***
   The cluster will not attempt to start, stop or recover services
   
   Node List:
   * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
   Full List of Resources:
   * No resources

Configura recinzioni

Per configurare la scherma, definisci una risorsa cluster con l'agente fence_gce per ogni VM host.

Per garantire la corretta sequenza di eventi dopo un'azione di scherma, devi anche configurare il sistema operativo in modo da ritardare il riavvio di Corosync dopo che una VM è stata recintata. Puoi anche regolare il timeout del pacemaker per i riavvii in modo da tenere conto del ritardo.

Creare le risorse di scherma dei dispositivi

Per ogni VM nel cluster, crei una risorsa cluster per il dispositivo di recinzione in grado di riavviarla. Il dispositivo di recinzione per una VM deve essere eseguito su una VM diversa, quindi configurerai la località della risorsa del cluster in modo che venga eseguita su qualsiasi VM ad eccezione della VM in cui può essere riavviata.

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

   # crm configure primitive FENCING_RESOURCE_PRIMARY_VM stonith:fence_gce \
     op monitor interval="300s" timeout="120s" \
     op start interval="0" timeout="60s" \
     params port="PRIMARY_VM_NAME" zone="PRIMARY_ZONE" \
     project="CLUSTER_PROJECT_ID" \
     pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30

2. Configura la posizione del dispositivo di scherma per la VM principale in modo che sia attiva solo sulla VM secondaria:

   # crm configure location FENCING_LOCATION_NAME_PRIMARY_VM \
     FENCING_RESOURCE_PRIMARY_VM -inf: "PRIMARY_VM_NAME"

3. Nell'host principale come root, crea una risorsa cluster per un dispositivo di scherma per la VM secondaria:

   # crm configure primitive FENCING_RESOURCE_SECONDARY_VM stonith:fence_gce \
     op monitor interval="300s" timeout="120s" \
     op start interval="0" timeout="60s" \
     params port="SECONDARY_VM_NAME" zone="SECONDARY_VM_ZONE" \
     project="CLUSTER_PROJECT_ID" \
     pcmk_reboot_timeout=300 pcmk_monitor_retries=4

4. Configura la posizione del dispositivo di scherma per la VM secondaria in modo che sia attiva solo sulla VM principale:

   # crm configure location FENCING_LOCATION_NAME_SECONDARY_VM \
     FENCING_RESOURCE_SECONDARY_VM -inf: "SECONDARY_VM_NAME"

Imposta un ritardo per il riavvio di Corosync

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

   systemctl edit corosync.service

2. Aggiungi le seguenti righe al file:

   [Service]
   ExecStartPre=/bin/sleep 60

3. Salva il file ed esci dall'editor.

4. Ricarica la configurazione del gestore di sistema.

   systemctl daemon-reload

5. Conferma che il file a discesa è stato creato:

   service corosync status

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

Creare le risorse del file system

Ora che hai creato le directory del file system condiviso, puoi definire le risorse del cluster.

1. Configura le risorse del file system per le directory specifiche dell'istanza.

   # crm configure primitive ASCS_FILE_SYSTEM_RESOURCE Filesystem \
   device="NFS_PATH/usrsapSID_UCASCSASCS_INSTANCE_NUMBER" \
   directory="/usr/sap/SID_UC/ASCSASCS_INSTANCE_NUMBER" fstype="nfs" \
   op start timeout=60s interval=0 \
   op stop timeout=60s interval=0 \
   op monitor interval=20s timeout=40s

   Sostituisci quanto segue:

   • ASCS_FILE_SYSTEM_RESOURCE: specifica un nome per la risorsa del cluster per il file system ASCS.
   • NFS_PATH: specifica il percorso del file system NFS per ASCS.
   • SID_UC: specifica l'ID sistema (SID). Usa il maiuscolo per tutte le lettere.
   • ASCS_INSTANCE_NUMBER: specifica il numero dell'istanza ASCS.

   # crm configure primitive ERS_FILE_SYSTEM_RESOURCE Filesystem \
   device="NFS_PATH/usrsapSID_UCERSERS_INSTANCE_NUMBER" \
   directory="/usr/sap/SID_UC/ERSERS_INSTANCE_NUMBER" fstype="nfs" \
   op start timeout=60s interval=0 \
   op stop timeout=60s interval=0 \
   op monitor interval=20s timeout=40s

   Sostituisci quanto segue:

   • ERS_FILE_SYSTEM_RESOURCE: specifica un nome per la risorsa del cluster per il file system ERS.
   • NFS_PATH: specifica il percorso del file system NFS per ERS.
   • SID_UC: specifica l'ID sistema (SID). Usa il maiuscolo per tutte le lettere.
   • ERS_INSTANCE_NUMBER: specifica il numero dell'istanza ASCS.

Creare le risorse per il controllo di integrità

1. Configura le risorse cluster per i controlli di integrità ASCS e ERS:

# crm configure primitive ASCS_HEALTH_CHECK_RESOURCE anything \
  params binfile="/usr/bin/socat" \
  cmdline_options="-U TCP-LISTEN:ASCS_HEALTHCHECK_PORT_NUM,backlog=10,fork,reuseaddr /dev/null" \
  op monitor timeout=20s interval=10s \
  op_params depth=0

# crm configure primitive ERS_HEALTH_CHECK_RESOURCE anything \
  params binfile="/usr/bin/socat" \
  cmdline_options="-U TCP-LISTEN:ERS_HEALTHCHECK_PORT_NUM,backlog=10,fork,reuseaddr /dev/null" \
  op monitor timeout=20s interval=10s \
  op_params depth=0

Creare le risorse VIP

Definisci le risorse del cluster per gli indirizzi VIP.

1. Per cercare l'indirizzo VIP numerico, 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 cluster per i VIP ASCS e ERS.

   # crm configure primitive ASCS_VIP_RESOURCE IPaddr2 \
    params ip=ASCS_VIP_ADDRESS cidr_netmask=32 nic="eth0" \
    op monitor interval=3600s timeout=60s

   # crm configure primitive ERS_VIP_RESOURCE IPaddr2 \
    params ip=ERS_VIP_ADDRESS cidr_netmask=32 nic="eth0" \
    op monitor interval=3600s timeout=60s

Visualizza le risorse definite

1. Per visualizzare tutte le risorse definite finora, inserisci il seguente comando:

   # crm status

   Dovresti vedere un output simile all'esempio seguente:

   Stack: corosync
   Current DC: nw-ha-vm-1 (version 1.1.24+20201209.8f22be2ae-3.12.1-1.1.24+20201209.8f22be2ae) - partition with quorum
   Last updated: Wed May 26 19:10:10 2021
   Last change: Tue May 25 23:48:35 2021 by root via cibadmin on nw-ha-vm-1
   
   2 nodes configured
   8 resource instances configured
   
                 *** Resource management is DISABLED ***
     The cluster will not attempt to start, stop or recover services
   
   Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
   Full list of resources:
   
    fencing-rsc-nw-aha-vm-1        (stonith:fence_gce):    Stopped (unmanaged)
    fencing-rsc-nw-aha-vm-2        (stonith:fence_gce):    Stopped (unmanaged)
    filesystem-rsc-nw-aha-ascs      (ocf::heartbeat:Filesystem):    Stopped (unmanaged)
    filesystem-rsc-nw-aha-ers      (ocf::heartbeat:Filesystem):    Stopped (unmanaged)
    health-check-rsc-nw-ha-ascs     (ocf::heartbeat:anything):      Stopped (unmanaged)
    health-check-rsc-nw-ha-ers     (ocf::heartbeat:anything):      Stopped (unmanaged)
    vip-rsc-nw-aha-ascs     (ocf::heartbeat:IPaddr2):       Stopped (unmanaged)
    vip-rsc-nw-aha-ers     (ocf::heartbeat:IPaddr2):       Stopped (unmanaged)

Installa ASCS ed ERS

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

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

Prepararsi all'installazione

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

1. Escludere il cluster dalla modalità di manutenzione:

   # crm configure property maintenance-mode="false"

2. Su entrambi i server come root, inserisci i seguenti comandi, 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_UC/SYS
   # chown SID_LCadm:sapsys /sapmnt/SID_UC -R
   # chown SID_LCadm:sapsys /usr/sap/trans -R
   # chown SID_LCadm:sapsys /usr/sap/SID_UC/SYS -R
   # chown SID_LCadm:sapsys /usr/sap/SID_UC -R

   Sostituisci quanto segue:

   • GID_SAPINST: specifica l'ID del gruppo Linux per lo strumento di provisioning SAP.
   • GID_SAPSYS: specifica il percorso del file system NFS.
   • UID_SIDADM: specifica il numero dell'istanza ASCS.
   • SID_LC: specifica l'ID sistema (SID). Utilizza le minuscole per tutte le lettere.
   • UID_SAPADM: specifica lo User-ID per l'agente host SAP.
   • SID_UC: specifica l'ID sistema (SID). Usa il maiuscolo per tutte le lettere.

Installa il componente ASCS

1. Sul server secondario, inserisci il comando seguente per mettere il server secondario in modalità standby:

   # crm_standby -v on -N ${HOSTNAME};

   La configurazione del server secondario in modalità standby consolida tutte le risorse del cluster sul server principale, semplificando l'installazione.

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

   # crm status

   Dovresti vedere un output simile all'esempio seguente:

   Stack: corosync
    Current DC: nw-ha-vm-1 (version 1.1.24+20201209.8f22be2ae-3.12.1-1.1.24+20201209.8f22be2ae) - partition with quorum
    Last updated: Thu May 27 17:45:16 2021
    Last change: Thu May 27 17:45:09 2021 by root via crm_attribute on nw-ha-vm-2
   
    2 nodes configured
    8 resource instances configured
   
    Node nw-ha-vm-2: standby
    Online: [ nw-ha-vm-1 ]
   
    Full list of resources:
   
     fencing-rsc-nw-aha-vm-1        (stonith:fence_gce):    Stopped
     fencing-rsc-nw-aha-vm-2        (stonith:fence_gce):    Started nw-ha-vm-1
     filesystem-rsc-nw-aha-scs      (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
     filesystem-rsc-nw-aha-ers      (ocf::heartbeat:Filesystem):    Started nw-ha-vm-1
     health-check-rsc-nw-ha-scs     (ocf::heartbeat:anything):      Started nw-ha-vm-1
     health-check-rsc-nw-ha-ers     (ocf::heartbeat:anything):      Started nw-ha-vm-1
     vip-rsc-nw-aha-scs     (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
     vip-rsc-nw-aha-ers     (ocf::heartbeat:IPaddr2):       Started nw-ha-vm-1
   

3. Sul server principale come utente root, modifica la directory in una directory di installazione temporanea, ad esempio /tmp, per installare l'istanza ASCS eseguendo lo SAP Software Provisioning Manager (SWPM).

   • Per accedere all'interfaccia web di SWPM, devi disporre della password per l'utente root. Se il tuo 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 host virtuale che hai definito per l'indirizzo VIP ASCS nel file /etc/hosts.

     Ad esempio:

     cd /tmp; /mnt/nfs/install/SWPM/sapinst SAPINST_USE_HOSTNAME=vh-aha-scs

   • Nella pagina di conferma finale di SWPM, assicurati che il nome dell'host virtuale sia corretto.

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

   # crm_standby -v off -N ${HOSTNAME}; # On SECONDARY

Installa il componente ERS

1. Sul server principale come root o sidadm, 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 il comando seguente per mettere il server principale in modalità standby:

   # crm_standby -v on -N ${HOSTNAME};

   La configurazione del server principale in modalità standby consolida tutte le risorse del cluster sul server secondario, semplificando l'installazione.

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

   # crm status

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

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

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

     Ad esempio:

     cd /tmp; /mnt/nfs/install/SWPM/sapinst SAPINST_USE_HOSTNAME=vh-aha-ers

   • Nella pagina di conferma finale di SWPM, assicurati che il nome dell'host virtuale sia corretto.

5. Disconnetti la VM principale per averle entrambe attive:

   # crm_standby -v off -N ${HOSTNAME};

Configura i servizi SAP

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

Conferma le voci di servizio SAP

1. Su entrambi i server, verifica che /usr/sap/sapservices contenga voci per entrambi i servizi ASCS ed ERS. Puoi aggiungere le voci mancanti utilizzando l'elemento sapstartsrv command con le opzioni pf=PROFILE_OF_THE_SAP_INSTANCE e -reg. Ad esempio:

   # LD_LIBRARY_PATH=/usr/sap/hostctrl/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH
   /usr/sap/hostctrl/exe/sapstartsrv \
    pf=/usr/sap/SID_UC/SYS/profile/SID_UC_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \
    -reg
   /usr/sap/hostctrl/exe/sapstartsrv \
    pf=/usr/sap/SID_UC/SYS/profile/SID_UC_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
    -reg

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 su tutti i server siano arrestati tutti i servizi:

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

   Dovresti vedere un output simile all'esempio seguente:

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

Modificare i profili ASCS e 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 profili ASCS e ERS indicando i file nella directory del profilo oppure utilizzando i seguenti formati:

   SID_UC_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME

   SID_UC_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME

3. Abilita il pacchetto sap-suse-cluster-connector aggiungendo le seguenti righe ai profili delle istanze ASCS e ERS:

   #-----------------------------------------------------------------------
   # SUSE HA library
   #-----------------------------------------------------------------------
   service/halib = $(DIR_CT_RUN)/saphascriptco.so
   service/halib_cluster_connector = /usr/bin/sap_suse_cluster_connector
   

4. Se utilizzi ENSA1, attiva 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: con keepalive interval.

5. Se necessario, modifica i profili ASCS e ERS per cambiare il comportamento di avvio di Enqueue Server e Enqueue Replication Server.

   ENSA1

   Nella sezione "Avviare SAP enqueue server" del profilo ASCS, se vedi Restart_Program_NN, cambia "Restart", in "Start" come mostrato nell'esempio seguente.

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

   Nella sezione "Start enqueue replica server" del profilo ERS, se vedi Restart_Program_NN, cambia "Restart" in "Start" come mostrato nell'esempio seguente.

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

   ENSA2

   Nella sezione "Avviare SAP enqueue server" del profilo ASCS, se vedi Restart_Program_NN, cambia "Restart", in "Start" come mostrato nell'esempio seguente.

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

   Nella sezione "Inizia replicatore di coda" del profilo ERS, se vedi Restart_Program_NN, cambia "Restart" in "Start", come mostrato nell'esempio seguente.

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

Aggiungi l'utente sidadm al gruppo utenti haclient

Quando hai installato sap-suse-cluster-connector, l'installazione ha creato un gruppo di utenti haclient. Per consentire all'utente SID_LCadm di lavorare con il cluster, aggiungilo al gruppo di utenti haclient.

1. Su entrambi i server, aggiungi l'utente SID_LCadm al gruppo di utenti haclient:

   # usermod -aG haclient SID_LCadm

Configurare le risorse cluster per ASCS ed ERS

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

   # crm configure property maintenance-mode="true"

2. Verifica che il selettore sia in modalità di manutenzione:

   # crm status

   Se il cluster è in modalità di manutenzione, lo stato include le seguenti righe:

                 *** Resource management is DISABLED ***
   The cluster will not attempt to start, stop or recover services

3. Crea le risorse cluster per i servizi ASCS e ERS:

   ENSA1

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

     # crm configure primitive ASCS_INSTANCE_RESOURCE SAPInstance \
       operations \$id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \
       op monitor interval=11 timeout=60 on-fail=restart \
       params InstanceName=SID_UC_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
          START_PROFILE="/PATH_TO_PROFILE/SID_UC_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" \
          AUTOMATIC_RECOVER=false \
       meta resource-stickiness=5000 failure-timeout=60 \
          migration-threshold=1 priority=10

   • Crea la risorsa cluster per l'istanza ERS. Il valore di InstanceName è il nome del profilo dell'istanza che SWPM ha generato quando hai installato ERS. Il parametro IS_ERS=true indica a Pacemaker di impostare il flag runsersSID_UC su 1 nel nodo in cui è attiva l'ERS.

     # crm configure primitive ERS_INSTANCE_RESOURCE SAPInstance \
       operations \$id=ERS_INSTANCE_RSC_OPERATIONS_NAME \
       op monitor interval=11 timeout=60 on-fail=restart \
       params InstanceName=SID_UC_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME  \
          START_PROFILE="/PATH_TO_PROFILE/SID_UC_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" \
          AUTOMATIC_RECOVER=false IS_ERS=true \
       meta priority=1000

   ENSA2

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

     # crm configure primitive ASCS_INSTANCE_RESOURCE SAPInstance \
       operations \$id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \
       op monitor interval=11 timeout=60 on-fail=restart \
       params InstanceName=SID_UC_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
          START_PROFILE="/PATH_TO_PROFILE/SID_UC_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" \
          AUTOMATIC_RECOVER=false \
       meta resource-stickiness=5000 failure-timeout=60

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

     # crm configure primitive ERS_INSTANCE_RESOURCE SAPInstance \
       operations \$id=ERS_INSTANCE_RSC_OPERATIONS_NAME \
       op monitor interval=11 timeout=60 on-fail=restart \
       params InstanceName=SID_UC_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME  \
          START_PROFILE="/PATH_TO_PROFILE/SID_UC_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" \
          AUTOMATIC_RECOVER=false IS_ERS=true

Configurare gruppi di risorse e vincoli di località

1. Raggruppare le risorse ASCS e ERS. Puoi visualizzare i nomi di tutte le risorse definite in precedenza inserendo il comando crm resource status:

   # crm configure group ASCS_RESOURCE_GROUP ASCS_FILE_SYSTEM_RESOURCE \
     ASCS_HEALTH_CHECK_RESOURCE ASCS_VIP_RESOURCE \
     ASCS_INSTANCE_RESOURCE \
     meta resource-stickiness=3000

   Sostituisci quanto segue:

   • 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, 'nw1_ASCS00_group'.
   • ASCS_FILE_SYSTEM_RESOURCE: specifica il nome della risorsa del cluster definita in precedenza per il file system ASCS.
   • ASCS_HEALTH_CHECK_RESOURCE: specifica il nome della risorsa cluster che hai definito per il controllo di integrità ASCS in precedenza.
   • ASCS_VIP_RESOURCE: specifica il nome della risorsa del cluster definita in precedenza per il VIP ASCS.
   • ASCS_INSTANCE_RESOURCE: specifica il nome della risorsa del cluster definita in precedenza per l'istanza ASCS.

   # crm configure group ERS_RESOURCE_GROUP ERS_FILE_SYSTEM_RESOURCE \
     ERS_HEALTH_CHECK_RESOURCE ERS_VIP_RESOURCE \
     ERS_INSTANCE_RESOURCE

   Sostituisci quanto segue:

   • 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_group". Ad esempio, "nw1_ERS10_group".
   • ERS_FILE_SYSTEM_RESOURCE: specifica il nome della risorsa del cluster definita in precedenza per il file system ERS.
   • ERS_HEALTH_CHECK_RESOURCE: specifica il nome della risorsa cluster che hai definito per il controllo di integrità ERS in precedenza.
   • ERS_VIP_RESOURCE: specifica il nome della risorsa del cluster definita in precedenza per il VIP ERS.
   • ERS_INSTANCE_RESOURCE: specifica il nome della risorsa cluster che hai definito in precedenza per l'istanza ERS.

2. Crea i vincoli di colocation:

   ENSA1

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

      # crm configure colocation PREVENT_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUP

   2. Configura ASCS per il failover al server in cui è in esecuzione ERS, come determinato dal flag runsersSID_UC uguale a 1:

      # crm configure location LOC_SCS_SID_FAILOVER_TO_ERS ASCS_INSTANCE_RESOURCE \
      rule 2000: runs_ers_SID_UC eq 1

   3. Configura l'ASCS in modo che venga avviato prima che l'ERS passi all'altro server dopo un failover:

      # crm configure order ORD_SAP_SID_UC_FIRST_START_ASCS \
       Optional: ASCS_INSTANCE_RESOURCE:start \
       ERS_INSTANCE_RESOURCE:stop symmetrical=false

   ENSA2

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

      # crm configure colocation PREVENT_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUP

   2. Configura l'ASCS in modo che venga avviato prima che l'ERS passi all'altro server dopo un failover:

      # crm configure order ORD_SAP_SID_FIRST_START_ASCS \
       Optional: ASCS_INSTANCE_RESOURCE:start \
       ERS_INSTANCE_RESOURCE:stop symmetrical=false

3. Disattiva modalità di manutenzione.

   # crm configure property maintenance-mode="false"

4. Controlla la configurazione dei gruppi, i vincoli di colocation e l'ordinamento:

   # crm config show

   L'output deve includere righe simili a quelle dell'esempio seguente:

   ENSA1

   group ers-aha-rsc-group-name filesystem-rsc-nw-aha-ers health-check-rsc-nw-ha-ers vip-rsc-nw-aha-ers ers-aha-instance-rsc-name
   group ascs-aha-rsc-group-name filesystem-rsc-nw-aha-ascs health-check-rsc-nw-ha-ascs vip-rsc-nw-aha-ascs ascs-aha-instance-rsc-name \
           meta resource-stickiness=3000
   colocation prevent-aha-ascs-ers-coloc -5000: ers-aha-rsc-group-name ascs-aha-rsc-group-name
   location fencing-rsc-nw-aha-vm-1-loc fencing-rsc-nw-aha-vm-1 -inf: nw-ha-vm-1
   location fencing-rsc-nw-aha-vm-2-loc fencing-rsc-nw-aha-vm-2 -inf: nw-ha-vm-2
   location loc-sap-AHA-failover-to-ers ascs-aha-instance-rsc-name \
           rule 2000: runs_ers_AHA eq 1

   ENSA2

   group ers-aha-rsc-group-name filesystem-rsc-nw-aha-ers health-check-rsc-nw-ha-ers vip-rsc-nw-aha-ers ers-aha-instance-rsc-name
   group ascs-aha-rsc-group-name filesystem-rsc-nw-aha-ascs health-check-rsc-nw-ha-ascs vip-rsc-nw-aha-ascs ascs-aha-instance-rsc-name \
           meta resource-stickiness=3000
   location fencing-location-nw-aha-vm-1 fencing-rsc-nw-aha-vm-1 -inf: nw-ha-vm-1
   location fencing-location-nw-aha-vm-2 fencing-rsc-nw-aha-vm-2 -inf: nw-ha-vm-2
   order ord-sap-AHA-first-start-ascs Optional: ascs-aha-instance-rsc-name:start ers-aha-instance-rsc-name:stop symmetrical=false
   colocation prevent-aha-ascs-ers-coloc -5000: ers-aha-rsc-group-name ascs-aha-rsc-group-name

Convalida e testa il cluster

Questa sezione mostra come eseguire i seguenti test:

• Verifica la presenza di errori di configurazione
• Verificare che le risorse ASCS e ERS cambino correttamente i server durante gli failover
• Verificare che le serrature siano 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 uno dei due server, controlla su quali nodi sono in esecuzione le risorse:

   # crm status

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

   Cluster Summary:
     * Stack: corosync
     * Current DC: nw-ha-vm-2 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum
     * Last updated: Thu May 20 16:58:46 2021
     * Last change:  Thu May 20 16:57:31 2021 by ahaadm via crm_resource on nw-ha-vm-2
     * 2 nodes configured
     * 10 resource instances configured
   
   Node List:
     * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
   
   Active Resources:
     * fencing-rsc-nw-aha-vm-1     (stonith:fence_gce):     Started nw-ha-vm-2
     * fencing-rsc-nw-aha-vm-2     (stonith:fence_gce):     Started nw-ha-vm-1
     * Resource Group: ascs-aha-rsc-group-name:
       * filesystem-rsc-nw-aha-ascs (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
       * health-check-rsc-nw-ha-ascs        (ocf::heartbeat:anything):       Started nw-ha-vm-1
       * vip-rsc-nw-aha-ascs        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-1
       * ascs-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-1
     * Resource Group: ers-aha-rsc-group-name:
       * filesystem-rsc-nw-aha-ers (ocf::heartbeat:Filesystem):     Started nw-ha-vm-2
       * health-check-rsc-nw-ha-ers        (ocf::heartbeat:anything):       Started nw-ha-vm-2
       * vip-rsc-nw-aha-ers        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-2
       * ers-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started 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 dell'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:

   20.05.2021 01:33:25
   HAGetFailoverConfig
   OK
   HAActive: TRUE
   HAProductVersion: SUSE Linux Enterprise Server for SAP Applications 15 SP2
   HASAPInterfaceVersion: SUSE Linux Enterprise Server for SAP Applications 15 SP2 (sap_suse_cluster_connector 3.1.2)
   HADocumentation: https://www.suse.com/products/sles-for-sap/resource-library/sap-best-practices/
   HAActiveNode: nw-ha-vm-1
   HANodes: nw-ha-vm-1, nw-ha-vm-2

4. Come SID_LCadm, verifica la presenza di errori nella configurazione:

   > sapcontrol -nr INSTANCE_NUMBER -function HACheckConfig

   Dovresti vedere un output simile all'esempio seguente:

   20.05.2021 01:37:19
       HACheckConfig
       OK
       state, category, description, comment
       SUCCESS, SAP CONFIGURATION, Redundant ABAP instance configuration, 0 ABAP instances detected
       SUCCESS, SAP CONFIGURATION, Redundant Java instance configuration, 0 Java 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 (vh-ascs-aha_AHA_00), SAPInstance includes is-ers patch
       SUCCESS, SAP CONFIGURATION, Enqueue replication (vh-ascs-aha_AHA_00), Enqueue replication enabled
       SUCCESS, SAP STATE, Enqueue replication state (vh-ascs-aha_AHA_00), Enqueue replication active

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

      > sapcontrol -nr ASCS_INSTANCE_NUMBER -function HAFailoverToNode ""

   2. Come root, se segui il failover utilizzando crm_mon, dovresti vedere ASCS passare all'altro server, ERS fermarsi su quel server e ERS sull'altro server.

   Simula un failover

   Testa il cluster simulando un errore sull'host principale. Utilizza un sistema di test oppure esegui il test sul tuo sistema di produzione prima di rilasciarlo 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, in quanto convalida sia il failover che la scherma.

   1. Esegui il backup del sistema.

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

      # ip link set eth0 down

   3. Riconnettiti a un host utilizzando SSH e passa all'utente root.

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

      Cluster Summary:
      * Stack: corosync
      * Current DC: nw-ha-vm-2 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum
      * Last updated: Fri May 21 22:31:32 2021
      * Last change:  Thu May 20 20:36:36 2021 by ahaadm via crm_resource on nw-ha-vm-1
      * 2 nodes configured
      * 10 resource instances configured
      
      Node List:
      * Online: [ nw-ha-vm-1 nw-ha-vm-2 ]
      
      Full List of Resources:
      * fencing-rsc-nw-aha-vm-1     (stonith:fence_gce):     Started nw-ha-vm-2
      * fencing-rsc-nw-aha-vm-2     (stonith:fence_gce):     Started nw-ha-vm-1
      * Resource Group: scs-aha-rsc-group-name:
        * filesystem-rsc-nw-aha-scs (ocf::heartbeat:Filesystem):     Started nw-ha-vm-2
        * health-check-rsc-nw-ha-scs        (ocf::heartbeat:anything):       Started nw-ha-vm-2
        * vip-rsc-nw-aha-scs        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-2
        * scs-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-2
      * Resource Group: ers-aha-rsc-group-name:
        * filesystem-rsc-nw-aha-ers (ocf::heartbeat:Filesystem):     Started nw-ha-vm-1
        * health-check-rsc-nw-ha-ers        (ocf::heartbeat:anything):       Started nw-ha-vm-1
        * vip-rsc-nw-aha-ers        (ocf::heartbeat:IPaddr2):        Started nw-ha-vm-1
        * ers-aha-instance-rsc-name (ocf::heartbeat:SAPInstance):    Started nw-ha-vm-1

   Conferma che le voci di blocco vengono conservate

   Per confermare che le voci di blocco vengano conservate in un failover, seleziona prima la scheda della tua versione di Enqueue Server e segui la procedura per generare voci di blocco, simulare un failover e confermare che le voci di blocco vengano conservate dopo l'attivazione di ASCS.

   ENSA1

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

      > enqt pf=/PATH_TO_PROFILE/SID_UC_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 11 NUMBER_OF_LOCKS

   2. Come SID_LCadm, sul server in cui ASCS è attivo, verifica che le voci di blocco siano registrate:

      > 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 è attiva l'ERS, avvia la funzione di monitoraggio, OpCode=20, del programma enqt:

      > enqt pf=/PATH_TO_PROFILE/SID_UC_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 spostarla 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 interrompe, esci dal monitor inserendo Ctrl + c.

   6. Facoltativamente, come root su uno dei due server, monitora il failover del cluster:

      # crm_mon

   7. Dopo aver confermato che i blocchi sono stati conservati, rilasciali come SID_LCadm.

      > enqt pf=/PATH_TO_PROFILE/SID_UC_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 12 NUMBER_OF_LOCKS

   8. Come SID_LCadm, sul server in cui ASCS è attivo, verifica che le voci di blocco siano 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_UC_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME

   2. Come SID_LCadm, sul server in cui ASCS è attivo, verifica che le voci di blocco siano registrate:

      > 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 l'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 uno dei due server, monitora il failover del cluster:

      # crm_mon

   6. Come SID_LCadm, sul server in cui ASCS è stato riavviato, 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 in cui è attiva l'ERS, 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_UC_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME

   8. Come SID_LCadm, sul server in cui ASCS è attivo, verifica che le voci di blocco siano rimosse:

      > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

      Dovresti vedere un output simile al seguente esempio:

      locks_now: 0

   Simulare 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 prendono in considerazione la durata delle migrazioni attive. Se utilizzi valori più brevi nella configurazione del cluster, il rischio che la migrazione live possa attivare un failover è maggiore.

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

   1. Sul nodo principale, attiva un evento di manutenzione simulato utilizzando il seguente comando dell'interfaccia a riga di comando gcloud:

      # gcloud compute instances simulate-maintenance-event PRIMARY_VM_NAME

   2. Verifica che il nodo principale non cambi:

      # crm status

   Risolvere i problemi

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

   Raccogliere informazioni di diagnostica 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 necessarie e contatta l'assistenza clienti Google Cloud.

   Per raccogliere informazioni di diagnostica, consulta la sezione Cluster di alta disponibilità sulle informazioni di diagnostica SLES.

   Assistenza

   Per problemi con l'infrastruttura o i servizi Google Cloud, contatta l'assistenza clienti. Puoi trovare le informazioni di contatto nella pagina Panoramica dell'assistenza in Google Cloud Console. Se l'assistenza clienti stabilisce che un problema si trova nei tuoi sistemi SAP, ti verrà indirizzato all'assistenza SAP.

   Per problemi relativi al prodotto SAP, registra la tua richiesta di assistenza tramite l'assistenza SAP. SAP valuta il ticket di assistenza e, se sembra essere un problema relativo all'infrastruttura Google Cloud, trasferisce il ticket 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 e 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:

   • Ricevere assistenza per SAP su Google Cloud
   • Nota SAP 2456406 (è necessario un account utente SAP)

   Esecuzione delle attività post-deployment

   Prima di utilizzare il sistema SAP NetWeaver, ti consigliamo di eseguire il backup del tuo nuovo sistema SAP NetWeaver HA.

   Per ulteriori informazioni:

   • Guida operativa di SAP NetWeaver.

   Passaggi successivi

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

   • Best practice per SUSE
   • Guida alla pianificazione della disponibilità elevata per SAP NetWeaver su Google Cloud
   • Per ulteriori informazioni sull'amministrazione e il monitoraggio delle VM, consulta la guida alle operazioni di NetWeaver di SAP