Replica degli oggetti in IBM Cloud® Object Storage

La replica consente di definire regole per la copia automatica e asincrona di oggetti da un bucket di origine a un bucket di destinazione dello stesso account. Inoltre, è possibile copiare gli oggetti da un bucket a un altro bucket in account diversi.

Cos'è la replica?

La replica copia gli oggetti appena creati e gli aggiornamenti degli oggetti da un bucket di origine a un bucket di destinazione.

  • Solo i nuovi oggetti o le nuove versioni degli oggetti esistenti (creati dopo l'aggiunta della regola di replica al bucket) vengono copiati nel bucket di destinazione. Gli oggetti esistenti possono essere replicati copiandoli su se stessi, creando una nuova versione replicata.
  • I metadati dell'oggetto sorgente vengono applicati all'oggetto replicato.
  • La replica bidirezionale tra due bucket richiede che le regole siano attive su entrambi i bucket.
  • I filtri (composti da prefissi e/o tag) possono essere usati per definire l'ambito della regola di replica in modo che si applichi solo a un sottoinsieme di oggetti. È possibile definire più regole in un singolo criterio e queste regole possono specificare destinazioni diverse. In questo modo, oggetti diversi dello stesso bucket possono essere replicati su destinazioni diverse.

Perché usare la replica?

  • Conservare una copia dei dati in un bucket in una posizione geografica diversa.
  • Soddisfate le norme di conformità per la sovranità dei dati definendo regole di replica che memorizzano le repliche solo nelle posizioni consentite.
  • La replica conserva i metadati degli oggetti, come l'ora dell'ultima modifica, l'ID della versione e così via.
  • Gestire la classe di archiviazione e i criteri di ciclo di vita degli oggetti replicati indipendentemente dall'origine, definendo una classe di archiviazione e/o regole di ciclo di vita diverse per il bucket di destinazione. Allo stesso modo, è possibile memorizzare le repliche in un bucket in un'istanza di servizio separata o persino in un account IBM Cloud e controllare in modo indipendente l'accesso alle repliche.

Come iniziare con la replica

Per iniziare, è necessario soddisfare alcuni prerequisiti:

  • Impostare il ruolo della piattaforma Writer o Manager sul bucket di origine, oppure un ruolo personalizzato con le azioni di replica appropriate (come cloud-object-storage.bucket.put_replication).
  • Non è necessario avere accesso al bucket di destinazione, ma è necessario avere ruoli di piattaforma sufficienti per creare nuovi criteri IAM che consentano al bucket di origine di scrivere sul bucket di destinazione.
  • Il bucket di destinazione non deve avere un firewall del bucket legacy abilitato, ma può utilizzare restrizioni basate sul contesto.
  • Gli oggetti crittografati con SSE-C non possono essere replicati, anche se la crittografia gestita(SSE-KMS)come Key Protect è pienamente compatibile con la replica.
  • Gli oggetti in stato di archiviazione non possono essere replicati.
  • Se i bucket di origine e di destinazione si trovano in account diversi di IBM, assicurarsi di creare i bucket in ciascun account.
  • Abilitare il versioning su entrambi i bucket di origine e di destinazione.

Poiché il versionamento è un requisito per la replica, è impossibile replicare gli oggetti nei bucket configurati con un criterio Immutable Object Storage.

Utilizzo di un account IBM

Per replicare gli oggetti tra i bucket dello stesso account IBM, procedere come segue:

  1. Dopo essersi spostati sul bucket di origine scelto, fare clic sulla scheda Configurazione.
  2. Cercare la voce Bucket replication e fare clic sul pulsante Setup replication.
  3. Selezionare l'origine della replica e fare clic su Avanti.
  4. Selezionare l'istanza e il bucket dai menu a discesa. In alternativa, selezionare il pulsante di opzione su No e incollare il CRN del bucket di destinazione.
  5. Fare clic sul pulsante Verifica autorizzazioni.

Ora è necessario concedere al bucket di origine Writer i permessi sul bucket di destinazione. Esistono diversi modi per farlo, ma il più semplice è quello di utilizzare IBM Cloud Shell e la CLI di IBM Cloud.

  1. Aprire un IBM Cloud Shell in una nuova finestra o scheda.
  2. Copiare il comando IBM Cloud CLI visualizzato nella console di archiviazione oggetti e incollarlo nella nuova shell.
  3. Torna alla finestra o alla scheda di configurazione del bucket e fai nuovamente clic sul pulsante Verifica autorizzazioni.

Ora si creerà una regola di replica.

  1. Assicurarsi che il pulsante di opzione Stato della regola sia impostato su Abilitato.
  2. Assegnare un nome e una priorità alla regola, oltre a eventuali filtri di prefisso o tag che limitino gli oggetti soggetti alla regola di replica.
  3. Fai clic su Done.

Utilizzo di diversi account IBM

Per replicare gli oggetti tra i bucket di diversi account IBM, procedere come segue:

  1. Impostare un criterio IAM sull'account di destinazione IBM. Per informazioni sulla creazione di un criterio IAM, vedere Cosa sono i criteri IAM e chi può assegnarli.

  2. Individuare l'ID dell'account e l'ID dell'istanza di servizio in formato CRN nella pagina di configurazione del bucket.

  3. Utilizzando l'interfaccia utente IBM Cloud dell'account di destinazione, fare clic su Gestione>Accesso**(IAM)**.

  4. Fare clic su Autenticazione nel pannello di sinistra.

  5. Fare clic su Crea per creare una nuova politica IAM.

  6. Concedere la configurazione di una pagina di autorizzazione del servizio. Questa è la pagina in cui si viene reindirizzati dopo aver creato una nuova politica IAM.

  7. Selezionare Un altro account e fornire l'ID account dell'account di origine.

  8. Fornire l'accesso al servizio come Cloud Object Storage.

  9. Nell'Ambito di accesso, selezionare Risorse specifiche.

  10. Selezionare Istanza di servizio di origine e inserire l'ID dell'istanza di servizio per il bucket di origine.

  11. In Target, selezionare Cloud Object Storage per l'accesso al bucket sorgente.

  12. Per l'ambito di destinazione, selezionare Risorse specifiche> Istanza di servizio**.

  13. Selezionare l'ID dell'istanza di servizio dell'account di destinazione dal menu a discesa.

  14. Selezionare il ruolo Object Writer o Writer come richiesto.

    Il ruolo di Object writer è sufficiente per abilitare la replica.

Terminologia

Bucket di origine: Il bucket per il quale è configurato un criterio di replica. È l'origine degli oggetti replicati.

Bucket di destinazione: Il bucket definito come destinazione nel criterio di replica del bucket di origine. È la destinazione degli oggetti replicati. Anche detto secchio di "destinazione".

Replica: Il nuovo oggetto creato in un bucket di destinazione a seguito di una richiesta fatta a un bucket di origine.

Cosa viene replicato?

I nuovi oggetti creati utilizzando CopyObject, PutObject, o CompleteMultipartUpload vengono replicati dal bucket di origine al bucket di destinazione. Gli oggetti replicati ereditano i seguenti campi di metadati dall'oggetto di origine: Etag, Last Modified Time, Version ID, user-attributes, e Tags.

I marcatori di eliminazione vengono replicati se configurati dalla politica di replica.

Gli aggiornamenti ai tag di una versione vengono replicati dal bucket di origine al bucket di destinazione.

I seguenti non sono replicati:

  • Azioni avviate da eventi del ciclo di vita
  • Oggetti scritti direttamente nell'archivio
  • Oggetti ripristinati da un livello di archivio
  • Oggetti crittografati tramite SSE-C
  • ACL degli oggetti

Utilizzo della replica per la continuità operativa e il disaster recovery

La replica può essere utilizzata per garantire la continuità del servizio in caso di interruzione:

  • Assicurarsi che i bucket di origine e di destinazione si trovino in posizioni diverse.
  • Verificare che le ultime versioni degli oggetti siano sincronizzate tra i due bucket. Uno strumento come Rclone (il comando rclone check ) può essere utile per verificare la sincronia dalla riga di comando.
  • In caso di interruzione, il traffico di un'applicazione può essere reindirizzato al bucket di destinazione.

Coerenza e integrità dei dati

Mentre IBM Cloud Object Storage offre una forte coerenza per tutte le operazioni di IO dei dati, la configurazione dei bucket è eventualmente coerente. Dopo aver abilitato le regole di replica per la prima volta su un bucket, potrebbero essere necessari alcuni istanti affinché la configurazione si propaghi nel sistema e i nuovi oggetti inizino a essere replicati.

Gestione degli errori

Gli errori di replica possono verificarsi per molte ragioni, tra cui (ma non solo) configurazioni errate dei bucket, interruzioni del servizio e interazioni dell'utente con il bucket di destinazione.

Object Storage dispone di una resilienza integrata per gestire gli errori di replica. Quando si verifica un errore, Object Storage può riprovare per un massimo di 30 giorni. La frequenza dei tentativi può variare a seconda della natura dell'errore. Ad esempio, i tentativi falliti causati da rari errori di I/O possono essere ripetuti nel giro di poche ore, mentre quelli dovuti a configurazioni errate dei bucket da parte degli utenti possono essere ripetuti una volta al giorno. Se un errore non viene risolto entro 30 giorni, il sistema non effettua più tentativi automatici di risoluzione. È possibile elencare tutti gli errori a lungo termine utilizzando ListBucketReplicationFailures.

Se desideri riprovare a risolvere errori "stantii" risalenti a più di 30 giorni fa, puoi avviare un nuovo tentativo utilizzando il PutBucketReplicationFailureReattempt.

Cause dei guasti

Nella risposta dell'API " ListBucketReplicationFailures ", per ogni elemento di errore viene fornito il campo " SyncFailureCause ", che indica l'ultima causa nota dell'errore. La tabella seguente illustra le possibili cause:

Causa Spiegazione
Gestione delle versioni disabilitata sul bucket di destinazione La gestione delle versioni non è abilitata nel bucket di destinazione. Probabilmente l'utente ha sospeso il controllo delle versioni dopo aver configurato la replica.
Operazione di replica non autorizzata sul bucket di destinazione Il servizio Object Storage non è autorizzato a modificare il bucket di destinazione per conto dell'utente. Verifica se in IAM è ancora presente l'autorizzazione da servizio a servizio tra le risorse dei bucket di origine e di destinazione.
Bucket remoto non trovato Impossibile individuare il contenitore di destinazione. È possibile che l'utente abbia eliminato il bucket di destinazione. Verifica se il bucket di destinazione esiste ancora.
Fonte/bucket remoto non trovato o disabilitato Il secchio non è stato trovato oppure è inutilizzabile. Verifica se il bucket esiste ancora. In tal caso, contatta l'assistenza clienti.
Oggetto di destinazione non trovato Si è tentato di replicare una modifica ai metadati (ad esempio, blocco di tag/oggetto), ma l'oggetto di destinazione non esiste. Probabilmente l'utente ha eliminato l'oggetto dal bucket di destinazione prima che la modifica potesse essere replicata.
Oggetto locale non trovato Durante il tentativo di replica non è stato trovato l'oggetto di origine. Probabilmente l'utente ha eliminato l'oggetto di origine poco dopo averlo creato o modificato.
Il blocco degli oggetti non è abilitato nel bucket di destinazione Si è tentato di replicare le impostazioni di Object Lock su un oggetto, ma nel bucket di destinazione la funzione Object Lock non era abilitata.
La chiave di crittografia non è attiva oppure è stata eliminata Object Storage ha tentato di recuperare la chiave di crittografia da Key Protect (il bucket di origine ha SSE-KP/SSE-HPCS configurato), ma la chiave è stata eliminata.
Mancano le informazioni sull'endpoint dell'istanza KMS Impossibile recuperare l'endpoint del Key Management Service necessario per leggere la chiave di crittografia. Se l'errore persiste, contattare l'assistenza clienti.
Autorizzazioni insufficienti per la ricerca delle informazioni sull'endpoint KMS La risorsa "source bucket" non dispone delle autorizzazioni necessarie per interrogare l'endpoint del Key Management Service richiesto per leggere la chiave di crittografia. Verifica la politica di autorizzazione da servizio a servizio del tuo servizio IAM.
Errore interno Diversi problemi interni che impediscono la replica. Contattare l'assistenza clienti.

Azioni IAM

Ci sono nuove azioni IAM associate alla replica.

Azione IAM Ruolo
cloud-object-storage.bucket.get_replication Gestore, scrittore, lettore
cloud-object-storage.bucket.put_replication Gestore, Scrittore
cloud-object-storage.bucket.delete_replication Gestore, Scrittore
cloud-object-storage.bucket.get_replication_failures Gestore, scrittore, lettore
cloud-object-storage.bucket.put_replication_reattempt Gestore, Scrittore

Eventi Activity Tracker

La replica genera ulteriori eventi.

Azione evento Generato su Descrizione
cloud-object-storage.bucket-replication.create Bucket di origine Quando l'utente effettua una richiesta all'API di PutBucketReplication
cloud-object-storage.bucket-replication.read Bucket di origine Quando l'utente effettua una richiesta all'API di GetBucketReplication
cloud-object-storage.bucket-replication.delete Bucket di origine Quando l'utente effettua una richiesta all'API di DeleteBucketReplication
cloud-object-storage.bucket-replication-failures.list Bucket di origine Quando l'utente effettua una richiesta all'API di ListBucketReplicationFailures
cloud-object-storage.bucket-replication-failures.update Bucket di origine Quando l'utente effettua una richiesta all'API di PutReplicationFailureReattempt
cloud-object-storage.object-replication.sync Bucket di origine Quando Object Storage replica un oggetto dal bucket di origine
cloud-object-storage.object-replication.create Bucket di destinazione Quando Object Storage crea una nuova versione della replica nel bucket di destinazione
cloud-object-storage.object-replication.update Bucket di destinazione Quando Object Storage replica l'aggiornamento dei metadati su una replica esistente nel bucket di destinazione
cloud-object-storage.object-replication.delete Bucket di destinazione Quando Object Storage replica un marcatore di eliminazione sul bucket di destinazione

Per gli eventi cloud-object-storage.bucket-replication.create, i seguenti campi forniscono ulteriori informazioni:

Campo Descrizione
requestData.replication.num_sync_remote_buckets Il numero di bucket di destinazione specificati nelle regole di replica del bucket.
requestData.replication.failed_remote_sync I CRN dei bucket che non hanno superato la verifica della replica.

Quando la replica è attiva, le operazioni sugli oggetti possono generare le seguenti informazioni aggiuntive:

Campo Descrizione
requestData.replication.replication_throttled Indica se la replica dell'oggetto è stata ritardata sull'origine a causa di un meccanismo di limitazione.
requestData.replication.destination_bucket_id Il CRN del bucket di destinazione.
requestData.replication.sync_type Il tipo di operazione di sincronizzazione.
- content indica che i dati dell'oggetto e gli eventuali metadati sono stati scritti sulla destinazione.
- tag indica che sono stati replicati i tag dell'oggetto.
- retention indica che sono state replicate le impostazioni di conservazione del blocco oggetti.
- legal_hold indica che sono state replicate le impostazioni di conservazione legale del blocco oggetti.
- delete indica che è stato scritto un marcatore di eliminazione sulla destinazione.
responseData.replication.source_bucket_id Il CRN del bucket di origine.
responseData.replication.result I valori possono essere success, failure (indica un errore server), user (indica un errore utente).
responseData.replication.message Il messaggio di risposta HTTP (ad esempio OK).

È possibile tracciare un oggetto da quando viene scritto sull'origine fino a quando non viene scritto sulla destinazione. Ricercare l'ID richiesta associato alla scrittura dell'oggetto e visualizzare tre eventi:

  • Il PUT originale.
  • La richiesta di sincronizzazione dall'origine.
  • La richiesta PUT sulla destinazione.

Uno di questi tre elementi mancanti indica un errore.

Utilizzo e contabilità

Tutte le repliche sono oggetti e contribuiscono all'utilizzo come qualsiasi altro dato. La replica eseguita correttamente risulta in richieste PUT, GET e HEAD fatturabili, anche se la larghezza di banda utilizzata nel processo di replica non viene fatturata.

La replica genera metriche aggiuntive da utilizzare con IBM Cloud Monitoring:

  • ibm_cos_bucket_replication_sync_requests_issued
  • ibm_cos_bucket_replication_sync_requests_received

Interazioni

Gestione versioni

Il controllo versioni è obbligatorio per abilitare la replica. Dopo aver abilitato il controllo delle versioni sui bucket di origine e di destinazione e configurato la replica sul bucket di origine, potresti riscontrare i seguenti problemi:

  • Se tenti di disattivare il controllo delle versioni sul bucket di origine, Object Storage restituisce un errore. È necessario rimuovere la configurazione della replica prima di disabilitare il controllo delle versioni sul bucket di origine.
  • Se si disabilita il controllo delle versioni sul bucket di destinazione, la replica non riesce.

Blocco oggetti

Object Lock può essere abilitato sui bucket con la replica. Quando gli oggetti di origine vengono creati con Object Lock (conservazione e/o blocco legale) oppure se Object Lock viene aggiornato su oggetti esistenti, tale impostazione viene replicata nella destinazione.

Object Lock può essere replicato solo se è abilitato sul bucket di destinazione. Pertanto, abilitare Object Lock sul bucket di destinazione se è abilitato sul bucket di origine.

La tabella seguente illustra il comportamento quando i bucket di origine e di destinazione presentano configurazioni diverse di Object Lock:

Blocco oggetto di origine Blocco oggetto di destinazione Comportamento
Abilitato Abilitato Tutti gli stati di Object Lock dell'origine vengono replicati nella destinazione.

Se l'oggetto di origine viene creato senza Object Lock, alla replica potrebbe essere applicata la conservazione predefinita del bucket di destinazione.

La replica di Object Lock segue tutte le restrizioni di Object Lock di S3. Ad esempio, non è mai possibile ridurre il periodo di conservazione sulla replica in modalità di conformità se l'utente ha apportato modifiche in modo autonomo sulla destinazione.
Disabilitato Abilitato Gli oggetti di origine non possono avere Object Lock, pertanto gli stati di Object Lock non vengono mai propagati dall'origine alla destinazione.
Se il bucket di destinazione ha una conservazione predefinita impostata, questa viene applicata alle nuove repliche create.
Abilitato Disabilitato Gli oggetti sorgente creati con Object Lock non vengono replicati. Questi errori vengono riprovati da Object Storage e possono essere replicati una volta abilitato Object Lock sul bucket di destinazione. Anche eventuali aggiornamenti relativi alla conservazione dei dati (Object Lock) o al blocco legale (legal hold) sugli oggetti esistenti non possono essere replicati finché Object Lock non viene abilitato nella destinazione.

Gli oggetti di origine creati senza Object Lock possono comunque essere replicati.

Crittografia Key Protect

Gli oggetti di origine vengono crittografati utilizzando la chiave radice del bucket di origine, mentre le repliche vengono crittografate utilizzando la chiave radice del bucket di destinazione.

Configurazioni del ciclo di vita

Se su un bucket di destinazione è abilitata una politica di ciclo di vita, le azioni relative al ciclo di vita si basano sulla data di creazione originale dell’oggetto nella fonte, non sul momento in cui la replica diventa disponibile nel bucket di destinazione.

Immutable Object Storage

L'utilizzo delle politiche di conservazione è impossibile su un bucket con controllo delle versioni abilitato e poiché il controllo delle versioni è un requisito per la replica, è impossibile replicare gli oggetti in o da un bucket con Object Storage abilitato.

Firewall bucket legacy

I bucket che utilizzano i firewall legacy per limitare l'accesso in base agli indirizzi IP non sono in grado di utilizzare la replica, poiché i servizi in background che replicano gli oggetti non hanno indirizzi IP fissi e non possono passare il firewall.

Utilizzare invece restrizioni basate sul contesto per controllare l'accesso in base alle informazioni di rete.

Code Engine

Al momento, la configurazione della replica non attiva eventi di Code Engine, ma le operazioni di scrittura e cancellazione degli oggetti generano notifiche Object:Delete sia per il bucket di origine che Object:Write per quello di destinazione. Questi eventi sono contrassegnati dal campo " notifications.replication_type ", che indica se l'evento ha attivato una sincronizzazione o è stato attivato da una sincronizzazione.

Replica di oggetti esistenti

Una regola di replica può agire solo sugli oggetti scritti dopo che la regola è configurata e applicata a un bucket. Se ci sono oggetti esistenti in un bucket che devono essere replicati, i processi di replica devono essere resi consapevoli dell'esistenza degli oggetti. Ciò può essere facilmente realizzato utilizzando l'operazione PUT copy per copiare gli oggetti su se stessi.

Questo processo reimposta alcuni metadati degli oggetti, inclusi i timestamp di creazione. Ciò influisce sulle politiche relative al ciclo di vita e su qualsiasi altro servizio che utilizzi timestamp di creazione o modifica (come le reti di distribuzione dei contenuti). Assicurarsi che tutte le interruzioni che possono derivare dalla reimpostazione dei metadati dell'oggetto siano gestite in maniera appropriata.

Il processo prevede:

  1. Creazione di un elenco di tutti gli oggetti in un bucket che devono essere soggetti alle regole di replica,
  2. Iterazione su tale elenco, eseguendo un'operazione PUT copy su ciascun oggetto con l'origine identica alla destinazione della richiesta.

Questo esempio replica solo la nuova versione dell'oggetto creata dalla richiesta PUT copy. Per replicare tutte le versioni dell'oggetto, sarebbe necessario copiare anche ogni singola versione.

Il seguente esempio è scritto in Python, ma l'algoritmo può essere applicato in qualsiasi linguaggio di programmazione o contesto.

import os
import sys
import ibm_boto3
from ibm_botocore.config import Config
# Create client connection
cos = ibm_boto3.client("s3",
                       ibm_api_key_id=os.environ.get('IBMCLOUD_API_KEY'),
                       ibm_service_instance_id=os.environ['SERVICE_INSTANCE_ID'],
                       config=Config(signature_version="oauth"),
                       endpoint_url=os.environ['US_GEO']
                       )
# Define the bucket with existing objects for replication
bucket = os.environ['BUCKET']
def copy_in_place(BUCKET_NAME):
    print("Priming existing objects in " + bucket + " for replication...")
    paginator = cos.get_paginator('list_objects_v2')
    pages = paginator.paginate(Bucket=bucket)
    for page in pages:
        for obj in page['Contents']:
            key = obj['Key']
            print("  * Copying " + key + " in place...")
            try:
                headers = cos.head_object(
                    Bucket=bucket,
                    Key=key
                    )
                md = headers["Metadata"]
                cos.copy_object(
                    CopySource={
                        'Bucket': bucket,
                        'Key': key
                        },
                    Bucket=bucket,
                    Key=key,
                    TaggingDirective='COPY',
                    MetadataDirective='REPLACE',
                    Metadata=md
                    )
                print("    Success!")
            except Exception as e:
                print("    Unable to copy object: {0}".format(e))
    print("Existing objects in " + bucket + " are now subject to replication rules.")
copy_in_place(bucket)

Esempi di API REST

I seguenti esempi vengono mostrati utilizzando cURL per facilità d'uso. Le variabili di ambiente vengono utilizzate per rappresentare elementi specifici dell'utente come $BUCKET, $TOKEN e $REGION. Tieni presente che $REGION includerà anche tutte le specifiche del tipo di rete, quindi l'invio di una richiesta a un bucket in us-south utilizzando la rete privata richiederebbe l'impostazione della variabile su private.us-south.

Abilita replica su un bucket

La configurazione della replica viene fornita come XML nel corpo della richiesta. Le nuove richieste sovrascrivono eventuali regole di replica già presenti nel bucket.

Una configurazione di replica deve includere almeno una regola e può contenere un massimo di 1.000. Ciascuna regola identifica un sottoinsieme di oggetti da replicare filtrandoli nel bucket di origine. Per scegliere ulteriori sottoserie di oggetti da replicare, aggiungere una regola per ciascun sottoinsieme.

Per specificare una serie secondaria di oggetti nel bucket di origine a cui applicare una regola di replica, aggiungere l'elemento Filter come child dell'elemento Rule. È possibile filtrare gli oggetti in base a un prefisso chiave oggetto, una o più tag oggetto o entrambe. Quando si aggiunge l'elemento Filter nella configurazione, è necessario anche aggiungere i seguenti elementi: DeleteMarkerReplication, Status e Priority.

Intestazioni facoltative

Intestazioni facoltative
Intestazione Immettere Descrizione
Content-MD5 Stringa L'hash MD5 a 128 bit del payload, codificato in base64, utilizzato come controllo di integrità per garantire che il payload non sia stato alterato durante il trasferimento.
x-amz-checksum-crc32 Stringa Questa intestazione è il checksum Base64 codificato a 32 bit CRC32 dell'oggetto.
x-amz-checksum-crc32c Stringa Questa intestazione è il checksum Base64 codificato a 32 bit CRC32C dell'oggetto.
x-amz-checksum-crc64nvme Stringa Questa intestazione è il checksum Base64 codificato a 64 bit CRC64NVME dell'oggetto. Il checksum di CRC64NVME è sempre un checksum completo dell'oggetto.
x-amz-checksum-sha1 Stringa Questa intestazione è il digest Base64 codificato a 160 bit SHA1 dell'oggetto.
x-amz-checksum-sha256 Stringa Questa intestazione è il digest Base64 codificato a 256 bit SHA256 dell'oggetto.

Un'intestazione Content-MD5 o un'intestazione checksum (comprese x-amz-checksum-crc32, x-amz-checksum-crc32c, x-amz-checksum-crc64nvme, x-amz-checksum-sha1, o x-amz-checksum-sha256) è richiesta come controllo di integrità per il payload. Il corpo della richiesta deve contenere un blocco XML con il seguente schema:

Elemento Immettere Elemento secondario Predecessore Vincolo
ReplicationConfiguration Container Rule Nessuno Limite 1.
Rule Container ID, Status, Filter, DeleteMarkerReplication, Destination, Priority ReplicationConfiguration Limite 1000.
ID Stringa Nessuno Rule Devono contenere (a-z,A-Z0-9) e i seguenti simboli: !``_``.``*``'``(``)``-
Destination Container Bucket Rule Limite 1.
Bucket Stringa Nessuno Destination Il CRN del bucket di destinazione.
Priority Numero intero Nessuno Rule A ciascuna regola è associata una priorità. Ci possono essere casi in cui più regole possono essere applicabili a un oggetto caricato. In queste situazioni, l’object storage applica la regola con la priorità più alta al momento della replica di quell’oggetto. Pertanto, solo una singola regola di replica può essere applicata a qualsiasi oggetto, indipendentemente dal numero di regole nella politica di replica che possono essere una corrispondenza per l'oggetto. Notare che maggiore è il numero, maggiore è la priorità.
Status Stringa Nessuno Rule Specifica se la regola è abilitata. I valori validi sono Enabled o Disabled.
DeleteMarkerReplication Container Status Rule Limite 1.
Status Stringa Nessuno DeleteMarkerReplication Specifica se l'archivio oggetti replica gli indicatori di eliminazione. I valori validi sono Enabled o Disabled.
Filter Stringa Prefix, Tag, AND Rule Filtro che identifica il sottoinsieme di oggetti a cui si applica la regola di replica. Un Filter deve specificare esattamente un elemento child Prefix, Tag o And.
Prefix Stringa Nessuno Filter Un prefisso del nome chiave oggetto che identifica la sottoserie di oggetti a cui si applica la regola.
Tag Stringa Nessuno Filter Un contenitore per specificare una chiave tag e un valore. La regola si applica solo agli oggetti che hanno la tag nella relativa serie di tag.
And Stringa Nessuno Filter Un contenitore per specificare i filtri delle regole. I filtri determinano il sottoinsieme di oggetti a cui si applica la regola. Questo elemento è richiesto solo se si specifica più di un filtro.
Key Stringa Nessuno Tag La chiave tag.
Value Stringa Nessuno Tag Il valore della tag.

Questo esempio replica tutti i nuovi oggetti, ma non replica i marcatori di eliminazione.

curl -X "PUT" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?replication" \
     -H 'Authorization: bearer $TOKEN' \
     -H 'Content-MD5: exuBoz2kFBykNwqu64JZuA==' \
     -H 'Content-Type: text/plain; charset=utf-8' \
     -d $'<ReplicationConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
            <Rule>
              <ID>SimpleReplication</ID>
              <Priority>1</Priority>
              <Status>Enabled</Status>
              <DeleteMarkerReplication>
                <Status>Disabled</Status>
              </DeleteMarkerReplication>
              <Filter/>
              <Destination>
                <Bucket>$DESTINATION_CRN</Bucket>
              </Destination>
          	</Rule>
          </ReplicationConfiguration>'

Questo esempio replica tutti gli oggetti con una chiave (nome) che inizia con project_a/ nel bucket identificato con $DESTINATION_CRN_A, tutti gli oggetti con una chiave (nome) che inizia con project_b/ nel bucket identificato con $DESTINATION_CRN_B, e tutti gli oggetti che hanno un tag oggetto con la chiave Client e il valore ACME in un terzo bucket identificato con $DESTINATION_CRN_C, replicando in tutti i casi i marcatori di eliminazione.

Si supponga che i seguenti quattro oggetti vengano aggiunti al bucket di origine. Vengono replicati nei bucket di destinazione come descritto di seguito:

  1. project_a/foo.mp4
  2. project_a/bar.mp4
  3. project_b/baz.pdf
  4. project_b/acme.pdf. Questo quarto oggetto ha anche una tag oggetto con la chiave Client e il valore ACME.

A causa delle seguenti regole, gli oggetti 1 e 2 vengono replicati su $DESTINATION_CRN_A. L'oggetto 3 viene replicato su $DESTINATION_CRN_B. L'oggetto 4 viene replicato solo in perché $DESTINATION_CRN_C la regola con ID AcmeCorp ha un valore di priorità superiore rispetto alla regola con ID e ProjectB, pur soddisfacendo i requisiti di entrambe le regole, è soggetto solo alla prima.

curl -X "PUT" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?replication" \
     -H 'Authorization: bearer $TOKEN' \
     -H 'Content-MD5: exuBoz2kFBykNwqu64JZuA==' \
     -H 'Content-Type: text/plain; charset=utf-8' \
     -d $'<ReplicationConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
            <Rule>
              <ID>ProjectA</ID>
              <Priority>10</Priority>
              <Status>Enabled</Status>
              <DeleteMarkerReplication>
                <Status>Enabled</Status>
              </DeleteMarkerReplication>
              <Filter>
                <Prefix>project_a/</prefix>
              </Filter>
              <Destination>
                <Bucket>$DESTINATION_CRN_A</Bucket>
              </Destination>
          	</Rule>
            <Rule>
              <ID>ProjectB</ID>
              <Priority>5</Priority>
              <Status>Enabled</Status>
              <DeleteMarkerReplication>
                <Status>Enabled</Status>
              </DeleteMarkerReplication>
              <Filter>
                <Prefix>project_b/</prefix>
              </Filter>
              <Destination>
                <Bucket>$DESTINATION_CRN_B</Bucket>
              </Destination>
          	</Rule>
            <Rule>
              <ID>AcmeCorp</ID>
              <Priority>20</Priority>
              <Status>Enabled</Status>
              <DeleteMarkerReplication>
                <Status>Enabled</Status>
              </DeleteMarkerReplication>
              <Filter>
                <Tag>
                  <Key>Client</Key>
                  <Value>ACME</Value>
                </Tag>
              </Filter>
              <Destination>
                <Bucket>$DESTINATION_CRN_C</Bucket>
              </Destination>
          	</Rule>
          </ReplicationConfiguration>'

Una richiesta riuscita restituisce una risposta 200.

Visualizza la configurazione della replica per un bucket

curl -X "GET" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?replication" \
     -H 'Authorization: bearer $TOKEN'

Restituisce un corpo della risposta XML con lo schema appropriato:

<ReplicationConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <Rule>
    <ID>SimpleReplication</ID>
    <Status>ENABLED</Status>
    <DeleteMarkerReplication>
      <Status>DISABLED</Status>
    </DeleteMarkerReplication>
    <Destination>
      <Bucket>crn:v1:bluemix:public:cloud-object-storage:global:a/9978e07eXXXXXXXX66c89c428028654:ef1c725e-XXXX-4967-bcc1-734c03a2b846:bucket:replication-destination</Bucket>
    </Destination>
    <Priority>1</Priority>
    <Filter/>
  </Rule>
</ReplicationConfiguration>

Eliminare la configurazione di replica per un bucket

curl -X "DELETE" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?replication" \
     -H 'Authorization: bearer $TOKEN'

Una richiesta riuscita restituisce una risposta 204.

Elenco degli errori di replica per un bucket

Esempio di richiesta utilizzando curl

curl -X "GET" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?ibm-replication-failures" \
     -H 'Authorization: bearer $TOKEN'

Parametri di query facoltativi

Nome Immettere Descrizione
tipo di codifica Stringa Se in un nome di oggetto vengono utilizzati caratteri Unicode non supportati da XML, è possibile impostare questo parametro su url per codificare correttamente la risposta.
numero massimo di chiavi Stringa Limita il numero di errori da visualizzare nella risposta. Il valore predefinito e massimo è 1.000.
primo-tentativo-di-sincronizzazione-effettuato-prima Stringa Specifica il timestamp a partire dal quale deve iniziare l'elenco, in ordine cronologico inverso. L'ora corrisponde al momento in cui la replica è stata originariamente avviata (campo " " nella voce). Pertanto, l'elenco contiene tutti gli errori di replica risalenti almeno al timestamp specificato.
token di continuazione Stringa Specifica l'evento di errore a partire dal quale deve iniziare l'elenco, in ordine cronologico inverso. Questo viene utilizzato ai fini dell'impaginazione qualora siano presenti ulteriori voci oltre a quelle restituite nell'ultima richiesta di elenco.

Risposta di esempio

<ListReplicationFailureResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <Name>example</Name>
    <FirstSyncAttemptedBefore>2025-12-15T00:00:00.000Z</FirstSyncAttemptedBefore>
    <MaxKeys>10</MaxKeys>
    <IsTruncated>false</IsTruncated>
    <EncodingType>false</EncodingType>
    <KeyCount>2</KeyCount>
    <Contents>
        <Key>test-obj+*1765434016787</Key>
        <VersionId>00000000-0000-0000-0000-019b0c114413</VersionId>
        <SyncType>Content</SyncType>
        <FirstSyncAttempted>2025-12-11T06:20:16.787Z</FirstSyncAttempted>
        <LastSyncAttempted>2025-12-11T06:20:16.787Z</LastSyncAttempted>
        <SyncFailureCause>Versioning disabled on destination bucket</SyncFailureCause>
    </Contents>
    <Contents>
        <Key>test-obj+*1765434016786</Key>
        <VersionId>00000000-0000-0000-0000-019b0c114412</VersionId>
        <SyncType>Content</SyncType>
        <FirstSyncAttempted>2025-12-11T06:20:16.786Z</FirstSyncAttempted>
        <LastSyncAttempted>2025-12-11T06:20:16.786Z</LastSyncAttempted>
        <SyncFailureCause>Replication operation not authorized on target bucket</SyncFailureCause>
    </Contents>
</ListReplicationFailureResult>

Elementi di risposta

Nome Immettere Descrizione
ListReplicationFailureResult Container Tag di primo livello
Name Stringa Nome del bucket che viene elencato.
FirstSyncAttemptedBefore Stringa ISO-8601 data e ora della richiesta ?first-sync-attempted-before
MaxKeys Numero Numero massimo di chiavi richiesto per questo annuncio.
IsTruncated Booleano Se l'elenco corrente è stato troncato (ovvero, ci sono altri errori dopo l'ultimo elemento restituito in questo elenco). Se true, viene sempre fornito NextContinuationToken.
EncodingType Stringa Tipo di codifica richiesto in questo annuncio.
KeyCount Numero Numero di elementi difettosi riportati in questo elenco.
ContinuationToken Stringa Il token di continuazione specificato per questo annuncio.
NextContinuationToken Stringa Successivo token di continuazione da utilizzare per l'impaginazione nel caso in cui l'elenco corrente fosse stato troncato.

Pianificare un nuovo tentativo per gli errori di replica non risolti in un bucket

Questa operazione pianifica un nuovo tentativo per tutti gli errori di replica, compresi eventuali errori "obsoleti" risalenti a più di 30 giorni fa e che non sono più idonei per i tentativi automatici da parte del sistema. Gli errori di replica a lungo termine vengono gestiti con cadenza di 24 ore. L'invio di questa richiesta programma nuovi tentativi per gli errori non risolti nel ciclo che avrà inizio alla mezzanotte GMT successiva. Ad esempio, se viene inviata una richiesta all'indirizzo 2026-01-01T01:00:00Z, il primo momento in cui tali errori verranno elaborati è 2026-01-02T00:00:00Z. Se la richiesta va a buon fine, questo timestamp viene fornito anche nell'intestazione della risposta x-ibm-replication-reattempt-scheduled-time. Le richieste multiple che arrivano nello stesso giorno in GMT (ovvero, con lo stesso orario di esecuzione pianificato) sono idempotenti.

Ogni operazione non andata a buon fine viene riprovata una volta, con il massimo impegno: viene eseguita, ma non viene fornita alcuna garanzia sui tempi di esecuzione.

Esempio di richiesta utilizzando curl

curl -X "PUT" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?ibm-replication-reattempt" \
     -H 'Authorization: bearer $TOKEN'

