Usa Data Box per migrare da Network Attached Storage (NAS) a condivisioni file Azure

✔️ Si applica a: condivisioni file SMB classiche create con il provider di risorse Microsoft.Storage

✖️ Non si applica a: tutte le condivisioni di file NFS, incluse quelle create con il provider di risorse Microsoft.FileShares o le condivisioni di file classiche create con il provider di risorse Microsoft.Storage

Questo articolo sulla migrazione è uno dei diversi che coinvolgono le parole chiave NAS e Azure Data Box. Controllare se questo articolo si applica al proprio scenario:

  • Origine dati: Network Attached Storage (NAS)
  • Percorso di migrazione: NAS ⇒ Data Box ⇒ Azure file share
  • Nessun file di memorizzazione nella cache locale: poiché l'obiettivo finale consiste nell'usare le condivisioni file di Azure direttamente nel cloud, non è previsto l'uso di Sincronizzazione file di Azure.

Se lo scenario è diverso, esaminare la tabella delle guide alla migrazione.

Note

Data Box supporta NFS come protocollo di copia, quindi puoi usarlo per copiare dati da un NAS che serve NFS. Tuttavia, Data Box non supporta l'importazione diretta dei dati nelle condivisioni file di NFS Azure. Questa guida riguarda solo i target di condivisione file SMB.

Questo articolo illustra come eseguire la pianificazione, la distribuzione e le configurazioni di rete necessarie per eseguire la migrazione dall'appliance NAS alle condivisioni file di Azure funzionali. Questa guida utilizza Azure Data Box per il trasporto di dati in massa (trasporto dati offline).

Obiettivi della migrazione

L'obiettivo è spostare le condivisioni nell'appliance NAS in Azure e farle diventare condivisioni file di Azure native. È possibile usare condivisioni file di Azure native senza bisogno di un server Windows. Questa migrazione deve essere eseguita in modo da garantire l'integrità dei dati di produzione e della disponibilità durante la migrazione. Quest'ultimo aspetto richiede un tempo di inattività minimo, in modo da poter rientrare o superare leggermente le normali finestre di manutenzione.

Panoramica della migrazione

Il processo di migrazione è costituito da varie fasi. Per prima cosa, distribuisci account di archiviazione Azure e condivisioni file e configura la rete. Poi, migra i tuoi file usando Azure Data Box e RoboCopy per aggiornarti sulle modifiche. Infine, si esegue il cut-over degli utenti e delle app nelle nuove condivisioni file di Azure create. Le sezioni seguenti descrivono in dettaglio le fasi del processo di migrazione.

Suggerimento

Se si torna a questo articolo, usare lo spostamento sul lato destro per passare alla fase di migrazione in cui ci si è interrotti.

Fase 1: Determinare il numero di condivisioni file di Azure necessarie

Determina quante condivisioni file di Azure ti occorrono. Potrebbero essere presenti più cartelle nei volumi attualmente condivisi in locale come condivisioni SMB per gli utenti e le app. A seconda del numero di condivisioni di file che desideri migrare nel cloud, scegli tra una mappatura uno a uno e un raggruppamento delle condivisioni.

Usare un mapping 1:1

Se hai un numero limitato di azioni, usa una mappatura uno a uno. Il modo più semplice per farsi un'idea di questo scenario è immaginare una condivisione on-premises che corrisponde uno a uno a una condivisione file di Azure.

Usare il raggruppamento di condivisioni

Se si dispone di un numero elevato di condivisioni file, prendere in considerazione il raggruppamento di condivisioni. Ad esempio, se il reparto risorse umane (HR) ha 15 condivisioni, valutare l’archiviazione di tutti i dati delle risorse umane in una singola condivisione file di Azure. In questo modo, è necessaria solo una singola condivisione file di Azure nel cloud per questo gruppo di condivisioni locali.

Fase 2: Distribuire le risorse di archiviazione di Azure

In questa fase, effettua il provisioning degli account di archiviazione di Azure e delle condivisioni di file al loro interno.

Tenere presente che una condivisione file di Azure è distribuita nel cloud in un account di archiviazione di Azure. Per le condivisioni file HDD (standard), questa disposizione rende l'account di archiviazione un obiettivo di scalabilità per metriche di prestazione come IOPS e velocità effettiva. Se si inseriscono più condivisioni file in un singolo account di archiviazione, si crea un pool condiviso di operazioni di I/O al secondo e velocità effettiva per queste condivisioni.

