Guida alla pianificazione dell'alta disponibilità SAP HANA

Questa guida fornisce una panoramica delle opzioni, dei suggerimenti e dei concetti generali da conoscere prima di eseguire il deployment di un sistema SAP HANA 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 HANA. Pertanto, la guida si concentra principalmente su ciò che devi sapere per implementare un sistema di questo tipo su Google Cloud.

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

Questa guida alla pianificazione è incentrata esclusivamente sull'alta disponibilità per SAP HANA e non riguarda l'alta disponibilità per i sistemi di applicazioni. Per informazioni su alta disponibilità per SAP NetWeaver, consulta la Guida alla pianificazione dell'alta disponibilità per SAP NetWeaver su Google Cloud.

Questa guida non sostituisce la documentazione fornita da SAP.

Opzioni ad alta disponibilità per SAP HANA su Google Cloud

Puoi utilizzare una combinazione di funzionalità di Google Cloud e SAP nella progettazione di una configurazione ad alta disponibilità per SAP HANA in grado di gestire i guasti a livello di infrastruttura o software. La seguente tabella descrive le funzionalità SAP e Google Cloud utilizzate per offrire l'alta disponibilità.

Selezione delle Descrizione
Migrazione live di Compute Engine

Compute Engine monitora lo stato dell'infrastruttura sottostante ed esegue automaticamente la migrazione dell'istanza da un evento di manutenzione dell'infrastruttura. Non è necessario alcun intervento da parte dell'utente.

Compute Engine mantiene l'istanza in esecuzione durante la migrazione, se possibile. In caso di interruzioni importanti, potrebbe verificarsi un leggero ritardo tra il momento in cui l'istanza viene arrestata e il momento in cui è disponibile.

Nei sistemi multi-host, i volumi condivisi, come il volume "/hana/shared" utilizzato nella guida al deployment, sono dischi permanenti collegati alla VM che ospita l'host master e sono montati su NFS negli host worker. Il volume NFS è inaccessibile per alcuni secondi nel caso della migrazione live dell'host master. Dopo il riavvio dell'host master, il volume NFS torna a funzionare su tutti gli host e il normale funzionamento viene ripristinato automaticamente.

Un'istanza recuperata è identica all'istanza originale, inclusi l'ID istanza, l'indirizzo IP privato, 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 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.
Riavvio automatico del servizio SAP HANA

Il riavvio automatico del servizio SAP HANA è una soluzione di ripristino dei guasti fornita da SAP.

SAP HANA ha molti servizi configurati in esecuzione sempre per varie attività. Quando uno qualsiasi di questi servizi viene disabilitato a causa di un errore del software o di un errore umano, la funzione di riavvio automatica del watchdog del servizio SAP HANA lo riavvia automaticamente. Quando il servizio viene riavviato, carica nuovamente tutti i dati necessari in memoria e riprende il funzionamento.
Backup di SAP HANA

I backup di SAP HANA creano copie dei dati del tuo database che possono essere utilizzate per ricostruire il database in un determinato momento.

Per ulteriori informazioni sull'utilizzo dei backup di SAP HANA su Google Cloud, consulta la guida alle operazioni di SAP HANA.
Replica dello spazio di archiviazione SAP HANA

La replica dello spazio di archiviazione SAP HANA fornisce supporto per il ripristino di emergenza a livello di archiviazione tramite determinati partner hardware. La replica dello spazio di archiviazione SAP HANA non è supportata su Google Cloud. Puoi invece prendere in considerazione l'utilizzo di snapshot di disco permanente di Compute Engine.

Per ulteriori informazioni sull'utilizzo degli snapshot di disco permanente per eseguire il backup di sistemi SAP HANA su Google Cloud, consulta la guida alle operazioni di SAP HANA.
Failover automatico dell'host SAP HANA

Il failover automatico dell'host SAP HANA è una soluzione di ripristino dei guasti locale che richiede uno o più host SAP HANA in standby in un sistema con scale out. Se si verifica un errore in uno degli host principali, il failover automatico dell'host mette automaticamente online l'host in standby e riavvia l'host non riuscito come host in standby.

Per ulteriori informazioni, vedi:
Replica del sistema SAP HANA

La replica del sistema SAP HANA consente di configurare uno o più sistemi che subiscano il controllo del sistema principale in scenari di alta disponibilità o di ripristino di emergenza. Puoi ottimizzare la replica per soddisfare le tue esigenze in termini di prestazioni e tempo di failover.
Opzione di riavvio rapido di SAP HANA (consigliata)

Il riavvio rapido SAP HANA riduce i tempi di riavvio in caso di terminazione di SAP HANA, ma il sistema operativo rimane in esecuzione. SAP HANA riduce i tempi di riavvio sfruttando la funzionalità della memoria permanente SAP HANA per preservare i frammenti di dati PRINCIPALI delle tabelle di archivi a colonne in DRAM mappata al file system tmpfs.

Per ulteriori informazioni sull'utilizzo dell'opzione di riavvio rapido di SAP HANA, consulta le guide al deployment ad alta disponibilità:
Hook del provider ad alta disponibilità/RE SAP HANA (consigliato)

Gli hook dei provider SAP HANA/RE consentono a SAP HANA di inviare notifiche per determinati eventi al cluster Pacemaker, migliorando così il rilevamento degli errori. Gli hook del provider ad alta disponibilità/RE di SAP HANA richiedono SAP HANA 2.0 SPS 03 o una versione successiva.

Per ulteriori informazioni sull'utilizzo degli hook del provider SAP HANA/RE, consulta le guide al deployment ad alta disponibilità:

Cluster ad alta disponibilità nativi del sistema operativo per SAP HANA su Google Cloud

Il clustering del sistema operativo Linux, consente di conoscere lo stato delle applicazioni e dei guest in merito allo stato delle applicazioni e automatizza le azioni di ripristino in caso di errore.

