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

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

Questa guida presuppone che tu abbia già una conoscenza dei concetti e delle pratiche generalmente richiesti per implementare un sistema di alta disponibilità SAP NetWeaver. Pertanto, la guida si concentra principalmente su ciò che devi sapere per implementare un sistema di questo tipo su Google Cloud.

Se vuoi saperne di più sui concetti e sulle pratiche generali necessari per implementare un sistema SAP NetWeaver HA, consulta:

Questa guida alla pianificazione si concentra esclusivamente sull'alta affidabilità per SAP NetWeaver e non riguarda l'alta affidabilità 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 HA Linux di base 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 di Standalone Enqueue Server (ENSA1), consulta Architettura di Standalone Enqueue Server (ENSA1).

L'istanza di Central Services attiva si trova sull'host principale. L'istanza Enqueue Replication Server 2 (ERS) attiva si trova sull'host secondario. Central Services ed 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 su Standalone Enqueue Server 2 nelle configurazioni HA, consulta la nota SAP 2711036 - Usage of the Standalone Enqueue Server 2 in an HA Environment.

Una configurazione HA di base per SAP NetWeaver su Google Cloud con due host, ciascuno in una zona diversa

Architettura Standalone Enqueue Server (ENSA1)

Nel seguente diagramma, l'istanza attiva di Central Services, che contiene il servizio di gestione dei blocchi o di accodamento, e l'istanza inattiva di Enqueue Replication Server (ERS) si trovano sull'host principale. L'istanza ERS attiva e l'istanza Central Services non attiva si trovano sull'host secondario. Ogni coppia di servizi centrali ed 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 di accodamento autonomo nel nodo in cui è in esecuzione il server di replica di accodamento per conservare le informazioni di blocco. Valuta la possibilità di aggiornare il sistema per utilizzare Standalone Enqueue Server 2, se la tua versione software lo supporta. Per ulteriori informazioni, consulta la nota SAP 2630416 - Supporto per Standalone Enqueue Server 2.

Una configurazione HA di base per SAP NetWeaver su Google Cloud con due host, ciascuno in una zona diversa

L'alta disponibilità dell'infrastruttura Google Cloud

Google Cloud è progettato per essere ad alta disponibilità, con un'infrastruttura ridondante di data center in tutto il mondo che contengono zone progettate per essere indipendenti l'una dall'altra. Le zone di solito dispongono di alimentazione, raffreddamento, networking e control plane isolati dalle altre zone. Se si verificasse un singolo evento di errore, nella maggior parte dei casi interesserebbe una sola zona.

In alcuni casi, potresti soddisfare i requisiti di disponibilità senza implementare tutte le misure di protezione on-premise tradizionali contro guasti hardware, di archiviazione e di rete, il che potrebbe farti risparmiare tempo e denaro.

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

Per informazioni generali su affidabilità, privacy e sicurezza di Google Cloud, consulta Affidabilità.

Opzioni di clustering HA per i sistemi SAP su Google Cloud

Definisci un cluster ad alta disponibilità per SAP NetWeaver su Google Cloud utilizzando gli stessi tipi di software di cluster HA di terze parti che potresti utilizzare in un'installazione on-premise. Il software del cluster HA monitora lo stato di integrità dei sistemi e gestisce il failover quando si verificano problemi.

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

  • Red Hat Enterprise Linux (RHEL) per SAP Solutions
  • SUSE Linux Enterprise Server (SLES) for SAP Applications
  • Clustering di failover di Windows Server

Software di clustering ad alta disponibilità Linux

Le versioni recenti di RHEL e SLES includono il supporto HA integrato che è abilitato specificamente per Google Cloud. Per verificare se la tua versione di Linux include il supporto HA abilitato per Google Cloud, cerca "GC-HA" nella tabella in Supporto dei sistemi operativi per SAP NetWeaver su Google Cloud.

Quando utilizzi installazioni basate su Oracle Database, per rendere l'istanza SAP Central Services ad alta disponibilità, devi assicurarti quanto segue:

  • Un'istanza Compute Engine che esegue Oracle Database o qualsiasi altro sistema ausiliario strettamente accoppiato deve utilizzare un sistema operativo supportato.
  • In deroga al requisito precedente, un'istanza di calcolo che esegue l'istanza di SAP Central Services come ASCS o ERS può utilizzare qualsiasi sistema operativo certificato SAP, a condizione che l'istanza di calcolo non ospiti Oracle Database o non abbia installato software Oracle.

