Replica di oggetti per i BLOB in blocchi

La replicazione degli oggetti copia asincronamente i BLOB di blocchi tra un account di archiviazione di origine e un account di archiviazione di destinazione. Alcuni scenari supportati dalla replica di oggetti includono:

• Riduzione al minimo della latenza. La replica di oggetti può ridurre la latenza per le richieste di lettura consentendo ai client di usare i dati di un'area con prossimità fisica più stretta.
• Aumento dell'efficienza per i carichi di lavoro di calcolo. Con la replica di oggetti, i carichi di lavoro di calcolo possono elaborare gli stessi set di BLOB in blocchi in aree diverse.
• Ottimizzazione della distribuzione dei dati. È possibile elaborare o analizzare i dati in un'unica posizione e quindi replicare solo i risultati in aree aggiuntive.
• Ottimizzazione dei costi. Dopo aver replicato i dati, è possibile ridurre i costi spostandolo nel livello archivio usando i criteri di gestione del ciclo di vita.

Il diagramma seguente illustra come la replica di oggetti replichi i BLOB a blocchi da un account di archiviazione di origine in una regione verso account di destinazione in due regioni diverse.

Per informazioni su come configurare la replica di oggetti, vedere Configurare la replica di oggetti.

Prerequisiti e avvertenze per la replica di oggetti

La replica di oggetti richiede che siano abilitate anche le funzionalità di Azure Storage seguenti:

• Change feed: deve essere abilitato nell'account di origine. Per informazioni su come abilitare il feed di modifiche, vedere Enable e disabilitare il feed di modifiche.
• Controllo delle versioni BLOB: deve essere abilitato in entrambi gli account di origine e di destinazione. Per informazioni su come abilitare il controllo delle versioni, consultare Abilitare e gestire il controllo delle versioni dei BLOB.

L'abilitazione del feed di cambiamento e del versionamento dei blob può implicare costi aggiuntivi. Per altre informazioni, vedere la pagina dei prezzi Azure Storage.

La replica di oggetti è supportata per gli account di archiviazione General-purpose v2 e per gli account Premium per blob a blocchi. Entrambi gli account di origine e di destinazione devono essere account per utilizzo generico v2 o account BLOB in blocchi Premium. La replica di oggetti supporta solo BLOB in blocchi; i BLOB di accodamento e i BLOB di pagine non sono supportati.

La replica di oggetti è supportata per gli account crittografati con chiavi gestite da Microsoft o chiavi gestite dal cliente. Per altre informazioni sulle chiavi gestite dal cliente, vedere Chiavi gestite dal cliente per la crittografia di Azure Storage.

La replica di oggetti non è supportata per i BLOB nell'account di origine crittografati con una chiave fornita dal cliente. Per altre informazioni sulle chiavi fornite dal cliente, vedere Provide una chiave di crittografia in una richiesta di Blob storage.

Il failover gestito dal cliente non è supportato per l'origine o l'account di destinazione in un criterio di replica di oggetti.

La replica di oggetti non è ancora supportata negli account con uno spazio dei nomi gerarchico abilitato.

La replica di oggetti non è supportata per i BLOB caricati tramite api Data Lake Storage.

Funzionamento della replica di oggetti

La replica di oggetti copia in modo asincrono i BLOB in blocchi in un contenitore in base alle regole configurate. Il contenuto del BLOB, le versioni associate al BLOB e i metadati e le proprietà del BLOB vengono tutti copiati dal contenitore di origine al contenitore di destinazione.

Controllo delle versioni per i BLOB

Per la replica degli oggetti è necessario abilitare il controllo delle versioni dei BLOB sia nell'account di origine sia in quello di destinazione. Quando viene modificato un BLOB replicato nell'account di origine, viene creata una nuova versione del BLOB nell'account di origine che riflette lo stato precedente del BLOB, prima della modifica. La versione corrente nell'account di origine riflette gli aggiornamenti più recenti. Sia la versione corrente sia le versioni precedenti vengono replicate nell'account di destinazione. Per altre informazioni su come le operazioni di scrittura influiscono sulle versioni dei BLOB, vedere Controllo delle versioni nelle operazioni di scrittura.

Qualora nell'account di archiviazione siano in vigore criteri di replica degli oggetti, non è possibile disabilitare il versioning dei blob per tale account. Prima di disabilitare il controllo delle versioni dei BLOB, è necessario eliminare tutti i criteri di replica degli oggetti nell'account.

