Configura e pianifica un deployment del servizio di backup e RE

Questa pagina descrive come eseguire l'attivazione iniziale del servizio Backup e DR e configurare le impostazioni per il tuo progetto.

Componenti dell'architettura di Backup e RE

L'architettura del servizio di backup e DR viene fornita tramite i seguenti componenti:

  • Console di gestione: la console di gestione funge da piano di gestione per le appliance di backup/ripristino. Ogni deployment di Backup e RE include una singola console di gestione che gestisce un numero qualsiasi di appliance di backup/ripristino. La console di gestione viene implementata nel progetto di amministrazione dei backup ed è a disponibilità elevata all'interno della regione di deployment, garantendo la resilienza contro le interruzioni a livello di zona.

  • Appliance di backup/ripristino: l'appliance di backup/ripristino è il dispositivo di trasferimento dei dati che acquisisce, sposta e gestisce in modo efficiente il ciclo di vita dei dati di backup all'interno dell'azienda. Le appliance di backup/ripristino vengono implementate nell'entità Workload per i carichi di lavoro cloud.

  • Agenti Backup and DR: l'agente Backup and RE chiama le API native dell'applicazione per acquisire in modo efficiente i dati dalle applicazioni di produzione in modo incrementale per sempre e fornisce la consapevolezza dell'applicazione al momento del ripristino. L'agente è installato sugli host delle applicazioni in cui risiedono le applicazioni da proteggere. Se proteggi solo l'intera VM o un sottoinsieme dei suoi dischi, l'agente Backup REDR non è necessario.

La console di gestione viene attivata in una rete VPC del producer di servizi. Il VPC del producer di servizi comunica con il tuo progetto utilizzando l'accesso privato Google.

La comunicazione tra il server di gestione e gli appliance, tra gli appliance e tra gli appliance e gli agenti host è protetta dall'autenticazione TLS reciproca (mTLS).

Considerazioni sull'implementazione

Di seguito sono riportate alcune considerazioni importanti che influiscono sulla modalità di deployment del servizio di backup e DR:

  • Quali sono i requisiti di RTO (Recovery Time Objective) della tua organizzazione? L'RTO è il periodo di tempo massimo che puoi permetterti di rimanere senza i tuoi dati. Ad esempio, se il tuo RTO è di 4 ore,devi essere in grado di accedere ai tuoi dati entro 4 ore da un disastro.

  • Devi centralizzare la gestione dei backup? Devi decidere se vuoi gestire i backup in modo centralizzato o meno.

    • La gestione centralizzata dei backup ti consente di disporre di un'unica console di gestione per gestire i backup di tutti i tuoi carichi di lavoro in tutte le linee di business. Questo può essere un modo più efficiente per gestire i backup, in quanto devi gestire una sola console di gestione.
    • La gestione decentralizzata dei backup significa che hai una console di gestione separata per ogni linea di business. La modalità di funzionamento varia da un'organizzazione all'altra.

  • Qual è il tuo caso d'uso per il backup? Hai bisogno di backup per la preparazione al ripristino di emergenza in caso di disastro in una regione di produzione o è sufficiente proteggere i dati localmente? Se hai bisogno della funzionalità di ripristino di emergenza, devi prendere in considerazione i backup tra regioni. Ciò significa archiviare i backup in più posizioni, in modo che se una posizione è interessata da un disastro, i tuoi dati saranno comunque accessibili.

I workload si trovano in una singola regione

La strategia di backup migliore all'interno di una regione dipende dalle tue esigenze.

Se non hai bisogno del ripristino di emergenza

Per ottenere le prestazioni più rapide e ridurre i costi, esegui il deployment della console di gestione e delle appliance di backup/ripristino nella stessa regione in cui vengono eseguiti i carichi di lavoro. Archivia le immagini di backup nella stessa regione dei tuoi carichi di lavoro.

Se vuoi anche avere copie di backup offsite, puoi archiviare i backup in una regione diversa o utilizzare l'archiviazione in due regioni o multiregionale. L'archiviazione dei backup in una regione diversa comporta costi di rete e di archiviazione.

Se hai bisogno sia del backup che RE

