Guida alla pianificazione dell'alta disponibilità di SAP HANA

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

Questa guida presuppone che tu abbia già compreso i concetti e pratiche generalmente richiesti per implementare una soluzione SAP HANA ad alta disponibilità. Pertanto, la guida si concentra principalmente su ciò che per implementare questo sistema su Google Cloud.

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

Questa guida alla pianificazione si concentra esclusivamente sull'alta disponibilità per SAP HANA e non copre l'alta disponibilità per i sistemi applicativi. Per informazioni sull'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 di alta disponibilità per SAP HANA su Google Cloud

Puoi utilizzare una combinazione di funzionalità di Google Cloud e SAP progettazione di una configurazione ad alta disponibilità per SAP HANA in grado di gestire a livello di infrastruttura o software. La tabella seguente descrive le funzionalità di SAP e Google Cloud utilizzate per garantire la disponibilità elevata.

Funzionalità Descrizione
Migrazione live di Compute Engine

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

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

Nei sistemi multi-host, i volumi condivisi, ad esempio "/hana/shared" volume utilizzato nelle guida all'implementazione, sono dischi permanenti collegati alla VM che ospita il master. e sono montati su NFS sugli host worker. Il volume NFS è inaccessibile per un massimo di alcuni secondi in caso di migrazione in tempo reale dell'host master. Al riavvio dell'host master, il volume NFS su tutti gli host e il normale funzionamento riprende 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 sulla migrazione live. Me ti consigliamo di non modificare questa impostazione.

Per ulteriori informazioni, vedi Migrazione live.
Riavvio automatico di Compute Engine

Se l'istanza è impostata per terminare in caso di manutenzione o se l'istanza ha un arresto anomalo a causa di un hardware sottostante puoi configurare Compute Engine per il riavvio automatico l'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 recupero degli errori fornita da SAP.

SAP HANA ha molti servizi configurati in esecuzione in continuazione per varie attività. Quando uno di questi servizi viene disattivato a causa di un errore del software o un errore umano, il servizio SAP HANA si riavvia automaticamente funzione watchdog lo riavvia automaticamente. Quando il servizio viene riavviato, carica di nuovo in memoria tutti i dati necessari e riprende il suo funzionamento.
Backup di SAP HANA

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

Per ulteriori informazioni sull'utilizzo dei backup SAP HANA su Google Cloud, consulta Guida alle operazioni di SAP HANA.
SAP HANA Storage Replication

La replica dell'archiviazione SAP HANA fornisce un'emergenza a livello di archiviazione il supporto per il ripristino tramite determinati partner per l'hardware. Archiviazione SAP HANA non è supportata su Google Cloud. Ti consigliamo di utilizzare gli snapshot dei dischi permanenti di Compute Engine.

Per ulteriori informazioni sull'utilizzo degli snapshot dei dischi permanenti per eseguire il backup dei 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 locale per il ripristino dei guasti che richiede uno o più host SAP HANA in standby in un sistema a scalabilità orizzontale. Se uno degli host principali non funziona, il failover automatico dell'host mette automaticamente online l'host di riserva e riavvia l'hosting non funzionante come host di riserva.

Per ulteriori informazioni, vedi:
SAP HANA System Replication

La replica di sistema SAP HANA consente di configurare una o più che prenderanno il controllo del sistema principale in alta disponibilità scenari di ripristino di emergenza. Puoi ottimizzare la replica in base alle tue esigenze in termini di prestazioni e tempo di failover.
Opzione Fast Restart di SAP HANA (consigliata)

Il riavvio rapido di SAP HANA riduce il tempo di riavvio nel caso in cui SAP HANA venga terminato, ma il sistema operativo rimanga in esecuzione. SAP HANA riduce il tempo di riavvio sfruttando la funzionalità della memoria permanente SAP HANA per preservare i frammenti di dati MAIN delle tabelle del magazzino delle colonne nella 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 SAP HANA HA/DR (opzione consigliata)

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

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

Cluster HA nativi del sistema operativo per SAP HANA su Google Cloud

Il clustering del sistema operativo Linux fornisce consapevolezza delle applicazioni e degli ospiti per lo stato dell'applicazione e automatizza le azioni di recupero in caso di errore.

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

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

Per istruzioni su come eseguire il deployment e configurare manualmente un cluster HA 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à di SAP HANA.

Agenti delle risorse del cluster

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

