Che cos'è la replica cross-grid?
Suggerisci modifiche
PDF
La replica cross-grid è la replica automatica degli oggetti tra bucket S3 selezionati in due sistemi StorageGRID collegati in un "connessione a federazione di griglie". "Clone dell'account" è necessario per la replica cross-grid.
Workflow per la replica cross-grid
Il diagramma del flusso di lavoro riassume i passaggi per la configurazione della replica cross-grid tra bucket su due griglie.
Requisiti per la replica cross-grid
Se un account tenant dispone dell'autorizzazione Usa connessione federazione griglia per utilizzare uno o più account "connessioni a federazione di griglie", Un utente tenant con autorizzazione di accesso Root può creare bucket identici negli account tenant corrispondenti su ogni griglia. Questi bucket:
-
Deve avere lo stesso nome e la stessa regione
-
È necessario attivare la versione
-
È necessario che S3 Object Lock sia disattivato
-
Deve essere vuoto
Una volta creati entrambi i bucket, è possibile configurare la replica cross-grid per uno o entrambi i bucket.
Come funziona la replica cross-grid
È possibile configurare la replica cross-grid in modo che avvenga in una direzione o in entrambe le direzioni.
Replica in un'unica direzione
Se si attiva la replica cross-grid per un bucket su una sola griglia, gli oggetti aggiunti a quel bucket (il bucket di origine) vengono replicati nel bucket corrispondente sull'altra griglia (il bucket di destinazione). Tuttavia, gli oggetti aggiunti al bucket di destinazione non vengono replicati di nuovo nell'origine. Nella figura, la replica cross-grid è attivata per my-bucket Dalla griglia 1 alla griglia 2, ma non è attivata nell'altra direzione.
Replica in entrambe le direzioni
Se si attiva la replica cross-grid per lo stesso bucket su entrambe le griglie, gli oggetti aggiunti a entrambi i bucket vengono replicati nell'altra griglia. Nella figura, la replica cross-grid è attivata per my-bucket in entrambe le direzioni.
Cosa succede quando gli oggetti vengono acquisiti?
Quando un client S3 aggiunge un oggetto a un bucket con replica cross-grid attivata, si verifica quanto segue:
-
StorageGRID replica automaticamente l'oggetto dal bucket di origine al bucket di destinazione. Il tempo necessario per eseguire questa operazione di replica in background dipende da diversi fattori, tra cui il numero di altre operazioni di replica in sospeso.
Il client S3 può verificare lo stato di replica di un oggetto emettendo una richiesta DI oggetto GET o HEAD. La risposta include uno specifico StorageGRID
x-ntap-sg-cgr-replication-statusIntestazione della risposta, che avrà uno dei seguenti valori: Il client S3 può verificare lo stato di replica di un oggetto emettendo una richiesta DI oggetto GET o HEAD. La risposta include uno specifico StorageGRIDx-ntap-sg-cgr-replication-statusintestazione della risposta, che avrà uno dei seguenti valori:Griglia Stato della replica Origine
-
SUCCESSO: La replica è riuscita per tutte le connessioni alla rete.
-
PENDING: L'oggetto non è stato replicato in almeno una connessione di rete.
-
GUASTO: La replica non è in sospeso per nessuna connessione alla rete e almeno una ha avuto esito negativo con un errore permanente. Un utente deve risolvere l'errore.
Destinazione
REPLICA: L'oggetto è stato replicato dalla griglia di origine.
StorageGRID non supporta x-amz-replication-statusintestazione. -
-
StorageGRID utilizza i criteri ILM attivi di ogni griglia per gestire gli oggetti, proprio come qualsiasi altro oggetto. Ad esempio, l'oggetto A sulla griglia 1 potrebbe essere memorizzato come due copie replicate e conservato per sempre, mentre la copia dell'oggetto A replicata sulla griglia 2 potrebbe essere memorizzata utilizzando la codifica di cancellazione 2+1 ed eliminata dopo tre anni.
Cosa succede quando gli oggetti vengono cancellati?
Come descritto in "Eliminare il flusso di dati", StorageGRID può eliminare un oggetto per uno dei seguenti motivi:
-
Il client S3 invia una richiesta di eliminazione.
-
Un utente tenant Manager seleziona "Eliminare gli oggetti nel bucket" opzione per rimuovere tutti gli oggetti da un bucket.
-
Il bucket ha una configurazione del ciclo di vita che scade.
-
L'ultimo periodo di tempo nella regola ILM per l'oggetto termina e non sono stati specificati ulteriori posizionamenti.
Quando StorageGRID elimina un oggetto a causa di un'operazione Delete Objects (Elimina oggetti) nel bucket, della scadenza del ciclo di vita del bucket o della scadenza del posizionamento ILM, l'oggetto replicato non viene mai cancellato dall'altra griglia in una connessione a federazione di griglie. Tuttavia, i marker di eliminazione aggiunti al bucket di origine da S3 client Delete possono essere replicati nel bucket di destinazione.
Per capire cosa accade quando un client S3 elimina oggetti da un bucket che ha la replica cross-grid attivata, rivedere come i client S3 eliminano oggetti dai bucket che hanno la versione attivata, come segue:
-
Se un client S3 invia una richiesta di eliminazione che include un ID di versione, la versione dell'oggetto viene rimossa in modo permanente. Nessun marker di eliminazione aggiunto al bucket.
-
Se un client S3 invia una richiesta di eliminazione che non include un ID di versione, StorageGRID non elimina alcuna versione di oggetto. Al contrario, aggiunge un contrassegno di eliminazione al bucket. Il contrassegno DELETE fa sì che StorageGRID agisca come se l'oggetto fosse stato cancellato:
-
Una richiesta GET senza un ID versione non riesce con
404 No Object Found -
Una richiesta GET con un ID di versione valido avrà esito positivo e restituirà la versione dell'oggetto richiesta.
-
Quando un client S3 elimina un oggetto da un bucket con la replica cross-grid attivata, StorageGRID determina se replicare la richiesta di eliminazione nella destinazione, come segue:
-
Se la richiesta di eliminazione include un ID di versione, la versione dell'oggetto viene rimossa in modo permanente dalla griglia di origine. Tuttavia, StorageGRID non replica le richieste di eliminazione che includono un ID di versione, pertanto la stessa versione dell'oggetto non viene eliminata dalla destinazione.
-
Se la richiesta di eliminazione non include un ID di versione, StorageGRID può facoltativamente replicare il marker di eliminazione, in base alla configurazione della replica cross-grid per il bucket:
-
Se si sceglie di replicare i marker di eliminazione (impostazione predefinita), un marker di eliminazione viene aggiunto al bucket di origine e replicato nel bucket di destinazione. In effetti, l'oggetto sembra essere cancellato su entrambe le griglie.
-
Se si sceglie di non replicare i marker di eliminazione, un marker di eliminazione viene aggiunto al bucket di origine ma non viene replicato nel bucket di destinazione. In effetti, gli oggetti eliminati nella griglia di origine non vengono cancellati nella griglia di destinazione.
-
Nella figura, Replicate delete markers è stato impostato su Yes quando "la replica cross-grid è stata attivata". Le richieste di eliminazione per il bucket di origine che includono un ID di versione non elimineranno gli oggetti dal bucket di destinazione. Le richieste di eliminazione per il bucket di origine che non includono un ID di versione verranno visualizzate per eliminare gli oggetti nel bucket di destinazione.
|
|
Se si desidera mantenere le eliminazioni degli oggetti sincronizzate tra le griglie, creare le corrispondenti "Configurazioni del ciclo di vita S3" per i bucket su entrambe le griglie. |
Modalità di replica degli oggetti crittografati
Quando si utilizza la replica cross-grid per replicare oggetti tra griglie, è possibile crittografare singoli oggetti, utilizzare la crittografia bucket predefinita o configurare la crittografia a livello di griglia. È possibile aggiungere, modificare o rimuovere le impostazioni di crittografia predefinite del bucket o dell'intera griglia prima o dopo aver attivato la replica cross-grid per un bucket.
Per crittografare singoli oggetti, è possibile utilizzare SSE (crittografia lato server con chiavi gestite da StorageGRID) quando si aggiungono gli oggetti al bucket di origine. Utilizzare x-amz-server-side-encryption richiedi intestazione e specifica AES256. Vedere "Utilizzare la crittografia lato server".
|
|
L'utilizzo di SSE-C (crittografia lato server con chiavi fornite dal cliente) non è supportato per la replica cross-grid. L'operazione di acquisizione non riesce. |
Per utilizzare la crittografia predefinita per un bucket, utilizzare una richiesta di crittografia PUT bucket e impostare SSEAlgorithm parametro a. AES256. La crittografia a livello di bucket si applica a tutti gli oggetti acquisiti senza x-amz-server-side-encryption intestazione della richiesta. Vedere "Operazioni sui bucket".
Per utilizzare la crittografia a livello di griglia, impostare l'opzione Stored Object Encryption su AES-256. La crittografia a livello di griglia si applica a tutti gli oggetti che non sono crittografati a livello di bucket o che sono acquisiti senza x-amz-server-side-encryption intestazione della richiesta. Vedere "Configurare le opzioni di rete e degli oggetti".
|
|
SSE non supporta AES-128. Se l'opzione Stored Object Encryption è attivata per la griglia di origine utilizzando l'opzione AES-128, l'utilizzo dell'algoritmo AES-128 non verrà propagato all'oggetto replicato. L'oggetto replicato utilizzerà invece l'impostazione predefinita del bucket o della crittografia a livello di griglia della destinazione, se disponibile. |
Quando si determina come crittografare gli oggetti di origine, StorageGRID applica le seguenti regole:
-
Utilizzare
x-amz-server-side-encryptionacquisire l'intestazione, se presente. -
Se non è presente un'intestazione di acquisizione, utilizzare l'impostazione di crittografia predefinita del bucket, se configurata.
-
Se un'impostazione bucket non è configurata, utilizzare l'impostazione di crittografia a livello di griglia, se configurata.
-
Se non è presente un'impostazione a livello di griglia, non crittografare l'oggetto di origine.
Quando si determina come crittografare gli oggetti replicati, StorageGRID applica queste regole nel seguente ordine:
-
Utilizzare la stessa crittografia dell'oggetto di origine, a meno che tale oggetto non utilizzi la crittografia AES-128.
-
Se l'oggetto di origine non è crittografato o utilizza AES-128, utilizzare l'impostazione di crittografia predefinita del bucket di destinazione, se configurato.
-
Se il bucket di destinazione non dispone di un'impostazione di crittografia, utilizzare l'impostazione di crittografia a livello di griglia della destinazione, se configurata.
-
Se non è presente un'impostazione a livello di griglia, non crittografare l'oggetto di destinazione.
IL TAG PUT object e DELETE object non sono supportati
LE richieste DI TAGGING DEGLI oggetti PUT e DELETE non sono supportate per gli oggetti nei bucket che hanno la replica cross-grid attivata.
Se un client S3 invia una richiesta DI TAGGING DEGLI oggetti PUT o DELETE, 501 Not Implemented viene restituito. Il messaggio è Put(Delete) ObjectTagging is not available for buckets that have cross-grid replication configured.
Come vengono replicati gli oggetti segmentati
Le dimensioni massime dei segmenti della griglia di origine si applicano agli oggetti replicati nella griglia di destinazione. Quando gli oggetti vengono replicati in un'altra griglia, l'impostazione Maximum Segment Size (CONFIGURATION > System > Storage options) della griglia di origine viene utilizzata su entrambe le griglie. Ad esempio, supponiamo che la dimensione massima del segmento per la griglia di origine sia di 1 GB, mentre la dimensione massima del segmento della griglia di destinazione sia di 50 MB. Se si riceve un oggetto da 2 GB nella griglia di origine, tale oggetto viene salvato come due segmenti da 1 GB. Inoltre, verrà replicato nella griglia di destinazione come due segmenti da 1 GB, anche se la dimensione massima del segmento della griglia è di 50 MB.