Disponibilità e durabilità dei dati

In questa pagina vengono illustrati i concetti di disponibilità e durabilità in Cloud Storage:

  • Disponibilità: la capacità di accedere ai dati immediatamente su richiesta.

  • Durabilità: protezione a lungo termine per garantire che i dati rimangano intatti e non danneggiati.

Le sezioni seguenti descrivono come Cloud Storage archivia i dati in modo ridondante, il comportamento di replica predefinito per le regioni doppie e le regioni multiple e le funzionalità avanzate come la replica turbo e la replica tra bucket.

Concetti fondamentali

  • La disponibilità mensile dei dati archiviati in Cloud Storage dipende dalla classe di archiviazione dei dati e dal tipo di località del bucket. Per ulteriori informazioni, vedi Classi di archiviazione disponibili.

  • Cloud Storage è progettato per garantire una durabilità annuale di almeno il 99,999999999% (11 9), indipendentemente dalla classe di archiviazione e dal tipo di località.

    • Per raggiungere questo obiettivo, Cloud Storage utilizza la codifica di cancellazione e archivia i dati in modo ridondante su più dispositivi.

    • Le scritture in Cloud Storage vengono confermate come riuscite solo dopo che i dati sono stati archiviati in modo ridondante.

    • I checksum vengono memorizzati e riconvalidati regolarmente per verificare in modo proattivo l'integrità di tutti i dati at-rest, nonché per rilevare la corruzione dei dati in transito. Se necessario, le correzioni vengono eseguite automaticamente utilizzando i dati ridondanti.

In che modo il tipo di località di un bucket influisce su disponibilità e durabilità

  • I bucket regionali archiviano i dati in modo ridondante in almeno due zone di disponibilità nella regione selezionata. Sono progettati per tollerare la perdita di una qualsiasi zona di disponibilità nella regione.

    • Le scritture di oggetti in un bucket vengono confermate come riuscite solo dopo che i dati sono stati archiviati in modo ridondante in almeno due zone di disponibilità diverse.

    • Nell'improbabile eventualità di un'interruzione della zona di disponibilità, ad esempio causata da una calamità naturale, i bucket regionali rimangono disponibili, senza la necessità di modificare i percorsi di archiviazione.

  • I bucket a due regioni e multiregionali archiviano i dati in modo ridondante in al meno due località geografiche separate.

    • Per le regioni doppie, seleziona le regioni specifiche in cui vengono archiviati gli oggetti.

    • Per le regioni multiple, i data center specifici utilizzati per l'archiviazione dei dati vengono determinati da Cloud Storage in base alle esigenze, ma si trovano all'interno del limite geografico della regione multipla e sono separati da almeno 160 km. In questo modo si ottiene la ridondanza tra le regioni a un costo di archiviazione inferiore rispetto alle regioni doppie.

    • Le scritture di oggetti in un bucket vengono confermate come riuscite solo dopo che i dati sono stati archiviati in modo ridondante in una regione iniziale, in almeno due zone di disponibilità diverse (come le scritture in un bucket regionale). I dati vengono quindi replicati in modo asincrono utilizzando la replica predefinita per fornire la ridondanza prevista tra le regioni.

      • Se una delle regioni in cui è archiviato un oggetto diventa non disponibile dopo il caricamento dell'oggetto, ma prima che venga replicato per la ridondanza geografica, la coerenza elevata di Cloud Storage garantisce che non vengano pubblicate versioni obsolete dell'oggetto e che le sovrascritture successive non vengano ripristinate quando la regione torna disponibile.

      • Come offerta premium, puoi abilitare facoltativamente la replica turbo sui bucket a due regioni per ottenere tempi di replica più rapidi e più prevedibili tra le regioni per i dati appena scritti.

    • Nell'improbabile eventualità di un'interruzione a livello regionale, ad esempio causata da una calamità naturale, i bucket a due regioni e multiregionali rimangono disponibili, senza la necessità di modificare i percorsi di archiviazione.

    • Per ottenere la ridondanza tra una coppia di regioni non disponibile come una regione a due regioni, valuta la possibilità di creare un bucket separato per ogni regione e di utilizzare i trasferimenti basati su eventi di Storage Transfer Service o la replica tra bucket per mantenere sincronizzati i bucket.

  • I dati con ridondanza locale, come i dati in un bucket zonale, offrono una durabilità annuale del 99, 999999999% (11 9) contro i guasti hardware come quelli di host, rack o unità. Tuttavia, poiché i dati non sono ridondanti tra le zone di disponibilità, potrebbero diventare non disponibili o persi definitivamente in caso di guasto della zona di disponibilità. Di conseguenza, l'archiviazione con ridondanza locale è più adatta ai dati che possono essere sostituiti o ricostruiti.

Ridondanza tra le regioni

Mentre i modelli di archiviazione tradizionali spesso si basano su un approccio attivo-passivo con località geografiche "primarie" e "secondarie", le regioni doppie e le regioni multiple di Cloud Storage forniscono un'architettura attivo-attivo basata su un singolo bucket con ridondanza tra le regioni. Questo semplifica la disaster recovery eliminando la necessità per gli utenti di replicare i dati da un bucket a un altro o di eseguire manualmente il failover a un bucket secondario in caso di tempi di inattività della regione primaria.

Cloud Storage comprende sempre lo stato attuale di un bucket e pubblica in modo trasparente gli oggetti da una regione disponibile, se necessario. Di conseguenza, i bucket a due regioni e multiregionali sono progettati per avere un RTO (Recovery Time Objective) pari a zero e gli errori regionali temporanei sono in genere invisibili agli utenti. In caso di interruzione a livello regionale, i bucket a due regioni e multiregionali continuano automaticamente a erogare tutti i dati replicati tra le regioni.

Tuttavia, la ridondanza tra le regioni si verifica in modo asincrono e tutti i dati che non completano la replica tra le regioni prima che una regione diventi non disponibile non sono accessibili finché la regione inattiva non torna online. I dati potrebbero andare persi nell'improbabile caso di distruzione fisica della regione.

La replica predefinita in Cloud Storage è progettata per fornire ridondanza tra le regioni per il 99,9% degli oggetti appena scritti entro un'ora e per il 100% degli oggetti appena scritti entro 12 ore. Gli oggetti appena scritti includono caricamenti, riscritture, copie e composizioni.

Cloud Storage offre anche una funzionalità di replica tra bucket che può essere utilizzata per replicare i dati tra bucket indipendenti per soddisfare esigenze di replica dei dati aggiuntive non soddisfatte dalle località a due regioni o a più regioni.

Replica turbo

La replica turbo fornisce una ridondanza più rapida tra le regioni per i dati nei bucket a due regioni, il che riduce il rischio di esposizione alla perdita di dati e contribuisce a supportare un servizio ininterrotto in seguito a un'interruzione a livello regionale. Se abilitata, la replica turbo è progettata per replicare il 100% degli oggetti appena scritti nelle due regioni che costituiscono una regione a due regioni entro l'RPO (Recovery Point Objective) di 15 minuti, indipendentemente dalle dimensioni dell'oggetto.

Tieni presente che, anche per la replica predefinita, la maggior parte degli oggetti completa la replica in pochi minuti.

Sebbene la ridondanza tra le regioni e la replica turbo contribuiscano a supportare gli sforzi di continuità operativa e ripristino di emergenza (BCDR), gli amministratori devono pianificare e implementare un'architettura BCDR completa adatta al loro carico di lavoro.

Per ulteriori informazioni, vedi la Guida passo passo alla progettazione del ripristino di emergenza per le applicazioni in Google Cloud.

Limitazioni

  • La replica turbo è disponibile solo per i bucket in due regioni.

  • La replica turbo non può essere gestita tramite l'API XML, inclusa la creazione di un nuovo bucket con la replica turbo abilitata.

  • Quando la replica turbo è abilitata su un bucket, possono essere necessari fino a 10 secondi prima che inizi a essere applicata agli oggetti appena scritti.

  • Le scritture di oggetti iniziate prima dell'abilitazione della replica turbo su un bucket vengono replicate tra le regioni alla velocità di replica predefinita.

    • La composizione di oggetti che utilizza gli oggetti di origine scritti utilizzando la replica predefinita nelle ultime 12 ore crea un oggetto composito che utilizza anche la replica predefinita.

Replica tra bucket

In alcuni casi, potresti voler conservare una copia dei dati in un secondo bucket. La replica tra bucket copia in modo asincrono gli oggetti nuovi e aggiornati da un bucket di origine a un bucket di destinazione.

La replica tra bucket differisce dalla replica predefinita e dalla replica turbo in quanto i dati esistono in due bucket indipendenti, ognuno con le proprie configurazioni, come località di archiviazione, crittografia, accesso e classe di archiviazione. È particolarmente adatta per:

  • Sovranità dei dati: mantieni i dati in regioni geograficamente distanti.
  • Mantenere versioni di sviluppo e produzione separate: crea bucket e spazi dei nomi distinti, in modo che lo sviluppo non influisca sul carico di lavoro di produzione.
  • Condividere i dati: replica i dati in un bucket di proprietà di un fornitore o di un partner.
  • Aggregare i dati: combina i dati di bucket diversi in un unico bucket per eseguire carichi di lavoro di analisi.
  • Gestire costi, sicurezza e conformità: mantieni i dati con proprietà, classi di archiviazione e periodi di conservazione diversi.

La replica tra bucket utilizza Storage Transfer Service per replicare gli oggetti e Pub/Sub per ricevere notifiche delle modifiche ai bucket di origine e di destinazione. Puoi abilitare la replica tra bucket sui nuovi bucket che crei e sui bucket esistenti.

Per i bucket in cui la velocità di modifica degli oggetti è inferiore a 3000 al secondo e gli oggetti sono inferiori a 1 GiB, la replica tra bucket richiede in genere da pochi minuti a decine di minuti, ma non è supportato alcun limite superiore specifico. Inoltre, i bucket che registrano velocità di modifica più elevate o che contengono oggetti più grandi possono prevedere ritardi di replica maggiori.

Per istruzioni sull'utilizzo della replica tra bucket, vedi Utilizzare la replica tra bucket.

Limitazioni

  • I nomi personalizzati non sono supportati per i job di replica tra bucket. Le richieste di creazione che contengono un valore per il campo name restituiscono un errore.

  • La replica tra bucket non è supportata per i bucket di spazi dei nomi gerarchici o per i bucket zonali.

  • Le eliminazioni di oggetti nel bucket di origine non vengono replicate nel bucket di destinazione.

  • Le configurazioni del ciclo di vita degli oggetti non vengono replicate.

  • Quando gli oggetti vengono replicati, i metadati dei timestamp (ad esempio, timeCreated e timeUpdated) non vengono conservati. Per informazioni dettagliate sulla conservazione dei metadati, vedi Trasferimenti tra bucket Cloud Storage.

  • Poiché la replica tra bucket può essere utilizzata per replicare i dati tra bucket che si trovano in qualsiasi Google Cloud località, le prestazioni della replica tra bucket variano in base alle località selezionate. Di conseguenza, la replica tra bucket non offre un RPO (Recovery Point Objective).

  • Gli oggetti già presenti nel bucket al momento della creazione di un job di replica non vengono replicati automaticamente. Vengono replicati solo gli oggetti nuovi e aggiornati. Per replicare gli oggetti esistenti, crea un job di trasferimento di Storage Transfer Service una tantum dal bucket esistente al nuovo bucket. Per istruzioni, vedi Creare trasferimenti.

Monitoraggio delle prestazioni

Cloud Storage monitora gli oggetti non replicati più vecchi nei bucket a due regioni e a più regioni utilizzando la replica predefinita o la replica turbo. Se un oggetto rimane non replicato per un periodo di tempo superiore all'RPO (Recovery Point Objective), viene considerato fuori dall'RPO. Ogni minuto in cui uno o più oggetti sono fuori dall'RPO viene conteggiato come un minuto "non valido".

Ad esempio, se un oggetto ha generato 20 minuti non validi dalle 9:00 alle 9:20 e un altro oggetto ha generato 10 minuti non validi dalle 9:15 alle 9:25, allora ci sono due oggetti per il mese che sono fuori dall'RPO. Il numero totale di minuti non validi per il mese è di 25 minuti, perché dalle 9:00 alle 9:25 c'era almeno un oggetto che non rispettava l'RPO.

  • Per i bucket che utilizzano la replica turbo, l'RPO per gli oggetti è di 15 minuti.

  • Per i bucket che utilizzano la replica predefinita, l'RPO per gli oggetti è di 12 ore.

    • Per i bucket che utilizzano la replica predefinita, gli oggetti vengono in genere replicati in un'ora o meno.

  • La replica tra bucket non fornisce un RPO.

Nella Google Cloud console, il grafico Percentuale di minuti fuori dall'RPO consente di monitorare la percentuale di minuti non validi durante gli ultimi 30 giorni per il bucket quando si utilizza la replica predefinita o la replica turbo all'interno di bucket a due regioni o a più regioni. Questo indicatore del livello di servizio può essere utilizzato per monitorare la conformità mensile del tempo di replica del bucket. Allo stesso modo, la percentuale di oggetti fuori dal target tiene traccia delle repliche di oggetti che non si sono verificate entro l'RPO. Questo indicatore del livello di servizio può essere utilizzato per monitorare la conformità mensile del volume di replica del bucket. Per ulteriori informazioni, vedi Monitoraggio di Cloud Storage e SLA di Cloud Storage.

Passaggi successivi