Guida alla pianificazione del ripristino di emergenza per SAP NetWeaver su Google Cloud

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 dei disastri e l'alta disponibilità sono due elementi distinti nel concetto più ampio della continuatività aziendale. Questa guida è incentrata sul ripristino di emergenza.

Una soluzione DR è progettata per ripristinare l'elaborazione delle applicazioni dopo un disastro naturale o artificiale o un guasto dell'infrastruttura che causa un'interruzione su larga scala. Tali interruzioni disattivano non solo il sistema di elaborazione principale delle applicazioni, ma qualsiasi sistema di standby che protegge da errori di piccola scala o di infrastruttura locale.

Altre caratteristiche di una soluzione DR che la distinguono da una soluzione ad alta disponibilità sono:

  • Il sistema di ripristino in una soluzione DR di solito non è un sistema standby attivo.
  • Una procedura di ripristino di emergenza richiede in genere un intervento manuale per recuperare o ripristinare l'elaborazione delle applicazioni da backup o replica di dati, sistemi e infrastruttura.
  • La soluzione include un sito di ripristino che si trova in una posizione geografica diversa rispetto al sistema principale.
  • In genere, l'obiettivo di tempo di ripristino (RTO) per una soluzione di ripristino di emergenza viene misurato in ore, se non in giorni.

L'architettura di esempio riportata di seguito mostra un sistema SAP che include sia una soluzione ad alta disponibilità sia una soluzione DR. Il sito DR, in cui il sistema verrà ripristinato in seguito a una catastrofe, si trova sulla destra dell'area geografica 2. Il sistema principale si trova a sinistra nella sezione Area geografica 1 ed è configurato per l'alta disponibilità con cluster di failover che coprono due zone. La funzione di backup della soluzione DR è rappresentata da linee tratteggiate che attraversano entrambe le aree geografiche. Per l'archiviazione, i sistemi utilizzano un bucket Cloud Storage in più aree geografiche, riportato nella parte inferiore del diagramma.

L'esempio mostra anche un database. Il recupero delle applicazioni dipende dal recupero dei dati, ma le procedure DR per i sistemi di database non vengono trattate in questa guida. Fai riferimento alla documentazione del database e a tutte le note SAP applicabili. Questa guida si concentra specificamente sul sistema SAP NetWeaver (SAP ASCS/ERS) e sui server delle applicazioni (SAP PAS e AAS).

Panoramica di un sistema ad alta disponibilità e a risposta diretta con sistema DB: alta disponibilità in due zone a sinistra.
sito DR in un'altra area geografica sulla destra.

Per informazioni sull'implementazione dei 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 il ripristino di emergenza per SAP HANA su Google Cloud, consulta rispettivamente le guide alla pianificazione dell'alta disponibilità di SAP HANA e la guida alla pianificazione per il ripristino di emergenza di SAP HANA.

Per informazioni generali sulla RE su Google Cloud, consulta la Guida alla pianificazione del ripristino di emergenza.

Approcci di progettazione DR 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 alla soluzione DR, in cui l'architettura e il software del sistema DR su Google Cloud sono gli stessi del sistema principale. Oppure, puoi adottare un approccio cloud-native in cui, nell'ambito della progettazione della tua soluzione DR, ottimizzi il sistema recuperato per il cloud, supportato da prodotti o servizi Google Cloud o partner 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 in uso sia autorizzato per l'utilizzo su Google Cloud.

Per ulteriori informazioni sulle licenze, consulta i Termini di servizio di Google Cloud Platform.

Progettare elementi di una soluzione DR per SAP NetWeaver su Google Cloud

Gli elementi di progettazione di una soluzione DR per SAP NetWeaver su Google Cloud possono includere i seguenti:

  • Località sito DR
  • Networking
  • Sicurezza
  • Considerazioni sulle macchine virtuali (VM)
  • Opzioni di backup
  • Archiviazione