Come regola generale, è possibile raggruppare più condivisioni file di Azure nello stesso account di archiviazione se si dispone di condivisioni di archiviazione o si prevede un'attività giornaliera bassa. Tuttavia, se hai condivisioni molto attive (condivisioni usate da molti utenti e applicazioni), distribuisci account di archiviazione con una condivisione file ciascuno. Queste limitazioni non si applicano agli account di archiviazione FileStorage (SSD), in cui le prestazioni vengono sottoposte a provisioning esplicito e garantite per ogni condivisione.

Note

Esiste un limite di 250 account di archiviazione per sottoscrizione e area di Azure. Con un aumento di quota, è possibile creare fino a 500 account di archiviazione per area. Per altre informazioni, vedere Aumentare le quote degli account di archiviazione di Azure.

Un'altra considerazione quando si distribuisce un account di archiviazione riguarda la ridondanza. Vedere Ridondanza di File di Azure.

Se fai una lista delle tue condivisioni, mappa ogni condivisione all'account di archiviazione dove la crei.

Anche i nomi delle risorse sono importanti. Ad esempio, se raggruppi più condivisioni per il reparto HR in un account di archiviazione Azure, nomina correttamente l'account di archiviazione. Allo stesso modo, quando dai un nome ai tuoi file shares Azure, usa nomi simili a quelli usati per i loro corrispettivi on-local.

A questo punto, distribuire il numero appropriato di account di archiviazione di Azure con il numero appropriato di condivisioni file di Azure, seguendo le istruzioni in Creare una condivisione file SMB. Nella maggior parte dei casi, assicurati che la regione di ciascuno dei tuoi account di archiviazione sia la stessa.

Fase 3: Determinare il numero di appliance Azure Data Box necessarie

Inizia questo passaggio solo quando completi la fase precedente. A questo punto, dovresti aver creato le risorse di archiviazione Azure, inclusi account di archiviazione e condivisioni file. Durante l'ordine del Data Box, devi specificare in quali account di archiviazione il Data Box trasferisce i dati.

In questa fase, mappa i risultati del piano di migrazione dalla fase precedente ai limiti delle opzioni disponibili di Data Box. Queste considerazioni ti aiutano a pianificare quali opzioni Data Box scegliere e quante ne servono per trasferire le condivisioni NAS su condivisioni file Azure.

Per determinare il numero di dispositivi necessari per ciascun tipo, considerare questi limiti importanti:

  • Qualsiasi Azure Data Box può spostare dati in fino a 10 account di archiviazione.
  • Ogni opzione Data Box ha una propria capacità utilizzabile. Vedere Opzioni di Data Box.

Consulta il tuo piano di migrazione per il numero di account di archiviazione che hai deciso di creare e le quote in ciascuno. Esaminare, quindi, le dimensioni di ognuna delle condivisioni nel NAS. Combinando queste informazioni, puoi decidere quale appliance inviare i dati a quali account di archiviazione. Puoi far spostare i file nello stesso account di archiviazione da due dispositivi Data Box, ma non suddividere il contenuto di una singola condivisione file tra due appliance Data Box.

Opzioni di Data Box

Per una migrazione standard, scegli una o una combinazione di queste due opzioni Data Box:

  • Data Box Questa opzione è la scelta più comune. È un appliance Data Box robusto che funziona in modo simile a un NAS. Viene spedito a te con una capacità utilizzabile di 80 TiB. Per altre informazioni, vedere Documentazione di Data Box.
  • Data Box Heavy Questa opzione presenta un apparato robusto Data Box su ruote che funziona in modo simile a un NAS, con una capacità di 1 PiB. La capacità utilizzabile è circa il 20% inferiore a causa del sovraccarico di crittografia e file system. Per altre informazioni, vedere Documentazione di Data Box Heavy.

Avviso

Data Box Disks non è consigliato per le migrazioni in condivisioni file di Azure. Data Box Disks non mantiene i metadati dei file, ad esempio le autorizzazioni di accesso (ACL) e altri attributi.

Fase 4: Effettuare il provisioning di un server Windows temporaneo

Mentre aspetti l'arrivo dei tuoi appliance Azure Data Box, puoi già distribuire uno o più server Windows necessari per eseguire i lavori RoboCopy. Per i requisiti di versione del sistema operativo, consulta la nota importante nella sezione RoboCopy.

  • Usa questi server per copiare i file sulla Data Box.
  • Usa questi server per aggiornarti sulle modifiche che avvengono sull'appliance NAS mentre il Data Box è in servizio. Questo approccio mantiene al minimo il tempo di inattività sul lato di origine.

La velocità con cui funzionano i tuoi lavori RoboCopy dipende principalmente da questi fattori:

