Guida alla pianificazione della disponibilità elevata per SAP NetWeaver su Google Cloud

Questa guida fornisce una panoramica delle opzioni, dei suggerimenti e dei concetti generali che devi conoscere prima di eseguire il deployment di un sistema SAP NetWeaver ad alta disponibilità su Google Cloud.

Questa guida presuppone che tu conosca già i concetti e le pratiche generalmente richiesti per implementare un sistema ad alta disponibilità SAP NetWeaver. Pertanto, la guida si concentra principalmente su ciò che devi sapere per implementare questo sistema su Google Cloud.

Per ulteriori informazioni sui concetti e sulle pratiche generali necessari per l'implementazione di un sistema SAP NetWeaver HA, vedi:

Questa guida alla pianificazione si concentra esclusivamente sull'alta disponibilità per SAP NetWeaver e non copre l'alta disponibilità per i sistemi di database. Per informazioni su HA per SAP HANA, consulta la guida alla pianificazione dell'alta disponibilità di SAP HANA.

Architettura di deployment

Il seguente diagramma mostra un cluster HA Linux di base che utilizza il software 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 area geografica.

Il cluster utilizza SAP Standalone Enqueue Server 2 (ENSA2). Per la descrizione di un cluster che utilizza la versione precedente di ENSA1 (ENSA1 Server) in versione autonoma, consulta la sezione Architettura ENSA1 (ENSA1) autonoma.

L'istanza di Service Central attiva si trova sull'host principale. L'istanza Active Replication Server 2 (ERS) attiva è sull'host secondario. I servizi centralizzati e l'ERS hanno ciascuno il proprio indirizzo IP virtuale (VIP). Nel diagramma, "Central Services" rappresenta ABAP SAP Central Services o, per uno stack Java, SAP Central Services.

Per ulteriori informazioni sull'Enqueue Server 2 autonomo nelle configurazioni HA, consulta la Nota SAP 2711036 - Utilizzo di Enqueue Server 2 in modalità autonoma in un ambiente HA.

Una configurazione ad alta disponibilità per SAP NetWeaver su Google Cloud con due host,
ciascuno in una zona diversa

Architettura ENSA1 (Enqueue Server) autonoma

Nel diagramma seguente, l'istanza Central Services attiva, che contiene il servizio di gestione della serratura, o servizio Enqueue, e l'istanza ERS (Enqueue Server) non attiva si trovano nell'host principale. L'istanza ERS attiva e l'istanza di Servizi principali inattivi si trovano nell'host secondario. Ogni coppia Central Services e ERS ha il proprio indirizzo IP virtuale (VIP). Nel diagramma, "Central Services" rappresenta ABAP SAP Central Services o, per uno stack Java, SAP Central Services.

In caso di errore, il software di clustering ad alta disponibilità deve spostare il server Enqueue autonomo nel nodo in cui è in esecuzione il server di replica Enqueue per conservare le informazioni di blocco. Valuta la possibilità di aggiornare il tuo sistema per utilizzare Standalone Enqueue Server 2, se supportato dalla tua versione software. Per ulteriori informazioni, fai riferimento a SAP Note 2630416 - Supporto per Enqueue Server 2 in modalità autonoma.

Una configurazione ad alta disponibilità per SAP NetWeaver su Google Cloud con due host,
ciascuno in una zona diversa

L'alta disponibilità dell'infrastruttura Google Cloud

Google Cloud è altamente progettato, 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, rete e controllo isolati. Se si verificasse un singolo evento in errore, nella maggior parte dei casi ciò avrebbe una sola zona.

In alcuni casi, potresti soddisfare i requisiti di disponibilità senza implementare tutte le tradizionali misure di sicurezza on-premise contro i guasti hardware, di archiviazione e di networking, con conseguente risparmio di tempo e denaro.

Prima di progettare e implementare una strategia ad alta disponibilità su Google Cloud, consulta gli accordi sul livello del servizio Google Cloud.

Per informazioni generali sull'affidabilità, sulla privacy e sulla sicurezza di Google Cloud, consulta l'articolo Affidabilità.

Opzioni di clustering ad alta disponibilità per sistemi SAP su Google Cloud

Puoi definire un cluster ad alta disponibilità (HA) per SAP NetWeaver su Google Cloud utilizzando gli stessi tipi di software per cluster HA di terze parti che potresti utilizzare in un'installazione on-premise. Il software del cluster ad alta disponibilità monitora l'integrità dei sistemi e gestisce il failover in caso di problemi.

Puoi utilizzare diverse soluzioni software per cluster HA, ad esempio:

  • Red Hat Enterprise Linux (RHEL) per SAP Solutions
  • SUSE Linux Enterprise Server (SLES) per le applicazioni SAP
  • Cluster di failover di Windows Server

