Pianificare la distribuzione di File di Azure

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

• Montaggio diretto di una condivisione file Azure: poiché File di Azure fornisce l'accesso SMB (Server Message Block) o NFS (Network File System), è possibile montare Azure condivisioni file 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. Questa architettura significa che non è necessario applicare patch software o scambiare dischi fisici. È possibile scegliere Azure condivisioni file classiche (SMB e NFS) o Microsoft. FileShares (solo NFS) come modello di gestione.

• Cache Azure file condivisi in locale con Sincronizzazione file di Azure (solo SMB): 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 server di file locale. Sincronizzazione file di Azure trasforma un Windows Server locale (o cloud) in una cache rapida della condivisione file Azure SMB.

Questo articolo riguarda principalmente le considerazioni sulla distribuzione per la distribuzione di una condivisione file Azure da montare direttamente da un client locale o cloud. Se si prevede di usare Sincronizzazione file di Azure, vedere Planning per una distribuzione Sincronizzazione file di Azure.

Concetti relativi alla gestione

In Azure, un resource è un elemento gestibile creato e configurato all'interno delle sottoscrizioni e dei gruppi di risorse Azure. I provider di risorse sono servizi di gestione che offrono tipi specifici di risorse. Anche se è possibile usare molte risorse per distribuire un carico di lavoro in Azure, File di Azure si concentra su due risorse chiave:

• Account di archiviazione, offerti dal provider di risorse Microsoft.Storage. Gli account di archiviazione sono risorse di primo livello che rappresentano un pool condiviso di archiviazione, operazioni di I/O al secondo e velocità effettiva in cui è possibile distribuire condivisioni file classiche o altre risorse di archiviazione, a seconda del tipo di account di archiviazione. Tutte le risorse di archiviazione distribuite in un account di archiviazione condividono i limiti che si applicano a tale account di archiviazione. Le condivisioni file classiche supportano sia i protocolli di condivisione file SMB sia NFS.

• Condivisioni di file, offerte dal fornitore di risorse Microsoft.FileShares. Le condivisioni file sono una nuova risorsa di primo livello che semplifica la distribuzione di File di Azure eliminando la necessità di un account di archiviazione. A differenza delle condivisioni file classiche, che è necessario distribuire in un account di archiviazione, si distribuiscono condivisioni file direttamente nel gruppo di risorse, ad esempio gli account di archiviazione stessi o altre risorse Azure come macchine virtuali, dischi o reti virtuali. Attualmente, Microsoft.FileShares supporta solo il protocollo di condivisione file NFS. Se è necessario SMB, scegliere condivisioni file classiche.

Questo video offre una panoramica completa delle differenze tra l'account di archiviazione e i modelli di gestione delle condivisioni file:

Condivisioni file classiche (Microsoft.Storage)

Le condivisioni file classiche o le condivisioni file distribuite negli account di archiviazione rappresentano il modo tradizionale per distribuire condivisioni file per File di Azure. Supportano tutte le funzionalità principali supportate da File di Azure, inclusi i livelli di supporto SMB e NFS, SSD e HDD, ogni tipo di ridondanza e disponibilità in ogni area. Anche se le condivisioni file classiche supportano l'intera gamma di funzionalità di File di Azure, presentano limitazioni importanti:

• Pianificazione della capacità: le condivisioni file classiche, nonché gli oggetti figlio come i contenitori BLOB che si trovano nello stesso account di archiviazione, condividono un pool comune di archiviazione, IOPS e velocità effettiva. Questa architettura richiede una pianificazione attenta per evitare colli di bottiglia di capacità quando si collocano più condivisioni file classiche in un account di archiviazione. Tenere presenti sia le esigenze attuali sia quelle future di ogni condivisione file classica presente in un account di archiviazione, poiché la crescita di una condivisione file classica può ridurre lo spazio disponibile per le altre condivisioni file.

• Impostazioni condivise: si applicano molte impostazioni importanti, ad esempio le regole di rete e di sicurezza, a livello di account di archiviazione. Di conseguenza, è necessario considerare attentamente come inserire le condivisioni file classiche nello stesso account di archiviazione. Considera l'account di archiviazione come un confine di attendibilità e inserisci le condivisioni file classiche nello stesso account di archiviazione solo se per te va bene che abbiano le stesse impostazioni di sicurezza.

• Complessità del ridimensionamento: le distribuzioni di File di Azure su larga scala possono richiedere la gestione di molte sottoscrizioni Azure a causa dei vincoli sugli account di archiviazione del Microsoft.Storage provider di risorse. Per altre informazioni, vedere Limiti dell'account di archiviazione.

Le distribuzioni classiche di condivisione file usano due tipi di account di archiviazione:

• Account di archiviazione provisionati: Il FileStorage tipo di account di archiviazione identifica gli account di archiviazione provisionati. È possibile distribuire condivisioni file classiche con provisioning su hardware basato su SSD o HDD usando gli account di archiviazione di cui è stato effettuato il provisioning. È possibile usare solo gli account di archiviazione di cui è stato effettuato il provisioning per archiviare condivisioni file classiche. Non è possibile usarli per altre risorse di archiviazione, ad esempio contenitori blob, code e tabelle. Utilizzare gli account di archiviazione con provisioning effettuato per tutte le nuove implementazioni di condivisioni file classiche.

• Account di archiviazione con pagamento in base al consumo: il StorageV2 tipo di account di archiviazione identifica gli account di archiviazione con pagamento in base al consumo. È possibile distribuire condivisioni file con pagamento in base al consumo su hardware basato su HDD usando account di archiviazione con pagamento in base al consumo. È possibile usare gli account di archiviazione con pagamento in base al consumo per archiviare condivisioni file classiche e altre risorse di archiviazione, ad esempio contenitori BLOB, code o tabelle.