Eliminazione di un BLOB nell'account di origine

Quando un BLOB nell'account di origine viene eliminato, la versione corrente del BLOB diventa una versione precedente e non esiste più una versione corrente. Tutte le versioni precedenti esistenti del BLOB vengono mantenute. Questo stato viene replicato nell'account di destinazione. Per altre informazioni su come l'eliminazione delle operazioni influisce sulle versioni del BLOB, vedere Controllo delle versioni nelle operazioni di eliminazione.

Snapshot

La replica di oggetti non supporta gli snapshot dei BLOB. Gli snapshot di un BLOB nell'account di origine non vengono replicati nell'account di destinazione.

Tag indice del BLOB

La replica di oggetti supporta ora la copia di tag di indice dai BLOB di origine ai BLOB di destinazione. È possibile configurare questa funzionalità come parte di una regola di replica nuova o esistente. Per altre informazioni, vedere Configurare la replica di oggetti.

Suddivisione in livelli BLOB

La replica di oggetti è supportata quando gli account di origine e di destinazione si trovano in un livello online qualsiasi (ad accesso frequente, sporadico o saltuario). Gli account di origine e di destinazione potrebbero trovarsi in livelli diversi. Tuttavia, la replica di oggetti non riesce se un blob nell'account di origine o in quello di destinazione viene spostato nel livello archivio. Per altre informazioni sui livelli BLOB, vedere Livelli di accesso per i dati BLOB.

BLOB non modificabili

I criteri di immutabilità per Azure Blob Storage includono criteri di conservazione basati sul tempo e blocchi legali. Quando una politica di immutabilità è attiva sull'account di destinazione, la replica degli oggetti potrebbe essere influenzata. Per ulteriori informazioni sui criteri di immutabilità, vedere Archiviare dati blob critici per il business con archiviazione immutabile.

Se il contenitore di destinazione dispone di criteri di immutabilità a livello di contenitore, le modifiche apportate agli oggetti nel contenitore di origine, ad esempio aggiornamenti o eliminazioni, potrebbero comunque avere esito positivo. Tuttavia, queste modifiche potrebbero non riuscire a eseguire la replica nel contenitore di destinazione a causa della restrizione dell'immutabilità. Per altre informazioni sulle operazioni non consentite con un criterio di immutabilità con ambito di un contenitore, vedere Scenari con ambito a livello di contenitore.

Se la versione BLOB di un account di destinazione ha un criterio di immutabilità a livello di versione attivo, un'operazione di eliminazione o aggiornamento eseguita sulla versione BLOB del contenitore di origine corrispondente potrebbe avere esito positivo. Tuttavia, la replica dell'operazione nell'oggetto di destinazione ha esito negativo. Per altre informazioni sulle operazioni non consentite con un criterio di immutabilità con ambito di un contenitore, vedere Scenari con ambito a livello di versione.

Regole e criteri di replica di oggetti

Quando si configura la replica di oggetti, si creano criteri di replica che specificano l'account di origine storage e l'account di destinazione. I criteri di replica includono una o più regole che specificano un contenitore di origine e di destinazione e indicano quali BLOB di origine vengono replicati.

Dopo aver configurato la replica di oggetti, Azure Storage controlla periodicamente il feed di modifiche per l'account di origine e replica in modo asincrono tutte le operazioni di scrittura o eliminazione nell'account di destinazione. La latenza di replica dipende dalla dimensione del BLOB in blocchi da replicare.

Criteri di replica

Quando si configura la replica di oggetti, si creano criteri di replica nell'account di destinazione tramite il provider di risorse Azure Storage. Dopo che il criterio di replica è stato creato, Azure Storage assegna ad esso un ID criterio. È quindi necessario associare tale criterio di replica all'account di origine usando l'ID criterio. L'ID criterio negli account di origine e di destinazione deve essere lo stesso per consentire la replica.

Un account di origine può eseguire la replica in massimo due account di destinazione, con un criterio per ogni account di destinazione. Analogamente, un account potrebbe fungere da account di destinazione per non più di due criteri di replica.

Gli account di origine e di destinazione potrebbero trovarsi nella stessa area o in aree diverse. Possono risiedere anche nella stessa sottoscrizione o in sottoscrizioni diverse. Facoltativamente, gli account di origine e di destinazione potrebbero risiedere in tenant Microsoft Entra diversi. È possibile creare un solo criterio di replica per ogni coppia di account di origine/account di destinazione.