Per fornire aggiornamenti non ancora inclusi negli agenti di risorse di sistema operativo di base, Google Cloud fornisce periodicamente agenti di risorse aggiuntivi per i cluster HA per SAP. Quando sono richiesti questi agenti di risorsa companion, Le procedure di deployment di Google Cloud includono un passaggio per scaricarle.

Agenti di scherma

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

Google Cloud fornisce due agenti di scherma da utilizzare con SAP su Linux sistemi operativi, l'agente fence_gce incluso nella certificazione Red Hat e SUSE Linux, nonché l'agente gcpstonith legacy, che puoi eseguire anche il download per l'utilizzo con le distribuzioni Linux che non includono il Agente fence_gce. Ti consigliamo di utilizzare l'agente fence_gce, se disponibili.

Autorizzazioni IAM richieste per gli agenti di fencing

Gli agenti di scherma riavviano le VM mediante una chiamata di reimpostazione alla l'API Compute Engine. Per l'autenticazione e l'autorizzazione per accedere all'API, gli agenti di recinzione 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 Amministratore istanze Compute predefinito 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 basato sulle risorse.

Indirizzo IP virtuale

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

I tipici deployment non cloud utilizzano un protocollo di risoluzione degli indirizzi gratuito (ARP) richiesta di annuncio del movimento e della riassegnazione di un VIP a un nuovo MAC .

Su Google Cloud, anziché utilizzare richieste ARP gratuite, puoi utilizzare uno di diversi metodi per spostare e riallocare un VIP in un cluster HA. La il metodo consigliato è utilizzare un bilanciatore del carico TCP/UDP interno, ma, a seconda in base alle tue esigenze, puoi anche utilizzare l'implementazione VIP basata su route o implementazione VIP basata su IP alias.

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

Archiviazione e replica

Una configurazione del cluster SAP HANA HA utilizza la replica di sistema SAP HANA sincrona per mantenere sincronizzati i database SAP HANA principali e secondari. Gli agenti standard forniti dal sistema operativo per SAP HANA gestiscono di replicare il sistema durante un failover, con avvio e arresto replicare e cambiare le istanze che fungono da istanza le istanze attive e in standby nel processo di replica.

Se hai bisogno di spazio di archiviazione dei 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 di file di terze parti come NetApp Cloud Volumes Service per Google Cloud. Il livello Enterprise di Filestore può essere utilizzato per ambienti e il livello Base di Filestore può essere usato deployment a zona singola.

I dischi permanenti regionali di Compute Engine offrono archiviazione a blocchi con replica sincrona tra le zone. Anche se i dischi permanenti a livello di regione non sono supportati per l'archiviazione dei database nei sistemi SAP ad alta disponibilità, puoi usarli con i file server NFS.

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

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

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

Considera i valori consigliati come punto di partenza per ottimizzare le impostazioni di Corosync nel cluster HA. Devi confermare che la sensibilità del rilevamento di errori e dell'attivazione del failover sia appropriata 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 i valori per diversi parametri nella sezione totem del file di configurazione di corosync.conf che sono diversi dai valori predefiniti impostati da Corosync o dal tuo account distributore.

La tabella seguente mostra i parametri totem per cui Google Cloud consiglia i valori e l'impatto della loro modifica. Per i valori predefiniti di questi parametri, che possono differire tra le distribuzioni Linux, consulta la documentazione per la tua 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 adesione.
max_messages 20 Aumenta il numero massimo di messaggi che possono essere inviati da nel nodo dopo aver ricevuto il token.
token 20000 (ms)

Aumenta il tempo di attesa del nodo per un token di protocollo totem prima dichiara una perdita di token, presuppone un errore del nodo e inizia prendere provvedimenti.

Aumentando il valore del parametro token, più tollerante nei confronti di eventi temporanei dell'infrastruttura, come una migrazione live. Tuttavia, il cluster può richiedere più tempo per rilevare e recuperare un errore del nodo.

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

consensus N/D

Specifica, in millisecondi, il tempo di attesa per ottenere un consenso prima di iniziare un nuovo ciclo di configurazione dell'abbonamento.

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

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

token_retransmits_before_loss_const 10 Aumenta il numero di ritrasmissioni del token tentate dal nodo prima di concludere che il nodo destinatario ha avuto un errore e di 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, vedi la guida alla configurazione per la tua distribuzione Linux:

Impostazioni di timeout e intervalli per le risorse del cluster

Quando definisci una risorsa del cluster, imposti interval e timeout, in secondi, per varie operazioni delle 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 operazione delle risorse, poiché sono illustrati nella tabella seguente.

Operazione risorsa Azione di timeout
monitor Se il timeout viene superato, lo stato del monitoraggio solitamente i report come non riusciti e la risorsa associata viene considerata in stato Non riuscito. Il cluster tenta di applicare le opzioni di recupero, che possono includere un failover. Il cluster non riprova a eseguire un monitoraggio non riuscito operativa.
start Se una risorsa non viene avviata prima del raggiungimento del timeout, il cluster tenta di riavviare la risorsa. Il comportamento è dettato dall'azione in caso di errore associato a una risorsa.
stop Se una risorsa non risponde a un'operazione di arresto prima del viene raggiunto il timeout, viene attivato un evento di fencing.

Insieme ad altre impostazioni di configurazione del cluster, le impostazioni interval e timeout delle risorse del cluster influiscono sulla rapidità 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 dei cluster per l'account SAP HANA per gli eventi di manutenzione della migrazione live di Compute Engine.

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

Impostazioni delle risorse per recinzioni

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

La tabella seguente mostra i parametri di scherma che Google Cloud consiglia insieme ai valori consigliati e ai dettagli dei parametri. Per i valori predefiniti dei parametri, che possono differire tra Per le distribuzioni Linux, consulta la documentazione per la tua 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:

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

Specifica un ritardo casuale per le azioni di recinzione per impedire ai nodi del cluster di recintarsi contemporaneamente. Per evitare una gara di recinzione assicurandoti che solo a un'istanza venga assegnato un ritardo casuale, questo parametro deve essere attivato solo su una delle risorse di recinzione in un cluster HANA HA 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 aver configurato il cluster e aver eseguito il deployment dei sistemi di cluster e SAP HANA nell'ambiente di test, devi testare il cluster per verificare che il sistema HA sia configurato correttamente e funzioni come previsto.

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

  • Arresta la VM
  • Creare un kernel panic
  • Arresta l'applicazione
  • Interrompere la rete tra le istanze

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

Logging e monitoraggio

Gli agenti di risorse possono includere funzionalità di logging che propagano i log a Osservabilità di Google Cloud per l'analisi. Ogni agente delle risorse include informazioni di configurazione che identificano eventuali opzioni di registrazione. In caso di bash implementazioni, l'opzione di logging è gcloud logging.

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

Per informazioni sull'utilizzo di Cloud Monitoring per configurare i controlli dei servizi che monitorano la disponibilità degli endpoint dei servizi, consulta Gestire i 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 in conformità 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, pertanto 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 limitandole solo a istanze specifiche di una risorsa, ad esempio le istanze VM nel cluster HA, aggiungendo condizioni nelle associazioni di ruolo dei criteri IAM di una risorsa.

Le autorizzazioni minime di cui i tuoi sistemi hanno bisogno dipendono dalle risorse Google Cloud a cui accedono e dalle azioni che eseguono. Di conseguenza, per determinare le autorizzazioni minime richieste per le VM host nel cluster HA potrebbe essere necessario esaminare esattamente a quali risorse accedono i sistemi sulla VM host e le azioni che questi sistemi eseguono con queste risorse.

Come punto di partenza, l'elenco seguente mostra alcune risorse del cluster ad alta disponibilità le autorizzazioni associate di cui hanno bisogno:

  • Recinzione
    • compute.instances.list
    • compute.instances.get
    • compute.instances.reset
    • compute.instances.stop
    • compute.instances.start
    • logging.logEntries.create
    • compute.zones.list
  • VIP implementato utilizzando 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 utilizzando 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 utilizzando un bilanciatore del carico interno
    • Non sono richieste autorizzazioni specifiche: il bilanciatore del carico opera sugli stati del controllo di integrità che non richiedono l'interazione con il cluster o modificare le risorse in Google Cloud

Implementazione di indirizzi IP virtuali su Google Cloud