Software di clustering ad alta disponibilità Linux

Le versioni recenti di RHEL e SLES includono il supporto ad alta disponibilità integrato abilitato specificamente per Google Cloud. Per verificare se la tua versione Linux include il supporto ad alta disponibilità di Google Cloud, cerca "GCP-HA" nella tabella dell'articolo Assistenza per il sistema operativo per SAP NetWeaver su Google Cloud.

Software di clustering ad alta disponibilità di Windows

Su Windows Server utilizzi il clustering di failover di Windows Server (WSFC) per creare il cluster ad alta disponibilità, come descritto nella sezione Esecuzione del cluster 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 un'implementazione VIP di route statica.

Cloud Load Balancing utilizza i controlli di integrità per determinare il nodo attivo.

Deployment, zone e aree geografiche di Google Cloud in alta disponibilità SAP

Esegui il deployment dei nodi del tuo cluster ad alta disponibilità in due o più zone Compute Engine all'interno della stessa area geografica. Il deployment dei nodi in zone diverse garantisce che si trovino su macchine fisiche diverse e protegge anche dalla probabilità molto improbabile di un guasto a livello di zona.

Mantenere le zone all'interno della stessa area geografica assicura che i nodi siano sufficientemente geograficamente sufficienti a soddisfare i requisiti di latenza di SAP per i sistemi ad alta disponibilità.

Macchine virtuali Compute Engine e deployment SAP NetWeaver HA

Per supportare l'alta disponibilità, le VM di Compute Engine sono supportate da migrazione live e riavvio automatico.

Migrazione live di 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 dell'utente.

In caso di interruzioni gravi, potrebbe verificarsi un leggero ritardo tra il momento in cui l'istanza viene interrotta e quando è disponibile.

Nella maggior parte dei casi, gli eventi di migrazione live si verificano senza influire sul cluster ad alta disponibilità. Tuttavia, verifica il tuo cluster ad alta disponibilità simulando una migrazione live dell'host attivo dopo che è stato configurato e che i sistemi sono in esecuzione, in particolare se il monitor del cluster ad alta disponibilità è configurato con una soglia di failover bassa. Per ulteriori informazioni sulla simulazione di un evento di migrazione live, consulta Test dei criteri di disponibilità.

Un'istanza di cui è stata eseguita la migrazione è identica all'istanza originale, tra cui l'ID istanza, l'indirizzo IP privato e tutti i metadati e l'archiviazione dell'istanza.

Per impostazione predefinita, la migrazione live delle istanze standard è configurata. Sconsigliamo di modificare questa impostazione.

Per ulteriori informazioni, consulta la sezione Migrazione live.

Riavvio automatico di Compute Engine

Se la tua istanza è impostata per terminare in caso di evento di manutenzione o se si verifica un arresto anomalo a causa di un problema hardware sottostante, puoi configurare Compute Engine per riavviare automaticamente l'istanza. Per impostazione predefinita, le istanze sono riavviate automaticamente. Sconsigliamo di modificare questa impostazione.

Per ulteriori informazioni sul riavvio automatico, vedi Riavvio automatico.

Opzioni di archiviazione condivise per i sistemi SAP ad alta disponibilità su Google Cloud

Il file system globale SAP NetWeaver è un singolo punto di errore 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 spazio di archiviazione condiviso con disponibilità elevata o dischi permanenti 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 i deployment ad alta disponibilità a più zone, mentre il livello base di Filestore può essere utilizzato per i deployment a zona singola.

Per la replica dei dischi permanenti a livello di zona per i sistemi Linux, puoi utilizzare un dispositivo a blocchi replica distribuito (DRBD) per replicare i dischi permanenti che contengono il file system globale SAP tra i nodi nel tuo cluster ad alta disponibilità.

Sebbene i dischi permanenti di Compute Engine a livello di area geografica offrano archiviazione a blocchi replicata in modo sincrono tra le zone, attualmente non sono supportati per i sistemi ad alta disponibilità SAP NetWeaver.

Per saperne di più sulle opzioni di archiviazione su Google Cloud, vedi:

Opzioni di networking per i sistemi SAP ad alta disponibilità

Quando configuri la rete per il tuo cluster ad alta disponibilità, oltre a completare i passaggi descritti in Creare 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.
  • Definisci il percorso di comunicazione tra l'istanza di SAP Central Services e l'istanza di Enqueue Replication Server.
  • Definisci le regole firewall per supportare i percorsi di comunicazione definiti.

Implementazione di IP virtuali su Google Cloud

Un cluster ad alta disponibilità utilizza un indirizzo IP floating o virtuale (VIP) per spostare il carico di lavoro da un nodo cluster all'altro in caso di guasto imprevisto o per manutenzione pianificata. L'indirizzo IP dei VIP non cambia, per cui le applicazioni client non sono consapevoli che il lavoro viene pubblicato da un nodo diverso.