Sebbene i principi dei cluster ad alta disponibilità applicabili in ambienti non cloud si applichino generalmente a Google Cloud, esistono differenze nel modo in cui vengono implementate alcune cose, come la recinzione e gli IP virtuali.

Puoi utilizzare distribuzioni Linux ad alta disponibilità Red Hat o SUSE per il cluster ad alta disponibilità per SAP HANA su Google Cloud.

Per istruzioni per il deployment e la configurazione manuale di un cluster ad alta disponibilità su Google Cloud per SAP HANA, consulta:

Per le opzioni di deployment automatico fornite da Google Cloud, consulta Opzioni di deployment automatico per le configurazioni ad alta disponibilità SAP HANA.

Agenti delle risorse cluster

Sia Red Hat che SUSE forniscono agenti per le risorse di Google Cloud con le loro implementazioni ad alta disponibilità del software per cluster Pacemaker. Gli agenti delle risorse per Google Cloud gestiscono la recinzione, i VIP implementati con route o IP alias e azioni di archiviazione.

Per fornire aggiornamenti non ancora inclusi negli agenti delle risorse del sistema operativo di base, Google Cloud fornisce periodicamente agenti di risorse companion per i cluster ad alta disponibilità per SAP. Quando sono richiesti agenti di risorse companion, le procedure di deployment di Google Cloud includono un passaggio per scaricarli.

Agenti per recinzioni

Fencing, nel contesto del clustering del sistema operativo di Google Cloud Compute Engine, assume la forma di STONITH, che fornisce a ogni membro di un cluster a due nodi la possibilità di riavviare l'altro nodo.

Google Cloud fornisce due agenti di fencing da utilizzare con SAP su sistemi operativi Linux, l'agente fence_gce incluso nelle distribuzioni Red Hat e SUSE Linux più recenti e l'agente gcpstonith legacy, che puoi anche scaricare per l'utilizzo con le distribuzioni Linux che non includono l'agente fence_gce.

Autorizzazioni IAM richieste per gli agenti di fencing

Gli agenti di recinzione riavviano le VM effettuando una chiamata di reimpostazione all'API Compute Engine. Per l'autenticazione e l'autorizzazione ad accedere all'API, gli agenti fence utilizzano l'account di servizio della VM. All'account di servizio utilizzato da un agente di recinzione deve essere concesso un ruolo che includa le seguenti autorizzazioni:

  • compute.instances.get
  • compute.instances.list
  • compute.instances.reset
  • compute.instances.start
  • compute.instances.stop
  • compute.zoneOperations.get
  • logging.logEntries.create
  • compute.zoneOperations.list

Il ruolo predefinito Amministratore istanze Compute contiene tutte le autorizzazioni richieste.

Per limitare l'ambito dell'autorizzazione di riavvio dell'agente al nodo di destinazione, puoi configurare l'accesso basato sulle risorse. Per ulteriori informazioni, consulta Configurazione dell'accesso basato sulle risorse.

Indirizzo IP virtuale

I cluster ad alta disponibilità per SAP su Google Cloud utilizzano un indirizzo IP (VIP) virtuale o mobile per reindirizzare il traffico di rete da un host a un altro in caso di failover.

I deployment non cloud tipici utilizzano una richiesta ARP (Address Resolution Protocol) gratuita per annunciare lo spostamento e la riassegnazione di un VIP a un nuovo indirizzo MAC.

Su Google Cloud, invece di utilizzare richieste ARP gratuite, utilizzi uno dei vari metodi per spostare e riallocare un VIP in un cluster ad alta disponibilità. Il metodo consigliato consiste nell'utilizzare un bilanciatore del carico TCP/UDP interno, ma, a seconda delle esigenze, puoi anche utilizzare un'implementazione VIP basata su route o un'implementazione VIP basata su alias IP.

Per ulteriori informazioni sull'implementazione VIP su Google Cloud, consulta Implementazione dell'IP virtuale su Google Cloud.

Archiviazione e replica

La configurazione di un cluster SAP HANA ad alta disponibilità utilizza la replica di sistema SAP HANA sincrona per mantenere sincronizzati i database SAP HANA principali e secondari. Gli agenti di risorse standard forniti dal sistema operativo per SAP HANA gestiscono la replica del sistema durante un failover, avviando e interrompendo la replica e cambiando le istanze attive e in standby nel processo di replica.

Se hai bisogno di spazio di archiviazione file condiviso, i filer basati su NFS o SMB possono fornire la funzionalità richiesta.

Per una soluzione di archiviazione condivisa ad alta disponibilità, puoi utilizzare Filestore o una soluzione di condivisione file di terze parti come NetApp Cloud Volumes Service for Google Cloud. Il livello Enterprise di Filestore può essere utilizzato per i deployment multizona, mentre il livello base di Filestore può essere utilizzato per i deployment a zona singola.

I dischi permanenti a livello di regione di Compute Engine offrono archiviazione a blocchi replicata in modo sincrono tra le zone. Sebbene i dischi permanenti a livello di regione non siano supportati per l'archiviazione dei database nei sistemi SAP ad alta disponibilità, puoi utilizzarli con i file server NFS.

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

Impostazioni di configurazione per i cluster ad alta disponibilità su Google Cloud

Google Cloud consiglia di modificare i valori predefiniti di determinati parametri di configurazione del cluster con valori più adatti per i sistemi SAP nell'ambiente Google Cloud. Se utilizzi gli script di automazione forniti da Google Cloud, i valori consigliati sono impostati automaticamente.

Considera i valori consigliati come punto di partenza per l'ottimizzazione delle impostazioni Corosync nel cluster ad alta disponibilità. Devi confermare che la sensibilità del rilevamento degli errori e dell'attivazione del failover sono appropriate per i tuoi sistemi e carichi di lavoro nell'ambiente Google Cloud.

