Pianificazione per la distribuzione di Sincronizzazione file di Azure

Sincronizzazione file di Azure è un servizio che consente di memorizzare nella cache varie condivisioni file di Azure in una macchina virtuale locale Windows Server o cloud.

Questo articolo introduce i concetti e le funzionalità di Sincronizzazione file di Azure. Dopo aver acquisito familiarità con Sincronizzazione file di Azure, è consigliabile seguire la guida alla distribuzione Sincronizzazione file di Azure per provare questo servizio.

I file verranno archiviati nel cloud in condivisioni file di Azure. Le condivisioni file di Azure possono essere usate in due modi: montando direttamente queste condivisioni file di Azure serverless (SMB) o memorizzando nella cache le condivisioni file di Azure in locale usando Sincronizzazione file di Azure. Quale opzione di distribuzione si sceglie modifica gli aspetti da considerare durante la pianificazione della distribuzione.

• Montaggio diretto di una condivisione file di Azure: poiché File di Azure fornisce l'accesso SMB, è possibile montare condivisioni file di Azure in locale o nel cloud usando il client SMB standard disponibile in Windows, macOS e Linux. Poiché le condivisioni file di Azure sono serverless, la distribuzione per gli scenari di produzione non richiede la gestione di un file server o di un dispositivo NAS. Ciò significa che non è necessario applicare patch software o sostituire dischi fisici.

• Memorizzare nella cache la condivisione file di Azure in locale con Sincronizzazione file di Azure: Sincronizzazione file di Azure consente di centralizzare le condivisioni file dell'organizzazione in File di Azure, mantenendo al tempo stesso flessibilità, prestazioni e compatibilità di un file server locale. Il servizio Sincronizzazione file di Azure trasforma un'istanza locale o cloud di Windows Server in una cache rapida della condivisione file di Azure.

Concetti relativi alla gestione

Una distribuzione di Sincronizzazione file di Azure si basa su tre oggetti di gestione:

• Condivisione file di Azure: una condivisione file di Azure è una condivisione file cloud serverless, che fornisce l'endpoint cloud di una relazione di sincronizzazione Sincronizzazione file di Azure. È possibile accedere ai file in una condivisione file di Azure direttamente con SMB o il protocollo FileREST, anche se si consiglia di accedere principalmente ai file tramite la cache di Windows Server quando la condivisione file di Azure viene usata con Sincronizzazione file di Azure. Ciò è dovuto al fatto che File di Azure oggi non dispone di un meccanismo efficiente di rilevamento delle modifiche, ad esempio Windows Server, quindi le modifiche alla condivisione file di Azure richiederanno tempo per propagarsi nuovamente agli endpoint server.
• Endpoint server: percorso in Windows Server sincronizzato con una condivisione file di Azure. Può trattarsi di una cartella specifica in un volume o della radice del volume. Se gli spazi dei nomi non si sovrappongono, possono esistere più endpoint server nello stesso volume.
• Gruppo di sincronizzazione: oggetto che definisce la relazione di sincronizzazione tra un endpoint cloud o una condivisione file di Azure e un endpoint server. Gli endpoint all'interno di un gruppo di sincronizzazione vengono mantenuti sincronizzati tra loro. Se si hanno due set distinti di file da gestire con Sincronizzazione file di Azure, ad esempio, si creeranno due gruppi di sincronizzazione e si aggiungeranno endpoint diversi a ognuno.

Concetti relativi alla gestione delle condivisioni file di Azure

Le condivisioni file di Azure vengono distribuite in account di archiviazione, ovvero oggetti di primo livello che rappresentano un pool di archiviazione condiviso. Questo pool di archiviazione condiviso può essere usato per distribuire più condivisioni file, nonché altre risorse di archiviazione, come contenitori BLOB, code o tabelle. Tutte le risorse di archiviazione distribuite in un account di archiviazione condividono i limiti applicabili a tale account. Per i limiti correnti dell'account di archiviazione, vedere File di Azure obiettivi di scalabilità e prestazioni.

Sono due i tipi principali di account di archiviazione che verranno usati per le distribuzioni di File di Azure:

• Account di archiviazione per utilizzo generico versione 2 (GPv2): gli account di archiviazione GPv2 consentono di distribuire condivisioni file di Azure in hardware standard o basato su disco rigido. Oltre a archiviare le condivisioni file di Azure, gli account di archiviazione per utilizzo generico v2 possono archiviare altre risorse di archiviazione, ad esempio contenitori BLOB, code o tabelle.
• Account di archiviazione FileStorage: Gli account di archiviazione FileStorage consentono di distribuire le condivisioni file di Azure a risorse hardware di livello Premium o basate su unità SSD. Gli account FileStorage possono essere usati solo per archiviare le condivisioni file di Azure. Non è infatti possibile distribuire altre risorse di archiviazione (contenitori BLOB, code, tabelle e così via) in un account FileStorage. Solo gli account FileStorage possono distribuire sia condivisioni file SMB che NFS.

Esistono diversi altri tipi di account di archiviazione che è possibile trovare nel portale di Azure, in PowerShell o nell'interfaccia della riga di comando. Due tipi di account di archiviazione, ovvero gli account di archiviazione BlockBlobStorage e BlobStorage, non possono contenere condivisioni file di Azure. Gli altri due tipi di account di archiviazione disponibili sono gli account di archiviazione per utilizzo generico v1 e quelli classici, che possono contenere entrambi condivisioni file di Azure. Anche se gli account di archiviazione classici e per utilizzo generico v1 possono contenere condivisioni file di Azure, la maggior parte delle nuove funzionalità di File di Azure è disponibile solo negli account di archiviazione per utilizzo generico v2 e FileStorage. È quindi consigliabile usare solo account di archiviazione per utilizzo generico v2 e FileStorage per le nuove distribuzioni e per aggiornare account di archiviazione per utilizzo generico v1 e classici, se esistono già nell'ambiente corrente.

Concetti relativi alla gestione di Sincronizzazione file di Azure

I gruppi di sincronizzazione vengono distribuiti in servizi di sincronizzazione archiviazione, oggetti di livello superiore che registrano i server da usare con Sincronizzazione file di Azure e contengono le relazioni dei gruppi di sincronizzazione. Il servizio di sincronizzazione archiviazione è un peer della risorsa account di archiviazione e può essere distribuito in modo analogo a questa nei gruppi di risorse di Azure. Un servizio di sincronizzazione archiviazione può creare gruppi di sincronizzazione che contengono condivisioni file di Azure ubicate in più account di archiviazione e più istanze di Windows Server registrate.

Prima di poter creare un gruppo di sincronizzazione in un servizio di sincronizzazione archiviazione, è necessario registrare un'istanza di Windows Server nel servizio di sincronizzazione archiviazione. In questo modo si crea un oggetto server registrato, che rappresenta una relazione di trust tra il server (o cluster) e il servizio di sincronizzazione archiviazione. Per registrare un servizio di sincronizzazione archiviazione, è prima necessario installare l'agente di Sincronizzazione file di Azure nel server. È possibile registrare un server o un cluster con un solo servizio di sincronizzazione archiviazione alla volta.

Un gruppo di sincronizzazione contiene un endpoint cloud, una condivisione file di Azure e almeno un endpoint server. L'oggetto endpoint server contiene le impostazioni che configurano la funzionalità di suddivisione in livelli cloud, che fornisce la funzionalità di memorizzazione nella cache di Sincronizzazione file di Azure. Per eseguire la sincronizzazione con una condivisione file di Azure, l'account di archiviazione contenente la condivisione file di Azure deve trovarsi nella stessa area di Azure del servizio di sincronizzazione archiviazione.

Prendere in considerazione il numero di servizi di sincronizzazione archiviazione necessari

Una sezione precedente illustra la risorsa principale da configurare per Sincronizzazione file di Azure: un servizio di sincronizzazione archiviazione. Un windows Server può essere registrato solo in un servizio di sincronizzazione archiviazione. È quindi consigliabile distribuire un singolo servizio di sincronizzazione archiviazione e registrare tutti i server in esso.

Creare più servizi di sincronizzazione archiviazione solo se si dispone di:

• set distinti di server che non devono mai scambiare dati tra loro. In questo caso, si vuole progettare il sistema per escludere determinati set di server da sincronizzare con una condivisione file di Azure già in uso come endpoint cloud in un gruppo di sincronizzazione in un altro servizio di sincronizzazione archiviazione. Un altro modo per esaminare questo è che i server Windows registrati in un servizio di sincronizzazione archiviazione diverso non possono eseguire la sincronizzazione con la stessa condivisione file di Azure.
• una necessità di avere più server registrati o gruppi di sincronizzazione rispetto a un singolo servizio di sincronizzazione archiviazione può supportare. Per informazioni più dettagliate, esaminare Obiettivi di scalabilità di Sincronizzazione file di Azure.

Pianificare topologie di sincronizzazione bilanciate

Prima di distribuire qualsiasi risorsa, è importante pianificare ciò che verrà sincronizzato in un server locale, con cui la condivisione file di Azure. La creazione di un piano consentirà di determinare quanti account di archiviazione, condivisioni file di Azure e sincronizzare le risorse necessarie. Queste considerazioni sono ancora rilevanti, anche se i dati non risiedono attualmente in windows Server o nel server che si vuole usare a lungo termine. La sezione relativa alla migrazione consente di determinare i percorsi di migrazione appropriati per la situazione.

In questo passaggio verrà determinato il numero di condivisioni file di Azure necessarie. Una singola istanza di Windows Server (o cluster) può sincronizzare fino a 30 condivisioni file di Azure.

Potrebbero essere presenti più cartelle nei volumi attualmente condivisi in locale come condivisioni SMB per gli utenti e le app. Il modo più semplice per eseguire l'immagine di questo scenario consiste nell'immaginare una condivisione locale che esegue il mapping 1:1 a una condivisione file di Azure. Se si dispone di un numero sufficientemente piccolo di condivisioni, inferiore a 30 per una singola istanza di Windows Server, è consigliabile eseguire un mapping 1:1.

Se sono presenti più di 30 condivisioni, il mapping di una condivisione locale 1:1 a una condivisione file di Azure spesso non è necessario. Valutare le opzioni seguenti.

Raggruppamento di condivisioni

Ad esempio, se il reparto risorse umane (HR) ha 15 condivisioni, valutare l’archiviazione di tutti i dati delle risorse umane in una singola condivisione file di Azure. L'archiviazione di più condivisioni locali in un’unica condivisione file di Azure non impedisce di creare le 15 condivisioni SMB normali nell'istanza locale di Windows Server. Significa solo che si organizzano le cartelle radice di queste 15 condivisioni come sottocartelle in una cartella comune. Si sincronizza, quindi, questa cartella comune con una condivisione file di Azure. In questo modo, è necessaria solo una singola condivisione file di Azure nel cloud per questo gruppo di condivisioni locali.

Sincronizzazione di volumi

Sincronizzazione file di Azure supporta la sincronizzazione della radice di un volume con una condivisione file di Azure. Se si sincronizza la radice del volume, tutte le sottocartelle e i file passeranno nella stessa condivisione file di Azure.

La sincronizzazione della radice del volume non è sempre l'opzione migliore. La sincronizzazione di più posizioni offre alcuni vantaggi. In questo modo, ad esempio, è possibile mantenere inferiore il numero di elementi per ambito di sincronizzazione. Vengono testate le condivisioni file di Azure e Sincronizzazione file di Azure con 100 milioni di elementi (file e cartelle) per condivisione. Ma una procedura consigliata consiste nel cercare di mantenere il numero inferiore a 20 milioni o 30 milioni in una singola quota. La configurazione di Sincronizzazione file di Azure con un numero inferiore di elementi non è utile solo per la sincronizzazione file. Un numero inferiore di elementi offre benefici anche in scenari come i seguenti:

• L'analisi iniziale del contenuto cloud può essere completata più rapidamente, riducendo a sua volta l'attesa della visualizzazione dello spazio dei nomi in un server abilitato per Sincronizzazione file di Azure.
• Il ripristino lato cloud da uno snapshot di condivisione file di Azure sarà più veloce.
• Il ripristino di emergenza di un server locale può accelerare notevolmente.
• Le modifiche apportate direttamente in una condivisione file di Azure (al di fuori della sincronizzazione) possono essere rilevate e sincronizzate più velocemente.

Approccio strutturato a una mappa di distribuzione

Prima di distribuire l'archiviazione nel cloud in un passaggio successivo, è importante creare una mappa tra le cartelle locali e le condivisioni file di Azure. Questo mapping consentirà di appurare quante e quali risorse del gruppo di sincronizzazione di Sincronizzazione file di Azure verranno sottoposte a provisioning. Un gruppo di sincronizzazione collega la condivisione file di Azure e la cartella nel server e stabilisce una connessione di sincronizzazione.

Per decidere il numero di condivisioni file di Azure necessarie, esaminare i limiti e le procedure consigliate seguenti. In questo modo, sarà possibile ottimizzare la mappa.

• Un server in cui è installato l'agente di Sincronizzazione file di Azure può eseguire la sincronizzazione con un massimo di 30 condivisioni file di Azure.

• Una condivisione file di Azure viene distribuita in un account di archiviazione. Questa disposizione rende l'account di archiviazione una destinazione di scalabilità per i numeri correlati alle prestazioni come operazioni di I/O al secondo e velocità effettiva.

  Quando si distribuiscono condivisioni file di Azure, prestare attenzione alle limitazioni di un account di archiviazione in termini di operazioni di I/O al secondo. L’ideale sarebbe eseguire il mapping 1:1 delle condivisioni file con gli account di archiviazione. Tuttavia, ciò non sempre è possibile, a causa dei diversi limiti e restrizioni imposti dalla propria organizzazione e da Azure. Quando non è possibile distribuire una sola condivisione file per account di archiviazione, valutare quali condivisioni saranno particolarmente attive e quali lo saranno meno, in modo da non inserire le condivisioni file più utilizzate nello stesso account di archiviazione.

  Se si prevede di trasferire un'app in Azure che userà la condivisione file di Azure in modo nativo, potrebbe essere necessario ottenere prestazioni più elevate dalla condivisione file di Azure. Se questo tipo di uso è una possibilità, anche in futuro, è consigliabile creare una singola condivisione file standard di Azure nel proprio account di archiviazione.

• Esiste un limite di 250 account di archiviazione per sottoscrizione e area di Azure.

È consigliabile mantenere basso il numero di elementi per ambito di sincronizzazione. Questo è un fattore importante da considerare nel mapping delle cartelle alle condivisioni file di Azure. Sincronizzazione file di Azure è testato con 100 milioni di elementi (file e cartelle) per condivisione. Molte volte, tuttavia, è preferibile cercare di mantenere il numero di elementi al di sotto di 20 milioni o 30 milioni in una singola quota. Suddividere lo spazio dei nomi in più condivisioni se si inizia a superare questi numeri. È possibile continuare a raggruppare più condivisioni locali nella stessa condivisione file di Azure se si rimane approssimativamente al di sotto di questi numeri. Questa pratica fornirà spazio per la crescita.

È possibile che, nella propria situazione, un set di cartelle possa essere sincronizzato logicamente con la stessa condivisione file di Azure (usando il nuovo approccio comune alle cartelle radice menzionato in precedenza). Potrebbe essere preferibile, tuttavia, raggruppare le cartelle in modo che vengano sincronizzate con due condivisioni file di Azure anziché una sola. È possibile usare questo approccio per mantenere bilanciato il numero di file e cartelle per condivisione file nel server. È anche possibile suddividere le condivisioni locali e la sincronizzazione tra più server locali, aggiungendo la possibilità di eseguire la sincronizzazione con altre 30 condivisioni file di Azure per ogni server aggiuntivo.

Scenari e considerazioni comuni di sincronizzazione dei file

#	Scenario di sincronizzazione	Supportata	Considerazioni (o limitazioni)	Soluzione (soluzione alternativa)
1	File server con più dischi/volumi e più condivisioni nella stessa condivisione file di Azure di destinazione (consolidamento)	No	Una condivisione file di Azure di destinazione (endpoint cloud) supporta la sincronizzazione con un solo gruppo di sincronizzazione. Un gruppo di sincronizzazione supporta un solo endpoint server per ogni server registrato.	1) Iniziare con la sincronizzazione di un solo disco (relativo volume radice) alla condivisione file di Azure di destinazione. Cominciare dal disco/volume più grande sarà utile per i requisiti di archiviazione locale. Configurare il cloud a livelli per suddividere in livelli tutti i dati nel cloud, liberando spazio sul disco del file server. Spostare i dati da altri volumi/condivisioni nel volume corrente che esegue la sincronizzazione. Continuare i passaggi uno per uno fino a quando tutti i dati vengono suddivisi in livelli nel cloud o nella migrazione. 2) Specificare come destinazione un solo volume radice (disco) alla volta. Usare il cloud a livelli per suddividere in livelli tutti i dati per la condivisione file di Azure di destinazione. Rimuovere l'endpoint server dal gruppo di sincronizzazione, ricreare l'endpoint con il volume/disco radice successivo, sincronizzare e ripetere il processo. Nota: potrebbe essere necessario reinstallare l'agente. 3) Consigliare l'uso di più condivisioni file di Azure di destinazione (account di archiviazione identico o diverso in base ai requisiti di prestazioni)
2	File server con singolo volume e più condivisioni nella stessa condivisione file di Azure di destinazione (consolidamento)	Sì	Non è possibile avere più endpoint server per ogni server registrato che esegue la sincronizzazione con la stessa condivisione file di Azure di destinazione (uguale a quella precedente)	Sincronizzare la radice del volume che contiene più condivisioni o cartelle di primo livello. Per altre informazioni, fare riferimento a Concetto di raggruppamento delle condivisioni e Sincronizzazione di volumi.
3	File server con più condivisioni e/o volumi in più condivisioni file di Azure con un singolo account di archiviazione (mapping 1:1 della condivisione)	Sì	Una singola istanza di Windows Server (o cluster) può sincronizzare fino a 30 condivisioni file di Azure. Un account di archiviazione è una destinazione di scalabilità per le prestazioni. Le operazioni di I/O al secondo e la velocità effettiva vengono condivise tra le condivisioni file. Mantenere il numero di elementi per gruppo di sincronizzazione entro 100 milioni di elementi (file e cartelle) per condivisione. L’ideale sarebbe rimanere al di sotto di 20 o 30 milioni di elementi per condivisione.	1) Usare più gruppi di sincronizzazione (numero di gruppi di sincronizzazione = numero di condivisioni file di Azure da sincronizzare). 2) In questo scenario è possibile sincronizzare solo 30 condivisioni alla volta. Se esistono più di 30 condivisioni in tale file server, usare il Concetto di raggruppamento delle condivisioni e Sincronizzazione di volumi per ridurre il numero di cartelle radice o di primo livello nell'origine. 3) Usare server di Sincronizzazione file aggiuntivi in locale e dividere/spostare i dati in questi server per aggirare le limitazioni nel server Windows di origine.
4	File server con più condivisioni e/o volumi in più condivisioni file di Azure con un account di archiviazione differente (mapping 1:1 della condivisione)	Sì	Una singola istanza di Windows Server (o cluster) può sincronizzare fino a 30 condivisioni file di Azure (account di archiviazione identico o differente). Mantenere il numero di elementi per gruppo di sincronizzazione entro 100 milioni di elementi (file e cartelle) per condivisione. L’ideale sarebbe rimanere al di sotto di 20 o 30 milioni di elementi per condivisione.	Stesso approccio illustrato in precedenza
5	Più file server con singolo (condivisione o volume radice) nella stessa condivisione file di Azure di destinazione (consolidamento)	No	Un gruppo di sincronizzazione non può usare l'endpoint cloud (condivisione file di Azure) già configurato in un altro gruppo di sincronizzazione. Anche se un gruppo di sincronizzazione può avere endpoint server in file server diversi, i file non possono essere distinti.	Seguire le indicazioni riportate nello scenario 1 precedente con considerazioni aggiuntive sulla destinazione di un solo file server alla volta.

Creare una tabella di mapping

Usare le informazioni precedenti per determinare il numero di condivisioni file di Azure necessarie e quali parti dei dati esistenti finiranno nelle varie condivisioni file di Azure.

Creare una tabella che registra le considerazioni effettuate in modo da potervi fare riferimento quando è necessario. Rimanere organizzati è importante perché può essere facile perdere i dettagli del piano di mapping quando si esegue il provisioning di molte risorse di Azure contemporaneamente. Scaricare il file di Excel seguente da usare come modello per facilitare la creazione del mapping.

Scaricare un modello di mapping dello spazio dei nomi.

Considerazioni relative al file server Windows

Per abilitare la funzionalità di sincronizzazione in Windows Server, è necessario installare l'agente scaricabile di Sincronizzazione file di Azure. L'agente Sincronizzazione file di Azure fornisce due componenti principali: FileSyncSvc.exe, il servizio Windows in background responsabile del monitoraggio delle modifiche negli endpoint server e l'avvio di sessioni di sincronizzazione e StorageSync.sys, un filtro del file system che consente il cloud a livelli e il ripristino di emergenza rapido.

Requisiti per il sistema operativo

Sincronizzazione file di Azure è supportato con le versioni di Windows Server seguenti:

Versione	SKU supportati	Opzioni di distribuzione supportate
Windows Server 2025	Azure, Datacenter, Essentials, Standard e IoT	Full e Core
Windows Server 2022	Azure, Datacenter, Essentials, Standard e IoT	Full e Core
Windows Server 2019	Datacenter, Essentials, Standard e IoT	Full e Core
Windows Server 2016	Datacenter, Essentials, Standard e Storage Server	Full e Core
Windows Server 2012 R2*	Datacenter, Essentials, Standard e Storage Server	Full e Core

*Richiede il download e l'installazione di Windows Management Framework (WMF) 5.1. Il pacchetto appropriato da scaricare e installare per Windows Server 2012 R2 è Win8.1AndW2K12R2-KB*******-x64.msu.

Le versioni future di Windows Server verranno aggiunte non appena verranno rilasciate.

Risorse di sistema minime

Sincronizzazione file di Azure richiede un server, fisico o virtuale, con almeno una CPU, almeno 2 GiB di memoria e un volume collegato localmente formattato con il file system NTFS.

Per la maggior parte dei carichi di lavoro di produzione, non è consigliabile configurare un server di sincronizzazione Sincronizzazione file di Azure con solo i requisiti minimi. Per altre informazioni, vedere Risorse di sistema consigliate.

Risorse di sistema consigliate

Come per qualsiasi applicazione o funzionalità server, i requisiti relativi alle risorse di sistema per Sincronizzazione file di Azure sono determinati dalla scala della distribuzione. Le distribuzioni di dimensioni maggiori in un server richiedono più risorse di sistema. Per Sincronizzazione file di Azure, la scala è determinata dal numero di oggetti negli endpoint server e dalla varianza del set di dati. Un singolo server può avere endpoint server in più gruppi di sincronizzazione e il numero di oggetti elencati nella tabella seguente tiene conto dell'intero spazio dei nomi a cui un server è collegato.

Ad esempio, endpoint server A con 10 milioni di oggetti + endpoint server B con 10 milioni di oggetti = 20 milioni di oggetti. Per questa distribuzione di esempio si consigliano 8 CPU, 16 GiB di memoria per lo stato stabile e, se possibile, 48 GiB di memoria per la migrazione iniziale.

I dati dello spazio dei nomi vengono archiviati in memoria per motivi di prestazioni. Per questo motivo, gli spazi dei nomi più grandi richiedono una maggiore quantità di memoria per garantire prestazioni ottimali e una maggiore varianza richiede più CPU per l'elaborazione.

Nella tabella seguente sono disponibili sia le dimensioni dello spazio dei nomi che la conversione alla capacità per le condivisioni file per utilizzo generico tipico, in cui la dimensione media del file è 512 KiB. Se i file nel proprio ambiente sono di dimensioni inferiori, valutare la possibilità di aggiungere ulteriore memoria per la stessa quantità di capacità. Basare la configurazione della memoria sulle dimensioni dello spazio dei nomi.

Dimensioni dello spazio dei nomi - File e directory (milioni)	Capacità tipica (TiB)	Core CPU	Memoria consigliata (GiB)
3	1.4	2	8 (sincronizzazione iniziale)/2 (varianza tipica)
5	2.3	2	16 (sincronizzazione iniziale)/4 (varianza tipica)
10	4.7	4	32 (sincronizzazione iniziale)/8 (varianza tipica)
30	14,0	8	48 (sincronizzazione iniziale)/16 (varianza tipica)
50	23,3	16	64 (sincronizzazione iniziale)/32 (varianza tipica)
100*	46,6	32	128 (sincronizzazione iniziale)/32 (varianza tipica)

*Non è consigliabile sincronizzare più di 100 milioni di file e directory. Si tratta di un limite flessibile, basato sulle soglie testate. Per altre informazioni, vedere Obiettivi di scalabilità di Sincronizzazione file di Azure.

Cmdlet di valutazione

Prima di distribuire Sincronizzazione file di Azure, è necessario valutare se è compatibile con il sistema usando il cmdlet di valutazione Sincronizzazione file di Azure. Questo cmdlet consente di rilevare potenziali problemi con il file system e il set di dati, ad esempio caratteri non supportati o versione del sistema operativo non supportata. Questi controlli riguardano la maggior parte, ma non tutte le funzionalità indicate di seguito; È consigliabile leggere attentamente il resto di questa sezione per assicurarsi che la distribuzione funzioni senza problemi.

Il cmdlet di valutazione può essere installato installando il modulo Az PowerShell, che può essere installato seguendo le istruzioni riportate qui: Installare e configurare Azure PowerShell.

Utilizzo