Risposta di esempio

HTTP/1.1 204 No Content
Connection: close
...
x-ibm-replication-reattempt-scheduled-time: Fri, 12 Dec 2025 00:00:00 GMT

Esempi SDK

Gli esempi seguenti utilizzano gli SDK IBM Cloud Object Storage per Python e Node.js, sebbene l'implementazione del versioning degli oggetti debba essere pienamente compatibile con qualsiasi libreria o strumento S3-compatible che consenta l'impostazione di endpoint personalizzati. L'utilizzo di strumenti di terze parti richiede le credenziali HMAC per calcolare le firme AWS V4. Per ulteriori informazioni relative alle credenziali HMAC, consultare la documentazione.

Python

È possibile abilitare il controllo delle versioni utilizzando l'SDK IBM Cloud Object Storage per Python, ricorrendo alla sintassi client di basso livello.

Utilizzo di un client:

#!/usr/bin/env python3
import ibm_boto3
from ibm_botocore.config import Config
from ibm_botocore.exceptions import ClientError
# Define constants
API_KEY = os.environ.get('IBMCLOUD_API_KEY')
SERVICE_INSTANCE = os.environ.get('SERVICE_INSTANCE_ID')
ENDPOINT = os.environ.get('ENDPOINT')
BUCKET = "my-replication-bucket" # The bucket that will enable replication.
# Create resource client with configuration info pulled from environment variables.
cosClient = ibm_boto3.client("s3",
                         ibm_api_key_id=API_KEY,
                         ibm_service_instance_id=SERVICE_INSTANCE,
                         config=Config(signature_version="oauth"),
                         endpoint_url=ENDPOINT
                         )
