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

Questa guida illustra come eseguire il deployment e configurare una campagna ottimizzata per Red Hat Enterprise Linux (RHEL) ad alta disponibilità (HA) per il sistema SAP NetWeaver.

Fatta eccezione per le procedure specifiche per l'accodamento autonomo Server 2 (ENSA2), disponibile solo in ABAP, questa guida si applica stack SAP NetWeaver ABAP e Java.

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

Se utilizzi uno stack Java, prima di utilizzare i comandi o gli esempi in questa guida, sostituisci eventuali istanze di "ASCS" con "SCS".

Questa guida illustra i passaggi per:

• Configura un bilanciatore del carico di rete passthrough interno per reinstradare il traffico nella evento di errore
• Configurazione di un cluster Pacemaker on RHEL per gestire il SAP sistemi e altre risorse durante un failover

Questa guida include anche i passaggi per la configurazione del sistema SAP NetWeaver per l'alta disponibilità, ma consulta la documentazione SAP per le istruzioni definitive.

Per informazioni sul deployment delle VM di Compute Engine per SAP NetWeaver che non è specifico per l'alta disponibilità, consulta SAP NetWeaver all'implementazione specifica per il tuo sistema operativo.

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

Questa guida è destinata agli utenti avanzati di SAP NetWeaver che conoscono Configurazioni Linux ad alta disponibilità per SAP NetWeaver.

Il sistema implementato da questa guida

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

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

• Due VM host, una per l'istanza ASCS attiva e una per istanza attiva del replicatore di accodamento ENSA2 o dell'accodamento ENSA1 Replication Server (ENSA1). Sono indicate le istanze ENSA2 e ENSA1 fino a ERS.
• Gestore delle risorse del cluster ad alta disponibilità Pacemaker.
• Un meccanismo di scherma robusto.
• Riavvio automatico dell'istanza non riuscita come nuova istanza secondaria.

Questa guida spiega come utilizzare i modelli di Cloud Deployment Manager fornite da Google Cloud per eseguire il deployment per garantire che le VM soddisfino la supportabilità SAP requisiti e a rispettare le best practice attuali.

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

Prerequisiti

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

• Hai letto Guida alla pianificazione di SAP NetWeaver e la Guida alla pianificazione dell'alta disponibilità per SAP NetWeaver su Google Cloud.
• Tu o la tua organizzazione disponete di un account Google Cloud e avete creato un progetto per il deployment di SAP NetWeaver. Per informazioni sulla creazione gli account e i progetti Google Cloud, vedi Creazione di un progetto nella Guida al deployment di SAP NetWeaver per Linux.
• Se hai bisogno che il tuo carico di lavoro SAP venga eseguito in conformità con la residenza dei dati, controllo dell'accesso, personale o requisiti normativi, devi creare i necessari Cartella Assured Workloads. Per ulteriori informazioni, consulta Conformità e controlli di sovranità per SAP su Google Cloud.

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

  • Configurare i nomi DNS per il progetto o le istanze
  • Esecuzione di query sui metadati personalizzati
  • Impostazione di 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 sia abilitato nei metadati di progetto, devi disabilitare OS Login temporaneamente fino al completamento del deployment. Per il 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 e questo deployment non riesce. Al termine del deployment, puoi abilitare di nuovo OS Login.

  Per ulteriori informazioni, vedi:

  • Attivare o disattivare 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 consigli:

.
• Utilizza un gateway NAT.
• Crea regole firewall che bloccano tutti gli accessi esterni non necessari.
• Quando crei le tue VM:
  • Specifica un tag di rete per ogni VM da utilizzare nel routing e nel firewall le regole del caso. Se usi Deployment Manager fornito da Google Cloud, specifica un tag networkTag: [TAG].
  • Crea le VM senza un IP esterno. Se utilizzi i modelli Deployment Manager che Google Cloud fornisce, specifica publicIP: No.

Informazioni correlate da RHEL

Ad eccezione di dove richiesto per l'ambiente Google Cloud, informazioni riportate in questa guida sono coerenti con quanto segue: guide correlate di Red Hat e SAP:

• Configura SAP NetWeaver ASCS/ERS ENSA1 con risorse autonome in RHEL 7.5 e versioni successive e RHEL 8
• Configura SAP S/4HANA ASCS/ERS con accodamento autonomo 2 (ENSA2) in Pacemaker
• SAP Note 2002167 - Red Hat Enterprise Linux 7.x: Installazione e upgrade
• SAP Note 2772999 - Red Hat Enterprise Linux 8.x: Installazione e configurazione
• SAP Note 3108316 - Red Hat Enterprise Linux 9.x: Installazione e configurazione
• SAP Note 2641322 - Installazione di ENSA2 e aggiornamento da ENSA1 a ENSA2 quando si utilizzano le soluzioni Red Hat HA per SAP

Creare una rete

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

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

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

Per configurare il networking:

Console

1. Nella console Google Cloud, 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 le 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 subnet:
   .
   1. Inserisci un nome per la subnet.
   2. In Regione, seleziona Regione di Compute Engine in cui in cui vuoi creare la subnet.
   3. Per Tipo di stack IP, seleziona IPv4 (stack singolo) e inserisci un IP dell'intervallo di indirizzi Formato CIDR, ad esempio 10.1.0.0/24.

      Si tratta della principale Intervallo IPv4 per la subnet. Se prevedi di aggiungere più di una subnet, assegnare intervalli IP CIDR non sovrapposti per ciascuna subnet nella rete. Tieni presente che ogni subnet e i relativi intervalli IP interni sono mappati a un regione.

   4. Fai clic su Fine.
6. Per aggiungere altre subnet, fai clic su Aggiungi subnet e ripeti i passaggi precedenti. Puoi aggiungere più subnet alla rete dopo aver creato la rete.
7. Fai clic su Crea.

gcloud

1. Vai a Cloud Shell.

   Vai a Cloud Shell

2. Per creare una nuova rete in modalità subnet personalizzate, esegui:

   gcloud compute networks create NETWORK_NAME --subnet-mode custom

   Sostituisci NETWORK_NAME con il nome della nuova rete. La devono rispettare le 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, crea automaticamente una subnet in ogni regione di Compute Engine. Per ulteriori informazioni informazioni, consulta Modalità di creazione subnet.

3. Crea una subnet e specifica la regione e l'intervallo IP:

   gcloud compute networks subnets create SUBNETWORK_NAME \
       --network NETWORK_NAME --region REGION --range RANGE

   Sostituisci quanto segue:

   • SUBNETWORK_NAME: il nome della nuova subnet
   • NETWORK_NAME: il nome della rete che hai creato nella passaggio precedente
   • REGION: il valore region dove vuoi che la subnet
   • RANGE: l'intervallo di indirizzi IP, specificato in formato CIDR, come 10.1.0.0/24

     Se prevedi di aggiungere più di una subnet, assegna che non si sovrappongano a intervalli IP CIDR per ogni subnet nella rete. Tieni presente che ciascuna subnet e i relativi intervalli IP interni sono mappati a una singola regione.

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

Configurazione di un gateway NAT

Se devi creare una o più VM senza indirizzi IP pubblici, devi utilizzare la rete traduzione degli indirizzi (NAT) per consentire alle VM di accedere a internet. Utilizza Cloud NAT, uno strumento Servizio gestito distribuito e software-defined di Google Cloud che consente alle VM di inviare messaggi in uscita di pacchetti a internet e ricevono i corrispondenti 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 vengono eseguiti in contemporanea processi che potrebbero superare il valore predefinito di Cloud NAT per il numero di porte, causare errori di attivazione o di download.

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

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

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

