Usare RoboCopy per eseguire la migrazione alle condivisioni file di Azure

  • Articolo

Questo articolo sulla migrazione descrive l'uso di RoboCopy per spostare o migrare file in una condivisione file di Azure SMB. RoboCopy è un'utilità di copia file attendibile e nota con un set di funzionalità che lo rende adatto per le migrazioni. Usa il protocollo SMB, che lo rende ampiamente applicabile a qualsiasi combinazione di origine e destinazione che supporta SMB.

  • Origini dati: qualsiasi origine che supporta il protocollo SMB, ad esempio network attached Archiviazione (NAS), server Windows o Linux, un'altra condivisione file di Azure e molti altri
  • Route di migrazione: dall'archiviazione di origine ⇒ computer Windows con RoboCopy ⇒ condivisione file di Azure
  • 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.

Esistono molte route di migrazione diverse per diverse combinazioni di origine e distribuzione. Vedere la tabella delle guide alla migrazione per trovare la migrazione più adatta alle proprie esigenze.

Si applica a

Tipo di condivisione file SMB NFS
Condivisioni file Standard (GPv2), archiviazione con ridondanza locale/archiviazione con ridondanza della zona Sì No
Condivisioni file Standard (GPv2), archiviazione con ridondanza geografica/archiviazione con ridondanza geografica della zona Sì No
Condivisioni file Premium (FileStorage), archiviazione con ridondanza locale/archiviazione con ridondanza della zona Sì No

AzCopy e RoboCopy

AzCopy e RoboCopy sono due strumenti di copia file fondamentalmente diversi. RoboCopy usa qualsiasi versione del protocollo SMB. AzCopy è uno strumento "born-in-the-cloud" che può essere usato per spostare i dati purché la destinazione si trova nell'archiviazione di Azure. AzCopy dipende da un protocollo REST.

RoboCopy, come strumento di copia affidabile basato su Windows, ha il vantaggio home-turf quando si tratta di copiare i file a piena fedeltà. RoboCopy supporta molti scenari di migrazione grazie al suo ricco set di funzionalità e alla possibilità di copiare file e cartelle in piena fedeltà. Per altre informazioni sull'importanza della copia dei file al massimo possibile, vedere la sezione relativa alla fedeltà dei file nell'articolo di panoramica della migrazione.

AzCopy, d'altra parte, è stato espanso solo di recente per supportare la copia di file con una certa fedeltà e ha aggiunto le prime funzionalità necessarie per essere considerate come uno strumento di migrazione. Tuttavia, esistono ancora lacune e possono verificarsi facilmente errori di funzionalità durante il confronto dei flag AzCopy con i flag RoboCopy.

Un esempio: RoboCopy /MIR eseguirà il mirroring dell'origine nella destinazione. Ciò significa che vengono considerati i file aggiunti, modificati ed eliminati. Una differenza importante nell'uso di AzCopy -sync è che i file eliminati nell'origine non vengono rimossi nella destinazione. Ciò rende disponibile un set di funzionalità di copia differenziale incompleto. AzCopy continuerà a evolversi. Al momento, non è consigliabile usare AzCopy per gli scenari di migrazione con condivisioni file di Azure come destinazione.

Obiettivi della migrazione

L'obiettivo è spostare i dati da percorsi di condivisione file esistenti ad Azure. In Azure si archivieranno i dati in condivisioni file di Azure native che è possibile usare senza la necessità di windows Server. Questa migrazione deve essere eseguita in modo da garantire l'integrità dei dati di produzione e della disponibilità durante la migrazione. Quest'ultimo richiede un tempo di inattività minimo, in modo che possa rientrare o superare leggermente le normali finestre di manutenzione.

Panoramica della migrazione

Il processo di migrazione è costituito da diverse fasi. Prima di tutto, è necessario distribuire gli account di archiviazione di Azure e le condivisioni file. Successivamente, si configurerà la rete, si consideri una distribuzione dello spazio dei nomi DFS (DFS-N) o si aggiornerà quella esistente. Quando è il momento della copia dei dati effettiva, è necessario prendere in considerazione le esecuzioni ripetute e differenziali di RoboCopy per ridurre al minimo i tempi di inattività e infine tagliare gli utenti alle nuove condivisioni file di Azure create. Le sezioni seguenti descrivono in dettaglio le fasi del processo di migrazione.

Fase 1: Distribuire le risorse di archiviazione di Azure

In questa fase si eseguirà il provisioning degli account di archiviazione di Azure e delle condivisioni file di Azure SMB all'interno di essi.

Tenere presente che una condivisione file di Azure viene distribuita nel cloud in un account di archiviazione di Azure. Per le condivisioni file standard, questa disposizione rende l'account di archiviazione una destinazione di scalabilità per i numeri di prestazioni come IOPS e velocità effettiva. Se si inseriscono più condivisioni file in un singolo account di archiviazione, si sta creando 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 si hanno condivisioni molto attive (condivisioni usate da molti utenti e/o applicazioni), è consigliabile distribuire gli account di archiviazione con una condivisione file ciascuno. Queste limitazioni non si applicano agli account di archiviazione File Archiviazione (Premium), in cui le prestazioni vengono sottoposte a provisioning esplicito e garantite per ogni condivisione.

Nota

È previsto un limite di 250 account di archiviazione per ogni sottoscrizione per ogni area di Azure. Con un aumento della 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 è la ridondanza. Vedere ridondanza File di Azure.

Le condivisioni file di Azure standard vengono create con un limite di 5 TiB per impostazione predefinita. Se è necessaria una capacità maggiore, è possibile creare una condivisione file di grandi dimensioni (fino a 100 TiB). Tuttavia, tale condivisione può usare solo opzioni di ridondanza dell'archiviazione con ridondanza della zona o archiviazione con ridondanza della zona. Prendere in considerazione le esigenze di ridondanza dell'archiviazione prima di usare 100 condivisioni file TiB.

Se è stato creato un elenco delle condivisioni, è necessario eseguire il mapping di ogni condivisione all'account di archiviazione in cui verrà creato.

Anche i nomi delle risorse sono importanti. Ad esempio, se si raggruppano più condivisioni per il reparto risorse umane in un account di archiviazione di Azure, è necessario assegnare un nome appropriato all'account di archiviazione. Analogamente, quando si assegna un nome alle condivisioni file di Azure, è consigliabile usare nomi simili a quelli usati per le controparti locali.

Distribuire ora il numero appropriato di account di archiviazione di Azure con il numero appropriato di condivisioni file di Azure, seguendo le istruzioni riportate in Creare una condivisione file SMB. Nella maggior parte dei casi, è necessario assicurarsi che l'area di ogni account di archiviazione sia la stessa.

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

Con le informazioni in questa fase, sarà possibile decidere in che modo i server e gli utenti in Azure e all'esterno di Azure saranno abilitati per usare le condivisioni file di 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. L'uso dell'autenticazione basata su identità e dell'aggiunta al dominio dell'account di archiviazione consentirà alle app e agli utenti di usare l'identità di Ad per l'autenticazione.
  • Autorizzazione: gli ACL a livello di condivisione per ogni condivisione file di Azure consentirà a utenti e gruppi di AD di accedere a una determinata condivisione e all'interno di una condivisione file di Azure, gli ACL NTFS nativi assumeranno il controllo. L'autorizzazione basata su ACL di file e cartelle funziona come per le condivisioni SMB locali.
  • Continuità aziendale: l'integrazione di condivisioni file di Azure in un ambiente esistente comporta spesso la conservazione degli indirizzi di condivisione esistenti. Se non si usano già spazi dei nomi DFS, è consigliabile stabilire che nell'ambiente in uso. Sarà possibile mantenere gli indirizzi di condivisione usati dagli utenti e dagli script, senza modifiche. DFS-N fornisce un servizio di routing dello spazio dei nomi per SMB reindirizzando i client alle condivisioni file di Azure.

Questo video è una guida e una demo per 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. Si noti che Azure Active Directory è ora Microsoft Entra ID. Per altre informazioni, vedere Nuovo nome per Azure AD.

Montaggio di una condivisione 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 in Windows Server che si prevede di usare per RoboCopy.

Importante

Assicurarsi di montare la condivisione file di Azure usando la chiave di accesso dell'account di archiviazione. Non usare un'identità di dominio. Prima di poter montare correttamente una condivisione file di Azure in un server Windows locale, è necessario aver completato la fase 2: Preparazione all'uso delle condivisioni file di Azure.

