Coerenza
La coerenza fornisce un equilibrio tra la disponibilità degli oggetti e la loro coerenza in diversi nodi e siti storage. È possibile modificare la coerenza come richiesto dall'applicazione.
Per impostazione predefinita, StorageGRID garantisce la coerenza di lettura dopo scrittura per gli oggetti appena creati. Qualsiasi GET successivo a un PUT completato con successo sarà in grado di leggere i dati appena scritti. Le sovrascritture di oggetti esistenti, gli aggiornamenti dei metadati e le eliminazioni alla fine risultano coerenti.
Se si desidera eseguire operazioni a oggetti con una coerenza diversa, è possibile:
-
Specificare una coerenza perogni secchio .
-
Specificare una coerenza per Ogni operazione API.
-
Modificare la coerenza predefinita a livello di griglia eseguendo una delle seguenti operazioni:
-
In Grid Manager, vai a Configurazione > Sistema > Impostazioni di archiviazione > Coerenza predefinita del bucket.
-
.
Una modifica alla coerenza a livello di griglia si applica solo ai bucket creati dopo la modifica dell'impostazione. Per determinare i dettagli di una modifica, vedere il registro di controllo situato in /var/local/log
(cercare consistencyLevel).
-
Valori di coerenza
La coerenza influisce sul modo in cui i metadati utilizzati da StorageGRID per tracciare gli oggetti vengono distribuiti tra i nodi. La coerenza influisce sulla disponibilità degli oggetti per le richieste dei client.
È possibile impostare la coerenza per un bucket o un'operazione API su uno dei seguenti valori:
-
All: Tutti i nodi ricevono immediatamente i metadati degli oggetti o la richiesta non riesce.
-
Strong-global: garantisce la coerenza di lettura e scrittura per tutte le richieste dei client su tutti i siti. Quando la semantica del quorum è configurata, si applicano i seguenti comportamenti:
-
Consente la tolleranza ai guasti del sito per le richieste dei client quando le griglie hanno tre o più siti. Le griglie a due siti non avranno tolleranza ai guasti del sito.
-
Le seguenti operazioni S3 non riusciranno se un sito è inattivo:
-
DeleteBucketEncryption
-
PutBucketBranch
-
PutBucketEncryption
-
PutBucketVersioning
-
PutObjectLegalHold
-
PutObjectLockConfiguration
-
PutObjectRetention
-
Se necessario, puoi "configurare la semantica del quorum StorageGRID per una coerenza globale forte" .
-
-
Strong-site: I metadati degli oggetti vengono immediatamente distribuiti ad altri nodi del sito. Garantisce la coerenza di lettura dopo scrittura per tutte le richieste dei client all'interno di un sito.
-
Read-after-new-write: Fornisce coerenza lettura dopo scrittura per nuovi oggetti ed eventuale coerenza per gli aggiornamenti degli oggetti. Offre alta disponibilità e garanzie di protezione dei dati. Consigliato per la maggior parte dei casi.
-
Available: Fornisce una coerenza finale sia per i nuovi oggetti che per gli aggiornamenti degli oggetti. Per i bucket S3, utilizzare solo se necessario (ad esempio, per un bucket che contiene valori di log che vengono raramente letti o per operazioni HEAD o GET su chiavi che non esistono). Non supportato per i bucket S3 FabricPool.
Utilizzare la coerenza "Read-after-new-write" e "available"
Quando un'operazione HEAD o GET utilizza la coerenza "Read-after-new-write", StorageGRID esegue la ricerca in più passaggi, come segue:
-
Per prima cosa, cerca l'oggetto utilizzando una bassa coerenza.
-
Se la ricerca non riesce, ripete la ricerca al valore di coerenza successivo finché non raggiunge una coerenza equivalente al comportamento per strong-Global.
Se un'operazione HEAD o GET utilizza la coerenza "Read-after-new-write" ma l'oggetto non esiste, la ricerca degli oggetti raggiungerà sempre una coerenza equivalente al comportamento per strong-Global. Poiché questa coerenza richiede la disponibilità di più copie dei metadati degli oggetti in ogni sito, è possibile ricevere un elevato numero di errori del server interno 500 nel caso in cui due o più nodi storage nello stesso sito non fossero disponibili.
A meno che non si richiedano garanzie di coerenza simili a Amazon S3, è possibile evitare questi errori per le operazioni HEAD and GET impostando la coerenza su "disponibile". Quando un'operazione HEAD o GET utilizza la consistenza "disponibile", StorageGRID fornisce solo la consistenza finale. Non ritenta un'operazione non riuscita ad aumentare la coerenza, pertanto non richiede la disponibilità di più copie dei metadati degli oggetti.
specificare la coerenza per l'operazione API
Per impostare la coerenza per una singola operazione API, i valori di coerenza devono essere supportati per l'operazione ed è necessario specificare la coerenza nell'intestazione della richiesta. Nell'esempio riportato di seguito viene impostata la coerenza su "strong-Site" per un'operazione GetObject.
GET /bucket/object HTTP/1.1 Date: date Authorization: authorization name Host: host Consistency-Control: strong-site
|
È necessario utilizzare la stessa coerenza per entrambe le operazioni PutObject e GetObject. |
Specifica la coerenza per il bucket
Per impostare la coerenza per il bucket, è possibile utilizzare la richiesta StorageGRID"METTI la coerenza del bucket". In alternativa, è possibile "modificare la consistenza di un bucket" rivolgersi al responsabile del tenant.
Quando si imposta la consistenza per un secchio, tenere presente quanto segue:
-
L'impostazione della consistenza per un bucket determina la consistenza utilizzata per S3 operazioni eseguite sugli oggetti nel bucket o nella configurazione del bucket. Non influisce sulle operazioni sul bucket stesso.
-
La coerenza per una singola operazione API sovrascrive la coerenza per il bucket.
-
In generale, i bucket devono utilizzare la coerenza predefinita, "Read-after-new-write". Se le richieste non funzionano correttamente, modificare il comportamento del client dell'applicazione, se possibile. In alternativa, configurare il client per specificare la coerenza per ogni richiesta API. Impostare la consistenza a livello del bucket solo come ultima risorsa.
Come interagiscono coerenza e regole ILM per influenzare la protezione dei dati
Sia la scelta della coerenza che la regola ILM influiscono sulla protezione degli oggetti. Queste impostazioni possono interagire.
Ad esempio, la coerenza utilizzata durante la memorizzazione di un oggetto influisce sul posizionamento iniziale dei metadati degli oggetti, mentre il comportamento di acquisizione selezionato per la regola ILM influisce sul posizionamento iniziale delle copie degli oggetti. Poiché StorageGRID richiede l'accesso sia ai metadati dell'oggetto che ai relativi dati per soddisfare le richieste del client, la selezione di livelli di protezione corrispondenti per il comportamento di coerenza e acquisizione può offrire una migliore protezione iniziale dei dati e risposte di sistema più prevedibili.
Per le regole ILM sono disponibili le seguenti "opzioni di acquisizione"opzioni:
- Commit doppio
-
StorageGRID effettua immediatamente copie provvisorie dell'oggetto e restituisce il successo al cliente. Le copie specificate nella regola ILM vengono eseguite quando possibile.
- Rigoroso
-
Tutte le copie specificate nella regola ILM devono essere eseguite prima che l'operazione sia restituita al cliente.
- Bilanciato
-
StorageGRID tenta di eseguire tutte le copie specificate nella regola ILM al momento dell'acquisizione; se ciò non è possibile, vengono create copie provvisorie e viene restituita al cliente l'avvenuta esecuzione. Le copie specificate nella regola ILM vengono eseguite quando possibile.
Esempio di interazione tra la regola coerenza e ILM
Supponiamo di avere una griglia a tre siti con la seguente regola ILM e la seguente coerenza:
-
Regola ILM: creare tre copie dell'oggetto, una nel sito locale e una in ciascun sito remoto. Utilizzare un comportamento di acquisizione rigoroso.
-
Coerenza: Strong-global (i metadati degli oggetti vengono distribuiti immediatamente su più siti).
Quando un client memorizza un oggetto nella griglia, StorageGRID esegue tutte e tre le copie dell'oggetto e distribuisce i metadati a più siti prima di restituire l'esito positivo al client.
L'oggetto è completamente protetto contro la perdita al momento dell'acquisizione corretta del messaggio. Ad esempio, se il sito locale viene perso poco dopo l'acquisizione, copie sia dei dati dell'oggetto sia dei metadati dell'oggetto sono ancora presenti nei siti remoti. L'oggetto è completamente recuperabile dagli altri siti.
Se invece si utilizzasse la stessa regola ILM e la coerenza del sito forte, il client potrebbe ricevere un messaggio di successo dopo che i dati dell'oggetto sono stati replicati nei siti remoti, ma prima che i metadati dell'oggetto vengano distribuiti lì. In questo caso, il livello di protezione dei metadati degli oggetti non corrisponde al livello di protezione dei dati degli oggetti. Se il sito locale viene perso subito dopo l'acquisizione, anche i metadati dell'oggetto vengono persi. L'oggetto non può essere recuperato.
L'interrelazione tra coerenza e regole ILM può essere complessa. Contattare NetApp per assistenza.