Per ulteriori informazioni sull'esecuzione di Oracle Database con applicazioni basate su SAP NetWeaver, consulta la pagina Pianificare l'implementazione di Oracle Database per SAP NetWeaver.

Software di clustering ad alta disponibilità di Windows

Su Windows Server utilizzi il clustering di failover di Windows Server (WSFC) per creare il cluster HA, come descritto in Esecuzione del 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'implementazione VIP di route statico o IP alias.

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

Google Cloud zone, regioni e deployment HA di SAP NetWeaver

Esegui il deployment dei nodi del cluster HA in due o più zone 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 guasto zonale.

Mantenere le zone all'interno della stessa regione garantisce che i nodi siano sufficientemente vicini geograficamente per soddisfare i requisiti di latenza SAP per i sistemi ad alta disponibilità.

Macchine virtuali Compute Engine e deployment HA di SAP NetWeaver

Per supportare l'alta disponibilità, le VM Compute Engine sono supportate dalla migrazione live e dal 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, la mantiene in esecuzione durante la migrazione. Non è richiesto alcun intervento da parte dell'utente.

In caso di interruzioni gravi, potrebbe verificarsi un lieve ritardo tra il momento in cui l'istanza non è più disponibile e il momento in cui torna disponibile.

Nella maggior parte dei casi, gli eventi di migrazione live si verificano senza influire sul cluster HA. Tuttavia, testa il cluster HA simulando una migrazione live dell'host attivo dopo aver configurato il cluster HA e avviato i sistemi, soprattutto se il monitor del cluster HA è configurato con una soglia di failover bassa. Per saperne di più su come simulare un evento di migrazione live, consulta Testare le policy di disponibilità.

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

Per impostazione predefinita, le istanze standard sono impostate per la migrazione live. Ti consigliamo di non modificare questa impostazione.

Per maggiori informazioni, vedi Esegui migrazione live.

Riavvio automatico di Compute Engine

Se la tua istanza è impostata per essere terminata in caso di evento di manutenzione o se si arresta in modo anomalo a causa di un problema hardware sottostante, puoi configurare Compute Engine per riavviare automaticamente l'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, consulta la sezione Riavvio automatico.

Opzioni di archiviazione condivisa per sistemi SAP HA su Google Cloud

Il file system globale SAP NetWeaver è un unico punto di errore che deve essere disponibile per tutte le istanze SAP NetWeaver nel sistema HA. Per garantire la disponibilità del file system globale su Google Cloud, puoi utilizzare uno spazio di archiviazione condiviso a disponibilità elevata o dischi permanenti di zona replicati.

Per una soluzione di archiviazione condivisa ad alta disponibilità, puoi utilizzare Google Cloud Filestore o soluzioni come Google Cloud NetApp Volumes o NetApp Cloud Volumes ONTAP.

Il livello regionale (in precedenza Enterprise) di Filestore può essere utilizzato per i deployment multizona ad alta disponibilità, mentre il livello Basic di Filestore può essere utilizzato per i deployment monozona.

Per la replica dei dischi permanenti di zona per i sistemi Linux, puoi utilizzare un Distributed Replicated Block Device (DRBD) per replicare i dischi permanenti che contengono il file system globale SAP tra i nodi del cluster HA.

Sebbene i dischi permanenti regionali di Compute Engine offrano l'archiviazione a blocchi replicata in modo sincrono tra le zone, non sono supportati per i sistemi SAP NetWeaver HA.

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

Opzioni di networking per i sistemi SAP HA

Quando configuri la rete per il cluster HA, 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.
  • Definisci il percorso di comunicazione tra l'istanza SAP Central Services e l'istanza Enqueue Replication Server.
  • Definisci le regole firewall per supportare i percorsi di comunicazione definiti.

Implementazione dell'IP virtuale su Google Cloud

Un cluster ad alta disponibilità utilizza un indirizzo IP mobile o virtuale (VIP) per spostare il workload da un nodo del 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 si accorgono che il lavoro viene servito da un nodo diverso.

Un VIP è anche chiamato indirizzo IP mobile.

Su Google Cloud, gli IP virtuali vengono implementati in modo leggermente diverso rispetto alle installazioni on-premise, in quanto quando si verifica un failover, le richieste ARP gratuite non possono essere utilizzate per annunciare la modifica. In alternativa, puoi implementare un indirizzo VIP per un cluster SAP HA utilizzando uno dei seguenti metodi:

Implementazioni VIP del bilanciatore del carico di rete passthrough interno

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