Tieni a mente i dettagli di riferimento quando decidi la RAM e il numero di thread che fornisci ai tuoi Windows Server temporanei.

Fase 5: Preparazione all'uso delle condivisioni file di Azure

Per risparmiare tempo, procedi con questa fase mentre aspetti l'arrivo della tua Data Box. Con le informazioni di questa fase, puoi decidere come i tuoi server e gli utenti possono utilizzare le condivisioni file Azure. Le decisioni più critiche sono:

  • Rete: abilitare le reti per instradare il traffico SMB.
  • Autenticazione: configurare gli account di archiviazione di Azure per l'autenticazione Kerberos. Microsoft Entra Connect e l'unione al dominio del tuo account di archiviazione permettono alle tue app e agli utenti di usare la loro identità AD per l'autenticazione.
  • Autorizzazione: Le ACL a livello di condivisione per ogni condivisione file Azure permettono agli utenti AD e ai gruppi di accedere a una determinata condivisione, e all'interno di una condivisione file Azure assumono il controllo delle ACL NTFS native. L'autorizzazione basata su ACL di file e cartelle funziona quindi come per le condivisioni SMB locali.
  • Continuità aziendale: L'integrazione delle condivisioni file Azure in un ambiente esistente spesso comporta la conservazione degli indirizzi di condivisione esistenti. Se non si usano già i namespace DFS, considerare l'implementazione nell'ambiente. Puoi mantenere invariati gli indirizzi di condivisione usati dai tuoi utenti e script. È possibile usare DFS-N come servizio di routing dello spazio dei nomi per SMB reindirizzando le destinazioni DFS-Namespace alle condivisioni file di Azure dopo la migrazione.

Questo video è una guida e una demo su come esporre in modo sicuro le condivisioni file di Azure direttamente agli information worker e alle app in cinque semplici passaggi.
Il video fa riferimento alla documentazione dedicata per gli argomenti seguenti. Tenere presente che Azure Active Directory è ora Microsoft Entra ID. Per altre informazioni, vedere Nuovo nome di Azure AD.

Fase 6: Copia i file sulla tua Data Box

Quando arriva il tuo Data Box, configura il tuo Data Box con connettività di rete senza ostacoli al tuo dispositivo NAS. Segui la documentazione di configurazione per il tipo di Data Box che hai ordinato.

A seconda del tipo di Data Box, potresti avere accesso agli strumenti di copia Data Box. A questo punto, non usarli per le migrazioni verso le condivisioni file Azure perché non copiano i tuoi file con piena fedeltà alla Data Box. Al suo posto usare RoboCopy.

Quando il tuo Data Box arriva, ha condivisioni SMB pre-provisionate disponibili per ogni account di archiviazione che hai specificato al momento dell'ordine.

  • Se i tuoi file vengono archiviati in una condivisione file di Azure basata su SSD, è presente una condivisione SMB per ogni account di archiviazione SSD "File storage".
  • Se i tuoi file vengono archiviati in un account di archiviazione HDD, sono disponibili tre condivisioni SMB per ogni account di archiviazione HDD con pagamento in base al consumo. Solo la condivisione file che termina con _AzFile è rilevante per la tua migrazione. Ignorare condivisioni BLOB di pagine e blocchi.

Come Data Box mappa le cartelle alle condivisioni file di Azure

Nella condivisione del dispositivo <storage-account-name>_AzFile, ogni cartella di primo livello corrisponde a una condivisione file di Azure nell'account di archiviazione di destinazione:

  • Il nome della cartella di primo livello diventa il nome della condivisione file Azure durante l'ingestione. Se una condivisione con quel nome non esiste già nell'account di archiviazione target, Data Box la crea. Se esiste, Data Box copia i dati in quella condivisione esistente.

  • Non copiare i file direttamente nella directory principale della condivisione _AzFile. Tutti i dati devono essere inseriti in una cartella di primo livello.

  • Per una mappatura uno a uno con le tue condivisioni SMB sorgente, crea una cartella di primo livello per ogni condivisione sorgente (usando il nome desiderato della condivisione file Azure) e copia ogni condivisione sorgente nella corrispondente cartella. Per esempio:

    \\<DataBox-IP>\<storage-account-name>_AzFile\Share1
\\<DataBox-IP>\<storage-account-name>_AzFile\Share2
\\<DataBox-IP>\<storage-account-name>_AzFile\Share3

Per ulteriori informazioni, vedere Connettersi a Data Box.

Seguire i passaggi descritti nella documentazione di Azure Data Box:

  1. Connettersi a Data Box
  2. Copiare i dati nel Data Box
  3. Controlla il file di log di RoboCopy per eventuali errori e conferma che tutti i file siano stati copiati con successo.
  4. Prepara il tuo Data Box per la partenza verso Azure

La documentazione Data Box collegata specifica un comando RoboCopy. Tuttavia, il comando non è adatto a preservare la fedeltà completa di file e cartelle. Questo comando viene utilizzato /MT:32 perché è una copia LAN locale per la Data Box con latenza trascurabile, quindi qui è appropriato un numero di thread più alto rispetto alla copia WAN di recupero nella Fase 7:

Robocopy /MT:32 /NP /NFL /NDL /B /MIR /IT /COPY:DATSO /DCOPY:DAT /UNILOG:<FilePathAndName> <SourcePath> <Dest.Path>
  • Per altre informazioni sui singoli flag RoboCopy, vedere la tabella nella sezione RoboCopy di seguito.
  • Per altre informazioni su come ridimensionare in modo appropriato il conteggio dei thread /MT:n, ottimizzare la velocità di RoboCopy e fare in modo che RoboCopy sia un buon vicino nel data center, esaminare la sezione Risoluzione dei problemi di RoboCopy.

Suggerimento

Come alternativa a RoboCopy, Data Box offre un servizio di copia dati. È possibile usare questo servizio per caricare file in Data Box con piena fedeltà. Seguire questa esercitazione sul servizio di copia dei dati e assicurarsi di impostare la destinazione corretta della condivisione file di Azure.

Fase 7: Recupero di RoboCopy dal NAS

Dopo che il tuo Data Box segnala di aver inserito tutti i file e le cartelle nelle condivisioni Azure pianificate, continua con questa fase. È necessario eseguire una sincronizzazione con RoboCopy solo se i dati nel NAS potrebbero essere cambiati da quando è iniziata la copia con Data Box. In alcuni scenari in cui si usa una condivisione per scopi di archiviazione, è possibile arrestare le modifiche alla condivisione nel NAS fino al termine della migrazione. È anche possibile soddisfare i requisiti aziendali impostando condivisioni NAS in sola lettura durante la migrazione.

Nei casi in cui è necessario che una condivisione sia in lettura/scrittura durante la migrazione e che possa assorbire solo una piccola finestra di inattività, è importante completare questo passaggio di recupero di RoboCopy prima del failover dell'accesso utente direttamente alla condivisione file di Azure.

In questo passaggio, esegui i processi RoboCopy per sincronizzare le tue condivisioni cloud con le modifiche più recenti presenti nel NAS dal momento in cui hai copiato le tue condivisioni nel Data Box. Il recupero di RoboCopy può terminare rapidamente o richiedere qualche minuto a seconda della quantità di abbandono che si è verificata nelle condivisioni NAS.

Eseguire la prima copia locale nella cartella di destinazione del server Windows:

  1. Identificare la prima posizione nell'appliance NAS.
  2. Identificare la condivisione file di Azure corrispondente.
  3. Montare la condivisione file di Azure come unità di rete locale sul tuo server Windows temporaneo.
  4. Avviare la copia usando RoboCopy come descritto.

Montaggio di una condivisione di File di Azure

Prima di poter usare RoboCopy, è necessario rendere accessibile la condivisione file di Azure tramite SMB. Il modo più semplice consiste nel montare la condivisione come unità di rete locale nel server Windows che si prevede di usare per RoboCopy.

Importante

Prima di poter montare correttamente una condivisione file di Azure in un server Windows locale, è necessario completare la fase 5: Preparazione all'uso delle condivisioni file di Azure.

Quando sei pronto, consulta l'articolo guida Usare una condivisione file di Azure con Windows e monta la condivisione file di Azure per la quale vuoi avviare la sincronizzazione di recupero del NAS con RoboCopy.

RoboCopy

Il seguente comando RoboCopy copia solo le differenze (file e cartelle aggiornati) dallo storage NAS alla condivisione file Azure.

robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
Opzione Significato
/MT:n Consente l'esecuzione di Robocopy in multithreading. L'impostazione predefinita per n è 8. Il massimo è di 128 thread. Anche se un numero elevato di thread facilita la saturazione della larghezza di banda disponibile, non è detto che la migrazione sarà sempre più veloce con più thread. I test con File di Azure tra 8 e 20 dimostrano prestazioni bilanciate per l'esecuzione di una copia iniziale. Le esecuzioni successive di /MIR sono progressivamente influenzate dal rapporto tra calcolo disponibile e la larghezza di banda di rete disponibile. Per le esecuzioni successive, il valore del conteggio dei thread dovrà avvicinarsi al numero di core del processore e al conteggio dei thread per core. Valutare se i core devono essere riservati ad altre eventuali attività di un server di produzione. I test con File di Azure hanno dimostrato che fino a 64 thread producono prestazioni ottimali, ma solo se i processori possono mantenerli attivi contemporaneamente.
/R:n Numero massimo di nuovi tentativi per un file che non viene copiato al primo tentativo. Robocopy proverà n volte prima che il file non riesca a copiare definitivamente nell'esecuzione. È possibile ottimizzare le prestazioni dell'esecuzione: scegliere un valore pari a due o tre se si ritiene che i problemi di timeout abbiano causato errori in passato. Ciò può essere più comune rispetto ai collegamenti WAN. Scegliere nessun nuovo tentativo o un valore di uno se si ritiene che la copia del file non sia riuscita perché era attivamente in uso. Un nuovo tentativo dopo alcuni secondi potrebbe non essere sufficiente per lo stato in uso del file da modificare. Gli utenti o le app che contengono il file aperto potrebbero richiedere più ore. In questo caso, accettando che il file non è stato copiato e recuperandolo in una delle successive esecuzioni di Robocopy pianificate, la copia del file potrebbe avvenire correttamente. Ciò consente all'esecuzione corrente di terminare più velocemente senza ritardi dovuti a molti tentativi che alla fine finiscono nella maggior parte in errori di copia a causa di file ancora aperti oltre il timeout di ripetizione dei tentativi.
/W:n Specifica il tempo in cui Robocopy rimane in attesa prima di provare a ripetere un'operazione di copia di un file che ha avuto esito negativo in un tentativo precedente. n è il numero di secondi di attesa tra i tentativi. /W:n viene spesso usato insieme a /R:n.
/B Esegue Robocopy nella stessa modalità che verrebbe usata da un'applicazione di backup. Questa opzione consente a Robocopy di spostare i file per cui l'utente corrente non dispone delle autorizzazioni. L'opzione di backup dipende dall'esecuzione del comando di Robocopy in una console con privilegi elevati di amministratore o in una finestra di PowerShell. Se usi Robocopy per File di Azure, assicurati di montare la condivisione file Azure usando la chiave di accesso dell'account di archiviazione invece di un'identità di dominio. In caso contrario, i messaggi di errore potrebbero impedire una risoluzione del problema in modo intuitivo.
/MIR (Mirror da origine a destinazione.) Consente a Robocopy di copiare solo i delta tra origine e destinazione. Le sottodirectory vuote verranno copiate. Gli elementi (file o cartelle) modificati o non presenti nella destinazione verranno copiati. Gli elementi presenti nella destinazione ma non nell'origine verranno rimossi (eliminati) dalla destinazione. Quando si usa questa opzione, le strutture delle cartelle di origine e di destinazione devono essere identiche. Corrispondenza significa copiare dal livello corretto di origine e cartella al livello di cartella corrispondente nella destinazione. Solo a questo punto una copia "di recupero" può avere esito positivo. Quando l'origine e la destinazione non corrispondono, l'uso di /MIR porterà a eliminazioni e creazione di nuove copie su larga scala.
/IT Verifica che venga mantenuta la fedeltà in determinati scenari di mirror.
Ad esempio, se si verifica un cambiamento di ACL e un aggiornamento degli attributi in un file tra due esecuzioni di Robocopy, il file viene contrassegnato come nascosto. Senza /IT, Robocopy potrebbe non rilevare il cambiamento di ACL e la modifica potrebbe non essere trasferita alla posizione di destinazione.
/COPY:[copyflags] La fedeltà della copia del file. Impostazione predefinita: /COPY:DAT. Flag di copia: D= Dati, A= Attributi, T= Timestamp, S= Sicurezza = ACL NTFS, O= Informazioni sul proprietario, UA= Informazioni di controllo. Le informazioni di controllo non possono essere archiviate in una condivisione file di Azure.
/DCOPY:[copyflags] Fedeltà per la copia delle directory. Impostazione predefinita: /DCOPY:DA. Flag di copia: D= Dati, A= Attributi, T= Timestamp.
/NP Specifica che non verrà visualizzato l'avanzamento della copia per ogni file e cartella. La visualizzazione dell'avanzamento riduce notevolmente le prestazioni di copia.
/NFL Specifica che i nomi dei file non vengono registrati. Aumenta le prestazioni di copia.
/NDL Specifica che i nomi delle directory non vengono registrati. Aumenta le prestazioni di copia.
/XD Specifica le directory da escludere. Quando si esegue Robocopy nella radice di un volume, considerare l'esclusione della cartella System Volume Information nascosta. Se usato come progettato, tutte le informazioni contenute sono specifiche del volume esatto su questo sistema esatto e possono essere rigenerare su richiesta. Copiare queste informazioni non è utile nel cloud o quando i dati vengono nuovamente copiati su un altro volume Windows. Lasciare questi contenuti indietro non è perdita di dati.
/UNILOG:<file name> Scrive lo stato nel file di log come Unicode. (Sovrascrive il log esistente.)
/L Solo per un'esecuzione di test
I file devono essere solo elencati. Non verranno copiati o eliminati e non verranno applicati timestamp. Spesso viene usato con /TEE per l'output della console. Potrebbe essere necessario rimuovere i flag dello script di esempio, come /NP, /NFL e /NDL, per raggiungere i risultati del test documentati correttamente.
/Z Usare con cautela
Copia i file in modalità di riavvio. Questa operazione è consigliata solo in un ambiente di rete instabile. Riduce significativamente le prestazioni di copia a causa della registrazione aggiuntiva.
/ZB Usare con cautela
Usa la modalità di riavvio. Se viene negato l'accesso, questa opzione usa la modalità di backup. Questa opzione riduce significativamente le prestazioni di copia a causa del checkpoint.

