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 cloud provider.
Definizione del ripristino di emergenza
Il ripristino di emergenza (RE) e l'alta disponibilità (HA) sono due elementi distinti nel concetto più ampio di continuità aziendale. Questa guida si concentra sul ripristino di emergenza.
Una soluzione di RE è progettata per ripristinare l'elaborazione delle applicazioni dopo una calamità naturale o provocata dall'uomo o un guasto dell'infrastruttura che provoca un'interruzione su vasta scala. Queste interruzioni disabilitano non solo il sistema di elaborazione delle applicazioni principale, ma anche qualsiasi sistema in standby che protegge da guasti del sistema su scala ridotta o dell'infrastruttura locale.
Altre caratteristiche di una soluzione di RE che la distinguono da una soluzione ad alta disponibilità includono:
- Il sistema di ripristino in una soluzione di RE in genere non è un sistema hot-standby.
- Una procedura di ripristino di emergenza solitamente richiede un intervento manuale per recuperare o ripristinare l'elaborazione delle applicazioni dai backup o dalla replica di dati, sistemi e infrastruttura.
- La soluzione include un sito di recupero che si trova in una posizione geografica diversa rispetto al sistema principale.
- L'RTO (Recovery Time Objective) per una soluzione di ripristino di emergenza viene in genere misurato in ore, se non in giorni.
L'architettura di esempio seguente mostra un sistema SAP che include sia una soluzione ad alta disponibilità sia una soluzione di RE. Il sito di RE, in cui il sistema verrà ripristinato dopo un'emergenza, si trova a destra nell'area geografica 2. Il sistema principale si trova a sinistra in Regione 1 ed è configurato per l'alta disponibilità con cluster di failover che coprono due zone. La funzione di backup della soluzione di RE è rappresentata da linee tratteggiate che coprono entrambe le regioni. Per l'archiviazione, i sistemi utilizzano un bucket Cloud Storage su più regioni, mostrato alla fine del diagramma.
L'esempio mostra anche un database. Sebbene il recupero delle applicazioni dipenda dal recupero dei dati, le procedure di RE per i sistemi di database non sono trattate in questa guida. Fai riferimento alla documentazione del database ed eventuali note SAP applicabili. Questa guida si concentra in particolare 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 rispettivamente la guida alla pianificazione dell'alta disponibilità di SAP HANA e la guida alla pianificazione del ripristino di emergenza di SAP HANA.
Per informazioni generali sul RE su Google Cloud, consulta la Guida alla pianificazione del ripristino di emergenza.
Approcci di progettazione di RE per sistemi SAP non in esecuzione su Google Cloud
Se il tuo sistema SAP principale non è in esecuzione su Google Cloud, puoi adottare un approccio 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 Google Cloud o partner di Google Cloud.
Se utilizzi un approccio lift and shift, devi confermare che l'architettura del tuo sistema principale sia completamente supportata su Google Cloud. In entrambi i casi, devi assicurarti che tutto il software che utilizzi sia debitamente autorizzato per l'utilizzo su Google Cloud.
Per ulteriori informazioni sulle licenze, consulta i Termini di servizio della piattaforma Google Cloud.
Progettare gli elementi 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 sito di RE
- Networking
- Sicurezza
- Considerazioni sulle macchine virtuali (VM)
- Opzioni di backup
- Archiviazione
Per implementare ciascuno di questi elementi di progettazione, hai a disposizione varie opzioni per raggiungere i tuoi obiettivi di ripristino e costo.
Posizione sito di RE
Quando scegli una regione Google Cloud per il tuo sito di RE, devi considerare:
- L'area del potenziale impatto di qualsiasi calamità che potrebbe verificarsi nel tuo sito principale
- La località degli utenti del sistema SAP NetWeaver
- Se le risorse e le funzionalità di Google Cloud utilizzate dal sistema SAP sono disponibili nella regione e nella zona che hai scelto
Scegli per il tuo sito di RE una regione Google Cloud sufficientemente distante dal sito principale in modo che il sito di RE non sia interessato da eventuali problemi che potrebbero verificarsi nel sito principale. Una distanza di 100 miglia o più è in genere considerata sufficiente, ma regolamenti o 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 qualsiasi regione Google Cloud vicina agli utenti, diversa dalla regione in cui è in esecuzione il sistema principale. Le regioni Google Cloud sono sufficientemente distanti l'una dall'altra in modo che nessuna regione Google Cloud possa essere interessata dalla stessa calamità.
Se il tuo sistema SAP principale è in esecuzione al di fuori di Google Cloud, posiziona il sito di RE in una regione il più vicina possibile agli utenti, senza rientrare nella zona di potenziale impatto di qualsiasi calamità che potrebbe verificarsi sul sito principale.
Nella regione di RE, posiziona il sistema di RE in una zona che supporti i tipi di istanze VM e altre infrastrutture richieste dai tuoi 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 in modo da fornire risorse sufficienti per il sistema di RE prima di un evento.
Per le località di tutte le regioni di Google Cloud, 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, a livello di regione e a livello di zona, consulta Risorse globali, a livello di regione e di zona.
Networking
Su Google Cloud, Virtual Private Cloud (VPC) fornisce funzionalità di networking che possono essere estese in tutto il mondo.
Devi creare una rete VPC per il 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 si trova su Google Cloud, la configurazione della rete è più semplice se entrambi i siti principale e di RE si trovano nella stessa rete VPC. Tuttavia, se necessario, puoi inserire i siti principali e di RE in diverse reti VPC o anche in progetti diversi.
Durante la progettazione della 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 sistema SAP
- La connessione tra i tuoi utenti e il sistema SAP
Per le connessioni da siti esterni a Google Cloud, Google Cloud offre una varietà di prodotti di networking per supportare ognuno di questi punti di connessione.
Collegamento 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 tuo sistema principale è in esecuzione su Google Cloud, rendere disponibili i backup nel sito di RE è quasi automatico. Gli snapshot di Compute Engine possono essere designati come multiregionali. Altri backup possono essere archiviati direttamente dal sistema principale in bucket Cloud Storage su più regioni per garantire la disponibilità immediata presso il 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 ad alta disponibilità che, con alcune modifiche, potrebbe essere adattata a uno scenario di RE, consulta Stabilire una disponibilità del 99,99% per Dedicated Interconnect.
Per alcuni esempi di topologie di gateway VPN a più regioni a disponibilità elevata che possono essere adattate anche a uno scenario di RE, consulta Topologie Cloud VPN.
Una considerazione fondamentale per la configurazione della connessione a Google Cloud da un sito esterno alla piattaforma è la larghezza di banda. La connessione deve supportare in modo adeguato il regolare trasferimento di dati e backup in Google Cloud.
Per ulteriori informazioni sulle opzioni a tua disposizione per la connessione a Google Cloud da siti esterni alla piattaforma, consulta Prodotti per la connettività ibrida.
Connettività tra server, database e applicazioni 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 è relativamente semplice per la modellazione di nomi host, subnet, firewall e così via sul sito principale.
Se il tuo sistema principale non è in esecuzione su Google Cloud, in fase di progettazione potrebbe essere necessario un maggiore impegno per tradurre l'architettura di networking del sito principale nel sito di RE su Google Cloud.
Il test delle procedure di RE è fondamentale per identificare e risolvere eventuali problemi di connettività prima che l'attività debba dipendere dal sistema ripristinato.
Collegare gli utenti al sito di RE
In un ripristino, dopo che il sistema SAP è stato ripristinato sul sito di RE, il traffico degli utenti deve essere reindirizzato al sistema ripristinato. In genere, puoi farlo aggiornando gli alias di rete nelle voci DNS con i nuovi indirizzi IP che sono a livello di regione.
Se la tua architettura di networking utilizza route VPC, dovrai aggiornarle durante il ripristino.
Su Google Cloud, puoi utilizzare Cloud DNS o un'altra soluzione DNS.
Risorse di networking a livello di regione
Se il tuo sistema principale è in esecuzione su Google Cloud e utilizzi risorse di networking di regione come Cloud NAT o Cloud Load Balancing a livello di regione, hai bisogno di un'istanza della risorsa in ogni regione.
Per ulteriori informazioni:
Controllo dell'accesso alla rete
Assicurati che nel sito di RE siano aperte le stesse porte aperte del sito principale.
Puoi definire regole firewall nella tua rete VPC per controllare il traffico da e verso le VM.
Se disponi di un servizio Active Directory su Windows Server, devi configurarlo prima del ripristino e mantenerlo sincronizzato con l'istanza di Active Directory sul sito principale.
Sicurezza
Devi implementare gli stessi controlli di sicurezza e le stesse autorizzazioni del sito principale del sito di RE. Le stesse normative di conformità si applicano anche all'ambiente recuperato.
Tutti gli utenti o i ruoli che richiedono l'accesso al sito principale devono accedere anche al sito di RE.
Per informazioni generali sulla progettazione della sicurezza per una soluzione di RE su Google Cloud, consulta Implementazione dei controlli di sicurezza e conformità.
Considerazioni sulle VM
Puoi accelerare il deployment delle istanze di macchina virtuale (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 Deployment Manager per SAP su Google Cloud che possono essere utilizzati per predefinire ed eseguire il deployment del sistema SAP presso il sito di RE. L'utilizzo dei file Terraform o Deployment Manager accelera 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 Compute Engine. L'uso dei modelli di istanza consente di accelerare il deployment e ridurre la configurazione manuale delle VM durante il ripristino. Tuttavia, poiché richiedono una riconfigurazione del sito di RE, il recupero delle VM da un disco di avvio di ripristino, come descritto nella sezione successiva, potrebbe essere più semplice.
Per saperne di più sui modelli di istanza, vedi Modelli di istanza.
Puoi anche utilizzare strumenti di orchestrazione dei deployment, come Terraform, per gestire i deployment dell'infrastruttura su Google Cloud.
A seconda dell'RTO, puoi eseguire il deployment preliminare delle istanze di Compute Engine oppure, dal momento che 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 utilizzarle per altri scopi non essenziali fino a quando non sono necessarie per il ripristino.
Inoltre, puoi ridurre al minimo i costi consolidando un sistema distribuito su meno VM nel sito di ripristino. Ad esempio, se i server delle applicazioni del sito principale si trovano su host dedicati nel sito principale, nel sito di RE, potresti collocare i server delle applicazioni nello stesso host dei servizi centrali SAP. Tuttavia, devi valutare il risparmio sui costi rispetto alla maggiore complessità derivante dall'avere diverse configurazioni in ciascun sito.
Disco di avvio di ripristino
Puoi creare un'immagine personalizzata dal disco di avvio dell'host nel sistema principale, quindi utilizzarla per creare l'istanza di ripristino sul sito di RE.
Se il sistema è in esecuzione su Google Cloud, crea un'immagine personalizzata se hai creato e modificato un disco di avvio permanente di Compute Engine per il tuo sistema principale. Se utilizzi un'immagine pubblica di Google Cloud non modificata, puoi usare l'immagine pubblica di Google Cloud anche sul sito di ripristino. Per ulteriori informazioni, consulta Creazione, eliminazione e ritiro di immagini personalizzate.
Se il sistema non è in esecuzione su Google Cloud, puoi importare un'immagine disco di avvio in Google Cloud dal tuo ambiente on-prem oppure importare dischi virtuali dalle VM in esecuzione sulla tua workstation locale o su un'altra piattaforma cloud.
Opzioni di backup
Google Cloud offre una serie di diverse opzioni di backup tra cui scegliere quando progetta una soluzione di RE:
- Immagini personalizzate di Compute Engine
- Snapshot di disco permanente di Compute Engine
- Replica
Immagini personalizzate di Compute Engine
Per eseguire il backup del disco di avvio del sistema principale per utilizzarlo nel ripristino, puoi archiviarlo su Google Cloud come immagine personalizzata di Compute Engine. Per ulteriori informazioni, consulta Disco di avvio di ripristino.
Snapshot di disco permanente di Compute Engine
Per eseguire il backup di SAP o di altri file system che si trovano su un disco permanente di Compute Engine, puoi utilizzare gli snapshot di dischi permanenti.
Puoi anche definire una pianificazione degli snapshot per acquisire snapshot 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 degli obiettivi dei punti di ripristino, puoi replicare i file system. La replica può essere usata per database, archiviazione a livello di blocco o file.
La progettazione di una soluzione di RE che utilizzi la replica è la migliore per le applicazioni business critical con una tolleranza molto bassa per la perdita di dati.
Se il tuo sistema principale è in esecuzione su Google Cloud, i bucket e gli snapshot a più regioni vengono replicati automaticamente tra le regioni selezionate.
Per la replica dell'archiviazione a livello di blocco, puoi utilizzare Replica asincrona DP. La replica asincrona DP offre una replica asincrona con un RPO (Recovery Point Objective) e un RTO (Recovery Time Objective) bassi per il ripristino di emergenza attivo e passivo tra regioni.
Puoi anche utilizzare la replica fornita da soluzioni di archiviazione di terze parti.
Archiviazione
Quando progetti una soluzione di RE su Google Cloud, è probabile che utilizzerai più tipi di archiviazione, a seconda di dove è in esecuzione il sistema principale e di cosa stai archiviando.
Bucket Cloud Storage per i file di backup
Per i backup diversi dagli snapshot dei dischi, ad esempio i file caricati da un sistema SAP non in esecuzione su Google Cloud, crea in Cloud Storage un bucket a cui puoi accedere sia dal sito principale sia dal sito di RE. Quando crei un bucket, scegli una classe di archiviazione predefinita e una località.
Seleziona una classe di archiviazione predefinita in base all'accordo sul livello del servizio (SLA) richiesto, 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 località del bucket, scegli una località 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 tuo sistema principale è su Google Cloud, scegli una località a più regioni che includa le regioni dei siti principale e di RE, in modo da poter accedere al bucket da entrambi i siti.
Se il tuo sistema principale non è su Google Cloud, per risparmiare sui costi puoi selezionare una località con una sola regione che includa il tuo sito di RE.
Se il tuo sistema principale è su Google Cloud e utilizzi una soluzione di terze parti per l'archiviazione condivisa, le opzioni di archiviazione potrebbero essere determinate dalla soluzione. Fai riferimento alla documentazione della soluzione o al tuo rappresentante dell'assistenza clienti Google Cloud.
Per informazioni sui prezzi, vedi Prezzi di Cloud Storage.
Archiviazione per snapshot di disco permanente di Compute Engine
Quando crei uno snapshot, puoi specificare una posizione di archiviazione. La località di uno snapshot influisce sulla sua disponibilità e può comportare costi di rete quando crei lo snapshot o lo ripristini su un nuovo disco.
Gli snapshot possono essere archiviati in una località di Cloud Storage in più regioni, ad esempio asia, o in una località di Cloud Storage a livello di regione, ad esempio asia-south1.
Una località di archiviazione multiregionale offre maggiore disponibilità e potrebbe ridurre i costi di rete durante la creazione o il ripristino di uno snapshot. Una località di Regional Storage ti offre un maggiore controllo sulla posizione fisica dei dati.
Indipendentemente dalle opzioni di località scelte, gli snapshot devono essere archiviati in una località accessibile dal sito di RE.
Per ulteriori informazioni sulle località degli snapshot, consulta Selezione della posizione di archiviazione per uno snapshot.
Per informazioni sui prezzi per l'archiviazione degli snapshot, vedi Prezzi dei dischi permanenti.
Spazio di archiviazione per le immagini personalizzate
Dopo aver aggiunto i file immagine personalizzati all'elenco, Compute Engine gestisce l'archiviazione delle immagini. Le immagini in un elenco personalizzato sono risorse globali, quindi sono disponibili in qualsiasi regione.
Per informazioni sui prezzi di archiviazione delle immagini, vedi Archiviazione delle immagini.
Test del piano di RE
Una volta completato il piano di RE, testalo regolarmente, annotando eventuali problemi e modificando il piano di conseguenza.
Assicurati di testare tutti gli aspetti del tuo piano di RE, inclusi:
- Backup e pianificazioni dei backup
- Trasferimento di dati da siti esterni alla piattaforma
- Ripristino dai backup archiviati
- Controlli di sicurezza e accesso al sistema
- Routing di rete
Quando testi i sistemi di RE, i sistemi principali continueranno a funzionare. Per prevenire conflitti o scenari cerebrali diviso, devi isolare il sistema di test dal sistema principale e dai suoi utenti.
Per informazioni generali sui test di RE su Google Cloud, consulta la Guida alla pianificazione del ripristino di emergenza.
Progetta la tua soluzione di RE in base agli RPO e agli RTO
Alcuni prodotti, funzioni e servizi di Google Cloud sono fondamentali per progettare una soluzione di RE che soddisfi gli RPO e gli RTO.
Progettazione per l'RPO
Quando progetti una soluzione di RE su Google Cloud per soddisfare un determinato RPO, esistono due variabili che controllano il momento in cui puoi recuperare:
- Frequenza di backup
- Conservazione backup
Frequenza di backup
La frequenza di backup determina la quantità massima di tempo che può trascorrere tra l'ultimo backup e un'emergenza. Se crei backup di RE ogni 24 ore, potresti perdere quasi 24 ore di aggiornamenti dei dati se l'emergenza si verifica 23 ore e 59 minuti dopo l'esecuzione dell'ultimo backup.
La replica può ridurre a zero il tempo massimo trascorso dall'ultimo backup. Tuttavia, poiché la replica è costosa, puoi utilizzarla solo per i database e i file delle applicazioni fondamentali per l'attività.
In una soluzione di RE, le copie o gli snapshot point-in-time vengono comunemente utilizzati per eseguire il backup dei file system delle applicazioni SAP necessari per il ripristino.
Su Google Cloud puoi automatizzare gli snapshot dei dischi permanenti di Compute Engine creando una pianificazione oraria, giornaliera o settimanale degli snapshot. Tuttavia, poiché gli snapshot di Compute Engine controllano la coerenza solo a livello di blocco, ti consigliamo 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 nella scelta della frequenza di backup è il costo del trasferimento dei dati. Viene preso in considerazione anche il costo di archiviazione, ma i criteri di conservazione del backup potrebbero avere un impatto sui costi di archiviazione maggiore rispetto alla frequenza del backup.
Per ulteriori informazioni sulle pianificazioni di snapshot, consulta Creazione di snapshot pianificati per dischi permanenti.
Conservazione backup
La conservazione dei backup determina per quanti giorni indietro nel tempo è possibile spostare il punto di ripristino. La conservazione di copie di backup aiuta a proteggere dagli errori logici consentendo il ripristino fino a un momento precedente all'errore logico.
Puoi impostare criteri di conservazione per gli snapshot di Compute Engine e i bucket Cloud Storage che eliminano automaticamente i file di backup dopo un determinato periodo di tempo.
Il costo principale da considerare nella scelta di un criterio di conservazione è il costo dell'archiviazione. Gli snapshot di Compute Engine riducono la quantità di spazio di archiviazione necessaria per più snapshot archiviando solo le modifiche incrementali a livello di blocco dopo l'archiviazione del primo snapshot completo.
Per ulteriori informazioni sulla definizione dei criteri di conservazione per gli snapshot, consulta Criterio di conservazione degli snapshot.
Per informazioni sull'impostazione dei criteri di conservazione per i bucket Cloud Storage, consulta Criteri di conservazione che utilizzano il blocco dei bucket.
Progettazione per RTO
Quando progetti la tua soluzione Google Cloud RE per soddisfare un determinato RTO, l'idoneità dell'infrastruttura, del software, dei file system e dei dati presso il sito di ripristino di emergenza è la variabile di controllo principale.
Ad esempio, per ottenere un RTO molto basso, potresti mantenere un sistema hot standby nel sito di RE, con infrastruttura pre-deployment, sistemi SAP attivi e dati replicati. Tuttavia, un RTO basso ha un costo maggiore.
Puoi bilanciare costi e tempi di ripristino configurando in anticipo un'infrastruttura a basso costo o senza costi e rimandando alcuni passaggi di configurazione al momento del ripristino.
Ad esempio, puoi configurare ed eseguire il deployment di una VM in anticipo, per poi arrestarla. Le risorse collegate alla VM, ad esempio IP statici esterni o dischi permanenti, potrebbero comunque comportare addebiti, ma non la VM arrestata.
Poiché puoi configurare ed eseguire il deployment di una VM Compute Engine su Google Cloud in tempi piuttosto rapidi, potresti essere in grado di farlo al momento del ripristino e rispettare comunque il tuo RTO, soprattutto se utilizzi Terraform o Deployment Manager per eseguire il deployment del tuo sistema di RE o creare la VM da un modello e un'immagine personalizzata creata in anticipo.
Considerazioni su quote e risorse per soluzioni di ripristino di emergenza con RTO elevato
Se non esegui il pre-deployment dell'infrastruttura e dei sistemi, verifica periodicamente le quote delle risorse nell'area geografica del sito di RE per assicurarti che siano sufficienti per eseguire il deployment del sistema di ripristino di emergenza.
Eseguire in anticipo il deployment dell'infrastruttura e dei sistemi di RE consente di garantire che il sistema di RE rientri nelle quote e che le risorse Google Cloud necessarie per il sistema siano disponibili quando il sistema ne ha bisogno.
Architetture di esempio per diversi obiettivi
I seguenti diagrammi dell'architettura mostrano esempi di progetti di RE per RTO diversi.
Ciascuno dei diagrammi mostra le opzioni di backup per più regioni a sinistra e una configurazione SAP semplificata corrispondente nel sito di RE a destra.
Ogni esempio mostra una possibile combinazione di elementi di progettazione di RE. Per adattare la progettazione di RE ai tuoi obiettivi e alle circostanze, puoi combinare gli elementi di uno o tutti gli esempi.
Esempio di architettura di RE di emergenza con RTO ridotto
Il seguente diagramma dell'architettura mostra un esempio di progettazione di RE con basso RTO.
In questa progettazione, manterrai un sistema SAP quasi funzionante presso il sito di RE. Il deployment delle VM è stato eseguito e sono attive. I server delle applicazioni SAP e il server di database sono attivi, ma il servizio dell'applicazione è arrestato.
Le opzioni di backup che probabilmente utilizzerai in questo scenario includono immagini del sistema operativo archiviate in, snapshot di disco permanente archiviati in Compute Engine e replica dei dati tra i siti principali e di RE. Per la replica dei dati, puoi utilizzare la Replica asincrona DP.
Poiché viene utilizzata la replica dei dati, il rischio di perdita di dati è limitato all'ultima sincronizzazione del database.
Per estendere l'RPO indietro nel tempo, puoi aggiungere backup dei dati a Cloud Storage, operazione non mostrata nel diagramma. Per gli snapshot di dischi permanenti, puoi utilizzare gli snapshot pianificati e regolare il criterio di conservazione in base all'RPO.
Le azioni che devi intraprendere per ripristinare un sistema a basso RTO come questa 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.
Dei tre esempi di architetture mostrate, quello con RTO basso è quello più costoso.
Esempio di architettura di RE (RTO) medio
L'architettura di RE dell'esempio seguente 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, nonché la replica dei dati tra il sito principale e il sito di RE. Per la replica dei dati, puoi utilizzare la Replica asincrona DP.
Poiché viene utilizzata la replica dei dati, il rischio di perdita di 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 di disco permanente, puoi utilizzare gli snapshot pianificati e regolare il criterio di conservazione in base all'RPO.
A seconda dei requisiti del tuo sistema di database, potresti essere in grado di eseguire il deployment del database su una VM più piccola nel sito di RE rispetto a quello richiesto dal sito principale, il che può aiutare a ridurre i costi fino all'attivazione del sistema di RE. In questo caso, devi ridimensionare la VM alle dimensioni richieste durante il ripristino.
Le azioni che devi intraprendere per ripristinare un sistema come questo includono:
- Se necessario, eseguire il deployment delle istanze VM per SAP NetWeaver e dei server delle applicazioni da immagini o snapshot di disco permanente.
- Sincronizzazione dei file system da snapshot di disco permanente o altri tipi di archiviazione.
- Se necessario, ridimensiona l'istanza VM del database.
- Passaggio del database principale al sito di RE.
- Avvio del servizio dell'applicazione nel sito di RE.
Esempio di architettura di RE emergenza con RTO elevato
Il seguente diagramma dell'architettura ha l'RTO più alto tra gli esempi mostrati ed è l'opzione più economica.
In questa progettazione puoi eseguire il pre-deployment dei server e quindi arrestarli per evitare addebiti per le VM oppure, per evitare costi associati ai dischi permanenti e ad altre risorse relative alle VM, puoi eseguire il deployment delle VM come parte del processo di ripristino.
Le opzioni di backup che probabilmente utilizzerai in questo scenario includono immagini del sistema operativo archiviate, snapshot di disco permanente archiviati in Compute Engine e backup dei dati archiviati in Cloud Storage.
Per soddisfare l'RPO, puoi regolare sia la frequenza di backup sia i criteri di conservazione delle pianificazioni degli snapshot e dei backup nel bucket Cloud Storage.
Le azioni che devi intraprendere per ripristinare un sistema come questo includono:
- Se necessario, eseguire il deployment delle istanze VM per SAP NetWeaver, i server delle applicazioni e il server di database da snapshot o immagini del disco permanente in più regioni archiviati in Compute Engine.
- Sincronizzazione dei file system da snapshot di disco permanente o altri tipi di archiviazione.
- Ripristino del database dai file di backup in un bucket Cloud Storage su più regioni o altrove.
- Passaggio del database principale al sito di RE.
- Avvio del servizio dell'applicazione nel sito di RE.
Partner e prodotti per soluzioni di RE per SAP su Google Cloud
I partner che ti aiuteranno con la tua soluzione di RE sono disponibili nella directory dei partner Google Cloud.
Su Google Cloud Marketplace puoi anche trovare vari prodotti e partner per supportare la tua soluzione di RE.