Regole di replica

Le regole di replica specificano come Azure Storage replica i BLOB da un contenitore di origine a un contenitore di destinazione. È possibile specificare fino a 1.000 regole di replica per ogni criterio di replica. Ogni regola di replica definisce un singolo contenitore di origine e di destinazione e ogni contenitore di origine e di destinazione può essere usato in una sola regola. Di conseguenza, un massimo di 1.000 contenitori di origine e 1.000 contenitori di destinazione possono partecipare a una singola politica di replica.

Dopo aver creato una regola di replica, i BLOB preesistenti vengono ignorati; solo i nuovi BLOB in blocchi aggiunti dopo la creazione della regola vengono copiati per impostazione predefinita. È possibile tuttavia specificare che vengono copiati i BLOB in blocchi nuovi ed esistenti. È anche possibile definire un ambito di copia personalizzato che copia tutti i BLOB in blocchi creati dopo un determinato periodo di tempo.

È anche possibile specificare uno o più filtri come parte di una regola di replica per filtrare i BLOB in blocchi per prefisso. Quando si specifica un prefisso, solo i BLOB corrispondenti al prefisso nel contenitore di origine vengono copiati nel contenitore di destinazione.

Devono esistere sia i contenitori di origine che di destinazione prima di poterli specificare in una regola. Dopo aver creato i criteri di replica, le operazioni di scrittura nel contenitore di destinazione non sono consentite. Qualsiasi tentativo di scrittura nel contenitore di destinazione non riesce e viene restituito il codice errore 409 (conflitto).

Per scrivere in un contenitore di destinazione con una regola di replica, è prima necessario disabilitare la replica. È possibile disabilitare la regola eliminandola per tale contenitore o rimuovendo l'intero criterio di replica.

Le operazioni di lettura ed eliminazione nel contenitore di destinazione sono consentite quando i criteri di replica sono attivi.

È possibile chiamare l'operazione Imposta livello BLOB su un BLOB nel contenitore di destinazione per poterlo spostare in un livello di archivio. Per ulteriori informazioni sul livello archivio, vedere Livelli di accesso per i dati BLOB.

File di definizione dei criteri

Un file JSON viene usato per definire un criterio di replica degli oggetti. È possibile ottenere il file di definizione dei criteri da un criterio di replica di oggetti esistente oppure è possibile creare un criterio di replica di oggetti caricando un file di definizione dei criteri.

File di definizione dei criteri di esempio

Nell'esempio seguente vengono impostati criteri di replica nell'account di destinazione con una regola. La regola è destinata ai BLOB con il prefisso b e specifica un tempo di creazione minimo per la replica. Ricordare di sostituire i valori tra parentesi angolari con valori personalizzati:

{
  "properties": {
    "policyId": "default",
    "sourceAccount": "/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
    "destinationAccount": "/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
    "rules": [
      {
        "ruleId": "",
        "sourceContainer": "<source-container>",
        "destinationContainer": "<destination-container>",
        "filters": {
          "prefixMatch": [
            "b"
          ],
          "minCreationTime": "2021-08-28T00:00:00Z"
        }
      }
    ]
  }
}

Specificare gli ID risorsa completi per gli account di origine e di destinazione

Quando si crea il file di definizione dei criteri, specificare gli ID risorsa Azure Resource Manager completi per le voci sourceAccount e destinationAccount, come illustrato nell'esempio nella sezione precedente. Per informazioni su come individuare l'ID risorsa per un account storage, vedere Get the resource ID for a storage account.

L'ID risorsa completo è nel formato seguente:

/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>

Il file di definizione dei criteri in precedenza richiedeva solo il nome dell'account, anziché l'ID risorsa completo per l'account storage. Con l'introduzione della proprietà di sicurezza AllowCrossTenantReplication nella versione 2021-02-01 dell'API REST del provider di risorse Azure Storage, è ora necessario fornire l'ID risorsa completo per tutti i criteri di replica degli oggetti creati quando la replica tra tenant non è consentita per gli account di archiviazione che fanno parte della politica di replica. Azure Storage usa l'ID risorsa completo per verificare se gli account di origine e di destinazione si trovano nello stesso tenant. Per ulteriori informazioni su come disabilitare le politiche di replica tra tenant, vedere Prevent replication across Microsoft Entra tenants.