Il VIP è chiamato anche indirizzo IP mobile.

Su Google Cloud, i VIP vengono implementati in modo leggermente diverso rispetto a quelli delle 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 HA utilizzando uno dei seguenti metodi:

Implementazioni VIP interne di bilanciamento del carico TCP/UDP

Un bilanciatore del carico distribuisce in genere il traffico degli utenti tra più istanze delle tue applicazioni, sia per distribuire il carico di lavoro che in più sistemi attivi, e per proteggere da un rallentamento o un errore di elaborazione in ogni istanza.

Il servizio di bilanciamento del carico TCP/UDP interno fornisce anche il 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 per il failover di bilanciamento del carico TCP/UDP interno è l'implementazione VIP consigliata per diversi motivi, tra cui:

  • Il bilanciamento del carico su Compute Engine offre uno SLA del 99,99% .
  • Il bilanciamento del carico supporta cluster ad alta disponibilità multizona, che proteggono da errori della zona con tempi di failover cross-zone prevedibili.
  • L'uso del bilanciamento del carico riduce il tempo necessario per rilevare e attivare un errore, generalmente entro pochi secondi dall'errore. I tempi di failover complessivi dipendono dai tempi di failover di ciascuno dei componenti nel sistema ad alta disponibilità, che possono includere host, sistemi di database, sistemi di applicazioni e altro ancora.
  • L'uso del bilanciamento del carico semplifica la configurazione del cluster e riduce le dipendenze.
  • A differenza di un'implementazione VIP che utilizza route, con bilanciamento del carico, puoi utilizzare intervalli IP dalla tua rete VPC, in modo da poterli prenotare e configurarli in base alle esigenze.
  • Il bilanciamento del carico può essere facilmente utilizzato per reindirizzare il traffico a un sistema secondario in caso di interruzioni di manutenzione pianificate.

Quando crei un controllo di integrità per un'implementazione del bilanciatore del carico di un VIP, devi specificare la porta dell'host che il probe del controllo di integrità verifica per determinare l'integrità dell'host. Per un cluster SAP HA, specifica una porta host di destinazione nell'intervallo privato, 49152-65535, per evitare lo scontro con altri servizi. Nella VM host, configura la porta di destinazione con un servizio helper secondario, ad esempio 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 il bilanciamento del carico per 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 programmata del software sui sistemi SAP.

Per ulteriori informazioni sul supporto del failover del bilanciamento del carico TCP/UDP interno, consulta la sezione Configurare il failover per il bilanciamento del carico TCP/UDP interno.

Per eseguire il deployment di un cluster ad alta disponibilità con un'implementazione VIP del bilanciatore del carico, vedi:

Implementazioni statiche di VIP route

L'implementazione statica della route offre anche protezione contro gli errori della 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 entri in conflitto con gli indirizzi IP esterni nella rete estesa.

Le implementazioni di route statiche possono anche introdurre complessità quando vengono utilizzate con le configurazioni VPC condivise, che hanno lo scopo di segregare la configurazione di rete a un progetto host.

Se utilizzi un'implementazione di route statica per il VIP, rivolgiti all'amministratore della rete per determinare un indirizzo IP adatto per l'implementazione di una route statica.

Implementazioni VIP degli alias IP

Le implementazioni dell'IP IP alias non sono consigliate per i deployment ad alta disponibilità a più zone, perché se una zona ha esito negativo, la riassegnazione dell'IP alias a un nodo in una zona diversa può subire ritardi. Implementa il tuo VIP con un bilanciamento del carico TCP/UDP interno con supporto per il failover.

Se esegui il deployment di tutti i nodi del cluster SAP HA nella stessa zona, puoi utilizzare un IP alias per implementare un VIP per il cluster ad alta disponibilità.

Se hai già cluster cluster ad alta disponibilità SAP a più zone che utilizzano un'implementazione IP alias per il VIP, puoi eseguire la migrazione a un'implementazione del bilanciamento del carico TCP/UDP interno senza modificare l'indirizzo VIP. Sia l'IP alias che il bilanciamento del carico TCP/UDP interno utilizzano gli intervalli IP dalla rete VPC.

Gli indirizzi IP alias non sono consigliati per le implementazioni VIP nei cluster multizona, ma hanno altri casi d'uso nei deployment SAP. Ad esempio, possono essere utilizzati per fornire un nome host logico e assegnazioni di indirizzi IP per i deployment SAP flessibili, come quelli gestiti da SAP scape Management.

Best practice generali per VIP su Google Cloud

Per saperne di più 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

Per istruzioni per la configurazione di un cluster Linux ad alta disponibilità per SAP NetWeaver, consulta: