Questa guida fornisce una panoramica delle opzioni di ripristino di emergenza per SAP Sistemi HANA di cui è stato eseguito il deployment su Google Cloud.
Questa guida non intende sostituire la documentazione SAP standard.
Preparazione al ripristino di emergenza
Per prepararti ai disastri, puoi utilizzare la replica di sistema SAP HANA su un server Sistema SAP HANA, esegui backup di SAP HANA per abilitare il ripristino o utilizza entrambi.
Per carichi di lavoro mission critical 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, in quanto una nuova ed eseguire il ripristino dei backup. nel momento desiderato.
In entrambi i casi, devi utilizzare modelli per reindirizzare le applicazioni client che utilizzano il sistema SAP HANA alla piattaforma Indirizzo IP del sistema sostitutivo, una volta 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 di alta disponibilità/ripristino dopo disastro (HA/DR) e integrarlo con la procedura di acquisizione della replica di sistema SAP HANA per automatizzare attività come il reindirizzamento delle connessioni dei client di database dal sistema principale al sistema secondario dopo un'acquisizione. Per ulteriori informazioni, vedi Implementazione di un provider HA/DR.
Tieni presente che eventuali limitazioni definite da SAP, inclusa la limitazione di distanza per la replica sincrona, sono in vigore anche su Google Cloud.
In alternativa alle opzioni di ripristino di emergenza native, per il ripristino di emergenza attivo-passivo tra regioni puoi utilizzare la replica asincrona del disco permanente (PD Async Replication). La replica asincrona del disco permanente fornisce la replica asincrona dei dati tra due regioni Google Cloud.
Ripristino di emergenza utilizzando la replica del sistema SAP HANA
per massimizzare l'utilizzo delle risorse dell'infrastruttura e per ottimizzare i costi del tuo RE puoi utilizzare il sistema secondario per i casi d'uso non di produzione, come a quello di sviluppo o QA. In questo caso, il sistema secondario non vengono precaricati con i dati, quindi il tempo di failover è più lungo rispetto a quello necessario in un sistema precaricato con dati e mantenuto sincronizzato con il sistema principale.
HANA 2 SPS00 include il supporto della modalità di configurazione Active/Active (lettura abilitata), che consente alla replica del sistema SAP HANA di supportare l'accesso in lettura sul sistema secondario. Per maggiori informazioni, consulta Attivo/attivo (lettura abilitata).
Quando si utilizza SAP, sono supportate sia la replica sincrona che asincrona Replica del sistema HANA con Google Cloud.
Se possibile, ti consigliamo di utilizzare la replica sincrona, in cui le transazioni SQL non vengono confermate nell'istanza del database principale finché non vengono confermate nell'istanza di standby. In questo modo, l'istanza di standby rimane sincronizzata al 100% e garantisce un Recovery Point Objective pari a zero. La replica sincrona può essere utilizzata per le istanze che si trovano in qualsiasi zona all'interno della stessa regione.
Se il sistema di standby si trova in una regione diversa da quella del sistema principale, utilizza la replica asincrona, in cui non è necessario attendere che l'istanza di standby accetti i dati prima del commit sull'istanza principale. In questo scenario, potresti perdere piccole quantità di dati in caso di incidente. Un compromesso è che il motore la replica ti offre un Recovery Point Objective maggiore di zero.
Per tutti gli scenari di replica, devi eseguire manualmente una presa in carico sul sistema di standby per avviare il piano di ripristino in caso di disastro. Devi anche reindirizzare manualmente tutte le applicazioni che utilizzano il database SAP HANA in modo che abbiano come target l'istanza a cui è stato eseguito il failover nel sistema di standby.
Scegli l'opzione di replica di sistema HANA più adatta alle tue esigenze aziendali, come RTO (Recovery Time Objective) e RPO (Recovery Point Objective). Per ulteriori informazioni, vedi Modalità di replica per la replica di sistema SAP HANA.
Replica di sistema SAP HANA con precaricamento
In questo scenario, il tuo sistema SAP HANA viene replicato in un standby dedicato di un sistema operativo completo. Il database SAP HANA viene replicato in una VM di Compute Engine che ha un nome host univoco e i propri dischi permanenti collegati. Tutte le risorse SAP HANA i dati vengono caricati nella memoria del sistema in standby. Se devi eseguire il failover, il tempo necessario è di circa 90 secondi perché tutti i dati sono precaricati.
Per ulteriori informazioni sulla replica di sistema SAP HANA con precaricamento, consulta la sezione Replica di sistema in SAP HANA - Alta disponibilità.
Replica del sistema SAP HANA senza precaricamento
In questo scenario, il sistema SAP HANA viene replicato in un sistema di standby dedicato. Il database SAP HANA viene replicato in una VM Compute Engine con un nome host univoco e i relativi dischi permanenti collegati. I dati SAP HANA non viene caricato nella memoria del sistema in standby. Se devi eseguire il failover, il tempo di failover può variare da minuti a ore, a seconda delle dimensioni del set di dati.
Se non carichi in anteprima i dati, i requisiti di memoria per la VM Compute Engine che ospita il database SAP HANA sono molto inferiori. Per le indicazioni di dimensionamento più recenti, consulta la nota SAP 1999880 - Domande frequenti: replica di sistema SAP HANA nella sezione "Quali regole si applicano all'utilizzo della memoria nei siti di replica di sistema secondari?".
Puoi ottenere informazioni sull'impronta in memoria del mazzo di righe eseguendo la seguente query:
SELECT round (sum(USED_FIXED_PART_SIZE + USED_VARIABLE_PART_SIZE)/1024/1024) AS "Row Tables MB" FROM M_RS_TABLES;
Il ridotto requisito di memoria ti offre opzioni di risparmio sui costi quando scegli un tipo di macchina Compute Engine.
Per ridurre i costi di gestione, puoi utilizzare un tipo di macchina con specifiche di memoria ridotte per ospitare il database SAP HANA nel sistema di standby. R con memoria ridotta non è supportata per SAP HANA in un sistema di produzione, ma potresti utilizzare questa VM a basso costo per eseguire un takeover durante un ripristino di emergenza dello scenario, dopodiché potrai modificare la VM per cambiare il tipo di macchina con una quantità di memoria supportata. Per farlo, devi arrestare la VM per eseguire l'upgrade, quindi dovrai prevedere un tempo di riposo aggiuntivo prima che il sistema SAP HANA sia disponibile.
Puoi utilizzare un tipo di macchina con memoria elevata per ospitare il database SAP HANA il sistema standby e può condividerlo con i sistemi di sviluppo o test per migliorare il ritorno sull'investimento. Puoi impostare il limite di allocazione globale per SAP HANA a 64 GB seguendo le istruzioni all'indirizzo Modifica il limite di allocazione della memoria globale, e lasciare il resto della memoria a disposizione degli altri sistemi. Quando il sistema in standby arresta le operazioni di sviluppo e test, esegui un takeover 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 nella stessa regione Google Cloud.
Puoi utilizzare un provider HA/RE per risolvere problemi come l'arresto di sviluppo e/o test nell'host secondario.
Attivazione di un takeover
Per richiamare il ripristino di emergenza, attiva il takeover della replica del sistema SAP HANA nel sistema di standby. SAP Note 2063657 fornisce linee guida che ti aiuteranno a decidere se il takeover è l'opzione migliore.
Per attivare il rilevamento, segui la procedura standard di rilevamento di SAP HANA. Per ulteriori informazioni su questa procedura, consulta Come eseguire la replica del sistema per SAP HANA 2.0.
In caso di problemi relativi ai dati o guasti del software, potrebbero non essere disponibili in modo che tu possa prendere il controllo. Valuta la possibilità di creare una per l'invio di avvisi tramite gli strumenti di monitoraggio di Cloud Monitoring o HANA.
Ripristino di emergenza con backup SAP HANA
Nei casi in cui sia accettabile un Recovery Time Objective più lungo e il recupero è superiore a 15 minuti, puoi eseguire il ripristino eseguendo il ripristino da una copia di backup. Per garantire il corretto ripristino quando si utilizzano i backup, eseguire spesso copie dei file di backup, in particolare i backup dei log, del bucket Cloud Storage o di qualche altra località di archiviazione a lungo termine esistente. al di fuori della regione in cui viene eseguito il 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 Guida alle operazioni di SAP HANA.
Ripristino di emergenza utilizzando la replica asincrona dei dischi permanenti
Per i carichi di lavoro SAP in esecuzione su Google Cloud, replica asincrona PD il ripristino di emergenza mediante la replica tra due regioni Google Cloud. La replica asincrona PD offre un Blocco RPO (Recovery Point Objective) e un RTO (Low Recovery Time Objective) replica asincrona di archiviazione per attivi/passivi tra regioni ripristino di emergenza. Nell'improbabile caso di interruzione del servizio a livello di regione, La replica asincrona PD consente di eseguire il failover dei dati SAP in una regione secondaria e riavvia il carico di lavoro SAP in quella regione.
Puoi utilizzare la replica asincrona PD per gestire la replica per Compute Engine basati su carichi di lavoro SAP a livello di infrastruttura a livello di carico di lavoro, come replica di sistema SAP HANA.
La replica asincrona PD replica i dati SAP da un disco primario collegato a un carico di lavoro in esecuzione a un disco secondario vuoto che si trova in un'altra regione. Per ulteriori informazioni, consulta Informazioni sulla replica asincrona del disco permanente.
Limitazioni della replica asincrona PD
Per la replica asincrona del disco permanente, puoi utilizzare solo dischi permanenti bilanciati (pd-balanced) e dischi permanenti prestazionali (SSD) (pd-ssd) nelle coppie di regioni supportate.
Per ulteriori informazioni, vedi Limitazioni.
Monitora e valuta il tasso di variazione del tuo carico di lavoro rispetto alle funzionalità della replica asincrona dei dischi permanenti esaminando le metriche di monitoraggio per la coppia di dispositivi come descritto in Esaminare le prestazioni della replica asincrona dei dischi permanenti.
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.