Una volta pronti, vedere Usare una condivisione file di Azure con Windows. Montare quindi la condivisione file di Azure per cui si vuole avviare RoboCopy.

Fase 3: RoboCopy

Il comando RoboCopy seguente copia solo le differenze (file e cartelle aggiornati) dall'archiviazione di origine alla condivisione file di 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>
Commutatore Significato
/MT:n Consente l'esecuzione di Robocopy in multithreading. Il valore predefinito per n è 8. Il massimo è di 128 thread. Anche se un numero elevato di thread consente di saturare la larghezza di banda disponibile, non significa che la migrazione sarà sempre più veloce con più thread. I test con File di Azure indicano tra 8 e 20 prestazioni bilanciate per un'esecuzione di copia iniziale. Le esecuzioni successive /MIR sono progressivamente interessate dal calcolo disponibile rispetto alla 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 in modo permanente 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. Questo può essere più comune rispetto ai collegamenti WAN. Scegliere nessun nuovo tentativo o un valore di uno se si ritiene che il file non sia riuscito a copiare perché era attivamente in uso. Il tentativo di nuovo alcuni secondi dopo 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 ore più tempo. In questo caso, accettare il file non è stato copiato e intercettarlo in una delle esecuzioni di Robocopy pianificate, potrebbe riuscire a copiare correttamente il file. Ciò consente all'esecuzione corrente di terminare più velocemente senza essere prolungati da molti tentativi che alla fine finiscono nella maggior parte degli 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 Robocopy in una console con privilegi elevati di amministratore o in una finestra di PowerShell. Se si usa Robocopy per File di Azure, assicurarsi di montare la condivisione file di Azure usando la chiave di accesso dell'account di archiviazione e un'identità di dominio. In caso contrario, i messaggi di errore potrebbero non causare 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. La corrispondenza significa copiare dal livello di origine e cartella corretto 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 /MIR porterà a eliminazioni e ripozioni su larga scala.
/IT Verifica che venga mantenuta la fedeltà in determinati scenari di mirror.
Ad esempio, se un file riscontra una modifica ACL e un aggiornamento dell'attributo tra due esecuzioni robocopy, viene contrassegnato come nascosto. Senza /IT, la modifica dell'elenco di controllo di accesso potrebbe non essere stata rilevata da Robocopy e non trasferita nella posizione di destinazione.
/COPY:[copyflags] La fedeltà della copia del file. Impostazione predefinita: /COPY:DAT. Flag di copia: D= Data, A= Attributes, T= Timestamps, S= Security = NTFS ACL, O= Owner information, U= Auditing information. 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, prendere in considerazione l'esclusione della cartella nascosta System Volume Information . Se usato come progettato, tutte le informazioni contenute in sono specifiche del volume esatto su questo sistema esatto e possono essere ricompilate su richiesta. La copia di queste informazioni non sarà utile nel cloud o quando i dati vengono copiati in un altro volume di Windows. Lasciare il contenuto in ritardo non deve essere considerato perdita di dati.
/UNILOG:<file name> Scrive lo stato nel file di log come Unicode. Sovrascrive il log esistente.
/L Solo per i file di esecuzione
di test devono essere elencati solo. Non verranno copiati o eliminati e non verranno applicati timestamp. Spesso usato con /TEE per l'output della console. I flag dello script di esempio, ad esempio /NP, /NFLe /NDL, potrebbero dover essere rimossi per ottenere risultati di test documentati correttamente.
/Z Usare copia con cautela
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 Usa con cautela
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

È consigliabile usare Windows Server 2022. Quando si usa Un Windows Server 2019, assicurarsi che sia installato al livello di patch più recente o almeno l'aggiornamento del sistema operativo KB5005103 . Contiene correzioni importanti per determinati scenari Robocopy.

Suggerimento

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

Fase 4: Taglio utente

Quando si esegue il comando RoboCopy per la prima volta, gli utenti e le applicazioni accedono ancora ai file nell'origine della migrazione e possono essere modificati. È possibile che RoboCopy abbia elaborato una directory, spostata alla successiva, quindi un utente nel percorso di origine aggiunge, modifica o elimina 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 la maggior parte dei dati in blocchi 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, vedere la sezione Risoluzione dei problemi.

Al termine dell'esecuzione iniziale, eseguire di nuovo il comando.