Un cluster ad alta disponibilità utilizza un indirizzo IP fluttuante o virtuale (VIP). di spostare il carico di lavoro da un nodo cluster a un altro nel caso di un un guasto imprevisto o una manutenzione pianificata. L'indirizzo IP del VIP non cambia, pertanto 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, non è possibile utilizzare richieste ARP gratuite per annunciare la modifica. In alternativa, puoi implementare per un cluster ad alta disponibilità SAP, 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 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 inoltre il failover di supporto che puoi utilizzare con i controlli di integrità di Compute Engine rilevare errori, attivare il failover e reindirizzare il traffico a un nuovo progetto SAP principale in un cluster ad alta disponibilità 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 multizona ad alta disponibilità, protegge 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 complessivi di failover sono dipende dai tempi di failover di ciascuno dei componenti del sistema ad alta disponibilità, che può includere host, sistemi di database, sistemi applicativi e altro ancora.
  • Il bilanciamento del carico semplifica la configurazione del cluster e riduce delle dipendenze.
  • A differenza di un'implementazione VIP che utilizza le route, con il bilanciamento del carico, utilizzare gli intervalli IP della tua rete VPC, consentendoti di prenotare configurarle in base alle tue esigenze.
  • Il bilanciamento del carico può essere facilmente utilizzato per reindirizzare il traffico a un server per le interruzioni di manutenzione pianificate.

Quando crei un controllo di integrità per l'implementazione del bilanciatore del carico di un VIP, devi specificare la porta host probe del controllo di integrità 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. Configura la porta di destinazione sulla VM host con un servizio helper secondario, come l'utilità socat o HAProxy.

Per i cluster di database in cui rimane il sistema secondario in standby online, il servizio di controllo di integrità e helper consente il bilanciamento del carico indirizzare il traffico al sistema online che attualmente funziona come 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 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 offre 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 di IP alias VIP non sono consigliate per l'alta disponibilità multizona perché, in caso di errore di una zona, la riallocazione dell'IP alias a un nodo in una zona diversa possono subire ritardi. 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.

Failover automatico dell'host SAP HANA su Google Cloud

Google Cloud supporta il failover automatico dell'host SAP HANA, soluzione di ripristino dagli errori fornita da SAP HANA. Failover automatico dell'host di una soluzione utilizza uno o più host di standby mantenuti di riserva per rispetto al lavoro dell'host master o di un host worker in caso di errore dell'host. Gli host di riserva non contengono dati né elaborano alcun lavoro.

Al termine di un failover, l'host in errore viene riavviato come host in standby.

SAP supporta fino a tre host di riserva nei sistemi scalabili su Google Cloud. Gli host di riserva non vengono conteggiati nel numero massimo di 16 host attivi supportati da SAP nei sistemi di scalabilità su Google Cloud.

Per ulteriori informazioni di 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 dagli errori che interessano una singola nodo in un sistema di scale out SAP HANA, con 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 in tempo reale proteggono insieme dalle interruzioni pianificate e non pianificate della VM. Pertanto, per la protezione delle VM, la soluzione di failover automatico dell'host SAP HANA non è necessaria.

Il failover automatico dell'host SAP HANA non protegge da errori a livello di zona, il deployment di tutti i nodi di un sistema di 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 di standby, pertanto quando un nodo di standby prende il controllo, il tempo di recupero complessivo del nodo è determinato principalmente dal tempo necessario per caricare i dati nella memoria del nodo di 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.
  • Esegui la migrazione lift and shift, in cui è necessario riprodurre i configurazione SAP HANA on-premise fino a quando non potrai ottimizzare SAP HANA in Google Cloud.
  • Quando una configurazione di alta disponibilità completamente replicata e tra zone è proibitiva in termini di costi e la tua attività può tollerare:
    • Un tempo di recupero del nodo più lungo a causa della necessità di caricare dati SAP HANA nella memoria di un nodo in standby.
    • Il rischio di errori a livello di zona.

Il gestore dello spazio di archiviazione per SAP HANA

I volumi /hana/data e /hana/log vengono 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 il gestore dello spazio di archiviazione Google Cloud per i nodi in standby di SAP HANA per spostare i mount dei volumi dall'host in cui si è verificato l'errore all'host in standby.

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

Versioni supportate dello Storage Manager per SAP HANA

