Pianificare una distribuzione di File di Azure

Pianificare una distribuzione di File di Azure comporta alcune decisioni chiave. Usa questo articolo per scegliere le opzioni giuste per il tuo carico di lavoro.

Devi decidere quanto segue:

  1. Come accederanno i clienti alla condivisione? Montare direttamente da client cloud o on-premises, o memorizzare in cache on-premises con Sincronizzazione file di Azure?
  2. Quale modello di gestione? Condivisioni di file classiche (account di archiviazione) o il nuovo provider di risorse Microsoft.FileShares?
  3. Quale protocollo?SMB (Windows/Linux/macOS) o NFS (solo Linux)?
  4. Come si autenticheranno gli utenti?Autenticazione basata sull'identità o chiave di archiviazione?
  5. Quale configurazione di rete? Endpoint pubblico, endpoint di servizio o endpoint privati?
  6. Quale livello di prestazioni e opzione di ridondanza?SSD o HDD, e quale opzione di ridondanza?

Le sezioni seguenti trattano ogni decisione in dettaglio.

Tip

Se intendi usare Sincronizzazione file di Azure, vedi invece Pianificare la distribuzione di Sincronizzazione file di Azure.

Concetti relativi alla gestione

File di Azure offre due modelli di gestione per il deployment delle condivisioni file:

  • Condivisioni file classiche (Microsoft. Fornitore di risorse di storage): Distribuire condivisioni file all'interno di un account di archiviazione. Supporta SMB e NFS, SSD e HDD, tutti i tipi di ridondanza e tutte le regioni.
  • Condivisioni di file (provider di risorse Microsoft.FileShares): Distribuisci condivisioni di file come risorse Azure di primo livello senza un account di archiviazione. Semplifica la gestione con rete per condivisione, fatturazione e sicurezza. Attualmente disponibile solo per condivisioni di file NFS.

Per dettagli sui fornitori di risorse, il confronto delle funzionalità e la disponibilità regionale, consulta File di Azure management concepts.

Protocolli disponibili

File di Azure offre due protocolli standard di settore per file system per montare le condivisioni file di Azure: il protocollo Server Message Block (SMB) e il protocollo Network File System (NFS). Scegliere il protocollo più adatto al carico di lavoro. Azure condivisioni file non supportano entrambi i protocolli SMB e NFS nella stessa condivisione file, anche se è possibile creare condivisioni file SMB e NFS Azure all'interno dello stesso account di archiviazione.

Con le condivisioni file SMB e NFS, File di Azure offre condivisioni file di livello aziendale in grado di aumentare le prestazioni per soddisfare le esigenze di archiviazione e migliaia di client possono accedervi simultaneamente.

Funzionalità Piccole e Medie Imprese (PMI) 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 multimediali disponibili SSD e HDD Solo UNITÀ SSD
Ridondanza
  • Locale
  • Della zona
  • Geografica
  • GeoZone (GZRS)
  • Locale
  • Della zona
Semantica del file system 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 maiuscole/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
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
Accessibile tramite Internet, facoltativamente. Sì (solo SMB 3.0+) NO
Supporta FileREST Sì (Microsoft.Storage solo)
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 Pipes Non supportato N/D
SMB diretto Non supportato N/D
Leasing 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
Transazioni di file system (TxF) Non supportato N/D

Identità

Per accedere a una condivisione file Azure, è necessario essere autenticati e autorizzati ad accedere alla condivisione. In quasi tutti i casi, usa l'autenticazione basata su identità anziché la chiave dell'account di archiviazione per accedere alle condivisioni file SMB di Azure.