Valori parametro di configurazione Corosync

Nelle guide alla configurazione dei cluster ad alta disponibilità per SAP HANA, Google Cloud consiglia valori per diversi parametri della sezione totem del file di configurazione corosync.conf diversi dai valori predefiniti impostati da Corosync o dal tuo distributore Linux.

La seguente tabella mostra i parametri totem per i quali Google Cloud consiglia valori, insieme all'impatto della modifica dei valori. Per i valori predefiniti di questi parametri, che possono variare tra le distribuzioni Linux, consulta la documentazione relativa alla distribuzione Linux.
Parametro Valore consigliato Impatto della modifica del valore
secauth off Disattiva l'autenticazione e la crittografia di tutti i messaggi totem.
join 60 (ms) Aumenta il tempo di attesa del nodo per i messaggi join nel protocollo di appartenenza.
max_messages 20 Aumenta il numero massimo di messaggi che potrebbero essere inviati dal nodo dopo la ricezione del token.
token 20.000 (ms)

Aumenta il tempo di attesa del nodo per un token di protocollo totem prima che il nodo dichiari una perdita di token, presume un errore del nodo e inizi a intervenire.

L'aumento del valore del parametro token rende il cluster più tollerante a eventi infrastrutturali temporanei, come una migrazione live. Tuttavia, può anche allungare il tempo di rilevamento e ripristino da parte del cluster in caso di errore del nodo.

Il valore del parametro token determina anche il valore predefinito del parametro consensus, che controlla per quanto tempo un nodo attende il consenso prima che venga raggiunto il consenso prima di tentare di ristabilire l'appartenenza alla configurazione.

consensus N/A

Specifica, in millisecondi, quanto tempo attendere il consenso per ottenere il consenso prima di iniziare un nuovo round di configurazione dell'appartenenza.

Ti consigliamo di omettere questo parametro. Quando il parametro consensus non è specificato, Corosync imposta il suo valore su 1,2 volte il valore del parametro token. Se utilizzi il valore consigliato del parametro token di 20000, il parametro consesus viene impostato con il valore 24000.

Se specifichi esplicitamente un valore per consensus, assicurati che il valore sia 24000 o 1.2*token, a seconda di quale sia maggiore.

token_retransmits_before_loss_const 10 Aumenta il numero di ritrasmissioni del token che il nodo tenta di eseguire prima di concludere che il nodo destinatario ha esito negativo e intervenire.
transport
  • Per SLES: udpu
  • Per RHEL 8 o versioni successive: knet
  • Per RHEL 7: udpu
 Specifica il meccanismo di trasporto utilizzato da corosync.

Per ulteriori informazioni sulla configurazione del file corosync.conf, consulta la guida alla configurazione per la tua distribuzione Linux:

Impostazioni di timeout e intervallo per le risorse del cluster

Quando definisci una risorsa cluster, imposti i valori interval e timeout, in secondi, per varie operazioni sulle risorse (op). Ad esempio:

primitive rsc_SAPHanaTopology_HA1_HDB00 ocf:suse:SAPHanaTopology \
 operations \$id="rsc_sap2_HA1_HDB00-operations" \
 op monitor interval="10" timeout="600" \
 op start interval="0" timeout="600" \
 op stop interval="0" timeout="300" \
 params SID="HA1" InstanceNumber="00"

clone cln_SAPHanaTopology_HA1_HDB00 rsc_SAPHanaTopology_HA1_HDB00 \
 meta is-managed="true" clone-node-max="1" target-role="Started" interleave="true"

I valori timeout influiscono in modo diverso su ciascuna delle operazioni delle risorse, come spiegato nella tabella seguente.

Operazione risorsa Azione di timeout
monitor Se il timeout viene superato, lo stato di monitoraggio in genere segnala come non riuscito e la risorsa associata viene considerata non riuscita. Il cluster tenta di utilizzare opzioni di recupero, che possono includere un failover. Il cluster non riprova a un'operazione di monitoraggio non riuscita.
start Se una risorsa non viene avviata prima che venga raggiunto il timeout, il cluster tenta di riavviarla. Il comportamento è dettato dall'azione in caso di errore associata a una risorsa.
stop Se una risorsa non risponde a un'operazione di arresto prima che venga raggiunto il timeout, viene attivato un evento di recinzione.

Insieme ad altre impostazioni di configurazione del cluster, le impostazioni interval e timeout delle risorse del cluster influiscono sulla velocità con cui il software del cluster rileva un errore e attiva un failover.

I valori timeout e interval suggeriti da Google Cloud nelle guide alla configurazione del cluster per l'account SAP HANA per gli eventi di manutenzione di migrazione live di Compute Engine.

Indipendentemente dai valori timeout e interval che utilizzi, devi valutare i valori quando testi il cluster, in particolare durante i test della migrazione live, poiché la durata degli eventi di migrazione live può variare leggermente in base al tipo di macchina in uso e ad altri fattori, come l'utilizzo del sistema.

Impostazioni delle risorse di recinzione

Nelle guide alla configurazione dei cluster ad alta disponibilità per SAP HANA, Google Cloud consiglia diversi parametri durante la configurazione delle risorse di fencing del cluster ad alta disponibilità. I valori consigliati sono diversi da quelli predefiniti impostati da Corosync o dal tuo distributore Linux.

La seguente tabella mostra i parametri di recinzione consigliati da Google Cloud insieme ai valori consigliati e ai dettagli dei parametri. Per conoscere i valori predefiniti dei parametri, che possono variare tra le distribuzioni Linux, consulta la documentazione della distribuzione Linux.

Parametro Valore consigliato Dettagli
pcmk_reboot_timeout 300 (secondi)

