Questa guida mostra come eseguire il deployment e configurare un cluster SUSE Linux Enterprise Server (SLES) ad alta disponibilità (HA) ottimizzato per le prestazioni per il sistema SAP NetWeaver.
Questa guida include i passaggi per:- Configurazione di un bilanciatore del carico di rete passthrough interno per reindirizzare il traffico in caso di guasto.
- Configurazione di un cluster Pacemaker on SLES per gestire il SAP sistemi e altre risorse durante un failover. La configurazione Montaggio semplice è fornita anche per SLES 15 per SAP e versioni successive.
Questa guida include anche i passaggi per configurare il sistema SAP NetWeaver per l'HA, ma fai riferimento alla documentazione di 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 HANA su Red Hat Enterprise Linux (RHEL), consulta la guida alla configurazione manuale del cluster ad alta disponibilità per SAP NetWeaver su RHEL.
Questa guida è rivolta agli utenti avanzati di SAP NetWeaver che hanno familiarità con le configurazioni di disponibilità elevata di Linux per SAP NetWeaver.
Il sistema di cui questa guida descrive il deployment
Seguendo questa guida, eseguirai il deployment di due istanze SAP NetWeaver cluster ad alta disponibilità su SLES. Esegui il deployment di ogni istanza SAP NetWeaver su una VM Compute Engine in una zona diversa all'interno della stessa regione. Questa guida non tratta l'installazione ad alta disponibilità del database sottostante.
Il cluster di cui è stato eseguito il deployment include le seguenti funzioni e funzionalità:
- Due VM host, una per l'istanza ASCS attiva e una per l'istanza attiva dell'Enqueue Replicator ENSA2 o del server di replicazione enqueue ENSA1. Sono indicate le istanze ENSA2 e ENSA1 fino a ERS.
- Gestore delle risorse del cluster ad alta disponibilità Pacemaker.
- Un meccanismo di scherma STONITH.
- Riavvio automatico dell'istanza non riuscita come nuova istanza secondaria.
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 SLES.
Prerequisiti
Prima di creare il cluster SAP NetWeaver ad alta disponibilità, assicurati che siano soddisfatti i seguenti prerequisiti:
- Hai letto la guida alla pianificazione di SAP NetWeaver e la guida alla pianificazione della disponibilità elevata 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 di account e progetti Google Cloud, consulta la sezione Creare un progetto della Guida all'implementazione 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 Controlli di conformità e sovranità per SAP su Google Cloud.
Se utilizzi il DNS interno della VPC, il valore della variabile
vmDnsSetting
nei metadati del progetto deve essereGlobalOnly
oZonalPreferred
per abilitare la risoluzione dei nomi dei nodi nelle varie zone. L'impostazione predefinita divmDnsSetting
èZonalOnly
. Per ulteriori informazioni, consulta:Hai configurato una condivisione file utilizzando una soluzione di archiviazione file condivisa NFS, come Filestore Enterprise.
Se OS Login è abilitato nei metadati del progetto, devi disabilitarlo temporaneamente fino al completamento del deployment. Ai fini del deployment, questa procedura configura le chiavi SSH nei metadati dell'istanza. Quando l'accesso al sistema operativo è abilitato, le configurazioni delle chiavi SSH basate su metadati vengono disabilitate e questo deployment non va a buon fine. Al termine del deployment, puoi abilitare di nuovo OS Login.
Per ulteriori informazioni, vedi:
Informazioni correlate di SUSE
Ad eccezione di dove richiesto per l'ambiente Google Cloud, il informazioni riportate in questa guida sono coerenti con quanto segue: guide correlate di SUSE:
- SAP NetWeaver Accodamento replica 1 Cluster ad alta disponibilità - Guida alla configurazione per SAP NetWeaver 7.40 e 7.50 | SUSE Linux Enterprise Server per applicazioni SAP 12
- SAP NetWeaver Accodamento replica 1 Cluster ad alta disponibilità - Guida alla configurazione per SAP NetWeaver 7.40 e 7.50 | SUSE Linux Enterprise Server per applicazioni SAP 15
- SAP S/4 HANA - Cluster ad alta disponibilità di replica in coda 2 - Guida alla configurazione | SUSE Linux Enterprise Server per applicazioni SAP 12
- SAP S/4 HANA - Enqueue Replication 2 High Availability Cluster - Setup Guide | SUSE Linux Enterprise Server for SAP Applications 15
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 una tua rete VPC in modo che le uniche regole firewall in vigore siano quelle che crei esplicitamente.
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 gateway NAT e con i tag di rete VM supporta questo accesso, anche se le VM di destinazione non hanno IP esterni.
Per configurare il networking:
Console
- Nella console Google Cloud, vai alla pagina Reti VPC.
- Fai clic su Crea rete VPC.
- Inserisci un nome per la rete.
Il nome deve rispettare la convenzione di denominazione. Le reti VPC utilizzano la convenzione di denominazione di Compute Engine.
- In Modalità di creazione subnet, scegli Personalizzata.
- Nella sezione Nuova subnet, specifica i seguenti parametri di configurazione per una
subnet:
- Inserisci un nome per la subnet.
- Per Regione, seleziona la regione Compute Engine in cui vuoi creare la sottorete.
- 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 dell'intervallo IPv4 principale per la subnet. Se prevedi di aggiungere più di una subnet, assegni intervalli IP CIDR non sovrapposti per ogni subnet della rete. Tieni presente che ogni subnet e i relativi intervalli IP interni sono mappati a una singola regione.
- Fai clic su Fine.
- Per aggiungere altre subnet, fai clic su Aggiungi subnet e ripeti i passaggi precedenti. Puoi aggiungere altre subnet alla rete dopo averla creata.
- Fai clic su Crea.
gcloud
- Vai a Cloud Shell.
- Per creare una nuova rete in modalità di subnet personalizzate, esegui:
gcloud compute networks create NETWORK_NAME --subnet-mode custom
Sostituisci
NETWORK_NAME
con il nome della nuova rete. 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 maggiori informazioni informazioni, consulta Modalità di creazione subnet. - Crea una subnet e specifica la regione e l'intervallo IP:
gcloud compute networks subnets create SUBNETWORK_NAME \ --network NETWORK_NAME --region REGION --range RANGE
Sostituisci quanto segue:
SUBNETWORK_NAME
: il nome della nuova subnetNETWORK_NAME
: il nome della rete creata nel passaggio precedenteREGION
: la regione in cui vuoi la subnetRANGE
: l'intervallo di indirizzi IP, specificato in formato CIDR, ad esempio10.1.0.0/24
Se prevedi di aggiungere più di una subnet, assegna intervalli IP CIDR non sovrapposti per ogni subnet della rete. Tieni presente che ogni subnet e i relativi intervalli IP interni sono mappati a una singola regione.
- Se vuoi, ripeti il passaggio precedente e aggiungi altre subnet.
Configurazione di un gateway NAT
Se devi creare una o più VM senza indirizzi IP pubblici, devi utilizzare la rete Address Translation (NAT) per consentire alle VM di accedere a internet. Utilizza Cloud NAT, un servizio gestito software-defined distribuito di Google Cloud che consente alle VM di inviare pacchetti in uscita a internet e di ricevere eventuali pacchetti di risposta in entrata stabiliti corrispondenti. In alternativa, puoi configurare una VM separata come gateway NAT.
Per creare un'istanza Cloud NAT per il tuo progetto, consulta Utilizzo di Cloud NAT.
Dopo aver configurato Cloud NAT per il progetto, le istanze VM possono accedere in sicurezza a internet senza un indirizzo IP pubblico.
aggiungi regole firewall
Per impostazione predefinita, le connessioni in entrata dall'esterno della rete Google Cloud sono bloccati. Per consentire le connessioni in entrata, configura una regola firewall per la tua VM. Le regole firewall regolano solo le nuove connessioni in entrata a una VM. Dopo 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 specifiche tra le VM nella stessa subnet.
Crea regole firewall per consentire l'accesso per elementi quali:
- 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 su quale indirizzo IP utilizzare, rivolgiti all'amministratore di rete della tua azienda.
- Comunicazione tra VM in una configurazione a 3 livelli, scalabile o ad alta disponibilità. Ad esempio, se esegui il deployment di un sistema a tre livelli, nella sottorete avrai almeno due VM: 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à.
Per creare una regola firewall:
Nella console Google Cloud, vai alla pagina Firewall della rete VPC.
Nella parte superiore della pagina, fai clic su Crea regola firewall.
- Nel campo Rete, seleziona la rete in cui si trova la VM.
- Nel campo Destinazioni, seleziona Tutte le istanze nella rete.
- Nel campo Filtro di origine, seleziona una delle seguenti opzioni:
- Intervalli IP per consentire il traffico in entrata da indirizzi IP specifici. Specifica l'intervallo di indirizzi IP nel campo Intervalli IP di origine.
- Subnet per consentire il traffico in entrata da una determinata una subnet. Specifica il nome della subnet nel seguente subnet. 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 e specifica
tcp:PORT_NUMBER;
.
Fai clic su Crea per creare la regola firewall.
Deployment delle VM per SAP NetWeaver
Prima di iniziare a configurare il cluster ad alta disponibilità, definisci ed esegui il deployment delle istanze VM che fungeranno da nodi principali e secondari nel 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 la definizione della seconda VM al file di configurazione copiando e incollando 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.
Apri Cloud Shell.
Scarica il modello di file di configurazione YAML,
template.yaml
, nella directory di lavoro:wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/template.yaml
Se vuoi, rinomina il file
template.yaml
per identificare la configurazione che definisce. Ad esempio,nw-ha-sles15sp3.yaml
.Apri il file di configurazione YAML nell'editor di codice di Cloud Shell facendo clic sull'icona a forma di matita (edit) nell'angolo in alto a destra della finestra del terminale di Cloud Shell per avviare l'editor.
Nel modello del file di configurazione YAML, definisci la prima istanza VM. Puoi definire la seconda istanza VM nel passaggio successivo dopo la tabella seguente.
Specifica i valori delle proprietà sostituendo le parentesi e i relativi contenuti con i valori per la 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
, di cui uno commentato. La specificatype
attiva per impostazione predefinita specifica la versione del modello comelatest
. La specificatype
commentata specifica una versione del modello specifica con un timestamp.Se vuoi che tutti i tuoi implementazioni utilizzino la stessa versione del modello, utilizza la specifica
type
che include il timestamp.instanceName
Stringa Il nome dell'istanza VM che stai definendo. Specifica nomi diversi nelle definizioni delle VM principali e secondarie. Valuta la possibilità di utilizzare nomi che identifichino le istanze come appartenenti allo 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 le VM primarie e secondarie. Se hai bisogno di un tipo di VM personalizzato, specifica un piccolo tipo di VM predefinito e, al termine del deployment, personalizza la VM in base alle tue esigenze.
zone
Stringa La zona Google Cloud in cui eseguire il deployment dell'istanza VM che stai definendo. Specifica zone diverse nella stessa regione per le definizioni della VM principale e secondaria. Le zone devono trovarsi nella stessa regione selezionata per la subnet. subnetwork
Stringa Il nome della subnet che hai creato in un passaggio precedente. Se esegui il deployment in un VPC condiviso, specifica questo valore come SHAREDVPC_PROJECT/SUBNETWORK
. Ad esempio,myproject/network1
.linuxImage
Stringa Il nome dell'immagine o della famiglia di immagini del sistema operativo Linux che utilizzi con SAP NetWeaver. Per specificare un'immagine: famiglia, aggiungi il prefisso family/
al cognome. Per ad esempiofamily/sles-15-sp3-sap
. Per l'elenco delle famiglie di immagini disponibili, consulta la pagina Immagini nella console Google Cloud.linuxImageProject
Stringa Il progetto Google Cloud che contiene l'immagine che useremo. Questo progetto potrebbe essere il tuo progetto o il progetto immagine Google Cloud suse-sap-cloud
. Per un elenco dei progetti di immagini Google Cloud, consulta la pagina Immagini della documentazione di Compute Engine.usrsapSize
Numero intero La dimensione del disco /usr/sap
. 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 necessarie durante il deployment per configurare la VM per SAP.
Se
serviceAccount
non è specificato, viene utilizzato il service account Compute Engine predefinito.Specifica l'indirizzo completo dell'account di servizio. Ad esempio:
sap-ha-example@example-project-123456.iam.gserviceaccount.com
publicIP
Booleano Facoltativo. Determina se viene aggiunto un indirizzo IP pubblico dell'istanza VM. Il valore predefinito è Yes
.sap_deployment_debug
Booleano Facoltativo. Se questo valore è impostato su Yes
, il deployment genera log dettagliati. Non attivare attiva, a meno che un tecnico del servizio di assistenza Google non ti chieda di abilitare il debug del machine learning.Nel file di configurazione YAML, crea la definizione della seconda VM copiando la definizione della prima VM e incollando la copia dopo la prima definizione. Per un esempio, vedi Esempio di un file di configurazione YAML completo.
Nella definizione della seconda VM, specifica valori diversi per le seguenti proprietà rispetto a quelli specificati nella prima definizione:
name
instanceName
zone
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 file di configurazione YAML.
Il comando precedente richiama Deployment Manager, che esegue il deployment delle VM in base alle specifiche nel file di configurazione YAML.
L'elaborazione del deployment prevede due fasi. Nella prima fase, Deployment Manager scrive il proprio stato nella console. Nella seconda fase, gli script di deployment scrivono il proprio stato in Cloud Logging.
Esempio di file di configurazione YAML completo
L'esempio seguente mostra un file di configurazione YAML completato che esegue il deployment di due istanze VM per una configurazione HA per SAP NetWeaver utilizzando la versione più recente dei modelli di Deployment Manager. L'esempio omette i commenti contenuti nel modello al primo download.
Il file contiene le definizioni di due risorse da eseguire il deployment:
sap_nw_node_1
e sap_nw_node_2
. Ogni definizione della 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 sezione Opzioni avanzate del modello del file di configurazione.
resources: - name: sap_nw_node_1 type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/sap_nw.py properties: instanceName: nw-ha-vm-1 instanceType: n2-standard-4 zone: us-central1-b subnetwork: example-sub-network-sap linuxImage: family/sles-15-sp3-sap linuxImageProject: suse-sap-cloud usrsapSize: 15 swapSize: 24 networkTag: cluster-ntwk-tag,allow-health-check serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com - name: sap_nw_node_2 type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_nw/sap_nw.py properties: instanceName: nw-ha-vm-2 instanceType: n2-standard-4 zone: us-central1-c subnetwork: example-sub-network-sap linuxImage: family/sles-15-sp3-sap linuxImageProject: suse-sap-cloud usrsapSize: 15 swapSize: 24 networkTag: cluster-ntwk-tag,allow-health-check serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com
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 HA
- I controlli di integrità utilizzati da Cloud Load Balancing, come descritto nel passaggio successivo Creare una regola firewall per i controlli di integrità.
Quando crei regole firewall VPC, specifichi i tag di rete che hai definito nel file di configurazione template.yaml
per 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 istruzioni, vedi Aggiungere regole firewall.
Verifica del deployment delle VM
Prima di installare SAP NetWeaver o di iniziare a configurare il cluster ad alta disponibilità, 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
Nella console Google Cloud, apri Cloud Logging per monitorare l'installazione progressi e verificare la presenza di errori.
Filtra i log:
Esplora log
Nella pagina Esplora log, vai al riquadro Query.
Nel menu a discesa Risorsa, seleziona Globale, quindi fai clic su Aggiungi.
Se non vedi l'opzione Globale, nell'editor di query inserisci la seguente query:
resource.type="global" "Deployment"
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.
Analizza i log filtrati:
- Se viene visualizzato
"--- Finished"
, significa che l'elaborazione del deployment è completata e puoi procedere al passaggio successivo. Se viene visualizzato un errore relativo alla quota:
Nella piattaforma IAM e Amministratore Quote aumenta le quote che non soddisfano I requisiti SAP NetWeaver elencati nella Guida alla pianificazione di SAP NetWeaver.
In Deployment Manager Deployment elimina il deployment per ripulire le VM dell'installazione non riuscita.
Esegui di nuovo il deployment.
- Se viene visualizzato
Controlla la configurazione delle VM
Dopo il deployment delle istanze VM, connettiti alle VM utilizzando
ssh
.- Se non l'hai ancora fatto,
crea una regola firewall
per consentire una connessione SSH sulla porta
22
. Vai alla pagina Istanze VM.
Connettiti a ogni istanza VM facendo clic sul pulsante SSH nella per ogni istanza VM, oppure puoi utilizzare metodo SSH preferito.
- Se non l'hai ancora fatto,
crea una regola firewall
per consentire una connessione SSH sulla porta
Visualizza il file system:
~>
df -hAssicurati di vedere 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 tmpfs 6.3G 0 6.3G 0% /run/user/1002 tmpfs 6.3G 0 6.3G 0% /run/user/0
Verifica che lo spazio di scambio sia stato creato:
~>
cat /proc/meminfo | grep SwapVedrai 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:
- Correggi l'errore.
- Nella sezione Deployment elimina il deployment per ripulire le VM e i dischi permanenti dell'installazione non riuscita.
- Esegui di nuovo il deployment.
Aggiornare Google Cloud CLI
Il modello Deployment Manager ha installato Google Cloud CLI sulle VM durante il deployment. Aggiorna gcloud CLI per assicurarti che includa tutti gli aggiornamenti più recenti.
Accedi tramite SSH alla VM principale.
Aggiorna l'interfaccia a riga di comando gcloud:
~>
sudo gcloud components updateSegui le istruzioni.
Ripeti i passaggi sulla VM secondaria.
Abilita la comunicazione di backend del bilanciatore del carico tra le VM
Dopo aver verificato che le VM sono state implementate correttamente, attiva la comunicazione di backend tra le VM che fungeranno da nodi nel cluster ad alta disponibilità.
Attiva la comunicazione di backend tra le VM modificando la configurazione del google-guest-agent
, incluso nell'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:
Interrompi l'agente:
sudo service google-guest-agent stop
Apri o crea il file
/etc/default/instance_configs.cfg
per modificarlo. Ad esempio:sudo vi /etc/default/instance_configs.cfg
Nel file
/etc/default/instance_configs.cfg
, specifica quanto segue di configurazione come mostrato. Se le sezioni non esistono, creane di nuove. In particolare, assicurati che entrambe le proprietàtarget_instance_ips
eip_forwarding
siano impostate sufalse
:[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
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 ulteriori informazioni, 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 forniti da Google Cloud generano una chiave per te, ma puoi sostituirla con una chiave generata da te, se necessario.
La tua organizzazione ha probabilmente linee guida che regolano le comunicazioni della rete interna. 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. Consulta Gestire i file con Cloud Shell.
- Scambia file utilizzando un bucket Cloud Storage. Consulta: Caricamenti e download.
- Utilizza una soluzione di archiviazione file come Filestore o 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 questi passaggi. I passaggi presuppongono che venga utilizzata la chiave SSH viene generato dai modelli di Deployment Manager con SAP.
Nella VM host principale:
Connettiti alla VM tramite SSH.
Passa al root:
$
sudo su -Verifica che la chiave SSH esista:
#
ls -l /root/.ssh/Dovresti vedere i file della chiave id_rsa come nell'esempio seguente:
-rw-r--r-- 1 root root 569 May 4 23:07 authorized_keys -rw------- 1 root root 2459 May 4 23:07 id_rsa -rw-r--r-- 1 root root 569 May 4 23:07 id_rsa.pub
Aggiorna i metadati della VM principale con le informazioni sulla chiave SSH per la VM secondaria.
#
gcloud compute instances add-metadata SECONDARY_VM_NAME \ --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" \ --zone SECONDARY_VM_ZONEVerifica che le chiavi SSH siano configurate correttamente aprendo una connessione SSH dal sistema principale a quello secondario:
#
ssh SECONDARY_VM_NAME
Sulla VM host secondaria:
Accedi tramite SSH alla VM.
Passa al root:
$
sudo su -Verifica che la chiave SSH esista:
#
ls -l /root/.ssh/Dovresti vedere i file della chiave id_rsa come nell'esempio seguente:
-rw-r--r-- 1 root root 569 May 4 23:07 authorized_keys -rw------- 1 root root 2459 May 4 23:07 id_rsa -rw-r--r-- 1 root root 569 May 4 23:07 id_rsa.pub
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_keysVerifica che le chiavi SSH siano configurate correttamente aprendo una connessione SSH dal sistema secondario a quello principale.
#
ssh PRIMARY_VM_NAME
Configurare lo spazio di archiviazione dei file condivisi e 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. Il software del cluster garantisce che le directory appropriate vengano montate solo sulle istanze corrette.
La configurazione di una soluzione di condivisione file non è trattata in questa guida. Per istruzioni sulla configurazione del sistema di condivisione dei file, consulta le istruzioni fornite dal fornitore della soluzione selezionata. Se scegli di utilizzare Filestore per la tua soluzione di condivisione file, ti consigliamo di utilizzare Livello Enterprise di Filestore. Per scoprire come creare un'istanza Filestore, consulta Creare 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:
Se non hai ancora configurato una soluzione di archiviazione file condivisa NFS a disponibilità elevata, fallo ora.
Monta lo spazio di archiviazione condiviso NFS su entrambi i server per la configurazione iniziale.
~>
sudo mkdir /mnt/nfs~>
sudo mount -t nfs NFS_PATH /mnt/nfsSostituisci
NFS_PATH
con il percorso del file NFS una soluzione condivisa. Ad esempio,10.49.153.26:/nfs_share_nw_ha
.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}Se utilizzi una configurazione di montaggio semplice, esegui invece i seguenti comandi:
~>
sudo mkdir /mnt/nfs/sapmntSID~>
sudo mkdir /mnt/nfs/usrsap{trans,SID}Sostituisci quanto segue:
SID
: l'ID sistema SAP (SID). Utilizza le lettere maiuscole per tutte le lettere. Ad esempio,AHA
.ASCS_INSTANCE_NUMBER
: il numero di istanza di il sistema ASCS. Ad esempio,00
.ERS_INSTANCE_NUMBER
: il numero di istanza del sistema ERS. Ad esempio,10
.
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_NUMBERSe utilizzi una configurazione di montaggio semplice, esegui invece i seguenti comandi:
~>
sudo mkdir -p /sapmnt/SID~>
sudo mkdir -p /usr/sap/trans~>
sudo mkdir -p /usr/sap/SIDConfigura
autofs
per montare le directory comuni dei file condivisi al primo accesso alle directory dei file. Il montaggio dei modelliASCSASCS_INSTANCE_NUMBER
eERSERS_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.sapPer informazioni su
autofs
, vedi autofs - come funziona.Se utilizzi una configurazione di montaggio semplice, esegui invece i seguenti comandi:
~>
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}/sapmnt" | sudo tee -a /etc/auto.sap~>
echo "/usr/sap/trans ${NFS_OPTS}/usrsaptrans" | sudo tee -a /etc/auto.sap~>
echo "/usr/sap/SID ${NFS_OPTS}/usrsapSID" | sudo tee -a /etc/auto.sapAvvia il servizio
autofs
su entrambi i server:~>
sudo systemctl enable autofs~>
sudo systemctl restart autofs~>
sudo automount -vAttiva
autofs
per montare le directory condivise accedendo a ciascuna utilizzando il comandocd
. Ad esempio:~>
cd /sapmnt/SID~>
cd /usr/sap/transSe utilizzi una configurazione di montaggio semplice, esegui invece il seguente comando:
~>
cd /sapmnt/SID~>
cd /usr/sap/trans~>
cd /usr/sap/SIDDopo aver eseguito l'accesso a tutte le directory, esegui il comando
df -Th
per verificare che le directory siano montate.~>
df -Th | grep FILE_SHARE_NAMESostituisci
FILE_SHARE_NAME
con il nome del tuo di condivisione file NFS. Ad esempio,nfs_share_nw_ha
.Vedrai punti di montaggio e directory simili al seguente esempio:
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
Se utilizzi una configurazione di montaggio semplice, vedrai punti di montaggio e directory simili all'esempio seguente:
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 10.49.153.26:/nfs_share_nw_ha/usrsapAHA nfs 1007G 76M 956G 1% /usr/sap/AHA
Configurare il supporto del 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 indirizzi IP virtuali (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à, crei due VIP, talvolta indicati come indirizzi IP virtuali. Un VIP segue l'istanza SAP Central Services (SCS) attiva mentre l'altra 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.
Apri Cloud Shell:
Prenota un indirizzo IP per l'IP virtuale dell'ASCS e per l'IP VIP dell'ERS. Per ASCS, l'indirizzo IP è l'indirizzo IP utilizzato dalle applicazioni per accedere a SAP NetWeaver. Per ERS, l'indirizzo IP è l'indirizzo IP che viene utilizzato per la replica del server di coda. Se ometti il
--addresses
flag, viene scelto un indirizzo IP nella subnet specificata:~
gcloud compute addresses create ASCS_VIP_NAME \ --region CLUSTER_REGION --subnet CLUSTER_SUBNET \ --addresses ASCS_VIP_ADDRESS~
gcloud compute addresses create ERS_VIP_NAME \ --region CLUSTER_REGION --subnet CLUSTER_SUBNET \ --addresses ERS_VIP_ADDRESSSostituisci quanto segue:
ASCS_VIP_NAME
: specifica un nome per l'indirizzo IP virtuale dell'istanza ASCS. Ad esempio,ascs-aha-vip
.CLUSTER_REGION
: specifica la regione Google Cloud in cui si trova il tuo 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
: facoltativamente, specifica un indirizzo IP per l'IP virtuale dell'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.
Conferma prenotazione dell'indirizzo IP:
~
gcloud compute addresses describe VIP_NAME \ --region CLUSTER_REGIONDovresti vedere un output simile al seguente esempio:
address: 10.1.0.2 addressType: INTERNAL creationTimestamp: '2022-04-04T15:04:25.872-07:00' description: '' id: '555067171183973766' kind: compute#address name: ascs-aha-vip networkTier: PREMIUM purpose: GCE_ENDPOINT region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1 selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/addresses/ascs-aha-vip status: RESERVED subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-sub-network-sap
Definisci i nomi host per l'indirizzo VIP in /etc/hosts
Definisci un nome host per ogni indirizzo VIP e poi aggiungi gli indirizzi IP e i nomi host sia per le VM sia per i VIP al file /etc/hosts
su ogni VM.
I nomi host VIP non sono noti al di fuori delle VM, a meno che non li aggiunga anche al
tuo 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 controlli di integrità: uno per l'istanza ASCS attiva e uno per l'ERS attivo.
In Cloud Shell, crea i controlli di integrità. Per evitare conflitti con altri servizi, designa i numeri di porta per le istanze ASCS ed ERS nell'intervallo privato 49152-65535. I valori di intervallo di controllo e timeout nei seguenti comandi sono leggermente più lunghi rispetto ai valori predefiniti per aumentare la tolleranza al failover durante gli eventi di migrazione in produzione di Compute Engine. Se necessario, puoi modificare i valori:
~
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~
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
Conferma la creazione di ogni controllo di integrità:
~
gcloud compute health-checks describe HEALTH_CHECK_NAMEDovresti vedere un output simile al seguente esempio:
checkIntervalSec: 10 creationTimestamp: '2021-05-12T15:12:21.892-07:00' healthyThreshold: 2 id: '1981070199800065066' kind: compute#healthCheck name: ascs-aha-health-check-name selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/scs-aha-health-check-name tcpHealthCheck: port: 60000 portSpecification: USE_FIXED_PORT proxyHeader: NONE timeoutSec: 10 type: TCP unhealthyThreshold: 2
Crea una regola firewall per i controlli di integrità
Se non lo hai già fatto, definisci una regola firewall per una porta nell'intervallo privato che consenta l'accesso alle VM host dagli intervalli IP utilizzati dai controlli di integrità di Cloud Load Balancing, 35.191.0.0/16
e
130.211.0.0/22
. Per saperne di più sulle regole firewall per i bilanciatori del carico,
consulta Creazione di regole firewall per i controlli di integrità.
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
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_NUMAd 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 contenente una VM con nodo cluster e aggiungere la VM in quella zona al gruppo di istanze.
In Cloud Shell, crea il gruppo di istanze principale e aggiungi la VM principale:
~
gcloud compute instance-groups unmanaged create PRIMARY_IG_NAME \ --zone=PRIMARY_ZONE~
gcloud compute instance-groups unmanaged add-instances PRIMARY_IG_NAME \ --zone=PRIMARY_ZONE \ --instances=PRIMARY_VM_NAME
In Cloud Shell, crea il gruppo di istanze secondarie e aggiungi dalla VM secondaria:
~
gcloud compute instance-groups unmanaged create SECONDARY_IG_NAME \ --zone=SECONDARY_ZONE~
gcloud compute instance-groups unmanaged add-instances SECONDARY_IG_NAME \ --zone=SECONDARY_ZONE \ --instances=SECONDARY_VM_NAME
Conferma la creazione dei gruppi di istanze:
~
gcloud compute instance-groups unmanaged listDovresti 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 gli gruppi di istanze a ogni servizio di backend, designando il gruppo di istanze opposto come gruppo di istanze di failover in ogni servizio di backend. Infine, crea le regole di forwarding dai VIP ai servizi di backend.
In Cloud Shell, crea il servizio di backend e il gruppo di failover per ASCS:
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-checksAggiungi 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_REGIONAggiungi 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
In Cloud Shell, crea il servizio di backend e il gruppo di failover per ERS:
Crea il servizio di backend per ERS:
~
gcloud compute backend-services create ERS_BACKEND_SERVICE_NAME \ --load-balancing-scheme internal \ --health-checks ERS_HEALTH_CHECK_NAME \ --no-connection-drain-on-failover \ --drop-traffic-if-unhealthy \ --failover-ratio 1.0 \ --region CLUSTER_REGION \ --global-health-checksAggiungi il gruppo di istanze secondario 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_REGIONAggiungi 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
Facoltativamente, conferma che i servizi di backend contengano l'istanza gruppi come previsto:
~
gcloud compute backend-services describe BACKEND_SERVICE_NAME \ --region=CLUSTER_REGIONDovresti vedere un output simile all'esempio riportato di seguito per il servizio di backend ASCS. Per ERS,
failover: true
viene visualizzato nel gruppo di istanze principali: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
In Cloud Shell, crea regole di inoltro per i servizi di backend ASCS e ERS:
Crea la regola di inoltro dall'IP virtuale 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 ALLCrea la regola di inoltro dall'IP pubblico virtuale ERS al servizio di backend ERS:
~
gcloud compute forwarding-rules create ERS_FORWARDING_RULE_NAME \ --load-balancing-scheme internal \ --address ERS_VIP_ADDRESS \ --subnet CLUSTER_SUBNET \ --region CLUSTER_REGION \ --backend-service ERS_BACKEND_SERVICE_NAME \ --ports ALL
Testa la configurazione del bilanciatore del carico
Anche se i gruppi di istanze di backend non verranno registrati come integri fino a più tardi, puoi testare la configurazione del bilanciatore del carico impostando un listener per rispondere ai controlli di integrità. Dopo aver configurato un ascoltatore, se il bilanciatore del carico è configurato correttamente, lo stato dei gruppi di istanze di backend diventa Stabile.
Le sezioni seguenti presentano diversi metodi che puoi utilizzare per testare la configurazione.
Test del bilanciatore del carico con l'utilità socat
Puoi utilizzare l'utilità socat
per ascoltare temporaneamente su una porta di controllo di integrità. Devi comunque installare socat
l'utilità, perché
in seguito, durante la configurazione delle risorse del cluster.
Su entrambe le VM host come utente root, installa l'utilità
socat
:#
zypper install socatSulla VM principale, assegna temporaneamente il VIP alla scheda di rete eth0:
ip addr add VIP_ADDRESS dev eth0
Nella VM principale, avvia un processo
socat
per ascoltare per 60 secondi sulla porta di controllo dell'integrità dell'ASCS:#
timeout 60s socat - TCP-LISTEN:ASCS_HEALTHCHECK_PORT_NUM,forkIn 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_REGIONDovresti 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
Rimuovi l'IP virtuale dall'interfaccia eth0:
ip addr del VIP_ADDRESS dev eth0
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 modificare temporaneamente il controllo di integrità in modo che utilizzi la porta 22
, che ha un listener che può rispondere al controllo di integrità.
Per utilizzare temporaneamente la porta 22
:
Nella console Google Cloud, vai alla pagina Controlli di integrità di Compute Engine:
Fai clic sul nome del controllo di integrità.
Fai clic su Modifica.
Nel campo Porta, imposta il numero di porta su 22.
Fai clic su Salva e attendi un minuto o due.
In Cloud Shell, dopo aver atteso qualche secondo affinché il controllo di integrità rilevi il listener, controlla lo stato dei gruppi di istanze di backend:
~
gcloud compute backend-services get-health BACKEND_SERVICE_NAME \ --region CLUSTER_REGIONDovresti 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
Al termine, ripristina il numero di porta del controllo di integrità.
Configura Pacemaker
La procedura seguente configura l'implementazione SUSE di un cluster Pacemaker su VM Compute Engine per SAP NetWeaver.
Per ulteriori informazioni sulla configurazione dei cluster ad alta disponibilità su SLES, consulta la documentazione dell'estensione SUSE Linux Enterprise High Availability per la tua versione di SLES.
Installa i pacchetti di cluster richiesti
Come root sia sull'host principale sia su quello secondario, scarica quanto segue pacchetti di cluster richiesti:
Lo schema
ha_sles
:#
zypper install -t pattern ha_slesIl pacchetto
sap-suse-cluster-connector
:#
zypper install -y sap-suse-cluster-connectorSe utilizzi un montaggio semplice ed esegui anche il seguente :
#
zypper install -y sapstartsrv-resource-agentsSe non l'hai ancora installata, l'utilità
socat
:#
zypper install -y socat
Verifica che siano caricati gli agenti di alta disponibilità più recenti:
#
zypper se -t patch SUSE-SLE-HA
Inizializza, configura e avvia il cluster sulla VM principale
Per inizializzare il cluster, utilizza lo script ha-cluster-init
SUSE. Poi devi modificare il file di configurazione di Corosync e sincronizzarlo con il nodo secondario. Dopo aver avviato il cluster, devi impostare
le proprietà e i valori predefiniti del cluster usando i comandi crm
.
Crea i file di configurazione di Corosync
Crea un file di configurazione Corosync sull'host principale:
Utilizzando il tuo editor di testo preferito, crea il seguente file:
/etc/corosync/corosync.conf
Nel file
corosync.conf
sull'host principale, aggiungi la seguente configurazione, sostituendo il testo delle variabili in corsivo con i tuoi valori:totem { version: 2 secauth: off crypto_hash: sha1 crypto_cipher: aes256 cluster_name: hacluster clear_node_high_bit: yes token: 20000 token_retransmits_before_loss_const: 10 join: 60 max_messages: 20 transport: udpu interface { ringnumber: 0 Bindnetaddr: STATIC_IP_OF_THIS_HOST mcastport: 5405 ttl: 1 } } logging { fileline: off to_stderr: no to_logfile: no logfile: /var/log/cluster/corosync.log to_syslog: yes debug: off timestamp: on logger_subsys { subsys: QUORUM debug: off } } nodelist { node { ring0_addr: THIS_HOST_NAME nodeid: 1 } node { ring0_addr: OTHER_HOST_NAME nodeid: 2 } } quorum { provider: corosync_votequorum expected_votes: 2 two_node: 1 }
Sostituisci quanto segue:
STATIC_IP_OF_THIS_HOST
: specifica l'indirizzo IP interno primario statico di questa VM, come mostrato in Interfacce di rete nella console Google Cloud o visualizzato dagcloud compute instances describe VM_NAME
.THIS_HOST_NAME
: specifica il nome host di questo VM.OTHER_HOST_NAME
: specifica il nome host dell'altra VM nel cluster.
Crea un file di configurazione Corosync sull'host secondario ripetendo gli stessi passaggi utilizzati per l'host principale. A parte l'IP statico dell'HDB nella proprietà
Bindnetaddr
e l'ordine dei nomi host innodelist
, i valori delle proprietà del file di configurazione sono gli stessi per ogni host.
Inizializza il cluster
Per inizializzare il cluster:
Cambia la password per l'utente
hacluster
:#
passwd haclusterNell'host principale, come utente root, inizializza il cluster.
I seguenti comandi assegnano un nome al cluster e creano il file di configurazione
corosync.conf
:configuralo e imposta la sincronizzazione tra i nodi del cluster.#
crm cluster init --name CLUSTER_NAME --yes ssh#
crm cluster init --name CLUSTER_NAME --yes --interface eth0 csync2#
crm cluster init --name CLUSTER_NAME --yes --interface eth0 corosyncAvvia Pacemaker sull'host principale:
#
systemctl enable pacemaker#
systemctl start pacemaker
Imposta le proprietà aggiuntive del cluster
Imposta le proprietà generali del cluster:
#
crm configure property stonith-timeout="300s"#
crm configure property stonith-enabled="true"#
crm configure rsc_defaults resource-stickiness="1"#
crm configure rsc_defaults migration-threshold="3"#
crm configure op_defaults timeout="600"Quando definisci le singole risorse del cluster, i valori che definisci impostata per
resource-stickiness
emigration-threshold
sostituiscono i valori predefiniti impostati qui.Puoi visualizzare i valori predefiniti delle risorse, nonché i valori di eventuali risorse definite, inserendo
crm config show
.
Collega la VM secondaria al cluster
Dal terminale aperto sulla VM principale, partecipa e avvia il cluster sulla VM secondaria tramite SSH.
Modifica la password dell'utente
hacluster
:#
passwd haclusterDalla VM principale, esegui le seguenti opzioni dello script
crm cluster join
sulla VM secondaria tramite SSH. Se hai configurato il cluster HA come descritto da queste istruzioni, puoi ignorare gli avvisi relativi al dispositivo watchdog.Esegui l'opzione
--yes ssh
per configuraressh
tra i nodi del cluster:#
ssh SECONDARY_VM_NAME 'crm cluster join --cluster-node PRIMARY_VM_NAME --yes ssh'Esegui l'opzione
--interface eth0 csync2
:#
ssh SECONDARY_VM_NAME 'crm cluster join --cluster-node PRIMARY_VM_NAME --yes --interface eth0 csync2'Esegui l'opzione
ssh_merge
:#
ssh SECONDARY_VM_NAME 'crm cluster join --cluster-node PRIMARY_VM_NAME --yes ssh_merge'Esegui l'opzione
cluster
:#
ssh SECONDARY_VM_NAME 'crm cluster join --cluster-node PRIMARY_VM_NAME --yes cluster'
Avvia Pacemaker sull'host secondario:
Attiva Pacemaker:
#
ssh SECONDARY_VM_NAME systemctl enable pacemakerAvvia Pacemaker:
#
ssh SECONDARY_VM_NAME systemctl start pacemaker
Su entrambi gli host come utente root, verifica che il cluster mostri entrambi i nodi:
#
crm_mon -sDovresti vedere un output simile al seguente:
CLUSTER OK: 2 nodes online, 0 resource instances configured
Configura le risorse del cluster per l'infrastruttura
Definisci le risorse gestite da Pacemaker in un cluster ad alta disponibilità. Devi definire le risorse per i seguenti componenti del cluster:
- Il dispositivo di recinzione, che impedisce gli scenari di split brain
- Directory ASCS ed ERS nel file system condiviso
- I controlli di integrità
- VIP
- Componenti ASCS ed ERS
Le risorse per i componenti ASCS ed ERS verranno definite in un secondo momento rispetto alle altre perché devi prima installare SAP NetWeaver.
Abilita modalità di manutenzione
Su entrambi gli host, come utente root, imposta il cluster in modalità di manutenzione:
#
crm configure property maintenance-mode="true"Conferma la modalità di manutenzione:
#
crm statusL'output dovrebbe indicare che la gestione delle risorse è disattivata, come mostrato nell'esempio seguente:
Cluster Summary: * Stack: corosync * Current DC: nw-ha-vm-1 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum * Last updated: Fri May 14 15:26:08 2021 * Last change: Thu May 13 19:02:33 2021 by root via cibadmin on nw-ha-vm-1 * 2 nodes configured * 0 resource instances configured *** Resource management is DISABLED *** The cluster will not attempt to start, stop or recover services Node List: * Online: [ nw-ha-vm-1 nw-ha-vm-2 ] Full List of Resources: * No resources
Configurare la recinzione
La configurazione del recinto virtuale avviene definendo una risorsa del cluster con l'agente fence_gce
per ogni VM host.
Per garantire la sequenza corretta degli eventi dopo un'azione di recinzione, devi anche configurare il sistema operativo in modo da ritardare il riavvio di Corosync dopo la recinzione di una VM. Puoi anche regolare il timeout del pacemaker per i riavvii nell'account per il ritardo.
Crea le risorse del dispositivo di recinzione
Per ogni VM del cluster, crea una risorsa cluster per il dispositivo di recinzione che può 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.
Nell'host principale, come utente root, crea una risorsa cluster per un dispositivo di recinzione per la VM principale:
#
crm configure primitive FENCING_RESOURCE_PRIMARY_VM stonith:fence_gce \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s" \ params port="PRIMARY_VM_NAME" zone="PRIMARY_ZONE" \ project="CLUSTER_PROJECT_ID" \ pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30Configura la località del dispositivo di recinzione per la VM principale in modo che è attivo solo sulla VM secondaria:
#
crm configure location FENCING_LOCATION_NAME_PRIMARY_VM \ FENCING_RESOURCE_PRIMARY_VM -inf: "PRIMARY_VM_NAME"Conferma la configurazione appena creata:
#
crm config show related:FENCING_RESOURCE_PRIMARY_VMDovresti vedere un output simile al seguente esempio:
primitive FENCING_RESOURCE_PRIMARY_VM stonith:fence_gce \ op monitor interval=300s timeout=120s \ op start interval=0 timeout=60s \ params PRIMARY_VM_NAME zone=PRIMARY_ZONE project=CLUSTER_PROJECT_ID pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 location FENCING_RESOURCE_PRIMARY_VM FENCING_RESOURCE_PRIMARY_VM -inf: PRIMARY_VM_NAME
Nell'host principale come root, crea una risorsa cluster per dispositivo di scherma per la VM secondaria:
#
crm configure primitive FENCING_RESOURCE_SECONDARY_VM stonith:fence_gce \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s" \ params port="SECONDARY_VM_NAME" zone="SECONDARY_VM_ZONE" \ project="CLUSTER_PROJECT_ID" \ pcmk_reboot_timeout=300 pcmk_monitor_retries=4Configura la posizione del dispositivo di recinzione per la VM secondaria in modo che sia attivo solo sulla VM principale:
#
crm configure location FENCING_LOCATION_NAME_SECONDARY_VM \ FENCING_RESOURCE_SECONDARY_VM -inf: "SECONDARY_VM_NAME"Conferma la configurazione appena creata:
#
crm config show related:FENCING_RESOURCE_SECONDARY_VMDovresti vedere un output simile al seguente esempio:
primitive FENCING_RESOURCE_SECONDARY_VM stonith:fence_gce \ op monitor interval=300s timeout=120s \ op start interval=0 timeout=60s \ params SECONDARY_VM_NAME zone=SECONDARY_ZONE project=CLUSTER_PROJECT_ID pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 location FENCING_RESOURCE_SECONDARY_VM FENCING_RESOURCE_SECONDARY_VM -inf: SECONDARY_VM_NAME
Imposta un ritardo per il riavvio di Corosync
Su entrambi gli host, come utente root, crea un file drop-in
systemd
che ritarda l'avvio di Corosync per garantire la sequenza corretta di eventi dopo il riavvio di una VM con recinzione:systemctl edit corosync.service
Aggiungi le seguenti righe al file:
[Service] ExecStartPre=/bin/sleep 60
Salva il file ed esci dall'editor.
Ricarica la configurazione dell'amministratore di sistema.
systemctl daemon-reload
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
Se utilizzi un montaggio semplice e poi salti questa sezione perché una configurazione di montaggio semplice non utilizza risorse del file system specifiche dell'istanza. gestite dal cluster.
Dopo aver creato le directory del file system condivise, puoi per definire le risorse del cluster.
Configura le risorse del file system per le directory specifiche dell'istanza.
#
crm configure primitive ASCS_FILE_SYSTEM_RESOURCE Filesystem \ device="NFS_PATH/usrsapSIDASCSASCS_INSTANCE_NUMBER" \ directory="/usr/sap/SID/ASCSASCS_INSTANCE_NUMBER" fstype="nfs" \ op start timeout=60s interval=0 \ op stop timeout=60s interval=0 \ op monitor interval=20s timeout=40sSostituisci quanto segue:
ASCS_FILE_SYSTEM_RESOURCE
: specifica un nome per la risorsa cluster per il file system ASCS.NFS_PATH
: specifica il percorso del file system NFS per ASCS.SID
: specifica l'ID di sistema (SID). Utilizza le lettere maiuscole per tutte le lettere.ASCS_INSTANCE_NUMBER
: specifica l'istanza ASCS numero.
#
crm configure primitive ERS_FILE_SYSTEM_RESOURCE Filesystem \ device="NFS_PATH/usrsapSIDERSERS_INSTANCE_NUMBER" \ directory="/usr/sap/SID/ERSERS_INSTANCE_NUMBER" fstype="nfs" \ op start timeout=60s interval=0 \ op stop timeout=60s interval=0 \ op monitor interval=20s timeout=40sSostituisci quanto segue:
ERS_FILE_SYSTEM_RESOURCE
: specifica un nome per la risorsa cluster per il file system ERS.NFS_PATH
: specifica il percorso del file NFS per l'ERS.SID
: specifica l'ID di sistema (SID). Utilizza le lettere maiuscole per tutte le lettere.ERS_INSTANCE_NUMBER
: specifica l'istanza ASCS numero.
Conferma la configurazione appena creata:
#
crm configure show ASCS_FILE_SYSTEM_RESOURCE ERS_FILE_SYSTEM_RESOURCEDovresti vedere un output simile all'esempio seguente:
primitive ASCS_FILE_SYSTEM_RESOURCE Filesystem \ params device="NFS_PATH/usrsapSIDASCSASCS_INSTANCE_NUMBER" directory="/usr/sap/SID/ASCSASCS_INSTANCE_NUMBER" fstype=nfs \ op start timeout=60s interval=0 \ op stop timeout=60s interval=0 \ op monitor interval=20s timeout=40s primitive ERS_FILE_SYSTEM_RESOURCE Filesystem \ params device="NFS_PATH/usrsapSIDERSERS_INSTANCE_NUMBER" directory="/usr/sap/SID/ERSERS_INSTANCE_NUMBER" fstype=nfs \ op start timeout=60s interval=0 \ op stop timeout=60s interval=0 \ op monitor interval=20s timeout=40s
crea le risorse per il controllo di integrità
Configura le risorse del cluster per i controlli di integrità ASCS ed ERS:
#
crm configure primitive ASCS_HEALTH_CHECK_RESOURCE anything \ params binfile="/usr/bin/socat" \ cmdline_options="-U TCP-LISTEN:ASCS_HEALTHCHECK_PORT_NUM,backlog=10,fork,reuseaddr /dev/null" \ op monitor timeout=20s interval=10s \ op_params depth=0#
crm configure primitive ERS_HEALTH_CHECK_RESOURCE anything \ params binfile="/usr/bin/socat" \ cmdline_options="-U TCP-LISTEN:ERS_HEALTHCHECK_PORT_NUM,backlog=10,fork,reuseaddr /dev/null" \ op monitor timeout=20s interval=10s \ op_params depth=0Conferma la configurazione appena creata:
#
crm configure show ERS_HEALTH_CHECK_RESOURCE ASCS_HEALTH_CHECK_RESOURCEDovresti vedere un output simile al seguente esempio:
primitive ERS_HEALTH_CHECK_RESOURCE anything \ params binfile="/usr/bin/socat" cmdline_options="-U TCP-LISTEN:ASCS_HEALTHCHECK_PORT_NUM,backlog=10,fork,reuseaddr /dev/null" \ op monitor timeout=20s interval=10s \ op_params depth=0 primitive ASCS_HEALTH_CHECK_RESOURCE anything \ params binfile="/usr/bin/socat" cmdline_options="-U TCP-LISTEN:ERS_HEALTHCHECK_PORT_NUM,backlog=10,fork,reuseaddr /dev/null" \ op monitor timeout=20s interval=10s \ op_params depth=0
Crea le risorse VIP
Definisci le risorse del cluster per gli indirizzi VIP.
Se devi cercare l'indirizzo VIP numerico, puoi utilizzare:
gcloud compute addresses describe ASCS_VIP_NAME
--region=CLUSTER_REGION --format="value(address)"gcloud compute addresses describe ERS_VIP_NAME
--region=CLUSTER_REGION --format="value(address)"
Crea le risorse del cluster per i VIP ASCS ed ERS.
#
crm configure primitive ASCS_VIP_RESOURCE IPaddr2 \ params ip=ASCS_VIP_ADDRESS cidr_netmask=32 nic="eth0" \ op monitor interval=3600s timeout=60s#
crm configure primitive ERS_VIP_RESOURCE IPaddr2 \ params ip=ERS_VIP_ADDRESS cidr_netmask=32 nic="eth0" \ op monitor interval=3600s timeout=60sConferma la configurazione appena creata:
#
crm configure show ASCS_VIP_RESOURCE ERS_VIP_RESOURCEDovresti vedere un output simile all'esempio seguente:
primitive ASCS_VIP_RESOURCE IPaddr2 \ params ip=ASCS_VIP_ADDRESS cidr_netmask=32 nic=eth0 \ op monitor interval=3600s timeout=60s primitive ERS_VIP_RESOURCE IPaddr2 \ params ip=ERS_VIP_RESOURCE cidr_netmask=32 nic=eth0 \ op monitor interval=3600s timeout=60s
Visualizza le risorse definite
Per visualizzare tutte le risorse che hai definito finora, inserisci quanto segue :
#
crm statusDovresti vedere un output simile all'esempio seguente:
Stack: corosync Current DC: nw-ha-vm-1 (version 1.1.24+20201209.8f22be2ae-3.12.1-1.1.24+20201209.8f22be2ae) - partition with quorum Last updated: Wed May 26 19:10:10 2021 Last change: Tue May 25 23:48:35 2021 by root via cibadmin on nw-ha-vm-1 2 nodes configured 8 resource instances configured *** Resource management is DISABLED *** The cluster will not attempt to start, stop or recover services Online: [ nw-ha-vm-1 nw-ha-vm-2 ] Full list of resources: fencing-rsc-nw-aha-vm-1 (stonith:fence_gce): Stopped (unmanaged) fencing-rsc-nw-aha-vm-2 (stonith:fence_gce): Stopped (unmanaged) filesystem-rsc-nw-aha-ascs (ocf::heartbeat:Filesystem): Stopped (unmanaged) filesystem-rsc-nw-aha-ers (ocf::heartbeat:Filesystem): Stopped (unmanaged) health-check-rsc-nw-ha-ascs (ocf::heartbeat:anything): Stopped (unmanaged) health-check-rsc-nw-ha-ers (ocf::heartbeat:anything): Stopped (unmanaged) vip-rsc-nw-aha-ascs (ocf::heartbeat:IPaddr2): Stopped (unmanaged) vip-rsc-nw-aha-ers (ocf::heartbeat:IPaddr2): Stopped (unmanaged)
Se utilizzi una configurazione di montaggio semplice , vedrai un output simile al seguente esempio:
Stack: corosync Current DC: nw-ha-vm-1 (version 1.1.24+20201209.8f22be2ae-3.12.1-1.1.24+20201209.8f22be2ae) - partition with quorum Last updated: Wed Sep 26 19:10:10 2024 Last change: Tue Sep 25 23:48:35 2024 by root via cibadmin on nw-ha-vm-1 2 nodes configured 8 resource instances configured *** Resource management is DISABLED *** The cluster will not attempt to start, stop or recover services Online: [ nw-ha-vm-1 nw-ha-vm-2 ] Full list of resources: fencing-rsc-nw-aha-vm-1 (stonith:fence_gce): Stopped (unmanaged) fencing-rsc-nw-aha-vm-2 (stonith:fence_gce): Stopped (unmanaged) health-check-rsc-nw-ha-ascs (ocf::heartbeat:anything): Stopped (unmanaged) health-check-rsc-nw-ha-ers (ocf::heartbeat:anything): Stopped (unmanaged) vip-rsc-nw-aha-ascs (ocf::heartbeat:IPaddr2): Stopped (unmanaged) vip-rsc-nw-aha-ers (ocf::heartbeat:IPaddr2): Stopped (unmanaged)
Installare ASCS ed ERS
La sezione seguente illustra solo i requisiti e i consigli specifici per l'installazione di SAP NetWeaver su Google Cloud.
Per istruzioni di installazione complete, consulta la documentazione di SAP NetWeaver.
Prepararsi all'installazione
Per garantire la coerenza nel cluster e semplificare l'installazione, prima di installare i componenti ASCS ed ERS di SAP NetWeaver, definisci gli utenti, i gruppi e le autorizzazioni e metti il server secondario in modalità standby.
Disattiva la modalità di manutenzione del cluster:
#
crm configure property maintenance-mode="false"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 -RSe utilizzi un montaggio semplice ed esegui questi comandi, su entrambi i server come root. Specifica 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#
chown SID_LCadm:sapsys /sapmnt/SID -R#
chown SID_LCadm:sapsys /usr/sap/trans -R#
chown SID_LCadm:sapsys /usr/sap/SID -R#
chown SID_LCadm:sapsys /usr/sap/SID/SYSSostituisci quanto segue:
GID_SAPINST
: specifica l'ID gruppo Linux per lo strumento di provisioning SAP.GID_SAPSYS
: specifica l'ID gruppo Linux per l'utente SAPSYS.UID_SIDADM
: specifica l'ID utente Linux per amministratore del sistema SAP (SID).SID_LC
: specifica l'ID sistema (SID). Utilizza le lettere minuscole.UID_SAPADM
: specifica l'ID utente per l'agente di hosting SAP.SID
: specifica l'ID di sistema (SID). Utilizza le funzionalità di maiuscole per tutte le lettere.
Ad esempio, di seguito è riportato uno schema di numerazione pratico per GID e UID:
Group sapinst 1001 Group sapsys 1002 Group dbhshm 1003 User en2adm 2001 User sapadm 2002 User dbhadm 2003
Installazione del componente ASCS
Sul server secondario, inserisci il seguente comando per metterlo in modalità standby:
#
crm_standby -v on -N ${HOSTNAME};La modalità standby del server secondario consente di consolidare tutte le risorse del cluster sul server principale, semplificando l'installazione.
Verifica che il server secondario sia in modalità standby:
#
crm statusL'output è simile all'esempio seguente:
Stack: corosync Current DC: nw-ha-vm-1 (version 1.1.24+20201209.8f22be2ae-3.12.1-1.1.24+20201209.8f22be2ae) - partition with quorum Last updated: Thu May 27 17:45:16 2021 Last change: Thu May 27 17:45:09 2021 by root via crm_attribute on nw-ha-vm-2 2 nodes configured 8 resource instances configured Node nw-ha-vm-2: standby Online: [ nw-ha-vm-1 ] Full list of resources: fencing-rsc-nw-aha-vm-1 (stonith:fence_gce): Stopped fencing-rsc-nw-aha-vm-2 (stonith:fence_gce): Started nw-ha-vm-1 filesystem-rsc-nw-aha-scs (ocf::heartbeat:Filesystem): Started nw-ha-vm-1 filesystem-rsc-nw-aha-ers (ocf::heartbeat:Filesystem): Started nw-ha-vm-1 health-check-rsc-nw-ha-scs (ocf::heartbeat:anything): Started nw-ha-vm-1 health-check-rsc-nw-ha-ers (ocf::heartbeat:anything): Started nw-ha-vm-1 vip-rsc-nw-aha-scs (ocf::heartbeat:IPaddr2): Started nw-ha-vm-1 vip-rsc-nw-aha-ers (ocf::heartbeat:IPaddr2): Started nw-ha-vm-1
Se utilizzi un montaggio semplice dell'output, l'output è simile seguenti:
Stack: corosync Current DC: nw-ha-vm-1 (version 1.1.24+20201209.8f22be2ae-3.12.1-1.1.24+20201209.8f22be2ae) - partition with quorum Last updated: Wed Sep 26 19:30:10 2024 Last change: Tue Sep 25 23:58:35 2024 by root via crm_attribute on nw-ha-vm-2 2 nodes configured 8 resource instances configured Node nw-ha-vm-2: standby Online: [ nw-ha-vm-1 ] Full list of resources: fencing-rsc-nw-aha-vm-1 (stonith:fence_gce): Stopped fencing-rsc-nw-aha-vm-2 (stonith:fence_gce): Started nw-ha-vm-1 health-check-rsc-nw-ha-scs (ocf::heartbeat:anything): Started nw-ha-vm-1 health-check-rsc-nw-ha-ers (ocf::heartbeat:anything): Started nw-ha-vm-1 vip-rsc-nw-aha-scs (ocf::heartbeat:IPaddr2): Started nw-ha-vm-1 vip-rsc-nw-aha-ers (ocf::heartbeat:IPaddr2): Started nw-ha-vm-1
Sul server principale come utente root, modifica la directory in un directory di installazione temporanea, ad esempio
/tmp
, per installare l'ASCS eseguendo 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 usareSAPINST_REMOTE_ACCESS_USER
.Quando avvii SWPM, utilizza il parametro
SAPINST_USE_HOSTNAME
per specificare il nome dell'host virtuale che hai definito per l'indirizzo VIP ASCS nel file/etc/hosts
.Ad esempio:
cd /tmp; /mnt/nfs/install/SWPM/sapinst SAPINST_USE_HOSTNAME=vh-aha-scs
Nella pagina di conferma finale di SWPM, assicurati che il nome host virtuale sia risposta esatta.
Al termine della configurazione, metti fuori standby la VM secondaria modalità:
#
crm_standby -v off -N ${HOSTNAME}; # On SECONDARY
Installa il componente ERS
Sul server principale, come utente root o
SID_LCadm
, interrompi il servizio ASCS.#
su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function Stop"#
su - SID_LCadm -c "sapcontrol -nr ASCS_INSTANCE_NUMBER -function StopService"Sul server principale, inserisci questo comando per inserire la server in modalità standby:
#
crm_standby -v on -N ${HOSTNAME};L'impostazione del server principale in modalità standby consolida tutte le di risorse cluster sul server secondario, semplificando così l'installazione.
Verifica che il server principale sia in modalità standby:
#
crm statusSul server secondario, come utente root, modifica la directory in una directory di installazione temporanea, ad esempio
/tmp
, per installare l'istanza ERS eseguendo SAP Software Provisioning Manager (SWPM).Utilizza lo stesso utente e la stessa password per accedere a SWPM che hai utilizzato quando hai installato il componente ASCS.
Quando avvii SWPM, utilizza il parametro
SAPINST_USE_HOSTNAME
per specificare il nome dell'host virtuale che hai definito per l'indirizzo VIP ERS nel file/etc/hosts
.Ad esempio:
cd /tmp; /mnt/nfs/install/SWPM/sapinst SAPINST_USE_HOSTNAME=vh-aha-ers
Nella pagina di conferma finale di SWPM, assicurati che il nome host virtuale sia risposta esatta.
Rimuovi la VM principale dallo stato di standby per attivarle entrambe:
#
crm_standby -v off -N ${HOSTNAME};
Configura i servizi SAP
Devi verificare che i servizi siano configurati correttamente, controllare le impostazioni nei profili ASCS ed ERS e aggiungere l'utente SID_LCadm
al gruppo di utenti haclient
.
Conferma le voci di servizio SAP
Su entrambi i server, verifica che il file
/usr/sap/sapservices
contenga voci sia per i servizi ASCS sia per ERS. Per farlo, puoi utilizzare l'integrazione disystemV
osystemd
.Puoi aggiungere eventuali voci mancanti utilizzando il comando
sapstartsrv
con Opzionipf=PROFILE_OF_THE_SAP_INSTANCE
e-reg
.Per ulteriori informazioni su queste integrazioni, consulta le seguenti note SAP:
systemV
Di seguito è riportato un esempio delle voci per ASCS ed ERS servizi nel file
/usr/sap/sapservices
quando utilizzi Integrazione disystemV
:#
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_LCadmsystemd
Verifica che il file
/usr/sap/sapservices
contenga voci per i servizi ASCS ed ERS. Di seguito è riportato un esempio di come queste voci vengono visualizzate nel file/usr/sap/sapservices
quando utilizzi l'integrazionesystemd
: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
Disabilita l'integrazione
systemd
nelle istanze ASCS e ERS:#
systemctl disable SAPSID_ASCS_INSTANCE_NUMBER.service#
systemctl stop SAPSID_ASCS_INSTANCE_NUMBER.service#
systemctl disable SAPSID_ERS_INSTANCE_NUMBER.service#
systemctl stop SAPSID_ERS_INSTANCE_NUMBER.serviceVerifica che l'integrazione di
systemd
sia disabilitata:#
systemctl list-unit-files | grep sapUn output simile all'esempio seguente indica che l'integrazione di
systemd
è disattivata. Tieni presente che alcuni servizi, comesaphostagent
esaptune
, sono abilitati e alcuni sono disattivati.SAPSID_ASCS_INSTANCE_NUMBER.service disabled SAPSID_ERS_INSTANCE_NUMBER.service disabled saphostagent.service enabled sapinit.service generated saprouter.service disabled saptune.service enabled
Per ulteriori informazioni, consulta il documento SUSE Disabilitazione di
systemd
servizi delle istanze SAP ERS e ASCS.
Arresta i servizi SAP
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"Su ogni server, verifica che tutti i servizi siano stati 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()
Attiva sapping
e sappong
Poiché le procedure di avvio e arresto nel cluster sono gestite da Pacemaker,
devi assicurarti che sapstartsrv
non si avvii automaticamente durante
avvio di sistema. Durante l'avvio del sistema, sapping
viene eseguito prima di sapinit
, il che nasconde
i file sapservices
. Al termine di sapinit
, sappong
mostra
sapservices
file.
Per attivare questo flusso, devi abilitare i servizi systemd
sapping
e
sappong
utilizzando i seguenti comandi:
#
systemctl enable sapping sappong#
systemctl status sapping sappong
Modificare i profili ASCS ed ERS
Su entrambi i server, passa alla directory del profilo utilizzando uno dei seguenti comandi:
#
cd /usr/sap/SID/SYS/profile#
cd /sapmnt/SID/profileSe necessario, puoi trovare i nomi dei file dei profili ASCS e ERS elencando i file nella directory del profilo o utilizzando i seguenti formati:
SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME
SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME
Attiva il pacchetto
sap-suse-cluster-connector
aggiungendo le seguenti righe ai profili delle istanze ASCS ed ERS:#----------------------------------------------------------------------- # SUSE HA library #----------------------------------------------------------------------- service/halib = $(DIR_CT_RUN)/saphascriptco.so service/halib_cluster_connector = /usr/bin/sap_suse_cluster_connector
Se utilizzi ENSA1, attiva la funzione keepalive impostando quanto segue nel profilo ASCS:
enque/encni/set_so_keepalive = true
Per ulteriori informazioni, consulta la Nota SAP 1410736 - TCP/IP: impostazione keepalive predefinito.
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 il server di replica in coda" del profilo ERS, se visualizzi
Restart_Program_NN
, modifica "Restart
" in "Start
", come mostrato nell'esempio seguente.Start_Program_00 = local $(_ER) pf=$(_PFL) NR=$(SCSID)
ENSA2
Nella sezione "Avvia il server di coda SAP" del profilo ASCS, se visualizzi
Restart_Program_NN
, modifica "Restart
" in "Start
", come mostrato nell'esempio seguente.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) ...
Aggiungi l'utente sidadm
al gruppo di utenti haclient
Quando hai installato sap-suse-cluster-connector
, l'installazione ha creato
un gruppo di utenti haclient
. Per attivare SID_LCadm
per lavorare con il cluster, aggiungilo al gruppo di utenti haclient
.
Su entrambi i server, aggiungi l'utente
SID_LCadm
al Gruppo di utentihaclient
:#
usermod -aG haclient SID_LCadm
Configura le risorse del cluster per ASCS ed ERS
Come root di entrambi i server, imposta il cluster in modalità di manutenzione:
#
crm configure property maintenance-mode="true"Verifica che il cluster sia in modalità di manutenzione:
#
crm statusSe il cluster è in modalità di manutenzione, lo stato include le seguenti righe:
*** Resource management is DISABLED *** The cluster will not attempt to start, stop or recover services
Se utilizzi una configurazione Montaggio semplice, crea le risorse del cluster
sapstartsrv
per i servizi ASCS ed ERS. Se non utilizzi una configurazione di montaggio semplice, salta questo passaggio.Per ASCS, crea un file di configurazione denominato
sapstartsrv_scs.txt
con i seguenti contenuti:primitive rsc_SAPStartSrv_SID_ASCSINSTANCENUMBER ocf:suse:SAPStartSrv \ params InstanceName=SID_ASCSINSTANCE_NUMBER_ASCS_VIRTUAL_HOSTNAME
Per caricare la configurazione per ASCS, esegui il seguente comando:
#
crm configure load update sapstartsrv_scs.txtPer ERS, crea un file di configurazione denominato
sapstartsrv_ers.txt
con i seguenti contenuti:primitive rsc_SAPStartSrv_SID_ERSINSTANCENUMBER ocf:suse:SAPStartSrv \ params InstanceName=SID_ERSINSTANCE_NUMBER_ERS_VIRTUAL_HOSTNAME
Per caricare la configurazione per ERS, esegui il seguente comando:
#
crm configure load update sapstartsrv_ers.txt
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.#
crm configure primitive ASCS_INSTANCE_RESOURCE SAPInstance \ operations \$id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \ op monitor interval=11 timeout=60 on-fail=restart \ params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \ START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" \ AUTOMATIC_RECOVER=false \ meta resource-stickiness=5000 failure-timeout=60 \ migration-threshold=1 priority=10Utilizzi un montaggio semplice ed esegui questo comando :
#
crm configure primitive ASCS_INSTANCE_RESOURCE SAPInstance \ operations \$id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \ op monitor interval=11 timeout=60 on-fail=restart \ params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \ START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" \ AUTOMATIC_RECOVER=false MINIMAL_PROBE=true \ meta resource-stickiness=5000 failure-timeout=60 \ migration-threshold=1 priority=10Crea 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 parametroIS_ERS=true
indica a Pacemaker di impostare il flagrunsersSID
su1
sul nodo in cui è attivo il sistema ERS.#
crm configure primitive ERS_INSTANCE_RESOURCE SAPInstance \ operations \$id=ERS_INSTANCE_RSC_OPERATIONS_NAME \ op monitor interval=11 timeout=60 on-fail=restart \ params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \ START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" \ AUTOMATIC_RECOVER=false IS_ERS=true \ meta priority=1000Se utilizzi una configurazione di montaggio semplice, eseguite invece il seguente comando:
#
crm configure primitive ERS_INSTANCE_RESOURCE SAPInstance \ operations \$id=ERS_INSTANCE_RSC_OPERATIONS_NAME \ op monitor interval=11 timeout=60 on-fail=restart \ params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \ START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" \ AUTOMATIC_RECOVER=false MINIMAL_PROBE=true IS_ERS=true \ meta priority=1000Conferma la configurazione appena creata:
#
crm configure show ASCS_INSTANCE_RESOURCE ERS_INSTANCE_RESOURCEUn output simile all'esempio seguente:
primitive ASCS_INSTANCE_RESOURCE SAPInstance \ operations $id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \ op monitor interval=11 timeout=60 on-fail=restart \ params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false \ meta resource-stickiness=5000 failure-timeout=60 migration-threshold=1 priority=10 
 primitive ERS_INSTANCE_RESOURCE SAPInstance \ operations $id=ERS_INSTANCE_RSC_OPERATIONS_NAME \ op monitor interval=11 timeout=60 on-fail=restart \ params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false IS_ERS=true \ meta priority=1000
Se utilizzi un montaggio semplice configurazione, l'output è simile a nell'esempio seguente:
primitive ASCS_INSTANCE_RESOURCE SAPInstance \ operations $id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \ op monitor interval=11 timeout=60 on-fail=restart \ params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false MINIMAL_PROBE=true \ meta resource-stickiness=5000 failure-timeout=60 migration-threshold=1 priority=10 
 primitive ERS_INSTANCE_RESOURCE SAPInstance \ operations $id=ERS_INSTANCE_RSC_OPERATIONS_NAME \ op monitor interval=11 timeout=60 on-fail=restart \ params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false MINIMAL_PROBE=true IS_ERS=true \ meta priority=1000
ENSA2
Crea la risorsa cluster per l'istanza ASCS. Il valore di
InstanceName
è il nome del profilo dell'istanza utilizzato da SWPM generato al momento dell'installazione di ASCS.#
crm configure primitive ASCS_INSTANCE_RESOURCE SAPInstance \ operations \$id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \ op monitor interval=11 timeout=60 on-fail=restart \ params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \ START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" \ AUTOMATIC_RECOVER=false \ meta resource-stickiness=5000 failure-timeout=60Se utilizzi una configurazione di montaggio semplice, esegui invece il seguente comando:
#
crm configure primitive ASCS_INSTANCE_RESOURCE SAPInstance \ operations \$id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \ op monitor interval=11 timeout=60 on-fail=restart \ params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME \ START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" \ AUTOMATIC_RECOVER=false MINIMAL_PROBE=true \ meta resource-stickiness=5000 failure-timeout=60Crea 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.#
crm configure primitive ERS_INSTANCE_RESOURCE SAPInstance \ operations \$id=ERS_INSTANCE_RSC_OPERATIONS_NAME \ op monitor interval=11 timeout=60 on-fail=restart \ params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \ START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" \ AUTOMATIC_RECOVER=false IS_ERS=trueSe utilizzi un montaggio semplice ed esegui questo comando anziché:
#
crm configure primitive ERS_INSTANCE_RESOURCE SAPInstance \ operations \$id=ERS_INSTANCE_RSC_OPERATIONS_NAME \ op monitor interval=11 timeout=60 on-fail=restart \ params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME \ START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" \ AUTOMATIC_RECOVER=false IS_ERS=true MINIMAL_PROBE=true \ meta priority=1000Conferma la configurazione appena creata:
#
crm configure show ASCS_INSTANCE_RESOURCE ERS_INSTANCE_RESOURCEL'output è simile al seguente esempio:
primitive ASCS_INSTANCE_RESOURCE SAPInstance \ operations $id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \ op monitor interval=11 timeout=60 on-fail=restart \ params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false \ meta resource-stickiness=5000 failure-timeout=60 
 primitive ERS_INSTANCE_RESOURCE SAPInstance \ operations $id=ERS_INSTANCE_RSC_OPERATIONS_NAME \ op monitor interval=11 timeout=60 on-fail=restart \ params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false IS_ERS=true \
Se utilizzi un montaggio semplice dell'output, l'output è simile seguenti:
primitive ASCS_INSTANCE_RESOURCE SAPInstance \ operations $id=ASCS_INSTANCE_RSC_OPERATIONS_NAME \ op monitor interval=11 timeout=60 on-fail=restart \ params InstanceName=SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false MINIMAL_PROBE=true \ meta resource-stickiness=5000 failure-timeout=60 \ migration-threshold=1 priority=10 
 primitive ERS_INSTANCE_RESOURCE SAPInstance \ operations $id=ERS_INSTANCE_RSC_OPERATIONS_NAME \ op monitor interval=11 timeout=60 on-fail=restart \ params InstanceName=SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME START_PROFILE="/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME" AUTOMATIC_RECOVER=false MINIMAL_PROBE=true IS_ERS=true \ meta priority=1000
configura i gruppi di risorse e i vincoli di località
Raggruppa le risorse ASCS ed ERS. Puoi visualizzare i nomi di tutte le risorse definite in precedenza inserendo il comando
crm resource status
: Se utilizzi un montaggio semplice ed esegui questo comando:#
crm configure group ASCS_RESOURCE_GROUP ASCS_FILE_SYSTEM_RESOURCE \ ASCS_HEALTH_CHECK_RESOURCE ASCS_VIP_RESOURCE \ ASCS_INSTANCE_RESOURCE \ meta resource-stickiness=3000 Sostituisci quanto segue:#
crm configure group ASCS_RESOURCE_GROUP ASCS_SAPSTARTSRV_RESOURCE \ ASCS_HEALTH_CHECK_RESOURCE ASCS_VIP_RESOURCE \ ASCS_INSTANCE_RESOURCE \ meta resource-stickiness=3000ASCS_RESOURCE_GROUP
: specifica un nome di gruppo univoco per le risorse del cluster ASCS. Puoi garantire l'unicità utilizzando una convenzione come "SID_ASCSistanza number_group". Ad esempio:nw1_ASCS00_group
.ASCS_FILE_SYSTEM_RESOURCE
: specifica il nome di la risorsa cluster che hai definito in precedenza per il file system ASCS. Questa variabile segnaposto non è applicabile se utilizzi una configurazione di montaggio semplice.ASCS_SAPSTARTSRV_RESOURCE
: specifica il nome della risorsa del cluster che hai definito in precedenza per "sapstartsrv" dell'ASCS. Questa variabile segnaposto è applicabile solo se utilizzi una configurazione di montaggio semplice.ASCS_HEALTH_CHECK_RESOURCE
: specifica il nome della risorsa del cluster che hai definito per il controllo dell'integrità dell'ASCS in precedenza.ASCS_VIP_RESOURCE
: specifica il nome della risorsa del cluster che hai definito in precedenza per l'IP virtuale ASCS.ASCS_INSTANCE_RESOURCE
: specifica il nome della risorsa del cluster che hai definito in precedenza per l'istanza ASCS.
Se utilizzi una configurazione Montaggio semplice , esegui invece il seguente comando:#
crm configure group ERS_RESOURCE_GROUP ERS_FILE_SYSTEM_RESOURCE \ ERS_HEALTH_CHECK_RESOURCE ERS_VIP_RESOURCE \ ERS_INSTANCE_RESOURCE Sostituisci quanto segue:#
crm configure group ERS_RESOURCE_GROUP ERS_SAPSTARTSRV_RESOURCE \ ERS_HEALTH_CHECK_RESOURCE ERS_VIP_RESOURCE \ ERS_INSTANCE_RESOURCEERS_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,nw1_ERS10_group
.ERS_SAPSTARTSRV_RESOURCE
: specifica il nome di la risorsa del cluster che hai definito in precedenza per l'ERS "sapstartsrv". Questa variabile segnaposto è applicabile solo se utilizzi una variabile Configurazione del montaggio.ERS_FILE_SYSTEM_RESOURCE
: specifica il nome di la risorsa cluster definita in precedenza per il file system ERS. Questa variabile segnaposto non è applicabile se utilizzi una variabile Configurazione del montaggio.ERS_HEALTH_CHECK_RESOURCE
: specifica il nome della risorsa del cluster che hai definito per il controllo di stato ERS in precedenza.ERS_VIP_RESOURCE
: specifica il nome di la risorsa cluster che hai definito in precedenza per il VIP ERS.ERS_INSTANCE_RESOURCE
: specifica il nome della risorsa cluster che hai definito in precedenza per l'istanza ERS.
Conferma la configurazione appena creata:
#
crm configure show type:groupL'output è simile al seguente esempio:
group ERS_RESOURCE_GROUP ERS_FILE_SYSTEM_RESOURCE ERS_HEALTH_CHECK_RESOURCE ERS_VIP_RESOURCE ERS_INSTANCE_RESOURCE group ASCS_RESOURCE_GROUP ASCS_FILE_SYSTEM_RESOURCE ASCS_HEALTH_CHECK_RESOURCE ASCS_VIP_RESOURCE ASCS_INSTANCE_RESOURCE \ meta resource-stickiness=3000
Se utilizzi una configurazione di montaggio semplice, l'output è simile all'esempio seguente:
group ERS_RESOURCE_GROUP ERS_SAPSTARTSRV_RESOURCE ERS_HEALTH_CHECK_RESOURCE ERS_VIP_RESOURCE ERS_INSTANCE_RESOURCE group ASCS_RESOURCE_GROUP ASCS_SAPSTARTSRV_RESOURCE ASCS_HEALTH_CHECK_RESOURCE ASCS_VIP_RESOURCE ASCS_INSTANCE_RESOURCE
Crea i vincoli di colocation:
ENSA1
Crea un vincolo di co-locazione che impedisca alle risorse ASCS di funzionare sullo stesso server delle risorse ERS:
#
crm configure colocation PREVENT_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUPConfigura ASCS in modo che esegui il failover sul server su cui è in esecuzione ERS, come stabilito dal flag
runsersSID
uguale a1
:#
crm configure location LOC_SCS_SID_FAILOVER_TO_ERS ASCS_INSTANCE_RESOURCE \ rule 2000: runs_ers_SID eq 1Configura ASCS in modo che venga avviato prima che ERS si trasferisca sull'altro server dopo un failover:
#
crm configure order ORD_SAP_SID_FIRST_START_ASCS \ Optional: ASCS_INSTANCE_RESOURCE:start \ ERS_INSTANCE_RESOURCE:stop symmetrical=falseConferma la configurazione appena creata:
#
crm configure show type:colocation type:location type:orderDovresti vedere un output simile all'esempio seguente:
order ORD_SAP_SID_FIRST_START_ASCS Optional: ASCS_INSTANCE_RESOURCE:start ERS_INSTANCE_RESOURCE:stop symmetrical=false colocation PREVENT_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUP location LOC_SCS_SID_FAILOVER_TO_ERS ASCS_INSTANCE_RESOURCE \ rule 2000: runs_ers_SID eq 1
ENSA2
Crea un vincolo di colocation che impedisce alle risorse ASCS di in esecuzione sullo stesso server delle risorse ERS:
#
crm configure colocation PREVENT_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUPConfigura ASCS in modo che venga avviato prima che ERS si trasferisca sull'altro server dopo un failover:
#
crm configure order ORD_SAP_SID_FIRST_START_ASCS \ Optional: ASCS_INSTANCE_RESOURCE:start \ ERS_INSTANCE_RESOURCE:stop symmetrical=falseConferma la configurazione appena creata:
#
crm configure show type:colocation type:orderDovresti vedere un output simile all'esempio seguente:
colocation PREVENT_SCS_ERS_COLOC -5000: ERS_RESOURCE_GROUP ASCS_RESOURCE_GROUP order ORD_SAP_SID_FIRST_START_ASCS Optional: ASCS_INSTANCE_RESOURCE:start ERS_INSTANCE_RESOURCE:stop symmetrical=false
Disattiva la modalità di manutenzione.
#
crm configure property maintenance-mode="false"
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
- Verifica che le serrature vengano conservate
- Simula un evento di manutenzione di Compute Engine per assicurarti che la migrazione in tempo reale non attivi un failover
Controlla la configurazione del cluster
Con accesso come utente root su uno dei server, controlla su quali nodi sono in esecuzione le risorse:
#
crm statusNell'esempio seguente, le risorse ASCS sono in esecuzione sul server
nw-ha-vm-1
e le risorse ERS sono in esecuzione sul servernw-ha-vm-2
.Cluster Summary: * Stack: corosync * Current DC: nw-ha-vm-2 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum * Last updated: Thu May 20 16:58:46 2021 * Last change: Thu May 20 16:57:31 2021 by ahaadm via crm_resource on nw-ha-vm-2 * 2 nodes configured * 10 resource instances configured Node List: * Online: [ nw-ha-vm-1 nw-ha-vm-2 ] Active Resources: * fencing-rsc-nw-aha-vm-1 (stonith:fence_gce): Started nw-ha-vm-2 * fencing-rsc-nw-aha-vm-2 (stonith:fence_gce): Started nw-ha-vm-1 * Resource Group: ascs-aha-rsc-group-name: * filesystem-rsc-nw-aha-ascs (ocf::heartbeat:Filesystem): Started nw-ha-vm-1 * health-check-rsc-nw-ha-ascs (ocf::heartbeat:anything): Started nw-ha-vm-1 * vip-rsc-nw-aha-ascs (ocf::heartbeat:IPaddr2): Started nw-ha-vm-1 * ascs-aha-instance-rsc-name (ocf::heartbeat:SAPInstance): Started nw-ha-vm-1 * Resource Group: ers-aha-rsc-group-name: * filesystem-rsc-nw-aha-ers (ocf::heartbeat:Filesystem): Started nw-ha-vm-2 * health-check-rsc-nw-ha-ers (ocf::heartbeat:anything): Started nw-ha-vm-2 * vip-rsc-nw-aha-ers (ocf::heartbeat:IPaddr2): Started nw-ha-vm-2 * ers-aha-instance-rsc-name (ocf::heartbeat:SAPInstance): Started nw-ha-vm-2
Se utilizzi una configurazione di montaggio semplice , l'output è simile al seguente esempio:
Cluster Summary: * Stack: corosync * Current DC: nw-ha-vm-2 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum * Last updated: Thu Sep 20 19:44:26 2024 * Last change: Thu Sep 20 19:53:41 2024 by ahaadm via crm_resource on nw-ha-vm-2 * 2 nodes configured * 10 resource instances configured Node List: * Online: [ nw-ha-vm-1 nw-ha-vm-2 ] Active Resources: * fencing-rsc-nw-aha-vm-1 (stonith:fence_gce): Started nw-ha-vm-2 * fencing-rsc-nw-aha-vm-2 (stonith:fence_gce): Started nw-ha-vm-1 * Resource Group: ascs-aha-rsc-group-name: * SAPStartSrv-rsc-nw-aha-ascs (ocf::heartbeat:SAPStartSrv): Started nw-ha-vm-1 * health-check-rsc-nw-ha-ascs (ocf::heartbeat:anything): Started nw-ha-vm-1 * vip-rsc-nw-aha-ascs (ocf::heartbeat:IPaddr2): Started nw-ha-vm-1 * ascs-aha-instance-rsc-name (ocf::heartbeat:SAPInstance): Started nw-ha-vm-1 * Resource Group: ers-aha-rsc-group-name: * SAPStartSrv-rsc-nw-aha-ers (ocf::heartbeat:SAPStartSrv): Started nw-ha-vm-2 * health-check-rsc-nw-ha-ers (ocf::heartbeat:anything): Started nw-ha-vm-2 * vip-rsc-nw-aha-ers (ocf::heartbeat:IPaddr2): Started nw-ha-vm-2 * ers-aha-instance-rsc-name (ocf::heartbeat:SAPInstance): Started nw-ha-vm-2
Passa all'utente
SID_LCadm
:#
su - SID_LCadmControlla la configurazione del cluster. Per
INSTANCE_NUMBER
, specifica il numero di istanza dell'istanza ASCS o ERS attiva sul server in cui stai inserendo il comando:>
sapcontrol -nr INSTANCE_NUMBER -function HAGetFailoverConfigHAActive
deve essereTRUE
, come mostrato nell'esempio seguente:20.05.2021 01:33:25 HAGetFailoverConfig OK HAActive: TRUE HAProductVersion: SUSE Linux Enterprise Server for SAP Applications 15 SP2 HASAPInterfaceVersion: SUSE Linux Enterprise Server for SAP Applications 15 SP2 (sap_suse_cluster_connector 3.1.2) HADocumentation: https://www.suse.com/products/sles-for-sap/resource-library/sap-best-practices/ HAActiveNode: nw-ha-vm-1 HANodes: nw-ha-vm-1, nw-ha-vm-2
Come
SID_LCadm
, controlla se sono presenti errori nella configurazione:>
sapcontrol -nr INSTANCE_NUMBER -function HACheckConfigDovresti vedere un output simile all'esempio seguente:
20.05.2021 01:37:19 HACheckConfig OK state, category, description, comment SUCCESS, SAP CONFIGURATION, Redundant ABAP instance configuration, 0 ABAP instances detected SUCCESS, SAP CONFIGURATION, Redundant Java instance configuration, 0 Java instances detected SUCCESS, SAP CONFIGURATION, Enqueue separation, All Enqueue server separated from application server SUCCESS, SAP CONFIGURATION, MessageServer separation, All MessageServer separated from application server SUCCESS, SAP STATE, SCS instance running, SCS instance status ok SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version (vh-ascs-aha_AHA_00), SAPInstance includes is-ers patch SUCCESS, SAP CONFIGURATION, Enqueue replication (vh-ascs-aha_AHA_00), Enqueue replication enabled SUCCESS, SAP STATE, Enqueue replication state (vh-ascs-aha_AHA_00), Enqueue replication active
Sul server in cui è attivo ASCS, come
SID_LCadm
, simula un failover:>
sapcontrol -nr ASCS_INSTANCE_NUMBER -function HAFailoverToNode ""Come utente root, se segui il failover utilizzando
crm_mon
, dovresti vedere ASCS spostarsi sull'altro server, ERS arrestarsi su quel server e poi ERS spostarsi sul server su cui era in esecuzione ASCS.
Simulare un failover
Testa il cluster simulando un errore sull'host principale. Utilizza un sistema di test o esegui il test sul sistema di produzione prima di rilasciarlo per l'utilizzo.
Puoi simulare un errore in diversi modi, tra cui:
shutdown -r
(sul nodo attivo)ip link set eth0 down
echo c > /proc/sysrq-trigger
Queste istruzioni utilizzano ip link set eth0 down
per mettere offline l'interfaccia di rete, in quanto convalidano sia il failover sia il fencing.
Esegui il backup del sistema.
Con accesso come utente root sull'host con l'istanza SCS attiva, metti offline l'interfaccia di rete:
#
ip link set eth0 downRiconnettiti a uno degli host utilizzando SSH e passa all'utente root.
Inserisci
crm status
per confermare che l'host principale è ora attivo sulla VM che in precedenza conteneva l'host secondario. Il riavvio automatico è abilitato nel cluster, quindi l'host fermato si riavvierà e assumerà il ruolo di host secondario, come mostrato nell'esempio seguente.Cluster Summary: * Stack: corosync * Current DC: nw-ha-vm-2 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum * Last updated: Fri May 21 22:31:32 2021 * Last change: Thu May 20 20:36:36 2021 by ahaadm via crm_resource on nw-ha-vm-1 * 2 nodes configured * 10 resource instances configured Node List: * Online: [ nw-ha-vm-1 nw-ha-vm-2 ] Full List of Resources: * fencing-rsc-nw-aha-vm-1 (stonith:fence_gce): Started nw-ha-vm-2 * fencing-rsc-nw-aha-vm-2 (stonith:fence_gce): Started nw-ha-vm-1 * Resource Group: scs-aha-rsc-group-name: * filesystem-rsc-nw-aha-scs (ocf::heartbeat:Filesystem): Started nw-ha-vm-2 * health-check-rsc-nw-ha-scs (ocf::heartbeat:anything): Started nw-ha-vm-2 * vip-rsc-nw-aha-scs (ocf::heartbeat:IPaddr2): Started nw-ha-vm-2 * scs-aha-instance-rsc-name (ocf::heartbeat:SAPInstance): Started nw-ha-vm-2 * Resource Group: ers-aha-rsc-group-name: * filesystem-rsc-nw-aha-ers (ocf::heartbeat:Filesystem): Started nw-ha-vm-1 * health-check-rsc-nw-ha-ers (ocf::heartbeat:anything): Started nw-ha-vm-1 * vip-rsc-nw-aha-ers (ocf::heartbeat:IPaddr2): Started nw-ha-vm-1 * ers-aha-instance-rsc-name (ocf::heartbeat:SAPInstance): Started nw-ha-vm-1
Se utilizzi una configurazione di montaggio semplice, vedrai un output simile al seguente:
Cluster Summary: * Stack: corosync * Current DC: nw-ha-vm-2 (version 2.0.4+20200616.2deceaa3a-3.3.1-2.0.4+20200616.2deceaa3a) - partition with quorum * Last updated: Wed Sep 26 19:10:10 2024 * Last change: Tue Sep 25 23:48:35 2024 by ahaadm via crm_resource on nw-ha-vm-1 * 2 nodes configured * 10 resource instances configured Node List: * Online: [ nw-ha-vm-1 nw-ha-vm-2 ] Full List of Resources: * fencing-rsc-nw-aha-vm-1 (stonith:fence_gce): Started nw-ha-vm-2 * fencing-rsc-nw-aha-vm-2 (stonith:fence_gce): Started nw-ha-vm-1 * Resource Group: scs-aha-rsc-group-name: * SAPStartSrv-rsc-nw-aha-scs (ocf::heartbeat:SAPStartSrv): Started nw-ha-vm-2 * health-check-rsc-nw-ha-scs (ocf::heartbeat:anything): Started nw-ha-vm-2 * vip-rsc-nw-aha-scs (ocf::heartbeat:IPaddr2): Started nw-ha-vm-2 * scs-aha-instance-rsc-name (ocf::heartbeat:SAPInstance): Started nw-ha-vm-2 * Resource Group: ers-aha-rsc-group-name: * SAPStartSrv-rsc-nw-aha-ers (ocf::heartbeat:SAPStartSrv): Started nw-ha-vm-1 * health-check-rsc-nw-ha-ers (ocf::heartbeat:anything): Started nw-ha-vm-1 * vip-rsc-nw-aha-ers (ocf::heartbeat:IPaddr2): Started nw-ha-vm-1 * ers-aha-instance-rsc-name (ocf::heartbeat:SAPInstance): Started nw-ha-vm-1
Conferma che le voci di blocco vengono conservate
Per 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
Come
SID_LCadm
, sul server in cui è attiva l'ERS, genera voci di blocco usando il programmaenqt
:>
enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 11 NUMBER_OF_LOCKSCome
SID_LCadm
, sul server in cui è attivo ASCS, verifica che le voci del blocco siano registrate:>
sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_nowSe hai creato 10 blocchi, dovresti vedere un output simile al seguente esempio:
locks_now: 10
Come
SID_LCadm
, sul server in cui è attiva l'ERS, avvia la funzione di monitoraggio,OpCode=20
, del programmaenqt
:>
enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 20 1 1 9999Ad esempio:
>
enqt pf=/sapmnt/AHA/profile/AHA_ERS10_vh-ers-aha 20 1 1 9999Se ASCS è attivo, riavvia il server.
Sul server di monitoraggio, quando Pacemaker interrompe ERS per spostarlo sull'altro server, dovresti visualizzare 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
Quando il monitoraggio di
enqt
si interrompe, esci dal monitoraggio inserendoCtrl + c
.Se vuoi, come utente root su uno dei server, monitora il failover del cluster:
#
crm_monIn qualità di
SID_LCadm
, dopo aver verificato che le serrature sono state trattene, rilasciale:>
enqt pf=/PATH_TO_PROFILE/SID_ERSERS_INSTANCE_NUMBER_ERS_VIRTUAL_HOST_NAME 12 NUMBER_OF_LOCKSCome
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
Come
SID_LCadm
, sul server in cui è attivo ASCS, genera voci di blocco usando il programmaenq_adm
:>
enq_admin --set_locks=NUMBER_OF_LOCKS:X:DIAG::TAB:%u pf=/PATH_TO_PROFILE/SID_ASCSASCS_INSTANCE_NUMBER_ASCS_VIRTUAL_HOST_NAMECome
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_nowSe hai creato 10 blocchi, dovresti vedere un output simile al seguente esempio:
locks_now: 10
Se ERS è attivo, verifica che le voci di blocco siano state replicate:
>
sapcontrol -nr ERS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_nowIl numero di blocchi restituiti deve essere lo stesso dell'istanza ASCS.
Se ASCS è attivo, riavvia il server.
Se vuoi, come utente root su uno dei server, monitora il failover del cluster:
#
crm_monCome
SID_LCadm
, sul server su cui è stato riavviato ASCS, verifica che le voci di blocco siano state conservate:>
sapcontrol -nr ASCS_INSTANCE_NUMBER -function EnqGetStatistic | grep locks_nowCome
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_NAMECome
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_nowDovresti vedere un output simile all'esempio riportato di seguito:
locks_now: 0
Simulare un evento di manutenzione Compute Engine
Simula un evento di manutenzione di Compute Engine per assicurarti che la migrazione live non attivi un failover.
I valori di timeout e intervallo utilizzati in queste istruzioni tengono conto della durata delle migrazioni in tempo reale. Se utilizzi valori più corti configurazione del cluster, il rischio che la migrazione live un failover è maggiore.
Per testare la tolleranza del cluster per la migrazione in tempo reale:
Sul nodo primario, attiva un evento di manutenzione simulato utilizzando seguente comando gcloud CLI:
#
gcloud compute instances simulate-maintenance-event PRIMARY_VM_NAMEVerifica che il nodo primario non cambi:
#
crm status
Valutare 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. In questo modo puoi migliorare la qualità, le prestazioni e l'affidabilità dei tuoi carichi di lavoro.
Per informazioni sulle best practice supportate da Workload Manager per la valutazione dei carichi di lavoro SAP NetWeaver con disponibilità elevata in esecuzione su Google Cloud, consulta le 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 sezione Risoluzione dei problemi relativi alle 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 con i cluster ad alta disponibilità per SAP NetWeaver, raccogli le informazioni di diagnostica necessarie e contatta l'assistenza clienti Google Cloud.
Per raccogliere le informazioni di diagnostica, consulta Informazioni di diagnostica sui cluster ad alta disponibilità su SLES.Assistenza
Per 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 il problema riguarda i tuoi sistemi SAP, ti verrà consigliato di rivolgerti all'assistenza SAP.
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 problema dell'infrastruttura Google Cloud, lo trasferisce al componente Google Cloud appropriato nel proprio sistema: BC-OP-LNX-GOOGLE
o
BC-OP-NT-GOOGLE
.
Requisiti di assistenza
Prima di poter ricevere assistenza per i sistemi SAP e per l'infrastruttura e i servizi Google Cloud che utilizzano, devi soddisfare i requisiti minimi del piano di assistenza.
Per ulteriori informazioni sui requisiti minimi di assistenza per SAP Google Cloud, consulta:
- Ricevere 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 HA.
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:
Guida alla pianificazione dell'alta disponibilità per SAP NetWeaver su Google Cloud
Per ulteriori informazioni sull'amministrazione e sul monitoraggio delle VM, consulta la Guida alle operazioni di SAP NetWeaver.