La seconda volta che si esegue RoboCopy per la stessa condivisione, verrà completata più velocemente, perché deve solo trasportare le modifiche apportate dopo l'ultima esecuzione. È possibile eseguire processi ripetuti per la stessa condivisione.

Dopo aver considerato la quantità di tempo di inattività accettabile, è necessario rimuovere l'accesso utente alle condivisioni di origine. 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 in ogni condivisione.

Eseguire un ultimo round RoboCopy. Raccoglierà eventuali modifiche che potrebbero essere state perse. 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.

Nella fase 2, gli utenti sono stati configurati per accedere alla condivisione con la propria identità e devono aver stabilito una strategia per consentire agli utenti di usare percorsi stabiliti per le nuove condivisioni file di Azure (DFS-N).

È possibile provare a eseguire alcune di queste copie tra diverse condivisioni di origine e di destinazione in parallelo. In questo caso, tenere presente che la velocità effettiva di rete e il numero di core al numero di thread non superano il sovraccarico del sistema.

Risoluzione di problemi e ottimizzazione

La velocità e la frequenza di successo di una determinata esecuzione RoboCopy dipenderanno 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
  • le dimensioni e il numero di file che è necessario copiare

Considerazioni sulle operazioni di I/O al secondo e sulla larghezza di banda

In questa categoria è necessario prendere in considerazione le capacità dell'archiviazione di origine, dell'archiviazione di destinazione e della rete che le connettono. 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 più desiderabile, prendere in considerazione l'utilizzo della rete locale e dell'appliance NAS per altre attività, spesso critiche per l'azienda.

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

  • Prendere in considerazione quando è preferibile nell'ambiente eseguire le migrazioni: durante il giorno, gli orari di minore attività o durante i fine settimana.
  • Prendere in considerazione anche QoS di rete in un 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 commutatore consente di evitare il monopolio delle risorse su dispositivi vincolati di I/O e 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 più valori, ad esempio da circa 20 millisecondi (n=20) a multipli di tale numero. Dopo aver introdotto un ritardo, è possibile valutare se le altre app possono ora funzionare come previsto. Questa strategia di ottimizzazione consentirà di trovare la velocità ottimale di RoboCopy nell'ambiente in uso.

Velocità di elaborazione

RoboCopy attraverserà lo spazio dei nomi a cui punta e valuterà ogni file e cartella per la copia. Ogni file verrà valutato durante una copia iniziale e durante le copie di recupero. Ad esempio, esecuzioni ripetute di RoboCopy /MIR nelle stesse posizioni di archiviazione di origine e di destinazione. Queste esecuzioni ripetute sono utili per ridurre al minimo i tempi di inattività per utenti e app e migliorare la percentuale complessiva di successo dei file migrati.

Spesso si considera la larghezza di banda come fattore più limitante in una migrazione e ciò 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. Si consideri che la copia di 1 TiB di file di piccole dimensioni richiederà molto più tempo rispetto alla copia di 1 TiB di file meno grandi, presupponendo che tutte le altre variabili rimangano invariate. Pertanto, è possibile che si verifichi un trasferimento lento se si esegue la migrazione di un numero elevato di file di piccole dimensioni. Si tratta di un comportamento previsto.

La causa di questa differenza è la potenza di elaborazione necessaria per esaminare uno spazio dei nomi. RoboCopy supporta copie multithread tramite il /MT:n parametro dove 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. La maggior parte dei casi è due thread per core. Il numero di core e thread di un computer è un punto dati importante per decidere quali valori /MT:n multithread è necessario specificare. Considerare anche il numero di processi RoboCopy che si prevede di eseguire in parallelo in un determinato computer.

Più thread copieranno il nostro esempio TiB 1 di file di piccole dimensioni notevolmente più veloce rispetto a un numero inferiore di thread. Allo stesso tempo, l'investimento di risorse aggiuntive sui nostri 1 TiB di file più grandi potrebbe non produrre benefici proporzionali. Un numero elevato di thread tenterà di copiare più file di grandi dimensioni in rete contemporaneamente. Questa attività di rete aggiuntiva aumenta la probabilità di ottenere 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, associare il valore del numero di thread al numero di core del processore e al numero di thread per core. Valutare se i core devono essere riservati per altre attività che un server di produzione potrebbe avere.

Suggerimento

