Disponibilità e durabilità dei dati

Questa pagina spiega i concetti di disponibilità e durabilità in Cloud Storage:

  • Disponibilità: la possibilità 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 doppie regioni e le più regioni 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 saperne di più, consulta Classi di archiviazione disponibili.

  • Cloud Storage è progettato per garantire una durabilità annuale di almeno il 99,999999999% (undici 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 pezzi di 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 apportate automaticamente utilizzando 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.

    • La scrittura di oggetti in un bucket viene confermata come riuscita solo dopo che i dati sono stati archiviati in modo ridondante in almeno due zone di disponibilità diverse.

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

  • I bucket dual-region e multi-region archiviano i dati in modo ridondante in almeno due località geografiche separate.

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

    • Per le multiregioni, i data center specifici utilizzati per l'archiviazione dei dati vengono determinati da Cloud Storage in base alle necessità, ma si trovano all'interno del confine geografico della multiregione e sono separati da almeno 160 km. In questo modo, la ridondanza tra le regioni è garantita a un costo di archiviazione inferiore rispetto alle due regioni.

    • 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 riuscito dell'oggetto, ma prima che venga replicato per la ridondanza geografica, la coerenza forte di Cloud Storage garantisce che le versioni obsolete dell'oggetto non vengano pubblicate e che le sovrascritture successive non vengano ripristinate quando la regione torna disponibile.

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

    • Nell'improbabile caso di un'interruzione a livello di regione, ad esempio causata da un disastro naturale, i bucket con due regioni e più regioni rimangono disponibili, senza necessità di modificare i percorsi di archiviazione.

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

  • I dati con ridondanza locale, come quelli in un bucket zonale, offrono una durabilità annua del 99, 999999999% (11 nove) contro i guasti hardware come host, rack o unità. Tuttavia, poiché i dati non sono ridondanti nelle zone di disponibilità, potrebbero non essere più disponibili o andare persi definitivamente in caso di errore a livello di zona di disponibilità. Di conseguenza, lo spazio di archiviazione con ridondanza locale è più adatto ai dati che possono essere sostituiti o ricostruiti.

Ridondanza tra regioni

Mentre i modelli di archiviazione tradizionali spesso si basano su un approccio attivo-passivo con località geografiche "principali" e "secondarie", le regioni doppie e le multiregioni di Cloud Storage forniscono un'architettura attivo-attivo basata su un singolo bucket con ridondanza tra le regioni. In questo modo si semplifica il processo di recupero di emergenza 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 principale.

Cloud Storage comprende sempre lo stato attuale di un bucket e fornisce in modo trasparente gli oggetti da una regione disponibile in base alle esigenze. Di conseguenza, i bucket a due regioni e multiregionali sono progettati per avere un obiettivo di tempo di ripristino (RTO) pari a zero e gli errori regionali temporanei sono normalmente invisibili agli utenti; in caso di interruzione del servizio a livello regionale, i bucket a due regioni e multiregionali continuano automaticamente a pubblicare tutti i dati replicati tra le regioni.

Tuttavia, la ridondanza tra regioni si verifica in modo asincrono e tutti i dati che non vengono replicati tra regioni prima che una regione diventi non disponibile non sono accessibili finché la regione inattiva non torna online. I dati potrebbero andare persi nel caso molto improbabile 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 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à dual-region o multiregionali.

Replica turbo

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

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

Sebbene la ridondanza tra 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 proprio carico di lavoro.

Per saperne di più, consulta 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'attivazione della replica turbo su un bucket vengono replicate tra regioni alla velocità di replica predefinita.

    • La composizione di oggetti che utilizza qualsiasi oggetto di origine scritto 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 mantenere una copia dei tuoi 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 posizione di archiviazione, crittografia, accesso e classe di archiviazione. È particolarmente adatta per:

  • Sovranità dei dati: mantieni i dati in regioni geograficamente distanti.
  • Gestione di versioni di sviluppo e produzione separate: crea bucket e spazi dei nomi distinti, in modo che lo sviluppo non influisca sul tuo workload di produzione.
  • Condivisione dei dati: replica i dati in un bucket di proprietà di un fornitore o partner.
  • Aggregazione dei dati: combina i dati di bucket diversi in un unico bucket per eseguire carichi di lavoro di analisi.
  • Gestione di costi, sicurezza e conformità: mantieni i tuoi dati sotto diverse proprietà, classi di archiviazione e periodi di conservazione.

La replica tra bucket utilizza Storage Transfer Service per replicare gli oggetti e Pub/Sub per ricevere avvisi relativi alle modifiche ai bucket di origine e di destinazione. Puoi attivare la replica tra bucket sui nuovi bucket che crei e su quelli 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 con tassi di modifica più elevati o con 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.

  • 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 del timestamp (ad esempio, timeCreated e timeUpdated) non vengono conservati. Per informazioni dettagliate sulla conservazione dei metadati, consulta Trasferimenti tra bucket Cloud Storage.

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

  • 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 le istruzioni, vedi Creare trasferimenti.

Monitoraggio delle prestazioni

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

Ad esempio, se un oggetto ha generato 20 minuti di dati non validi dalle 9:00 alle 9:20 e un altro oggetto ha generato 10 minuti di dati non validi dalle 9:15 alle 9:25, ci sono due oggetti per il mese che non rispettano l'RPO. Il numero totale di minuti non conformi per il mese è di 25 minuti, perché dalle 9:00 alle 9:25 almeno un oggetto 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 console Google Cloud , il grafico Percentuale di minuti al di fuori dell'RPO ti consente di monitorare la percentuale di minuti non validi negli ultimi 30 giorni per il tuo bucket quando utilizzi la replica predefinita o la replica turbo all'interno di bucket multiregionali o a doppia regione. Questo indicatore del livello del servizio può essere utilizzato per monitorare la conformità del tempo di replica mensile del bucket. Allo stesso modo, la percentuale di oggetti fuori dal target monitora le repliche di oggetti che non si sono verificate entro l'RPO. Questo indicatore del livello di servizio può essere utilizzato per monitorare la conformità del volume di replica mensile del bucket. Per maggiori informazioni, consulta Monitoraggio di Cloud Storage e SLA di Cloud Storage.

Passaggi successivi