response = cosClient.put_bucket_versioning(
    Bucket=BUCKET,
    ReplicationConfiguration={
        'Rules': [
            {
                'ID': 'string',
                'Priority': 123,
                'Filter': {
                    'Prefix': 'string',
                    'Tag': {
                        'Key': 'string',
                        'Value': 'string'
                    },
                    'And': {
                        'Prefix': 'string',
                        'Tags': [
                            {
                                'Key': 'string',
                                'Value': 'string'
                            },
                        ]
                    }
                },
                'Status': 'Enabled'|'Disabled',
                'Destination': {
                    'Bucket': 'string',
                },
                'DeleteMarkerReplication': {
                    'Status': 'Enabled'|'Disabled'
                }
            },
        ]
    }
)

Elenco delle versioni di un oggetto utilizzando lo stesso client:

resp = cosClient.list_object_versions(Prefix='some-prefix', Bucket=BUCKET)

Nota che le API Python sono molto flessibili e ci sono molti modi diversi per eseguire la stessa attività.

Node.js

Abilitazione del controllo delle versioni utilizzando l'IBM Cloud Object Storage SDK for Node.js:

const IBM = require('ibm-cos-sdk');
var config = {
    endpoint: '<endpoint>',
    apiKeyId: '<api-key>',
    serviceInstanceId: '<resource-instance-id>',
};
var cos = new IBM.S3(config);
var params = {
  Bucket: 'STRING_VALUE', /* required */
  ReplicationConfiguration: { /* required */
    Role: 'STRING_VALUE', /* required */
    Rules: [ /* required */
      {
        Destination: { /* required */
          Bucket: 'STRING_VALUE', /* required */
        },
        Status: Enabled | Disabled, /* required */
        Filter: {
          And: {
            Prefix: 'STRING_VALUE',
            Tags: [
              {
                Key: 'STRING_VALUE', /* required */
                Value: 'STRING_VALUE' /* required */
              },
              /* more items */
            ]
          },
          Prefix: 'STRING_VALUE',
          Tag: {
            Key: 'STRING_VALUE', /* required */
            Value: 'STRING_VALUE' /* required */
          }
        },
        ID: 'STRING_VALUE',
        Prefix: 'STRING_VALUE',
        Priority: 'NUMBER_VALUE',
        }
      }
    ]
  },
  ContentMD5: 'STRING_VALUE',
};
cos.putBucketReplication(params, function(err, data) {
  if (err) console.log(err, err.stack); // an error occurred
  else     console.log(data);           // successful response
});