Condividi tramite

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 un account 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 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.

Diagramma che mostra il funzionamento della replica di oggetti.

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

Prerequisiti e avvertenze per la replica di oggetti

Per la replica di oggetti è necessario che siano abilitate anche le funzionalità di Archiviazione di Azure seguenti:

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

La replica di oggetti è supportata per gli account di archiviazione per utilizzo generico v2 e gli account BLOB in blocchi Premium. 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 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 è ancora supportata negli account con uno spazio dei nomi gerarchico abilitato.

La replica di oggetti non è supportata per i BLOB caricati tramite le API di 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.

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.

Ora OR supporta la replica con priorità, che assegna la priorità alla replica di tutte le operazioni in una politica OR. Quando la replica con priorità OR è abilitata, le prestazioni di replica di tutte le operazioni vengono migliorate. Quando gli account di origine e di destinazione dei criteri di replica si trovano nello stesso continente, con la replica prioritaria OR viene replicato anche il 99% degli oggetti entro 15 minuti per i carichi di lavoro supportati. Le prestazioni delle funzionalità sono garantite con un contratto di servizio. Per altre informazioni, vedere i termini del contratto di servizio e l'articolo Replica prioritaria degli oggetti.

È anche 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 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.

Se l'account di archiviazione ha criteri di replica degli oggetti in vigore, non è possibile disabilitare il versionamento 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.

Note

Solo i blob vengono copiati nella destinazione. L'ID versione di un BLOB non viene copiato. Dopo che un blob viene posizionato nel percorso di destinazione, viene assegnato un nuovo ID di versione.

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 non copia i tag di indice del BLOB di origine nel BLOB di destinazione.

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 Archiviazione BLOB di Azure includono criteri di conservazione basati sul tempo e blocchi a fini giudiziari. Quando una politica di immutabilità è attiva sull'account di destinazione, la replica degli oggetti potrebbe essere influenzata. Per altre informazioni sui criteri di immutabilità, vedere Archiviare dati BLOB critici per l'azienda con archiviazione non modificabile.

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 crea un criterio di replica che specifica l'account di archiviazione di origine 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 qualsiasi operazione 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 il criterio di replica, Archiviazione di Azure assegna 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 il servizio di archiviazione di Azure 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 altre informazioni sul livello archivio, vedere Livelli di accesso per i dati BLOB.

Note

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

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-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 della 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 sull'annullamento dell'autorizzazione dei criteri di replica tra tenant, vedere Impedire la replica nei tenant di Microsoft Entra.

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 Archiviazione di Azure supportano l'uso del 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 replica tra tenant sia consentita per l'account di archiviazione.

Identificatore dell'account di archiviazione 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. Azure Storage crea il valore ID della policy per te. Stringa vuota. Archiviazione di Azure crea i valori ID regola per l'utente.
Account di origine Il valore dell'ID criterio restituito al momento del download del file di definizione dei criteri per l'account di destinazione. I valori degli ID delle regole restituiti al momento del download del file di definizione dei criteri per l'account di destinazione.

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 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 disabilita la replica di oggetti tra tenant per un account di archiviazione, Azure Storage impone un ulteriore requisito. Per i criteri di replica degli oggetti che usano questo account di archiviazione 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 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.

Metriche di replica

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

  • Operazioni in attesa di replica: numero totale di operazioni in attesa di essere replicate dall'account di archiviazione di origine a quello di destinazione emesso per ciascun intervallo di tempo
  • Byte in sospeso per la replica: somma dei byte in sospeso per la replica dagli account di archiviazione di origine a quelli di destinazione emessi per intervalli 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:

Metriche di replica degli oggetti che mostrano le operazioni in sospeso e i byte in sospeso per un periodo di sette giorni

È 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.

Note

Mentre la replica è in corso, non è possibile determinare la percentuale o i 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 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 Fornire una chiave di crittografia in una richiesta all'archiviazione BLOB.
  • 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 altre 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 altre informazioni sui criteri di immutabilità, vedere Panoramica dell'archiviazione non modificabile per i dati BLOB.

Supporto delle 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 è 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 conoscere il prezzo di ogni componente di costo, vedere Prezzi di Archiviazione BLOB di Azure.

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 di transazione per la lettura di un record del feed di modifiche
Costo di archiviazione del BLOB e di ogni BLOB versione1 Costo di transazione per la lettura del BLOB e delle versioni del BLOB2
Costo per aggiungere un record del feed di modifiche Costo di transazione per la scrittura del BLOB e delle versioni del BLOB2
Costi di recupero dei dati su livelli a bassa frequenza e livelli a bassa temperatura Costo di archiviazione del BLOB e di ogni BLOB versione1
Costo dell'uscita di 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 degli oggetti in un account che contiene solo alcuni oggetti. Misurare quindi l'impatto sui costi prima di abilitare la funzionalità in un'impostazione di produzione.

Passaggi successivi

  • Last updated on