Importante

Se possibile, usa Windows Server 2022 o versioni successive. Quando usi Windows Server 2019, assicurati che sia installato l'ultimo livello di patch o almeno il KB5005103 aggiornamento del sistema operativo. Contiene correzioni importanti per determinati scenari di Robocopy.

Suggerimento

Consultare la sezione Risoluzione dei problemi se RoboCopy influisce sull'ambiente di produzione, segnala un numero elevato di errori o non avanza velocemente come previsto.

Cutover utente

Quando si esegue il comando RoboCopy per la prima volta, gli utenti e le applicazioni stanno ancora accedendo ai file nel NAS e possono modificarli. È possibile che RoboCopy abbia elaborato una directory, passi alla successiva e che quindi un utente nel percorso di origine (NAS) aggiunga, modifichi o elimini un file che ora non verrà elaborato in questa esecuzione corrente di RoboCopy. Si tratta di un comportamento previsto.

La prima esecuzione consiste nello spostare il blocco dei dati inattivi nella condivisione file di Azure. La prima copia può richiedere un po' di tempo. Per altre informazioni su ciò che può influire sulle velocità di RoboCopy, consultare la sezione Risoluzione dei problemi.

Dopo che la prima esecuzione è completata, esegui di nuovo il comando.

La seconda volta che esegui RoboCopy per la stessa condivisione, termina più rapidamente, perché deve copiare solo le modifiche avvenute dall'ultima esecuzione. È possibile eseguire processi ripetuti per la stessa condivisione.

Quando si considera il tempo di inattività accettabile, è necessario rimuovere l'accesso utente alle condivisioni basate su NAS. A tale scopo, è possibile eseguire qualsiasi procedura che impedisca agli utenti di modificare la struttura e il contenuto di file e cartelle. Un esempio consiste nel puntare DFS-Namespace a una posizione non esistente o modificare gli ACL radice nella condivisione.

Eseguire un ultimo round di RoboCopy. Rileva eventuali cambiamenti che potrebbero essere stati trascurati. Il tempo necessario per questo passaggio finale dipende dalla velocità dell'analisi RoboCopy. È possibile stimare il tempo (uguale al tempo di inattività) misurando la durata dell'esecuzione precedente.

Creare una condivisione nella cartella del server Windows ed eventualmente modificare la distribuzione DFS-N in modo che punti a essa. Assicurarsi di impostare le stesse autorizzazioni a livello di condivisione della condivisione NAS SMB. Se si dispone di un NAS aggiunto a un dominio di classe aziendale, i SID utente corrisponderanno automaticamente, poiché gli utenti esistono in Active Directory e RoboCopy copia i file e i metadati a piena fedeltà. Se sono stati usati utenti locali nel NAS, è necessario ricreare questi utenti come utenti locali del server Windows ed eseguire il mapping dei SID esistenti che RoboCopy ha spostato nel server Windows ai SID dei nuovi utenti locali del server Windows.

È stata completata la migrazione di una condivisione o di un gruppo di condivisioni in un volume o una radice comune.

È possibile provare a eseguire alcune di queste copie in parallelo. Elabora l'ambito di una condivisione file Azure alla volta.

Risolvere problemi

La velocità e il tasso di successo di una run su RoboCopy dipendono da diversi fattori:

  • Operazioni di I/O al secondo nell'archiviazione di origine e di destinazione
  • Larghezza di banda di rete disponibile tra origine e destinazione;
  • Possibilità di elaborare rapidamente file e cartelle in uno spazio dei nomi;
  • Numero di modifiche tra le esecuzioni di RoboCopy;
  • Dimensioni e numero di file che è necessario copiare;