Per altre informazioni, vedere Creare una condivisione file classica.

Condivisioni file (Microsoft.FileShares)

Il Microsoft.FileShares provider di risorse offre condivisioni file come nuova risorsa Azure di primo livello. Queste condivisioni file offrono i vantaggi seguenti rispetto alle condivisioni file classiche:

• Gestione semplificata: creare condivisioni file direttamente come risorse di primo livello nel portale di Azure o tramite le API di gestione. Questo approccio rimuove il requisito di gestire un account di archiviazione e semplifica l'esperienza di distribuzione.

• Capacità e prestazioni indipendenti: ogni condivisione file ha una propria risorsa di archiviazione dedicata, operazioni di I/O al secondo e velocità effettiva. Questa progettazione evita la necessità di pianificare la capacità rispetto alle risorse limitate dell'account di archiviazione e consente alle condivisioni file di crescere liberamente man mano che le richieste di carico di lavoro aumentano.

• Configurazione granulare: applicare impostazioni di rete e sicurezza a livello di condivisione file, in modo da avere un controllo preciso dei limiti di accesso e dell'isolamento. Questa configurazione semplifica l'applicazione di criteri di sicurezza per app, team o ambienti specifici.

• Fatturazione prevedibile e flessibile: le condivisioni di file utilizzano il modello di fatturazione v2 a provisioning, che consente di effettuare il provisioning della risorsa di archiviazione in modo indipendente, delle operazioni IOPS e della velocità effettiva per condivisione. Poiché Azure fattura per ogni risorsa di primo livello Azure, è possibile tenere traccia facilmente dei costi di ogni singola condivisione per l'attribuzione dei costi al progetto, al team o al cliente che usa la condivisione file.

• Scalabilità e prestazioni migliorate: le condivisioni file supportano limiti più elevati e tempi di distribuzione inferiori rispetto alle condivisioni file classiche. Per altre informazioni, vedere File di Azure obiettivi di scalabilità e prestazioni.

Disponibilità regionale

Attualmente, è possibile creare una condivisione di file con Microsoft.FileShares nelle seguenti aree geografiche. Supporto dell'endpoint privato per la condivisione file con Microsoft. FileShares è disponibile in tutte le aree del cloud pubblico Azure.

• Australia Central
• Australia East
• Australia Southeast
• Brazil South
• Brazil Southeast
• Canada Central
• Canada East
• Central India
• East Asia
• East US
• Francia centrale
• Francia meridionale
• Germania settentrionale
• Germania centro-occidentale
• Israel Central
• Italia settentrionale
• Japan East
• Japan West
• JIO India centrale
• JIO India occidentale
• Korea Central
• Korea South
• Stati Uniti centro-settentrionali
• North Europe
• Norvegia orientale
• Norvegia occidentale
• Poland Central
• Sudafrica settentrionale
• Sudafrica occidentale
• Stati Uniti centro-meridionali
• South India
• Sud-est asiatico
• Svezia centrale
• UAE Central
• UAE North
• Regno Unito meridionale
• Regno Unito occidentale
• West Europe
• West US

Confronto tra provider di risorse: Microsoft.Storage e Microsoft.FileShares

Ti invitiamo a valutare la nuova esperienza di condivisione file con Microsoft.FileShares per tutte le nuove distribuzioni di File di Azure con protocollo NFS.

Se un requisito di funzionalità specifico non è ancora disponibile nella nuova esperienza di condivisione file o il carico di lavoro richiede il supporto del protocollo SMB, usare l'esperienza di condivisione file classica. La deprecazione dell'esperienza classica non inizierà fino a quando non vengono chiusi i gap di funzionalità rimanenti. Al momento, la migrazione automatica dalle condivisioni file classiche alle condivisioni file non è supportata.

Funzionalità	Condivisioni file classiche	Condivisioni file (Microsoft.FileShares)
Garanzia di supporto	Generalmente disponibile	Generalmente disponibile
Risorsa di primo livello per il servizio	Account di archiviazione	Condivisioni file
Protocollo SMB
Protocollo NFS
supporto per Sincronizzazione file di Azure
Account di archiviazione necessario
Pagamento in base al modello di fatturazione
Modello di fatturazione v1 con provisioning
Modello di fatturazione v2 con provisioning
Supporto HDD
Supporto SSD
Archiviazione con ridondanza locale
ZRS
Archiviazione con ridondanza geografica
Archiviazione con ridondanza geografica della zona
Fatturazione, rete e configurazioni di sicurezza a livello di condivisione
Configurazioni di rete virtuale singola per una condivisione file
Configurazione di una singola rete virtuale per più condivisioni file
Driver CSI del servizio Azure Kubernetes
API REST del piano dati
Supporto per l'eliminazione temporanea
Supporto degli snapshot
Crittografia dei dati in transito
Chiavi gestite dal cliente
Pinning per zona

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.

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 aggiunto un account di archiviazione a un dominio, l'utente finale può montare una condivisione di file con l'account utente con cui ha effettuato l'accesso al 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 devi usare la chiave dell'account di archiviazione, usa endpoint privati o endpoint di servizio come descritto nella sezione Networking.

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 server 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 tramite QUIC, è possibile creare una cache leggera delle condivisioni file 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 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 file di Azure usando gli snapshot della condivisione, che sono copie della condivisione di sola lettura in un determinato momento. 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. 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 desidera 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 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

• Pianificare una distribuzione di Sincronizzazione file di Azure
• Distribuire File di Azure
• Distribuire Sincronizzazione file di Azure