Componenti di base per il ripristino di emergenza

Last reviewed 2022-06-10 UTC

Questo documento è la seconda parte di una serie che tratta del ripristino di emergenza (RE) in Google Cloud. Questa parte illustra i servizi e i prodotti che puoi utilizzare come componenti di base per il tuo piano di RE, sia i prodotti Google Cloud che i prodotti funzionanti su più piattaforme.

La serie è costituita dai seguenti componenti:

Introduzione

Google Cloud offre un'ampia gamma di prodotti che puoi utilizzare nell'architettura di ripristino di emergenza (RE). Questa sezione illustra le funzionalità relative a RE dei prodotti più comunemente utilizzati come componenti di base per il ripristino di emergenza di Google Cloud.

Molti di questi servizi dispongono di funzionalità ad alta disponibilità. L'alta disponibilità non si sovrappone completamente alla RE, ma molti degli obiettivi dell'alta disponibilità si applicano anche alla progettazione di un piano di RE. Ad esempio, sfruttando le funzionalità ad alta disponibilità, puoi progettare architetture che ottimizzano l'uptime e possono mitigare gli effetti di errori su scala ridotta, come l'errore di una singola VM. Per ulteriori informazioni sul rapporto tra RE e HA, consulta la Guida alla pianificazione del ripristino di emergenza.

Le sezioni seguenti descrivono i componenti di base di Google Cloud RE e il modo in cui ti aiutano a implementare i tuoi obiettivi di RE.

Computing e archiviazione

La tabella seguente fornisce un riepilogo delle funzionalità dei servizi di computing e archiviazione di Google Cloud che fungono da componenti di base per RE:

Prodotto Selezione delle
Compute Engine
  • Risorse di calcolo scalabili
  • Tipi di macchina predefinita e personalizzata
  • Tempi di avvio rapidi
  • Snapshot
  • Modelli di istanza
  • gruppi di istanze gestite
  • Prenotazioni
  • Dischi permanenti
  • Migrazione live
Cloud Storage
  • Archivio di oggetti a elevata durabilità
  • Ridondanza tra regioni
  • Classi di archiviazione
  • Gestione del ciclo di vita degli oggetti
  • Trasferimento di dati da altre origini
  • Crittografia at-rest per impostazione predefinita
  • Eliminazione temporanea
GKE
  • Ambiente gestito per il deployment e la scalabilità delle applicazioni containerizzate
  • Riparazione automatica dei nodi
  • probe di attività e idoneità
  • I volumi permanenti
  • Cluster multizona e regionali
  • Strumento a riga di comando per la gestione di cluster tra regioni

Compute Engine

Compute Engine fornisce le istanze di macchine virtuali (VM) ed è il cavallo di battaglia di Google Cloud. Oltre alla configurazione, all'avvio e al monitoraggio delle istanze di Compute Engine, in genere viene utilizzata una serie di funzionalità correlate per implementare un piano di RE.

Per gli scenari di RE, puoi impedire l'eliminazione accidentale delle VM impostando il flag di protezione dall'eliminazione. Questo è particolarmente utile se ospiti servizi stateful come i database. Per rispettare i valori RTO e RPO bassi, segui le best practice per la progettazione di sistemi solidi.

Puoi configurare un'istanza con la tua applicazione preinstallata e poi salvarla come immagine personalizzata. L'immagine personalizzata può riflettere l'RTO che vuoi raggiungere.

Modelli di istanza

Puoi utilizzare i modelli di istanza di Compute Engine per salvare i dettagli di configurazione della VM e poi creare istanze da modelli di istanza esistenti. Puoi utilizzare il modello per avviare tutte le istanze necessarie, configurate esattamente come vuoi quando devi supportare l'ambiente di destinazione di RE. I modelli di istanza vengono replicati a livello globale, quindi puoi ricreare l'istanza ovunque in Google Cloud con la stessa configurazione.

Puoi creare modelli di istanza utilizzando un'immagine personalizzata o basati su istanze VM esistenti.

Ulteriori dettagli sull'utilizzo delle immagini Compute Engine sono disponibili nella sezione Bilanciamento della configurazione delle immagini e della velocità di deployment più avanti in questo documento.

gruppi di istanze gestite

I gruppi di istanze gestite utilizzano Cloud Load Balancing, come descritto più avanti in questo documento, per distribuire il traffico in gruppi di istanze configurate in modo identico e copiate in più zone. I gruppi di istanze gestite consentono funzionalità come la scalabilità automatica e la riparazione automatica, in cui il gruppo di istanze gestite può eliminare e ricreare automaticamente le istanze.

Prenotazioni

Compute Engine consente di prenotare le istanze VM in una zona specifica, utilizzando tipi di macchine personalizzate o predefinite, con o senza GPU aggiuntive o SSD locali. Per garantire la capacità dei tuoi carichi di lavoro mission critical per il ripristino di emergenza, devi creare prenotazioni nelle zone di destinazione di RE. Senza prenotazioni, è possibile che tu non abbia la capacità on demand necessaria per raggiungere il tuo Recovery Time Objective. Le prenotazioni possono essere utili in scenari di RE a freddo, caldo o caldo. Consentono di mantenere disponibili le risorse di recupero per il failover per soddisfare esigenze di RTO più ridotte, senza doverle configurare ed eseguire in anticipo il deployment.

Dischi e snapshot permanenti

I dischi permanenti sono dispositivi di archiviazione di rete durevoli a cui possono accedere le istanze. Sono indipendenti dalle istanze, quindi puoi scollegare e spostare i dischi permanenti per conservare i dati anche dopo aver eliminato le istanze.

Puoi creare backup o snapshot incrementali delle VM di Compute Engine che puoi copiare in più regioni e utilizzare per ricreare i dischi permanenti in caso di emergenza. Inoltre, puoi creare snapshot di dischi permanenti per proteggerti dalla perdita di dati dovuta a errori utente. Gli snapshot sono incrementali e la loro creazione richiede solo pochi minuti anche se i dischi degli snapshot sono collegati a istanze in esecuzione.

I dischi permanenti dispongono di ridondanza integrata per proteggere i dati da guasti dell'apparecchiatura e per garantirne la disponibilità tramite gli eventi di manutenzione del data center. I dischi permanenti sono a livello di zona o di regione. I dischi permanenti a livello di regione replicano le scritture su due zone in una regione. In caso di interruzione di una zona, un'istanza VM di backup può eseguire il collegamento forzato di un disco permanente a livello di regione nella zona secondaria. Per scoprire di più, consulta Opzioni di alta disponibilità che utilizzano dischi permanenti a livello di regione.

Migrazione live

La migrazione live mantiene le istanze VM in esecuzione anche quando si verifica un evento del sistema host, ad esempio un aggiornamento del software o dell'hardware. Compute Engine Live esegue la migrazione delle istanze in esecuzione a un altro host nella stessa zona anziché richiedere il riavvio delle VM. In questo modo, Google può eseguire la manutenzione, essenziale per mantenere l'infrastruttura protetta e affidabile, senza interrompere nessuna delle tue VM.

Strumento di importazione del disco virtuale

Lo strumento di importazione di dischi virtuali consente di importare formati file, tra cui VMDK, VHD e RAW, per creare nuove macchine virtuali Compute Engine. Questo strumento consente di creare macchine virtuali Compute Engine con la stessa configurazione delle macchine virtuali on-premise. Questo è un buon approccio quando non sei in grado di configurare le immagini Compute Engine dai programmi binari di origine del software già installato sulle tue immagini.

Cloud Storage

Cloud Storage è un archivio di oggetti ideale per l'archiviazione dei file di backup. Fornisce diverse classi di archiviazione adatte a casi d'uso specifici, come descritto nel diagramma seguente.

Diagramma che mostra Standard Storage per l'accesso ad alta frequenza, Nearline e Coldline per l'accesso a bassa frequenza e Archive per l'accesso con la frequenza più bassa