Per implementare ciascuno di questi elementi di progettazione, sono disponibili diverse opzioni per soddisfare gli obiettivi di recupero e costo.

Località sito DR

Quando scegli un'area geografica Google Cloud per il tuo sito DR, devi considerare:

  • La potenziale area d'impatto di qualsiasi catastrofe che potrebbe verificarsi sul tuo sito principale
  • La località degli utenti del sistema SAP NetWeaver
  • Se le risorse e le funzionalità di Google Cloud utilizzate dal tuo sistema SAP sono disponibili nell'area geografica e nella zona che hai scelto

Scegli un'area geografica di Google Cloud per il tuo sito DR abbastanza lontana dal sito principale in modo che il sito DR non sia interessato da eventuali catastrofi che potrebbero verificarsi nel sito principale. Generalmente, una distanza di almeno 160 km è considerata sufficiente, ma le normative o le linee guida organizzative possono richiedere una distanza minima diversa.

Se il sistema SAP principale è in esecuzione su Google Cloud, posiziona il sito DR in una qualsiasi area geografica Google Cloud vicina agli utenti, diversa dall'area geografica in cui è in esecuzione il sistema principale. Le aree geografiche di Google Cloud sono sufficientemente distanti l'una dall'altra in modo da impedire la presenza di due aree geografiche di Google Cloud.

Se il sistema SAP principale è in esecuzione all'esterno di Google Cloud, posiziona il sito DR in un'area geografica il più vicina possibile agli utenti senza trovarsi nella potenziale zona dell'impatto di qualsiasi catastrofe che potrebbe verificarsi sul sito principale.

Nella tua area geografica DR, posiziona il tuo sistema DR in una zona che supporta i tipi di istanze VM e altre infrastrutture richieste dai sistemi SAP e di database.

Dopo aver selezionato un'area geografica per il sito DR, potrebbe essere necessario aumentare le quote di risorse per l'area geografica in modo da fornire risorse sufficienti per il sistema DR prima di un evento.

Per le località di tutte le aree geografiche di Google Cloud, consulta la sezione Aree geografiche e zone.

Per informazioni sulle funzionalità disponibili in ogni area geografica, consulta Aree geografiche e zone disponibili.

Per esaminare le risorse Google Cloud a livello globale, di area geografica e di zona, consulta Risorse globali, a livello di area geografica e di zona.

Networking

Su Google Cloud, il Virtual Private Cloud (VPC) fornisce funzionalità di rete che possono essere estese in tutto il mondo.

Devi creare una rete VPC per il tuo sito DR, se non ne esiste già una. Devi anche creare una subnet e un intervallo IP per il sito DR.

Se il tuo sistema principale si trova su Google Cloud, configurare la tua rete è più semplice se sia il sito principale che il sito DR si trovano nella stessa rete VPC. Tuttavia, se necessario, puoi invece posizionare il sito principale e il sito RE in diverse reti VPC o in progetti diversi.

Quando progetti la soluzione DR, 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 applicazioni, database e server che costituiscono il tuo sistema SAP.
  • La connessione tra gli utenti e il sistema SAP

Per le connessioni da siti esterni a Google Cloud, Google Cloud fornisce una varietà di prodotti di rete per supportare ciascuno di questi punti di connessione.

Collegamento del sito principale al sito DR

La connessione tra il sito principale e il sito DR è 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, rendere disponibili i backup sul sito DR è quasi automatico. Gli snapshot di Compute Engine possono essere designati come multiregionali. Altri backup possono essere archiviati direttamente dal sistema principale nei bucket Cloud Storage in più aree geografiche per ottenere una disponibilità immediata sul sito DR.

Se il sistema principale non è in esecuzione su Google Cloud, puoi connettere il sito principale al tuo sito DR su Google Cloud utilizzando Cloud Interconnect o Cloud VPN.

Per un esempio di topologia di Cloud Interconnect ad alta disponibilità che, con alcune modifiche, potrebbe essere adattata a uno scenario DR, consulta Stabilire una disponibilità del 99,99% per Dedicated Interconnect.