aggiungi regole firewall

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

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

Crea regole firewall per consentire l'accesso a:

• Le porte predefinite utilizzate da SAP NetWeaver, come documentato in Porte TCP/IP di tutti i prodotti SAP.
• Le connessioni dal computer o dall'ambiente di rete aziendale al tuo di un'istanza VM di Compute Engine. Se hai dubbi sull'indirizzo IP da utilizzare, contatta l'amministratore di rete della tua azienda.
• Comunicazione tra le VM in un ambiente a 3 livelli, con scale out o ad alta disponibilità configurazione. Ad esempio: se esegui il deployment di un sistema a 3 livelli, avrai almeno 2 VM nella tua subnet: la VM per SAP NetWeaver e un'altra VM per il server di database. Per abilitare la comunicazione tra le due VM, devi creare una regola firewall per consentire il traffico proveniente dalla subnet.
• Controlli di integrità di Cloud Load Balancing. Per ulteriori informazioni, vedi Crea una regola firewall per i controlli di integrità.

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

Per creare una regola firewall:

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

   Vai a Firewall

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

   • Nel campo Rete, seleziona la rete in cui si trova la VM individuarlo.
   • Nel campo Destinazioni, seleziona Tutte le istanze nella rete.
   • Nel campo Filtro di origine, seleziona una delle seguenti opzioni:
     .
     • Intervalli IP per consentire il traffico in entrata da indirizzi IP specifici. Specifica l'intervallo di indirizzi IP nel campo IP di origine intervalli di tempo.
     • Subnet per consentire il traffico in entrata da una determinata una subnet. Specifica il nome della subnet nel subnets. Puoi utilizzare questa opzione per consentire l'accesso a le VM in una configurazione a 3 livelli o scale out.
   • Nella sezione Protocolli e porte, seleziona Protocolli e porte specificati porte 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 della VM che fungerà da server principale e secondario di nodi nel tuo cluster ad alta disponibilità.

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

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

Una volta eseguito il deployment delle VM, installa SAP NetWeaver e del cluster ad alta disponibilità.

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

1. Apri Cloud Shell.

   Vai a Cloud Shell

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

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

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

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

5. Nel modello del file di configurazione YAML, definisci la prima istanza VM. Tu definisci la seconda istanza VM nel passaggio successivo dopo .

   Specifica i valori delle proprietà sostituendo le parentesi e i relativi contenuti con i valori relativi alla tua installazione. Le proprietà sono descritte nella tabella seguente. Ad esempio, di un file di configurazione completato, consulta Esempio di un file YAML completo di configurazione del deployment.

   Proprietà	Tipo di dati	Descrizione
   name	Stringa	Un nome arbitrario che identifica la risorsa di deployment che definito dal seguente insieme di proprietà.
   type	Stringa	Specifica la posizione, il tipo e la versione Modello di Deployment Manager da utilizzare durante il deployment. Il file YAML include due specifiche type, uno dei quali viene commentato. La specifica type attiva per impostazione predefinita specifica la versione del modello come latest. La specifica type che è oggetto di commenti specifica una specifica versione del modello con un timestamp. Se hai bisogno che tutti i tuoi deployment utilizzino lo stesso modello usa la specifica type che include timestamp.
   instanceName	Stringa	Il nome dell'istanza VM che stai definendo. Specifica con nomi diversi nelle definizioni di VM primarie e secondarie. Valuta la possibilità di utilizzare nomi che identificano le istanze come appartenenti nello stesso cluster ad alta disponibilità. I nomi delle istanze devono contenere al massimo 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 un tipo di istanza per la VM principale e quella secondaria. Se hai bisogno di un tipo di VM personalizzata, specifica tipo di VM predefinito e al termine del deployment, personalizza la VM dell'oggetto o eliminare definitivamente una versione archiviata, in base alle necessità.
   zone	Stringa	La zona Google Cloud in cui eseguire il deployment della VM che stai definendo. Specifica zone diverse nella stessa regione per la VM principale e quella secondaria le tue definizioni. Le zone devono trovarsi nella stessa regione selezionato 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 stai utilizzando con SAP NetWeaver. Per specificare un'immagine: famiglia, aggiungi il prefisso family/ al cognome. Per ad esempio family/rhel-8-4-sap-ha. Per l'elenco le famiglie di immagini disponibili, consulta Immagini nella console Google Cloud.
   linuxImageProject	Stringa	Il progetto Google Cloud che contiene l'immagine che useremo. Potrebbe essere un tuo progetto o Progetto immagine Google Cloud rhel-sap-cloud. Per un elenco dei progetti immagine di Google Cloud, consulta Immagini della documentazione di Compute Engine.
   usrsapSize	Numero intero	Le dimensioni del disco /usr/sap. Le dimensioni minime è di 8 GB.
   sapmntSize	Numero intero	Le dimensioni del disco /sapmnt. Le dimensioni minime è di 8 GB.
   swapSize	Numero intero	La dimensione del volume di scambio. La dimensione minima è 1 GB.
   networkTag	Stringa	Facoltativo. Uno o più tag di rete separati da virgole rappresenta l'istanza VM ai fini del firewall o del routing. Per le configurazioni ad alta disponibilità, specifica un tag di rete da utilizzare per una regola firewall che consenta la comunicazione nodi cluster e un tag di rete da usare in una regola firewall che consente a Cloud Load Balancing di integrità per accedere ai nodi del cluster. Se specifichi publicIP: No e non specifichi un tag di rete, assicurati di fornire un altro mezzo di accesso su internet.
   serviceAccount	Stringa	Facoltativo. Specifica un account di servizio personalizzato da utilizzare per di una VM di cui è stato eseguito il deployment. L'account di servizio deve includere le autorizzazioni durante il deployment per configurare la VM per SAP. Se serviceAccount non è specificato, il valore predefinito Viene utilizzato l'account di servizio Compute Engine. Specifica l'indirizzo completo dell'account di servizio. Ad esempio: [e-mail]
   publicIP	Booleano	Facoltativo. Determina se viene aggiunto un indirizzo IP pubblico dell'istanza VM. Il valore predefinito è Yes. Nota: non specificare No a meno che tu non abbia configurato un gateway NAT un tag di rete definito per la VM oppure se hai fornito VM con un'altra route a internet. Se non è disponibile un percorso per internet, l'installazione non va a buon fine.
   sap_deployment_debug	Booleano	Facoltativo. Se questo valore è impostato su Yes, il valore il deployment genera log di deployment dettagliati. Non attivare attiva, a meno che un tecnico del servizio di assistenza Google non ti chieda di abilitare il debug del machine learning.

6. Nel file di configurazione YAML, crea la definizione della seconda VM copiando la definizione della prima VM per incollare la copia dopo la prima definizione. Per un esempio, vedi Esempio di un file di configurazione YAML completo.

7. Nella definizione della seconda VM, specifica valori diversi per il valore seguenti proprietà rispetto a quelle specificate 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 e deployment continuo.
   • TEMPLATE_NAME rappresenta il nome del tuo di configurazione YAML.

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

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

Esempio di un file di configurazione YAML completo

L'esempio seguente mostra un file di configurazione YAML completato che esegue il deployment di due istanze VM per una configurazione ad alta disponibilità per SAP NetWeaver usando l'ultima versione di Deployment Manager modelli di machine learning. Nell'esempio vengono omessi i commenti contenuti nel modello quando per prima cosa scaricalo.

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

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

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