Negli scenari di RE, le soluzioni di archiviazione Nearline, Coldline e Archive sono di particolare interesse. Queste classi di archiviazione riducono i costi di archiviazione rispetto alla classe Standard. Tuttavia, sono previsti costi aggiuntivi associati al recupero di dati o metadati archiviati in queste classi, oltre a durate minime di archiviazione che vengono addebitate. Nearline è progettato per scenari di backup in cui l'accesso avviene al massimo una volta al mese, il che è ideale per consentirti di eseguire regolari stress test di RE mantenendo bassi i costi.

Nearline, Coldline e Archive sono ottimizzate per gli accessi non frequenti e il modello di prezzo è progettato proprio per questo. Pertanto, ti vengono addebitati i costi per le durate minime di archiviazione e sono previsti costi aggiuntivi per il recupero di dati o metadati in queste classi precedenti alla durata minima di archiviazione per la classe.

Per proteggere i dati in un bucket Cloud Storage da eliminazioni accidentali o dannose, puoi utilizzare la funzionalità di eliminazione temporanea per conservare gli oggetti eliminati e sovrascritti per un determinato periodo di tempo.

Storage Transfer Service consente di importare i dati da Amazon S3 o da origini basate su HTTP in Cloud Storage. Negli scenari di RE, puoi utilizzare Storage Transfer Service per:

  • Esegui il backup dei dati di altri fornitori di spazio di archiviazione in un bucket Cloud Storage.
  • Sposta i dati da un bucket in una località con due o più regioni a un bucket in un'area geografica per ridurre i costi per l'archiviazione dei backup.

Filestore

Le istanze Filestore sono file server NFS completamente gestiti da utilizzare con applicazioni in esecuzione su istanze di Compute Engine o cluster GKE.

Le istanze Filestore operano a livello di zona e non supportano la replica tra le zone. Un'istanza Filestore non è disponibile se la zona in cui si trova è inattiva. Ti consigliamo di eseguire periodicamente il backup dei dati sincronizzando il volume Filestore con un'istanza Filestore in un'altra regione utilizzando il comando gsutil rsync. A questo scopo, è necessario pianificare un job per l'esecuzione su istanze di Compute Engine o cluster GKE.

Negli scenari di RE, le applicazioni possono riprendere rapidamente l'accesso ai volumi Filestore passando a Filestore nelle regioni di failover senza dover attendere il completamento del processo di ripristino. Il valore dell'RTO di questa soluzione di RE dipende in gran parte dalla frequenza del job pianificato.

GKE

GKE è un ambiente gestito e pronto per la produzione dedicato al deployment di applicazioni containerizzate. GKE ti consente di orchestrare i sistemi ad alta disponibilità e include le seguenti funzionalità:

  • Riparazione automatica dei nodi. Se un nodo non supera controlli di integrità consecutivi per un periodo di tempo prolungato (circa 10 minuti), GKE avvia un processo di riparazione per quel nodo.
  • Probe di attività. Puoi specificare un probe di attività, che comunica periodicamente a GKE che il pod è in esecuzione. Se il pod non supera il probe, può essere riavviato.
  • Volumi permanenti. I database devono essere in grado di persistere oltre la durata di un container. Utilizzando l'astrazione del volume permanente, mappata a un disco permanente di Compute Engine, puoi mantenere la disponibilità dello spazio di archiviazione indipendentemente dai singoli container.
  • Cluster multizona e a livello di regione. Puoi distribuire le risorse Kubernetes su più zone all'interno di una regione.
  • Il gateway multi-cluster consente di configurare risorse di bilanciamento del carico condivise in più cluster GKE in diverse regioni.
  • Backup per GKE ti consente di eseguire il backup e il ripristino dei carichi di lavoro nei cluster GKE.

Networking e trasferimento di dati

La seguente tabella fornisce un riepilogo delle funzionalità dei servizi di networking e trasferimento dati di Google Cloud che fungono da componenti di base per RE:

Prodotto Selezione delle
Cloud Load Balancing
  • Controlli di integrità
  • IP Anycast singolo
  • Tra regioni
  • Integrazione di Cloud CDN
  • Integrazione della scalabilità automatica
