Puoi utilizzare Google Cloud per ospitare soluzioni di ripristino di emergenza per i tuoi sistemi SAP in esecuzione su Google Cloud, on-premise o su un altro provider di servizi cloud.
Definizione di disaster recovery
Il recupero di emergenza (RE) e l'alta disponibilità (AD) sono due elementi distinti nel concetto più ampio di continuità aziendale. Questa guida si concentra sul ripristino di emergenzaa.
Una soluzione di RE è progettata per ripristinare l'elaborazione delle applicazioni dopo un disastro naturale o provocato dall'uomo o un guasto dell'infrastruttura che causa un'interruzione su larga scala. Queste interruzioni disabilitano non solo il sistema di elaborazione delle applicazioni principale, ma anche qualsiasi sistema di standby che protegge da guasti di sistema su piccola scala o dell'infrastruttura locale.
Altre caratteristiche di una soluzione di RE che la distinguono da una soluzione di alta disponibilità includono:
- Il sistema di ripristino in una soluzione di RE in genere non è un sistema di standby attivo.
- Una procedura di ripristino di emergenza di solito richiede un intervento manuale per recuperare o ripristinare l'elaborazione delle applicazioni da backup o repliche di dati, sistemi e infrastrutture.
- La soluzione include un sito di ripristino che si trova in una posizione geografica diversa rispetto al sistema principale.
- Il Recovery Time Objective (RTO) per una soluzione di ripristino di emergenza viene in genere misurato in ore, se non giorni.
La seguente architettura di esempio mostra un sistema SAP che include sia una soluzione HA sia una soluzione RE. Il sito di DR, in cui il sistema verrà ripristinato dopo un'emergenza, si trova a destra nella regione 2. Il sistema principale si trova a sinistra nella Regione 1 ed è configurato per l'alta disponibilità con cluster di failover che si estendono su due zone. La funzione di backup della soluzione di RE è rappresentata da linee tratteggiate che si estendono su entrambe le regioni. Per l'archiviazione, i sistemi utilizzano un bucket Cloud Storage multiregionale, mostrato nella parte inferiore del diagramma.
L'esempio mostra anche un database. Sebbene il recupero delle applicazioni dipenda dal recupero dei dati, le procedure diRER per i sistemi di database non sono trattate in questa guida. Consulta la documentazione del database e le note SAP applicabili. Questa guida si concentra in modo specifico sul sistema SAP NetWeaver (SAP ASCS/ERS) e sui server delle applicazioni (SAP AAS).
Per informazioni sull'implementazione di sistemi SAP ad alta disponibilità su Google Cloud, consulta la Guida alla pianificazione dell'alta disponibilità per SAP NetWeaver su Google Cloud.
Per informazioni sull'alta disponibilità e sul ripristino di emergenza per SAP HANA su Google Cloud, consulta Guida alla pianificazione dell'alta disponibilità di SAP HANA e Guida alla pianificazione del ripristino di emergenza di SAP HANA, rispettivamente.
Per informazioni generali sul RE su Google Cloud, vedi la Guida alla pianificazione del ripristino di emergenza.
Approcci di progettazione RE per i sistemi SAP non in esecuzione su Google Cloud
Se il tuo sistema SAP principale non è in esecuzione su Google Cloud, puoi adottare un approccio di lift and shift alla tua soluzione di RE, in cui l'architettura e il software del sistema di RE su Google Cloud sono gli stessi del sistema principale. In alternativa, puoi adottare un approccio cloud-native, in cui, nell'ambito della progettazione della tua soluzione di RE, ottimizzi il sistema recuperato per il cloud, supportato da prodotti o servizi di Google Cloud o Google Cloud partner.
Se utilizzi un approccio lift-and-shift, devi confermare che l'architettura del tuo sistema principale sia completamente supportata su Google Cloud. Per entrambi gli approcci, devi assicurarti che tutto il software che utilizzi sia correttamente concesso in licenza per l'uso su Google Cloud.
Per ulteriori informazioni sulle licenze, consulta i Termini di servizio della piattaforma Google Cloud.
Elementi di progettazione di una soluzione di RE per SAP NetWeaver su Google Cloud
Gli elementi di progettazione di una soluzione di RE per SAP NetWeaver su Google Cloud possono includere quanto segue:
- Posizione del sito di RE
- Networking
- Sicurezza
- Considerazioni sulla macchina virtuale (VM)
- Opzioni di backup
- Archiviazione
Per implementare ciascuno di questi elementi di progettazione, hai a disposizione diverse opzioni per soddisfare i tuoi obiettivi di recupero e di costo.
Posizione del sito di RE
Quando scegli una regione Google Cloud per il tuo sito di RE, devi considerare:
- L'area di potenziale impatto di qualsiasi disastro che potrebbe verificarsi nel tuo sito principale
- La posizione degli utenti del tuo sistema SAP NetWeaver
- Se le risorse e le funzionalità utilizzate dal tuo sistema SAP sono disponibili nella regione e nella zona che scegli Google Cloud
Scegli una Google Cloud regione per il sito di RE sufficientemente distante dal sito principale in modo che non venga interessato da eventuali disastri che potrebbero verificarsi nel sito principale. Una distanza di 160 km o più è generalmente considerata sufficiente, ma le normative o le linee guida organizzative potrebbero richiedere una distanza minima diversa.
Se il tuo sistema SAP principale è in esecuzione su Google Cloud, posiziona il sito di RE in una regione Google Cloud vicina ai tuoi utenti, diversa da quella in cui è in esecuzione il sistema principale. Le regioniGoogle Cloud sono situate a una distanza sufficiente l'una dall'altra in modo che nessuna delle due regioni Google Cloud possa essere interessata dallo stesso disastro.
Se il tuo sistema SAP principale viene eseguito al di fuori di Google Cloud, posiziona il sito di RE in una regione il più vicina possibile ai tuoi utenti senza trovarsi nella zona di potenziale impatto di eventuali disastri che potrebbero verificarsi nel sito principale.
Nella regione di RE, posiziona il sistema di RE in una zona che supporti i tipi di istanza VM e l'altra infrastruttura richiesta dai sistemi SAP e di database.
Dopo aver selezionato una regione per il sito di RE, potresti dover aumentare le quote delle risorse per la regione per fornire risorse sufficienti al sistema di RE prima di un evento.
Per le posizioni di tutte le Google Cloud regioni, consulta Regioni e zone.
Per visualizzare le funzionalità disponibili in ogni regione, consulta Regioni e zone disponibili.
Per esaminare quali risorse Google Cloud sono globali, regionali e di zona, consulta Risorse globali, regionali e di zona.
Networking
Su Google Cloud, Virtual Private Cloud (VPC) fornisce funzionalità di rete che possono estendersi in tutto il mondo.
Devi creare una rete VPC per il tuo sito di RE se non ne esiste già una. Devi anche creare una subnet e un intervallo IP per il sito di RE.
Se il sistema principale è attivo Google Cloud, la configurazione della rete è più semplice se i siti principale e di RE si trovano nella stessa rete VPC. Tuttavia, se necessario, puoi posizionare i siti principali e di RE in reti VPC diverse o persino in progetti diversi.
Quando progetti la tua soluzione di RE, devi considerare i seguenti percorsi di comunicazione:
- La connessione tra il sito principale e il sito di ripristino in Google Cloud
- La comunicazione interna tra le applicazioni, i database e i server che compongono il tuo sistema SAP
- La connessione tra gli utenti e il sistema SAP
Per le connessioni da siti esterni a Google Cloud, Google Cloud offre una serie di prodotti di rete per supportare ciascuno di questi punti di connessione.
Connessione del sito principale al sito di RE
La connessione tra il sito principale e il sito di RE è necessaria per archiviare i backup o fornire un percorso di replica tra i due sistemi in modo che le risorse di ripristino siano immediatamente disponibili in caso di emergenza e per testare le procedure di emergenza.
Se il sistema principale è in esecuzione su Google Cloud, la disponibilità dei backup nel sito diRER è quasi automatica. Gli snapshot di Compute Engine possono essere designati come multiregionali. Altri backup possono essere archiviati direttamente dal sistema principale in bucket Cloud Storage multiregionali per la disponibilità immediata nel sito di RE.
Se il sistema principale non è in esecuzione su Google Cloud, puoi connettere il sito principale al sito di RE su Google Cloud utilizzando Cloud Interconnect o Cloud VPN.
Per un esempio di topologia Cloud Interconnect a disponibilità elevata che, con alcune modifiche, potrebbe essere adattata a uno scenario di RE, consulta Definizione di una disponibilità del 99,99% per Dedicated Interconnect.
Per alcuni esempi di topologie di gateway VPN multiregionali ad alta disponibilità che possono essere adattate anche a uno scenarioREa, consulta Topologie Cloud VPN.
Una considerazione fondamentale quando configuri la connessione a Google Cloud da un sito esterno alla piattaforma è la larghezza di banda. La connessione deve supportare adeguatamente il trasferimento regolare di dati e backup a Google Cloud.
Per saperne di più sulle opzioni di connessione a Google Cloud da siti esterni alla piattaforma, vedi Prodotti di connettività ibrida.
Connettività tra applicazioni, database e server SAP
Se il tuo sistema principale è in esecuzione su Google Cloud, mantenere la connettività tra le applicazioni, i database e i server SAP nel sito di RE è una questione relativamente più semplice di modellazione dei nomi host, delle subnet, dei firewall e così via nel sito principale.
Se il tuo sistema principale non viene eseguito su Google Cloud, potrebbe essere necessario un maggiore impegno nella fase di progettazione per convertire l'architettura di rete del sito principale nel sito dREDR su Google Cloud.
Testare le procedure di RE è fondamentale per identificare e risolvere eventuali problemi di connettività prima che la tua attività debba dipendere dal sistema recuperato.
Connessione degli utenti al sito di RE
In un ripristino, dopo che il sistema SAP viene ripristinato nel sito di RE, il traffico dei tuoi utenti deve essere reindirizzato al sistema recuperato. In genere, questa operazione viene eseguita aggiornando gli alias di rete nelle voci DNS con i nuovi indirizzi IP, che sono regionali.
Se la tua architettura di rete utilizza le route VPC, dovrai aggiornare le route durante il ripristino.
Su Google Cloud, puoi utilizzare Cloud DNS oppure un'altra soluzione DNS.
Risorse di networking regionali
Se il tuo sistema principale è in esecuzione su Google Cloud e utilizzi risorse di rete regionali come Cloud NAT o un Cloud Load Balancing regionale, hai bisogno di un'istanza della risorsa in ogni regione.
Per ulteriori informazioni:
Controllo dell'accesso alla rete
Assicurati che le stesse porte siano aperte nel sito di RE e nel sito principale.
Puoi definire regole firewall nella tua rete VPC per controllare il traffico da e verso le tue VM.
Se hai un servizio Active Directory su Windows Server, devi configurarlo prima del ripristino e mantenerlo sincronizzato con l'istanza di Active Directory nel sito principale.
Sicurezza
Devi implementare gli stessi controlli di sicurezza e autorizzazioni che hai nel sito principale nel sito di RE. Al tuo ambiente recuperato si applicano anche le stesse normative di conformità.
Qualsiasi utente o ruolo che richiede l'accesso al sito principale richiede l'accesso anche al sitoREa.
Per informazioni generali sulla progettazione della sicurezza per una soluzione di RE su Google Cloud, vedi Implementazione dei controlli di sicurezza e conformità.
Considerazioni sulle VM
Puoi velocizzare il deployment delle tue istanze di macchine virtuali (VM) Compute Engine ed evitare errori di configurazione nel sito di RE utilizzando le configurazioni Terraform fornite da Google Cloud, prodotti e funzionalità come Cloud Deployment Manager, modelli di istanza e immagini personalizzate.
Configurazione e deployment delle macchine virtuali
Google Cloud fornisce file di configurazione Terraform e modelli di Deployment Manager per SAP su Google Cloud che puoi utilizzare per predefinire ed eseguire il deployment del sistema SAP nel sito di RE. L'utilizzo dei file Terraform o Deployment Manager velocizza il deployment, riduce gli errori di configurazione e garantisce che i tuoi sistemi SAP soddisfino i requisiti di assistenza SAP.
Un'altra opzione per configurare le VM in anticipo sono i modelli di istanza di Compute Engine. L'utilizzo dei modelli di istanza è un modo per velocizzare l'implementazione e ridurre la configurazione manuale delle VM durante il ripristino. Tuttavia, poiché richiedono una riconfigurazione per il sito di RE, potrebbe essere più semplice recuperare le VM da un disco di avvio di ripristino, come descritto nella sezione successiva.
Per ulteriori informazioni sui modelli di istanza, vedi Modelli di istanza.
Puoi anche utilizzare strumenti di orchestrazione del deployment, come Terraform, per gestire i deployment dell'infrastruttura su Google Cloud.
A seconda dell'RTO, puoi pre-eseguire il deployment delle istanze Compute Engine oppure, poiché il deployment di una VM richiede solo pochi minuti, puoi eseguirlo al momento del ripristino.
Se esegui il pre-deployment delle VM, puoi arrestarle per risparmiare sui costi oppure puoi utilizzarle per altri scopi non essenziali finché non sono necessarie per il ripristino.
Puoi anche ridurre al minimo i costi consolidando un sistema distribuito su un numero inferiore di VM nel sito di ripristino. Ad esempio, se i server delle applicazioni nel sito principale si trovano su host dedicati nel sito principale, nel sito di RE puoi inserire i server delle applicazioni sullo stesso host di SAP Central Services. Tuttavia, devi valutare il risparmio sui costi rispetto alla maggiore complessità di configurazioni diverse in ogni sito.
Disco di avvio di ripristino
Puoi creare un'immagine personalizzata dal disco di avvio dell'host nel sistema principale e poi utilizzare l'immagine personalizzata per creare l'istanza di ripristino nel sito di RE.
Se il tuo sistema è in esecuzione su Google Cloud, crea un'immagine personalizzata se hai creato e modificato un disco di avvio permanente Compute Engine per il tuo sistema principale. Se utilizzi un'immagine pubblica Google Cloud non modificata, puoi utilizzare l'immagine pubblica Google Cloud anche nel sito di recupero. Per maggiori informazioni, vedi Creare, eliminare e impostare come obsolete le immagini personalizzate.
Se il tuo sistema non è in esecuzione su Google Cloud, puoi importare un'immagine disco di avvio in Google Cloud dal tuo ambiente on-premise oppure importare dischi virtuali da VM in esecuzione sulla tua workstation locale o su un'altra piattaforma cloud.
Opzioni di backup
Google Cloud offre diverse opzioni di backup tra cui puoi scegliere quando progetti una soluzione di RE:
- Immagini personalizzate di Compute Engine
- Snapshot disco permanente di Compute Engine
- Replica
Immagini personalizzate di Compute Engine
Per eseguire il backup del disco di avvio del sistema principale da utilizzare per il ripristino, puoi archiviarlo su Google Cloud come immagine personalizzata di Compute Engine. Per ulteriori informazioni, vedi Disco di avvio di ripristino.
Snapshot disco permanente di Compute Engine
Per eseguire il backup di SAP o di altri file system che si trovano su un disco permanente Compute Engine, puoi utilizzare gli snapshot del disco permanente.
Puoi anche definire una pianificazione degli snapshot per eseguirli automaticamente a intervalli regolari. Consulta Creazione di snapshot pianificati per dischi permanenti.
Gli snapshot forniscono solo coerenza a livello di blocco. Per garantire la coerenza a livello di file, potresti dover implementare meccanismi per sospendere l'attività di scrittura sui file system di destinazione durante questi snapshot.
Replica
A seconda della soluzione di archiviazione condivisa e dei Recovery Point Objective, puoi replicare i file system. La replica può essere utilizzata per database, archiviazione a livello di blocco o file.
La progettazione di una soluzione di RE che utilizza la replica è ideale per le applicazioni business critical che hanno una tolleranza molto bassa alla perdita di dati.
Se il tuo sistema principale è in esecuzione su Google Cloud, i bucket multiregionali e gli snapshot multiregionali vengono replicati per te tra le regioni selezionate.
Per la replica dell'archiviazione a livello di blocchi, puoi utilizzare PD Async Replication. La replica asincrona del disco permanente (PD Async Replication) fornisce una replica asincrona con RPO (Recovery Point Objective) e RTO (Recovery Time Objective) bassi per il ripristino di emergenza attivo-passivo tra regioni.
Puoi anche utilizzare la replica fornita da soluzioni di archiviazione di terze parti.
Disaster recovery utilizzando la replica asincrona del disco permanente e Jetstream
Compute Engine utilizza PD Async Replication per la replica dei dati tra regioni. La replica asincrona PD facilita la replica dei dati associati a singole macchine virtuali (VM) o a gruppi di VM dipendenti utilizzando i gruppi di coerenza. Jetstream è un'offerta di un marketplace di terze parti che automatizza la replica dei server delle applicazioni SAP, riducendo così il carico operativo della gestione del RE per gli amministratori.
Jetstream viene implementato come appliance virtuale che opera come livello di supervisione sulla replica asincrona del disco permanente. Questo appliance concede il controllo e viene implementato su una VM all'interno dei progetti dei clienti ed eseguito nei progetti di servizio, con un controllo elevato su VM e progetti dei clienti specificati.
Puoi utilizzare Jetstream con la replica asincrona PD per ottenere ripristino di emergenza per i carichi di lavoro dei server delle applicazioni stateless come ABAP. Per i database, incluso SAP HANA, ti consigliamo di utilizzare metodi di replica nativi del database, come la replica del sistema HANA (HSR).
Archiviazione
Quando progetti una soluzione di RE su Google Cloud, è probabile che utilizzi più tipi di archiviazione, a seconda di dove viene eseguito il sistema principale e di cosa stai archiviando.
Bucket Cloud Storage per i file di backup
Per i backup diversi dagli snapshot del disco, ad esempio i file che carichi da un sistema SAP che non è in esecuzione su Google Cloud, crea un bucket in Cloud Storage a cui puoi accedere sia dal sito principale che da quello di RE. Quando crei un bucket, scegli una classe di archiviazione e una località predefinite.
Seleziona una classe di archiviazione predefinita in base all'accordo sul livello del servizio (SLA) che ti serve, all'utilizzo previsto dello spazio di archiviazione e ai vincoli di costo. Per il ripristino di emergenza, la classe Coldline Storage è spesso una buona opzione.
Per la posizione del bucket, scegli una posizione che includa la regione del sito di RE e, se il sistema principale è in esecuzione su Google Cloud, la regione del sito principale.
Se il sistema principale è attivo Google Cloud, scegli una località multiregionale che includa le regioni dei siti principali eREa in modo da poter accedere al bucket da entrambi i siti.
Se il sistema principale non è attivo Google Cloud, per risparmiare puoi selezionare una località a una sola regione nella regione che include il sitREza.
Se il tuo sistema principale è attivo Google Cloud e utilizzi una soluzione di terze parti per lo spazio di archiviazione condiviso, le tue opzioni di archiviazione potrebbero essere determinate dalla soluzione. Consulta la documentazione della soluzione o il tuo rappresentante diassistenza clienti Google Cloude.
Per informazioni sui prezzi, consulta la pagina Prezzi di Cloud Storage.
Storage per gli snapshot disco permanente di Compute Engine
Quando crei uno snapshot, puoi specificare una posizione di archiviazione. La posizione di uno snapshot influisce sulla sua disponibilità e può comportare costi di networking quando crei lo snapshot o lo ripristini su un nuovo disco.
Gli snapshot possono essere archiviati in una posizione multiregionale di Cloud Storage, ad esempio asia, o in una posizione regionale di Cloud Storage, ad esempio asia-south1.
Una località di archiviazione multiregionale offre una disponibilità più elevata e potrebbe ridurre i costi di rete durante la creazione o il ripristino di uno snapshot. Una posizione di archiviazione regionale ti offre un maggiore controllo sulla posizione fisica dei tuoi dati.
Indipendentemente dalle opzioni di località scelte, gli snapshot devono essere archiviati in una località accessibile dal sito diRER.
Per saperne di più sulle posizioni degli snapshot, consulta la sezione Selezione della posizione di archiviazione per uno snapshot.
Per informazioni sui prezzi dell'archiviazione degli snapshot, consulta Prezzi di Persistent Disk.
Archiviazione per immagini personalizzate
Dopo aver aggiunto i file di immagini personalizzate all'elenco delle immagini personalizzate, Compute Engine gestisce l'archiviazione delle immagini. Le immagini in un elenco di immagini personalizzato sono risorse globali, quindi sono disponibili in qualsiasi regione.
Per informazioni sui prezzi dell'archiviazione di immagini personalizzate, consulta la sezione "Archiviazione di immagini personalizzate" in Prezzi dei dischi e delle immagini.
Test del piano di RE
Una volta completato il piano di ripristino di emergenza, testalo regolarmente, annotando eventuali problemi che si presentano e modificando il piano di conseguenza.
Assicurati di testare tutti gli aspetti del tuo piano di RE, inclusi:
- Backup e pianificazioni di backup
- Trasferimento di dati da siti esterni alla piattaforma
- Recupero dai backup archiviati
- Controlli di sicurezza e accesso al sistema
- Routing di rete
Quando testi i sistemi di RE, i sistemi principali continuano a funzionare. Per evitare conflitti o scenari di split brain, devi isolare il sistema di test dal sistema principale e dai relativi utenti.
Per informazioni generali sui test di RE su Google Cloud, consulta la Guida alla pianificazione del ripristino di emergenza.
Progettare la soluzione di RE per soddisfare i tuoi RPO e RTO
Alcuni Google Cloud prodotti, funzioni e servizi sono fondamentali per progettare una soluzioneRER che soddisfi i tuoi RPO e RTO.
Progettazione per l'RPO
Quando progetti una soluzione di RE su Google Cloud per soddisfare un particolare RPO, esistono due variabili che controllano il momento nel tempo in cui puoi eseguire il ripristino:
- Frequenza del backup
- Conservazione backup
Frequenza del backup
La frequenza di backup determina la quantità massima di tempo che può trascorrere tra l'ultimo backup e un disastro. Se crei i backup di RE ogni 24 ore, potresti potenzialmente perdere quasi 24 ore di aggiornamenti dei dati se si verifica un problema 23 ore e 59 minuti dopo l'ultimo backup.
La replica può ridurre a quasi zero il tempo massimo trascorso dall'ultimo backup. Tuttavia, la replica è costosa, quindi potresti utilizzarla solo per i database e i file delle applicazioni business critical.
In una soluzione di RE, le copie o gli snapshot point-in-time vengono comunemente utilizzati per eseguire il backup dei file system dell'applicazione SAP necessari per il recupero.
Su Google Cloud, puoi automatizzare gli snapshot dei dischi permanenti Compute Engine creando una pianificazione degli snapshot oraria, giornaliera o settimanale. Tuttavia, poiché il controllo degli snapshot di Compute Engine per la coerenza avviene solo a livello di blocco, valuta la possibilità di sospendere l'attività di scrittura sui file system di destinazione durante gli snapshot per garantire la coerenza a livello di file.
Il costo principale da considerare quando si sceglie una frequenza di backup è il costo del trasferimento dei dati. Anche il costo di archiviazione è un fattore da considerare, ma la norma di conservazione dei backup potrebbe avere un impatto maggiore sui costi di archiviazione rispetto alla frequenza dei backup.
Per saperne di più sulle pianificazioni snapshot, consulta Creazione di snapshot pianificati per il disco permanente.
Conservazione backup
La conservazione dei backup determina quanto indietro nel tempo puoi spostare il punto di ripristino. La conservazione delle copie di backup aiuta a proteggersi dagli errori logici consentendoti di eseguire il ripristino a un momento precedente alla loro esistenza.
Puoi impostare criteri di conservazione per gli snapshot Compute Engine e i bucket Cloud Storage che eliminano automaticamente i file di backup dopo un periodo di tempo specificato.
Il costo principale da considerare quando scegli un criterio di conservazione è il costo dell'archiviazione. Gli snapshot di Compute Engine riducono la quantità di spazio di archiviazione necessaria per più snapshot memorizzando solo le modifiche incrementali a livello di blocco dopo la memorizzazione del primo snapshot completo.
Per saperne di più sulla definizione delle norme di conservazione per gli snapshot, consulta Norme di conservazione degli snapshot.
Per informazioni sull'impostazione delle norme di conservazione sui bucket Cloud Storage, consulta Norme di conservazione che utilizzano il blocco dei bucket.
Progettazione per l'RTO
Quando progetti la tua soluzione di Google Cloud DR per soddisfare un particolare RTO, la variabile di controllo principale è la preparazione dell'infrastruttura, del software, dei file system e dei dati nel sito di RE.
Ad esempio, per ottenere un RTO molto basso, potresti mantenere un sistema hot standby nel sito diRER, con infrastruttura pre-deployment, sistemi SAP attivi e dati replicati. Tuttavia, il basso RTO ha un costo più elevato.
Puoi bilanciare i costi e i tempi di ripristino configurando in anticipo un'infrastruttura a costi ridotti o nulli e rimandando alcuni passaggi di configurazione al momento del ripristino.
Ad esempio, puoi configurare e deployment una VM in anticipo, ma poi arrestarla. Le risorse collegate alla VM, come eventuali IP statici esterni o dischi permanenti, potrebbero comunque comportare costi, ma la VM arrestata stessa no.
Poiché puoi configurare e implementare una VM Compute Engine su Google Cloud in modo relativamente rapido, potresti essere in grado di farlo al momento del ripristino e rispettare comunque il RTO, soprattutto se utilizzi Terraform o Deployment Manager per implementare il sistema di RE o creare la VM da un modello e un'immagine personalizzata che crei in anticipo.
Considerazioni su quota e risorse per soluzioni di DR con RTO elevato
Se non esegui il pre-deployment dell'infrastruttura e dei sistemi, controlla periodicamente le quote delle risorse nella regione del sito di RE per assicurarti che siano sufficienti per il deployment del sistema di RE.
Il pre-deployment di gran parte dell'infrastruttura e dei sistemi di RE consentirà di assicurarti che il sistema di RE rientri nelle quote e che le risorse Google Cloud di cui ha bisogno siano disponibili quando necessarie.
Architetture di esempio per obiettivi diversi
I seguenti diagrammi dell'architettura mostrano esempi di progetti di RE per diversi RTO.
Ciascuno dei diagrammi mostra le opzioni di backup multiregione a sinistra e una corrispondente configurazione SAP semplificata nel sito diRER a destra.
Ogni esempio mostra una possibile combinazione di elementi di progettazione RE. Per adattare il tuo progetto di RE ai tuoi obiettivi e alle tue circostanze, puoi combinare elementi di uno o più esempi.
Esempio di architettura di RE con RTO basso
Il seguente diagramma dell'architettura mostra un esempio di progettazione di DR con RTO basso.
In questo progetto, mantieni un sistema SAP quasi funzionale nel sito di RE. Le VM sono implementate e attive. I server delle applicazioni SAP e il server di database sono attivi, ma il servizio applicazione è arrestato.
Le opzioni di backup che probabilmente utilizzerai in questo scenario includono immagini del sistema operativo archiviate in Compute Engine e snapshot di disco permanente archiviati in Compute Engine, nonché la replica dei dati tra i siti primario e di RE. Per la replica dei dati, puoi utilizzare PD Async Replication.
Poiché viene utilizzata la replica dei dati, il rischio di perdita dei dati è limitato all'ultima sincronizzazione del database.
Per estendere l'RPO nel tempo, puoi aggiungere backup dei dati a Cloud Storage, che non è mostrato nel diagramma. Per gli snapshot del disco permanente, puoi utilizzare gli snapshot pianificati e regolare la policy di conservazione in base al tuo RPO.
Le azioni che devi intraprendere per ripristinare un sistema con RTO basso come questo includono:
- Se necessario, esegui una sincronizzazione finale dei file o recupera i file da uno snapshot del disco permanente.
- Passaggio del database principale al sito di RE.
- Avvio dell'applicazione nel sito di RE.
Delle tre architetture di esempio mostrate, quella con RTO basso è la più costosa.
Architettura di RE di esempio con RTO medio
La seguente architettura di RE di esempio ha un RTO più elevato rispetto all'esempio precedente, ma un costo inferiore.
In questa progettazione, il server di database è attivo per supportare la replica dal sito principale. Le VM per i server delle applicazioni non sono attive.
Le opzioni di backup che probabilmente utilizzerai in questo scenario includono immagini del sistema operativo e snapshot di disco permanente archiviati in Compute Engine e la replica dei dati tra i siti primario e di RE. Per la replica dei dati, puoi utilizzare PD Async Replication.
Poiché viene utilizzata la replica dei dati, il rischio di perdita dei dati è limitato all'ultima sincronizzazione del database.
Per estendere l'RPO indietro nel tempo, puoi archiviare i backup dei dati in un bucket Cloud Storage, che non è mostrato nel diagramma. Per gli snapshot del disco permanente, puoi utilizzare gli snapshot pianificati e modificare il criterio di conservazione in base al tuo RPO.
A seconda dei requisiti del sistema di database, potresti essere in grado di eseguire il deployment del database su una VM più piccola nel sito di RE rispetto a quella richiesta nel sito principale, il che può contribuire a ridurre i costi fino all'attivazione del sistema di RE. In questo caso, devi ridimensionare la VM alla dimensione richiesta durante il ripristino.
Le azioni da intraprendere per ripristinare un sistema come questo includono:
- Se necessario, il deployment delle istanze VM per SAP NetWeaver e dei server delle applicazioni da snapshot o immagini del disco permanente.
- Sincronizzazione dei file system da snapshot del disco permanente o da un altro spazio di archiviazione.
- Se necessario, ridimensiona l'istanza VM del database.
- Passaggio del database principale al sito di RE.
- Avvio del servizio di applicazione nel sito di RE.
Esempio di architettura di RE con RTO elevato
Il seguente diagramma dell'architettura ha il RTO più elevato degli esempi mostrati ed è l'opzione più economica.
In questa progettazione, puoi pre-deployare i server e poi arrestarli per evitare di incorrere in addebiti per le VM oppure, per evitare costi associati a dischi permanenti e altre risorse correlate alle VM, puoi eseguire il deployment delle VM nell'ambito della procedura di ripristino.
Le opzioni di backup che probabilmente utilizzerai in questo scenario includono immagini del sistema operativo snapshotdisco permanentei archiviati in Compute Engine e backup dei dati archiviati in Cloud Storage.
Per soddisfare il tuo RPO, puoi modificare sia la frequenza di backup sia le norme di conservazione delle pianificazioni degli snapshot e dei backup nel bucket Cloud Storage.
Le azioni da intraprendere per ripristinare un sistema come questo includono:
- Se necessario, esegui il deployment delle istanze VM per SAP NetWeaver, dei server delle applicazioni e del server di database da snapshot o immagini di disco permanente multiregionali archiviati in Compute Engine.
- Sincronizzazione dei file system da snapshot di disco permanente o da altro spazio di archiviazione.
- Recupero del database dai file di backup nel bucket Cloud Storage multiregionale o altrove.
- Passaggio del database principale al sito di RE.
- Avvio del servizio di applicazione nel sito di RE.
Partner e prodotti per soluzioni di RE per SAP su Google Cloud
Puoi trovare partner che ti aiutino con la tua soluzione di RE nella Google Cloud directory dei partner.
Puoi anche trovare vari prodotti e partner per supportare la tua soluzione di RE su Google Cloud Marketplace.