Specifica il valore del timeout da utilizzare per le azioni di riavvio. Il valore pcmk_reboot_timeout deve essere maggiore della somma di quanto segue:

  • Timeout di Corosync token.
  • Timeout di Corosync consensus.
  • Il periodo di tempo necessario per completare un'operazione di riavvio, inclusi eventuali attributi di ritardo.
pcmk_monitor_retries 4 Specifica il numero massimo di tentativi di esecuzione del comando monitor entro il periodo di timeout.
pcmk_delay_max 30 (secondi)

Specifica un ritardo casuale nelle azioni di recinzione per impedire ai nodi cluster di applicare la recinzione contemporaneamente. Per evitare una corsa di recinzione garantendo che a una sola istanza venga assegnato un ritardo casuale, questo parametro deve essere abilitato solo su una delle risorse di recinzione in un cluster HANA ad alta disponibilità a due nodi (scalabilità verticale).

In un cluster HANA ad alta disponibilità con scale out, questo parametro deve essere abilitato su tutti i nodi che fanno parte di un sito (primari o secondari)

Test del cluster ad alta disponibilità su Google Cloud

Dopo la configurazione del cluster e il deployment del cluster e dei sistemi SAP HANA nel tuo ambiente di test, devi testare il cluster per confermare che il sistema ad alta disponibilità sia configurato correttamente e funzioni come previsto.

Per verificare che il failover funzioni come previsto, simula vari scenari di errore con le azioni seguenti:

  • Arresta la VM
  • Crea un panic del kernel
  • Arresta l'applicazione
  • Interrompi la rete tra le istanze

Inoltre, simula un evento di migrazione live di Compute Engine nell'host principale per verificare che non attivi un failover. Puoi simulare un evento di manutenzione utilizzando il comando Google Cloud CLI gcloud compute instances simulate-maintenance-event.

Logging e monitoraggio

Gli agenti risorse possono includere funzionalità di logging che propagano i log all'osservabilità di Google Cloud per l'analisi. Ogni agente risorsa include informazioni di configurazione che identificano le opzioni di logging. Nel caso delle implementazioni bash, l'opzione di logging è gcloud logging.

Puoi anche installare l'agente Cloud Logging per acquisire l'output di log dai processi del sistema operativo e correlare l'utilizzo delle risorse agli eventi di sistema. L'agente Logging acquisisce i log di sistema predefiniti, che includono i dati di log di Pacemaker e dei servizi di clustering. Per ulteriori informazioni, consulta Informazioni sull'agente Logging.

Per informazioni sull'utilizzo di Cloud Monitoring per configurare controlli di servizio che monitorano la disponibilità degli endpoint di servizio, consulta Gestione dei controlli di uptime.

Account di servizio e cluster ad alta disponibilità

Le azioni che il software del cluster può eseguire nell'ambiente Google Cloud sono protette dalle autorizzazioni concesse all'account di servizio di ogni VM host. Per gli ambienti ad alta sicurezza, puoi limitare le autorizzazioni negli account di servizio delle VM host per conformarti al principio del privilegio minimo.

Quando limiti le autorizzazioni dell'account di servizio, tieni presente che il tuo sistema potrebbe interagire con i servizi Google Cloud, come Cloud Storage, quindi potresti dover includere le autorizzazioni per queste interazioni di servizio nell'account di servizio della VM host.

Per le autorizzazioni più restrittive, crea un ruolo personalizzato con le autorizzazioni minime richieste. Per informazioni sui ruoli personalizzati, consulta Creazione e gestione di ruoli personalizzati. Puoi limitare ulteriormente le autorizzazioni solo a istanze specifiche di una risorsa, ad esempio le istanze VM nel cluster ad alta disponibilità, aggiungendo condizioni nelle associazioni di ruolo dei criteri IAM di una risorsa.

Le autorizzazioni minime necessarie ai sistemi dipendono dalle risorse Google Cloud a cui accedono i sistemi e dalle azioni eseguite dai sistemi. Di conseguenza, determinare le autorizzazioni minime richieste per le VM host nel cluster ad alta disponibilità potrebbe richiedere di esaminare esattamente quali risorse i sistemi su cui accedono la VM host e le azioni che quei sistemi eseguono con queste risorse.

Per iniziare, il seguente elenco mostra alcune risorse del cluster ad alta disponibilità e le autorizzazioni associate necessarie:

  • Recinzioni
    • compute.instances.list
    • compute.instances.get
    • compute.instances.reset
    • compute.instances.stop
    • compute.instances.start
    • logging.logEntries.create
    • compute.zones.list
  • VIP implementato tramite un IP alias
    • compute.instances.list
    • compute.instances.get
    • compute.zones.list
    • logging.logEntries.create
    • compute.instances.updateNetworkInterface
    • compute.zoneOperations.get
    • logging.logEntries.create
  • VIP implementato tramite route statiche
    • compute.instances.list
    • compute.instances.get
    • compute.zones.list
    • logging.logEntries.create
    • compute.routes.get
    • compute.routes.create
    • compute.routes.delete
    • compute.routes.update
    • compute.routes.list
    • compute.networks.updatePolicy
    • compute.networks.get
    • compute.globalOperations.get
    • logging.logEntries.create
  • VIP implementato tramite un bilanciatore del carico interno
    • Non sono richieste autorizzazioni specifiche: il bilanciatore del carico opera in base agli stati del controllo di integrità che non richiedono l'interazione o la modifica delle risorse in Google Cloud

Implementazione di IP virtuali su Google Cloud

Un cluster ad alta disponibilità utilizza un indirizzo IP (VIP) mobile 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 è gestito 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 possono essere utilizzate 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:

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 applicazioni, sia per distribuire il carico di lavoro su più sistemi attivi sia per proteggere da un rallentamento o un errore dell'elaborazione in qualsiasi istanza.