Traffic Director
  • Global L7 ILB gestito da Google
  • Piano di controllo per i proxy di servizio aperti conformi a xDSv2
  • Supporta VM e container
  • Offload controllo di integrità
  • Scalabilità automatica rapida
  • Routing delle richieste avanzato e criteri avanzati di controllo del traffico
Cloud DNS
  • Gestione del DNS programmatico
  • Controllo dell'accesso
  • Anycast per gestire le zone
  • Criteri DNS
Cloud Interconnect
  • Cloud VPN (IPsec VPN)
  • Peering diretto

Cloud Load Balancing

Cloud Load Balancing fornisce alta disponibilità per Compute Engine distribuendo le richieste degli utenti tra un insieme di istanze. Puoi configurare Cloud Load Balancing con controlli di integrità che determinano se le istanze sono disponibili per il funzionamento, in modo che il traffico non venga instradato a istanze con errori.

Cloud Load Balancing fornisce un unico indirizzo IP accessibile a livello globale per gestire le istanze di Compute Engine. L'applicazione può avere istanze in esecuzione in diverse regioni (ad esempio, in Europa e negli Stati Uniti) e gli utenti finali vengono indirizzati all'insieme di istanze più vicino. Oltre a fornire il bilanciamento del carico per i servizi esposti a internet, puoi configurare il bilanciamento del carico interno per i tuoi servizi dietro un indirizzo IP privato di bilanciamento del carico. Questo indirizzo IP è accessibile solo alle istanze VM interne al tuo Virtual Private Cloud (VPC).

Traffic Director

Con Traffic Director, esegui il deployment di un piano di controllo del traffico completamente gestito per il tuo mesh di servizi. Traffic Director gestisce la configurazione dei proxy di servizio in esecuzione sia in Compute Engine che in GKE. Eseguire il deployment di un servizio in più regioni per renderlo ad alta disponibilità. Traffic Director scaricherà i controlli di integrità dei servizi e avvierà una configurazione di failover dei proxy di servizio, reindirizzando il traffico a istanze in stato integro.

Traffic Director supporta inoltre concetti avanzati di controllo del traffico, interruzione dei circuiti e fault injection. Con l'interruzione di circuito, puoi applicare limiti alle richieste a un determinato servizio, dopodiché viene impedito alle richieste di raggiungere il servizio, impedendo un ulteriore deterioramento. Con l'inserimento di errori, Traffic Director può introdurre ritardi o interrompere una parte delle richieste a un servizio, consentendoti di testare la capacità del servizio di sopravvivere ai ritardi nelle richieste o alle richieste interrotte.

Cloud DNS

Cloud DNS offre un modo programmatico per gestire le voci DNS nell'ambito di un processo di recupero automatizzato. Cloud DNS utilizza la rete globale Google di server dei nomi Anycast per la gestione delle zone DNS da località ridondanti in tutto il mondo, offrendo disponibilità elevata e minore latenza ai tuoi utenti.

Se hai scelto di gestire le voci DNS on-premise, puoi abilitare le VM in Google Cloud per risolvere questi indirizzi tramite l'inoltro di Cloud DNS.

Cloud DNS supporta i criteri per configurare il modo in cui risponde alle richieste DNS. Ad esempio, puoi configurare criteri di routing per abilitare il failover a una configurazione di backup per fornire alta disponibilità o per instradare le richieste DNS in base alla loro posizione geografica.

Cloud Interconnect

Cloud Interconnect fornisce modi per spostare le informazioni da altre origini a Google Cloud. Parleremo di questo prodotto più avanti nella sezione Trasferimento di dati da e verso Google Cloud.

Gestione e monitoraggio

La tabella seguente fornisce un riepilogo delle funzionalità dei servizi di gestione e monitoraggio di Google Cloud che fungono da componenti di base per RE:

Prodotto Selezione delle
Dashboard dello stato di Cloud
  • Stato dei servizi Google Cloud
Osservabilità di Google Cloud
  • Monitoraggio del tempo di attività
  • Avvisi
  • Logging
  • Error Reporting

Dashboard dello stato di Cloud

La dashboard dello stato di Cloud mostra la disponibilità attuale dei servizi Google Cloud. Puoi visualizzare lo stato nella pagina e iscriverti a un feed RSS che viene aggiornato ogni volta che ci sono notizie su un servizio.

Cloud Monitoring

Cloud Monitoring raccoglie metriche, eventi e metadati da Google Cloud, AWS, probe di uptime ospitati, strumentazione delle applicazioni e una varietà di altri componenti delle applicazioni. Puoi configurare gli avvisi in modo da inviare notifiche a strumenti di terze parti come Slack o Pagerduty al fine di fornire aggiornamenti tempestivi agli amministratori. Un altro modo per utilizzare Cloud Monitoring per il RE è configurare un sink Pub/Sub e utilizzare Cloud Functions per attivare un processo automatizzato in risposta a un avviso di Cloud Monitoring.

Componenti di base per il RE multipiattaforma

Quando esegui carichi di lavoro su più piattaforme, un modo per ridurre il sovraccarico operativo consiste nel selezionare strumenti compatibili con tutte le piattaforme in uso. In questa sezione vengono descritti alcuni strumenti e servizi indipendenti dalla piattaforma che supportano scenari di RE multipiattaforma.

Strumenti di creazione dei modelli dichiarativi

Gli strumenti per la creazione di modelli dichiarativi consentono di automatizzare il deployment dell'infrastruttura su più piattaforme. Terraform è un popolare strumento per la creazione di modelli dichiarativi.

Strumenti di gestione delle configurazioni

Per un'infrastruttura di RE grande o complessa, consigliamo strumenti di gestione del software indipendenti dalla piattaforma, come Chef e Ansible. Questi strumenti garantiscono la possibilità di applicare configurazioni riproducibili indipendentemente da dove si trova il carico di lavoro di computing.

Archiviazione di oggetti

Un pattern di RE comune consiste nell'avere copie degli oggetti in archivi di oggetti in diversi cloud provider. Uno strumento multipiattaforma è boto, una libreria Python open source che consente di interfacciarsi sia con Amazon S3 che con Cloud Storage.

Strumenti di Orchestrator

I container possono essere considerati anche un componente di base per il RE. I container sono un modo per pacchettizzare servizi e introdurre coerenza tra le piattaforme.

Se lavori con i container, in genere utilizzi un orchestratore. Kubernetes funziona non solo per gestire i container all'interno di Google Cloud (utilizzando GKE), ma offre anche un modo per orchestrare i carichi di lavoro basati su container su più piattaforme. Google Cloud, AWS e Microsoft Azure forniscono tutte versioni gestite di Kubernetes.

Per distribuire il traffico ai cluster Kubernetes in esecuzione su diverse piattaforme cloud, puoi utilizzare un servizio DNS che supporti i record ponderati e incorpora il controllo di integrità.

Devi inoltre assicurarti di poter eseguire il pull dell'immagine nell'ambiente di destinazione. Ciò significa che devi poter accedere al registro delle immagini in caso di emergenza. Una buona opzione, anche indipendente dalla piattaforma, è Artifact Registry.

Trasferimento di dati

Il trasferimento di dati è un componente fondamentale degli scenari di RE multipiattaforma. Assicurati di progettare, implementare e testare i tuoi scenari di RE multipiattaforma utilizzando prototipi realistici di ciò che richiede lo scenario di trasferimento di dati di RE. Nella sezione successiva parleremo degli scenari di trasferimento di dati.

Pattern di RE

Questa sezione illustra alcuni dei pattern più comuni per le architetture di RE in base ai componenti di base discussi in precedenza.

Trasferimento di dati da e verso Google Cloud

Un aspetto importante del piano di RE è la velocità con cui i dati possono essere trasferiti da e verso Google Cloud. Ciò è fondamentale se il tuo piano di RE si basa sullo spostamento dei dati da on-premise a Google Cloud o da un altro cloud provider a Google Cloud. Questa sezione illustra il networking e i servizi Google Cloud che possono garantire una buona velocità effettiva.

Quando utilizzi Google Cloud come sito di ripristino per i carichi di lavoro on-premise o in un altro ambiente cloud, considera i seguenti elementi chiave:

  • Come ti colleghi a Google Cloud?
  • Quanta larghezza di banda c'è tra te e il fornitore di interconnessione?
  • Qual è la larghezza di banda fornita dal fornitore direttamente a Google Cloud?
  • Quali altri dati verranno trasferiti utilizzando questo link?

Se utilizzi una connessione a internet pubblica per trasferire i dati, la velocità effettiva di rete è imprevedibile, poiché la capacità e il routing dell'ISP sono limitati. L'ISP potrebbe offrire uno SLA limitato o nessuno. D'altra parte, queste connessioni hanno costi relativamente bassi.

Cloud Interconnect offre diverse opzioni per la connessione a Google e Google Cloud:

  • Cloud VPN consente la creazione di tunnel VPN IPsec tra una rete VPC di Google Cloud e la rete di destinazione. Il traffico tra le due reti viene criptato da un gateway VPN, quindi decriptato dall'altro gateway VPN. La VPN ad alta disponibilità consente di creare connessioni VPN ad alta disponibilità con uno SLA del 99,99% e una configurazione semplificata rispetto alla creazione di VPN ridondanti.
  • Il peering diretto fornisce hop di rete minimi agli indirizzi IP pubblici di Google. Puoi utilizzare il peering diretto per scambiare il traffico internet tra la tua rete e i punti di presenza perimetrali (PoP) di Google.
  • Dedicated Interconnect fornisce una connessione fisica diretta tra la tua rete on-premise e la rete Google. Offre uno SLA e una velocità effettiva più coerente per i trasferimenti di dati di grandi dimensioni. I circuiti hanno una velocità di 10 Gbps o 100 Gbps e sono terminati presso una delle strutture di colocation di Google. Con una larghezza di banda maggiore, puoi ridurre il tempo necessario per trasferire i dati dall'ambiente on-premise a Google Cloud. La seguente tabella illustra i guadagni di velocità con l'upgrade da 10 Gbps a 100 Gbps. Grafico che mostra il tempo per trasferire i dati a 10 Gbps rispetto a 100 Gbps
  • Partner Interconnect fornisce funzionalità simili a Dedicated Interconnect, ma a una velocità del circuito inferiore a 10 Gbps. Vedi Fornitori di servizi supportati.

Il seguente diagramma fornisce indicazioni su quale metodo di trasferimento utilizzare, a seconda della quantità di dati da trasferire a Google Cloud.

Grafico che mostra quantità di dati sull'asse Y (da 0 a 100 TB precedenti) e categorie di località dei dati sull'asse X (ad esempio "In Google Cloud", "On-premise con una buona connettività" e così via), con soluzioni di trasferimento diverse in ogni categoria

Puoi utilizzare il calcolatore del tempo di trasferimento per capire quanto tempo potrebbe richiedere un trasferimento, date le dimensioni del set di dati che stai spostando e la larghezza di banda disponibile per il trasferimento. Per ulteriori informazioni sul trasferimento di dati nell'ambito della pianificazione di RE, consulta Trasferimento di grandi set di dati.

Bilanciare la configurazione delle immagini e la velocità di deployment

Quando configuri un'immagine macchina per il deployment di nuove istanze, considera l'effetto della configurazione sulla velocità di deployment. Esiste un compromesso tra la quantità di preconfigurazione dell'immagine, i costi di manutenzione dell'immagine e la velocità di deployment. Ad esempio, se un'immagine macchina è configurata in modo minimo, l'avvio delle istanze che la utilizzano richiede più tempo perché è necessario scaricare e installare le dipendenze. Se invece l'immagine della tua macchina è altamente configurata, le istanze che la utilizzano vengono avviate più rapidamente, ma devi aggiornare l'immagine più spesso. Il tempo impiegato per avviare un'istanza completamente operativa avrà una correlazione diretta con il tuo RTO.

Diagramma che mostra 3 livelli di raggruppamento (da non in bundle a completamente in bundle) mappati in base al tempo di avvio dell'immagine (il più bundle è il più veloce da avviare)

Mantenimento della coerenza delle immagini delle macchine in tutti gli ambienti ibridi

Se implementi una soluzione ibrida (da on-premise a cloud o da cloud a cloud), devi trovare un modo per mantenere la coerenza delle VM negli ambienti di produzione.

Se è necessaria un'immagine completamente configurata, potresti prendere in considerazione Packer, in grado di creare immagini macchina identiche per più piattaforme. Puoi utilizzare gli stessi script con file di configurazione specifici per la piattaforma. Nel caso di Packer, puoi impostare il file di configurazione nel controllo della versione per tenere traccia della versione di cui viene eseguito il deployment in produzione.

In alternativa, puoi utilizzare strumenti di gestione della configurazione come Chef, Puppet, Ansible o Saltstack per configurare le istanze con maggiore granularità, creando immagini di base, immagini con configurazione minima o immagini completamente configurate in base alle esigenze. Per una discussione su come utilizzare questi strumenti in modo efficace, consulta la pagina Zero-to-Deploy with Chef on Google Cloud.

Puoi anche convertire e importare manualmente immagini esistenti, ad esempio AMI Amazon, immagini Virtualbox e immagini disco RAW, in Compute Engine.

Implementazione dell'archiviazione a più livelli

Il pattern di archiviazione a più livelli viene in genere utilizzato per i backup in cui il backup più recente si trova su uno spazio di archiviazione più veloce, mentre esegui lentamente la migrazione dei backup meno recenti a uno spazio di archiviazione dai costi inferiori (ma lento). Esistono due modi per implementare il pattern utilizzando Cloud Storage, a seconda dell'origine dei dati: su Google Cloud oppure on-premise. In entrambi i casi, esegui la migrazione degli oggetti tra bucket di classi di archiviazione diverse, in genere da classi di archiviazione Standard a quelle con costi inferiori.

Diagramma che mostra la migrazione dei dati da un disco permanente a Standard Storage a Nearline Storage

Se i dati di origine vengono generati on-premise, l'implementazione è simile al seguente diagramma:

Diagramma che mostra la migrazione dei dati da on-premise a Cloud Storage tramite Cloud Interconnect

In alternativa, puoi modificare la classe di archiviazione degli oggetti in un bucket utilizzando le regole del ciclo di vita degli oggetti per automatizzare la modifica della classe degli oggetti.

Mantenimento dello stesso indirizzo IP per le istanze private

Un pattern comune è mantenere una singola istanza di gestione di una VM. Se è necessario sostituire la VM, la sostituzione deve apparire come se fosse la VM originale. Di conseguenza, l'indirizzo IP che i client utilizzano per connettersi alla nuova istanza dovrebbe rimanere invariato.

La configurazione più semplice consiste nell'impostare un gruppo di istanze gestite che mantiene esattamente un'istanza. Questo gruppo di istanze gestite è integrato con un bilanciatore del carico interno (privato) che garantisce che lo stesso indirizzo IP venga utilizzato per gestire l'istanza, indipendentemente dal fatto che si tratti dell'immagine originale o di una sostitutiva.

Partner tecnologici

Google ha un solido ecosistema di partner che supporta casi d'uso di backup e RE con Google Cloud. In particolare, vediamo clienti che utilizzano le soluzioni dei partner per:

  • Esegui il backup dei dati da on-premise a Google Cloud. In questi casi, Cloud Storage è integrato come destinazione di archiviazione per la maggior parte delle piattaforme di backup on-premise. Puoi usare questo approccio per sostituire nastri e altre appliance di archiviazione.
  • Implementa un piano di RE che va da on-premise a Google Cloud. I nostri partner possono contribuire a eliminare i data center secondari e a utilizzare Google Cloud come sito di RE.
  • Implementa RE e backup per carichi di lavoro basati su cloud.

Per ulteriori informazioni sulle soluzioni dei partner, consulta la pagina Partner sul sito web di Google Cloud.

Passaggi successivi