Sono supportate le versioni 2.0 e successive di Gestione archiviazione per SAP HANA. Tutte le versioni precedenti alla 2.0 vengono è deprecata e non supportata. Se utilizzi una versione precedente, aggiorna il file SAP HANA per utilizzare l'ultima versione dello Gestione archiviazione per SAP HANA. Consulta Aggiornamento di Storage Manager 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 è indicato nei commenti alla pagina all'inizio del file gceStorageClient.py, come mostrato nell'esempio seguente. Se il numero di versione non è presente, significa che stai utilizzando una versione ritirata del gestore dello spazio di 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 Gestione archiviazione per SAP HANA è utilizzare un metodo di deployment automatizzato per eseguire il deployment di un sistema SAP HANA con scale out che include il Gestione archiviazione più recente per SAP HANA.

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

Se non puoi utilizzare un metodo di deployment automatico, ti consigliamo di contattare un consulente SAP, come quelli disponibili tramite i servizi di consulenza Google Cloud, per ricevere assistenza per l'installazione manuale del gestore dello spazio di archiviazione per SAP HANA.

Al momento non è documentata l'installazione manuale dello Storage Manager per SAP HANA in un sistema SAP HANA scale-out esistente o nuovo.

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

Aggiornamento di Storage Manager per SAP HANA

Per aggiornare Gestione archiviazione per SAP HANA, devi prima scaricare l'installazione ed eseguendo uno script di installazione che aggiorna Gestione archiviazione per SAP HANA eseguibile nell'unità SAP HANA /shared.

La procedura riportata di seguito è valida solo per la versione 2 dello Storage Manager per SAP HANA. Se utilizzi una versione di Gestione archiviazione per SAP HANA scaricata Prima del 1° febbraio 2021, installa la versione 2 prima di tentare di aggiornare Gestione archiviazione per SAP HANA.

Per aggiornare lo Storage Manager per SAP HANA:

  1. Controlla la versione del tuo attuale gestore dello spazio di archiviazione per SAP HANA:

    RHEL 

    sudo yum check-update google-sapgcestorageclient

    SLES 

    sudo zypper list-updates -r google-sapgcestorageclient

  2. Se esiste un aggiornamento, installalo:

    RHEL 

    sudo yum update google-sapgcestorageclient

    SLES 

    sudo zypper update

    Lo Storage Manager aggiornato per SAP HANA è installato in /usr/sap/google-sapgcestorageclient/gceStorageClient.py.

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

    • Se il file gceStorageClient.py esistente è in /hana/shared/gceStorageClient, il valore predefinito percorso di installazione, 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, sostituendolo.

Parametri di configurazione nel file global.ini

alcuni parametri di configurazione per Gestione archiviazione per SAP HANA, tra cui se la fencing è abilitata o disabilitata, vengono memorizzati spazio di archiviazione del file SAP HANA global.ini. Quando utilizzi Terraform di configurazione del deployment o il modello di Deployment Manager fornita da Google Cloud per eseguire il deployment di un server SAP HANA con la funzione di failover automatico dell'host, il processo di deployment aggiunge di configurazione al file global.ini.

L'esempio seguente mostra i contenuti di un global.ini creato per lo Storage Manager 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 il gestore dello spazio di archiviazione per SAP HANA

Per gestire i servizi e l'archiviazione SAP HANA, Gestione archiviazione per SAP HANA utilizza SID_LCadm account utente e richiede l'accesso sudo a un determinato sistema file binari.

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

Se installi manualmente lo Storage Manager per SAP HANA, utilizza il comando visudo per modificare il file /etc/sudoers in modo da concedere all'account utente SID_LCadm l'accesso sudo ai seguenti binari richiesti.

Fai clic sulla scheda del 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. Nella Ad esempio, l'ID di sistema per il sistema SAP HANA associato viene sostituito con SID_LC. La voce di esempio è stata creata dal modello Deployment Manager fornito da Google Cloud per il scaling 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 la compatibilità con le versioni precedenti. Devi includere solo i binari che compaiono 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

Spazio di archiviazione NFS per il failover automatico dell'host SAP HANA

Un sistema SAP HANA scalabile orizzontalmente con failover automatico dell'host richiede una soluzione NFS, come Filestore, per condividere i volumi /hana/shared e /hanabackup tra tutti gli host. Devi configurare la soluzione NFS autonomamente.

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

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

Il processo di deployment archivia /hana/shared e /hanabackup volumi sul server NFS e monta il server NFS su tutti gli host, incluso gli host in standby. L'host master gestisce quindi il server NFS.

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

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

Supporto dei sistemi operativi