Per ottenere le prestazioni più rapide e ridurre i costi, esegui il deployment di una console di gestione nella stessa regione del carico di lavoro di produzione e di una seconda console di gestione nella regione che puoi utilizzare per il ripristino di emergenza.

Esegui il deployment delle appliance di backup/ripristino sia nella regione del carico di lavoro di produzione sia nella regione di RE per ridurre al minimo l'RTO (Recovery Time Objective). In questo modo, un ambiente di RE viene completamente sottoposto al provisioning preliminare e reso disponibile in caso di emergenza.

Archivia le immagini di backup nella regione di produzione e una copia nella regione RE ripristino di emergenza, oppure utilizza l'archiviazione in due regioni o multiregionale. La copia di backup della regione di produzione può soddisfare le esigenze di backup di routine con prestazioni più rapide. I dati copiati nella regioneREa possono essere utilizzati per ripristinare i carichi di lavoro nel caso in cui la regione di produzione non sia disponibile.

I carichi di lavoro si trovano in più regioni

La strategia di backup migliore tra le regioni dipende dalle tue esigenze.

L'accesso ai vault di backup multiregionali è disponibile solo su invito. Se vuoi richiedere l'accesso ai vault di backup multiregionali nel tuo progetto Google Cloud, contatta il tuo rappresentante di vendita.

Se non hai bisogno del ripristino di emergenza

Per ottenere le prestazioni più rapide e ridurre i costi, esegui il deployment della console di gestione in una delle regioni in cui vengono eseguiti i carichi di lavoro. Ciò consente la gestione centralizzata di tutti i carichi di lavoro e le regioni.

Esegui il deployment di una o più appliance di backup/ripristino in ogni regione in cui vengono eseguiti i carichi di lavoro. Archivia i backup nella stessa regione dei carichi di lavoro.

Se vuoi anche avere copie di backup offsite, puoi archiviare i backup in una regione diversa o utilizzare l'archiviazione in due regioni o multiregionale. L'archiviazione dei backup in una regione o multiregione diversa comporta costi di rete e di archiviazione.

Se hai bisogno sia del backup che RE

Esegui il deployment di una console di gestione in ciascuna delle regioni dei carichi di lavoro di produzione e di un'altra console di gestione nella regione diRER.

Esegui il deployment delle appliance di backup/ripristino sia nelle regioni dei carichi di lavoro di produzione sia nella regione di RE per ridurre al minimo l'RTO (Recovery Time Objective). In questo modo, un ambiente di RE viene completamente sottoposto al provisioning preliminare e reso disponibile in caso di emergenza.

Archivia i backup nella regione del workload di produzione e una copia nella regione di RE oppure utilizza l'archiviazione in due o più regioni. La copia di backup della regione di produzione può essere utilizzata per soddisfare le esigenze di backup.

Un'immagine di backup nel RE può essere utilizzata per ripristinare i carichi di lavoro se la regione di produzione non è disponibile.

Configura il servizio di backup e DR nella console Google Cloud

Vai alla console Google Cloud per attivare l'API del servizio Backup e DR e configurare le autorizzazioni per il tuo account:

Attivare il servizio di backup e RE di Google Cloud

Tipi di appliance di backup/ripristino

Il servizio Backup e DR fornisce tipi di appliance ottimizzati per diversi carichi di lavoro: VM di Compute Engine, VM VMware, database e file system. Puoi scegliere il tipo di elettrodomestico più adatto alle tue esigenze. È importante selezionare il tipo di appliance migliore per i tuoi workload. Una volta che l'appliance di backup/ripristino è in servizio, viene eseguita continuamente, sempre pronta a eseguire e rieseguire backup, ripristino e altri job in qualsiasi momento.