resources:
- name: sap_nw_node_1
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/sap_nw.py
  properties:
    instanceName: nw-ha-vm-1
    instanceType: n2-standard-4
    zone: us-central1-b
    subnetwork: example-sub-network-sap
    linuxImage: family/rhel-8-4-sap-ha
    linuxImageProject: rhel-sap-cloud
    usrsapSize: 15
    sapmntSize: 15
    swapSize: 24
    networkTag: cluster-ntwk-tag,allow-health-check
    serviceAccount: [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/rhel-8-4-sap-ha
    linuxImageProject: rhel-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 lo hai già fatto, crea regole firewall che consentano l'accesso a ogni VM host dalle seguenti origini:

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

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

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

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

Assicurati che le regole firewall per la verifica del deployment e per le comunicazioni tra cluster vengono create prima di procedere con la . Per le istruzioni, consulta Aggiungere regole firewall.

Verifica del deployment delle VM

Prima di installare SAP NetWeaver o di iniziare a configurare il cluster ad alta disponibilità, per verificare che il deployment delle VM sia stato eseguito correttamente controllando i log e Mapping dello spazio di archiviazione del sistema operativo.

Controlla i log

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

   Nota: il completamento di questo passaggio in Cloud Logging potrebbe comportare dei costi. Per ulteriori informazioni, vedi Prezzi di Cloud Logging.

   Vai a Cloud Logging

2. Filtra i log:

   Esplora log

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

   2. Nel menu a discesa Risorsa, seleziona Globale, quindi 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 Visualizzatore log legacy, dal menu del selettore di base, seleziona Globale come risorsa di logging.

3. Analizza i log filtrati:

   • Se viene visualizzato "--- Finished", il parametro l'elaborazione del deployment è completa vai al passaggio successivo.

   • Se visualizzi un errore di quota:

     1. Nella piattaforma IAM e Amministratore Quote aumenta le quote che non soddisfano I requisiti SAP NetWeaver elencati nella Guida alla pianificazione di SAP NetWeaver.

     2. In Deployment Manager Deployment elimina il deployment per ripulire le VM dell'installazione non riuscita.

     3. Esegui di nuovo il deployment.

Controlla la configurazione delle VM

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

   1. Se non l'hai ancora fatto, crea una regola firewall per consentire una connessione SSH sulla porta 22.

   2. Vai alla pagina Istanze VM.

      Vai a Istanze VM

   3. Connettiti a ogni istanza VM facendo clic sul pulsante SSH nella per ogni istanza VM, oppure puoi utilizzare metodo SSH preferito.

      

2. Visualizza il file system:

   ~> df -h

   Assicurati che venga visualizzato un output simile al seguente:

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

3. Verifica che lo spazio di scambio sia stato creato:

   ~> cat /proc/meminfo | grep Swap

   Vedrai risultati simili all'esempio seguente:

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

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

1. Correggi l'errore.
2. Nella sezione Deployment elimina il deployment per ripulire le VM e i dischi permanenti dell'installazione non riuscita.
3. Esegui di nuovo il deployment.

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

Dopo aver confermato che il deployment delle VM è stato eseguito correttamente, abilita il backend comunicazione tra le VM che verranno usate da nodi nel cluster ad alta disponibilità.

Puoi abilitare la comunicazione backend tra le VM modificando configurazione di google-guest-agent, che è inclusa nel Ambiente guest Linux per tutte le immagini pubbliche Linux fornite da Google Cloud.

Per abilitare le comunicazioni back-end del bilanciatore del carico, segui questi passaggi su ogni VM che fa parte del tuo cluster:

1. Interrompi l'agente:

   sudo service google-guest-agent stop

2. Apri o crea il file /etc/default/instance_configs.cfg per la modifica. Ad esempio:

   sudo vi /etc/default/instance_configs.cfg

3. Nel file /etc/default/instance_configs.cfg, specifica quanto segue di configurazione come mostrato. Se le sezioni non esistono, creale. In particolare, assicurati che target_instance_ips e Le proprietà ip_forwarding sono impostate su false:

   [IpForwarding]
   ethernet_proto_id = 66
   ip_aliases = true
   target_instance_ips = false
   
   [NetworkInterfaces]
   dhclient_script = /sbin/google-dhclient-script
   dhcp_command =
   ip_forwarding = false
   setup = true
   

4. Avvia il servizio di agente ospite:

   sudo service google-guest-agent start

La configurazione del controllo di integrità del bilanciatore del carico richiede porta di destinazione per il controllo di integrità e un'assegnazione dell'IP virtuale a riga di comando. Per saperne di più, consulta Testare la configurazione del bilanciatore del carico.

Configura le chiavi SSH sulla VM principale e su quella secondaria

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

I modelli di Deployment Manager che Google Cloud genera automaticamente una chiave, ma puoi sostituirla con una chiave generati, se necessario.

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

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

• Trasferisci file più piccoli attraverso la workstation locale utilizzando Le opzioni dei menu Carica file e Scarica file di Cloud Shell. Vedi Gestire i file con Cloud Shell.
• Scambiare file utilizzando un bucket Cloud Storage. Consulta Caricamenti e download.
• Usa una soluzione di archiviazione file come Filestore NetApp Cloud Volumes Service per creare una cartella condivisa. Consulta Soluzioni per la condivisione di file.

Per abilitare le connessioni SSH tra le istanze principali e secondarie, segui questa procedura. I passaggi presuppongono che venga utilizzata la chiave SSH viene generato dai modelli di Deployment Manager con SAP.

1. Sulla VM host principale:

   1. Connettiti alla VM tramite SSH.

   2. Passa alla directory principale:

      $ sudo su -

   3. Verifica che la chiave SSH esista:

      # ls -l /root/.ssh/

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

      -rw-r--r-- 1 root root  569 May  4 23:07 authorized_keys
      -rw------- 1 root root 2459 May  4 23:07 id_rsa
      -rw-r--r-- 1 root root  569 May  4 23:07 id_rsa.pub

   4. Aggiorna i metadati della VM principale con informazioni sull'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 a quello secondario:

      # ssh SECONDARY_VM_NAME

2. Sulla VM host secondaria:

   1. Accedi tramite SSH alla VM.

   2. Passa alla directory principale:

      $ sudo su -

   3. Verifica che la chiave SSH esista:

      # ls -l /root/.ssh/

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

      -rw-r--r-- 1 root root  569 May  4 23:07 authorized_keys
      -rw------- 1 root root 2459 May  4 23:07 id_rsa
      -rw-r--r-- 1 root root  569 May  4 23:07 id_rsa.pub

   4. Aggiorna i metadati della VM secondaria con informazioni sulla chiave SSH per la VM principale.

      # gcloud compute instances add-metadata PRIMARY_VM_NAME \
      --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \
      --zone PRIMARY_VM_ZONE

      # cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

   5. Verifica che le chiavi SSH siano configurate correttamente aprendo una connessione SSH dal sistema secondario a quello principale.

      # ssh PRIMARY_VM_NAME

Imposta l'archiviazione condivisa dei file e configura le directory condivise

Devi configurare una soluzione di condivisione file NFS che offra disponibilità elevata uno spazio di archiviazione file condiviso a cui possono accedere entrambi i nodi del tuo cluster ad alta disponibilità. Tu e poi creare directory su entrambi i nodi che vengono mappate allo spazio di archiviazione dei file condiviso. La del cluster privato garantisce che le directory appropriate siano montate solo le istanze corrette.

La configurazione di una soluzione di condivisione file non è trattata in questa guida. Per istruzioni su come configurare il sistema di condivisione file, consulta le istruzioni fornita dal fornitore della soluzione selezionata. Se scegli di utilizzare Filestore per la tua soluzione di condivisione file, ti consigliamo di utilizzare Livello Enterprise di Filestore. Scopri come creare un file Filestore consulta l'istanza Creazione di istanze.

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

Per configurare le directory condivise:

1. Se non hai già configurato un file condiviso NFS ad alta disponibilità soluzione di archiviazione, fallo ora.

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

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

   Sostituisci NFS_PATH con il percorso del file NFS una soluzione condivisa. Ad esempio, 10.49.153.26:/nfs_share_nw_ha.

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

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

   Sostituisci quanto segue:

   • SID: l'ID sistema SAP (SID). Utilizza lettere maiuscole per scrivere una lettera. Ad esempio, AHA.
   • ASCS_INSTANCE_NUMBER: il numero di istanza di il sistema ASCS. Ad esempio, 00.
   • ERS_INSTANCE_NUMBER: il numero di istanza di il sistema ERS. Ad esempio, 10.

4. Crea i punti di montaggio necessari su entrambi i server:

   ~> sudo mkdir -p /sapmnt/SID
   ~> sudo mkdir -p /usr/sap/trans
   ~> sudo mkdir -p /usr/sap/SID/ASCSASCS_INSTANCE_NUMBER
   ~> sudo mkdir -p /usr/sap/SID/ERSERS_INSTANCE_NUMBER

5. Configura autofs per montare le directory comuni dei file condivisi al primo accesso alle directory dei file. Il montaggio dei modelli ASCSASCS_INSTANCE_NUMBER e ERSERS_INSTANCE_NUMBER directory è gestite dal software del cluster, che configurerai in un passaggio successivo.

   Modifica le opzioni NFS nei comandi in base alle tue esigenze per la condivisione di file.

   Configura autofs su entrambi i server:

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

   Per ulteriori informazioni su autofs, consulta l'articolo Autofs - Come funziona.

6. Avvia il servizio autofs su entrambi i server:

   ~> sudo systemctl enable autofs
   ~> sudo systemctl restart autofs
   ~> sudo automount -v

7. Attiva autofs per montare le directory condivise accedendo a ciascuna utilizzando il comando cd. Ad esempio:

   ~> cd /sapmnt/SID
   ~> cd /usr/sap/trans
   

8. Dopo aver eseguito l'accesso a tutte le directory, esegui il comando df -Th per confermare che le directory sono montate.

   ~> df -Th | grep FILE_SHARE_NAME

   Sostituisci FILE_SHARE_NAME con il nome del tuo di condivisione file NFS. Ad esempio, nfs_share_nw_ha.

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

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

Configurare il supporto per il failover di Cloud Load Balancing

Il servizio bilanciatore del carico di rete passthrough interno con supporto del failover instrada l'ASCS e il traffico ERS verso le istanze attive di ognuna in un cluster SAP NetWeaver. I bilanciatori del carico di rete passthrough interni utilizzano un IP virtuale (VIP), servizi di backend, gruppi di istanze e controlli di integrità per instradare il traffico in modo appropriato.

Prenota gli indirizzi IP per gli IP virtuali

Per un cluster SAP NetWeaver ad alta disponibilità, devi creare due VIP, chiamate a volte fluttuanti. e gli indirizzi IP esterni. Un VIP segue l'istanza SAP Central Services (SCS) attiva e l'altro segue l'istanza ERS (Enqueue Replication Server). Il carico bilanciatore del carico instrada il traffico inviato a ogni VIP alla VM attualmente che ospita 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 di ASCS e per il VIP di l'ERS. Per ASCS, l'indirizzo IP è l'indirizzo IP utilizzato dalle applicazioni per accedere a SAP NetWeaver. Per ERS, l'indirizzo IP è l'indirizzo IP che viene utilizzato per la replica del server di coda. Se ometti il parametro --addresses, un indirizzo IP nella subnet specificata sarà scelti per te:

   ~ 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 il Regione Google Cloud in cui si trova il cluster. Ad esempio, us-central1
   • CLUSTER_SUBNET: specifica la subnet che stai utilizzando con il tuo cluster. Ad esempio: example-sub-network-sap.
   • ASCS_VIP_ADDRESS: se vuoi, specifica un valore Indirizzo IP per l'IP virtuale ASCS in notazione CIDR. Ad esempio: 10.1.0.2.
   • ERS_VIP_NAME: specifica un nome per l'indirizzo IP virtuale dell'istanza ERS. Ad esempio: ers-aha-vip.
   • ERS_VIP_ADDRESS: se vuoi, specifica un valore Indirizzo IP per l'IP virtuale ERS in notazione CIDR. Ad esempio: 10.1.0.4.

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

3. Conferma 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 sia per le VM che per i VIP nel file /etc/hosts di ciascuna VM.

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

Gli aggiornamenti al file /etc/hosts dovrebbero essere simili ai seguenti esempio:

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

crea i controlli di integrità di Cloud Load Balancing

Crea i controlli di integrità: uno per l'istanza ASCS attiva e uno per 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 ed ERS nell'intervallo privato, 49152-65535. I valori di intervallo di controllo e di timeout nei seguenti comandi sono leggermente più lunghi dei valori predefiniti, quindi per aumentare la tolleranza di failover durante le istanze live di Compute Engine degli eventi di migrazione. 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 nel che consente l'accesso alle VM host dagli intervalli IP che vengono utilizzati dai controlli di integrità di Cloud Load Balancing, 35.191.0.0/16 130.211.0.0/22. Per saperne di più sulle regole firewall per i bilanciatori del carico, consulta Creazione di regole firewall per i controlli di integrità.

1. Se non ne hai già uno, aggiungi un tag di rete alle VM host. Questo Il tag di rete è 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 l'integrità controlli:

   ~ 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 un nodo cluster VM e aggiungi la VM in quella zona al gruppo di istanze.

1. In Cloud Shell, crea il gruppo di istanze principale e aggiungi dalla 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 dalla 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 gruppi di istanze a ciascun servizio di backend, designando il gruppo di istanze come gruppo di istanze di failover in ogni servizio di backend. Infine, crea le regole di forwarding dai VIP ai servizi di backend.

1. In Cloud Shell, crea il servizio di backend e il failover gruppo 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 principali al servizio di backend ASCS:

      ~ gcloud compute backend-services add-backend ASCS_BACKEND_SERVICE_NAME \
        --instance-group PRIMARY_IG_NAME \
        --instance-group-zone PRIMARY_ZONE \
        --region CLUSTER_REGION

   3. Aggiungi il gruppo di istanze secondarie come gruppo di istanze di failover per il servizio di backend ASCS:

      ~ gcloud compute backend-services add-backend ASCS_BACKEND_SERVICE_NAME \
        --instance-group SECONDARY_IG_NAME \
        --instance-group-zone SECONDARY_ZONE \
        --failover \
        --region CLUSTER_REGION

2. In Cloud Shell, crea il servizio di backend e il failover per ERS:

   1. Crea il servizio di backend per l'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 principali come gruppo di istanze di failover per il servizio di backend ERS:

      ~ gcloud compute backend-services add-backend ERS_BACKEND_SERVICE_NAME \
        --instance-group PRIMARY_IG_NAME \
        --instance-group-zone PRIMARY_ZONE \
        --failover \
        --region CLUSTER_REGION

3. Facoltativamente, conferma che i servizi di backend contengano l'istanza gruppi come previsto:

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

   Dovresti vedere un output simile all'esempio seguente per il backend ASCS completamente gestito di Google Cloud. Per ERS, failover: true verrebbe visualizzato nell'istanza principale gruppo:

   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 ASCS e Servizi di backend 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 gruppi di istanza di backend non verranno registrati come integri finché ha completato la configurazione del cluster Pacemaker.

Testa la configurazione del bilanciatore del carico

Anche se i gruppi di istanza di backend non verranno registrati come integri fino a puoi testare la configurazione del bilanciatore del carico configurando un listener che risponda ai controlli di integrità. Dopo la configurazione un listener, se il bilanciatore del carico è configurato correttamente, Lo stato dei gruppi di istanza di backend diventa integro.

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

Test del bilanciatore del carico con l'utilità socat

Puoi utilizzare l'utilità socat per ascoltare temporaneamente un controllo di integrità una porta.

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

   $ sudo yum install socat

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

   ip addr add VIP_ADDRESS dev eth0

3. Sulla VM principale, avvia un processo socat in cui rimanere in ascolto per 60 secondi porta per il controllo di integrità ASCS:

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

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

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

   Dovresti vedere un output simile al seguente esempio per ASCS:

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

5. Rimuovi il VIP dall'interfaccia eth0:

   ip addr del VIP_ADDRESS dev eth0

6. Ripeti i passaggi per l'ERS, sostituendo i valori delle variabili ASCS con Valori ERS.

Test del bilanciatore del carico utilizzando la porta 22

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

Per utilizzare temporaneamente la porta 22:

1. Nella console Google Cloud, vai a Compute Engine Pagina Controlli di integrità:

   Vai a Controlli di integrità

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

3. Fai clic su Modifica.

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

5. Fai clic su Salva e attendi un minuto o due.

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

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

   Dovresti vedere un output simile al seguente:

   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instanceGroups/sap-aha-primary-instance-group
   status:
     healthStatus:
     - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
       forwardingRuleIp: 10.1.0.85
       healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-b/instances/nw-ha-vm-1
       ipAddress: 10.1.0.79
       port: 80
     kind: compute#backendServiceGroupHealth
   ---
   backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/sap-aha-secondary-instance-group
   status:
     healthStatus:
     - forwardingRule: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/forwardingRules/scs-aha-forwarding-rule
       forwardingRuleIp: 10.1.0.85
       healthState: HEALTHY
       instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/nw-ha-vm-2
       ipAddress: 10.1.0.78
       port: 80
     kind: compute#backendServiceGroupHealth

7. Al termine, reimposta il numero di porta del controllo di integrità originale numero di porta.

Installa listener per i controlli di integrità

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

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

Installa un listener su ogni host nel cluster completando quanto segue passaggi:

1. Come root, installa un semplice listener TCP. Queste istruzioni installare e utilizzare HAProxy come listener.

   # yum install haproxy

2. Copia e rinomina il file di configurazione predefinito di haproxy.cfg per renderlo un file modello per le diverse istanze haproxy:

   # cp /usr/lib/systemd/system/haproxy.service \
       /etc/systemd/system/haproxy@.service
   

3. Modifica le sezioni [Unit] e [Service] di haproxy@.service per includere il parametro di istanza %i, come mostrato in nell'esempio seguente:

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

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

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

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

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

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

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

6. Crea un file di configurazione haproxy.cfg per l'istanza ERS. Ad esempio:

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

7. Nel file di configurazione ERS di haproxy-SIDers.cfg, inserisci la macro la configurazione seguente e sostituisci ERS_HEALTHCHECK_PORT_NUM con il numero di porta che hai specificato al momento della creazione Controllo di integrità di Compute Engine per ERS precedente:

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

8. Ricarica i servizi systemd:

   # systemctl daemon-reload

9. Verifica che il servizio haproxy sia configurato correttamente:

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

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

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

10. Ripeti i passaggi precedenti su ciascun host nel cluster.

Configura Pacemaker

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

La procedura si basa sulla documentazione di Red Hat per la configurazione ad alta disponibilità, incluse le seguenti pubblicazioni (una l'abbonamento a Red Hat è obbligatorio):

• Configurazione di SAP NetWeaver ASCS/ERS ENSA1 con risorse autonome in RHEL 7.5+ e RHEL 8
• Configurazione di ASCS/ERS SAP S/4HANA con server accoda autonomo 2 (ENSA2) in Pacemaker

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

• SAP Note 3108316 - Red Hat Enterprise Linux 9.x: Installazione e configurazione
• SAP Note 2772999 - Red Hat Enterprise Linux 8.x: Installazione e configurazione
• SAP Note 2002167 - Red Hat Enterprise Linux 7.x: Installazione e upgrade

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

Come root sia sull'host principale che su quello secondario, installa e aggiorna pacchetti cluster richiesti, configura hacluster e configura il sistema operativo completamente gestito di Google Cloud.

1. Installa i seguenti pacchetti di cluster richiesti:

   # yum install pcs pacemaker
   # yum install fence-agents-gce
   # yum install resource-agents-gcp
   # yum install resource-agents-sap
   # yum install sap-cluster-connector

2. Aggiorna i pacchetti installati:

   # yum update -y

3. Imposta la password per l'utente hacluster, che è installata nell'ambito di cluster Kubernetes:

   # passwd hacluster

4. Specifica una password per hacluster quando richiesto.

5. Nelle immagini RHEL fornite da Google Cloud, il sistema operativo il servizio firewall è attivo per impostazione predefinita. configura il servizio firewall per consentire il traffico ad alta disponibilità:

   # firewall-cmd --permanent --add-service=high-availability

   # firewall-cmd --reload

6. Avvia il servizio PC e configuralo in modo che venga avviato al momento dell'avvio:

   # systemctl start pcsd.service
   # systemctl enable pcsd.service

7. Controlla lo stato del servizio PC:

   # systemctl status pcsd.service

   Dovresti vedere un output simile al seguente:

   ● pcsd.service - PCS GUI and remote configuration interface
     Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled)
     Active: active (running) since Sat 2020-06-13 21:17:05 UTC; 25s ago
       Docs: man:pcsd(8)
             man:pcs(8)
   Main PID: 31627 (pcsd)
     CGroup: /system.slice/pcsd.service
             └─31627 /usr/bin/ruby /usr/lib/pcsd/pcsd
   Jun 13 21:17:03 hana-ha-vm-1 systemd[1]: Starting PCS GUI and remote configuration interface...
   Jun 13 21:17:05 hana-ha-vm-1 systemd[1]: Started PCS GUI and remote configuration interface.

Crea il cluster

1. Come utente root su uno dei due nodi, autorizza l'utente hacluster. Fai clic sulla scheda la versione RHEL per vedere il comando:

   RHEL 8 e versioni successive

   # pcs host auth PRIMARY_VM_NAME SECONDARY_VM_NAME

   RHEL 7

   # pcs cluster auth PRIMARY_VM_NAME SECONDARY_VM_NAME

2. Quando richiesto, inserisci il nome utente hacluster e la password impostato per l'utente hacluster.

3. Crea il cluster:

   RHEL 8 e versioni successive

   # pcs cluster setup CLUSTER_NAME PRIMARY_VM_NAME SECONDARY_VM_NAME

   RHEL 7

   # pcs cluster setup --name CLUSTER_NAME PRIMARY_VM_NAME SECONDARY_VM_NAME

Aggiorna i file di configurazione di Corosync

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

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

   # vi /etc/corosync/corosync.conf

2. Nella sezione totem del file corosync.conf, imposta il campo nel seguente esempio estratto ai valori visualizzati. È possibile che alcuni parametri siano già impostati sui valori corretti:

   RHEL 8

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

   RHEL 7

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

3. Sincronizza la configurazione sul secondo server:

   RHEL 8 e versioni successive

   # pcs cluster sync corosync

   RHEL 7

   # pcs cluster sync

4. Dalla VM principale, abilita e avvia il cluster

   # pcs cluster enable --all
   # pcs cluster start --all

5. Verifica che le nuove impostazioni di corosync siano attive nel cluster utilizzando l'utilità corosync-cmapctl:

   # corosync-cmapctl

6. Controlla lo stato del cluster:

   # pcs status

   Dovresti vedere un output simile all'esempio seguente:

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

Configura le risorse del cluster per l'infrastruttura

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

• Il dispositivo di recinzione, che previene gli scenari di tipo "cervello spaccato"
• Directory ASCS ed ERS nel file system condiviso
• I controlli di integrità
• VIP
• Componenti ASCS ed ERS

Sei tu a definire le risorse per il dispositivo di recinzione, il file system condiviso, i controlli di integrità e i VIP. Quindi installerai SAP NetWeaver. Dopo il giorno SAP NetWeaver è installato, puoi finalmente definire le risorse del cluster i componenti ASCS ed ERS.

Allestisci recinzioni

Per configurare la fencing devi definire una risorsa cluster con fence_gce per ogni VM host.

Per garantire la corretta sequenza degli eventi dopo un'azione di scherma, devi anche configurare il sistema operativo in modo che ritarda il riavvio di Corosync dopo una VM è recintato. Puoi anche regolare il timeout del pacemaker per i riavvii nell'account per il ritardo.

Nota: il parametro pcmk_delay_max=30 deve essere configurato solo su una risorsa del dispositivo di fencing.

Crea le risorse del dispositivo di recinzione

Per ogni VM nel cluster, crea una risorsa cluster in modo che il cluster possa riavviare la VM. Il dispositivo di recinzione di una VM deve essere eseguito su una VM diversa, quindi configuri la località della risorsa del cluster da eseguire su qualsiasi VM tranne la VM che può riavvia.

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

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

2. Configura la località del dispositivo di recinzione per la VM principale in modo che è attivo solo sulla VM secondaria:

   # pcs constraint location FENCING_RESOURCE_PRIMARY_VM avoids PRIMARY_VM_NAME

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

   # pcs stonith create FENCING_RESOURCE_SECONDARY_VM fence_gce \
       port="SECONDARY_VM_NAME" \
       zone="SECONDARY_ZONE" \
       project="CLUSTER_PROJECT_ID" \
       pcmk_reboot_timeout=300 pcmk_monitor_retries=4 \
       op monitor interval="300s" timeout="120s" \
       op start interval="0" timeout="60s"

4. Configura la località del dispositivo di recinzione per la VM secondaria in modo che che sia attiva solo sulla VM principale:

   # pcs constraint location FENCING_RESOURCE_SECONDARY_VM avoids SECONDARY_VM_NAME

Imposta un ritardo per il riavvio di Corosync

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

   systemctl edit corosync.service

2. Aggiungi le seguenti righe al file:

   [Service]
   ExecStartPre=/bin/sleep 60

3. Salva il file ed esci dall'editor.

4. Ricarica la configurazione dell'amministratore di sistema.

   systemctl daemon-reload

5. Verifica che il file di inserimento sia stato creato:

   service corosync status

   Dovresti vedere una riga per il file di inserimento, come mostrato nell' nell'esempio seguente:

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

crea le risorse del file system

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

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

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

   Sostituisci quanto segue:

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

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

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

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

   Sostituisci quanto segue:

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

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

Crea una risorsa di indirizzo IP virtuale

Definisci le risorse del cluster per gli indirizzi VIP.

1. Per cercare l'indirizzo VIP, puoi utilizzare:

   • gcloud compute addresses describe ASCS_VIP_NAME
--region=CLUSTER_REGION --format="value(address)"
   • gcloud compute addresses describe ERS_VIP_NAME
--region=CLUSTER_REGION --format="value(address)"

2. Crea le risorse del cluster per i VIP ASCS ed ERS.

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

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

crea le risorse per il controllo di integrità

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

   # pcs resource create _HEALTHCHECK_SCS service:haproxy@SIDascs \
      op monitor interval=10s timeout=20s \
      --group ASCS_RESOURCE_GROUP

2. Configura la risorsa del cluster per il controllo di integrità ERS:

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

Configura impostazioni predefinite aggiuntive per il cluster

1. Imposta proprietà aggiuntive del cluster:

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

Visualizza le risorse definite

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

1. Visualizza lo stato del cluster:

   # pcs status

   Dovresti vedere un output simile all'esempio seguente:

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

Installare ASCS ed ERS

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

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

Prepararsi all'installazione

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

1. Disattiva la modalità di manutenzione del cluster:

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

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

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

   Sostituisci quanto segue:

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

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

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

Installazione del componente ASCS

1. Sul server secondario, inserisci il comando seguente per inserire la riga secondaria server in modalità standby:

   # pcs node standby

   L'impostazione del server secondario in modalità standby consolida tutte le di risorse cluster sul server principale, semplificando così l'installazione.

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

   # pcs status

   Dovresti vedere un output simile all'esempio seguente:

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

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

   • Per accedere all'interfaccia web di SWPM, è necessario il password per l'utente root. Se i tuoi criteri IT non consentire all'amministratore SAP di accedere alla password root, puoi usare SAPINST_REMOTE_ACCESS_USER.

   • Quando avvii SWPM, usa il parametro SAPINST_USE_HOSTNAME per specificare il nome host virtuale che hai definito per il VIP ASCS indirizzo IP nel file /etc/hosts.

     Ad esempio:

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

   • Nella pagina di conferma finale di SWPM, assicurati che il nome host virtuale sia risposta esatta.

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

   # pcs node unstandby

Installazione del componente ERS

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

   # su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function Stop"
   # su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function StopService"

2. Sul server principale, inserisci questo comando per inserire la server in modalità standby:

   # pcs node standby

   L'impostazione del server principale in modalità standby consolida tutte le di risorse cluster sul server secondario, semplificando così l'installazione.

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

   # pcs status

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

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

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

     Ad esempio:

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

   • Nella pagina di conferma finale di SWPM, assicurati che il nome host virtuale sia risposta esatta.

5. Disattiva la VM principale per avere entrambe attive:

   # pcs node unstandby

Configura i servizi SAP

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

Conferma le voci di servizio SAP

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

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

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

   • 3139184 - Linux: integrazione di systemd per sapstartsrv e SAP Host Agent

   • 3115048 - sapstartsrv con supporto nativo per Linux systemd

   systemV

   Di seguito è riportato un esempio delle voci per ASCS ed ERS servizi nel file /usr/sap/sapservices quando utilizzi Integrazione di systemV:

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

   systemd

   1. Verifica che il file /usr/sap/sapservices contenga voci per il Servizi ASCS ed ERS. Di seguito è riportato un esempio di come queste voci vengono visualizzati nel file /usr/sap/sapservices quando utilizzi Integrazione di systemd:

      systemctl --no-ask-password start SAPSID_ASCS_INSTANCE_NUMBER # sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ASCSASCS_INSTANCE_NUMBER_SID_LCascs
      systemctl --no-ask-password start SAPSID_ERS_INSTANCE_NUMBER # sapstartsrv pf=/usr/sap/SID/SYS/profile/SID_ERSERS_INSTANCE_NUMBER_SID_LCers

   2. Disabilita l'integrazione systemd nelle istanze ASCS e ERS:

      Attenzione: la disabilitazione dell'integrazione systemd interrompe anche la SAP .

      # systemctl disable SAPSID_ASCS_INSTANCE_NUMBER.service
      # systemctl stop SAPSID_ASCS_INSTANCE_NUMBER.service
      # systemctl disable SAPSID_ERS_INSTANCE_NUMBER.service
      # systemctl stop SAPSID_ERS_INSTANCE_NUMBER.service
      

   3. Verifica che l'integrazione di systemd sia disabilitata:

      # systemctl list-unit-files | grep sap

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

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

Arresta i servizi SAP

1. Sul server secondario, interrompi il servizio ERS:

   # su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function Stop"
   # su - SID_LCadm -c "sapcontrol -nr ERS_INSTANCE_NUMBER -function StopService"

2. Su ciascun server, verifica che tutti i servizi siano arrestati:

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

   Dovresti vedere un output simile all'esempio seguente:

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

Disabilita il riavvio automatico del servizio in SAP

Punto chiave: questa sezione è obbligatoria SOLO per systemV.

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

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

   Ad esempio:

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

Modificare i profili ASCS ed ERS

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

   # cd /usr/sap/SID/SYS/profile

   # cd /sapmnt/SID/profile

2. Se necessario, puoi trovare i nomi dei file per ASCS ed ERS i profili tramite l'elenco dei file nella directory del profilo oppure seguenti formati:

   SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME

   SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME

3. Se si utilizza ENSA1, abilitare la funzione keepalive impostando nel profilo ASCS:

   enque/encni/set_so_keepalive = true

   Per ulteriori informazioni, consulta la Nota SAP 1410736 - TCP/IP: impostazione keepalive predefinito.

4. Se necessario, modifica i profili ASCS ed ERS per cambiare l'avvio comportamento del server di accodamento e di quello di replica di accodamento.

   ENSA1

   Nella sezione "Avvia server di accodamento SAP" del profilo ASCS, Se vedi Restart_Program_NN, modifica "Restart" a "Start", come mostrato di seguito esempio.

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

   Nella sezione "Avvia accoda il server di replica" del profilo ERS, Se vedi Restart_Program_NN, modifica "Restart" a "Start", come mostrato di seguito esempio.

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

   ENSA2

   Nella sezione "Avvia server di accodamento SAP" del profilo ASCS, Se vedi Restart_Program_NN, modifica "Restart" a "Start", come mostrato di seguito esempio.

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

   Nella sezione "Avvia accodamento replicatore" del profilo ERS, Se vedi Restart_Program_NN, modifica "Restart" a "Start", come mostrato di seguito esempio.

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

Configura le risorse del cluster per ASCS ed ERS

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

   # pcs property set maintenance-mode="true"

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

   # pcs status

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

   ENSA1

   • Crea la risorsa cluster per l'istanza ASCS. Il valore di InstanceName è il nome del profilo dell'istanza utilizzato da SWPM generato al momento dell'installazione di ASCS.

     # pcs resource create ASCS_INSTANCE_RESOURCE SAPInstance \
         InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
         START_PROFILE=/sapmnt/SID/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
         AUTOMATIC_RECOVER=false meta resource-stickiness=5000 migration-threshold=1 \
         failure-timeout=60  --group ASCS_RESOURCE_GROUP \
         op monitor interval=20 on-fail=restart timeout=60 \
         op start interval=0 timeout=600 \
         op stop interval=0 timeout=600
     

     # pcs resource meta ASCS_RESOURCE_GROUP resource-stickiness=3000
     

   • Crea la risorsa cluster per l'istanza ERS. Il valore di InstanceName è il nome del profilo dell'istanza utilizzato da SWPM generate al momento dell'installazione di ERS. Il parametro IS_ERS=true indica Pacemaker di impostare il flag runsersSID su 1 sul nodo in cui è attiva l'ERS.

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

   ENSA2

   • Crea la risorsa cluster per l'istanza ASCS. Il valore di InstanceName è il nome del profilo dell'istanza utilizzato da SWPM generato al momento dell'installazione di ASCS.

     # pcs resource create ASCS_INSTANCE_RESOURCE SAPInstance \
         InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
         START_PROFILE=/sapmnt/SID/profile/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \
         AUTOMATIC_RECOVER=false meta resource-stickiness=5000 \
         --group ASCS_RESOURCE_GROUP \
         op monitor interval=20 on-fail=restart timeout=60 \
         op start interval=0 timeout=600 \
         op stop interval=0 timeout=600
     

     # pcs resource meta ASCS_RESOURCE_GROUP resource-stickiness=3000
     

   • Crea la risorsa cluster per l'istanza ERS. Il valore di InstanceName è il nome del profilo dell'istanza utilizzato da SWPM generate al momento dell'installazione di ERS.

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

configura i vincoli di località e ordinamento

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

1. Definisci il vincolo dell'ordine iniziale:

ENSA1

1. Crea un vincolo di colocation che impedisce alle risorse ASCS di in esecuzione sullo stesso server delle risorse ERS:

   # pcs constraint colocation add ERS_RESOURCE_GROUP with \
       ASCS_RESOURCE_GROUP -5000
   

2. Configurare ASCS per il failover sul server su cui viene eseguito l'ERS, come determinato dal flag runsersSID che è uguale a 1:

   # pcs constraint location ASCS_INSTANCE \
       rule score=2000 runs_ers_SID eq 1

3. Configura l'ASCS in modo che inizi prima che l'ERS passi allo a un altro server dopo un failover:

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

ENSA2

1. Crea un vincolo di colocation che impedisce alle risorse ASCS di in esecuzione sullo stesso server delle risorse ERS:

   # pcs constraint colocation add ERS_RESOURCE_GROUP  with \
       ASCS_RESOURCE_GROUP -5000
   

2. Configura l'ASCS in modo che inizi prima che l'ERS passi allo a un altro server dopo un failover:

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

1. Controlla i vincoli:

   # pcs constraint

   Dovresti vedere un output simile al seguente:

   Location Constraints:
     Resource: ascs-aha-instance
       Constraint: location-ascs-instance
         Rule: score=2000
           Expression: runs_ers_HKN eq 1
     Resource: fence-nw-ha-vm-1
       Disabled on: nw-ha-vm-1 (score:-INFINITY)
     Resource: fence-nw-ha-vm-2
       Disabled on: nw-ha-vm-2 (score:-INFINITY)
   Ordering Constraints:
     start ascs-group then stop ers-group (kind:Optional) (non-symmetrical)
   Colocation Constraints:
     ascs-group with ers-group (score:-5000)
   Ticket Constraints:

2. Come root di uno dei due server, disabilita la modalità di manutenzione del cluster:

   # pcs property set maintenance-mode="false"

Configura il connettore di cluster Red Hat per SAP

Configura SAP Start Service sapstartsrv su ogni host nel cluster per comunicare tramite l'interfaccia ad alta disponibilità.

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

   usermod -a -G haclient SID_LCadm

2. Modifica i profili dell'istanza SAP aggiungendo le righe seguenti alla sezione alla fine di ogni profilo. I profili sono disponibili nel Directory /sapmnt/SID/profiles.

   service/halib = $(DIR_CT_RUN)/saphascriptco.so
   service/halib_cluster_connector = /usr/bin/sap_cluster_connector

3. Se le risorse delle istanze ASCS ed ERS sono attualmente in esecuzione disabilitale:

   pcs resource disable ERS_INSTANCE_RESOURCE
   pcs resource disable ASCS_INSTANCE_RESOURCE

4. Interrompi i servizi nell'host ASCS:

   sapcontrol -nr ASCS_INSTANCE_NUMBER -function StopService

5. Interrompi i servizi sull'host ERS:

   sapcontrol -nr ERS_INSTANCE_NUMBER -function StopService

6. Abilita le risorse:

   pcs resource enable ERS_INSTANCE_RESOURCE
   pcs resource enable ASCS_INSTANCE_RESOURCE

7. Ripeti i passaggi precedenti su ciascun host nel cluster.

Per ulteriori informazioni da Red Hat, consulta l'articolo Come configurare SAP halib per SAPInstance di risorse su RHEL 7 e 8.

Installa il database e i server delle applicazioni su host esterni al cluster

Nella configurazione ad alta disponibilità, consigliamo di installare su host diversi da quelli di ASCS ed ERS nel cluster.

Utilizzando host separati per ogni server, riduci la complessità e i rischi di un errore che interessa più server e puoi personalizzare le dimensioni Compute Engine a ogni tipo di server.

Ciò ti consente di scegliere la dimensione della macchina certificata più appropriata, per evitare errori e ridurre la complessità.

L'installazione del database e dei server delle applicazioni non è contemplata nella questa guida.

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

• SAP HANA su Google Cloud
• SAP ASE su Google Cloud
• SAP MaxDB su Google Cloud
• IBM Db2 per SAP su Google Cloud

convalida e testa il cluster

Questa sezione mostra come eseguire i seguenti test:

• Verificare la presenza di errori di configurazione
• Verifica che le risorse ASCS ed ERS cambino server correttamente durante failover
• Verificare che le serrature vengano mantenute
• Simula un evento di manutenzione di Compute Engine per assicurarti che la migrazione live non attiva un failover

Controlla la configurazione del cluster

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

   # pcs status

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

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

2. Passa all'utente SID_LCadm:

   # su - SID_LCadm

3. Controlla la configurazione del cluster. Per INSTANCE_NUMBER, specifica il numero di istanza dell'istanza ASCS o ERS attiva sul server in cui stanno inserendo il comando:

   > sapcontrol -nr INSTANCE_NUMBER -function HAGetFailoverConfig

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

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

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

   > sapcontrol -nr INSTANCE_NUMBER -function HACheckConfig

   Dovresti vedere un output simile all'esempio seguente:

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

5. Sul server in cui è attivo ASCS, come SID_LCadm, simula un failover:

   > sapcontrol -nr ASCS_INSTANCE_NUMBER -function HAFailoverToNode ""

6. Come root, se segui il failover utilizzando crm_mon, dovresti vedere L'ASCS viene spostato sull'altro server, l'ERS viene interrotta su quel server e poi l'ERS sul server su cui era in esecuzione l'ASCS.

Simula un failover

Testa il cluster simulando un errore sull'host principale. Utilizza un testa il sistema o esegui il test sul sistema di produzione prima del rilascio l'uso del sistema.

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 accedere all'interfaccia di rete perché convalida sia il failover sia la fencing.

1. Esegui il backup del sistema.

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

   $ ip link set eth0 down

3. Riconnettiti a uno dei due host tramite SSH e passa all'utente root.

4. Entra in pcs status per verificare che l'host principale sia ora attivo sulla VM che conteneva l'host secondario. Il riavvio automatico è abilitato in cluster, quindi l'host arrestato si riavvierà e assumerà il ruolo di come mostrato nell'esempio seguente.

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

Conferma che le voci di blocco vengono conservate

Per verificare che le voci di blocco vengano mantenute durante un failover, seleziona prima scheda relativa alla tua versione del server di accodamento e segui la procedura generare voci di blocco, simulare un failover e confermare le voci di blocco vengono conservate dopo la nuova attivazione di ASCS.

ENSA1

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

   > enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 11 NUMBER_OF_LOCKS

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

   > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_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_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, nel momento in cui Pacemaker interrompe l'ERS per spostarlo in sull'altro server, dovresti vedere un output simile al seguente.

   Number of selected entries: 10
   Number of selected entries: 10
   Number of selected entries: 10
   Number of selected entries: 10
   Number of selected entries: 10

5. Quando il monitor enqt si arresta, esci dal monitor inserendo Ctrl + c.

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

   # crm_mon

7. Come SID_LCadm, dopo la conferma che le serrature erano mantenuti, rilascia i blocchi:

   > enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 12 NUMBER_OF_LOCKS

8. Come SID_LCadm, sul server in cui è attivo ASCS, 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 è attivo ASCS, genera voci di blocco usando il programma enq_adm:

   > enq_admin --set_locks=NUMBER_OF_LOCKS:X:DIAG::TAB:%u pf=/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME

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

   > sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_now

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

   locks_now: 10

3. Quando 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 era riavviato, verifica che le voci del 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 verificato che i blocchi sono stati mantenuti, rilasciali:

   > enq_admin --release_locks=NUMBER_OF_LOCKS:X:DIAG::TAB:%u pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME

8. Come SID_LCadm, sul server in cui è attivo ASCS, 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

Simula un evento di manutenzione di Compute Engine

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

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

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

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

   $ gcloud compute instances simulate-maintenance-event PRIMARY_VM_NAME

2. Verifica che il nodo primario non cambi:

   $ pcs status

Valuta il carico di lavoro SAP NetWeaver

Per automatizzare i controlli di convalida continui per l'alta disponibilità di SAP NetWeaver carichi di lavoro in esecuzione su Google Cloud, puoi utilizzare Gestione dei carichi di lavoro.

Gestore carichi di lavoro consente di analizzare e valutare automaticamente l'alta disponibilità SAP NetWeaver carichi di lavoro con le best practice di fornitori SAP, Google Cloud e sistemi operativi. Ciò consente di migliorare la qualità, le prestazioni e l'affidabilità dei carichi di lavoro.

Per informazioni sulle best practice utilizzate da Workload Manager supporta la valutazione dell'alta disponibilità di SAP NetWeaver carichi di lavoro in esecuzione su Google Cloud, Best practice di Workload Manager per SAP. Per informazioni sulla creazione e sull'esecuzione di una valutazione tramite Gestore carichi di lavoro, vedi Crea ed esegui una valutazione.

Risoluzione dei problemi

Per risolvere i problemi relativi alle configurazioni ad alta disponibilità per SAP NetWeaver, consulta la pagina relativa alla risoluzione dei problemi delle configurazioni ad alta disponibilità per SAP.

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

Se hai bisogno di aiuto per risolvere un problema relativo ai cluster ad alta disponibilità per SAP NetWeaver, raccogliere le informazioni diagnostiche richieste e contatta l'assistenza clienti Google Cloud.

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

Assistenza

In caso di problemi con l'infrastruttura o i servizi Google Cloud, contatta l'assistenza clienti. Puoi trovare i dati di contatto nella Pagina Panoramica dell'assistenza nella console Google Cloud. Se l'assistenza clienti stabilisce che un problema risiede nei tuoi sistemi SAP, verrai indirizzato a SAP Support.

Per problemi relativi ai prodotti SAP, registra la richiesta di assistenza con Assistenza SAP. SAP valuta il ticket di assistenza e, se sembra essere un account Google Cloud, relativo a un problema dell'infrastruttura, SAP trasferisce il ticket Componente Google Cloud nel sistema: BC-OP-LNX-GOOGLE oppure BC-OP-NT-GOOGLE.

Requisiti di assistenza

Prima di poter ricevere assistenza per sistemi SAP e Google Cloud infrastruttura e servizi che utilizzano, devi soddisfare i requisiti minimi requisiti dei piani di assistenza.

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

• Ricevi assistenza per SAP su Google Cloud
• SAP Note 2456406 - SAP su Google Cloud Platform: prerequisiti di assistenza (È richiesto un account utente SAP)

Esecuzione di attività post-deployment

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

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

Passaggi successivi

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

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

• Criteri di supporto per i cluster RHEL ad alta disponibilità - Requisiti generali per recinzioni/STONITH

• Guida alla pianificazione dell'alta disponibilità per SAP NetWeaver su Google Cloud

• Per ulteriori informazioni sull'amministrazione e il monitoraggio delle VM, consulta Guida operativa di SAP NetWeaver