Condividi tramite

Pianificare la distribuzione di File di Azure

  • Articolo

È 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 usando Sincronizzazione file di Azure. Le considerazioni sulla distribuzione variano in base all'opzione scelta.

  • Montaggio diretto di una condivisione file di Azure: poiché File di Azure fornisce l'accesso SMB (Server Message Block) o NFS (Network File System), è possibile montare condivisioni file di Azure in locale o nel cloud usando 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. Sincronizzazione file di Azure trasforma un server Windows Server locale (o cloud) in una cache rapida della condivisione file di 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 Sincronizzazione file di Azure, vedere Pianificazione di una distribuzione Sincronizzazione file di Azure.

Protocolli disponibili

File di Azure offre due protocolli di file system standard del settore per il montaggio di condivisioni file di Azure:Protocollo SMB (Server Message Block) e protocollo NFS (Network File System), che consente di scegliere il protocollo più adatto al 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. NFS 4.1 è attualmente supportato solo all'interno del nuovo tipo di account di archiviazione FileStorage (solo condivisioni file Premium).

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.

Funzionalità SMB NFS
Versioni del protocollo supportate SMB 3.1.1, SMB 3.0, SMB 2.1 NFS 4.1
Sistema operativo consigliato
  • Windows 11, versione 21H2+
  • Windows 10, versione 21H1+
  • Windows Server 2019+
  • Kernel Linux versione 5.3+
 Kernel Linux versione 4.3+
Livelli disponibili Premium, ottimizzato per le transazioni, ad accesso frequente e sporadico Premium
Modello di fatturazione Capacità con provisioning
Endpoint della zona DNS di Azure (anteprima) Supportata Supportata
Ridondanza Archiviazione con ridondanza locale, Archiviazione con ridondanza della zona, Archiviazione con ridondanza geografica, Archiviazione con ridondanza geografica della zona LRS, ZRS
Semantica del file system App Win32 POSIX
Autenticazione Autenticazione basata su identità (Kerberos), autenticazione con chiave condivisa (NTLMv2) Autenticazione basata su host
Autorizzazione Elenchi di controllo di accesso in stile Win32 (ACL) Autorizzazioni di tipo UNIX
Distinzione tra maiuscole e minuscole Senza distinzione tra maiuscole e minuscole, mantenimento del caso Fa distinzione tra maiuscole e minuscole.
Eliminazione o modifica di file aperti Solo con blocco Sì
Condivisione di file Modalità di condivisione di Windows Gestione blocchi di rete per gli avvisi di intervallo di byte
Supporto per collegamenti rigidi Non supportato Supportato
Supporto dei collegamenti simbolici Non supportato Supportato
Facoltativamente accessibile da Internet Sì (solo SMB 3.0+) No
Supporta FileREST Sì Sottoinsieme:
Blocchi obbligatori per l'intervallo di byte Supportato Non supportato
Blocchi di intervalli di byte consultivi Non supportato Supportato
Attributi estesi/denominati Non supportato Non supportato
Flussi dei dati alternativi Non supportato N/D
Identificatori di oggetto Non supportato N/D
Punti di analisi Non supportato N/D
File sparse Non supportato N/D
Compressione Non supportato N/D
Named pipe Non supportato N/D
SMB diretto Non supportato N/D
Leasing di directory SMB Non supportato N/D
Copia shadow del volume Non supportato N/D
Nomi di file brevi (alias 8.3) Non supportato N/D
Servizio Server Non supportato N/D
Transazioni di file system (TxF) Non supportato N/D

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

Quando si distribuiscono condivisioni file di Azure in account di archiviazione, è consigliabile:

  • Solo la distribuzione di condivisioni file di Azure negli account di archiviazione con altre condivisioni file di Azure. Anche se gli account di archiviazione per utilizzo generico v2 consentono di avere account di archiviazione misti, poiché le risorse di archiviazione, ad esempio condivisioni file di Azure e contenitori BLOB condividono i limiti dell'account di archiviazione, la combinazione delle risorse tra loro può rendere più difficile risolvere i problemi di prestazioni in un secondo momento.

  • 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. Idealmente, è consigliabile eseguire il mapping delle condivisioni file 1:1 con gli account di archiviazione. Tuttavia, ciò potrebbe non essere sempre possibile a causa di vari limiti e restrizioni, sia dall'organizzazione che 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, per assicurarsi di non inserire le condivisioni file più utilizzate nello stesso account di archiviazione.

  • La distribuzione degli account per utilizzo generico v2 e FileStorage e l'aggiornamento degli account di archiviazione per utilizzo generico v1 e classico vengono visualizzati nell'ambiente in uso.

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 di Active Directory locali (AD DS o Servizi di dominio Active Directory locali): gli account di archiviazione di Azure possono essere aggiunti a un dominio a un Dominio di Active Directory 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 al dominio che lo aggiunge a un dominio di Active Directory Domain Services di proprietà del cliente. Questa opzione di distribuzione è particolarmente utile per gli scenari di lift-and-shift 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 la connettività di rete ai controller di dominio da macchine virtuali aggiunte a Microsoft Entra ibride e microsoft Entra.
  • Autenticazione di Active Directory su client SMB per Linux: File di Azure supporta l'autenticazione basata su identità su SMB per client 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 è un'operazione di amministratore, perché la condivisione file montata avrà 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 per la creazione di nuove condivisioni file in File di Azure si comportano come file server Windows o appliance NAS, l'aggiunta dell'account di archiviazione ad Active Directory Domain Services di proprietà del cliente è l'opzione consigliata. Per altre informazioni sull'aggiunta del dominio all'account di archiviazione a servizi di dominio Active Directory di proprietà del cliente, vedere Panoramica - Active Directory locale l'autenticazione di Servizi di dominio 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. Anche se i dati saranno 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 File di Azure considerazioni sulla rete.

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

Importante

Questa sezione illustra i dettagli della crittografia in transito per le condivisioni SMB. Per informazioni dettagliate sulla crittografia in transito con condivisioni NFS, vedere Sicurezza e rete.

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 consentirà 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 consentirà anche le chiamate api 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 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.

Protezione dei dati

File di Azure ha un approccio multi-layer per garantire che i dati vengano sottoposti a backup, recuperabili e protetti dalle minacce alla sicurezza. Vedere File di Azure panoramica della protezione dei dati.

Elimina temporaneamente

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 non disporre di eliminazione temporanea abilitata.

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

Backup

È possibile eseguire il backup della condivisione file di Azure tramite snapshot di condivisione, ovvero 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 le 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 orchestra anche l'abilitazione dell'eliminazione temporanea e accetta un blocco di eliminazione in un account di archiviazione non appena viene configurata una condivisione file all'interno di essa 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. Vedere Informazioni sulle differenze tra analisi malware e analisi della reputazione 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 livelli multimediali diversi di archiviazione, SSD (dischi ssd a stato solido) e HDD (unità disco rigido), che consentono di personalizzare le condivisioni in base ai requisiti di prestazioni e prezzo dello 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 v1 di cui è stato effettuato il provisioning. 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 sul contratto di servizio, vedere la pagina contratti di servizio di Azure (vedere "Account 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 condivisioni file SSD è probabilmente la soluzione migliore. Se la bassa latenza non è altrettanto preoccupante, ad esempio con le condivisioni del team montate in locale da Azure o memorizzate nella cache in locale usando Sincronizzazione file di Azure, le condivisioni file HDD possono essere più adatte 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 a 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.

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.

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

Disponibilità dell'archiviazione con ridondanza della zona standard

L'archiviazione con ridondanza della zona per account di archiviazione per utilizzo generico v2 standard è disponibile per un subset di aree di Azure.

Disponibilità dell'archiviazione con ridondanza della zona Premium

L'archiviazione con ridondanza della zona per le condivisioni file Premium è disponibile per un subset di aree di Azure.

Disponibilità GZRS Standard

L'archiviazione con ridondanza geografica della zona è disponibile 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 failover dell'account di archiviazione e ripristino di emergenza, 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