Questa guida fornisce una panoramica delle opzioni di ripristino di emergenza per i sistemi SAP HANA di cui è stato eseguito il deployment in Google Cloud.
Questa guida non intende sostituire la documentazione standard di SAP.
Preparazione per il ripristino di emergenza
Per prepararti in caso di emergenza, puoi utilizzare la replica del sistema SAP HANA su un sistema SAP HANA secondario, eseguire backup di SAP HANA per abilitare il ripristino oppure utilizzare entrambi.
Per i carichi di lavoro mission critical che richiedono tempi di ripristino rapidi, utilizza la replica del sistema HANA per ridurre al minimo i tempi di inattività. L'utilizzo dei backup per recuperare un sistema costa meno, ma richiede più tempo, poiché è necessario creare un nuovo sistema e poi ripristinare i backup al suo interno per ripristinare il momento desiderato.
In entrambi i casi, devi utilizzare il reindirizzamento basato sulla rete per reindirizzare le applicazioni client che utilizzano il sistema SAP HANA all'indirizzo IP del sistema sostitutivo quando sarà disponibile. Per ulteriori informazioni, consulta la guida all'amministrazione di SAP HANA.
A partire da SAP HANA SPS09, puoi utilizzare l'API basata su Python inclusa in SAP HANA per creare il tuo provider ad alta disponibilità/disaster-recovery (HA/RE) e integrarlo con il processo di acquisizione SAP HANA System Replication per automatizzare attività come il reindirizzamento delle connessioni client di database dal sistema principale al sistema secondario dopo un'acquisizione. Per ulteriori informazioni, consulta Implementazione di un provider di alta disponibilità e RE.
Tieni presente che qualsiasi limitazione definita da SAP, inclusa la limitazione della distanza per la replica sincrona, sono valide anche su Google Cloud.
In alternativa alle opzioni native di ripristino di emergenza, per il ripristino di emergenza (RE) attivo-passivo tra regioni, puoi utilizzare la replica asincrona del disco permanente (replica DP asincrona). La replica asincrona dei DP offre la replica asincrona dei dati tra due regioni di Google Cloud.
Ripristino di emergenza mediante SAP HANA System Replication
Per massimizzare l'utilizzo delle risorse dell'infrastruttura e ottimizzare i costi della soluzione di RE, puoi utilizzare il sistema secondario per casi d'uso non di produzione, ad esempio per un sistema di sviluppo o QA. In questo caso, il sistema secondario non è precaricato di dati, quindi il tempo di failover è più lungo di quello del sistema secondario precaricato con i dati e sincronizzato con il sistema principale.
HANA 2 SPS00 include il supporto per la modalità di configurazione Attiva/Attiva (abilitata in lettura), che consente alla replica del sistema SAP HANA di supportare l'accesso in lettura sul sistema secondario. Per ulteriori informazioni, consulta Attivo/Attivo (Lettura abilitata).
Quando si utilizza la replica di sistema SAP HANA con Google Cloud è supportata sia la replica sincrona che la replica asincrona.
Se possibile, consigliamo di utilizzare la replica sincrona, in cui il commit delle transazioni SQL non viene eseguito nell'istanza del database principale finché non viene eseguito il commit nell'istanza in standby. In questo modo l'istanza in standby rimane sincronizzata al 100% e garantisce un Recovery Point Objective. La replica sincrona può essere utilizzata per le istanze che risiedono in qualsiasi zona all'interno della stessa regione.
Se il sistema in standby si trova in una regione diversa da quella del sistema principale, utilizza la replica asincrona, in cui non è prevista alcuna attesa che l'istanza in standby riconosca i dati prima del commit nell'istanza principale. In questo scenario, potresti perdere piccole quantità di dati in caso di calamità. Un compromesso è che la replica asincrona offre un Recovery Point Objective maggiore di zero.
Per tutti gli scenari di replica, devi eseguire manualmente un takeover sul sistema in standby per avviare il ripristino di emergenza. Devi inoltre reindirizzare manualmente tutte le applicazioni che utilizzano il database SAP HANA per avere come target l'istanza a cui ha eseguito il failover nel sistema in standby.
Scegli l'opzione di replica del sistema HANA più adatta alle tue esigenze aziendali, come il Recovery Time Objective (RTO) e il Recovery Point Objective (RPO). Per ulteriori informazioni, consulta Modalità di replica per SAP HANA System Replication.
Replica del sistema SAP HANA con precaricamento
In questo scenario, il tuo sistema SAP HANA viene replicato in un sistema di standby dedicato. Il database SAP HANA viene replicato in una VM di Compute Engine con un nome host univoco e i propri dischi permanenti collegati. Tutti i dati SAP HANA vengono caricati in memoria nel sistema in standby. Se devi eseguire il failover, il tempo di failover richiede solo circa 90 secondi perché tutti i dati sono precaricati.
Per ulteriori informazioni sulla replica di sistema SAP HANA con precaricamento, consulta la sezione Replica del sistema in SAP HANA – Alta disponibilità.
Replica del sistema SAP HANA senza precaricamento
In questo scenario, il tuo sistema SAP HANA viene replicato in un sistema di standby dedicato. Il database SAP HANA viene replicato in una VM di Compute Engine con un nome host univoco e i propri dischi permanenti collegati. I dati SAP HANA non vengono caricati in memoria nel sistema in standby. Se devi eseguire il failover, il tempo di failover può richiedere da minuti a ore, a seconda delle dimensioni del set di dati.
Quando non precarichi i dati, i requisiti di memoria per la VM di Compute Engine che ospita il database SAP HANA sono molto inferiori. Per le indicazioni più recenti sul dimensionamento, consulta Nota SAP 1999880 - Domande frequenti: Replica di sistema SAP HANA in "Quali regole si applicano all'utilizzo della memoria sui siti di replica del sistema secondari?".
Per ottenere informazioni sull'utilizzo della memoria rowstore, esegui la query seguente:
SELECT round (sum(USED_FIXED_PART_SIZE + USED_VARIABLE_PART_SIZE)/1024/1024) AS "Row Tables MB" FROM M_RS_TABLES;
Il requisito di memoria ridotta offre opzioni di risparmio sui costi nella scelta di un tipo di macchina di Compute Engine.
Puoi utilizzare un tipo di macchina con specifiche di memoria insufficiente per ospitare il database SAP HANA nel sistema in standby, in modo da ridurre i costi di esecuzione. Una VM con memoria ridotta non è supportata per SAP HANA in un sistema di produzione, ma puoi utilizzare questa VM a basso costo per eseguire un takeover in uno scenario di ripristino di emergenza, per poi modificare la VM in un secondo momento per cambiare il tipo di macchina scegliendone uno con una quantità di memoria supportata. A questo scopo, devi arrestare la VM per eseguire l'upgrade, con conseguente tempi di inattività aggiuntivi prima che il sistema SAP HANA sia disponibile.
Puoi utilizzare un tipo di macchina con memoria elevata per ospitare il database SAP HANA nel sistema in standby e condividerlo con i sistemi di sviluppo o di test per migliorare il ritorno sull'investimento. Puoi impostare il limite di allocazione globale per il database SAP HANA su 64 GB seguendo le istruzioni riportate in Modificare il limite globale di allocazione della memoria, lasciando la memoria rimanente per altri sistemi. Quando è necessario il sistema in standby, arresta le operazioni di sviluppo e test, esegui un takeover e poi rimuovi il limite di allocazione globale.
Puoi utilizzare la replica sincrona e asincrona senza precaricamento. Tuttavia, la replica sincrona richiede che le istanze di origine e di destinazione si trovino nella stessa regione Google Cloud.
Puoi utilizzare un provider di disponibilità elevata/RE per risolvere problemi come l'arresto dei sistemi di sviluppo e/o di test nell'host secondario.
Attivazione di un takeover
Per richiamare il ripristino di emergenza, attiva la procedura SAP HANA System Replication Takeover nel sistema in standby. La nota SAP 2063657 fornisce linee guida per aiutarti a decidere se il takeover sia l'opzione migliore.
Per attivare l'acquisizione, segui il processo di acquisizione standard di SAP HANA. Per maggiori dettagli su questa procedura, vedi Come eseguire la replica di sistema per SAP HANA 2.0.
In caso di problemi relativi ai dati o guasti del software, potrebbero non essere presenti notifiche automatiche per consentirti di eseguire l'acquisizione. Valuta la possibilità di creare una soluzione personalizzata per inviare avvisi utilizzando gli strumenti di monitoraggio di Cloud Monitoring o HANA.
Ripristino di emergenza mediante backup SAP HANA
Nei casi in cui un Recovery Time Objective più lungo sia accettabile e il Recovery Point Objective è superiore a 15 minuti, puoi eseguire il ripristino di emergenza eseguendo il ripristino dal backup. Per garantire il successo del ripristino quando utilizzi i backup, crea copie frequenti dei tuoi file di backup, in particolare i backup dei log, in un bucket Cloud Storage o in qualche altra posizione di archiviazione a lungo termine al di fuori della regione in cui è in esecuzione il tuo sistema SAP HANA. Ti consigliamo di documentare l'infrastruttura del sistema principale e di creare script che ti consentano di creare rapidamente un sistema sostitutivo su cui ripristinare i backup.
Per ulteriori informazioni, consulta la guida alle operazioni SAP HANA.
Ripristino di emergenza mediante replica asincrona DP
Per i tuoi carichi di lavoro SAP in esecuzione su Google Cloud, DP Async Replication consente il ripristino di emergenza replicando i dati tra due regioni Google Cloud. La replica asincrona DP offre una replica asincrona di archiviazione a blocchi con RPO (Recovery Point Objective) e RTO (Recovery Time Objective) bassi per il ripristino di emergenza attivo-passivo tra regioni. Nell'improbabile eventualità di un'interruzione a livello di regione, la replica asincrona DP consente di eseguire il failover dei dati SAP in una regione secondaria e di riavviare il carico di lavoro SAP in quella regione.
Puoi utilizzare DP Async Replication per gestire la replica dei carichi di lavoro SAP basati su Compute Engine a livello di infrastruttura, anziché a livello di carico di lavoro SAP come SAP HANA System Replication.
La replica asincrona DP replica i dati SAP da un disco primario collegato a un carico di lavoro in esecuzione su un disco vuoto secondario che si trova in un'altra regione. Per saperne di più, vedi Informazioni sulla replica asincrona del disco permanente.
Limitazioni della replica asincrona DP
Per la replica asincrona dei DP, puoi utilizzare solo
dischi permanenti bilanciati (pd-balanced) e dischi permanenti con prestazioni (SSD) (pd-ssd) in coppie di regioni supportate.
Per ulteriori informazioni, vedi Limitazioni.
Monitora e valuta la frequenza di modifica del carico di lavoro rispetto alla capacità della replica asincrona di DP esaminando le metriche di monitoraggio per la coppia di dispositivi come descritto in Esaminare le prestazioni della replica asincrona del disco permanente.
Non è previsto che la metrica async_replication/sent_bytes_count mostri un aumento costante della quantità di dati trasferiti perché questa metrica rappresenta il delta del numero di byte inviati attraverso la rete tra regioni.