Il servizio di Backup e DR fornisce i seguenti tipi di appliance:

  • Standard per VM Compute Engine o database SAP HANA: seleziona questa opzione se vuoi eseguire il backup solo delle istanze Compute Engine o dei database SAP HANA utilizzando Persistent Disk. Per impostazione predefinita, questo appliance aggiunge un tipo di macchina e2-standard-4 con una capacità minimaPersistent Diske di 10 GB. Questa appliance può gestire fino a 5000 VM di Compute Engine.
  • Standard per VM VMware e altri database o risorse: seleziona questa opzione se vuoi una configurazione standard che supporti prestazioni ottimali per il backup di database, VM VMware e altre risorse. Per impostazione predefinita, questo appliance aggiunge un tipo di macchina n2-standard-16. In questo modo, la capacità minima del disco viene impostata su 4 TB. Questo appliance può gestire fino a 1500 applicazioni.

  • Di base per VM VMware e altri database o risorse: seleziona questa opzione se vuoi una configurazione di base che supporti prestazioni moderate per il backup di database, VM VMware e altre risorse. Per impostazione predefinita, questo appliance aggiunge un tipo di macchina e2-standard-16. Questo appliance può gestire fino a 1500 applicazioni. Puoi scegliere uno dei seguenti tipi di disco per archiviare i dati.

    • Disco permanente con capacità minima: questa opzione fornisce una capacità minima del disco di 10 GB. In questo tipo di archiviazione, i backup vengono archiviati come snapshot di Persistent Disk e non consumano lo spazio di archiviazione locale dell'appliance di backup/ripristino.
    • Disco permanente standard: seleziona questo tipo di archiviazione se vuoi un'archiviazione a blocchi efficiente. Questo tipo di disco è consigliato per le VM, i database o le applicazioni di file system di Google Cloud VMware Engine con I/O medio-alto, oltre che per le VM di Compute Engine. In questo modo, la capacità minima del disco è di 4 TB.
    • Disco permanente SSD: seleziona questo tipo di archiviazione se vuoi disporre di un'archiviazione a blocchi veloce. Consigliato per Google Cloud VMware Engine, per le applicazioni di database o file system con attività di I/O intensiva, oltre che per le VM di Compute Engine. In questo modo, la capacità minima del disco è di 4 TB.

Quando esegui il deployment di un'appliance, viene creato automaticamente un account di servizio indipendentemente dal tipo di appliance. Puoi visualizzare il account di servizio dalla pagina Service account.

Il nome del account di servizio viene visualizzato nel formato dell'indirizzo email my-service-account@my-project.iam.gserviceaccount.com, dove appliance-name è il nome di un'appliance e projectid è l'ID del tuo progetto Google Cloud .

Scegliere un tipo di archiviazione

L'appliance di backup/ripristino archivia i dati di backup nel pool di snapshot dell'appliance locale. Puoi copiarlo nell'archiviazione degli oggetti per la conservazione a lungo termine. Google Cloud offre i seguenti tre tipi di archiviazione degli oggetti locale:

  • Disco permanente con capacità minima: le immagini di backup vengono archiviate come snapshot Persistent Disk che non consumano lo spazio di archiviazione locale dell'appliance di backup/ripristino.

  • Disco permanente standard: questo tipo di archiviazione offre un'archiviazione a blocchi efficiente, a partire da un Persistent Disk da 4 TB. Consigliato per VMware Engine e applicazioni di database o file system con I/O medio-alto.

  • SSD Persistent Disk: questo tipo di archiviazione offre un'archiviazione a blocchi veloce, a partire da un Persistent Disk da 4 TB. Questo è consigliato per le VM di VMware Engine e per le applicazioni di database o file system con attività di I/O intensiva. Google Cloud

Puoi espandere la capacità dei tuoi pool di dischi in un secondo momento.

Puoi spostare i backup con esigenze di conservazione a lungo termine in Google Cloud Standard, Nearline e Coldline Storage a seconda della necessità prevista di accedere ai dati.

Topologia di rete consigliata per il servizio di backup e DR

Google Cloud consiglia l'utilizzo del VPC condiviso durante il deployment del servizio Backup e DR. Un VPC condiviso consente a un'organizzazione di connettere risorse di più progetti a una rete VPC (Virtual Private Cloud) comune, in modo che possano comunicare tra loro in modo sicuro ed efficiente utilizzando IP interni di quella rete. Quando utilizzi un VPC condiviso, designi un progetto come progetto host, a cui colleghi uno o più altri progetti di servizio. Le reti VPC nel progetto host sono chiamate reti VPC condiviso. Le risorse idonee dei progetti di servizio possono utilizzare subnet della rete VPC condiviso.

Un VPC condiviso consente agli amministratori dell'organizzazione di delegare le responsabilità amministrative, ad esempio la creazione e la gestione delle istanze, agli amministratori dei progetti di servizio mantenendo al contempo il controllo centralizzato sulle risorse di rete come subnet, route e firewall.