Google Cloud supporta il failover automatico dell'host SAP HANA solo su sui 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 te. Per ulteriori informazioni da SAP, vedi SAP Note 3108316 - Red Hat Enterprise Linux 9.x: Installazione e configurazione di Google.
  • SLES for SAP 12 SP5
  • SLES per SAP 15 SP1 o versione successiva

Per vedere le immagini pubbliche disponibili in Compute Engine, Immagini.

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

Il seguente diagramma mostra un'architettura scalabile su Google Cloud che include la funzionalità di failover automatico dell'host SAP HANA. Nel diagramma, lo storage manager per SAP HANA è rappresentato dal nome del relativo file eseguibile, gceStorageClient.

Il diagramma mostra un errore del nodo worker 2 e il nodo in standby. Storage Manager per SAP HANA funziona con SAP Storage Connector API (non mostrata) per scollegare i dischi che contengono i volumi /hana/data e /hana/logs della nodo worker e rimontarlo sul nodo standby, che poi diventa worker Node 2, mentre il nodo in errore diventa il nodo di standby.

Il diagramma illustra l'architettura di un sistema SAP HANA a scale out che include 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 puoi utilizzare per automatizzare il deployment dei sistemi SAP HANA ad alta disponibilità puoi eseguire il deployment e configurare i tuoi sistemi SAP HANA HA manualmente.

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

Google Cloud fornisce file di configurazione Terraform specifici per il deployment che devi completare. Utilizzi i comandi Terraform standard per inizializzare la directory di lavoro corrente, scaricare i file del plug-in e del modulo del provider Terraform per Google Cloud e applicare la configurazione per eseguire il deployment di un sistema SAP HANA.

I modelli di Deployment Manager che Google Cloud fornisce includono una configurazione template.yaml file completato. Deployment Manager legge di configurazione ed esegue il deployment di un sistema SAP HANA.

Questi metodi di deployment automatizzato di eseguire il deployment di un sistema SAP HANA supportato da SAP e che aderisce alle best practice di SAP e in Google Cloud.

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

Per SAP HANA, i metodi di deployment automatico consentono di eseguire 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 scherma 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 pre-caricamento della memoria.

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

Deployment automatico di sistemi SAP HANA scalabili orizzontalmente con failover automatico dell'host SAP HANA

Puoi utilizzare uno dei seguenti metodi di deployment per eseguire il deployment di SAP HANA sistemi a scalabilità orizzontale con failover automatico dell'host:

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

  • Un'istanza SAP HANA master
  • Da 1 a 15 host worker
  • Da 1 a 3 host di riserva
  • Una VM per ogni host SAP HANA
  • Dischi permanenti per gli host master e worker
  • Il gestore dello spazio di archiviazione Google Cloud per i nodi di standby SAP HANA

Un sistema di scale out SAP HANA con failover automatico dell'host richiede una soluzione NFS, come Filestore, per condividere /hana/shared e /hanabackup volumi tra tutti gli host. Per fare in modo che Terraform Deployment Manager può montare le directory NFS durante devi configurare personalmente la soluzione NFS prima di eseguire il deployment HANA.

Puoi configurare le istanze del server NFS Filestore in modo rapido e semplice seguendo le istruzioni riportate in 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 (con 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. Ciò consente di utilizzare il sistema secondario per attività ad alta intensità di lettura e di avere un migliore equilibrio dei carichi di lavoro tra le risorse di calcolo, migliorando le prestazioni complessive del database SAP HANA. Per ulteriori informazioni sulla funzionalità Active/Active (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 di 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 primari e secondari devono eseguire la stessa versione 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 SAP HANA.

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

  • Connettiti direttamente aprendo una connessione esplicita al sistema secondario.
  • Esegui una connessione indiretta eseguendo un'istruzione SQL sul sistema principale con un suggerimento, che al momento della valutazione reindirizza la query al sistema secondario.

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

Panoramica di un cluster Linux ad alta disponibilità per un sistema di scaleup SAP HANA attivo/attivo (abilitato alla lettura)

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

Passaggi successivi

Sia Google Cloud che SAP forniscono ulteriori informazioni sulla disponibilità elevata.

Ulteriori informazioni di Google Cloud sull'alta disponibilità

Per saperne di più sull'alta disponibilità per SAP HANA su Google Cloud, vedi Guida alle operazioni di SAP HANA.

Per informazioni generali sulla protezione dei sistemi su Google Cloud da vari scenari di errore, consulta Progettare sistemi robusti.

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

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