Guida alla pianificazione della disponibilità elevata 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à familiarità con i concetti e le pratiche generalmente richiesti per implementare un sistema SAP NetWeaver ad alta disponibilità. Pertanto, 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 HA, consulta:

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

Architettura di deployment

Il seguente diagramma mostra un cluster Linux HA di base che utilizza il software del cluster Pacemaker.

Il cluster include due host: uno principale e uno 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 coda autonomo (ENSA1), consulta Architettura del server di coda autonomo (ENSA1).

L'istanza di Central Services attiva si trova sull'host principale. L'istanza attiva di Enqueue Replication Server 2 (ERS) si trova sull'host secondario. I servizi centrali e 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 - Utilizzo di Standalone Enqueue Server 2 in un ambiente HA.

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

Architettura del server di coda autonomo (ENSA1)

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

Una configurazione di 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 è ad alta disponibilità per progettazione, con un'infrastruttura redundante di data center in tutto il mondo che contengono zone progettate per essere indipendenti l'una dall'altra. In genere, le zone dispongono di piani di controllo, reti, impianti di alimentazione e di raffreddamento isolati dalle altre zone. Se si verificasse un singolo evento di errore, nella maggior parte dei casi interesserebbe solo una singola zona.

In alcuni casi, potresti soddisfare i tuoi requisiti di disponibilità senza implementare tutte le salvaguardie on-premise tradizionali contro i guasti di hardware, archiviazione e reti, il che potrebbe farti risparmiare 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 su affidabilità, privacy e sicurezza di Google Cloud, consulta Affidabilità.

Opzioni di clustering HA per i 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 di cluster HA di terze parti che potresti utilizzare in un'installazione on-premise. Il software del cluster ad alta disponibilità monitora il funzionamento dei sistemi e gestisce il failover in caso di problemi.

Puoi utilizzare una serie di diverse soluzioni software per cluster HA, come ad esempio:

  • Soluzioni Red Hat Enterprise Linux (RHEL) per SAP
  • SUSE Linux Enterprise Server (SLES) per applicazioni SAP
  • Windows Server Failover Clustering

Software di clustering ad alta disponibilità Linux

Le versioni recenti di RHEL e SLES includono il supporto integrato per l'HA attivato specificamente per Google Cloud. Per verificare se la tua versione di Linux include il supporto HA 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 utilizzi il clustering di failover di Windows Server (WSFC) per creare il cluster ad alta disponibilità, come descritto in Eseguire il 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 l'implementazione di un alias IP o di una route VIP statica.

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

Zone, regioni e deployment SAP NetWeaver HA di Google Cloud

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 dalla possibilità molto improbabile di un errore a livello di zona.

Mantenere le zone all'interno della stessa regione garantisce che i nodi siano sufficientemente vicini dal punto di vista geografico per 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 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, mantiene l'istanza 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 si arresta e quello in cui è 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 la configurazione del cluster HA e l'esecuzione dei sistemi, soprattutto se il monitor del cluster HA è configurato con una soglia di failover bassa. Per ulteriori informazioni sulla simulazione di un evento di migrazione in tempo reale, consulta Testare i criteri 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 lo spazio di archiviazione dell'istanza.

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

Per ulteriori informazioni, consulta la sezione Eseguire la migrazione live.

Riavvio automatico di Compute Engine

Se l'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 in modo che riavvii automaticamente l'istanza. Per impostazione predefinita, le istanze sono impostate per il riavvio automatico. Ti consigliamo di non modificare questa impostazione.

Per ulteriori informazioni sul riavvio automatico, consulta la sezione Riavvio automatico.

Opzioni di archiviazione condivisa per i sistemi SAP HA 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 di disponibilità elevata. Per garantire la disponibilità del file system globale su Google Cloud, puoi utilizzare lo spazio di archiviazione condiviso ad alta disponibilità o i dischi zonali persistenti replicati.

Per una soluzione di archiviazione condivisa ad alta disponibilità, puoi utilizzare Filestore di Google Cloud o soluzioni di condivisione file di terze parti come NetApp Cloud Volumes Service per Google Cloud o NetApp Cloud Volumes ONTAP.