Per alcuni esempi di topologie gateway a più aree geografiche con disponibilità elevata, che possono essere adattate a uno scenario DR, consulta le 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 adeguatamente il regolare trasferimento di dati e backup a Google Cloud.

Per ulteriori informazioni sulle opzioni per connetterti a Google Cloud da siti al di fuori della piattaforma, consulta i prodotti per la connettività ibrida.

Connettività tra applicazioni, database e server SAP

Se il sistema principale è in esecuzione su Google Cloud, mantenere la connettività tra applicazioni SAP, database e server sul sito DR è una pratica 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, potrebbero essere necessari ulteriori sforzi nella fase di progettazione per tradurre l'architettura di networking del sito principale nel sito di RE su Google Cloud.

Testare le procedure DR è fondamentale per identificare e risolvere eventuali problemi di connettività prima che l'azienda debba dipendere dal sistema recuperato.

Collegamento degli utenti al sito di RE

In un ripristino, dopo che il sistema SAP è stato ripristinato al sito DR, il traffico degli utenti deve essere reindirizzato al sistema recuperato. In genere, puoi farlo aggiornando gli alias di rete nelle voci DNS ai nuovi indirizzi IP, che sono a livello di area geografica.

Se l'architettura di networking utilizza le route VPC, devi aggiornarle durante il ripristino.

Su Google Cloud, puoi utilizzare Cloud DNS o un'altra soluzione DNS.

Risorse di networking a livello di area geografica

Se il sistema principale è in esecuzione su Google Cloud e utilizzi risorse di networking a livello di area geografica come Cloud NAT o Cloud Load Balancing a livello di area geografica, hai bisogno di un'istanza della risorsa in ogni area geografica.

Per ulteriori informazioni:

Controllo dell'accesso alla rete

Assicurati che nel sito 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 tue VM.

Se hai un servizio Active Directory su Windows Server, devi configurarlo prima del ripristino e mantenerlo sincronizzato con l'istanza Active Directory nel sito principale.

Sicurezza

Devi implementare gli stessi controlli di sicurezza e le stesse autorizzazioni presenti nel sito principale del tuo sito DR. Lo stesso vale anche per l'ambiente recuperato.

Qualsiasi utente o ruolo che richiede l'accesso al sito principale richiede l'accesso anche sul sito DR.

Per informazioni generali sulla progettazione di una soluzione DR su Google Cloud, consulta l'articolo sull'implementazione dei controlli di sicurezza e conformità.

Considerazioni sulle VM

Puoi accelerare il deployment delle istanze di Macchina virtuale (VM) di Compute Engine ed evitare errori di configurazione sul tuo sito DR utilizzando prodotti e funzionalità di Google Cloud come Cloud Deployment Manager, modelli di istanze e immagini personalizzate.

Configurazione e deployment delle macchine virtuali

Google Cloud fornisce modelli Deployment Manager per SAP su GCP, che puoi utilizzare per predefinire e sottoporre a deployment il tuo sistema SAP sul sito della RE. L'uso dei modelli Deployment Manager velocizza il deployment, riduce gli errori di configurazione e garantisce che i sistemi SAP soddisfino i requisiti del supporto SAP.

Un'altra opzione per configurare in anticipo le VM sono i modelli di istanza di Compute Engine. L'uso dei modelli di istanza è un modo per velocizzare il deployment e ridurre la configurazione manuale delle VM durante il ripristino. Tuttavia, poiché richiedono una nuova configurazione per il sito DR, il ripristino delle VM da un disco di avvio di ripristino, come descritto nella sezione successiva, potrebbe essere più semplice.

Per scoprire di più sui modelli di istanza, consulta la sezione 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 di Compute Engine oppure, poiché il deployment di una VM richiede solo pochi minuti, puoi eseguire il deployment al momento del ripristino.