Anche se l'uso solo del nome dell'account è ancora supportato per la replica tra tenant, Microsoft consiglia di usare l'ID risorsa completo come procedura consigliata. Tutte le versioni precedenti dell'API REST del provider di risorse Azure Storage usano il percorso completo dell'ID risorsa nei criteri di replica degli oggetti.

Nella tabella seguente viene illustrato come il comportamento dei criteri di replica differisce quando si usa un ID risorsa completo rispetto a un nome account. Il confronto dipende dal fatto che la replicazione tra tenant sia consentita per l'account di archiviazione.

Specificare gli ID dei criteri e delle regole

Nella tabella seguente vengono riepilogati i valori da usare per le voci policyId e ruleId nel file di definizione dei criteri in ogni scenario.

Impedire la replica tra tenant di Microsoft Entra

Un tenant di Microsoft Entra è un'istanza dedicata di Microsoft Entra ID che rappresenta un'organizzazione per la gestione di identità e accesso. Ogni sottoscrizione Azure ha una relazione di trust con un singolo tenant di Microsoft Entra. Tutte le risorse in una sottoscrizione, inclusi gli account storage, sono associate allo stesso tenant di Microsoft Entra. Per altre informazioni, vedere Che è Microsoft Entra ID?

Per impostazione predefinita, la replica tra tenant è disabilitata per i nuovi account creati a partire dal 15 dicembre 2023. Se i criteri di sicurezza richiedono di limitare la replica degli oggetti agli account storage che risiedono solo nello stesso tenant, è possibile impedire la replica tra tenant impostando una proprietà di sicurezza, la proprietà AllowCrossTenantReplication (anteprima). Quando si disabilita la replica di oggetti tra tenant per un account storage, Azure Storage impone un requisito aggiuntivo. Per i criteri di replica degli oggetti che usano questo account storage come origine o destinazione, entrambi gli account devono appartenere allo stesso tenant di Microsoft Entra. Per altre informazioni su come impedire la replica di oggetti tra tenant per un account di archiviazione, vedere Prevent object replication across Microsoft Entra tenants (Impedire la replica di oggetti nei tenant di Microsoft Entra).

Per impedire la replica di oggetti tra tenant per un account storage, impostare la proprietà AllowCrossTenantReplication su false. Se l'account storage non partecipa attualmente ad alcun criterio di replica di oggetti tra tenant, l'impostazione della proprietà AllowCrossTenantReplication su false impedisce una configurazione futura dei criteri di replica di oggetti tra tenant con questo account storage come origine o destinazione.

Se l'account storage partecipa attualmente a uno o più criteri di replica di oggetti multi-tenant, l'impostazione della proprietà AllowCrossTenantReplication su false non è consentita. È necessario eliminare i criteri tra tenant esistenti prima di non consentire la replica tra tenant.

Per impostazione predefinita, la proprietà AllowCrossTenantReplication è impostata su false per un account storage creato a partire dal 15 dicembre 2023. Per gli account storage creati prima del 15 dicembre 2023, quando il valore della proprietà AllowCrossTenantReplication per un account storage è null o true, gli utenti autorizzati possono quindi configurare i criteri di replica di oggetti tra tenant con questo account come origine o destinazione. Per altre informazioni su come configurare i criteri tra tenant, vedere Configurare la replica degli oggetti per i BLOB in blocchi.

È possibile usare Azure Policy per controllare un set di account storage per assicurarsi che la proprietà AllowCrossTenantReplication sia impostata per impedire la replica di oggetti tra tenant. È anche possibile usare Azure Policy per applicare la governance per un set di account storage. Ad esempio, è possibile creare un criterio con l'effetto deny per impedire a un utente di creare un account storage in cui la proprietà AllowCrossTenantReplication è impostata su true o dalla modifica di un account di storage esistente per modificare il valore della proprietà in true.

Metriche di replica

La replica di oggetti supporta due metriche per fornire informazioni dettagliate sullo stato di avanzamento della replica:

• Operazioni in sospeso per la replica: numero totale di operazioni in sospeso per la replica dall'account di origine all'account di destinazione, emesso per ciascun bucket temporale.
• Byte in sospeso per la replica: somma dei byte in sospeso per la replica dall'account di archiviazione di origine all'account di archiviazione di destinazione generati per unità di tempo