La console di gestione viene attivata in una rete VPC VPC del producer di servizi. Il VPC del producer di servizi comunica con il tuo progetto utilizzando l'accesso privato Google. Lo scopo principale di questa connessione è lo scambio di metadati tra la console di gestione e gli appliance di backup/recupero. Il traffico di backup non attraversa questo collegamento. Tuttavia, una console di gestione deve comunicare con tutte le appliance di backup/ripristino di cui è stato eseguito il deployment in qualsiasi rete.

Best practice per il VPC condiviso

Si consiglia di adottare le best practice riportate di seguito.

  • Connessione alla console di gestione: è consigliabile connettere la rete del fornitore di servizi a un VPC condiviso all'interno della tua rete. Tutto il traffico dalla console di gestione passa attraverso questo VPC e, di conseguenza, attraverso il progetto host. Il provisioning della connettività al servizio di backup e DR tramite un VPC condiviso consente anche una connessione senza interruzioni tra i progetti in cui vengono eseguiti i carichi di lavoro (progetti di servizio) e il servizio di backup e DR.

  • Posizione dell'appliance di backup/ripristino: le appliance di backup/ripristino devono essere implementate in una subnet in cui è abilitato l'accesso privato Google per la connettività alla console di gestione. Esistono due strategie consigliate per selezionare i progetti per le appliance di backup/ripristino:

    • Nel progetto host centrale: in questa strategia, il servizio di Backup e DR è considerato un servizio centrale dell'IT. Il team di backup centrale governa il provisioning del servizio. Pertanto, tutte le appliance di backup/ripristino vengono sottoposte a provisioning nel progetto host, consentendo agli amministratori centrali di consolidare tutte le risorse di backup in un progetto centrale. Questo approccio ha il vantaggio di consolidare tutte le risorse correlate al backup e la relativa fatturazione in un unico progetto.

    • Nei progetti di servizio: questa strategia è adatta a team più decentralizzati in cui vengono creati progetti di servizio e la loro gestione viene delegata a team distribuiti. In questo scenario, la best practice consigliata è di eseguire il provisioning del VPC per i progetti di servizio downstream. L'appliance di backup/ripristino viene installata nei progetti di servizio all'interno di questi VPC. In questo modo è possibile la colocation del carico di lavoro e dell'appliance di backup/ripristino all'interno di un unico progetto.

    • Accesso privato Google: è una best practice abilitare l'accesso privato Google per ogni subnet in cui installi un'appliance di backup/recupero. In questo modo, l'appliance di backup/recupero può comunicare con le API, ad esempio Compute Engine, Cloud Storage e Cloud Logging, il che è importante per il funzionamento del monitoraggio e degli avvisi. Per semplificare e migliorare le connessioni alle API Google Cloud , valuta la possibilità di configurare la risoluzione DNS per private.googleapis.com come descritto nella sezione Riepilogo delle opzioni di configurazione. Inoltre, configura le regole firewall dagli appliance di backup/recupero per consentire le connessioni all'intervallo CIDR 199.36.153.8/30 sulla porta TCP 443.

Configurazioni del firewall

Vengono aggiunte automaticamente le seguenti regole firewall richieste per l'accesso in entrata al servizio di Backup e DR.

Finalità Origine Target Porta (TCP)
Traffico di assistenza (assistenza all'appliance) Host che esegue il client SSH Appliance di backup/ripristino 26
Backup iSCSI (host ad appliance) Host che esegue l'agente Backup and RE Appliance di backup/ripristino 3260
Traffico StreamSnap (da appliance ad appliance) Appliance di backup/ripristino Appliance di backup/ripristino 5107
Connettività dell'appliance di backup/ripristino alla console di gestione IP o subnet dell'appliance di backup/ripristino *.backupdr.googleusercontent.com 443

Per maggiori dettagli su come configurare questa regola, vedi Prepararsi per il deployment del servizio di backup e DR.

Per qualsiasi host che esegue l'agente Backup and RE, devi aggiungere manualmente la seguente porta TCP per consentire la connettività con una regola firewall in entrata.

Finalità Origine Target Porta (TCP)
Traffico dell'agente (appliance all'host) Appliance di backup/ripristino Host che esegue l'agente Backup and RE 5106