Se esegui il pre-deployment delle VM, puoi arrestarle per risparmiare sui costi o utilizzarle per altri scopi non essenziali finché non sono necessarie per il recupero.

Puoi anche ridurre al minimo il costo consolidando un sistema distribuito su un numero inferiore di VM nel sito di ripristino. Ad esempio, se i server delle applicazioni sul sito principale si trovano su host dedicati sul sito principale, nel sito DR, potresti inserire i server delle applicazioni sullo stesso host di SAP Central Services. Tuttavia, devi valutare i risparmi sui costi rispetto alla maggiore complessità di 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, quindi utilizzare l'immagine personalizzata per creare l'istanza di ripristino sul sito DR.

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 utilizzare l'immagine pubblica di Google Cloud anche sul sito di recupero. Per ulteriori informazioni, consulta Creazione, eliminazione e ritiro delle immagini personalizzate.

Se il sistema non è in esecuzione su Google Cloud, puoi importare un'immagine del disco di avvio in Google Cloud dall'ambiente on-prem o importare i dischi virtuali dalle VM in esecuzione sulla workstation locale o su un'altra piattaforma cloud.

Opzioni di backup

Google Cloud offre diverse opzioni di backup tra cui scegliere quando progetti una soluzione DR:

  • Immagini personalizzate di Compute Engine
  • Snapshot del 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 maggiori informazioni, consulta il disco di avvio di ripristino.

Snapshot del disco permanente di Compute Engine

Per eseguire il backup di SAP o di altri file system su un disco permanente di Compute Engine, puoi utilizzare i dischi permanenti.

Puoi anche definire una pianificazione di snapshot per acquisire automaticamente snapshot a intervalli regolari. Consulta Creazione di snapshot pianificati per un disco permanente.

Gli snapshot forniscono solo coerenza a livello di blocco. Per garantire la coerenza del file system, 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 per il punto di ripristino, puoi replicare il file system. La replica può essere utilizzata per database, archiviazione a livello di blocco o file.

La progettazione di una soluzione DR che utilizza la replica è la soluzione migliore per le applicazioni aziendali critiche con una tolleranza molto bassa alla perdita di dati.

Se il tuo sistema principale è in esecuzione su Google Cloud, i bucket a più aree geografiche e gli snapshot a più aree geografiche vengono replicati tra le aree geografiche selezionate.

Puoi anche utilizzare la replica fornita da soluzioni di archiviazione di terze parti.

Archiviazione

Quando progetti una soluzione DR su Google Cloud, è probabile che utilizzerai più tipi di archiviazione, a seconda di dove è in esecuzione il sistema principale e di ciò che stai archiviando.

Bucket Cloud Storage per i file di backup

Per i backup diversi da snapshot dei dischi, ad esempio i file che carichi da un sistema SAP non in esecuzione su Google Cloud, crea un bucket in Cloud Storage, a cui puoi accedere sia dal sito principale che dai siti DR. Quando crei un bucket, scegli una classe di archiviazione predefinita e una località.

Seleziona una classe di archiviazione predefinita sulla base dell'accordo sul livello del servizio (SLA) richiesto, l'utilizzo previsto dello spazio di archiviazione e i vincoli di costo. Per RE, la classe di coldline storage è spesso una buona opzione.

Per la località del bucket, scegli una località che includa l'area geografica del tuo sito RE e, se il sistema principale è in esecuzione su Google Cloud, l'area geografica del tuo sito principale.

Se il sistema principale è su Google Cloud, scegli una località con più aree geografiche che includa le aree geografiche sia del sito principale sia del sito 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à a singola area geografica che includa il tuo sito DR.

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, consulta la sezione Prezzi di Cloud Storage.

Archiviazione per snapshot di dischi permanenti 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 rete quando lo crei o lo ripristini su un nuovo disco.

Gli snapshot possono essere archiviati in una località a più aree geografiche di Cloud Storage, ad esempio asia, o in una località a livello di area geografica di Cloud Storage, ad esempio asia-south1.