Considerazioni su operazioni di I/O al secondo e larghezza di banda

In questa categoria è necessario prendere in considerazione le capacità dell'archiviazione di origine, l'archiviazione di destinazione e la rete che le connette. La velocità effettiva massima possibile è determinata dal più lento di questi tre componenti. Assicurarsi che l'infrastruttura di rete sia configurata per supportare velocità di trasferimento ottimali alle migliori capacità.

Attenzione

Mentre la copia il più veloce possibile è spesso preferibile, prendere in considerazione l'utilizzo della rete locale e dell'appliance NAS per altre attività, spesso critiche per l'azienda.

La copia più veloce possibile potrebbe non essere auspicabile quando esiste un rischio che la migrazione possa monopolizzare le risorse disponibili.

  • Valutare quando è preferibile nell'ambiente eseguire le migrazioni: durante il giorno, negli orari di minore attività o durante i fine settimana.
  • Prendere in considerazione anche QoS di rete in Windows Server per limitare la velocità di RoboCopy.
  • Evitare operazioni non necessarie per gli strumenti di migrazione.

RoboCopy può inserire ritardi tra pacchetti specificando l'opzione /IPG:n in cui n viene misurata in millisecondi tra i pacchetti RoboCopy. L'uso di questo interruttore può aiutare a evitare la monopolizzazione delle risorse sia sui dispositivi vincolati di I/O sia sui collegamenti di rete affollati.

/IPG:n non può essere usato per una limitazione di rete precisa a un determinato Mbps. Usare invece QoS di rete di Windows Server. RoboCopy si basa interamente sul protocollo SMB per tutte le esigenze di rete. L'uso di SMB è il motivo per cui RoboCopy non può influenzare la velocità effettiva di rete stessa, ma può rallentarne l'uso.

Una linea di pensiero simile si applica alle operazioni di I/O al secondo osservate sul NAS. Le dimensioni del cluster nel volume NAS, le dimensioni dei pacchetti e una matrice di altri fattori influenzano le operazioni di I/O al secondo osservate. L'introduzione del ritardo tra pacchetti è spesso il modo più semplice per controllare il carico sul NAS. Testare valori multipli, ad esempio da circa 20 millisecondi (n=20) fino a multipli di quel numero. Dopo aver introdotto un ritardo, puoi valutare se le tue altre app ora funzionano come previsto. Questa strategia di ottimizzazione ti aiuta a trovare la velocità ottimale di RoboCopy nel tuo ambiente.

Velocità di elaborazione

RoboCopy attraversa lo spazio dei nomi che specifichi e valuta ogni file e cartella per la copia. Valuta ogni file durante una copia iniziale e durante le copie di recupero. Ad esempio, esecuzioni ripetute di RoboCopy /MIR rispetto alle stesse posizioni di archiviazione di origine e di destinazione. Queste esecuzioni ripetute minimizzano i tempi di inattività per utenti e app e migliorano il tasso di successo complessivo dei file migrati.

La larghezza di banda è spesso considerata il fattore più limitante in una migrazione, e questo può essere vero. Tuttavia, la possibilità di enumerare uno spazio dei nomi può influenzare il tempo totale per copiare ancora di più per spazi dei nomi più grandi con file più piccoli. Considera che copiare 1 TiB di file piccoli richiede molto più tempo che copiare 1 TiB di file meno ma più grandi, assumendo che tutte le altre variabili rimangano le stesse. Pertanto, è possibile che si verifichi un trasferimento lento se si esegue la migrazione di un numero elevato di file di piccole dimensioni. Questa differenza è prevista.

La causa di questa differenza è la potenza di elaborazione necessaria per esaminare uno spazio dei nomi. RoboCopy supporta copie multithread tramite il parametro /MT:n in cui n indica il numero di thread da usare. Pertanto, quando si effettua il provisioning di un computer in particolare per RoboCopy, prendere in considerazione il numero di core del processore e la relazione con il numero di thread fornito. Nella maggior parte dei casi è di due thread per core. Il numero di core e thread di un computer è un punto dati importante per decidere quali valori multithread /MT:n è necessario specificare. Considerare anche il numero di processi RoboCopy che si prevede di eseguire in parallelo in un determinato computer.

