Condividi tramite

Domande frequenti su File di Azure e Sincronizzazione file di Azure

  • Articolo

File di Azure offre condivisioni file completamente gestite nel cloud, accessibili tramite il protocollo SMB (Server Message Block) e il protocollo NFS (Network File System) standard di settore. È 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 diverse ad Active Directory, anche se non aggiunti a un dominio. Anche se questa configurazione funziona dal punto di vista tecnico, non è consigliabile usarla come configurazione tipica dato che gli elenchi di controllo di accesso (ACL) definiti per i file e le cartelle in un server potrebbero non essere applicati da altri server nel gruppo di sincronizzazione. Per ottenere risultati ottimali, è consigliabile la sincronizzazione tra server nella stessa foresta di Active Directory, server in foreste di Active Directory diverse ma con relazioni di trust stabilite o server non inclusi in un dominio. È consigliabile evitare di usare una combinazione di queste configurazioni.

  • È stato creato un file direttamente nella condivisione file di Azure su SMB o nel portale. Quanto tempo occorre per la sincronizzazione del file nei 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 degli utenti finali, è consigliabile installare l'agente di Sincronizzazione file di Azure in una macchina virtuale IaaS e fare in modo che gli utenti finali accedano 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. È possibile incrementare la priorità dello sviluppo futuro di questa funzionalità 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: vengono mantenute entrambe le modifiche ai file modificati nei due endpoint contemporaneamente. 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.

  • Il cloud a livelli è disabilitato, perché nel percorso dell'endpoint server sono presenti file a livelli?
    Esistono due motivi per cui nel percorso dell'endpoint server potrebbero esistere file a livelli:

    • Quando si aggiunge un nuovo endpoint server a un gruppo di sincronizzazione esistente, se si sceglie l'opzione per richiamare prima lo spazio dei nomi oppure per richiamare solo lo spazio dei nomi per la modalità di download iniziale, i file verranno visualizzati come a livelli finché non vengono scaricati localmente. Per evitarlo, selezionare l'opzione Evitare i file a livelli per la modalità di download iniziale. Per richiamare manualmente i file, usare il cmdlet Invoke-StorageSyncFileRecall.

    • Se il cloud a livelli è stato abilitato nell'endpoint server e quindi disabilitato, i file rimarranno a livelli fino a quando non vi si accede.

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

    Questo comportamento non è specifico di Sincronizzazione file di Azure. Esplora file di Windows 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 le miniature per i file contrassegnati come 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. Operazioni di copia, spostamenti di file non a livelli e spostamenti di file a livelli in altri volumi non erano 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. Questo vuol dire che gli spostamenti nello stesso volume sono istantanei e che al termine dello spostamento il file viene richiamato automaticamente su disco.

  • Si è verificato un problema di Sincronizzazione file di Azure nel server (sincronizzazione, cloud a livelli e così via). È consigliabile rimuovere l'endpoint server e ricrearlo?

    No, rimuovere un endpoint server non equivale a riavviare un server. Rimuovere e ricreare l'endpoint server non è quasi mai una soluzione appropriata per risolvere i problemi di sincronizzazione, suddivisione in livelli del cloud o altri aspetti di Sincronizzazione file di Azure. La rimozione di un endpoint server è un'operazione distruttiva. Può comportare la perdita di dati se sono presenti file a livelli all'esterno dello spazio dei nomi dell'endpoint server. Per altre informazioni, vedere Perché sono presenti file a livelli all'esterno dello spazio dei nomi dell'endpoint server. In alternativa, potrebbe comportare l'inaccessibilità dei file a livelli presenti nello spazio dei nomi dell'endpoint server. Questi problemi non verranno risolti ricreando l'endpoint server. 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. È pertanto consigliabile non rimuovere l'endpoint server a meno che non si voglia interrompere l'uso di Sincronizzazione file di Azure con questa particolare cartella o non si ricevano istruzioni esplicite a tale scopo da un tecnico Microsoft. Per altre informazioni sulla rimozione degli endpoint server, vedere Rimuovere un endpoint server.

  • Si può spostare il servizio di sincronizzazione archiviazione e/o l'account di archiviazione in un gruppo di risorse, una sottoscrizione o un tenant di Microsoft Entra diversi?
    Si, è possibile spostare il servizio di sincronizzazione archiviazione e/o l'account di archiviazione in un gruppo di risorse, una sottoscrizione o un tenant di Microsoft Entra diverso. Dopo aver spostato il servizio di sincronizzazione archiviazione o l'account di archiviazione, è necessario concedere all'applicazione Microsoft.StorageSync l'accesso all'account di archiviazione. Seguire questa procedura:

    1. Accedere al portale di Azure e selezionare Controllo di accesso (IAM) dal menu di spostamento sinistro.

    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.StorageSync o il servizio Sincronizzazione file ibrida non compare nell'elenco, eseguire i passaggi seguenti:

      • Selezionare Aggiungi.
      • Nel campo Ruolo selezionare Lettore e accesso ai dati.
      • Nel campo Seleziona digitare Microsoft.StorageSync, 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 di 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 24, 2020, gli ACL nuovi ed esistenti suddivisi in livelli da Sincronizzazione file di Azure verranno mantenuti in formato NTFS e le modifiche agli ACL apportate direttamente alla condivisione file di Azure verranno sincronizzate in tutti i server del gruppo di sincronizzazione. Tutte le modifiche agli ACL apportate alle condivisioni file di Azure si sincronizzeranno 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 l'ultima versione. 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 Backup di Azure è stato abilitato nelle condivisioni file gestite da 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 gli snapshot come parte della soluzione di backup autogestita per le condivisioni file gestite da Sincronizzazione file di Azure, gli ACL potrebbero non essere ripristinati correttamente in ACL NTFS se gli snapshot sono stati eseguiti prima del 24 febbraio 24, 2020. In tal caso, è consigliabile contattare il supporto di Azure.

  • Sincronizzazione file di Azure sincronizza il valore LastWriteTime per le directory? Perché il timestamp della data di modifica di una directory non viene aggiornato quando vengono modificati i file al suo interno?
    No, Sincronizzazione file di Azure non sincronizza il valore LastWriteTime per le directory. Inoltre, File di Azure non aggiorna il timestamp della data di modifica (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 log di Archiviazione di Azure per tenere traccia delle modifiche ai 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 un'istanza di Windows Server in cui è installato l'agente di Sincronizzazione file di Azure, usare criteri di controllo o un prodotto di terze parti per tenere traccia delle modifiche ai file e dell'accesso degli utenti in Windows Server.

  • File di Azure supporta l'uso dell'enumerazione basata sull'accesso (Access-Based Enumeration, ABE) per controllare la visibilità dei file e delle cartelle nelle condivisioni file SMB di Azure?

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

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 quando si usa l'autenticazione basata sull'identità?

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

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

    Se la sottoscrizione in cui è distribuita la condivisione file è associata allo stesso tenant di Microsoft Entra della distribuzione di Microsoft Entra Domain Services in cui la macchina virtuale è aggiunta a un dominio, sarà possibile accedere a File di Azure usando le stesse credenziali di Microsoft Entra. La limitazione si applica non alla sottoscrizione, ma al tenant di Microsoft Entra associato.

  • È possibile abilitare l'autenticazione di Microsoft Entra Domain Services o 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 l'integrazione di Microsoft Entra Domain Services o di Active Directory Domain Services locale con un tenant di Microsoft Entra che si trova nella stessa sottoscrizione della condivisione file. Una sottoscrizione può essere associata a un solo 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 Microsoft Entra ID 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 icals invece.

  • 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 del servizio non fa 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 cmdlet Join-AzStorageAccountForAuth è l'account computer. Tuttavia, la scadenza della password configurata nell'ambiente AD può essere diversa per gli account di accesso del computer o del servizio ed è necessario prendere in considerazione questo aspetto per aggiornare la password dell'identità dell'account di archiviazione in AD.

  • Come è possibile 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?

    Per rimuovere le credenziali salvate associate alla chiave dell'account di archiviazione e rimuovere la connessione SMB, attenersi al processo in due passaggi seguente:

    1. Eseguire il comando seguente da un prompt dei comandi di Windows per rimuovere le credenziali. Se non è possibile trovare le credenziali, significa che non sono state conservate, quindi è possibile 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 percorso storage-account-name.file.core.windows.net.

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

  • È possibile visualizzare il nome dell'entità utente (UPN) di un proprietario di file/directory in Esplora file anziché l'ID di sicurezza (SID)?

    Esplora file chiama un'API RPC direttamente nel 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 al posto dell'UPN per file e 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

NFS (Network File System) versione 4.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 scelta l'archiviazione con ridondanza geografica per l'account, anche lo snapshot di condivisione verrà archiviato in modo ridondante nell'area associata.

Pulire gli snapshot di condivisione

  • È possibile eliminare la condivisione senza eliminare gli snapshot di condivisione?
    No. Il flusso di lavoro di eliminazione condivisione file eliminerà automaticamente gli snapshot quando viene eliminata la condivisione.

Determinazione dei prezzi e fatturazione

  • Cosa sono le transazioni in File di Azure e come vengono fatturate? Le transazioni di protocollo si verificano ogni volta che un utente, un'applicazione, uno script o un servizio interagisce con le condivisioni file di Azure (scrittura, lettura, elenco, eliminazione di file e così via). È importante ricordare che alcune azioni che potrebbero essere percepite come una singola operazione potrebbero in effetti implicare più transazioni. Per le condivisioni file standard di Azure fatturate con un modello con pagamento in base al consumo, tipi di transazioni diversi hanno prezzi diversi in base al loro impatto sulla condivisione file. Le transazioni non influiscono sulla fatturazione per le condivisioni file Premium, che vengono 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. È previsto un addebito solo per il contenuto modificato. Se è disponibile una condivisione con 100 GiB di dati, ma solo 5 GiB sono stati modificati dall'ultimo snapshot di condivisione, lo snapshot di condivisione consuma solo 5 GiB aggiuntivi e vengono addebitati solo 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 questo servizio per Archiviazione BLOB di Azure, vedere Distribuire un cloud di controllo per un cluster di failover.

Vedi anche