Il bilanciatore del carico di rete passthrough interno fornisce anche un 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 di zona 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 possono includere host, sistemi di database, sistemi applicativi e altro ancora.
  • Il 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, in modo da prenotarli 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 l'implementazione di un bilanciatore del carico di un VIP, specifichi la porta host su cui il controllo di integrità esegue il probe per determinare l'integrità dell'host. Per un cluster SAP ad alta disponibilità, specifica una porta host di destinazione che rientri 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 servizio di controllo di integrità e helper consente il bilanciamento del carico di indirizzare il traffico al sistema online che attualmente funge da 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, consulta:

Implementazioni VIP della route statica

L'implementazione delle route statiche fornisce inoltre protezione contro gli errori 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 sia in conflitto con gli indirizzi IP esterni nella rete estesa.

Le implementazioni delle route statiche possono anche introdurre complessità se utilizzate con le configurazioni di VPC condivisi, che hanno lo scopo di separare la configurazione di rete da 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 l'implementazione di una route statica.

Implementazioni VIP IP alias

Le implementazioni VIP con 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 a un nodo in una zona diversa può subire ritardi. Implementa invece il VIP con un bilanciatore del carico di rete passthrough interno che supporta il 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 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 in cluster ad alta disponibilità multizona, 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.

Failover automatico dell'host SAP HANA su Google Cloud

Google Cloud supporta il failover automatico dell'host SAP HANA, la soluzione di ripristino dei guasti locale fornita da SAP HANA. La soluzione di failover automatico dell'host utilizza uno o più host in standby mantenuti di riserva per assumere il lavoro del master o dell'host worker in caso di errore dell'host. Gli host in standby non contengono dati né elaborano alcuna attività.

Una volta completato il failover, l'host che non è riuscito viene riavviato come host in standby.

SAP supporta fino a tre host in standby nei sistemi con scale out su Google Cloud. Gli host in standby non vengono conteggiati nel numero massimo di 16 host attivi supportati da SAP nei sistemi con scale out su Google Cloud.

Per maggiori informazioni da SAP sulla soluzione di failover automatico dell'host, consulta Failover automatico dell'host.

Quando utilizzare il failover automatico dell'host SAP HANA su Google Cloud

Il failover automatico dell'host SAP HANA protegge da errori che interessano un singolo nodo in un sistema con scale out SAP HANA, inclusi gli errori di:

  • L'istanza SAP HANA
  • Il sistema operativo host
  • La VM host

Per quanto riguarda gli errori della VM host, su Google Cloud il riavvio automatico, che in genere ripristina la VM host SAP HANA più velocemente del failover automatico dell'host, e la migrazione live insieme proteggono contro le interruzioni delle VM pianificate e non pianificate. Quindi, per la protezione delle VM, non è necessaria la soluzione di failover automatico dell'host SAP HANA.

Il failover automatico dell'host SAP HANA non protegge dagli errori a livello di zona, poiché il deployment di tutti i nodi di un sistema con scale out SAP HANA viene eseguito in un'unica zona.

Il failover automatico dell'host SAP HANA non precarica i dati SAP HANA nella memoria dei nodi in standby. Di conseguenza, quando un nodo in standby prende il controllo, il tempo complessivo di ripristino dei nodi è determinato principalmente dal tempo necessario per caricare i dati nella memoria del nodo in standby.

Valuta la possibilità di utilizzare il failover automatico dell'host SAP HANA per i seguenti scenari:

  • Errori nel software o nel sistema operativo host di un nodo SAP HANA che potrebbero non essere rilevati da Google Cloud.
  • Lift and shift migrazioni, in cui è necessario riprodurre la configurazione SAP HANA on-premise finché non si può ottimizzare SAP HANA per Google Cloud.
  • Quando una configurazione interzona e ad alta disponibilità completamente replicata è proibitiva in termini di costi e la tua attività può tollerare:
    • Un tempo di recupero del nodo più lungo dovuto alla necessità di caricare i dati SAP HANA nella memoria di un nodo in standby.
    • Il rischio di errore a livello di zona.

Storage Manager per SAP HANA

I volumi /hana/data e /hana/log sono montati solo sugli host master e worker. Quando si verifica un takeover, la soluzione di failover automatico dell'host utilizza l'API SAP HANA Storage Connector e i nodi in standby di Google Cloud Gestione archiviazione per SAP HANA per spostare i montaggi dei volumi dall'host non riuscito all'host in standby.

Su Google Cloud, Gestione archiviazione per SAP HANA è obbligatorio per i sistemi SAP HANA che utilizzano il failover automatico dell'host SAP HANA.

Versioni supportate di Gestione archiviazione per SAP HANA

Sono supportate le versioni 2.0 e successive di Gestione archiviazione per SAP HANA. Tutte le versioni precedenti alla 2.0 sono deprecate e non supportate. Se utilizzi una versione precedente, aggiorna il tuo sistema SAP HANA in modo da utilizzare l'ultima versione di Gestione archiviazione per SAP HANA. Consulta Aggiornamento di Gestione archiviazione per SAP HANA.

Per determinare se la tua versione è deprecata, apri il file gceStorageClient.py. La directory di installazione predefinita è /hana/shared/gceStorageClient.

A partire dalla versione 2.0, il numero di versione è elencato nei commenti all'inizio del file gceStorageClient.py, come mostrato nell'esempio seguente. Se manca il numero di versione, significa che stai visualizzando una versione deprecata dello Gestione archiviazione per SAP HANA.

"""Google Cloud Storage Manager for SAP HANA Standby Nodes.

The Storage Manager for SAP HANA implements the API from the SAP provided
StorageConnectorClient to allow attaching and detaching of disks when
running in Compute Engine.

Build Date: Wed Jan 27 06:39:49 PST 2021
Version: 2.0.20210127.00-00

"""