Un numero maggiore di thread copia l'esempio da 1 TiB composto da file di piccole dimensioni considerevolmente più velocemente rispetto a un numero inferiore di thread. Allo stesso tempo, l'investimento extra di risorse sull'1 TiB dei file più grandi potrebbe non portare benefici proporzionali. Un alto numero di thread tenta di copiare contemporaneamente più file grandi sulla rete. Questa attività di rete aggiuntiva aumenta la probabilità di essere vincolati dalla velocità effettiva o dalle operazioni di I/O al secondo di archiviazione.

Durante un primo RoboCopy in una destinazione vuota o in un'esecuzione differenziale con molti file modificati, è probabile che la velocità effettiva della rete sia vincolata. Iniziare con un conteggio elevato dei thread per un'esecuzione iniziale. Un numero elevato di thread, anche oltre i thread attualmente disponibili nel computer, consente di saturare la larghezza di banda di rete disponibile. Le esecuzioni /MIR successive influiscono progressivamente sull'elaborazione degli elementi. Meno modifiche in un'esecuzione differenziale significano meno trasporto di dati in rete. La velocità dipende ora dalla capacità di elaborare gli elementi dello spazio dei nomi piuttosto che spostarli tramite il collegamento di rete. Per le esecuzioni successive, il valore del conteggio dei thread deve corrispondere al numero di core del processore e al conteggio dei thread per core. Valutare se i core devono essere riservati ad altre eventuali attività di un server di produzione.

Suggerimento

Regola generale: la prima esecuzione di RoboCopy, che sposterà molti dati di una rete a latenza più elevata, trae vantaggio dal provisioning eccessivo del numero di thread (/MT:n). Le esecuzioni successive copiano meno differenze e probabilmente si passa dalla velocità effettiva di rete vincolata ai vincoli di calcolo. In queste circostanze, è spesso preferibile associare il conteggio dei thread RoboCopy ai thread effettivamente disponibili nel computer. Il provisioning eccessivo in questo scenario può portare a un maggior numero di cambiamenti di contesto nel processore, probabilmente rallentando la copia.

Evitare operazioni non necessarie

Evitare modifiche su larga scala nello spazio dei nomi. Ad esempio, lo spostamento di file tra directory, la modifica delle proprietà su larga scala o la modifica delle autorizzazioni (ACL NTFS). In particolare le modifiche ACL possono avere un impatto elevato perché spesso hanno un effetto di modifica a catena sui file inferiori nella gerarchia di cartelle. Le conseguenze possono essere le seguenti:

  • il tempo di esecuzione del processo RoboCopy potrebbe risultare esteso perché ogni file e cartella interessato da una modifica ACL deve essere aggiornato
  • I dati spostati in precedenza potrebbero dover essere copiati nuovamente. Ad esempio, è necessario copiare più dati quando le strutture delle cartelle cambiano dopo che i file sono già stati copiati. Un processo RoboCopy non può "riprodurre" una modifica dello spazio dei nomi. Il processo successivo deve eliminare i file precedentemente trasportati nella struttura di cartelle precedente e caricare nuovamente i file nella nuova struttura di cartelle.

Un altro aspetto importante consiste nell'usare lo strumento RoboCopy in modo efficace. Utilizzando lo script RoboCopy consigliato, crei e salvi un file di log per gli errori. Gli errori di copia possono verificarsi ed è normale. Questi errori spesso rendono necessario eseguire più round di uno strumento di copia come RoboCopy. Ad esempio, una prima esecuzione, ad esempio da un NAS a Data Box o da un server a una condivisione file Azure, e una o più esecuzioni extra con lo /MIR switch per catturare e riprovare file che non sono stati copiati.

Preparati a eseguire più round di RoboCopy su un determinato ambito di namespace. Le esecuzioni successive terminano più velocemente perché hanno meno da copiare, ma sono sempre più vincolate dalla velocità di elaborazione dello spazio dei nomi. Quando si eseguono più round, è possibile velocizzare ogni round impedendo a RoboCopy di copiare inutilmente tutto in una determinata esecuzione. Questi commutatori RoboCopy possono fare una differenza significativa:

  • /R:n n = frequenza con cui si riprova a copiare un file non riuscito e
  • /W:n n = numero di secondi di attesa tra i tentativi

/R:5 /W:5 è un'impostazione ragionevole che è possibile regolare in base alle proprie esigenze. In questo esempio, la copia di un file non riuscita verrà ritentata cinque volte, con un tempo di attesa di cinque secondi tra i tentativi. Se la copia del file non riesce ancora, il processo RoboCopy successivo riproverà. Spesso, i file che non sono stati copiati perché sono in uso o perché ci sono problemi di timeout possono essere copiati correttamente in questo modo.

Vedere anche

  • Last updated on