Una località di archiviazione su più aree geografiche offre una disponibilità maggiore e potrebbe ridurre i costi di rete quando si crea o si ripristina uno snapshot. Una località di archiviazione a livello di area geografica ti offre un maggiore controllo sulla posizione fisica dei tuoi dati.

Indipendentemente dalle opzioni scelte per la località, le istantanee devono essere archiviate in una posizione accessibile dal tuo sito DR.

Per ulteriori informazioni sulla posizione degli snapshot, vedi Selezione della località di archiviazione di uno snapshot.

Per le informazioni sui prezzi per l'archiviazione degli snapshot, consulta la sezione relativa ai prezzi dei dischi permanenti.

Spazio di archiviazione per immagini personalizzate

Dopo aver aggiunto i file immagine personalizzati all'elenco di immagini personalizzate, Compute Engine gestisce lo spazio di archiviazione delle immagini. Le immagini in un elenco di immagini personalizzate sono risorse globali, pertanto sono disponibili in qualsiasi area geografica.

Per informazioni sui prezzi di archiviazione delle immagini, vedi Archiviazione delle immagini.

Test del piano DR in corso...

Una volta completato il piano DR, testalo regolarmente, annotando eventuali problemi emersi e modificandolo di conseguenza.

Assicurati di testare tutti gli aspetti del tuo piano RE, tra cui:

  • Backup e pianificazioni di 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 tuoi sistemi DR, quelli principali continueranno a funzionare. Per evitare conflitti o suddividere gli scenari cerebrali, devi isolare il sistema di test dal sistema principale e dai suoi utenti.

Per informazioni generali sui test DR su Google Cloud, consulta la guida alla pianificazione del ripristino di emergenza.

Progettazione della tua soluzione RE in modo che soddisfi le tue esigenze in materia

Alcuni prodotti, funzioni e servizi Google Cloud sono fondamentali per progettare una soluzione DR che soddisfi i tuoi requisiti RPO e RTO.

Progettazione per RPO

Quando progetti una soluzione DR su Google Cloud per soddisfare un determinato RPO, sono disponibili due variabili che controllano il momento del ripristino.

  • 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 una catastrofe. Se crei i tuoi backup DR ogni 24 ore, potresti perdere quasi 24 ore di aggiornamenti dei dati se si verificano avvertimenti 23 ore e 59 minuti dopo l'ultimo backup.

La replica può ridurre il tempo massimo trascorso dall'ultimo backup quasi a zero, ma la replica è costosa, quindi potresti utilizzarla solo per database e file di applicazioni business critical.

In una soluzione DR, le copie point-in-time o gli snapshot vengono comunemente utilizzati per eseguire il backup dei file system delle applicazioni SAP necessari per il recupero.

Su Google Cloud puoi automatizzare gli snapshot di dischi permanenti di Compute Engine creando una pianificazione oraria, giornaliera o settimanale. 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 di dati. Anche il costo di archiviazione è un fattore da prendere in considerazione, ma il criterio di conservazione del backup potrebbe avere un impatto maggiore sui costi di archiviazione rispetto alla frequenza di backup.

Per ulteriori informazioni sulle pianificazioni degli snapshot, consulta la sezione Creazione di snapshot pianificati per dischi permanenti.

Conservazione backup

La conservazione dei backup determina per quanti giorni indietro nel tempo puoi spostare il punto di ripristino. Conservare le copie di backup contribuisce a proteggerti da errori logici, consentendoti di eseguire il ripristino in un momento specifico prima che si verifichi l'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 quando si sceglie un criterio di conservazione è il costo di archiviazione. Gli snapshot di Compute Engine riducono la quantità di spazio di archiviazione richiesta per più snapshot archiviando solo le modifiche incrementali a livello di blocco dopo l'archiviazione della prima istantanea completa.

Per ulteriori informazioni sulla definizione dei criteri di conservazione per gli snapshot, consulta il criterio di conservazione Snapshot.