Il bilanciatore del carico di rete passthrough interno fornisce anche il supporto per il failover, che puoi utilizzare con i controlli di integrità di Compute Engine per rilevare gli errori, attivare il failover e reindirizzare il traffico a un nuovo sistema SAP primario in un cluster HA nativo del sistema operativo.

Il supporto del failover è l'implementazione VIP consigliata per una serie di motivi, tra cui:

  • Il bilanciamento del carico su Compute Engine offre uno SLA (accordo sul livello del servizio) con disponibilità del 99,99%.
  • Il bilanciamento del carico supporta cluster ad alta disponibilità multizona, che proteggono dai guasti di zona con tempi di failover tra zone prevedibili.
  • 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 di failover complessivi dipendono dai tempi di failover di ciascuno dei componenti del sistema HA, che possono includere host, sistemi di database, sistemi applicativi 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 le route, con il bilanciamento del carico puoi utilizzare intervalli IP della tua rete VPC, consentendoti di riservarli e configurarli 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 un'implementazione di un VIP del bilanciatore del carico, specifichi la porta host che i probe del controllo di integrità devono utilizzare per determinare l'integrità dell'host. Per un cluster SAP HA, specifica una porta host di destinazione nell'intervallo privato 49152-65535 per evitare conflitti con altri servizi. Sulla 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 di standby rimane online, il servizio di controllo di integrità e helper consente al bilanciamento del carico di indirizzare il traffico al sistema online che funge attualmente da sistema primario nel cluster.

Utilizzando il servizio helper e il reindirizzamento delle porte, puoi attivare un failover per la manutenzione software pianificata sui tuoi sistemi SAP.

Per ulteriori informazioni sul supporto del failover, vedi Configurazione del failover per i bilanciatori del carico di rete passthrough interni.

Per eseguire il deployment di un cluster HA con un'implementazione VIP del bilanciatore del carico, consulta:

Implementazioni VIP di route statiche

L'implementazione della route statica fornisce anche protezione dai guasti di zona, ma richiede l'utilizzo di un VIP al di fuori degli intervalli IP delle subnet VPC esistenti in cui risiedono le VM. Di conseguenza, devi anche assicurarti che il VIP non entri in conflitto con alcun indirizzo IP esterno nella rete estesa.

Le implementazioni di route statici possono anche introdurre complessità se utilizzate con configurazioni VPC condiviso, che hanno lo scopo di separare la configurazione di rete in un progetto host.

Se utilizzi un'implementazione di route statiche per il tuo VIP, consulta l'amministratore di rete per determinare un indirizzo IP adatto per un'implementazione di route statiche.

Implementazioni VIP IP alias

Le implementazioni VIP IP alias non sono consigliate per i deployment HA multi-zona perché, se una zona non funziona, la riallocazione dell'IP alias a un nodo in una zona diversa può essere ritardata. Implementa il VIP con un bilanciatore del carico di rete passthrough 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 HA.

Se hai cluster SAP HA multizona esistenti che utilizzano un'implementazione IP alias per l'IP virtuale, puoi eseguire la migrazione a un'implementazione del bilanciatore del carico di rete passthrough interno senza modificare l'indirizzo IP virtuale. 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 HA multizona, hanno altri casi d'uso nelle implementazioni 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 saperne di più sui VIP su Google Cloud, consulta 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 HA oppure puoi eseguire il deployment e configurare manualmente i sistemi SAP NetWeaver HA.

Per automatizzare il deployment dei sistemi SAP NetWeaver HA, completa il file di configurazione Terraform e utilizza i comandi Terraform standard per applicare le configurazioni. Per le istruzioni di implementazione, vedi:

Il metodo di deployment automatizzato esegue il deployment dell'infrastruttura per un sistema SAP NetWeaver completamente supportato da SAP e conforme alle best practice di SAP e Google Cloud. Google Cloud

Per SAP NetWeaver, il metodo di deployment automatico esegue il deployment di un cluster Linux ad alta disponibilità ottimizzato per le prestazioni che include:

  • Failover automatico.
  • Riavvio automatico.
  • Una prenotazione dell'indirizzo IP virtuale (VIP) che specifichi.
  • Supporto del failover fornito dal bilanciamento del carico TCP/UDP interno, che gestisce il routing dall'indirizzo IP virtuale (VIP) ai nodi del cluster HA.
  • Una regola firewall che consente i controlli di integrità di Compute Engine per monitorare le istanze VM nel cluster.
  • Gestore delle risorse del cluster ad alta disponibilità Pacemaker.
  • Un Google Cloud meccanismo di isolamento, l'fence_gceagente di isolamento.
  • Una VM con i volumi Persistent Disk o Hyperdisk 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, vedi: