Come StorageGRID utilizza il versioning degli oggetti
È possibile impostare lo stato di versione di un bucket se si desidera mantenere più versioni di ciascun oggetto. L'abilitazione della versione per un bucket può aiutare a proteggere dalla cancellazione accidentale di oggetti e consente di recuperare e ripristinare le versioni precedenti di un oggetto.
Il sistema StorageGRID implementa il controllo delle versioni con il supporto per la maggior parte delle funzionalità e con alcune limitazioni. StorageGRID supporta fino a 10,000 versioni di ciascun oggetto.
La versione degli oggetti può essere combinata con la gestione del ciclo di vita delle informazioni di StorageGRID (ILM) o con la configurazione del ciclo di vita del bucket S3. È necessario attivare esplicitamente il controllo delle versioni per ogni bucket. Quando la versione è abilitata per un bucket, a ogni oggetto aggiunto al bucket viene assegnato un ID di versione, che viene generato dal sistema StorageGRID.
L'utilizzo dell'autenticazione MFA (multi-factor Authentication) Delete non è supportato.
|
|
Il controllo delle versioni può essere attivato solo sui bucket creati con StorageGRID versione 10.3 o successiva. |
ILM e versione
I criteri ILM vengono applicati a ogni versione di un oggetto. Un processo di scansione ILM esegue una scansione continua di tutti gli oggetti e li rivaluti in base al criterio ILM corrente. Qualsiasi modifica apportata ai criteri ILM viene applicata a tutti gli oggetti precedentemente acquisiti. Sono incluse le versioni precedentemente ingerite se è abilitato il controllo delle versioni. La scansione ILM applica le nuove modifiche ILM agli oggetti acquisiti in precedenza.
Per gli oggetti S3 nei bucket abilitati per le versioni, il supporto per le versioni consente di creare regole ILM che utilizzano "tempo non corrente" come ora di riferimento (selezionare Sì per la domanda "Applica questa regola solo alle versioni precedenti degli oggetti?" in "Passaggio 1 della creazione guidata di una regola ILM"). Quando un oggetto viene aggiornato, le sue versioni precedenti diventano non aggiornate. L'utilizzo di un filtro "tempo non corrente" consente di creare policy per ridurre l'impatto sullo storage delle versioni precedenti di oggetti.
|
|
Quando si carica una nuova versione di un oggetto utilizzando un'operazione di caricamento multiparte, l'ora non corrente per la versione originale dell'oggetto si riflette quando il caricamento multiparte è stato creato per la nuova versione, non quando il caricamento multiparte è stato completato. In casi limitati, il tempo non corrente per la versione originale potrebbe essere di ore o giorni prima del tempo per la versione corrente. |
Come il versioning degli oggetti utilizza la capacità di storage in StorageGRID
La quantità di spazio di storage utilizzata per il versioning degli oggetti dipende dal numero di volte in cui carichi un oggetto, dalle regole dei criteri ILM e dall'accumulo di versioni non correnti:
-
Quando il versioning è abilitato su un bucket, ogni versione di un oggetto viene memorizzata come un oggetto completo e separato. Se carichi un file da 1 GB cinque volte, StorageGRID memorizza 5 GB di dati raw (5 x 1 GB) per quell'oggetto.
-
La policy ILM viene valutata per ogni versione dell'oggetto. Ad esempio, se hai una regola ILM di replica a due copie, StorageGRID memorizza due copie replicate di ogni versione dell'oggetto (corrente e non corrente). Quando questa regola ILM viene applicata a un bucket con 10 versioni di un oggetto da 1 GB, vengono utilizzati 20 GB di storage fisico.
-
Senza una policy del ciclo di vita del bucket S3 o una regola ILM che prenda di mira le versioni non correnti, StorageGRID conserva tutte le vecchie versioni a tempo indeterminato e queste continuano a consumare storage. Questa è la causa più comune di una crescita inattesa dello storage nei bucket versionati.