Pianificare la distribuzione di File di Azure

È possibile distribuire File di Azure in due modi principali: montando direttamente le condivisioni file di Azure serverless o memorizzando nella cache le condivisioni file di Azure in locale tramite Sincronizzazione file di Azure. Le considerazioni sulla distribuzione variano in base all'opzione scelta.

• Montaggio diretto di una condivisione file di Azure: Poiché Azure Files fornisce l'accesso tramite SMB (Server Message Block) o NFS (Network File System), è possibile montare le condivisioni file di Azure in locale o nel cloud utilizzando i client SMB o NFS standard disponibili nel sistema operativo. 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. Azure File Sync trasforma un server Windows Server locale (o su cloud) in una cache rapida per la condivisione di file Azure SMB.

Questo articolo riguarda principalmente le considerazioni sulla distribuzione per la distribuzione di una condivisione file di Azure da montare direttamente da un client locale o cloud. Per pianificare una distribuzione di Azure File Sync, vedere Pianificazione di una distribuzione di Azure File Sync.

Protocolli disponibili

File di Azure offre due protocolli di file system riconosciuti a livello industriale per montare le condivisioni file Azure: il protocollo Server Message Block (SMB) e il protocollo Network File System (NFS), permettendoti di scegliere il protocollo che meglio si adatta al tuo carico di lavoro. Le condivisioni file di Azure non supportano entrambi i protocolli SMB e NFS nella stessa condivisione file, anche se è possibile creare condivisioni file di Azure SMB e NFS all'interno dello stesso account di archiviazione.

Con le condivisioni file SMB e NFS, File di Azure offre condivisioni file di livello aziendale che possono aumentare le prestazioni per soddisfare le esigenze di archiviazione e possono essere accessibili simultaneamente da migliaia di client.

Concetti relativi alla gestione

Le condivisioni file di Azure vengono distribuite in account di archiviazione, ovvero oggetti di primo livello che rappresentano un pool di archiviazione condiviso. Gli account di archiviazione possono essere usati per implementare più condivisioni file, nonché altre risorse di archiviazione in base al tipo di account di archiviazione. 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 gli obiettivi di scalabilità e prestazioni di Azure Files.

Esistono due tipi principali di account di archiviazione usati per le distribuzioni di File di Azure:

• Account di archiviazione con provisioning: gli account di archiviazione con provisioning sono distinti usando il FileStorage tipo di account di archiviazione. Gli account di archiviazione con provisioning consentono di distribuire condivisioni file provisionate su hardware basato su unità SSD o HDD. Gli account di archiviazione con provisioning possono essere usati solo per archiviare condivisioni di file Azure. Le condivisioni file NFS possono essere distribuite solo negli account di archiviazione di cui è stato effettuato il provisioning nel livello multimediale SSD. Si consiglia di utilizzare gli account di archiviazione forniti per tutte le nuove distribuzioni di Azure Files.
• Account di archiviazione con pagamento in base al consumo: gli account di archiviazione con pagamento in base al consumo sono differenziati usando il StorageV2 tipo di account. Gli account di archiviazione con pagamento in base al consumo consentono di distribuire condivisioni file con pagamento in base al consumo su hardware basato su HDD. 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.

Identità

Per accedere a una condivisione file di Azure, l'utente della condivisione file deve essere autenticato e autorizzato ad accedere alla condivisione. Questa operazione viene eseguita in base all'identità dell'utente che accede alla condivisione file. File di Azure supporta i metodi di autenticazione seguenti:

• Servizi di dominio Active Directory locali (Active Directory Domain Services o Active Directory Domain Services locali): gli account di archiviazione di Azure possono essere aggiunti tramite dominio a un Active Directory Domain Services di proprietà del cliente, proprio come un file server Windows Server o un dispositivo NAS. È possibile distribuire un controller di dominio locale, in una macchina virtuale di Azure o anche come macchina virtuale in un altro provider di servizi cloud; File di Azure è indipendente dalla posizione in cui è ospitato il controller di dominio. Dopo che un account di archiviazione è aggiunto a un dominio, l'utente finale può montare una condivisione file con l'account utente con cui ha eseguito l'accesso al PC. L'autenticazione basata su ACTIVE Directory usa il protocollo di autenticazione Kerberos.
• Servizi di dominio Microsoft Entra: Microsoft Entra Domain Services fornisce un controller di dominio gestito da Microsoft che può essere usato per le risorse di Azure. L'aggiunta di un dominio all'account di archiviazione a Microsoft Entra Domain Services offre vantaggi simili a quelli dell'aggiunta del dominio a Active Directory Domain Services di proprietà del cliente. Questa opzione di distribuzione è particolarmente utile per gli scenari di migrazione dell'applicazione che richiedono autorizzazioni basate su Active Directory. Poiché Microsoft Entra Domain Services fornisce l'autenticazione basata su AD, questa opzione usa anche il protocollo di autenticazione Kerberos.
• Microsoft Entra Kerberos per le identità ibride: Microsoft Entra Kerberos consente di usare Microsoft Entra ID per autenticare le identità utente ibride, che sono identità di ACTIVE Directory locali sincronizzate con il cloud. Questa configurazione usa Microsoft Entra ID per rilasciare ticket Kerberos per accedere alla condivisione file con il protocollo SMB. Ciò significa che gli utenti finali possono accedere alle condivisioni file di Azure tramite Internet senza richiedere connettività di rete ai controller di dominio da macchine virtuali aggiunte a Microsoft Entra ibrido e Microsoft Entra.
• Autenticazione di Active Directory su client SMB per Linux: File di Azure supporta l'autenticazione basata su identità su client SMB per Linux usando il protocollo di autenticazione Kerberos tramite Servizi di dominio Active Directory o Microsoft Entra Domain Services.
• Chiave dell'account di archiviazione di Azure: le condivisioni file di Azure possono anche essere montate con una chiave dell'account di archiviazione di Azure. Per montare una condivisione file in questo modo, il nome dell'account di archiviazione viene usato come nome utente e la chiave dell'account di archiviazione viene usata come password. L'uso della chiave dell'account di archiviazione per montare la condivisione file di Azure è in effetti un'operazione di amministratore, perché la condivisione file montata dispone di autorizzazioni complete per tutti i file e le cartelle nella condivisione, anche se hanno ACL. Quando si usa la chiave dell'account di archiviazione per montare su SMB, viene usato il protocollo di autenticazione NTLMv2. Se si intende usare la chiave dell'account di archiviazione per accedere alle condivisioni file di Azure, è consigliabile usare endpoint privati o endpoint di servizio come descritto nella sezione Rete .

Per i clienti che eseguono la migrazione da file server locali o che creano nuove condivisioni file in Azure Files (File di Azure) intendendo farle comportare come dei file server Windows o appliance NAS, l'opzione consigliata è aggiungere l'account di archiviazione ai servizi di dominio Active Directory (AD DS) di proprietà del cliente. Per altre informazioni sull'aggiunta di un dominio all'account di archiviazione a servizi di dominio Active Directory di proprietà del cliente, vedere Panoramica - Autenticazione di Servizi di dominio Active Directory locale tramite SMB per le condivisioni file di Azure.

Rete

Il montaggio diretto della condivisione file di Azure richiede spesso alcune considerazioni sulla configurazione di rete perché:

• La porta usata dalle condivisioni file SMB per la comunicazione, la porta 445, è spesso bloccata da molte organizzazioni e provider di servizi Internet (ISP) per il traffico in uscita (Internet).
• Le condivisioni file NFS si basano sull'autenticazione a livello di rete e sono quindi accessibili solo tramite reti con restrizioni. L'uso di una condivisione file NFS richiede sempre un livello di configurazione di rete.

Per configurare la rete, File di Azure fornisce un endpoint pubblico accessibile da Internet e l'integrazione con funzionalità di rete di Azure come gli endpoint di servizio, che consentono di limitare l'endpoint pubblico alle reti virtuali specificate e agli endpoint privati, che forniscono all'account di archiviazione un indirizzo IP privato dall'interno di uno spazio indirizzi IP della rete virtuale. Anche se non sono previsti costi aggiuntivi per l'uso di endpoint pubblici o endpoint di servizio, le tariffe standard per l'elaborazione dei dati si applicano agli endpoint privati.

Ciò significa che è necessario considerare le configurazioni di rete seguenti:

• Se il protocollo richiesto è SMB e tutto l'accesso tramite SMB proviene dai client in Azure, non è necessaria alcuna configurazione di rete speciale.
• Se il protocollo richiesto è SMB e l'accesso proviene dai client locali, è necessaria una connessione VPN o ExpressRoute dall'ambiente locale alla rete di Azure, con File di Azure esposto nella rete interna usando endpoint privati.
• Se il protocollo richiesto è NFS, è possibile usare endpoint di servizio o endpoint privati per limitare la rete alle reti virtuali specificate. Se è necessario un indirizzo IP statico e/o il carico di lavoro richiede disponibilità elevata, usare un endpoint privato. Con gli endpoint di servizio, un evento raro, ad esempio un'interruzione della zona, potrebbe causare la modifica dell'indirizzo IP sottostante dell'account di archiviazione. Mentre i dati sono ancora disponibili nella condivisione file, il client richiederebbe un rimontaggio della condivisione.

Per altre informazioni su come configurare la rete per File di Azure, vedere considerazioni sulla rete di Azure Files.

Oltre a connettersi direttamente alla condivisione file usando l'endpoint pubblico o usando una connessione VPN/ExpressRoute con un endpoint privato, SMB offre una strategia di accesso client aggiuntiva: SMB su QUIC. SMB su QUIC offre la configurazione zero "SMB VPN" per l'accesso SMB tramite il protocollo di trasporto QUIC. Anche se File di Azure non supporta direttamente SMB su QUIC, è possibile creare una cache leggera delle condivisioni file di Azure in una macchina virtuale Windows Server 2022 Azure Edition usando Sincronizzazione file di Azure. Per altre informazioni su questa opzione, vedere SMB su QUIC con Sincronizzazione file di Azure.

Crittografia

File di Azure supporta due diversi tipi di crittografia:

• Crittografia in transito, correlata alla crittografia usata durante il montaggio/accesso alla condivisione file di Azure
• Crittografia dei dati inattivi, che si riferisce al modo in cui i dati vengono crittografati quando vengono archiviati su disco

Crittografia dei dati in transito

Per impostazione predefinita, la crittografia in transito è abilitata per tutti gli account di archiviazione di Azure. Ciò significa che quando si monta una condivisione file tramite SMB o lo si accede tramite il protocollo FileREST (ad esempio tramite il portale di Azure, PowerShell/CLI o Azure SDK), File di Azure consente la connessione solo se viene stabilita con SMB 3.x con crittografia o HTTPS. I client che non supportano SMB 3.x o client che supportano SMB 3.x ma non la crittografia SMB non potranno montare la condivisione file di Azure se la crittografia in transito è abilitata. Per altre informazioni sui sistemi operativi che supportano SMB 3.x con crittografia, vedere la documentazione per Windows, macOS e Linux. Tutte le versioni correnti di PowerShell, interfaccia della riga di comando e SDK supportano HTTPS.

È possibile disabilitare la crittografia in transito per un account di archiviazione di Azure. Quando la crittografia è disabilitata, File di Azure consente anche SMB 2.1 e SMB 3.x senza crittografia e chiamate API FileREST non crittografate su HTTP. Il motivo principale per disabilitare la crittografia in transito consiste nel supportare un'applicazione legacy che deve essere eseguita in un sistema operativo precedente, ad esempio Windows Server 2008 R2 o una distribuzione Linux precedente. File di Azure consente solo connessioni SMB 2.1 all'interno della stessa area di Azure della condivisione file di Azure. Un client SMB 2.1 all'esterno dell'area di Azure della condivisione file di Azure, ad esempio in locale o in un'area di Azure diversa, non sarà in grado di accedere alla condivisione file.

È 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 di dati inattivi

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 cifratura a riposo 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.

Protezione dei dati

Azure Files ha un approccio multi-strato per assicurare che i tuoi dati siano sottoposti a backup, recuperabili in caso di necessità e protetti dalle minacce alla sicurezza. Consulta Panoramica sulla protezione dei dati di Azure Files.

Eliminazione morbida

L'eliminazione temporanea è un'impostazione a livello di account di archiviazione che consente di ripristinare la condivisione file quando viene eliminata accidentalmente. Quando una condivisione file viene eliminata, passa a uno stato eliminato temporaneamente anziché essere cancellata in modo permanente. È possibile configurare la quantità di tempo di ripristino delle condivisioni eliminate temporaneamente prima che vengano eliminate definitivamente e annullare l'eliminazione della condivisione in qualsiasi momento durante questo periodo di conservazione.

