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 cloud.
Definizione di 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 un disastro naturale o provocato dall'uomo o un guasto dell'infrastruttura che causa un'interruzione su larga scala. Queste interruzioni disattivano non solo il sistema di elaborazione delle applicazioni principale, ma anche qualsiasi sistema di riserva che protegge da guasti di piccole dimensioni del sistema o dell'infrastruttura locale.
Altre caratteristiche di una soluzione di RE che la distinguono da una soluzione di alta disponibilità includono:
- Il sistema di recupero in una soluzione di RE in genere non è un sistema hot-standby.
- Una procedura di ripristino di emergenza in genere richiede un intervento manuale per recuperare o ripristinare l'elaborazione delle applicazioni dai backup o dalla replica dei dati, dei sistemi e dell'infrastruttura.
- La soluzione include un sito di ripristino in una località geografica diversa da quella del sistema principale.
- Il Recovery Time Objective (RTO) per una soluzione di ripristino di emergenza viene in genere misurato in ore, se non in giorni.
L'esempio di architettura seguente mostra un sistema SAP che include sia una soluzione HA sia una soluzione RE. Il sito di ripristino di emergenza, in cui il sistema verrà ripristinato dopo un disastro, 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 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 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 di RE per i sistemi di database non sono coperte in questa guida. Fai riferimento alla documentazione del database e alle eventuali note SAP applicabili. Questa guida si concentra specificamente 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 della disponibilità elevata 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 RE per i sistemi SAP non in esecuzione su Google Cloud
Se il sistema SAP principale non è in esecuzione su Google Cloud, puoi adottare un approccio lift-and-shift per la 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 del design della soluzione di RE, ottimizzi il sistema recuperato per il cloud, supportato da prodotti o servizi Google Cloud o di partner Google Cloud.
Se utilizzi un approccio di tipo lift-and-shift, devi verificare 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 concesso in licenza correttamente per l'utilizzo 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 RE
- Networking
- Sicurezza
- Considerazioni sulle macchine virtuali (VM)
- Opzioni di backup
- Archiviazione
Per implementare ciascuno di questi elementi di progettazione, hai a disposizione una serie di opzioni per soddisfare i tuoi obiettivi di recupero e di costo.
Posizione del sito RE
Quando scegli una regione Google Cloud per il tuo sito di RE, devi considerare quanto segue:
- L'area di impatto potenziale di qualsiasi disastro che potrebbe verificarsi nel tuo sito principale
- La posizione 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 scegli
Scegli una regione Google Cloud per il sito di RE sufficientemente lontana dal sito principale in modo che non venga interessata da eventuali calamità che potrebbero verificarsi nel sito principale. In genere, viene considerata sufficiente una distanza di almeno 160 km, ma le normative o le linee guida organizzative potrebbero richiedere una distanza minima diversa.
Se il sistema SAP principale è in esecuzione su Google Cloud, posiziona il sito di RE in una regione Google Cloud vicina agli utenti, diversa da quella in cui è in esecuzione il sistema principale. Le regioni Google Cloud sono abbastanza distanti tra loro da essere improbabile che due regioni Google Cloud siano interessate dalla stessa calamità.
Se il sistema SAP principale è in esecuzione al di fuori di Google Cloud, posiziona il sito di RE in una regione il più vicino possibile agli utenti senza che si trovi nella zona di potenziale impatto di qualsiasi disastro che potrebbe verificarsi nel sito principale.
Nella regione di RE, posiziona il sistema di RE in una zona che supporti i tipi di istanze 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 di risorse per la regione in modo che fornisca risorse sufficienti per il sistema di RE prima di un evento.
Per le sedi di tutte le regioni Google Cloud, consulta Regioni e zone.
Per visualizzare le funzionalità disponibili in ogni regione, consulta Regioni e zone disponibili.
Per esaminare le risorse Google Cloud globali, regionali e zonali, consulta Risorse globali, regionali e zonali.
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 esiste già. Devi anche creare una subnet e un intervallo IP per il sito di RE.
Se il sistema principale è su Google Cloud, la configurazione della rete è più semplice se sia il sito principale che quello di RE si trovano nella stessa rete VPC. Tuttavia, se necessario, puoi posizionare i siti principali e di RE in reti VPC diverse o addirittura 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 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.
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 recupero siano immediatamente disponibili in caso di disastro e per testare le procedure di gestione dei disastri.
Se il sistema principale è in esecuzione su Google Cloud, rendere disponibili i backup sul 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 multiregionali per la disponibilità immediata nel sito di RE.
Se il sistema principale non è in esecuzione su Google Cloud, puoi collegare il sito principale al sito di RE su Google Cloud utilizzando Cloud Interconnect o Cloud VPN.
Per un esempio di una topologia Cloud Interconnect altamente disponibile che, con alcune modifiche, potrebbe essere adattata a uno scenario di RE, consulta Definire una disponibilità del 99,99% per Dedicated Interconnect.
Per alcuni esempi di topologie di gateway VPN multiregione ad alta disponibilità che possono essere adattate anche a uno scenario di RE, consulta Topologie Cloud VPN.
Un aspetto fondamentale da considerare 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 su Google Cloud.
Per ulteriori informazioni sulle opzioni di connessione a Google Cloud da siti esterni alla piattaforma, consulta i prodotti di connettività ibrida.
Connettività tra applicazioni, database e server SAP
Se il 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: basta modellare i nomi host, le sottoreti, le firewall e così via sul sito principale.
Se il sistema principale non è in esecuzione su Google Cloud, nella fase di progettazione potrebbe essere necessario un maggiore impegno per tradurre l'architettura di rete del sito principale nel sito di RE su Google Cloud.
È fondamentale testare le procedure di RE per identificare e risolvere eventuali problemi di connettività prima che la tua attività debba fare affidamento sul sistema recuperato.
Collegamento degli utenti al sito RE
In caso di recupero, dopo il ripristino del sistema SAP nel sito di RE, il traffico proveniente dagli utenti deve essere reindirizzato al sistema recuperato. In genere, lo fai aggiornando gli alias di rete nelle voci DNS con i nuovi indirizzi IP, che sono regionali.
Se la tua architettura di rete utilizza route VPC, dovrai aggiornarle durante il recupero.
Su Google Cloud, puoi utilizzare Cloud DNS o un'altra soluzione DNS.
Risorse di networking regionali
Se il sistema principale è in esecuzione su Google Cloud e utilizzi risorse di rete regionali come Cloud NAT o un Cloud Load Balancing regionale, devi avere un'istanza della risorsa in ogni regione.
Per ulteriori informazioni:
Controllo dell'accesso alla rete
Assicurati che le stesse porte siano aperte sul sito di RE come sul 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 recupero e mantenerlo sincronizzato con l'istanza Active Directory nel sito principale.
Sicurezza
Devi implementare gli stessi controlli e le stesse autorizzazioni di sicurezza che hai sul sito principale sul sito di RE. Anche per l'ambiente recuperato valgono gli stessi regolamenti di conformità.
Qualsiasi utente o ruolo che richiede l'accesso al sito principale richiede l'accesso anche al sito di RE.
Per informazioni generali sulla progettazione della sicurezza per una soluzione di RE su Google Cloud, consulta Implementazione di controlli di sicurezza e conformità.
Considerazioni sulle VM
Puoi velocizzare il deployment delle istanze di macchine virtuali (VM) Compute Engine e 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 istanze 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 consente di eseguire il deployment più rapidamente, riduce gli errori di configurazione e garantisce che i sistemi SAP soddisfino i requisiti di assistenza SAP.
Un'altra opzione per configurare le VM in anticipo sono i modelli di istanze Compute Engine. L'utilizzo dei modelli di istanza è un modo per accelerare l'implementazione e ridurre la configurazione manuale delle VM durante il recupero. Tuttavia, poiché richiedono una certa riconfigurazione per il 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, consulta Modelli di istanza.
Puoi anche utilizzare strumenti di orchestrazione del deployment, come Terraform, per gestire i deployment dell'infrastruttura su Google Cloud.
A seconda del tuo RTO, puoi eseguire il pre-deployment delle istanze Compute Engine o, poiché il deployment di una VM richiede solo pochi minuti, puoi eseguire il deployment al momento del recupero.
Se esegui il pre-deployment delle VM, puoi interromperle per risparmiare sui costi o usarle per altri scopi non essenziali finché non sono necessarie per il recupero.
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 di RE potresti posizionare i server delle applicazioni sullo stesso host dei servizi centrali SAP. Tuttavia, devi valutare il risparmio sui costi rispetto alla maggiore complessità dell'avere 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 utilizzarla per creare l'istanza di recupero nel 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 sistema principale. Se utilizzi un'immagine pubblica di Google Cloud non modificata, puoi utilizzarla anche sul sito di recupero. Per ulteriori 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 del disco di avvio in Google Cloud dal tuo ambiente on-premise o 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 opzioni di backup tra cui 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 durante il recupero, puoi archiviarlo su Google Cloud come immagine personalizzata Compute Engine. Per ulteriori informazioni, consulta la sezione Disco di avvio per il recupero.
Snapshot disco permanente di Compute Engine
Per eseguire il backup di SAP o di altri file system su un disco permanente Compute Engine, puoi utilizzare gli snapshot dei dischi permanenti.
Puoi anche definire una pianificazione di snapshot per acquisire automaticamente snapshot a intervalli regolari. Consulta Creazione di snapshot pianificati per i dischi permanenti.
Gli snapshot forniscono coerenza solo a livello di blocco. Per garantire la coerenza a livello di file, potrebbe essere necessario 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 del punto di ripristino, puoi riprodurre 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 aziendali critiche che hanno una tolleranza molto bassa alla perdita di dati.
Se il sistema principale è in esecuzione su Google Cloud, i bucket con più regioni e gli snapshot con più regioni vengono replicati tra le regioni selezionate.
Per la replica di archiviazione a livello di blocco, puoi utilizzare la replica asincrona del disco permanente. La replica asincrona del disco permanente (DP asincrono) 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.
Archiviazione
Quando progetti una soluzione di RE su Google Cloud, è probabile che utilizzi 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 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 predefinita e una posizione.
Seleziona una classe di archiviazione predefinita in base all'accordo sul livello del servizio (SLA) richiesto, all'utilizzo previsto dell'archiviazione e ai vincoli di costo. Per il DR, la classe di archiviazione Coldline è 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 è su Google Cloud, scegli una località multiregione che includa le regioni sia del sito principale sia del sito 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à in una singola regione nella regione che include il tuo sito di RE.
Se il tuo sistema principale è su Google Cloud e utilizzi una soluzione di terze parti per lo spazio di archiviazione condiviso, le opzioni di archiviazione potrebbero essere determinate dalla soluzione. Fai riferimento alla documentazione della soluzione o al tuo rappresentante del team assistenza clienti Google Cloud.
Per informazioni sui prezzi, consulta Prezzi di Cloud Storage.
Spazio di archiviazione per gli snapshot disco permanente di Compute Engine
Quando crei uno snapshot, puoi specificare una località di archiviazione. La posizione di uno snapshot influisce sulla sua disponibilità e può comportare costi di networking quando lo crei o lo ripristini su un nuovo disco.
Gli snapshot possono essere archiviati in una località Cloud Storage con più regioni, ad esempio asia, o in una località Cloud Storage a livello di regione, ad esempio asia-south1.
Una località di archiviazione multiregionale offre una maggiore disponibilità 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 dati.
Indipendentemente dalle opzioni di località che scegli, gli snapshot devono essere archiviati in una posizione accessibile dal sito di RE.
Per ulteriori informazioni sulle posizioni degli snapshot, consulta Selezionare la posizione di archiviazione per uno snapshot.
Per informazioni sui prezzi dello spazio di archiviazione per gli snapshot, consulta Prezzi dei dischi permanenti.
Spazio di archiviazione per le immagini personalizzate
Dopo aver aggiunto i file di immagini personalizzate all'elenco delle immagini personalizzate, Compute Engine gestisce lo spazio di archiviazione per le immagini. Le immagini in un elenco di immagini personalizzate sono risorse globali, quindi sono disponibili in qualsiasi regione.
Per informazioni sui prezzi dell'archiviazione delle immagini, consulta Archiviazione delle immagini.
Test del piano di RE
Una volta completato il piano di RE, testalo regolarmente, annota eventuali problemi che si verificano e modifica il piano di conseguenza.
Assicurati di testare tutti gli aspetti del tuo piano di RE, ad esempio:
- 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 continueranno 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 in modo che soddisfi gli RPO e gli RTO
Alcuni prodotti, funzioni e servizi Google Cloud sono fondamentali per progettare una soluzione di RE che soddisfi i tuoi RPO e RTO.
Progettazione in base al RPO
Quando progetti una soluzione di RE su Google Cloud per soddisfare un determinato RPO, esistono due variabili che controllano il punto in cui puoi eseguire il recupero:
- Frequenza del backup
- Conservazione backup
Frequenza del backup
La frequenza dei backup determina il periodo di tempo massimo che può trascorrere tra il tuo 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 un disastro avviene 23 ore e 59 minuti dopo l'ultimo backup.
La replica può ridurre il tempo massimo trascorso dall'ultimo backup a quasi zero. Tuttavia, la replica è costosa, quindi potresti utilizzarla solo per i database e i file delle applicazioni aziendali critici.
In una soluzione di RE, le copie o gli snapshot istantanei vengono spesso utilizzati per eseguire il backup dei file system delle applicazioni SAP necessari per il recupero.
Su Google Cloud, puoi automatizzare gli snapshot dei dischi permanenti Compute Engine creando una pianificazione degli snapshot ogni ora, ogni giorno o ogni settimana. 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 quando si sceglie una frequenza di backup è il costo del trasferimento dei dati. Anche il costo di archiviazione è un fattore da considerare, ma le norme di conservazione dei backup potrebbero avere un impatto maggiore sui costi di archiviazione rispetto alla frequenza dei backup.
Per ulteriori informazioni sulle pianificazioni degli snapshot, consulta Creare snapshot pianificati per i dischi permanenti.
Conservazione backup
La conservazione dei backup determina quanto indietro nel tempo puoi spostare il punto di ripristino. Conservare le copie di backup aiuta a proteggerti dagli errori logici consentendoti di ripristinare un punto nel tempo precedente all'esistenza dell'errore logico.
Puoi impostare criteri di conservazione per gli snapshot di Compute Engine e per i bucket Cloud Storage che eliminano automaticamente i file di backup dopo un determinato periodo di tempo.
Il costo principale da considerare quando si sceglie 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 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 nei bucket Cloud Storage, consulta Criteri di conservazione che utilizzano il blocco dei bucket.
Progettazione in base al RTO
Quando progetti la tua soluzione di DR di Google Cloud per soddisfare un determinato RTO, la disponibilità dell'infrastruttura, del software, dei file system e dei dati sul sito di RE è la variabile di controllo principale.
Ad esempio, per ottenere un RTO molto basso, puoi gestire un sistema hot standby nel sito di RE, con un'infrastruttura pre-implementata, sistemi SAP attivi e dati replicati. Tuttavia, il basso RTO ha un costo più elevato.
Puoi bilanciare i costi e i tempi di recupero configurando in anticipo un'infrastruttura a basso o nessun costo e rimandando alcuni passaggi di configurazione al momento del recupero.
Ad esempio, puoi configurare ed eseguire il deployment di una VM in anticipo, ma poi fermarla. Le risorse collegate alla VM, ad esempio eventuali IP statici esterni o dischi permanenti, potrebbero comunque comportare addebiti, ma non la VM stessa arrestata.
Poiché puoi configurare ed eseguire il deployment di una VM Compute Engine su Google Cloud in modo relativamente rapido, potresti riuscire a farlo al momento del recupero e comunque soddisfare il tuo RTO, soprattutto se utilizzi Terraform o Deployment Manager per eseguire il deployment del sistema di RE o creare la VM da un modello e un'immagine personalizzata che hai creato in anticipo.
Considerazioni su quote e risorse per soluzioni di RP con RTO elevato
Se non esegui il pre-deployment dell'infrastruttura e dei sistemi, controlla periodicamente le quote di risorse nella regione del sito di RE per assicurarti che siano sufficienti per il deployment del sistema di RE.
Il pre-deployment della maggior parte dell'infrastruttura e dei sistemi di RE in base al budget consente di garantire che il sistema di RE rientri nelle quote e che le risorse Google Cloud di cui il sistema ha bisogno siano disponibili quando servono.
Architetture di esempio per obiettivi diversi
I seguenti diagrammi di architettura mostrano esempi di design di RE per diversi RTO.
Ciascuno dei diagrammi mostra le opzioni di backup multiregione a sinistra e una configurazione SAP semplificata corrispondente nel sito di RE a destra.
Ogni esempio mostra una possibile combinazione di elementi di design RE. Per adattare il design del RE ai tuoi obiettivi e alle tue circostanze, puoi combinare elementi di uno o più esempi.
Esempio di architettura di RE con RTO ridotto
Il seguente diagramma di architettura mostra un esempio di progettazione di DR con RTO ridotto.
In questo progetto, gestisci un sistema SAP quasi funzionale nel sito di RE. Le VM sono dipiattate e attive. I server delle applicazioni SAP e il server di database sono attivi, ma il servizio delle applicazioni è fermo.
Le opzioni di backup che probabilmente utilizzerai in questo scenario includono le immagini del sistema operativo memorizzate e gli snapshot disco permanente archiviati in Compute Engine, nonché la replica dei dati tra i siti principali e di RE. Per la replica dei dati, puoi utilizzare la replica asincrona di Play Console.
Poiché viene utilizzata la replica dei dati, il rischio di perdita di dati è limitato all'ultima sincronizzazione del database.
Per estendere il RPO nel tempo, puoi aggiungere i backup dei dati a Cloud Storage, che non è mostrato nel diagramma. Per le istantanee del disco permanenti, puoi utilizzare quelle pianificate e modificare il criterio di conservazione in base al tuo RPO.
Le azioni da intraprendere per recuperare un sistema con un RTO basso come questo includono:
- Se necessario, esegui una sincronizzazione finale dei file o recuperali da uno snapshot del disco permanente.
- Spostare il database principale sul sito di RE.
- Avvio dell'applicazione nel sito di RE.
Tra le tre architetture di esempio mostrate, quella con RTO basso è la più costosa.
Esempio di architettura di RE con RTO medio
L'esempio di architettura di RE seguente ha un RTO più elevato rispetto all'esempio precedente, ma un costo inferiore.
In questo progetto, 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 le immagini del sistema operativo e gli snapshot disco permanente archiviati in Compute Engine, nonché la replica dei dati tra i siti principali e di RE. Per la replica dei dati, puoi utilizzare la replica asincrona di Play Console.
Poiché viene utilizzata la replica dei dati, il rischio di perdita di dati è limitato all'ultima sincronizzazione del database.
Per estendere l'RPO a ritroso nel tempo, puoi archiviare i backup dei dati in un bucket Cloud Storage, che non è mostrato nel diagramma. Per gli snapshot 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 quanto richiesto 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 alle dimensioni richieste durante il recupero.
Le azioni che devi intraprendere per recuperare un sistema come questo includono:
- Se necessario, esegui il deployment delle istanze VM per SAP NetWeaver e i server di applicazioni da snapshot o immagini dei disco permanente.
- Sincronizzazione dei file system dagli snapshot disco permanente o da altri spazi di archiviazione.
- Se necessario, ridimensiona l'istanza VM del database.
- Spostare il database principale sul sito di RE.
- Avvio del servizio dell'applicazione nel sito di RE.
Esempio di architettura di RE con RTO elevato
Il seguente diagramma di architettura ha il RTO più elevato tra gli esempi riportati ed è l'opzione più economica.
In questo design, puoi pre-implementare i server e poi fermarli per evitare di pagare gli addebiti per le VM oppure, per evitare i costi associati ai dischi permanenti e ad altre risorse correlate alle VM, puoi implementare le VM nell'ambito della procedura di recupero.
Le opzioni di backup che probabilmente utilizzerai in questo scenario includono le immagini del sistema operativo e gli snapshot disco permanente archiviati in Compute Engine, nonché i backup dei dati archiviati in Cloud Storage.
Per soddisfare il tuo RPO, puoi modificare sia la frequenza dei backup sia i criteri di conservazione delle pianificazioni degli snapshot e dei backup nel bucket Cloud Storage.
Le azioni che devi intraprendere per recuperare un sistema come questo includono:
- Se necessario, esegui il deployment delle istanze VM per SAP NetWeaver, i server di applicazioni e il server di database da snapshot o immagini di disco permanente multi-regionali archiviati in Compute Engine.
- Sincronizzazione dei file system dagli snapshot disco permanente o da altro archiviazione.
- Recupero del database dai file di backup in un bucket Cloud Storage in più regioni o altrove.
- Spostare il database principale sul sito di RE.
- Avvio del servizio dell'applicazione nel sito di RE.
Partner e prodotti per le soluzioni di RE per SAP su Google Cloud
Puoi trovare partner che ti aiutino con la tua soluzione di RE nella Directory dei partner Google Cloud.
Puoi anche trovare vari prodotti e partner per supportare la tua soluzione di RE su Google Cloud Marketplace.