È possibile richiamare lo strumento di valutazione in modi diversi: è possibile eseguire i controlli di sistema, i controlli dei set di dati o entrambi. Per eseguire i controlli di sistema e del set di dati:

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

Per testare solo il set di dati:

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

Per testare solo i requisiti di sistema:

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

Per visualizzare i risultati in CSV:

$validation = Invoke-AzStorageSyncCompatibilityCheck C:\DATA
$validation.Results | Select-Object -Property Type, Path, Level, Description, Result | Export-Csv -Path C:\results.csv -Encoding utf8

Compatibilità del file system

Sincronizzazione file di Azure è supportato solo nei volumi NTFS collegati direttamente. In Windows Server, archiviazione collegata direttamente, o DAS (Direct-Attached Storage), significa che il sistema operativo Windows Server è proprietario del file system. È possibile fornire DAS tramite il collegamento fisico dei dischi al file server, il collegamento di dischi virtuali a una macchina virtuale file server (ad esempio una macchina virtuale ospitata da Hyper-V) o anche tramite iSCSI.

Sono supportati solo i volumi NTFS; ReFS, FAT, FAT32 e altri file system non sono supportati.

La tabella seguente illustra lo stato di interoperabilità delle funzionalità del file system NTFS:

Funzionalità	Stato del supporto	Note
Elenchi di controllo di accesso (ACL)	supporto completo	Gli elenchi di controllo di accesso discrezionale di Windows vengono mantenuti da Sincronizzazione file di Azure e vengono applicati da Windows Server negli endpoint server. Gli ACL possono anche essere applicati quando si monta direttamente la condivisione file di Azure, ma questa operazione richiede una configurazione aggiuntiva. Per altre informazioni, vedere le sezione Identità.
Collegamenti reali	Ignorato
Collegamenti simbolici	Ignorato
Punti di montaggio	Parzialmente supportato	I punti di montaggio possono corrispondere alla radice di un endpoint server, ma vengono ignorati se sono contenuti nello spazio dei nomi di un endpoint server.
Giunzioni	Ignorato	Ad esempio, le cartelle DfrsrPrivate e DFSRoots del file system distribuito.
Punti di analisi	Ignorato
Compressione NTFS	Parzialmente supportato	Sincronizzazione file di Azure non supporta gli endpoint server che si trovano in un volume con la directory SVI (System Volume Information) compressa.
File sparse	supporto completo	I file sparse vengono sincronizzati (non bloccati), ma vengono sincronizzati nel cloud come file completi. Se il contenuto del file viene modificato nel cloud (o in un altro server), il file non è più di tipo sparse quando viene scaricata la modifica.
Flussi di dati alternativi (ADS)	Mantenuti, ma non sincronizzati	Ad esempio, i tag di classificazione creati dall'infrastruttura di classificazione file non vengono sincronizzati. I tag di classificazione esistenti sui file in ognuno degli endpoint server non subiscono variazioni.

Sincronizzazione file di Azure ignorerà inoltre alcuni file temporanei e cartelle di sistema:

File/cartella	Nota
pagefile.sys	File specifico del sistema
Desktop.ini	File specifico del sistema
thumbs.db	file temporaneo per le anteprime
ehthumbs.db	File temporaneo per anteprime multimediali
~$*.*	file temporaneo di Office
*.Tmp	file temporaneo
*.laccdb	file di blocco del database di Access
635D02A9D91C401B97884B82B3BCDAEA.*	file di sincronizzazione interno
\System Volume Information	Cartella specifica del volume
$RECYCLE.BIN	Cartella
\SyncShareState	cartella per la sincronizzazione
. SystemShareInformation	Cartella per la sincronizzazione nella condivisione file di Azure

Valutare la quantità di spazio disponibile necessaria sul disco locale

Quando si prevede di usare Sincronizzazione file di Azure, valutare la quantità di spazio disponibile necessario nel disco locale in cui si prevede di avere un endpoint server.

Con Sincronizzazione file di Azure, è necessario tenere conto dello spazio seguente sul disco locale:

• Con la suddivisione in livelli cloud abilitata:

  • Reparse points for tiered files
  • database di metadati Sincronizzazione file di Azure
  • Sincronizzazione file di Azure heatstore
  • File completamente scaricati nella cache ad accesso frequente (se presente)
  • Requisiti dei criteri di spazio libero del volume

• Con la suddivisione in livelli cloud disabilitata:

  • File completamente scaricati
  • Sincronizzazione file di Azure heatstore
  • database di metadati Sincronizzazione file di Azure

Verrà usato un esempio per illustrare come stimare la quantità di spazio disponibile nel disco locale. Si supponga di aver installato l'agente Sincronizzazione file di Azure nella macchina virtuale Windows di Azure e di pianificare la creazione di un endpoint server su disco F. Si dispone di 1 milione di file e si vuole eseguire il livello di tutti, 100.000 directory e una dimensione del cluster del disco di 4 KiB. La dimensione del disco è 1000 GiB. Si vuole abilitare la suddivisione in livelli nel cloud e impostare i criteri di spazio libero del volume su 20%.

1. NTFS alloca una dimensione del cluster per ognuno dei file a livelli. 1 milione di file * 4 dimensioni del cluster KiB = 4.000.000 KiB (4 GiB)

   Nota

   Per sfruttare appieno la suddivisione in livelli nel cloud, è consigliabile usare dimensioni del cluster NTFS inferiori (minori di 64KiB) perché ogni file a livelli occupa un cluster. Inoltre, lo spazio occupato dai file a livelli viene allocato da NTFS. Pertanto, non verrà visualizzato in alcuna interfaccia utente.

2. I metadati di sincronizzazione occupano una dimensione del cluster per ogni elemento. (1 milione di file + 100.000 directory) * 4 dimensioni del cluster KiB = 4.400.000 KiB (4,4 GiB)
3. Sincronizzazione file di Azure heatstore occupa 1,1 KiB per file. 1 milione di file * 1,1 KiB = 1.100.000 KiB (1,1 GiB)
4. I criteri di spazio libero del volume sono del 20%. 1000 GiB * 0,2 = 200 GiB

In questo caso, Sincronizzazione file di Azure avrebbe bisogno di circa 209.500.000 KiB (209,5 GiB) di spazio per questo spazio dei nomi. Aggiungere questa quantità a qualsiasi spazio disponibile aggiuntivo desiderato per determinare la quantità di spazio disponibile necessaria per questo disco.

Clustering di failover

1. Il clustering di failover di Windows Server è supportato da Sincronizzazione file di Azure per l'opzione di distribuzione "File server per uso generale". Per altre informazioni su come configurare il ruolo "File Server per uso generico" in un cluster di failover, vedere Distribuzione di un file server in cluster a due nodi.
2. L'unico scenario supportato da Sincronizzazione file di Azure è Windows Server Failover Cluster with Clustered Disks
3. Il clustering di failover non è supportato in file server di scalabilità orizzontale per i dati dell'applicazione (SOFS) o su volumi condivisi cluster o dischi locali.

Deduplicazione dati

Windows Server 2025, Windows Server 2022, Windows Server 2019 e Windows Server 2016
La deduplicazione dati è supportata indipendentemente dal fatto che il cloud a livelli sia abilitato o disabilitato in uno o più endpoint server nel volume per Windows Server 2016, Windows Server 2019, Windows Server 2022 e Windows Server 2025. Abilitando Deduplicazione dati in un volume in cui è abilitata la funzionalità cloud a livelli, è possibile memorizzare nella cache un numero maggiore di file in locale senza effettuare il provisioning di altro spazio di archiviazione.

Quando si abilita Deduplicazione dati in un volume in cui è abilitato il cloud a livelli, i file ottimizzati dalla deduplicazione nel percorso dell'endpoint server verranno suddivisi in livelli come se si trattasse di un normale file, in base alle impostazioni dei criteri del cloud a livelli. Una volta suddivisi in livelli i file ottimizzati dalla deduplicazione, il processo di Garbage Collection di Deduplicazione dati viene eseguito automaticamente, per recuperare spazio su disco rimuovendo i blocchi non necessari che non sono più referenziati da altri file sul volume.

Si noti che i risparmi sul volume si applicano solo al server; I dati nella condivisione file di Azure non verranno deduplicati.

Windows Server 2012 R2
Sincronizzazione file di Azure non supporta deduplicazione dati e suddivisione in livelli cloud nello stesso volume in Windows Server 2012 R2. Se in un volume è abilitata la deduplicazione dei dati, la funzionalità cloud a livelli deve essere disabilitata.

Note

• Se la funzionalità Deduplicazione dati viene installata prima di installare l'agente di Sincronizzazione file di Azure, per supportare la deduplicazione e il cloud a livelli nello stesso volume è necessario il riavvio.

• Se si abilita la deduplicazione in un volume dopo aver abilitato il cloud a livelli, il processo iniziale di ottimizzazione di Deduplicazione dati ottimizzerà i file nel volume che non sono già suddivisi in livelli. L'effetto sul cloud a livelli sarà il seguente:

  • Il criterio di spazio disponibile continuerà a suddividere i file in livelli in base allo spazio libero nel volume usando la mappa termica.
  • Il criterio di data ignorerà la suddivisione in livelli di file che altrimenti sarebbero stati idonei, a causa del processo di ottimizzazione di Deduplicazione dati che accede ai file.

• Per i processi di ottimizzazione della deduplicazione in corso, il cloud a livelli con i criteri di data verrà ritardato dall'impostazione Data Deduplicazione MinimumFileAgeDays , se il file non è già a livelli.

  • Esempio: se l'impostazione MinimumFileAgeDays è di sette giorni e i criteri di data di suddivisione in livelli nel cloud sono di 30 giorni, i criteri di data verranno archiviati a livelli dopo 37 giorni.
  • Nota: dopo che un file è a livelli per Sincronizzazione file di Azure, il processo di ottimizzazione della deduplicazione ignorerà il file.

• Se un server che esegue Windows Server 2012 R2 con l'agente Sincronizzazione file di Azure installato viene aggiornato a Windows Server 2016, Windows Server 2019, Windows Server 2022 o Windows Server 2025, è necessario eseguire la procedura seguente per supportare la deduplicazione dei dati e la suddivisione in livelli cloud nello stesso volume:

  • Disinstallare l'agente di Sincronizzazione file di Azure per Windows Server 2012 R2 e riavviare il server.
  • Scaricare l'agente Sincronizzazione file di Azure per la nuova versione del sistema operativo server (Windows Server 2016, Windows Server 2019, Windows Server 2022 o Windows Server 2025).
  • Installare l'agente di Sincronizzazione file di Azure e riavviare il server.

  Nota: le impostazioni di configurazione Sincronizzazione file di Azure nel server vengono mantenute quando l'agente viene disinstallato e reinstallato.

File system distribuito (DFS)

Sincronizzazione file di Azure supporta l'interoperabilità con Spazi dei nomi DFS (DFS-N) e Replica DFS (DFS-R).

Spazi dei nomi DFS (DFS-N): Sincronizzazione file di Azure è completamente supportato con l'implementazione DFS-N. È possibile installare l'agente Sincronizzazione file di Azure in uno o più file server per sincronizzare i dati tra gli endpoint server e l'endpoint cloud e quindi usare DFS-N per fornire il servizio spazi dei nomi. Per altre informazioni, vedere Panoramica degli spazi dei nomi DFS e Spazi dei nomi DFS con File di Azure.

Replica DFS (DFS-R): poiché DFS-R e Sincronizzazione file di Azure sono entrambe soluzioni di replica, nella maggior parte dei casi, è consigliabile sostituire DFS-R con Sincronizzazione file di Azure. Esistono tuttavia diversi scenari in cui si vuole usare DFS-R e Sincronizzazione file di Azure insieme:

• Si sta eseguendo la migrazione da una distribuzione DFS-R a una distribuzione Sincronizzazione file di Azure. Per altre informazioni, vedere Eseguire la migrazione di una distribuzione di Replica DFS (DFS-R) in Sincronizzazione file di Azure.
• Non tutti i server locali in cui è necessaria una copia dei dati dei file possono essere connessi direttamente a Internet.
• I server di succursale consolidano i dati in un unico server di hub per cui si vorrebbe usare Sincronizzazione file di Azure.

Per il funzionamento in parallelo di Sincronizzazione file di Azure e DFS-R:

1. Nei volumi con cartelle replicate con DFS-R deve essere disabilitata la suddivisione in livelli cloud di Sincronizzazione file di Azure.
2. Gli endpoint server non devono essere configurati nelle cartelle di replica di sola lettura DFS-R.
3. Solo un singolo endpoint server può sovrapporsi a una posizione DFS-R. Più endpoint server sovrapposti ad altri percorsi DFS-R attivi possono causare conflitti.

Per altre informazioni, vedere la panoramica di Replica DFS.

Sysprep

L'uso di sysprep in un server in cui è installato l'agente Sincronizzazione file di Azure non è supportato e può causare risultati imprevisti. L'installazione dell'agente e la registrazione del server devono avvenire dopo la distribuzione dell'immagine del server e il completamento dell'installazione minima di sysprep.

Windows Search

Se il cloud a livelli è abilitato in un endpoint server, i file a livelli vengono ignorati e non vengono indicizzati da Windows Search. I file non suddivisi in livelli vengono indicizzati correttamente.

Altre soluzioni di gestione dell'archiviazione gerarchica

Con Sincronizzazione file di Azure non devono essere usate altre soluzioni di gestione dell'archiviazione gerarchica.

Prestazioni e scalabilità

Poiché l'agente di Sincronizzazione file di Azure viene eseguito in un computer Windows Server che si connette alle condivisioni file di Azure, le effettive prestazioni di sincronizzazione dipendono da diversi fattori nell'infrastruttura: Windows Server e configurazione dei dischi sottostante, larghezza di banda tra il server e l'archiviazione di Azure, dimensioni dei file, dimensioni totali del set di dati e attività nel set di dati. Poiché Sincronizzazione file di Azure opera a livello di file, le caratteristiche in termini di prestazioni di una soluzione basata su Sincronizzazione file di Azure possono essere misurate meglio in base al numero di oggetti (file e directory) elaborati al secondo.

Le modifiche apportate alla condivisione file di Azure usando il portale di Azure o SMB non vengono rilevate e replicate immediatamente come le modifiche all'endpoint server. File di Azure non dispone di notifiche di modifica o inserimento nel journal, quindi non è possibile avviare automaticamente una sessione di sincronizzazione quando i file vengono modificati. In Windows Server Sincronizzazione file di Azure usa l'inserimento nel journal del numero di sequenza di aggiornamento (USN) di Windows per avviare automaticamente una sessione di sincronizzazione quando i file vengono modificati.

Per rilevare le modifiche apportate alla condivisione file di Azure, Sincronizzazione file di Azure ha un processo pianificato denominato processo di rilevamento modifiche. Il processo di rilevamento modifiche enumera tutti i file nella condivisione file e quindi confronta ogni file con la versione di sincronizzazione corrispondente. Se il processo di rilevamento modifiche determina che i file sono stati modificati, Sincronizzazione file di Azure avvia una sessione di sincronizzazione. Il processo di rilevamento modifiche viene avviato ogni 24 ore. Poiché il processo di rilevamento modifiche funziona tramite l'enumerazione di ogni file nella condivisione file di Azure, il rilevamento delle modifiche richiede più tempo negli spazi dei nomi di grandi dimensioni rispetto agli spazi dei nomi più piccoli. Per gli spazi dei nomi di grandi dimensioni il tempo necessario per determinare quali file sono stati modificati può risultare superiore a 24 ore.

Per altre informazioni, vedere Sincronizzazione file di Azure metriche delle prestazioni e Sincronizzazione file di Azure destinazioni di scalabilità

Identità

Sincronizzazione file di Azure funziona con l'identità standard basata su ACTIVE Directory senza alcuna configurazione speciale oltre la configurazione della sincronizzazione. Quando si usa Sincronizzazione file di Azure, l'aspettativa generale è che la maggior parte degli accessi passa attraverso i server di memorizzazione nella cache Sincronizzazione file di Azure, anziché tramite la condivisione file di Azure. Poiché gli endpoint server si trovano in Windows Server e Windows Server supporta da molto tempo gli ACL di Active Directory e di Windows, non occorre fare altro oltre a verificare che i file server Windows registrati con il servizio di sincronizzazione archiviazione siano aggiunti a un dominio. Sincronizzazione file di Azure archivierà gli ACL nei file nella condivisione file di Azure e li replicherà in tutti gli endpoint server.

Anche se le modifiche apportate direttamente alla condivisione file di Azure richiederanno più tempo per la sincronizzazione con gli endpoint server nel gruppo di sincronizzazione, è anche possibile assicurarsi di poter applicare le autorizzazioni di Active Directory anche nella condivisione file direttamente nel cloud. A questo scopo, è necessario aggiungere il proprio account di archiviazione ad AD locale, esattamente come sono aggiunti a un dominio i file server Windows. Per altre informazioni sull'aggiunta dell'account di archiviazione a un dominio di Active Directory di proprietà del cliente, vedere Azure Files Active Directory overview (Panoramica di Active Directory per File di Azure).

Rete