Regola generale: la prima esecuzione di RoboCopy (che sposterà molti dati di una rete a latenza più elevata) trae vantaggio dall'over-provisioning 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 di proprietà su larga scala o la modifica delle autorizzazioni a livello di file e directory (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:

  • tempo di esecuzione del processo RoboCopy esteso perché ogni file e cartella interessato da una modifica ACL deve essere aggiornato
  • potrebbe essere necessario copiare nuovamente i dati spostati in precedenza. Ad esempio, sarà necessario copiare più dati quando le strutture delle cartelle cambiano dopo la copia dei file già copiati in precedenza. 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. Con lo script RoboCopy consigliato, si creerà e si salverà un file di log per gli errori. Gli errori di copia possono verificarsi: è normale. Questi errori spesso rendono necessario eseguire più round di uno strumento di copia come RoboCopy: un'esecuzione iniziale, ad esempio da un NAS a DataBox o da un server a una condivisione file di Azure e una o più esecuzioni aggiuntive con l'opzione /MIR per intercettare e riprovare i file che non sono stati copiati.

È consigliabile prepararsi a eseguire più round di RoboCopy in base a un determinato ambito dello spazio dei nomi. Le esecuzioni successive verranno completate più velocemente perché hanno meno da copiare, ma sono vincolate sempre più dalla velocità di elaborazione dello spazio dei nomi. Quando si eseguono più round, è possibile velocizzare ogni round non avendo RoboCopy provare in modo non ragionevole per copiare 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 tentativi

/R:5 /W:5 è un'impostazione ragionevole che è possibile regolare in base alle proprie esigenze. In questo esempio, un file non riuscito verrà ritentato cinque volte, con un tempo di attesa di cinque secondi tra i tentativi. Se il file non riesce ancora a eseguire la copia, il processo RoboCopy successivo verrà riprovato. Spesso i file non riusciti perché sono in uso o a causa di problemi di timeout potrebbero essere copiati correttamente in questo modo.

Stima degli addebiti delle transazioni di archiviazione

Quando si inizia la migrazione a File di Azure, RoboCopy copia i file e le cartelle in Azure. A seconda del modello di fatturazione per File di Azure, potrebbero essere applicati addebiti per le transazioni. Vedere Informazioni sulla fatturazione.

Se si usa un modello di fatturazione con pagamento in base al consumo per le condivisioni file standard di Azure, potrebbe essere difficile stimare il numero di transazioni generate dalla migrazione.

  • Non è possibile stimare il numero di transazioni in base alla capacità di archiviazione utilizzata dell'origine. Il numero di transazioni viene ridimensionato con il numero di elementi dello spazio dei nomi (file e cartelle) e le relative proprietà di cui viene eseguita la migrazione, non le relative dimensioni. Ad esempio, sono necessarie più transazioni per eseguire la migrazione di 1 GiB di file di piccole dimensioni rispetto a 1 GiB di file di dimensioni maggiori.
  • Per ridurre al minimo i tempi di inattività, potrebbe essere necessario eseguire più volte operazioni di copia dall'origine alla destinazione. Tutti gli elementi di origine e di destinazione vengono elaborati durante ogni operazione di copia, anche se le esecuzioni successive terminano più velocemente. Dopo le operazioni iniziali, solo le differenze introdotte tra le esecuzioni di copia vengono trasportate in rete. È importante comprendere che, anche se viene trasportato meno dati, il numero di transazioni necessarie potrebbe rimanere invariato.
  • La copia dello stesso file due volte potrebbe non comportare lo stesso numero di transazioni. L'elaborazione di un elemento migrato in un'esecuzione di copia precedente potrebbe comportare solo poche transazioni di lettura. Al contrario, le modifiche apportate ai metadati o al contenuto tra le esecuzioni di copia potrebbero richiedere un numero maggiore di transazioni per aggiornare la destinazione. Ogni file nello spazio dei nomi potrebbe avere requisiti univoci, con conseguente numero diverso di transazioni.

È consigliabile eseguire alcuni test iniziali sui propri dati per comprendere meglio il numero di transazioni sostenute. In questo modo si avrà un'idea migliore del numero totale di transazioni che potrebbe essere generata da una migrazione di file.

Passaggi successivi

Gli articoli seguenti consentono di comprendere le opzioni avanzate e le procedure consigliate.