Installazione di Gestione archiviazione per SAP HANA

Il metodo consigliato per installare il Gestione archiviazione per SAP HANA è utilizzare un metodo di deployment automatico per eseguire il deployment di un sistema SAP HANA con scale out che include la Gestione archiviazione più recente per SAP HANA.

Se devi aggiungere il failover automatico dell'host SAP HANA a un sistema di scale out SAP HANA esistente su Google Cloud, l'approccio consigliato è simile: utilizza il file di configurazione Terraform o il modello di Deployment Manager fornito da Google Cloud per eseguire il deployment di un nuovo sistema SAP HANA con scale out e quindi caricare i dati nel nuovo sistema dal sistema esistente. Per caricare i dati, puoi utilizzare le procedure standard di backup e ripristino di SAP HANA o la replica del sistema SAP HANA, che può limitare i tempi di inattività. Per ulteriori informazioni sulla replica del sistema, consulta la nota SAP 2473002 - Utilizzo della replica del sistema HANA per eseguire la migrazione del sistema che fa lo scale out.

Se non riesci a utilizzare un metodo di deployment automatico, potresti contattare un consulente per le soluzioni SAP, disponibile tramite i servizi di consulenza Google Cloud, per ricevere assistenza per l'installazione manuale di Gestione archiviazione per SAP HANA.

L'installazione manuale dello Gestione archiviazione per SAP HANA in un sistema SAP HANA esistente o con scale out nuovo non è attualmente documentata.

Per ulteriori informazioni sulle opzioni di deployment automatico per il failover automatico dell'host SAP HANA, consulta Deployment automatico di sistemi con scale out di SAP HANA con failover automatico dell'host SAP HANA.

Aggiornamento di Gestione archiviazione per SAP HANA

Per aggiornare il Gestione archiviazione per SAP HANA, scarica prima il pacchetto di installazione ed esegui uno script di installazione, in modo da aggiornare il Gestione archiviazione per SAP HANA nell'unità /shared SAP HANA.

La procedura seguente è solo per la versione 2 di Gestione archiviazione per SAP HANA. Se utilizzi una versione di Gestione archiviazione per SAP HANA che è stata scaricata prima del 1° febbraio 2021, installa la versione 2 prima di tentare di aggiornare lo Gestione archiviazione per SAP HANA.

Per aggiornare Gestione archiviazione per SAP HANA:

  1. Controlla la versione del tuo Gestione archiviazione attuale per SAP HANA:

    RHEL 

    sudo yum check-update google-sapgcestorageclient

    SLES 

    sudo zypper list-updates -r google-sapgcestorageclient

  2. Se è disponibile un aggiornamento, installalo:

    RHEL 

    sudo yum update google-sapgcestorageclient

    SLES 

    sudo zypper update

    Il Gestione archiviazione aggiornato per SAP HANA è installato in /usr/sap/google-sapgcestorageclient/gceStorageClient.py.

  3. Sostituisci il valore gceStorageClient.py esistente con il file gceStorageClient.py aggiornato:

    • Se il file gceStorageClient.py esistente si trova in /hana/shared/gceStorageClient, il percorso di installazione predefinito, utilizza lo script di installazione per aggiornare il file:

      sudo /usr/sap/google-sapgcestorageclient/install.sh

    • Se il file gceStorageClient.py esistente non si trova in /hana/shared/gceStorageClient, copia il file aggiornato nella stessa posizione del file esistente, sostituendo il file esistente.

Parametri di configurazione nel file global.ini

Alcuni parametri di configurazione per Gestione archiviazione per SAP HANA, incluso l'abilitazione o la disattivazione del fencing, vengono archiviati nella sezione relativa allo spazio di archiviazione del file global.ini SAP HANA. Quando utilizzi il file di configurazione Terraform o il modello Deployment Manager fornito da Google Cloud per eseguire il deployment di un sistema SAP HANA con la funzione di failover automatico dell'host, il processo di deployment aggiunge i parametri di configurazione al file global.ini.

L'esempio seguente mostra i contenuti di un oggetto global.ini creato per il Gestione archiviazione per SAP HANA:

[persistence]
basepath_datavolumes = %BASEPATH_DATAVOLUMES%
basepath_logvolumes = %BASEPATH_LOGVOLUMES%
use_mountpoints = %USE_MOUNTPOINTS%
basepath_shared = %BASEPATH_SHARED%

[storage]
ha_provider = gceStorageClient
ha_provider_path = %STORAGE_CONNECTOR_PATH%

#
# Example configuration for 2+1 setup
#
# partition_1_*__pd = node-mnt00001
# partition_2_*__pd = node-mnt00002
# partition_3_*__pd = node-mnt00003
# partition_*_data__dev = /dev/hana/data
# partition_*_log__dev = /dev/hana/log
# partition_*_data__mountOptions = -t xfs -o logbsize=256k
# partition_*_log__mountOptions = -t xfs -o logbsize=256k
# partition_*_*__fencing = disabled

[trace]
ha_gcestorageclient = info

Accesso Sudo per Gestione archiviazione per SAP HANA

Per gestire l'archiviazione e i servizi SAP HANA, Gestione archiviazione per SAP HANA utilizza l'account utente SID_LCadm e richiede l'accesso sudo a determinate linee binarie di sistema.

Se utilizzi gli script di automazione forniti da Google Cloud per eseguire il deployment di SAP HANA con failover automatico dell'host, l'accesso sudo richiesto viene configurato automaticamente.

Se installi manualmente Gestione archiviazione per SAP HANA, utilizza il comando visudo per modificare il file /etc/sudoers e concedere all'account utente SID_LCadm l'accesso sudo ai seguenti programmi binari richiesti.