Ognuna delle metriche elencate in precedenza può essere visualizzata con la dimensione dei bucket di tempo. Questa suddivisione consente di acquisire informazioni dettagliate sul numero di byte o operazioni in sospeso per la replica per intervalli di tempo, come indicato di seguito.

• 0-5 minuti
• 5-10 minuti
• 10-15 minuti
• 15-30 minuti
• 30 minuti a 2 ore
• 2-8 ore
• 8-24 ore
• >24 ore

L'immagine di esempio seguente mostra la metrica delle operazioni e dei byte in sospeso per i sette giorni precedenti:

È possibile abilitare le metriche di replica nell'account di origine per il monitoraggio dei byte in sospeso e delle operazioni in sospeso. Per altre informazioni, vedere Configurare le metriche di replica.

Stato della replica

È possibile controllare lo stato della replica per un BLOB nell'account di origine. Per altre informazioni, vedere Controllare lo stato di replica di un BLOB.

Se lo stato di replica per un BLOB nell'account di origine indica un errore, esaminare le possibili cause seguenti:

• Assicurarsi che i criteri di replica degli oggetti siano configurati nell'account di destinazione.
• Verificare che l'account di destinazione esista ancora.
• Verificare che il contenitore di destinazione esista ancora.
• Verificare che il contenitore di destinazione non venga eliminato e che non sia in corso l'eliminazione. L'eliminazione di un contenitore può richiedere fino a 30 secondi.
• Verificare che il contenitore di destinazione partecipi ancora ai criteri di replica degli oggetti.
• Se il BLOB di origine viene crittografato con una chiave fornita dal cliente come parte di un'operazione di scrittura, la replica degli oggetti non riesce. Per altre informazioni sulle chiavi fornite dal cliente, vedere Provide una chiave di crittografia in una richiesta di Blob storage.
• Controllare se il BLOB di origine o di destinazione viene spostato nel livello archivio. I BLOB archiviati non possono essere replicati tramite la replica di oggetti. Per ulteriori informazioni sul livello archivio, vedere Livelli di accesso per i dati BLOB.
• Verificare che il contenitore di destinazione o il blob non sia protetto da una politica di immutabilità. Tenete presente che un contenitore o un BLOB può ereditare un criterio di immutabilità dal suo elemento padre. Per ulteriori informazioni sui criteri di immutabilità, vedere Panoramica dello storage non modificabile per i dati BLOB.

Supporto delle funzionalità

Il supporto per questa funzionalità potrebbe essere influenzato dall'abilitazione di Data Lake Storage Gen2, del protocollo NFS (Network File System) 3.0 o del protocollo SFTP (SSH File Transfer Protocol). Se è stata abilitata una di queste funzioni, consulta Supporto delle funzionalità di Blob Storage negli account di Azure Storage per valutare il supporto della funzione.

Fatturazione

Non è previsto alcun costo per configurare la replica degli oggetti, inclusa l'attività di abilitazione del feed di modifiche, l'abilitazione del controllo delle versioni e l'aggiunta di criteri di replica. Tuttavia, la replica di oggetti comporta costi per le transazioni di lettura e scrittura sugli account di origine e di destinazione. Gli addebiti in uscita per la replica dei dati dall'account di origine all'account di destinazione implicano un costo aggiuntivo, come avviene per i costi di lettura durante l'elaborazione del change feed.

Ecco una suddivisione dei costi. Per trovare il prezzo di ogni componente di costo, consultare Prezzi di Azure Blob Storage.

¹ Nell'account di origine, se il livello di un blob o di una versione è invariato, vengono fatturati i blocchi univoci di dati presenti in quel blob e nelle sue versioni. Vedere Prezzi e fatturazione per il controllo delle versioni dei BLOB. Nell'account di destinazione, per una versione, vengono fatturati tutti i blocchi di una versione indipendentemente dal fatto che tali blocchi siano univoci.

² Questo include solo le versioni BLOB create dopo il completamento dell'ultima replica.

³ La replica di oggetti copia l'intera versione nella destinazione (non solo i blocchi univoci della versione). Questo trasferimento comporta il costo dell'uscita di rete. Visualizza prezzi di banda.

Passaggi successivi

• Configurare la replica di oggetti
• Impedire la replica di oggetti nei tenant di Microsoft Entra
• Versionamento dei Blob
• supporto per il feed di modifica in Azure Blob Storage