Per informazioni sulla configurazione dei criteri di conservazione nei bucket Cloud Storage, consulta i criteri di conservazione che utilizzano il blocco dei bucket.

Progettazione per RTO

Quando progetti la tua soluzione DR Google Cloud per soddisfare un determinato RTO, la disponibilità dell'infrastruttura, del software, dei file system e dei dati sul sito DR è la variabile di controllo principale.

Ad esempio, per ottenere un RTO molto basso, puoi mantenere un sistema hot standby nel sito di RE, con un'infrastruttura pre-deployment, sistemi SAP attivi e dati replicati. Tuttavia, il RTO basso ha un costo maggiore.

Puoi bilanciare costi e tempi di recupero configurando in anticipo un'infrastruttura a basso costo o senza costi e rimandando alcuni passaggi di configurazione al tempo di ripristino.

Ad esempio, puoi configurare ed eseguire il deployment di una VM in anticipo, ma poi interromperla. Le risorse collegate alla VM, come eventuali IP statici esterni o dischi permanenti, potrebbero comunque incorrere in addebiti, ma la VM arrestata non lo fa.

Poiché puoi configurare ed eseguire il deployment di una VM di Compute Engine su Google Cloud in tempi relativamente brevi, potresti riuscire a eseguirla al momento del ripristino e comunque rispettare il tuo RTO, specialmente se utilizzi Deployment Manager per eseguire il deployment del tuo sistema DR o creare la VM da un modello e da un'immagine personalizzata creata in anticipo.

Considerazioni sulle quote e sulle risorse per soluzioni RTO DR elevate

Se non esegui il pre-provisioning dell'infrastruttura e dei sistemi, controlla periodicamente le tue quote delle risorse nell'area geografica del sito DR per assicurarti che siano sufficienti per il deployment del sistema DR.

Eseguire il pre-deployment di tutta l'infrastruttura e dei sistemi DR consentiti dal tuo budget può aiutarti a garantire che il tuo sistema DR rientri nelle tue quote e che le risorse GCP di cui il tuo sistema abbia bisogno sia disponibile quando ne ha bisogno.

Architetture di esempio per obiettivi diversi

I seguenti diagrammi dell'architettura mostrano esempi di progettazione DR per diversi RTO.

Ciascuno diagramma mostra le opzioni di backup per più aree geografiche a sinistra, mentre una configurazione SAP semplificata corrispondente corrisponde al sito DR a destra.

Ogni esempio mostra una possibile combinazione di elementi di progettazione DR. Per adattare la progettazione della risposta diretta ai tuoi obiettivi e alle tue circostanze, puoi combinare gli elementi di uno o tutti gli esempi.

Architettura DR di esempio a basso RTO

Il seguente diagramma dell'architettura mostra un esempio di progettazione DR a basso RTO.

In questa progettazione, mantieni un sistema SAP quasi funzionante presso la sede DR. Il deployment delle VM è attivo e risulta attivo. I server delle applicazioni SAP e i server dei database sono attivi, ma il servizio dell'applicazione è arrestato.

Le opzioni di backup che potresti utilizzare in questo scenario includono immagini di sistema operativo archiviate in snapshot di dischi permanenti e Compute Engine e replica dei dati tra il sito principale e il sito DR.

Dal momento che viene utilizzata la replica dei dati, il rischio di perderla è limitato all'ultima sincronizzazione del database.

Per estendere l'RPO nel tempo, puoi aggiungere backup dei dati a Cloud Storage, che non viene mostrato nel diagramma. Per gli snapshot dei dischi permanenti, puoi utilizzare le istantanee pianificate e regolare il criterio di conservazione all'RPO.

Le azioni che devi intraprendere per recuperare un sistema a basso ritorno sulla spesa pubblicitaria, come questo:

  • Se necessario, esegui una sincronizzazione finale dei file o recuperali da uno snapshot di disco permanente.
  • Passaggio del database principale al sito DR.
  • Avvio dell'applicazione sul sito della RE.