File di Azure supporta i metodi di autenticazione seguenti per le condivisioni SMB:

  • Active Directory Domain Services (AD DS) locali: è possibile aggiungere gli account di archiviazione di Azure a un dominio Active Directory Domain Services (AD DS) di proprietà del cliente, proprio come per un file server di Windows Server o un dispositivo NAS. È possibile distribuire un controller di dominio locale, in una macchina virtuale 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 aver unito il dominio a un account di storage, l'utente finale può creare una condivisione file con l'account utente con cui ha effettuato l'accesso al proprio PC. L'autenticazione basata su ACTIVE Directory usa il protocollo di autenticazione Kerberos.
  • Microsoft Entra Domain Services: Microsoft Entra Domain Services fornisce un controller di dominio gestito da Microsoft che è possibile usare 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 migrazione dell'applicazione che richiedono autorizzazioni basate su Active Directory. Poiché Domain Services fornisce l'autenticazione basata su ACTIVE Directory, questa opzione usa anche il protocollo di autenticazione Kerberos.
  • Microsoft Entra Kerberos: Microsoft Entra Kerberos consente di usare Microsoft Entra ID per autenticare hybrid o identità solo cloud. Questa configurazione usa Microsoft Entra ID per rilasciare ticket Kerberos per accedere alla condivisione file con il protocollo SMB. Questo significa che gli utenti finali possono accedere alle condivisioni file di Azure tramite Internet da macchine virtuali con connessione diretta o ibrida a Microsoft Entra.
  • Autenticazione di Active Directory tramite SMB per i client Linux: File di Azure supporta l'autenticazione basata su identità tramite SMB per i client Linux mediante il protocollo di autenticazione Kerberos attraverso Servizi di dominio Active Directory (AD DS) o Microsoft Entra Domain Services.
  • Chiave dell'account di archiviazione di Azure: Sebbene non sia consigliato per motivi di sicurezza, è anche possibile montare le condivisioni file di Azure utilizzando una chiave dell'account di archiviazione di Azure invece di un'identità. Per montare una condivisione file usando la chiave dell'account di archiviazione, usare il nome dell'account di archiviazione come nome utente e la chiave dell'account di archiviazione come password. L'uso della chiave dell'account di archiviazione per montare la condivisione file 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 dispongono di ACL. Quando si utilizza la chiave dell'account di archiviazione per eseguire il montaggio tramite SMB, viene utilizzato il protocollo di autenticazione NTLMv2. Se è necessario usare la chiave dell'account di archiviazione, 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 File di Azure destinate a comportarsi come file di Windows Server o appliance NAS, aggiungere l'account di archiviazione al dominio AD DS di proprietà del cliente. Per ulteriori informazioni, vedere Panoramica - autenticazione AD DS locale tramite SMB per le condivisioni file di Azure.

Rete

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

  • Molte organizzazioni e provider di servizi Internet bloccano la porta 445, che le condivisioni file SMB usano per la comunicazione, 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 le funzionalità di rete 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 di 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.

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 Azure ExpressRoute dall'ambiente locale alla rete 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, 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, puoi creare una cache leggera delle tue Azure condivisioni file su una VM Windows Server 2022 Azure Edition usando Sincronizzazione file di Azure. Per saperne di più su questa opzione, consulta SMB over QUIC con Sincronizzazione file di Azure.

Crittografia per File di Azure

File di Azure supporta due diversi tipi di crittografia:

  • Crittografia in transito, correlata alla crittografia usata durante il montaggio o l'accesso alla condivisione file 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, tutti gli account di archiviazione Azure hanno la crittografia in transito abilitata. Questa funzionalità 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 possono montare la condivisione file Azure se la crittografia in transito è abilitata. Per altre informazioni sui sistemi operativi che supportano SMB 3.x con crittografia, vedere la documentazione relativa a 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 Azure. Quando si disabilita la crittografia, File di Azure consente 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 Azure della condivisione file Azure. Un client SMB 2.1 all'esterno dell'area Azure della condivisione file Azure, ad esempio in locale o in un'area Azure diversa, non può accedere alla condivisione file.

Verificare che la crittografia dei dati in transito sia abilitata.