Fai clic sulla scheda relativa al tuo sistema operativo:

RHEL 

/bin/kill
/bin/mount
/bin/umount
/sbin/dmsetup
/sbin/lvdisplay
/sbin/lvscan
/sbin/pvscan
/sbin/vgchange
/sbin/vgscan
/usr/bin/gcloud
/usr/bin/lsof
/usr/bin/mkdir
/usr/bin/sg_persist
/usr/bin/systemctl
/usr/sbin/lsof
/usr/sbin/xfs_repair

SLES 

/bin/kill
/bin/mount
/bin/umount
/sbin/dmsetup
/sbin/lvdisplay
/sbin/lvscan
/sbin/pvscan
/sbin/vgchange
/sbin/vgscan
/sbin/xfs_repair
/usr/bin/gcloud
/usr/bin/lsof
/usr/bin/mkdir
/usr/bin/sg_persist
/usr/bin/systemctl
/usr/sbin/lsof

L'esempio seguente mostra una voce nel file /etc/sudoers. Nell'esempio, l'ID sistema per il sistema SAP HANA associato viene sostituito con SID_LC. La voce di esempio è stata creata dal modello di Deployment Manager fornito da Google Cloud per lo scale out di SAP HANA con failover automatico dell'host. La voce creata dal modello Deployment Manager include programmi binari che non sono più necessari, ma che vengono conservati per compatibilità con le versioni precedenti. Devi includere solo i programmi binari riportati nell'elenco precedente.

SID_LCadm ALL=NOPASSWD: /sbin/multipath,/sbin/multipathd,/etc/init.d/multipathd,/usr/bin/sg_persist,/bin/mount,/bin/umount,/bin/kill,/usr/bin/lsof,/usr/bin/systemctl,/usr/sbin/lsof,/usr/sbin/xfs_repair,/sbin/xfs_repair,/usr/bin/mkdir,/sbin/vgscan,/sbin/pvscan,/sbin/lvscan,/sbin/vgchange,/sbin/lvdisplay,/usr/bin/gcloud,/sbin/dmsetup

Archiviazione NFS per il failover automatico dell'host SAP HANA

Un sistema di scale out di SAP HANA con failover automatico dell'host richiede una soluzione NFS, ad esempio Filestore, per condividere i volumi /hana/shared e /hanabackup tra tutti gli host. Devi configurare personalmente la soluzione NFS.

Quando utilizzi un metodo di deployment automatico, fornisci informazioni sul server NFS nel file di deployment per montare le directory NFS durante il deployment.

Il volume NFS utilizzato deve essere vuoto. Tutti i file esistenti possono essere in conflitto con il processo di deployment, in particolare se i file o le cartelle fanno riferimento all'ID sistema SAP (SID). Il processo di deployment non è in grado di determinare se i file possono essere sovrascritti.

Il processo di deployment archivia i volumi /hana/shared e /hanabackup sul server NFS e monta il server NFS su tutti gli host, inclusi gli host in standby. A questo punto l'host master gestisce il server NFS.

Se stai implementando una soluzione di backup, ad esempio l'agente Backint Cloud Storage per SAP HANA, puoi rimuovere il volume /hanabackup dal server NFS al termine del deployment.

Per ulteriori informazioni sulle soluzioni per i file condivisi disponibili su Google Cloud, consulta Soluzioni di condivisione file per SAP su Google Cloud.

Supporto del sistema operativo

Google Cloud supporta il failover automatico dell'host SAP HANA solo nei seguenti sistemi operativi:

  • RHEL per SAP 7.7 o versioni successive
  • RHEL per SAP 8.1 o versioni successive
  • RHEL per SAP 9.0 o versioni successive
    • Prima di installare qualsiasi software SAP su RHEL for SAP 9.x, è necessario installare pacchetti aggiuntivi sulle tue macchine host, in particolare chkconfig e compat-openssl11. Se utilizzi un'immagine fornita da Compute Engine, questi pacchetti vengono installati automaticamente. Per maggiori informazioni da SAP, consulta la pagina SAP Note 3108316 - Red Hat Enterprise Linux 9.x: Installation and Configuration.
  • SLES per SAP 12 SP5
  • SLES per SAP 15 SP1 o versioni successive

Per visualizzare le immagini pubbliche disponibili da Compute Engine, consulta Immagini.

Architettura di un sistema SAP HANA con failover automatico dell'host

Il seguente diagramma mostra un'architettura con scale out su Google Cloud che include la funzionalità di failover automatico dell'host SAP HANA. Nel diagramma, il Gestione archiviazione per SAP HANA è rappresentato dal nome del suo eseguibile, gceStorageClient.

Il diagramma mostra un errore del nodo worker 2 e il passaggio del nodo in standby. Storage Manager per SAP HANA utilizza l'API SAP Storage Connector (non mostrata) per scollegare i dischi che contengono i volumi /hana/data e /hana/logs dal nodo worker in stato di errore e per rimontarli sul nodo in standby, che poi diventa il nodo worker 2, mentre quello non riuscito diventa il nodo in standby.

Il diagramma mostra l'architettura di un sistema SAP HANA a scale out che include il supporto per il failover automatico dell'host

Opzioni di deployment automatico per le configurazioni ad alta disponibilità SAP HANA

Google Cloud fornisce file di deployment che puoi utilizzare per automatizzare il deployment di sistemi ad alta disponibilità SAP HANA o eseguire il deployment e configurare i sistemi ad alta disponibilità SAP HANA manualmente.

Per il deployment automatico dei sistemi ad alta disponibilità SAP HANA, puoi utilizzare Terraform o Deployment Manager.

Google Cloud fornisce i file di configurazione Terraform specifici per il deployment che completi. Utilizzerai i comandi Terraform standard per inizializzare la tua directory di lavoro attuale e scaricare il plug-in e i file dei moduli del provider Terraform per Google Cloud, quindi applicare la configurazione per eseguire il deployment di un sistema SAP HANA.