L'agente di Sincronizzazione file di Azure comunica con il servizio di sincronizzazione archiviazione e la condivisione file di Azure tramite il protocollo FileREST e il protocollo REST di Sincronizzazione file di Azure, che usano entrambi HTTPS sulla porta 443. SMB non viene mai usato per caricare o scaricare dati tra Windows Server e la condivisione file di Azure. Poiché la maggior parte delle organizzazioni consente il traffico HTTPS sulla porta 443, come requisito per visitare la maggior parte dei siti Web, in genere non è necessaria una configurazione di rete speciale per distribuire Sincronizzazione file di Azure.

In base ai criteri dell'organizzazione o ai requisiti normativi univoci, potrebbe essere necessaria una comunicazione più restrittiva con Azure e pertanto Sincronizzazione file di Azure fornisce diversi meccanismi per configurare la rete. In base ai propri requisiti, è possibile:

• Effettuare il tunneling del traffico di sincronizzazione e di caricamento/download di file attraverso la rete VPN di Azure o ExpressRoute.
• Usare le funzionalità di File di Azure e Rete di Azure, ad esempio endpoint di servizio ed endpoint privati.
• Configurare Sincronizzazione file di Azure per supportare il proxy in uso nell'ambiente.
• Limitare l'attività di rete da Sincronizzazione file di Azure.

Per altre informazioni sulle Sincronizzazione file di Azure e sulla rete, vedere Sincronizzazione file di Azure considerazioni sulla rete.

Crittografia

Quando si usa Sincronizzazione file di Azure, esistono tre diversi livelli di crittografia da considerare: la crittografia dei dati inattivi di Windows Server, la crittografia dei dati in transito tra l'agente di Sincronizzazione file di Azure e Azure e la crittografia dei dati inattivi nella condivisione file di Azure.

Crittografia dei dati inattivi di Windows Server

Esistono due strategie per crittografare i dati in Windows Server che funzionano in generale con Sincronizzazione file di Azure: crittografia sottostante al file system, per crittografare il file system e tutti i dati scritti su di esso, e crittografia nel formato di file stesso. Questi metodi non si escludono a vicenda; possono essere usati insieme se lo scopo della crittografia è diverso.

Per fornire la crittografia sotto il file system, Windows Server offre la posta in arrivo BitLocker. BitLocker è completamente trasparente per Sincronizzazione file di Azure. Il motivo principale per usare un meccanismo di crittografia come BitLocker consiste nel impedire l'esfiltrazione fisica dei dati dal data center locale da un utente che ruba i dischi e impedire il trasferimento locale di un sistema operativo non autorizzato per eseguire letture/scritture non autorizzate nei dati. Per alte informazioni su BitLocker, vedere Panoramica di BitLocker.

I prodotti di terze parti che funzionano in modo analogo a BitLocker, per il fatto di essere sottostanti al volume NTFS, dovrebbero funzionare in modo completamente trasparente con Sincronizzazione file di Azure.

L'altro metodo principale per la crittografia dei dati consiste nel crittografare il flusso di dati del file quando l'applicazione salva il file. Alcune applicazioni potrebbero eseguire questa operazione in modo nativo, tuttavia questo in genere non è il caso. Azure Information Protection (AIP), Azure Rights Management Services (Azure RMS) e Active Directory RMS sono esempi di metodi per crittografare il flusso di dati del file. Il motivo principale per usare un meccanismo di crittografia come AIP/RMS è impedire l'esfiltrazione di dati dalla condivisione file da parte di utenti che li copiano in posizioni alternative, ad esempio in un'unità flash, o che li inviano tramite posta elettronica a un utente non autorizzato. Quando il flusso di dati di un file viene crittografato come parte del formato di file, il file continuerà a essere crittografato nella condivisione file di Azure.

Sincronizzazione file di Azure non interagisce con NTFS Encrypted File System (NTFS EFS) o soluzioni di crittografia di terze parti che si trovano sopra il file system, ma sotto il flusso di dati del file.

Crittografia dei dati in transito

L'agente di Sincronizzazione file di Azure comunica con il servizio di sincronizzazione archiviazione e la condivisione file di Azure tramite il protocollo FileREST e il protocollo REST di Sincronizzazione file di Azure, che usano entrambi HTTPS sulla porta 443. Sincronizzazione file di Azure non invia richieste non crittografate su HTTP.

Gli account di archiviazione di Azure contengono un'opzione per richiedere la crittografia in transito, abilitata per impostazione predefinita. Anche se l'opzione a livello di account di archiviazione è disabilitata, vale a dire che sono possibili connessioni non crittografate alle condivisioni file di Azure, Sincronizzazione file di Azure userà comunque soltanto canali crittografati per accedere alla condivisione file.

La crittografia in transito per l'account di archiviazione viene in genere disabilitata principalmente per supportare un'applicazione legacy che deve essere eseguita in un sistema operativo meno recente, ad esempio Windows Server 2008 R2 o una distribuzione Linux precedente, che comunica direttamente con una condivisione file di Azure. Se l'applicazione legacy comunica con la cache Windows Server della condivisione file, la modifica di questa impostazione non avrà alcun effetto.

È fortemente consigliabile verificare che la crittografia dei dati in transito sia abilitata.

Per altre informazioni sulla crittografia in transito, vedere Richiedere il trasferimento sicuro in Archiviazione di Azure.

Crittografia dei dati inattivi della condivisione file di Azure

Tutti i dati archiviati in File di Azure vengono crittografati quando sono inattivi usando la crittografia del servizio di archiviazione di Azure. La crittografia del servizio di archiviazione funziona in modo analogo a BitLocker in Windows in quanto i dati vengono crittografati sotto il livello del file system. Dal momento che i dati vengono crittografati sotto il file system della condivisione file di Azure, perché sono codificati su disco, non è necessario avere accesso alla chiave sottostante nel client per leggere o scrivere nella condivisione file di Azure. La crittografia dati inattivi si applica a entrambi i protocolli SMB e NFS.

Per impostazione predefinita, i dati archiviati in File di Azure vengono crittografati con chiavi gestite da Microsoft. Con le chiavi gestite da Microsoft, Microsoft detiene le chiavi per crittografare/decrittografare i dati ed è responsabile della loro rotazione a intervalli regolari. È anche possibile scegliere di gestire le proprie chiavi, in modo da controllare manualmente il processo di rotazione. Se si sceglie di crittografare le condivisioni file con chiavi gestite dal cliente, File di Azure è autorizzato ad accedere alle chiavi per soddisfare le richieste di lettura e scrittura ricevute dai client. Con le chiavi gestite dal cliente è possibile revocare questa autorizzazione in qualsiasi momento, ma questo significa che la condivisione file di Azure non sarà più accessibile tramite SMB o l'API REST per file.

File di Azure usa lo stesso schema di crittografia di altri servizi di archiviazione di Azure, ad esempio Archiviazione BLOB di Azure. Per altre informazioni sulla crittografia del servizio di archiviazione di Azure, vedere Crittografia del servizio di archiviazione di Azure per i dati inattivi.

Livelli di archiviazione

File di Azure offre due diversi livelli multimediali di archiviazione, SSD e HDD, che consentono di personalizzare le condivisioni in base ai requisiti di prestazioni e prezzo dello scenario:

• SSD (Premium): le condivisioni file Premium usano unità SSD (Solid State Drive) e offrono prestazioni elevate coerenti e bassa latenza, entro millisecondi a cifra singola per la maggior parte delle operazioni di I/O, per carichi di lavoro a elevato utilizzo di I/O. Le condivisioni file Premium sono adatte per una vasta gamma di carichi di lavoro, ad esempio database, hosting di siti Web e ambienti di sviluppo. Le condivisioni file Premium possono essere usate con entrambi i protocolli SMB (Server Message Block) e NFS (Network File System). Le condivisioni file Premium vengono distribuite nel tipo di account di archiviazione FileStorage e sono disponibili solo in un modello di fatturazione con provisioning. Per altre informazioni sul modello di fatturazione con provisioning per le condivisioni file Premium, vedere Informazioni sul provisioning per le condivisioni file Premium. Le condivisioni file Premium offrono un contratto di servizio con disponibilità superiore rispetto alle condivisioni file standard (vedere "File di Azure livello Premium").

• HDD (Standard): le condivisioni file Standard usano unità disco rigido (HDD) e offrono un'opzione di archiviazione conveniente per le condivisioni file per utilizzo generico. Le condivisioni file standard vengono distribuite nel tipo di account di archiviazione per utilizzo generico versione 2 (GPv2). Per informazioni sul contratto di servizio, vedere la pagina contratti di servizio di Azure (vedere "Account di archiviazione"). Le condivisioni file standard usano un modello con pagamento in base al consumo che fornisce prezzi basati sull'utilizzo. Il livello di accesso di una condivisione file consente di modificare i costi di archiviazione in base al costo delle operazioni di I/O al secondo per ottimizzare la fattura totale:

  • Le condivisioni file ottimizzate per le transazioni offrono i prezzi delle transazioni con costi più bassi per carichi di lavoro pesanti che non richiedono la bassa latenza offerta dalle condivisioni file Premium. Consigliato durante la migrazione dei dati a File di Azure.
  • Le condivisioni file ad accesso frequente offrono risorse di archiviazione bilanciate e prezzi delle transazioni per i carichi di lavoro con una buona misura di entrambi.
  • Le condivisioni file ad accesso sporadico offrono i prezzi di archiviazione più convenienti per carichi di lavoro a elevato utilizzo di archiviazione.

Quando si seleziona un livello multimediale per il carico di lavoro, prendere in considerazione i requisiti di prestazioni e utilizzo. Se il carico di lavoro richiede la latenza a cifra singola o se si usano supporti di archiviazione SSD in locale, il livello Premium è probabilmente la soluzione migliore. Se la bassa latenza non rappresenta un problema, come nel caso delle condivisioni di team montate in locale da Azure o memorizzate nella cache locale con Sincronizzazione file di Azure, l'archiviazione standard può essere una soluzione migliore dal punto di vista dei costi.

Dopo aver creato una condivisione file in un account di archiviazione, non è possibile spostarla in livelli esclusivi in diversi tipi di account di archiviazione. Ad esempio, per spostare una condivisione file ottimizzata per le transazioni nel livello Premium, è necessario creare una nuova condivisione file in un account di archiviazione FileStorage e copiare i dati dalla condivisione originale in una nuova condivisione file nell'account FileStorage. È consigliabile usare AzCopy per copiare dati tra condivisioni file di Azure, ma si possono usare anche strumenti come robocopy in Windows o rsync per macOS e Linux.

Per altre informazioni, vedere Informazioni sulla fatturazione di File di Azure.

disponibilità Sincronizzazione file di Azure'area

Per la disponibilità a livello di area, vedere Prodotti disponibili in base all'area.

Le aree seguenti richiedono di richiedere l'accesso a Archiviazione di Azure prima di poter usare Sincronizzazione file di Azure con esse:

• Francia meridionale
• Sudafrica occidentale
• Emirati Arabi Uniti centrali

Per richiedere l'accesso a queste aree, seguire la procedura descritta in questo documento.

Ridondanza

Per proteggere i dati nelle condivisioni file di Azure da perdita o danneggiamento dei dati, File di Azure archivia più copie di ogni file durante la scrittura. A seconda dei requisiti, è possibile selezionare diversi gradi di ridondanza. File di Azure supporta attualmente le opzioni di ridondanza dei dati seguenti:

• Archiviazione con ridondanza locale: con archiviazione con ridondanza locale, ogni file viene archiviato tre volte all'interno di un cluster di archiviazione di Azure. Ciò protegge dalla perdita di dati a causa di errori hardware, ad esempio un'unità disco non valida. Tuttavia, se all'interno del data center si verifica un'emergenza come, ad esempio un incendio o un alluvione, tutte le repliche dell'account di archiviazione che usano l'archiviazione con ridondanza locale potrebbero essere perse o irrecuperabili.
• Archiviazione con ridondanza della zona:con archiviazione con ridondanza della zona, vengono archiviate tre copie di ogni file. Tuttavia, queste copie sono fisicamente isolate in tre cluster di archiviazione distinti in zone di disponibilità di Azure diverse. Le zone di disponibilità sono località fisiche esclusive all'interno di un'area di Azure. Ogni zona è costituita da uno o più data center dotati di impianti indipendenti per l'alimentazione, il raffreddamento e la connettività di rete. Una scrittura nell'archiviazione non viene accettata finché non viene scritta nei cluster di archiviazione in tutte e tre le zone di disponibilità.
• Archiviazione con ridondanza geografica: con l'archiviazione con ridondanza geografica sono disponibili due aree, un'area primaria e un'area secondaria. I file vengono archiviati tre volte all'interno di un cluster di archiviazione di Azure nell'area primaria. Le scritture vengono replicate in modo asincrono in un'area secondaria definita da Microsoft. L'archiviazione con ridondanza geografica fornisce sei copie dei dati distribuiti tra due aree di Azure. In caso di grave emergenza, ad esempio la perdita permanente di un'area di Azure a causa di un'emergenza naturale o di un altro evento simile, Microsoft eseguirà un failover. In questo caso, il database secondario diventa il database primario, che gestisce tutte le operazioni. Poiché la replica tra le aree primarie e secondarie è asincrona, in caso di emergenza grave, i dati non ancora replicati nell'area secondaria andranno persi. È anche possibile eseguire un failover manuale di un account di archiviazione con ridondanza geografica.
• Archiviazione con ridondanza geografica della zona: è possibile considerare L'archiviazione con ridondanza della zona come archiviazione con ridondanza geografica, ma con ridondanza geografica. Con l'archiviazione con ridondanza della zona, i file vengono archiviati tre volte in tre cluster di archiviazione distinti nell'area primaria. Tutte le scritture vengono replicate in modo asincrono in un'area secondaria definita da Microsoft. Il processo di failover per l'archiviazione con ridondanza geografica della zona funziona come l'archiviazione con ridondanza geografica.

Le condivisioni file standard di Azure fino a 5 TiB supportano tutti e quattro i tipi di ridondanza. Le condivisioni file standard superiori a 5 TiB supportano solo l'archiviazione con ridondanza locale e archiviazione con ridondanza della zona. Le condivisioni file di Azure Premium supportano solo archiviazione con ridondanza locale e archiviazione con ridondanza della zona.

Gli account di archiviazione per utilizzo generico versione 2 (GPv2) offrono due altre opzioni di ridondanza che File di Azure non supportano: l'archiviazione con ridondanza geografica accessibile in lettura (RA-GRS) e l'archiviazione con ridondanza geografica accessibile in lettura (RA-GZRS). È possibile effettuare il provisioning delle condivisioni file di Azure negli account di archiviazione con queste opzioni impostate, ma File di Azure non supporta la lettura dall'area secondaria. Le condivisioni file di Azure distribuite in account di archiviazione RA-GRS o RA-GZRS vengono fatturate rispettivamente come archiviazione con ridondanza geografica o archiviazione con ridondanza geografica della zona.

Migrazione

Se si dispone di un file server Windows 2012R2 o versione successiva, Sincronizzazione file di Azure può essere installato direttamente sul posto, senza la necessità di spostare i dati in un nuovo server. Se si prevede di eseguire la migrazione a un nuovo file server Windows come parte dell'adozione di Sincronizzazione file di Azure o se i dati si trovano attualmente in Archiviazione connessa alla rete,esistono diversi approcci di migrazione possibili per l'uso di Sincronizzazione file di Azure con questi dati. L'approccio di migrazione da scegliere dipende dalla posizione in cui risiedono i dati.

Per indicazioni dettagliate, vedere l'articolo panoramica sulla migrazione delle Sincronizzazione file di Azure e delle condivisioni file di Azure.

Antivirus

Poiché l'antivirus funziona analizzando i file per codice dannoso noto, un prodotto antivirus potrebbe causare il richiamo dei file a livelli, causando costi di uscita elevati. I file a livelli hanno il set di attributi FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS di Windows sicuro e consigliamo di consultare il fornitore del software per informazioni su come configurare la soluzione per ignorare la lettura dei file con questo set di attributi (molti lo fanno automaticamente).

Le soluzioni antivirus Microsoft, Windows Defender e System Center Endpoint Protection (SCEP), escludono automaticamente dalla lettura i file con questo attributo. Un test su entrambe le soluzioni ha identificato un problema secondario: quando si aggiunge un server a un gruppo di sincronizzazione esistente, i file di dimensioni inferiori a 800 byte vengono richiamati (scaricati) nel nuovo server. Questi file rimarranno nel nuovo server e non verranno a livelli perché non soddisfano il requisito di dimensioni di suddivisione in livelli (>64 kb).

Backup

Se è abilitata la suddivisione in livelli nel cloud, non è consigliabile usare soluzioni che eseerebbero direttamente il backup dell'endpoint server o di una macchina virtuale in cui si trova l'endpoint server. La suddivisione in livelli nel cloud fa sì che solo un subset dei dati venga archiviato nell'endpoint server, con il set di dati completo che risiede nella condivisione file di Azure. A seconda della soluzione di backup usata, i file a livelli verranno ignorati e non sottoposti a backup (perché hanno impostato l'attributo FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS ) oppure verranno richiamati su disco, causando addebiti elevati in uscita. È consigliabile usare una soluzione di backup cloud per eseguire direttamente il backup della condivisione file di Azure. Per altre informazioni, vedere Informazioni sul backup della condivisione file di Azure o contattare il provider di backup per verificare se supportano il backup delle condivisioni file di Azure.

Se si preferisce usare una soluzione di backup locale, i backup devono essere eseguiti in un server nel gruppo di sincronizzazione con cloud a livelli disabilitato e assicurarsi che non siano presenti file a livelli. Quando si esegue un ripristino, usare le opzioni di ripristino a livello di volume o a livello di file. I file ripristinati usando l'opzione di ripristino a livello di file verranno sincronizzati con tutti gli endpoint del gruppo di sincronizzazione e i file esistenti verranno sostituiti con la versione ripristinata dal backup. I ripristini a livello di volume non sostituiranno le versioni più recenti dei file nella condivisione file di Azure o in altri endpoint server.

Classificazione dei dati

Se è installato software di classificazione dei dati, l'abilitazione del cloud a livelli potrebbe comportare un aumento dei costi per due motivi:

1. Con la suddivisione in livelli cloud abilitata, i file più attivi vengono memorizzati nella cache in locale e i file più interessanti vengono archiviati a livelli nella condivisione file di Azure nel cloud. Se la classificazione dei dati analizza regolarmente tutti i file nella condivisione file, i file a livelli nel cloud devono essere richiamati ogni volta che vengono analizzati.

2. Se il software di classificazione dei dati usa i metadati nel flusso di dati di un file, il file deve essere richiamato completamente per consentire al software di visualizzare la classificazione.

Questi aumenti nel numero di richiami e nella quantità di dati richiamati possono aumentare i costi.

Criteri di aggiornamento dell'agente Sincronizzazione file di Azure

L'agente Sincronizzazione file di Azure viene aggiornato a intervalli regolari per aggiungere nuove funzionalità e risolvere eventuali problemi. Si consiglia di aggiornare l'agente Sincronizzazione file di Azure perché sono disponibili nuove versioni.

Confronto tra versioni principali e secondarie dell'agente

• Le versioni principali dell'agente contengono spesso nuove funzionalità e hanno un numero crescente come prima parte del numero di versione. Ad esempio 17.0.0.0.
• Le versioni secondarie dell'agente sono denominate anche "patch" e vengono rilasciate con maggiore frequenza rispetto alle versioni principali. Spesso contengono correzioni di bug e miglioramenti di entità minore, ma non nuove funzionalità. Ad esempio 17.2.0.0.

Percorsi di aggiornamento

Esistono quattro modi approvati e testati per installare gli aggiornamenti dell'agente Sincronizzazione file di Azure.

1. Usare la funzionalità di aggiornamento automatico dell'agente Sincronizzazione file di Azure per installare gli aggiornamenti dell'agente. L'agente Sincronizzazione file di Azure eseguirà l'aggiornamento automatico. È possibile scegliere di installare la versione più recente dell'agente quando disponibile o aggiornare quando l'agente attualmente installato è prossimo alla scadenza. Per altre informazioni vedere Gestione automatica del ciclo di vita dell'agente.
2. Configurare Microsoft Update per scaricare e installare automaticamente gli aggiornamenti dell'agente. Si consiglia di scaricare tutti gli aggiornamenti di Sincronizzazione file di Azure per poter accedere alle correzioni più recenti per l'agente server. Microsoft Update semplifica questo processo scaricando e installando gli aggiornamenti automaticamente.
3. Usare AfsUpdater.exe per scaricare e installare gli aggiornamenti dell'agente. Il file AfsUpdater.exe si trova nella directory di installazione dell'agente. Fare doppio clic sul file eseguibile per scaricare e installare gli aggiornamenti dell'agente. A seconda della versione di rilascio, può essere necessario riavviare il server.
4. Applicare una patch a un agente Sincronizzazione file di Azure esistente usando un file di patch di Microsoft Update o un eseguibile con estensione msp. L'aggiornamento più recente di Sincronizzazione file di Azure può essere scaricato da Microsoft Update Catalog. Eseguendo un eseguibile .msp si aggiorna l'installazione di Sincronizzazione file di Azure con lo stesso metodo usato automaticamente da Microsoft Update. Applicando una patch di Microsoft Update verrà eseguito un aggiornamento sul posto di un'installazione di Sincronizzazione file di Azure.
5. Scaricare il programma di installazione più recente dell'agente Sincronizzazione file di Azure dall' Area download Microsoft. Per aggiornare un'installazione esistente dell'agente Sincronizzazione file di Azure, disinstallare la versione precedente e quindi installare la versione più recente dal programma di installazione scaricato. Il programma di installazione di Sincronizzazione file di Azure mantiene la registrazione del server, i gruppi di sincronizzazione e tutte le altre impostazioni.

Gestione automatica del ciclo di vita dell'agente

L'agente Sincronizzazione file di Azure eseguirà l'aggiornamento automatico. È possibile selezionare una delle due modalità e specificare una finestra di manutenzione in cui verrà eseguito il tentativo di aggiornamento nel server. Questa funzionalità è progettata per facilitare la gestione del ciclo di vita dell'agente fornendo una protezione che impedisce la scadenza dell'agente oppure consentendo un'impostazione senza problemi per mantenersi aggiornati.

1. Per impostazione predefinita viene eseguito il tentativo di impedire la scadenza dell'agente. Entro 21 giorni dalla data di scadenza pubblicata di un agente, l'agente tenterà di eseguire l'aggiornamento automatico. Verrà avviato un tentativo di aggiornamento una volta alla settimana nei 21 giorni prima della scadenza e nella finestra di manutenzione selezionata. Questa opzione non elimina la necessità di installare regolarmente le patch di Microsoft Update.
2. Facoltativamente, è possibile selezionare l’opzione di aggiornamento automatico dell’agente appena è disponibile una nuova versione agente (attualmente non applicabile ai server cluster). Questo aggiornamento verrà eseguito durante la finestra di manutenzione selezionata e consente al server di sfruttare le nuove funzionalità e i miglioramenti appena sono disponibili a livello generale. Questa è l'impostazione senza problemi consigliata, quella che permette al server di ricevere le principali versioni agente e di installare regolarmente le patch di aggiornamento regolari. Ogni agente è rilasciato con la qualità disponibilità generale. Se si seleziona questa opzione, Microsoft distribuirà in anteprima la versione agente più recente. I server cluster sono esclusi. Una volta completata la distribuzione di versioni di anteprima, l'agente diventerà disponibile anche in Microsoft Update e nell' Area download Microsoft.

Modifica dell'impostazione di aggiornamento automatico

Se è necessario apportare modifiche, le istruzioni seguenti descrivono come modificare le impostazioni dopo aver completato il programma di installazione.

Aprire una console di PowerShell e passare alla directory in cui è installato l'agente Sincronizzazione, quindi importare i cmdlet del server. Per impostazione predefinita viene visualizzata qualcosa di analogo a quanto segue:

cd 'C:\Program Files\Azure\StorageSyncAgent'
Import-Module -Name .\StorageSync.Management.ServerCmdlets.dll

È possibile eseguire Get-StorageSyncAgentAutoUpdatePolicy per controllare l'impostazione di criteri corrente e decidere se modificarla.

Per modificare l'impostazione di criteri corrente nella traccia di aggiornamento posticipato è possibile usare:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

Per modificare l'impostazione di criteri corrente nella traccia di aggiornamento immediato è possibile usare:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest -Day <day> -Hour <hour>

Garanzie relative al ciclo di vita dell'agente e alla gestione del cambiamento

Sincronizzazione file di Azure è un servizio cloud che introduce continuamente nuove funzionalità e miglioramenti. Ciò significa che una specifica versione dell'agente Sincronizzazione file di Azure può essere supportata solo per un periodo di tempo limitato. Per semplificare la distribuzione le regole seguenti garantiscono tempo e notifiche sufficienti per supportare gli aggiornamenti dell'agente nel processo di gestione delle modifiche:

• Le versioni principali dell'agente sono supportate per almeno sei mesi dalla data di rilascio iniziale.
• Microsoft garantisce che una sovrapposizione di almeno tre mesi tra il supporto delle versioni principali dell'agente.
• Per i server registrati che usano un agente prossimo alla scadenza vengono generati avvisi almeno tre mesi prima della scadenza. È possibile verificare se un server registrato sta usando una versione precedente dell'agente nella sezione dei server registrati di un servizio di sincronizzazione archiviazione.
• La durata di una versione secondaria dell'agente è legata alla versione principale associata. Ad esempio, quando la versione agente 17.0.0.0 viene impostata per scadere, le versioni agente 17.*.*.* vengono impostate tutte per scadere insieme.

Passaggi successivi

• Impostazioni di proxy e firewall di Sincronizzazione file di Azure
• Come distribuire i file di Azure
• Come distribuire Sincronizzazione file di Azure
• Monitorare Sincronizzazione file di Azure