Il livello Enterprise di Filestore può essere utilizzato per i deployment multizona con alta disponibilità, mentre il livello di base di Filestore può essere utilizzato per i deployment monozona.

Per la replica dei dischi permanenti zonali per i sistemi Linux, puoi utilizzare un dispositivo di blocco replicato distribuito (DRBD) per replicare i dischi permanenti contenenti il file system globale SAP tra i nodi del cluster HA.

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

Per ulteriori informazioni sulle opzioni di archiviazione su Google Cloud, consulta:

Opzioni di networking per i sistemi SAP HA

Quando configuri la rete per il cluster ad alta disponibilità, oltre a completare i passaggi descritti in Creare una rete, devi completare le seguenti attività specifiche per l'HA:

  • Scegli l'implementazione di 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 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) virtuale o mobile per spostare il proprio carico di lavoro da un nodo del cluster a un altro in caso di guasto imprevisto o per la manutenzione pianificata. L'indirizzo IP del VIP non cambia, quindi le applicazioni client non sanno che il lavoro viene eseguito da un altro nodo.

Un VIP è noto anche come indirizzo IP dinamico.

Su Google Cloud, le VIP vengono implementate 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 di 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 su più sistemi attivi sia per proteggerti da un rallentamento o da un errore di elaborazione su una singola istanza.

Il bilanciatore del carico di rete passthrough interno fornisce anche il supporto del 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 principale 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 multi-zona ad alta disponibilità, che proteggono dai guasti delle zone 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 ciascun componente del sistema HA, 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 le route, con il bilanciamento del carico puoi utilizzare intervalli IP della tua rete VPC, consentendoti di prenotarli e configurarli in base alle tue esigenze.
  • Il bilanciamento del carico può essere facilmente utilizzato per reindirizzare il traffico a un sistema secondario per interruzioni pianificate per la manutenzione.

Quando crei un controllo di integrità per un'implementazione di un bilanciatore del carico di un VIP, specifica la porta dell'host che il controllo di integrità esegue per determinare l'integrità dell'host. Per un cluster SAP HA, specifica una porta host di destinazione che rientri nell'intervallo privato 49152-65535 per evitare conflitti con altri servizi. Nella VM host, configura la porta di destinazione con un servizio di assistenza secondario, ad esempio l'utilità socat o HAProxy.

Per i cluster di database in cui il sistema di riserva secondario rimane online, il servizio di controllo di integrità e di assistenza consente al bilanciamento del carico di indirizzare il traffico al sistema online che attualmente funge da sistema principale nel cluster.

Utilizzando il servizio di assistenza 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 Configurare il failover per i bilanciatori del carico di rete passthrough interni.

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

Implementazioni VIP con route statiche

L'implementazione della route statica fornisce anche protezione contro i guasti delle zone, 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 delle route statiche possono anche introdurre complessità se utilizzate con configurazioni VPC condivise, che hanno lo scopo di separare la configurazione di rete in un progetto host.

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

Implementazioni VIP IP alias

Le implementazioni VIP con alias IP 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 del failover.

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

Se disponi di cluster SAP HA multizona esistenti che utilizzano un'implementazione di IP alias per l'IP virtuale, puoi eseguire la migrazione a un'implementazione di 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 rete VPC.

Sebbene gli indirizzi IP alias non siano consigliati per le implementazioni VIP nei cluster HA multizona, hanno altri casi d'uso nei deployment SAP. Ad esempio, possono essere utilizzati per fornire un nome host logico e le 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 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 manualmente i sistemi SAP NetWeaver ad alta disponibilità.

Per automatizzare il deployment dei sistemi SAP NetWeaver HA, compila 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 automatico esegue il deployment dell'infrastruttura Google Cloud per un sistema SAP NetWeaver completamente supportato da SAP e conforme alle best practice sia di SAP sia di 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) 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 HA.
  • Una regola firewall che consenta ai controlli di integrità di Compute Engine di monitorare le istanze VM nel cluster.
  • Il gestore delle risorse del cluster ad alta disponibilità Pacemaker.
  • Un meccanismo di recinzione di Google Cloud, l'agente di recinzione 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: