Questa guida fornisce una panoramica delle opzioni, dei suggerimenti e dei concetti generali che è necessario conoscere prima di eseguire il deployment di un sistema SAP NetWeaver ad alta disponibilità su Google Cloud.
Questa guida presuppone che tu abbia già una conoscenza dei concetti e delle pratiche generalmente necessari per implementare un sistema ad alta disponibilità SAP NetWeaver. La guida si concentra principalmente su ciò che devi sapere per implementare un sistema di questo tipo su Google Cloud.
Per saperne di più sui concetti e sulle pratiche generali necessari per implementare un sistema SAP NetWeaver ad alta disponibilità, consulta:
- Le best practice SAP documentano la creazione di un'alta disponibilità per SAP NetWeaver e SAP HANA su Linux
- Documentazione di SAP NetWeaver
Questa guida alla pianificazione è incentrata esclusivamente sull'alta disponibilità per SAP NetWeaver e non riguarda l'alta disponibilità per i sistemi di database. Per informazioni sull'alta disponibilità per SAP HANA, consulta la guida alla pianificazione dell'alta disponibilità di Sap HANA.
Architettura di deployment
Il seguente diagramma mostra un cluster Linux ad alta disponibilità che utilizza il software del cluster Pacemaker.
Il cluster include due host: un host principale e un host secondario. Ogni host si trova in una zona diversa all'interno della stessa regione.
Il cluster utilizza SAP Standalone Enqueue Server 2 (ENSA2). Per una descrizione di un cluster che utilizza la versione precedente del server di enqueue autonomo (ENSA1), vedi Architettura del server di enqueue autonomo (ENSA1).
L'istanza di Servizi centrali attiva si trova sull'host principale. L'istanza ERS (Enqueue Replication Server 2) attiva si trova sull'host secondario. Central Services ed ERS hanno ciascuno il proprio indirizzo IP virtuale (VIP). Nel diagramma, "Central Services" rappresenta i servizi centrali SAP ABAP o, per uno stack Java, i servizi centrali di SAP.
Per ulteriori informazioni sul Server di accodamento autonomo 2 nelle configurazioni ad alta disponibilità, consulta la sezione Nota SAP 2711036 - Utilizzo dell'encoda autonoma Server 2 in un ambiente ad alta disponibilità.
Architettura del server di enqueue autonomo (ENSA1)
Nel diagramma seguente, l'istanza dei Servizi centrali attiva, che contiene il servizio di gestione dei blocchi o il servizio Enqueue, e l'istanza inattiva del server di replica (ERS, Enqueue) si trovano sull'host principale. L'istanza ERS attiva e quella inattiva dei Servizi centrali si trovano sull'host secondario. Ogni coppia di servizi centrali ed ERS ha il proprio indirizzo IP virtuale (VIP). Nel diagramma, "Central Services" rappresenta i servizi centrali SAP ABAP o, per uno stack Java, i servizi centrali di SAP.
In caso di errore, il software di clustering ad alta disponibilità deve riposizionare il server di accodamento autonomo nel nodo su cui è in esecuzione il server di replica di accoda per conservare le informazioni sul blocco. Valuta la possibilità di aggiornare il sistema in modo da utilizzare il Server di accodamento autonomo 2, se la tua versione del software lo supporta. Per ulteriori informazioni, fai riferimento alla Nota SAP 2630416 - Supporto per Server Enqueue 2 autonomo.
L'alta disponibilità dell'infrastruttura Google Cloud
Google Cloud è altamente disponibile per definizione, con un'infrastruttura ridondante di data center in tutto il mondo che contengono zone progettate per essere indipendenti l'una dall'altra. In genere le zone hanno piani di alimentazione, raffreddamento, networking e controllo isolati dalle altre zone. Se si verificasse un singolo evento di errore, nella maggior parte dei casi interesserà solo una singola zona.
In alcuni casi, potresti soddisfare i requisiti di disponibilità senza implementare tutte le tradizionali misure di protezione on-premise per evitare problemi di hardware, archiviazione e networking, con conseguente risparmio in termini di tempo e denaro.
Prima di progettare e implementare la tua strategia di alta disponibilità su Google Cloud, consulta gli accordi sul livello del servizio di Google Cloud.
Per informazioni generali sull'affidabilità, la privacy e la sicurezza di Google Cloud, consulta Affidabilità.
Opzioni di clustering ad alta disponibilità per sistemi SAP su Google Cloud
Puoi definire un cluster ad alta disponibilità per SAP NetWeaver su Google Cloud utilizzando gli stessi tipi di software per cluster ad alta disponibilità che potresti utilizzare in un'installazione on-premise. Il software del cluster ad alta disponibilità monitora l'integrità dei sistemi e gestisce il failover quando si verificano problemi.
Puoi utilizzare una serie di soluzioni software per cluster ad alta disponibilità, come le seguenti:
- Red Hat Enterprise Linux (RHEL) per soluzioni SAP
- SUSE Linux Enterprise Server (SLES) per applicazioni SAP
- Clustering di failover di Windows Server
Software di clustering ad alta disponibilità Linux
Le versioni recenti sia di RHEL che di SLES includono il supporto ad alta disponibilità integrato, abilitato specificamente per Google Cloud. Per verificare se la tua versione di Linux include il supporto ad alta disponibilità abilitato per Google Cloud, cerca "GCP-HA" nella tabella in Supporto del sistema operativo per SAP NetWeaver su Google Cloud.
Software di clustering ad alta disponibilità Windows
Su Windows Server si utilizza il clustering di failover di Windows Server (WSFC) per creare il cluster ad alta disponibilità, come descritto in Esecuzione di clustering di failover di Windows Server.
Su Google Cloud, il routing del traffico in entrata al nodo attivo in un cluster WSFC è gestito da Cloud Load Balancing, che non richiede un IP alias o l'implementazione di una route statica VIP.
Cloud Load Balancing utilizza i controlli di integrità per determinare il nodo attivo.
Zone, regioni e deployment di SAP NetWeaver ad alta disponibilità Google Cloud
Esegui il deployment dei nodi del tuo cluster ad alta disponibilità in due o più zone di Compute Engine all'interno della stessa regione. Il deployment dei nodi in zone diverse garantisce che si trovino su macchine fisiche diverse e protegge anche dall'improbabile possibilità di un errore a livello di zona.
Il mantenimento delle zone all'interno della stessa regione assicura che i nodi siano sufficientemente vicini geograficamente da soddisfare i requisiti di latenza SAP per i sistemi ad alta disponibilità.
Macchine virtuali Compute Engine e deployment SAP NetWeaver ad alta disponibilità
Per supportare l'alta disponibilità, le VM di Compute Engine sono supportate da migrazione live e riavvio automatico.
Migrazione live Compute Engine
Compute Engine monitora lo stato dell'infrastruttura sottostante. Quando si verifica un evento di manutenzione dell'infrastruttura, Compute Engine esegue automaticamente la migrazione dell'istanza dall'evento e, se possibile, mantiene l'istanza in esecuzione durante la migrazione. Non è necessario alcun intervento da parte dell'utente.
In caso di interruzioni gravi, potrebbe verificarsi un leggero ritardo tra il momento in cui l'istanza non funziona e il momento in cui diventa disponibile.
Nella maggior parte dei casi, gli eventi di migrazione live si verificano senza influire sul cluster ad alta disponibilità. Tuttavia, puoi testare il tuo cluster ad alta disponibilità simulando una migrazione live dell'host attivo dopo la configurazione del cluster ad alta disponibilità e l'esecuzione dei sistemi, soprattutto se il monitoraggio del cluster ad alta disponibilità è configurato con una soglia di failover bassa. Per saperne di più su come simulare un evento di migrazione live, consulta Test dei criteri di disponibilità.
Un'istanza di cui è stata eseguita la migrazione è identica a quella originale, inclusi l'ID istanza, l'indirizzo IP privato, nonché tutti i metadati e lo spazio di archiviazione dell'istanza.
Per impostazione predefinita, le istanze standard sono impostate sulla migrazione live. Ti consigliamo di non modificare questa impostazione.
Per saperne di più, vedi Eseguire la migrazione live.
Riavvio automatico di Compute Engine
Se l'istanza è impostata per terminare quando si verifica un evento di manutenzione o se si arresta in modo anomalo a causa di un problema hardware sottostante, puoi configurare Compute Engine per il riavvio automatico dell'istanza. Per impostazione predefinita, le istanze sono impostate per il riavvio automatico. Ti consigliamo di non modificare questa impostazione.
Per saperne di più sul riavvio automatico, vedi Riavvio automatico.
Opzioni di archiviazione condivisa per sistemi SAP ad alta disponibilità su Google Cloud
Il file system globale SAP NetWeaver è un single point of failure che deve essere disponibile per tutte le istanze SAP NetWeaver nel sistema ad alta disponibilità. Per garantire la disponibilità del file system globale su Google Cloud, puoi utilizzare uno spazio di archiviazione condiviso a disponibilità elevata o dischi permanenti a livello di zona replicati.
Per una soluzione di archiviazione condivisa ad alta disponibilità, puoi utilizzare Google Cloud Filestore o soluzioni di condivisione file di terze parti come NetApp Cloud Volumes Service for Google Cloud o NetApp Cloud Volumes ONTAP.
Il livello Enterprise di Filestore può essere utilizzato per deployment ad alta disponibilità multizona, mentre il livello base di Filestore può essere utilizzato per deployment a zona singola.
Per la replica dei dischi permanenti a livello di zona per sistemi Linux, puoi utilizzare un dispositivo a blocchi distribuiti distribuiti (DRBD) per replicare i dischi permanenti che contengono il file system globale SAP tra i nodi nel cluster ad alta disponibilità.
Sebbene i dischi permanenti a livello di regione di Compute Engine offrano l'archiviazione a blocchi replicata in modo sincrono tra le zone, al momento non sono supportati per i sistemi SAP NetWeaver ad alta disponibilità.
Per ulteriori informazioni sulle opzioni di archiviazione su Google Cloud, vedi:
- Soluzioni di condivisione file per SAP su Google Cloud
- File server su Compute Engine
- Opzioni di archiviazione di Compute Engine
Opzioni di Networking per sistemi SAP ad alta disponibilità
Quando configuri la rete per il cluster ad alta disponibilità, oltre a completare i passaggi descritti in Creazione di una rete, devi completare le seguenti attività specifiche per l'alta disponibilità:
- Scegli l'implementazione VIP per i sistemi Linux, come descritto nella sezione seguente. I sistemi Windows utilizzano un bilanciatore del carico interno, che non richiede le stesse soluzioni VIP dei sistemi Linux.
- Definire il percorso di comunicazione tra l'istanza SAP Central Services e l'istanza Enqueue Replication Server.
- Definisci le regole del firewall per supportare i percorsi di comunicazione definiti.
Implementazione dell'IP virtuale su Google Cloud
Un cluster ad alta disponibilità utilizza un indirizzo IP (VIP) floating o virtuale per spostare il carico di lavoro da un nodo cluster a un altro in caso di errore imprevisto o per la manutenzione pianificata. L'indirizzo IP del VIP non cambia, quindi le applicazioni client non sono consapevoli che il lavoro è offerto da un nodo diverso.
Un VIP è definito anche indirizzo IP mobile.
Su Google Cloud, i VIP vengono implementati in modo leggermente diverso rispetto alle installazioni on-premise, in quanto, quando si verifica un failover, non è possibile utilizzare richieste ARP gratuite per annunciare la modifica. Puoi invece implementare un indirizzo VIP per un cluster SAP ad alta disponibilità utilizzando uno dei seguenti metodi:
- Supporto del failover del bilanciatore del carico di rete passthrough interno (consigliato).
- Route statiche Google Cloud.
- Indirizzi IP alias di Google Cloud.
Implementazioni VIP del bilanciatore del carico di rete passthrough interno
In genere, un bilanciatore del carico distribuisce il traffico degli utenti su più istanze delle tue applicazioni, sia per distribuire il carico di lavoro tra più sistemi attivi, sia per proteggere da un rallentamento o un errore dell'elaborazione su una qualsiasi istanza.
Il bilanciatore del carico di rete passthrough interno fornisce inoltre supporto per il failover che puoi utilizzare con i controlli di integrità di Compute Engine per rilevare errori, attivare il failover e reindirizzare il traffico a un nuovo sistema SAP principale in un cluster ad alta disponibilità nativo del sistema operativo.
Il supporto del failover è l'implementazione VIP consigliata per diversi motivi, tra cui:
- Il bilanciamento del carico su Compute Engine offre uno SLA con disponibilità del 99,99%.
- Il bilanciamento del carico supporta cluster multizona ad alta disponibilità, che proteggono da errori delle zone con tempi di failover prevedibili tra zone.
- L'utilizzo del bilanciamento del carico riduce il tempo necessario per rilevare e attivare un failover, in genere entro pochi secondi dall'errore. I tempi complessivi di failover dipendono dai tempi di failover di ciascuno dei componenti del sistema ad alta disponibilità, che può includere host, sistemi di database, sistemi di applicazioni e altro ancora.
- L'utilizzo del bilanciamento del carico semplifica la configurazione del cluster e riduce le dipendenze.
- A differenza di un'implementazione VIP che utilizza route, con il bilanciamento del carico puoi utilizzare intervalli IP dalla tua rete VPC, in modo da poterli prenotare e configurare in base alle esigenze.
- Il bilanciamento del carico può essere facilmente utilizzato per reindirizzare il traffico a un sistema secondario per interruzioni di manutenzione pianificate.
Quando crei un controllo di integrità per l'implementazione di un bilanciatore del carico di un VIP, specifichi la porta host che viene sottoposta al controllo di integrità per determinare l'integrità dell'host. Per un cluster SAP ad alta disponibilità, specifica una porta host di destinazione compresa nell'intervallo privato 49152-65535 per evitare conflitti con altri servizi. Sulla VM host, configura la porta di destinazione con un servizio helper secondario, come l'utilità socat o HAProxy.
Per i cluster di database in cui il sistema secondario in standby rimane online, il controllo di integrità e il servizio helper consentono al bilanciamento del carico di indirizzare il traffico al sistema online attualmente utilizzato come sistema principale nel cluster.
Utilizzando il servizio helper e il reindirizzamento delle porte, puoi attivare un failover per la manutenzione pianificata del software sui tuoi sistemi SAP.
Per ulteriori informazioni sul supporto del failover, consulta Configurazione del failover per bilanciatori del carico di rete passthrough interni.
Per eseguire il deployment di un cluster ad alta disponibilità con un'implementazione VIP del bilanciatore del carico, vedi:
- Terraform: guida alla configurazione dei cluster ad alta disponibilità SAP HANA
- Guida alla configurazione dei cluster ad alta disponibilità per SAP HANA su RHEL
- Guida alla configurazione dei cluster ad alta disponibilità per SAP HANA su SLES
Implementazioni VIP delle route statiche
L'implementazione della route statica fornisce anche protezione contro gli errori di zona, ma richiede l'utilizzo di un VIP al di fuori degli intervalli IP delle subnet VPC esistenti in cui si trovano le VM. Di conseguenza, devi anche assicurarti che il VIP non sia in conflitto con gli indirizzi IP esterni nella rete estesa.
Le implementazioni di route statiche possono introdurre complessità anche quando vengono utilizzate con configurazioni VPC condivise, il cui scopo è isolare la configurazione di rete in un progetto host.
Se utilizzi un'implementazione di route statica per il VIP, consulta l'amministratore di rete per determinare un indirizzo IP appropriato per un'implementazione di route statica.
Implementazioni VIP IP alias
Le implementazioni di VIP IP alias non sono consigliate per i deployment ad alta disponibilità multizona perché, in caso di errore di una zona, la riassegnazione dell'IP alias su un nodo in una zona diversa può subire ritardi. Implementa invece il VIP con un bilanciatore del carico di rete passthrough interno con supporto del failover.
Se esegui il deployment di tutti i nodi del tuo cluster SAP ad alta disponibilità nella stessa zona, puoi utilizzare un IP alias per implementare un VIP per il cluster ad alta disponibilità.
Se disponi di cluster SAP ad alta disponibilità multizona che utilizzano un'implementazione IP alias per il VIP, puoi eseguire la migrazione a un'implementazione del bilanciatore del carico di rete passthrough interno senza modificare l'indirizzo VIP. Sia gli indirizzi IP alias sia i bilanciatori del carico di rete passthrough interni utilizzano intervalli IP della tua rete VPC.
Sebbene gli indirizzi IP alias non siano consigliati per le implementazioni VIP nei cluster ad alta disponibilità a più zone, esistono altri casi d'uso nei deployment SAP. Ad esempio, possono essere utilizzati per fornire un nome host logico e assegnazioni IP per deployment SAP flessibili, come quelli gestiti da SAP Landscape Management.
Best practice generali per i VIP su Google Cloud
Per ulteriori informazioni sui VIP su Google Cloud, consulta le best practice per gli indirizzi IP mobili.
Configurazione di cluster ad alta disponibilità per SAP NetWeaver su Google Cloud
Google Cloud fornisce un file di configurazione Terraform che puoi utilizzare per automatizzare il deployment dei sistemi SAP NetWeaver ad alta disponibilità oppure puoi eseguire il deployment e configurare i sistemi SAP NetWeaver ad alta disponibilità manualmente.
Per automatizzare il deployment dei sistemi SAP NetWeaver ad alta disponibilità, devi completare il file di configurazione Terraform e utilizzare i comandi Terraform standard per applicare le configurazioni. Per istruzioni sul deployment, consulta:
- Terraform: guida alla configurazione dei cluster ad alta disponibilità per SAP NetWeaver su SLES
- Terraform: guida alla configurazione dei cluster ad alta disponibilità per SAP NetWeaver su RHEL
Il metodo di deployment automatizzato esegue il deployment dell'infrastruttura Google Cloud per un sistema SAP NetWeaver completamente supportato da SAP e conforme alle best practice di SAP e Google Cloud.
Per SAP NetWeaver, il metodo di deployment automatico esegue il deployment di un cluster Linux ad alta disponibilità e con ottimizzazione delle prestazioni che include:
- Failover automatico.
- Riavvio automatico.
- Una prenotazione dell'indirizzo IP virtuale (VIP) da te specificato.
- Supporto del failover fornito dal bilanciamento del carico TCP/UDP interno, che gestisce il routing dall'indirizzo IP virtuale (VIP) ai nodi del cluster ad alta disponibilità.
- Una regola firewall che consente ai controlli di integrità di Compute Engine di monitorare le istanze VM nel cluster.
- Il gestore delle risorse del cluster ad alta disponibilità di Pacemaker.
- Un meccanismo di scherma di Google Cloud, l'agente di scherma
fence_gce
. - Una VM con i dischi permanenti richiesti per ogni istanza SAP NetWeaver.
Per istruzioni su come eseguire il deployment e configurare manualmente un cluster ad alta disponibilità su Google Cloud per SAP NetWeaver, consulta:
- Guida alla configurazione manuale dei cluster ad alta disponibilità per SAP NetWeaver su SLES
- Guida alla configurazione manuale dei cluster ad alta disponibilità per SAP NetWeaver su RHEL