Per gli host che utilizzano NFS per il traffico di backup o per gli host ESX in esecuzione in VMware Engine che utilizzano NFS per i montaggi, devi aggiungere manualmente le seguenti porte TCP e UDP per consentire la connettività con una regola firewall in entrata.

Finalità Origine Target Porta (TCP/UDP)
Backup o montaggio NFS Host che esegue l'agente o host ESXi che esegue il montaggio Appliance di backup/ripristino 111, 756, 2049, 4001, 4045

Per un elenco delle autorizzazioni utilizzate durante questa operazione, consulta Documentazione di riferimento sulle autorizzazioni di installazione di RE e DR.

Aree geografiche supportate

La sezione seguente elenca le regioni supportate dalla console di gestione e dalle appliance di backup/ripristino.

Regioni supportate dalla console di gestione

Sebbene il servizio di Backup e DR possa essere utilizzato per eseguire il backup dei carichi di lavoro supportati in qualsiasi regioneGoogle Cloud , la console di gestione può essere attivata solo nelle seguenti regioni:

Area geografica Nome regione Descrizione regione
Nord America
northamerica-northeast1 * Montréal icona foglia Bassi livelli di CO2
northamerica-northeast2 Toronto icona foglia Bassi livelli di CO2
us-central1 Iowa icona foglia Bassi livelli di CO2
us-east1 Carolina del Sud
us-east4 Virginia del Nord
us-east5 Columbus
us-south1 Dallas icona foglia Bassi livelli di CO2
us-west1 Oregon icona foglia Bassi livelli di CO2
us-west2 Los Angeles
us-west3 Salt Lake City
us-west4 Las Vegas
northamerica-south1 * Querétaro
Sud America
southamerica-east1 San Paolo icona foglia Bassi livelli di CO2
southamerica-west1 Santiago icona foglia Bassi livelli di CO2
Europa
europe-central2 Varsavia
europe-north1 Finlandia icona foglia Bassi livelli di CO2
europe-southwest1 Madrid icona foglia Bassi livelli di CO2
europe-west1 Belgio icona foglia Bassi livelli di CO2
europe-west2 Londra icona foglia Bassi livelli di CO2
europe-west3 Francoforte icona foglia Bassi livelli di CO2
europe-west4 Paesi Bassi icona foglia Bassi livelli di CO2
europe-west6 Zurigo icona foglia Bassi livelli di CO2
europe-west8 Milano
europe-west9 Parigi icona foglia Bassi livelli di CO2
europe-west10 Berlino icona foglia Bassi livelli di CO2
europe-west12 Torino
Medio Oriente
me-central1 Doha
me-central2 Dammam
me-west1 Israele
Africa
africa-south1 Johannesburg
Asia Pacifico
asia-east1 Taiwan
asia-east2 Hong Kong
asia-northeast1 Tokyo
asia-northeast2 * Osaka
asia-northeast3 Seul
asia-southeast1 Singapore
asia-southeast2 Giacarta
australia-southeast1 Sydney
australia-southeast2 Melbourne
India
asia-south1 Mumbai
asia-south2 Delhi

* Querétaro, Montréal e Osaka hanno tre zone in uno o due data center fisici. Nel raro caso di un disastro, i dati archiviati in queste regioni possono andare persi.

Regioni supportate dall'appliance di backup/ripristino

È possibile eseguire il deployment delle appliance di backup/ripristino in qualsiasi Google Cloud zona.

Il servizio di workflow per eseguire il deployment dell'appliance di backup/ripristino è supportato nelle regioni elencate. Se il servizio Workflow non è disponibile in una regione in cui è stato eseguito il deployment dell'appliance di backup/ripristino, il servizio di backup e DR esegue il workflow per impostazione predefinita nella regione us-central1 (l'appliance stessa viene comunque creata nella regione selezionata). Se hai un criterio dell'organizzazione impostato per impedire la creazione di risorse in altre regioni, devi aggiornarlo temporaneamente per consentire la creazione di risorse nella regione us-central1. Puoi limitare la regione us-central1 dopo il deployment dell'appliance di backup/ripristino.

Passaggi successivi