Per ulteriori informazioni sulla crittografia in transito, vedere richiedere il trasferimento sicuro in Azure Storage e crittografia in transito per le condivisioni file di Azure NFS.

Crittografia di dati inattivi

File di Azure usa lo stesso schema di crittografia degli altri servizi di archiviazione Azure, ad esempio Archiviazione BLOB di Azure. Tutti i dati archiviati in File di Azure vengono crittografati inattivi tramite crittografia service-side encryption (SSE), che funziona in modo analogo a BitLocker in Windows.

Poiché i dati vengono crittografati sotto il file system della condivisione file di Azure, poiché vengono codificati su disco, non è necessario accedere alla chiave sottostante nel client per leggere o scrivere nella condivisione file 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 contiene le chiavi per crittografare e decrittografare i dati. Microsoft è responsabile della rotazione regolare di queste chiavi.

Per le Azure File Share classiche, è possibile scegliere di crittografare i dati usando chiavi gestite dai clienti. Se si scelgono chiavi gestite dal cliente, File di Azure è autorizzato ad accedere alle chiavi per soddisfare le richieste di lettura e scrittura dai client. Con le chiavi gestite dal cliente, è possibile revocare questa autorizzazione in qualsiasi momento. Ma senza questa autorizzazione, la condivisione file Azure non è più accessibile tramite SMB o l'API FileREST.

Non è possibile usare chiavi gestite dal cliente per la crittografia dei dati archiviati nelle condivisioni file di Azure create usando il provider di risorse Microsoft.FileShares. È necessario usare chiavi gestite da Microsoft.

Protezione dei dati

File di Azure usa un approccio multilivello 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.

Eliminazione morbida

L'eliminazione temporanea è un'impostazione a livello di account di archiviazione che è possibile usare per ripristinare la condivisione file quando viene eliminata accidentalmente. Quando si elimina una condivisione file, passa a uno stato eliminato temporaneamente anziché essere cancellato definitivamente. È 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 impostare un breve periodo di conservazione o non abilitare l'eliminazione temporanea.

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

Copia di Sicurezza

Eseguire il backup delle condivisioni dei file di Azure tramite condividi snapshot, ovvero copie temporizzate di sola lettura della condivisione. Gli snapshot sono incrementali, quindi includono solo i dati modificati dopo lo snapshot precedente. Ogni condivisione file supporta fino a 200 snapshot ed è possibile mantenerli fino a 10 anni. È possibile creare manualmente snapshot nel portale di Azure oppure usare PowerShell o l'interfaccia della riga di comando. È anche possibile usare Backup di Azure.

Backup di Azure per le condivisioni di file SMB 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. 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 a livello di elemento e di condivisione nel portale di Azure usando Backup di Azure. Scegli il punto di ripristino (uno snapshot particolare), il file o la directory specifica se rilevante, e poi la posizione (originale o alternativa) dove vuoi ripristinare. Il servizio di backup gestisce la copia dei dati dello snapshot e mostra lo stato di avanzamento del ripristino nel portale.

Proteggere le File di Azure con Microsoft Defender per l'archiviazione

Microsoft Defender per l'archiviazione è un livello nativo 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 Archiviazione 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 altro malware caricato in un account di archiviazione basato sull'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 enable Microsoft Defender for Storage a livello di sottoscrizione (scelta consigliata) o a livello di risorsa.

Livelli di archiviazione

File di Azure offre due livelli multimediali di archiviazione: disco ssd (solid-state disk) e unità disco rigido (HDD). Questi livelli consentono di personalizzare le azioni in base ai requisiti di prestazioni e prezzo dello scenario:

  • SSD (Premium): le condivisioni file SSD offrono prestazioni elevate omogenee e a bassa latenza, in millisecondi a cifra singola per la maggior parte delle operazioni di I/O, per i carichi di lavoro con I/O elevato. 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.

    È possibile usare le condivisioni file SSD con i protocolli SMB e NFS. Le condivisioni file SSD sono disponibili nel modello di fatturazione di cui è stato effettuato il provisioning v2 e il provisioning v1. Le condivisioni file SSD offrono un contratto di servizio con disponibilità superiore rispetto alle condivisioni file HDD.

  • HDD (standard): le condivisioni file HDD offrono un'opzione di archiviazione conveniente per le condivisioni file per utilizzo generico. Le condivisioni file HDD sono disponibili con i modelli di fatturazione con provisioning v2 e con pagamento in base al consumo, anche se è consigliabile usare il modello v2 con provisioning per le nuove distribuzioni di condivisioni file. Per informazioni sull'SLA, vedere la pagina SLA di Azure per servizi online.

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, le condivisioni file SSD sono probabilmente la soluzione migliore. Se la bassa latenza non è altrettanto preoccupante, le condivisioni file HDD potrebbero essere più adatte dal punto di vista dei costi. Ad esempio, la bassa latenza potrebbe essere meno preoccupante per le condivisioni del team montate in locale da Azure o memorizzate nella cache in locale tramite Sincronizzazione file di Azure.

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.

Per altre informazioni sui livelli di supporto SSD e HDD, vedere Informazioni sui modelli di fatturazione di File di Azure e Comprendere e ottimizzare le prestazioni della condivisione file Azure.

Ridondanza

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

  • Archiviazione con ridondanza locale (LRS): con ridondanza locale, ogni file viene archiviato tre volte in un cluster di archiviazione Azure. Questo approccio consente di proteggersi 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 Azure zone di disponibilità. Le zone di disponibilità sono posizioni fisiche univoche in un'area 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 la ridondanza geografica è disponibile un'area primaria e un'area secondaria. I file vengono archiviati tre volte in un cluster di archiviazione 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 le due aree Azure. Se si verifica un'emergenza grave, ad esempio la perdita permanente di un'area Azure a causa di un'emergenza naturale o di un altro evento simile, Microsoft esegue un failover. In questo caso, il database secondario diventa primario e 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 la ridondanza geografica della zona, i file vengono archiviati tre volte in tre cluster di archiviazione distinti nell'area primaria. Tutte le scritture vengono quindi replicate in modo asincrono in un'area secondaria definita da Microsoft. Il processo di failover per la ridondanza geografica della zona funziona come per la ridondanza geografica.

Le condivisioni file HDD supportano tutti e quattro i tipi di ridondanza. Le condivisioni file SSD supportano solo l'archiviazione con ridondanza locale e l'archiviazione con ridondanza della zona.

Gli account di archiviazione con pagamento in base al consumo offrono due altre opzioni di ridondanza che File di Azure non supporta: l'archiviazione con ridondanza geografica e accesso in lettura (RA-GRS) e l'archiviazione con ridondanza geografica a livello di zona e accesso in lettura (RA-GZRS). È possibile configurare le condivisioni file di Azure negli account di archiviazione con queste opzioni impostate, ma File di Azure non supporta la lettura dalla regione secondaria. Le condivisioni file di Azure distribuite in RA-GRS o RA-GZRS account di archiviazione vengono fatturate rispettivamente come ridondanti geografica o con ridondanza geografica.

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

Disponibilità di condivisioni file SSD con ridondanza della zona

Le condivisioni file SSD con ridondanza della zona sono disponibili per un sottoinsieme delle aree 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 (DR) per le condivisioni file Azure. Per comprendere i concetti e i processi coinvolti nel ripristino di emergenza e nel 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 è importante per il successo della migrazione.

Per le migrazioni SMB, vedere Panoramica della migrazione SMB che contiene una tabella che conduce alle guide alla migrazione che probabilmente coprono lo scenario.

Per le migrazioni NFS, vedere Migrare alle condivisioni di file NFS Azure.

Passaggi successivi