L'eliminazione temporanea è abilitata per impostazione predefinita per i nuovi account di archiviazione. Se si dispone di un flusso di lavoro in cui l'eliminazione della condivisione è comune e prevista, è possibile decidere di avere un breve periodo di conservazione o di non abilitare affatto l'eliminazione temporanea.

Per altre informazioni sull'eliminazione temporanea, vedere Impedire l'eliminazione accidentale dei dati.

Copia di Sicurezza

È possibile eseguire il backup della condivisione file di Azure tramite istantanee di condivisione, che sono copie temporizzate di sola lettura della condivisione. Gli snapshot sono incrementali, ovvero contengono solo la quantità di dati modificata rispetto allo snapshot precedente. È possibile avere fino a 200 snapshot per ogni condivisione file e conservarli per un massimo di 10 anni. È possibile creare manualmente snapshot nel portale di Azure, tramite PowerShell o l'interfaccia della riga di comando oppure è possibile usare Backup di Azure.

Backup di Azure per condivisioni file di Azure gestisce la pianificazione e la conservazione degli snapshot. Le funzionalità GFS (nonno-padre-figlio) indicano che è possibile creare snapshot giornalieri, settimanali, mensili e annuali, ognuno con il proprio periodo di conservazione distinto. Backup di Azure gestisce anche l'abilitazione dell'eliminazione temporanea e apporta un blocco di eliminazione su un account di archiviazione non appena al suo interno viene configurata una condivisione di file per il backup. Infine, Backup di Azure offre alcune funzionalità chiave di monitoraggio e avviso che consentono ai clienti di avere una visualizzazione consolidata del proprio patrimonio di backup.

È possibile eseguire ripristini sia a livello di elemento che a livello di condivisione nel portale di Azure usando Backup di Azure. È sufficiente scegliere il punto di ripristino (uno snapshot specifico), il file o la directory specifica, se pertinente, e quindi il percorso (originale o alternativo) in cui si vuole eseguire il ripristino. Il servizio di backup gestisce la copia dei dati dello snapshot e mostra lo stato di avanzamento del ripristino nel portale.

Proteggere File di Azure con Microsoft Defender per Archiviazione

Microsoft Defender per Archiviazione è un livello nativo di Azure di intelligence per la sicurezza che rileva potenziali minacce agli account di archiviazione. Offre sicurezza completa analizzando i dati di telemetria del piano dati e del piano di controllo generati da File di Azure. Usa funzionalità avanzate di rilevamento delle minacce basate su Microsoft Threat Intelligence per fornire avvisi di sicurezza contestuali, inclusi i passaggi per attenuare le minacce rilevate e prevenire attacchi futuri.

Defender per Storage analizza continuamente il flusso di telemetria generato da File di Azure. Quando vengono rilevate attività potenzialmente dannose, vengono generati avvisi di sicurezza. Questi avvisi vengono visualizzati in Microsoft Defender per il cloud, insieme ai dettagli delle attività sospette, dei passaggi di indagine, delle azioni di correzione e delle raccomandazioni sulla sicurezza.

Defender per Archiviazione rileva malware noto, ad esempio ransomware, virus, spyware e altri malware caricati in un account di archiviazione in base all'hash completo dei file (supportato solo per l'API REST). Ciò consente di impedire che il malware entri nell'organizzazione e si distribuirà a più utenti e risorse. Consulta Comprendere le differenze tra la scansione dei malware e l'analisi della reputazione degli hash.

Defender per Archiviazione non accede ai dati dell'account di archiviazione e non influisce sulle prestazioni. È possibile abilitare Microsoft Defender per Archiviazione a livello di sottoscrizione (scelta consigliata) o a livello di risorsa.

Livelli di archiviazione

File di Azure offre due diversi livelli di archiviazione, dischi a stato solido (SSD) e dischi rigidi (HDD), che consentono di adattare le condivisioni secondo le esigenze di prestazioni e costo del vostro scenario.

• SSD (Premium): le condivisioni file SSD offrono prestazioni elevate coerenti e bassa latenza, entro millisecondi a cifra singola per la maggior parte delle operazioni di I/O, per i carichi di lavoro a elevato utilizzo di I/O. Le condivisioni file SSD sono adatte a un'ampia gamma di carichi di lavoro, ad esempio database, hosting di siti Web e ambienti di sviluppo. Le condivisioni file SSD possono essere usate sia con protocolli SMB (Server Message Block) che NFS (Network File System). Le condivisioni file SSD sono disponibili nel modello di fatturazione provisioned v1. Le condivisioni file SSD offrono un contratto di servizio con disponibilità superiore rispetto alle condivisioni file HDD (vedere "File di Azure livello Premium").

• HDD (standard): le condivisioni file HDD offrono un'opzione di archiviazione conveniente per le condivisioni file per utilizzo generico. Condivisioni file HDD disponibili con i modelli di fatturazione con pagamento in base al consumo e versione 2 di cui è stato effettuato il provisioning per le nuove distribuzioni di condivisione file. Per informazioni sugli SLA, vedere la pagina degli accordi sul livello di servizio di Azure (vedere "Account di archiviazione").

Quando si seleziona un livello di archiviazione multimediale per il proprio carico di lavoro, è importante valutare 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, le condivisioni file SSD sono probabilmente la soluzione migliore. Se la bassa latenza non rappresenta un problema significativo, ad esempio nel caso di condivisioni del team montate localmente da Azure o memorizzate nella cache in locale usando Azure File Sync, le condivisioni file HDD possono essere una soluzione più conveniente dal punto di vista dei costi.

Dopo aver creato una condivisione file in un account di archiviazione, non è possibile spostarla direttamente in un livello multimediale diverso. Ad esempio, per spostare una condivisione file HDD nel livello multimediale SSD, è necessario creare una nuova condivisione file SSD e copiare i dati dalla condivisione originale alla nuova condivisione file. Consulta Eseguire la migrazione di file da una condivisione file a un'altra

Per altre informazioni sui livelli multimediali SSD e HDD, vedere Informazioni sulla fatturazione di File di Azure e Informazioni sulle prestazioni di File di Azure.

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 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 di zona (ZRS): Con la ridondanza di 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. Un'operazione di 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 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. La ridondanza geografica fornisce sei copie dei dati distribuiti tra due aree di Azure. Se si verifica un'emergenza grave, 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, se si verifica un'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: con ridondanza geografica 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 la ridondanza GeoZone funziona nello stesso modo della ridondanza geografica.

Le condivisioni file HDD supportano tutti e quattro i tipi di ridondanza. Le condivisioni di file su SSD supportano solo LRS e ZRS.

Gli account di archiviazione con pagamento in base al consumo offrono altre due altre opzioni di ridondanza che File di Azure non supporta: 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 di condivisioni file di Azure in 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 un account di archiviazione RA-GRS o RA-GZRS vengono fatturate rispettivamente come Geo o GeoZona.

Per altre informazioni sulla ridondanza, vedere File di Azure - ridondanza dei dati.

Disponibilità di condivisioni file SSD ridondanti tra zone

Le condivisioni file SSD con ridondanza della zona sono disponibili per un subset di aree di Azure.

Ripristino di emergenza e failover

In caso di interruzione del servizio a livello di area non pianificata, è necessario disporre di un piano di ripristino di emergenza per le condivisioni file di Azure. Per comprendere i concetti e i processi coinvolti nel ripristino di emergenza e failover dell'account di archiviazione, vedere Ripristino di emergenza e failover per File di Azure.

Migrazione

In molti casi, non verrà stabilita una nuova condivisione file net per l'organizzazione, ma si eseguirà invece la migrazione di una condivisione file esistente da un file server locale o da un dispositivo NAS a File di Azure. Scegliere la strategia e lo strumento di migrazione corretti per lo scenario è importante per il successo della migrazione.

L'articolo di panoramica della migrazione illustra brevemente le nozioni di base e contiene una tabella che conduce alle guide alla migrazione che probabilmente coprono lo scenario.

Passaggi successivi

• Planning for an Azure File Sync Deployment (Pianificazione della distribuzione di Sincronizzazione file di Azure)
• Distribuzione di File di Azure
• Distribuzione di Azure File Sync
• Consulta l'articolo di panoramica sulla migrazione per trovare la guida alla migrazione per il tuo scenario