Replica di oggetti per i BLOB in blocchi
La replica di oggetti copia in modo asincrono i BLOB in blocchi tra un account di archiviazione di origine e uno 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. Una volta che i dati sono stati replicati, è possibile ridurre i costi spostandoli nel livello archivio usando i criteri di gestione del ciclo di vita.
Il diagramma seguente illustra in che modo la replica di oggetti replica i BLOB in blocchi da un account di archiviazione di origine in un'area ad account di destinazione in due aree 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 Archiviazione di Azure seguenti:
- Feed di modifiche: deve essere abilitato nell'account di origine. Per informazioni su come abilitare il feed di modifiche, vedere Abilitare e disabilitare il feed di modifiche.
- Controllo delle versioni blob: deve essere abilitato sia negli account di origine che in quello di destinazione. Per informazioni su come abilitare il controllo delle versioni, vedere Abilitare e gestire il controllo delle versioni dei BLOB.
L'abilitazione del feed di modifiche e del controllo delle versioni dei BLOB può comportare costi aggiuntivi. Per altre informazioni, vedere la pagina dei prezzi Archiviazione di Azure.
La replica di oggetti è supportata per gli account di archiviazione per utilizzo generico v2 e gli account BLOB in blocchi Premium. Sia gli account di origine che di destinazione devono essere account BLOB in blocchi per utilizzo generico v2 o 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 Archiviazione di Azure.
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 Fornire una chiave di crittografia in una richiesta all'archiviazione BLOB.
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 è supportata per i BLOB caricati tramite le API Data Lake Archiviazione Gen2.
Funzionamento della replica di oggetti
La replica degli 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.
Importante
Poiché i dati BLOB in blocchi vengono replicati in modo asincrono, l'account di origine e l'account di destinazione non vengono sincronizzati immediatamente. Attualmente non esiste alcun contratto di servizio per quanto tempo è necessario per replicare i dati nell'account di destinazione. È possibile controllare lo stato della replica nel BLOB di origine per determinare se la replica è stata completata. Per altre informazioni, vedere Controllare lo stato di replica di un BLOB.
Controllo delle versioni del BLOB
Per la replica degli oggetti è necessario abilitare il controllo delle versioni dei BLOB sia nell'account di origine che 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 che 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.
Se l'account di archiviazione ha criteri di replica degli oggetti in vigore, non è possibile disabilitare il controllo delle versioni 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 eliminare le operazioni influiscono sulle versioni del BLOB, vedere Controllo delle versioni nelle operazioni di eliminazione.
Snapshots
La replica degli oggetti non supporta gli snapshot di BLOB. Tutti gli snapshot di un BLOB nell'account di origine non vengono replicati nell'account di destinazione.
Tag indice del BLOB
La replica di oggetti non copia i tag di indice del BLOB di origine nel BLOB di destinazione.
Suddivisione in livelli BLOB
La replica degli oggetti è supportata quando gli account di origine e di destinazione hanno il livello di accesso frequente o sporadico. Gli account di origine e di destinazione possono avere livelli diversi. Tuttavia, la replica di oggetti avrà esito negativo se un BLOB nell'account di origine o di destinazione è stato 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 Archiviazione BLOB di Azure includono criteri di conservazione basati sul tempo e blocchi legali. Quando un criterio di immutabilità è attivo sull'account di destinazione, la replica degli oggetti potrebbe essere interessata. Per altre informazioni sui criteri di immutabilità, vedere Archiviare dati BLOB critici per l'azienda con archiviazione non modificabile.
Se un criterio di immutabilità a livello di contenitore è attivo per un contenitore nell'account di destinazione e un oggetto nel contenitore di origine viene aggiornato o eliminato, l'operazione sul contenitore di origine può avere esito positivo, ma la replica di tale operazione nel contenitore di destinazione avrà 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 contenitore.
Se un criterio di immutabilità a livello di versione è attivo per una versione blob nell'account di destinazione e viene eseguita un'operazione di eliminazione o aggiornamento sulla versione blob nel contenitore di origine, l'operazione sull'oggetto di origine può avere esito positivo, ma la replica di tale operazione nell'oggetto di destinazione avrà 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 crea un criterio di replica che specifica l'account di archiviazione di origine e l'account di destinazione. Un criterio di replica include una o più regole che specificano un contenitore di origine e un contenitore di destinazione e indicano i BLOB in blocchi del contenitore di origine che verranno replicati.
Dopo aver configurato la replica di oggetti, Archiviazione di Azure controlla periodicamente il feed di modifiche per l'account di origine e replica in modo asincrono 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 Archiviazione di Azure. Dopo aver creato i criteri di replica, Archiviazione di Azure assegnargli 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 può fungere da account di destinazione per massimo due criteri di replica.
Gli account di origine e di destinazione possono 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 possono risiedere in tenant Microsoft Entra diversi. È possibile creare un solo criterio di replica per ogni coppia di account di origine/di destinazione.
Regole di replica
Le regole di replica specificano in che modo Archiviazione di Azure replica i BLOB da un contenitore di origine a un contenitore di destinazione. È possibile specificare fino a 1000 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, ovvero un massimo di 1000 contenitori di origine e 1000 contenitori di destinazione possono partecipare a un singolo criterio di replica.
Quando si crea una regola di replica, per impostazione predefinita vengono copiati solo i nuovi BLOB in blocchi aggiunti successivamente al contenitore di origine. È possibile specificare che i BLOB in blocchi nuovi ed esistenti vengono copiati oppure è possibile definire un ambito di copia personalizzato che copia i BLOB in blocchi creati da un'ora specificata.
È 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 verranno 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 per cui è configurata una regola di replica, è necessario eliminare la regola configurata per tale contenitore o rimuovere i criteri 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 in un BLOB nel contenitore di destinazione per spostarlo nel livello archivio. Per altre informazioni sul livello archivio, vedere Livelli di accesso per i dati BLOB.
Nota
La modifica del livello di accesso di un BLOB nell'account di origine non modifica il livello di accesso del BLOB nell'account di destinazione.
File di definizione dei criteri
I criteri di replica degli oggetti sono definiti dal file JSON. È possibile ottenere il file di definizione dei criteri da un criterio di replica di oggetti esistente. È anche possibile creare criteri di replica di oggetti caricando un file di definizione dei criteri.
File di definizione dei criteri di esempio
L'esempio seguente definisce un criterio di replica nell'account di destinazione con una singola regola che corrisponde al prefisso b e imposta il tempo di creazione minimo per i BLOB da replicare. 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-028T00: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 di 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 di archiviazione, vedere Ottenere l'ID risorsa per un account di archiviazione.
L'ID risorsa completo è nel formato seguente:
/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>
Il file di definizione dei criteri richiedeva in precedenza solo il nome dell'account, anziché l'ID risorsa completo per l'account di archiviazione. Con l'introduzione della proprietà di sicurezza AllowCrossTenantReplication nella versione 2021-02-01 dell'API REST del provider di risorse Archiviazione di Azure, è ora necessario specificare l'ID risorsa completo per tutti i criteri di replica degli oggetti creati quando la replica tra tenant non è consentita per un account di archiviazione che partecipa ai criteri di replica. Archiviazione di Azure usa l'ID risorsa completo per verificare se gli account di origine e di destinazione si trovano nello stesso tenant. Per altre informazioni sulla non autorizzazione dei criteri di replica tra tenant, vedere Impedire la replica nei tenant di Microsoft Entra.
Pur fornendo solo il nome dell'account è ancora supportato quando la replica tra tenant è consentita per un account di archiviazione, Microsoft consiglia sempre di fornire l'ID risorsa completo come procedura consigliata. Tutte le versioni precedenti dell'API REST del provider di risorse Archiviazione di Azure supportano l'uso del percorso completo dell'ID risorsa nei criteri di replica degli oggetti.
La tabella seguente descrive cosa accade quando si creano criteri di replica con l'ID risorsa completo specificato, rispetto al nome dell'account, negli scenari in cui la replica tra tenant è consentita o non consentita per l'account di archiviazione.
| Archiviazione identificatore dell'account nella definizione dei criteri | Replica tra tenant consentita | Replica tra tenant non consentita |
|---|---|---|
| ID risorsa completo | È possibile creare criteri dello stesso tenant. È possibile creare criteri tra tenant. |
È possibile creare criteri dello stesso tenant. Non è possibile creare criteri tra tenant. |
| Solo nome account | È possibile creare criteri dello stesso tenant. È possibile creare criteri tra tenant. |
Non è possibile creare né criteri dello stesso tenant né tra tenant. Si verifica un errore, perché Archiviazione di Azure non è in grado di verificare che gli account di origine e di destinazione si trovino nello stesso tenant. L'errore indica che è necessario specificare l'ID risorsa completo per le voci sourceAccount e destinationAccount nel file di definizione dei criteri. |
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.
| Quando si crea il file di definizione dei criteri per questo account... | Impostare l'ID criterio su questo valore | Impostare gli ID regola su questo valore |
|---|---|---|
| Account di destinazione | Valore stringa predefinito. Archiviazione di Azure creerà automaticamente il valore dell'ID criterio. | stringa vuota Archiviazione di Azure creerà automaticamente i valori dell'ID regola. |
| Account di origine | Valore dell'ID criterio restituito quando si scarica il file di definizione dei criteri per l'account di destinazione. | I valori degli ID regola restituiti quando si scarica il file di definizione dei criteri per l'account di destinazione. |
Impedire la replica nei tenant di Microsoft Entra
Un tenant di Microsoft Entra è un'istanza dedicata di Microsoft Entra ID che rappresenta un'organizzazione per la gestione delle identità e degli accessi. Ogni sottoscrizione di Azure ha una relazione di trust con un singolo tenant di Microsoft Entra. Tutte le risorse in una sottoscrizione, inclusi gli account di archiviazione, sono associate allo stesso tenant di Microsoft Entra. Per altre informazioni, consultare Che cos'è 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 di archiviazione che si trovano solo all'interno dello stesso tenant, è possibile impedire la replica tra tenant impostando una proprietà di sicurezza, la proprietà AllowCrossTenantReplication (anteprima). Quando si impedisce la replica di oggetti tra tenant per un account di archiviazione, per i criteri di replica degli oggetti configurati con tale account di archiviazione come account di origine o di destinazione, Archiviazione di Azure richiede che gli account di origine e di destinazione risiedano nello stesso tenant di Microsoft Entra. Per altre informazioni sulla disallowing cross-tenant object replication, 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 di archiviazione, impostare la proprietà AllowCrossTenantReplication su false. Se l'account di archiviazione non partecipa attualmente ad alcun criterio di replica di oggetti tra tenant, l'impostazione della proprietà AllowCrossTenantReplication su false impedisce la configurazione futura dei criteri di replica di oggetti tra tenant con questo account di archiviazione come origine o destinazione.
Se l'account di archiviazione partecipa attualmente a uno o più criteri di replica di oggetti tra 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 di archiviazione creato a partire dal 15 dicembre 2023. Per gli account di archiviazione creati prima del 15 dicembre 2023, quando il valore della proprietà AllowCrossTenantReplication per un account di archiviazione è Null o true, gli utenti autorizzati possono configurare 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 Criteri di Azure per controllare un set di account di archiviazione per assicurarsi che la proprietà AllowCrossTenantReplication sia impostata per impedire la replica di oggetti tra tenant. È anche possibile usare Criteri di Azure per applicare la governance per un set di account di archiviazione. Ad esempio, è possibile creare un criterio con l'effetto deny per impedire a un utente di creare un account di archiviazione in cui la proprietà AllowCrossTenantReplication è impostata su true o di modificare un account di archiviazione esistente per modificare il valore della proprietà su true.
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.
Nota
Mentre la replica è in corso, non è possibile determinare la percentuale di dati replicati.
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 sia in fase di eliminazione o che non sia stato semplicemente eliminato. 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 è stato crittografato con una chiave fornita dal cliente come parte di un'operazione di scrittura, la replica degli oggetti avrà esito negativo. Per altre informazioni sulle chiavi fornite dal cliente, vedere Fornire una chiave di crittografia in una richiesta all'archiviazione BLOB.
- Controllare se il BLOB di origine o di destinazione è stato spostato nel livello archivio. I BLOB archiviati non possono essere replicati tramite la replica di oggetti. Per altre informazioni sul livello archivio, vedere Livelli di accesso per i dati BLOB.
- Verificare che il contenitore o il BLOB di destinazione non sia protetto da criteri di immutabilità. Tenere presente che un contenitore o un BLOB può ereditare un criterio di immutabilità dal relativo elemento padre. Per altre informazioni sui criteri di immutabilità, vedere Panoramica dell'archiviazione non modificabile per i dati BLOB.
Supporto funzionalità
Il supporto di questa funzionalità potrebbe essere influenzato dall'abilitazione dei protocolli Data Lake Storage Gen2, NFS (Network File System) 3.0 o SFTP (SSH File Transfer Protocol). Se è stata abilitata una di queste funzionalità, vedere Supporto delle funzionalità di Archiviazione del BLOB negli account di Archiviazione di Azure per valutare il supporto per questa funzionalità.
Fatturazione
Non sono previsti costi per configurare la replica degli oggetti. Ciò include l'attività di abilitazione del feed di modifiche, l'abilitazione del controllo delle versioni e l'aggiunta di criteri di replica. Tuttavia, la replica degli oggetti comporta costi per le transazioni di lettura e scrittura sugli account di origine e di destinazione, nonché gli addebiti in uscita per la replica dei dati dall'account di origine all'account di destinazione e i costi di lettura per elaborare il feed di modifiche.
Ecco una suddivisione dei costi. Per trovare il prezzo di ogni componente di costo, vedere Archiviazione BLOB di Azure Prezzi.
| Costo per aggiornare un BLOB nell'account di origine | Costo per replicare i dati nell'account di destinazione |
|---|---|
| Costo della transazione di un'operazione di scrittura | Costo della transazione per la lettura di un record del feed di modifiche |
| Archiviazione costo del BLOB e di ogni BLOB versione1 | Costo delle transazioni per la lettura del BLOB e del BLOB versioni2 |
| Costo per aggiungere un record del feed di modifiche | Costo delle transazioni per la scrittura del BLOB e del BLOB versioni2 |
| Archiviazione costo del BLOB e di ogni BLOB versione1 | |
| Costo dell'uscitadi rete 3 |
1 Nell'account di origine, se non è stato modificato il livello di un BLOB o di una versione, vengono fatturati blocchi univoci di dati in tale BLOB, le relative 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.
2 Questo include solo le versioni BLOB create dopo il completamento dell'ultima replica.
3 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. Vedere Prezzi per la larghezza di banda.
Suggerimento
Per ridurre il rischio di una fattura imprevista, abilitare la replica di oggetti in un account che contiene solo un numero ridotto di oggetti. Misurare quindi l'impatto sui costi prima di abilitare la funzionalità in un'impostazione di produzione.
Passaggi successivi
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per