Eseguire la migrazione alle condivisioni file di Azure NFS
Questo articolo illustra gli aspetti di base della migrazione da file server Linux a condivisioni file di Azure NFS, disponibili solo come condivisioni file Premium (File Archiviazione tipo di account). Verranno confrontati anche gli strumenti di copia file open source fpsync e rsync per comprendere come eseguono durante la copia dei dati nelle condivisioni file di Azure.
Nota
File di Azure non supporta gli elenchi di controllo di accesso NFS (ACL).
Si applica a
| Tipo di condivisione file | SMB | NFS |
|---|---|---|
| Condivisioni file Standard (GPv2), archiviazione con ridondanza locale/archiviazione con ridondanza della zona |  |
|
| Condivisioni file Standard (GPv2), archiviazione con ridondanza geografica/archiviazione con ridondanza geografica della zona | |
|
| Condivisioni file Premium (FileStorage), archiviazione con ridondanza locale/archiviazione con ridondanza della zona | |
 |
Prerequisiti
È necessaria almeno una condivisione file di Azure NFS montata in una macchina virtuale Linux. Per crearne uno, vedere Creare una condivisione file di Azure NFS e montarla in una macchina virtuale Linux. È consigliabile montare la condivisione con nconnect per usare più connessioni TCP. Per altre informazioni, vedere Migliorare le prestazioni delle condivisioni file di Azure NFS.
Strumenti di migrazione
Molti strumenti open source sono disponibili per trasferire i dati in condivisioni file NFS. Tuttavia, non tutti sono efficienti quando si tratta di un file system distribuito con considerazioni sulle prestazioni distinte rispetto alle configurazioni locali. In un file system distribuito, ogni chiamata di rete prevede un round trip a un server che potrebbe non essere locale. Pertanto, l'ottimizzazione del tempo dedicato alle chiamate di rete è fondamentale per ottenere prestazioni ottimali e un trasferimento efficiente dei dati in rete.
Uso di fpsync e rsync
Nonostante sia a thread singolo, rsync è uno strumento di copia file open source versatile. Può copiare localmente, da/verso un altro host su qualsiasi shell remota o da un daemon rsync remoto. Offre molte opzioni e consente la specifica flessibile del set di file da copiare. Fpsync, tuttavia, è un'applicazione multithreading e offre quindi alcuni vantaggi, tra cui la possibilità di eseguire processi rsync in parallelo.
In questo articolo si userà fpsync per spostare i dati da un file server Linux a condivisioni file di Azure NFS.
Per copiare i dati, fpsync usa gli strumenti rsync (impostazione predefinita), cpio o tar. Calcola i subset della directory src_dir/ di origine e genera processi di sincronizzazione per sincronizzarli con la directory dst_dir/di destinazione . Esegue i processi di sincronizzazione in tempo reale durante la ricerca per indicizzazione simultanea del file system, rendendolo uno strumento utile per eseguire in modo efficiente la migrazione di file system di grandi dimensioni e la copia di set di dati di grandi dimensioni con più file.
Nota
Fpsync sincronizza solo il contenuto della directory, non la directory di origine stessa. A differenza di rsync, fpsync applica l'ultimo '/' nella directory di origine, il che significa che non si otterrà una sottodirectory con il nome della directory di origine nella directory di destinazione dopo la sincronizzazione.
Installare fpart
Per usare fpsync, è necessario installare il partitioner del file system fpart. Installare fpart nella distribuzione linux preferita. Dopo l'installazione, verrà visualizzato fpsync in /usr/bin/.
In Ubuntu usare apt package manager per installare fpart.
sudo apt-get install fpart
Copiare dati dall'origine alla destinazione
Assicurarsi che la condivisione file di Azure di destinazione (di destinazione) sia montata in una macchina virtuale Linux. Vedere Prerequisiti.
Se si esegue una migrazione completa, i dati verranno copiati in tre fasi:
- Copia di base: copia dall'origine alla destinazione quando non sono presenti dati nella destinazione. Per la copia di base, è consigliabile usare fpsync con cpio come strumento di copia.
- Copia incrementale: copiare solo le modifiche incrementali dall'origine alla destinazione. Per la sincronizzazione incrementale, è consigliabile usare fpsync con rsync come strumento di copia. Questa operazione deve essere eseguita più volte per acquisire tutte le modifiche.
- Passaggio finale: è necessario un passaggio finale per eliminare tutti i file nella destinazione che non esistono nell'origine.
La copia di dati con fpsync implica sempre una versione di questo comando:
fpsync -m <specify copy tool - rsync/cpio/tar> -n <parallel transfers> <absolute source path> <absolute destination path>
Copia di base
Per la copia di base, usare fpsync con cpio.
fpsync -m cpio -n <parallel transfers> <absolute source path> <absolute destination path>
Per altre informazioni, vedere Supporto di Cpio e Tar.
Copia incrementale
Per la sincronizzazione incrementale, usare fpsync con lo strumento di copia predefinito (rsync). Per acquisire tutte le modifiche, è consigliabile eseguire questa operazione più volte.
fpsync -n <parallel transfers> <absolute source path> <absolute destination path>
Per impostazione predefinita, fpsync specifica le opzioni rsync seguenti: -lptgoD -v --numeric-ids. È possibile specificare opzioni rsync aggiuntive aggiungendo -o option al comando fpsync.
Passaggio finale
Dopo diverse sincronizzazioni incrementali, è necessario eseguire un passaggio finale per eliminare tutti i file in tale destinazione che non esistono all'origine. È possibile eseguire questa operazione manualmente con rsync --delete per eliminare file aggiuntivi dalla /data/dst/ directory oppure usare fpsync con l'opzione -E. Per informazioni dettagliate, vedere Il passaggio finale.
Confronto tra rsync e fpsync con set di dati diversi
Questa sezione confronta le prestazioni di rsync e fpsync con set di dati diversi.
Set di dati e configurazione
La tabella seguente elenca i diversi set di dati usati per confrontare le prestazioni degli strumenti di copia in carichi di lavoro diversi.
| Config # | Tipo di copia | Numero di file | Conteggio directory | Dimensioni file | Dimensioni totali |
|---|---|---|---|---|---|
| 1.1 | Copia di base | 1 milione | 1 | 0-32 KiB | 18 GiB |
| 1.2 | Incrementale (modifica differenziale) | 1 milione | 1 | 0-32 KiB | 18 GiB |
| 2 | Copia di base | 191,345 | 3,906 | 0-32 KiB | 3 GiB |
| 3 | Copia di base | 5,000 | 1 | 10 MiB | 50 GiB |
I test sono stati eseguiti su macchine virtuali di Azure Standard_D8s_v3 con 8 vCPU, 32 GiB di memoria e più di 1 TiB di spazio su disco per set di dati di grandi dimensioni. Per la destinazione, sono stati configurati condivisioni file di Azure NFS con più di 1 TiB di cui è stato effettuato il provisioning.
Esperimenti e risultati: rsync e fpsync
In base agli esperimenti con le configurazioni precedenti, si è osservato che fpsync ha eseguito al meglio quando viene usato con 64 thread con rsync e 16 thread con cpio per una condivisione file NFS di Azure montata con nconnect=8. I risultati effettivi variano in base alla configurazione e ai set di dati.
Nota
La velocità effettiva per File di Azure può essere molto superiore a quella rappresentata nei grafici seguenti. Alcuni esperimenti sono stati deliberatamente condotti con piccoli set di dati per semplicità.
Configurazione 1
Per una singola directory con 1 milione di file di piccole dimensioni pari a 18 GiB, questo test è stato eseguito sia come copia di base che come copia incrementale.
Sono stati osservati i risultati seguenti eseguendo una copia di base dall'origine alla destinazione.
Sono stati osservati i risultati seguenti eseguendo una copia incrementale (modifica differenziale).
Configurazione 2
Sono stati osservati i risultati seguenti eseguendo una copia di base di 191.345 file di piccole dimensioni in 3.906 directory con dimensioni totali pari a 3 GiB.
Configurazione 3
Sono stati osservati i risultati seguenti eseguendo una copia di base di 5.000 file di grandi dimensioni (10 MiB) in una singola directory con dimensioni totali di 50 GiB.
Riepilogo dei risultati
L'uso di applicazioni multithread come fpsync può migliorare la velocità effettiva e le operazioni di I/O al secondo durante la migrazione alle condivisioni file di Azure NFS rispetto agli strumenti di copia a thread singolo, ad esempio rsync. I test mostrano che:
- La distribuzione dei dati nella directory consente di parallelizzare il processo di migrazione e di ottenere così prestazioni migliori.
- La copia di dati da dimensioni di file di dimensioni maggiori garantisce prestazioni migliori rispetto alla copia dei dati da dimensioni di file più piccole.
La tabella seguente riepiloga i risultati:
| Config # | Numero di file | Conteggio directory | Dimensioni file | Dimensioni totali | durata rsync | velocità effettiva rsync | durata fpsync | velocità effettiva fpsync | Aumento della velocità effettiva |
|---|---|---|---|---|---|---|---|---|---|
| 1.1 (baseline) | 1 milione | 1 | 0-32 KiB | 18 GiB | 837,06 minuti | 0.33 MiB/s | 228,16 minuti | 1.20 MiB/s | 267% |
| 1.2 (incrementale) | 1 milione | 1 | 0-32 KiB | 18 GiB | 84,02 minuti | 3.25 MiB/s | 7,5 minuti | 36.41 MiB/s | 1,020% |
| 2 (baseline) | 191,345 | 3,906 | 0-32 KiB | 3 GiB | 191,86 minuti | 0.27 MiB/s | 8,47 minuti | 6.04 MiB/s | 2,164% |
| 3 (baseline) | 5,000 | 1 | 10 MiB | 50 GiB | 8,12 minuti | 105.04 MiB/s | 2,76 minuti | 308.90 MiB/s | 94% |
Dichiarazione di non responsabilità sulle informazioni di terze parti
Gli strumenti open source menzionati in questo articolo sono soluzioni di terze parti note. Non sono sviluppati, di proprietà o supportati da Microsoft, direttamente o indirettamente. È responsabilità del cliente esaminare la licenza software e la dichiarazione di supporto fornita nella documentazione di terze parti.
Passaggi successivi
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per