Domande frequenti su File di Azure

  • Articolo

File di Azure offre condivisioni file completamente gestite nel cloud accessibili tramite il protocollo SMB (Server Message Block) standard di settore e il protocollo NFS (Network File System). È possibile montare le condivisioni file di Azure simultaneamente da distribuzioni cloud o locali di Windows, Linux e macOS. È anche possibile memorizzare nella cache le condivisioni file di Azure nei computer Windows Server tramite Sincronizzazione file di Azure per l'accesso rapido in prossimità della posizione in cui vengono usati i dati.

Sincronizzazione file di Azure

  • È possibile avere server aggiunti a un dominio e server non aggiunti a un dominio nello stesso gruppo di sincronizzazione?
    Sì. Un gruppo di sincronizzazione può contenere endpoint server con appartenenze ad Active Directory diverse, anche se non sono aggiunte a un dominio. Sebbene questa configurazione funzioni tecnicamente, non è consigliabile come configurazione tipica perché gli elenchi di controllo di accesso (ACL) definiti per file e cartelle in un server potrebbero non essere in grado di essere applicati da altri server nel gruppo di sincronizzazione. Per ottenere risultati ottimali, è consigliabile eseguire la sincronizzazione tra server che si trovano nella stessa foresta Active Directory, tra server che si trovano in foreste Active Directory diverse, ma che hanno stabilito relazioni di trust o tra server che non si trovano in un dominio. È consigliabile evitare di usare una combinazione di queste configurazioni.

  • È stato creato un file direttamente nella condivisione file di Azure usando SMB o nel portale. Quanto tempo è necessario per sincronizzare il file con i server nel gruppo di sincronizzazione?

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

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

    Per sincronizzare immediatamente i file modificati nella condivisione file di Azure, è possibile usare il cmdlet di PowerShell Invoke-AzStorageSyncChangeDetection, in modo da avviare manualmente il rilevamento delle modifiche nella condivisione file di Azure. Questo cmdlet è destinato agli scenari in cui alcuni tipi di processi automatici apportano modifiche alla condivisione file di Azure o le modifiche vengono eseguite da un amministratore, ad esempio lo spostamento di file e directory nella condivisione. Per le modifiche dell'utente finale, è consigliabile installare l'agente Sincronizzazione file di Azure in una macchina virtuale IaaS e consentire agli utenti finali di accedere alla condivisione file tramite la macchina virtuale IaaS. In questo modo, tutte le modifiche si sincronizzano rapidamente con altri agenti senza la necessità di usare il cmdlet Invoke-AzStorageSyncChangeDetection. Per altre informazioni, vedere la documentazione di Invoke-AzStorageSyncChangeDetection.

    Per i volumi in Windows Server è in fase di studio la possibilità di aggiungere una funzione di rilevamento delle modifiche per una condivisione file di Azure simile a USN. Aiutaci a classificare in ordine di priorità questa funzionalità per lo sviluppo futuro votandola nel feedback della community di Azure.

  • Cosa accade quando lo stesso file viene modificato in due server approssimativamente nello stesso momento?
    I conflitti di file vengono creati quando il file nella condivisione file di Azure non corrisponde al file nel percorso dell'endpoint server (le dimensioni e/o l'ora dell'ultima modifica sono diverse).

    Gli scenari seguenti possono causare conflitti di file:

    • Un file viene creato o modificato in un endpoint, ad esempio server A. Se lo stesso file viene modificato in un endpoint diverso prima che la modifica nel server A venga sincronizzata con tale endpoint, viene creato un conflitto di file.
    • Il file esisteva nella condivisione file di Azure e nel percorso dell'endpoint server prima della creazione dell'endpoint server. Se le dimensioni del file e/o l'ora dell'ultima modifica sono diverse tra il file nel server e la condivisione file di Azure quando viene creato l'endpoint server, viene creato un conflitto di file.
    • Il database di sincronizzazione è stato ricreato a causa di un danneggiamento o del raggiungimento del limite di conoscenza. Dopo aver ricreato il database, la sincronizzazione entra in una modalità denominata riconciliazione. Se le dimensioni del file e/o l'ora dell'ultima modifica sono diverse tra il file nel server e la condivisione file di Azure quando si verifica la riconciliazione, viene creato un conflitto di file.

    Al termine del caricamento iniziale nella condivisione file di Azure, Sincronizzazione file di Azure non sovrascrive alcun file nel gruppo di sincronizzazione. Usa invece una semplice strategia di risoluzione dei conflitti: mantiene entrambe le modifiche ai file che vengono modificate contemporaneamente in due endpoint. Per la modifica più di recente viene mantenuto il nome del file originale. Il file precedente (determinato da LastWriteTime) ha il nome dell'endpoint e il numero di conflitto aggiunto al nome del file. Per gli endpoint server, il nome dell'endpoint è il nome del server. Per gli endpoint cloud, il nome dell'endpoint è Cloud. Il nome segue questa tassonomia:

    <FileNameWithoutExtension-endpointName><>[-#].<Ext>

    Ad esempio, il primo conflitto per ReportAziendale.docx diventerebbe ReportAziendale-ServerCentrale.docx se ServerCentrale è il computer in cui è stata eseguita l'operazione di scrittura meno recente. Il nome per il secondo conflitto sarebbe ReportAziendale-ServerCentrale-1.docx. Sincronizzazione file di Azure supporta 100 file in conflitto per file. Dopo aver raggiunto il numero massimo di file in conflitto, il file non verrà sincronizzato finché il numero di file in conflitto è inferiore a 100.

  • La suddivisione in livelli nel cloud è disabilitata, perché sono presenti file a livelli nel percorso dell'endpoint server?
    Esistono due motivi per cui i file a livelli potrebbero esistere nel percorso dell'endpoint server:

    • Quando si aggiunge un nuovo endpoint server a un gruppo di sincronizzazione esistente, se si sceglie l'opzione di primo spazio dei nomi di richiamo o si richiama solo lo spazio dei nomi per la modalità di download iniziale, i file verranno visualizzati come a livelli fino a quando non vengono scaricati localmente. Per evitare questo problema, selezionare l'opzione evitare file a livelli per la modalità di download iniziale. Per richiamare manualmente i file, usare il Invoke-StorageSyncFileRecall cmdlet .

    • Se la suddivisione in livelli cloud è stata abilitata nell'endpoint server e quindi disabilitata, i file rimarranno a livelli fino a quando non si accede.

  • Perché i file a livelli non visualizzano anteprime o anteprime in Windows Esplora file?
    Per i file a livelli, le anteprime e le anteprime non saranno visibili nell'endpoint server. Questo comportamento è previsto perché la funzionalità cache di anteprima in Windows ignora intenzionalmente la lettura dei file con l'attributo offline. Con l'abilitazione della suddivisione in livelli nel cloud, la lettura dei file a livelli causerebbe il download (richiamato).

    Questo comportamento non è specifico per Sincronizzazione file di Azure. Windows Esplora file visualizza una "X grigia" per tutti i file con l'attributo offline impostato. Quando si accede ai file tramite SMB, verrà visualizzata l'icona X. Per una spiegazione dettagliata di questo comportamento, vedere Perché non si ottengono anteprime per i file contrassegnati offline?

    Per domande su come gestire i file a livelli, vedere Come gestire i file a livelli.

  • Perché sono presenti file a livelli all'esterno dello spazio dei nomi dell'endpoint server?
    Prima dell'agente di Sincronizzazione file di Azure versione 3, Sincronizzazione file di Azure bloccava lo spostamento dei file a livelli all'esterno dell'endpoint server e ne consentiva lo spostamento solo nello stesso volume dell'endpoint server. Le operazioni di copia, gli spostamenti di file non a livelli e gli spostamenti di file a livelli in altri volumi non sono stati interessati. Il motivo di questo comportamento è il presupposto implicito, da parte di Esplora file e di altre API di Windows, che le operazioni di spostamento nello stesso volume siano operazioni di ridenominazione (quasi) istantanee. Durante gli spostamenti, Esplora file o altri metodi di spostamento (ad esempio tramite riga di comando o PowerShell) sembrano quindi non rispondere mentre Sincronizzazione file di Azure richiama i dati dal cloud. A partire dall'agente di Sincronizzazione file di Azure versione 3.0.12.0, Sincronizzazione file di Azure consente di spostare un file a livelli all'esterno dell'endpoint server. Gli effetti negativi indicati in precedenza vengono evitati consentendo la presenza del file a livelli all'esterno dell'endpoint server e richiamando quindi il file in background. Ciò significa che gli spostamenti sullo stesso volume sono istantanei e vengono eseguite tutte le operazioni per richiamare il file su disco al termine dello spostamento.

  • Si è verificato un problema con Sincronizzazione file di Azure nel server (sincronizzazione, suddivisione in livelli cloud e così via). È necessario rimuovere e ricreare l'endpoint server?

    No: la rimozione di un endpoint server non è simile al riavvio di un server. La rimozione e la ricreazione dell'endpoint server non è quasi mai una soluzione appropriata per risolvere i problemi relativi alla sincronizzazione, alla suddivisione in livelli nel cloud o ad altri aspetti di Sincronizzazione file di Azure. La rimozione di un endpoint server è un'operazione distruttiva. Potrebbe comportare la perdita di dati nel caso in cui i file a livelli esistano all'esterno dello spazio dei nomi dell'endpoint server. Per altre informazioni, vedere perché i file a livelli esistono all'esterno dello spazio dei nomi dell'endpoint server per altre informazioni. In alternativa, potrebbe risultare inaccessibile file per i file a livelli presenti nello spazio dei nomi dell'endpoint server. Questi problemi non verranno risolti quando l'endpoint server viene ricreato. I file a livelli potrebbero esistere all'interno dello spazio dei nomi dell'endpoint server anche se la suddivisione a livelli del cloud non è mai stata abilitata. Per questo motivo, è consigliabile non rimuovere l'endpoint server a meno che non si voglia interrompere l'uso di Sincronizzazione file di Azure con questa cartella specifica o che sia stato richiesto esplicitamente di farlo da un tecnico Microsoft. Per altre informazioni sulla rimozione degli endpoint server, vedere Rimuovere un endpoint server.

  • È possibile spostare il servizio di sincronizzazione archiviazione e/o l'account di archiviazione in un gruppo di risorse, una sottoscrizione o un tenant Microsoft Entra diverso?
    Sì, è possibile spostare il servizio di sincronizzazione archiviazione e/o l'account di archiviazione in un gruppo di risorse, una sottoscrizione o un tenant Microsoft Entra diverso. Dopo aver spostato il servizio di sincronizzazione archiviazione o l'account di archiviazione, è necessario assegnare a Microsoft. Archiviazione Asincronizzazione dell'accesso all'account di archiviazione. Seguire questa procedura:

    1. Accedere al portale di Azure e selezionare Controllo di accesso (IAM) nel riquadro di spostamento a sinistra.

    2. Selezionare la scheda Assegnazioni di ruolo per elencare gli utenti e le applicazioni (entità servizio) che hanno accesso all'account di archiviazione.

    3. Verificare che Microsoft.StorageSync o il servizio Sincronizzazione file ibrida (nome dell'applicazione precedente) venga visualizzato nell'elenco con il ruolo Lettore e accesso ai dati.

      Se Microsoft.ArchiviazioneLa sincronizzazione o il servizio di Sincronizzazione file ibrido non viene visualizzato nell'elenco, seguire questa procedura:

      • Selezionare Aggiungi.
      • Nel campo Ruolo selezionare Lettore e accesso ai dati.
      • Nel campo Seleziona digitare Microsoft.ArchiviazioneSincronizzare, selezionare il ruolo e quindi selezionare Salva.

      Nota

      Quando si crea l'endpoint cloud, il servizio di sincronizzazione archiviazione e l'account di archiviazione devono trovarsi nello stesso tenant di Microsoft Entra. Dopo aver creato l'endpoint cloud, il servizio di sincronizzazione archiviazione e l'account di archiviazione possono essere spostati in tenant Microsoft Entra diversi.

  • Sincronizzazione file di Azure consente di mantenere gli ACL NTFS a livello di directory/file insieme ai dati archiviati in File di Azure?

    A partire dal 24 febbraio 2020, gli ACL nuovi ed esistenti a livelli per sincronizzazione file di Azure verranno mantenuti in formato NTFS e le modifiche ACL apportate direttamente alla condivisione file di Azure verranno sincronizzate con tutti i server del gruppo di sincronizzazione. Le modifiche apportate agli elenchi di controllo di accesso alle condivisioni file di Azure verranno sincronizzate tramite Sincronizzazione file di Azure. Quando si copiano dati in File di Azure, assicurarsi di usare uno strumento di copia che supporti la "fedeltà" necessaria per copiare attributi, timestamp e ACL in una condivisione file di Azure, tramite SMB o REST. Quando si usano strumenti di copia di Azure come AzCopy, è importante usare la versione più recente. Controllare la tabella degli strumenti di copia file per ottenere una panoramica degli strumenti di copia di Azure per assicurarsi di copiare tutti i metadati importanti di un file.

    Se è stata abilitata Backup di Azure nelle condivisioni file gestite Sincronizzazione file di Azure, gli ACL dei file possono continuare a essere ripristinati come parte del flusso di lavoro di ripristino del backup. Questa operazione può essere eseguita per l'intera condivisione o per singoli file/directory.

    Se si usano snapshot come parte della soluzione di backup autogestito per le condivisioni file gestite da Sincronizzazione file di Azure, gli ACL potrebbero non essere ripristinati correttamente negli ACL NTFS se gli snapshot sono stati creati prima del 24 febbraio 2020. In tal caso, è consigliabile contattare il supporto di Azure.

  • Sincronizzazione file di Azure sincronizza LastWriteTime per le directory? Perché il timestamp di data modificato in una directory non viene aggiornato quando vengono modificati i file all'interno?
    No, Sincronizzazione file di Azure non sincronizza LastWriteTime per le directory. Inoltre, File di Azure non aggiorna il timestamp di data modificato (LastWriteTime) per le directory quando i file all'interno della directory vengono modificati. Si tratta di un comportamento previsto.

Sicurezza, autenticazione e controllo di accesso

  • Come è possibile controllare l'accesso ai file e le modifiche in File di Azure?

    Sono disponibili due opzioni che forniscono funzionalità di controllo per File di Azure:

    • Se gli utenti accedono direttamente alla condivisione file di Azure, è possibile usare Archiviazione di Azure log per tenere traccia delle modifiche dei file e dell'accesso degli utenti ai fini della risoluzione dei problemi. Le richieste vengono registrate in base al massimo sforzo.
    • Se gli utenti accedono alla condivisione file di Azure tramite Windows Server in cui è installato l'agente Sincronizzazione file di Azure, usare un criterio di controllo o un prodotto di terze parti per tenere traccia delle modifiche dei file e dell'accesso degli utenti in Windows Server.

  • File di Azure supporta l'uso dell'enumerazione basata su accesso per controllare la visibilità dei file e delle cartelle nelle condivisioni file di Azure SMB?

    L'uso di ABE con File di Azure non è attualmente supportato, ma è possibile usare DFS-N con condivisioni file di Azure SMB.

Autenticazione basata sull'identità

  • Microsoft Entra Domain Services supporta l'accesso SMB usando le credenziali di Microsoft Entra dai dispositivi aggiunti o registrati con Microsoft Entra ID?

    No, questo scenario non è supportato.

  • È possibile usare il nome canonico (CNAME) per montare una condivisione file di Azure usando l'autenticazione basata su identità?

    Sì, questo scenario è ora supportato sia in ambienti a foresta singola che in più foreste per condivisioni file di Azure SMB. Tuttavia, File di Azure supporta solo la configurazione di CNAMes usando il nome dell'account di archiviazione come prefisso di dominio. Se non si vuole usare il nome dell'account di archiviazione come prefisso, è consigliabile usare invece spazi dei nomi DFS.

  • È possibile accedere alle condivisioni file di Azure con le credenziali di Microsoft Entra da una macchina virtuale in una sottoscrizione diversa?

    Se la sottoscrizione con cui viene distribuita la condivisione file è associata allo stesso tenant di Microsoft Entra della distribuzione di Microsoft Entra Domain Services a cui è aggiunta la macchina virtuale, è possibile accedere alle condivisioni file di Azure usando le stesse credenziali di Microsoft Entra. La limitazione viene imposta non sulla sottoscrizione, ma sul tenant Microsoft Entra associato.

  • È possibile abilitare Microsoft Entra Domain Services o l'autenticazione di Active Directory Domain Services locale per le condivisioni file di Azure usando un tenant di Microsoft Entra diverso dal tenant primario della condivisione file di Azure?

    No. File di Azure supporta solo Microsoft Entra Domain Services o l'integrazione di Active Directory Domain Services locale con un tenant di Microsoft Entra che risiede nella stessa sottoscrizione della condivisione file. Una sottoscrizione può essere associata solo a un tenant di Microsoft Entra. Quando si usa Active Directory Domain Services locale per l'autenticazione, le credenziali di Active Directory Domain Services devono essere sincronizzate con l'ID Microsoft Entra a cui è associato l'account di archiviazione.

  • L'autenticazione AD DS locale per le condivisioni file di Azure supporta l'integrazione con un ambiente AD DS usando più foreste?

    L'autenticazione AD DS locale di File di Azure si integra solo con la foresta del servizio del dominio in cui è registrato l'account di archiviazione. Per supportare l'autenticazione da un'altra foresta, è necessario che nell'ambiente sia configurato correttamente un trust della foreste. Per istruzioni dettagliate, vedere Usare File di Azure con più foreste di Active Directory.

    Nota

    In un'installazione a più foreste non usare Esplora file per configurare le autorizzazioni ACL/NTFS di Windows a livello di radice, directory o file. Usare invece icacls .

  • C'è una differenza nella creazione di un account computer o di un account di accesso al servizio per rappresentare l'account di archiviazione in AD?

    La creazione di un account computer (impostazione predefinita) o di un account di accesso al servizio non ha alcuna differenza sul funzionamento dell'autenticazione con File di Azure. È possibile scegliere l'identità di account di archiviazione nell'ambiente AD. Il valore predefinito DomainAccountType impostato nel Join-AzStorageAccountForAuth cmdlet è l'account computer. Tuttavia, l'età di scadenza della password configurata nell'ambiente AD può essere diversa per gli account di accesso al computer o al servizio ed è necessario prendere in considerazione questo aspetto per aggiornare la password dell'identità dell'account di archiviazione in AD.

  • Come rimuovere le credenziali memorizzate nella cache con la chiave dell'account di archiviazione ed eliminare le connessioni SMB esistenti prima di inizializzare una nuova connessione con le credenziali di Microsoft Entra ID o AD?

    Seguire il processo di due passaggi seguente per rimuovere le credenziali salvate associate alla chiave dell'account di archiviazione e rimuovere la connessione SMB:

    1. Eseguire il comando seguente da un prompt dei comandi di Windows per rimuovere le credenziali. Se non è possibile trovarne uno, significa che le credenziali non sono state salvate in modo permanente e possono ignorare questo passaggio.

      cmdkey /delete:Domain:target=storage-account-name.file.core.windows.net

    2. Eliminare la connessione esistente alla condivisione file. È possibile specificare il percorso di montaggio come lettera di unità montata o come storage-account-name.file.core.windows.net percorso.

      net use <drive-letter/share-path> /delete

  • È possibile visualizzare userPrincipalName (UPN) di un proprietario di file/directory in Esplora file anziché l'identificatore di sicurezza (SID)?

    Esplora file chiama un'API RPC direttamente al server (File di Azure) per convertire il SID in un UPN. File di Azure non supporta questa API, quindi in Esplora file, il SID di un proprietario di file/directory viene visualizzato anziché l'UPN per i file e le directory ospitati in File di Azure. Tuttavia, da un client aggiunto a un dominio, è possibile usare il comando di PowerShell seguente per visualizzare tutti gli elementi in una directory e il relativo proprietario, incluso l'UPN:

    Get-ChildItem <Path> | Get-ACL | Select Path, Owner

File system di rete (NFS v4.1)

Snapshot di condivisione

Creare snapshot di condivisione

  • Gli snapshot di condivisione hanno ridondanza geografica?
    Gli snapshot di condivisione hanno la stessa ridondanza della condivisione file di Azure per cui sono stati creati. Se è stata selezionata l'archiviazione con ridondanza geografica per l'account, lo snapshot di condivisione viene archiviato in modo ridondante nell'area abbinata.

Pulire gli snapshot di condivisione

  • È possibile eliminare la condivisione senza eliminare gli snapshot di condivisione?
    Se nella condivisione sono presenti snapshot di condivisione attivi, non è possibile eliminare la condivisione. È possibile usare un'API per eliminare gli snapshot di condivisione, insieme alla condivisione. È anche possibile eliminare sia gli snapshot di condivisione che la condivisione nel portale di Azure.

Determinazione dei prezzi e fatturazione

  • Quali sono le transazioni in File di Azure e come vengono fatturate? Le transazioni del protocollo si verificano ogni volta che un utente, un'applicazione, uno script o un servizio interagisce con le condivisioni file di Azure (scrittura, lettura, presentazione, eliminazione di file e così via). È importante ricordare che alcune azioni che potrebbero essere percepite come una singola operazione potrebbero effettivamente comportare più transazioni. Per le condivisioni file standard di Azure fatturate su un modello con pagamento in base al consumo, diversi tipi di transazioni hanno prezzi diversi in base al loro impatto sulla condivisione file. Le transazioni non influiscono sulla fatturazione per le condivisioni file Premium, fatturate usando un modello con provisioning. Per altre informazioni, vedere Informazioni sulla fatturazione.

  • Qual è il costo degli snapshot di condivisione?
    Gli snapshot di condivisione sono di natura incrementale. Lo snapshot di condivisione di base è la condivisione stessa. Tutti gli snapshot di condivisione successivi sono incrementali e archiviano solo le differenze rispetto allo snapshot di condivisione precedente. Vengono fatturati solo i contenuti modificati. Se si ha una condivisione con 100 GiB di dati, ma solo 5 GiB sono stati modificati dopo l'ultimo snapshot di condivisione, lo snapshot di condivisione utilizza solo 5 GiB aggiuntivi e viene addebitato un costo di 105 GiB. Per altre informazioni sui costi di transazione e di uscita standard, vedere la pagina dei prezzi.

Interoperabilità con altri servizi

  • È possibile usare una condivisione file di Azure come Controllo di condivisione file per un cluster di failover di Windows Server?
    Questa configurazione non è attualmente supportata per File di Azure. Per informazioni su come configurare questa impostazione usando l'archiviazione BLOB di Azure, vedere Distribuire un cloud di controllo per un cluster di failover.

Vedi anche