Delle tre architetture di esempio mostrate, l'esempio a basso ritorno sulla spesa pubblicitaria è il più costoso.

Opzione RTO più bassa degli esempi mostrati: il sito DR contiene PAS e ASCS su VM attive separate e di cui è stato eseguito il deployment.

Esempio di architettura DR di mezzo RTO

L'architettura di richiesta di servizio riportata di seguito ha un RTO più elevato rispetto all'esempio precedente, ma a un costo inferiore.

In questo progetto, il server del database è attivo per supportare la replica dal sito principale. Le VM per i server delle applicazioni non sono attive.

Le opzioni di backup che potresti utilizzare in questo scenario includono immagini di sistema operativo e snapshot di dischi permanenti archiviati in Compute Engine e la replica dei dati tra i siti principali e DR.

Dal momento che viene utilizzata la replica dei dati, il rischio di perderla è limitato all'ultima sincronizzazione del database.

Per estendere il tempo RPO, puoi archiviare i backup dei dati in un bucket Cloud Storage, che non viene mostrato nel diagramma. Per gli snapshot dei dischi permanenti, puoi utilizzare le istantanee pianificate e regolare il criterio di conservazione 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 quella richiesta sul sito principale, il che può contribuire a ridurre i costi fino all'attivazione del sistema di DR. In questo caso, devi ridimensionare la VM alle dimensioni richieste durante il ripristino.

Le azioni che devi intraprendere per ripristinare un sistema come questo sono:

  • Se necessario, esegui il deployment delle istanze VM per SAP NetWeaver e dei server delle applicazioni da snapshot di dischi permanenti o immagini.
  • Sincronizzazione dei file system da snapshot dei dischi permanenti o altro spazio di archiviazione.
  • Se necessario, ridimensionamento dell'istanza VM del database.
  • Passaggio del database principale al sito DR.
  • Avvio del servizio dell'applicazione nel sito DR.

Opzione RTO inferiore: il sito DR contiene PAS e ASCS su VM separate, pre-eseguite il deployment e inattive.

Architettura DR di esempio ad alto RTO

Il seguente diagramma dell'architettura mostra l'indice di RTO più elevato tra gli esempi mostrati ed è l'opzione più economica.

In questa progettazione, puoi eseguire il deployment dei server e quindi arrestarli per evitare che ti vengano addebitati costi per le VM oppure per evitare costi associati ai dischi permanenti e ad altre risorse correlate alle VM, puoi eseguire il deployment delle VM come parte del tuo processo di ripristino.

Le opzioni di backup che probabilmente utilizzerai in questo scenario includono immagini di sistema operativo e snapshot di dischi permanenti archiviati in Compute Engine e backup di dati archiviati in Cloud Storage.

Per soddisfare l'RPO, puoi modificare sia la frequenza di backup sia i criteri di conservazione delle tue pianificazioni di snapshot e dei backup nel bucket Cloud Storage.

Le azioni che devi intraprendere per ripristinare un sistema come questo sono:

  • Se necessario, il deployment delle istanze VM per SAP NetWeaver, dei server delle applicazioni e del server dei database da snapshot di dischi permanenti in più aree geografiche o immagini archiviate in Compute Engine.
  • Sincronizzazione dei file system da snapshot dei dischi permanenti o altro spazio di archiviazione.
  • Ripristino del database dai file di backup nel bucket Cloud Storage in più aree geografiche o altrove.
  • Passaggio del database principale al sito DR.
  • Avvio del servizio dell'applicazione nel sito DR.

Opzione più economica: il sito DR contiene solo snapshot di PAS, SAP ASCS/ERS e del server NFS.

Partner e prodotti per le soluzioni DR per SAP su Google Cloud

Puoi trovare partner per aiutarti con la tua soluzione DR nella Directory dei partner di Google Cloud.

Inoltre, puoi trovare vari prodotti e partner per supportare la tua soluzione DR su Google Cloud Marketplace.