I modelli di Deployment Manager forniti da Google Cloud includono un file di configurazione template.yaml da completare. Deployment Manager legge il file di configurazione ed esegue il deployment di un sistema SAP HANA.

Questi metodi di deployment automatici eseguono il deployment di un sistema SAP HANA completamente supportato da SAP e conforme alle best practice di SAP e Google Cloud.

Deployment automatico di cluster Linux ad alta disponibilità per SAP HANA

Per SAP HANA, i metodi di deployment automatici eseguono il deployment di un cluster Linux ad alta disponibilità e ottimizzato per le prestazioni che include:

  • Failover automatico.
  • Riavvio automatico.
  • Una prenotazione dell'indirizzo IP virtuale (VIP) che hai 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 recinzione di Google Cloud.
  • Una VM con i dischi permanenti richiesti per ogni istanza SAP HANA.
  • Istanze SAP HANA configurate per la replica sincrona e il precaricamento della memoria.

Puoi utilizzare uno dei seguenti metodi per eseguire il deployment di un cluster ad alta disponibilità per SAP HANA:

Deployment automatico di sistemi con scale out SAP HANA con failover automatico dell'host SAP HANA

Puoi utilizzare uno dei seguenti metodi per eseguire il deployment di sistemi di scale out SAP HANA con failover automatico dell'host:

Per un sistema di scale out SAP HANA che include la funzionalità di failover automatico dell'host SAP HANA, il metodo di deployment automatico esegue il deployment:

  • Un'istanza SAP HANA master
  • Da 1 a 15 host worker
  • Da 1 a 3 host in standby
  • Una VM per ogni host SAP HANA
  • Dischi permanenti per gli host master e worker
  • Google Cloud Gestione archiviazione per i nodi in standby SAP HANA

Un sistema di scale out di SAP HANA con failover automatico dell'host richiede una soluzione NFS, ad esempio Filestore, per condividere i volumi /hana/shared e /hanabackup tra tutti gli host. Per consentire a Terraform o Deployment Manager di montare le directory NFS durante il deployment, devi configurare la soluzione NFS autonomamente prima di eseguire il deployment del sistema SAP HANA.

Puoi configurare le istanze server NFS di Filestore in modo rapido e semplice seguendo le istruzioni riportate nella sezione Creazione di istanze.

Opzione Attiva/Attiva (lettura abilitata) per SAP HANA

A partire da SAP HANA 2.0 SPS1, SAP fornisce la configurazione Attiva/Attiva (lettura abilitata) per gli scenari di replica del sistema SAP HANA. In un sistema di replica configurato per Attivo/Attivo (Lettura abilitata), le porte SQL sul sistema secondario sono aperte per l'accesso in lettura. In questo modo puoi utilizzare il sistema secondario per attività di lettura ad alta intensità e avere un migliore equilibrio dei carichi di lavoro tra le risorse di calcolo, migliorando le prestazioni complessive del tuo database SAP HANA. Per ulteriori informazioni sulla funzionalità Attiva/Attiva (lettura abilitata), consulta la Guida all'amministrazione di SAP HANA specifica per la tua versione di SAP HANA e la Nota SAP 1999880.

Per configurare una replica del sistema che consenta l'accesso in lettura sul sistema secondario, devi utilizzare la modalità operativa logreplay_readaccess. Tuttavia, per utilizzare questa modalità operativa, i sistemi principali e secondari devono eseguire la stessa versione di SAP HANA. Di conseguenza, l'accesso di sola lettura al sistema secondario non è possibile durante un upgrade in sequenza finché entrambi i sistemi non eseguono la stessa versione di SAP HANA.

Per connettersi a un sistema secondario attivo/attivo (abilitato in lettura), SAP supporta le seguenti opzioni:

  • Esegui la connessione diretta aprendo una connessione esplicita al sistema secondario.
  • Esegui la connessione indirettamente eseguendo un'istruzione SQL sul sistema principale con un hint, che al momento della valutazione reindirizza la query al sistema secondario.

Il seguente diagramma mostra la prima opzione, con cui le applicazioni accedono al sistema secondario direttamente in un cluster Pacemaker di cui è stato eseguito il deployment in Google Cloud. Un indirizzo IP (VIP) mobile o virtuale aggiuntivo viene utilizzato per scegliere come target l'istanza VM che funge da sistema secondario nell'ambito del cluster SAP HANA Pacemaker. Il VIP segue il sistema secondario e può spostare il proprio carico di lavoro di lettura da un nodo cluster a un altro in caso di errore imprevisto o per la manutenzione pianificata. Per informazioni sui metodi di implementazione VIP disponibili, consulta Implementazione dell'IP virtuale su Google Cloud.

Panoramica di un cluster Linux ad alta disponibilità per un sistema di scale up SAP HANA attivo/attivo (abilitato in lettura)

Per istruzioni su come configurare la replica del sistema SAP HANA con Attivo/Attivo (lettura abilitata) in un cluster Pacemaker:

Passaggi successivi

Sia Google Cloud che SAP forniscono ulteriori informazioni sull'alta disponibilità.

Ulteriori informazioni di Google Cloud sull'alta disponibilità

Per ulteriori informazioni sull'alta disponibilità per SAP HANA su Google Cloud, consulta la Guida alle operazioni di SAP HANA.

Per informazioni generali sulla protezione dei sistemi su Google Cloud da diversi scenari di errore, consulta Progettazione di sistemi solidi.

Ulteriori informazioni da SAP sulle funzionalità ad alta disponibilità di SAP HANA

Per maggiori informazioni da SAP sulle funzionalità ad alta disponibilità di SAP HANA, consulta i seguenti documenti: