Condividi tramite

Usare DataBox per eseguire la migrazione da nas (Network Attached Archiviazione) alle condivisioni file di Azure

  • Articolo

Questo articolo sulla migrazione è uno dei diversi elementi che coinvolgono le parole chiave NAS e Azure DataBox. Controllare se questo articolo si applica allo scenario:

  • Origine dati: network attached Archiviazione (NAS)
  • Route di migrazione: NAS ⇒ DataBox ⇒ 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.

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

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 usa Azure DataBox per il trasporto di dati in blocco (trasporto dati offline).

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

Obiettivi della migrazione

L'obiettivo è spostare le condivisioni nell'appliance NAS in Azure e renderle condivisioni file native di Azure. È possibile usare condivisioni file native di Azure 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. Sarà necessario distribuire gli account di archiviazione di Azure e le condivisioni file e configurare la rete. Si eseguirà quindi la migrazione dei file usando Azure DataBox e RoboCopy per recuperare le modifiche. Infine, si eseguirà 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 si è interrotto.

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

In questo passaggio si determinerà il numero di condivisioni file di Azure necessarie. 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 file di cui si vuole eseguire la migrazione al cloud, è possibile scegliere di usare un mapping 1:1 o un raggruppamento di condivisioni.

Usare un mapping 1:1

Se si dispone di un numero sufficiente di condivisioni, è consigliabile eseguire un mapping 1:1. Il modo più semplice per eseguire l'immagine di questo scenario consiste nell'immaginare una condivisione locale che esegue il mapping di 1:1 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, è consigliabile archiviare 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 si eseguirà il provisioning degli account di archiviazione di Azure e delle condivisioni file 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.

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 3: Determinare il numero di appliance Azure DataBox necessarie

Avviare questo passaggio solo dopo aver completato la fase precedente. Le risorse di archiviazione di Azure (account di archiviazione e condivisioni file) devono essere create al momento. Durante l'ordine di DataBox, è necessario specificare in quali account di archiviazione il DataBox sta spostando i dati.

In questa fase è necessario eseguire il mapping dei risultati del piano di migrazione dalla fase precedente ai limiti delle opzioni di DataBox disponibili. Queste considerazioni consentono di creare un piano per le opzioni di DataBox che è necessario scegliere e quanti di essi sarà necessario spostare le condivisioni NAS in condivisioni file di Azure.

Per determinare il numero di dispositivi di cui si ha bisogno, considerare questi limiti importanti:

  • Qualsiasi azure DataBox può spostare i dati in un massimo di 10 account di archiviazione.
  • Ogni opzione DataBox ha la propria capacità utilizzabile. Vedere Opzioni di DataBox.

Consultare il piano di migrazione per il numero di account di archiviazione che si è deciso di creare e le condivisioni in ognuna di esse. Esaminare quindi le dimensioni di ognuna delle condivisioni nel NAS. La combinazione di queste informazioni consentirà di ottimizzare e decidere quale appliance deve inviare dati agli account di archiviazione. È possibile avere due dispositivi DataBox spostare i file nello stesso account di archiviazione, ma non suddividere il contenuto di una singola condivisione file in 2 DataBoxes.

Opzioni di DataBox

Per una migrazione standard, è necessario scegliere una o una combinazione di queste due opzioni di DataBox:

  • DataBox Questa è l'opzione più comune. Un'appliance DataBox resistente, che funziona in modo simile a un NAS, verrà spedita all'utente. Ha una capacità utilizzabile di 80 TiB. Per altre informazioni, vedere la documentazione di DataBox.
  • DataBox Heavy Questa opzione include un'appliance DataBox resistente sulle ruote, che funziona in modo simile a un NAS, con una capacità di 1 PiB. La capacità utilizzabile è di circa il 20% inferiore, a causa del sovraccarico della crittografia e del file system. Per altre informazioni, vedere la documentazione di DataBox 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 si attende l'arrivo di Azure DataBox(es), è già possibile distribuire uno o più server Windows necessari per l'esecuzione di processi RoboCopy.

  • Il primo uso di questi server consiste nel copiare i file in DataBox.
  • Il secondo uso di questi server sarà quello di recuperare le modifiche che si sono verificate nell'appliance NAS mentre DataBox era in trasporto. Questo approccio mantiene al minimo il tempo di inattività sul lato di origine.

La velocità di funzionamento dei processi RoboCopy dipende principalmente da questi fattori:

È importante tenere presenti i dettagli a cui si fa riferimento quando si decide la RAM e il numero di thread che verranno forniti ai server Windows temporanei.

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

Per risparmiare tempo, è necessario procedere con questa fase mentre si attende l'arrivo di DataBox. 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. Ad Connessione e Dominio che unisce l'account di archiviazione consentirà alle app e agli utenti di usare l'identità di Active Directory 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 delle 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. È possibile mantenere gli indirizzi di condivisione usati dagli utenti e dagli script, senza modifiche. È 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 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.

Fase 6: Copiare file in DataBox

Al momento dell'arrivo di DataBox, è necessario configurare DataBox con connettività di rete non implementata all'appliance NAS. Seguire la documentazione di installazione per il tipo di DataBox ordinato.

A seconda del tipo DataBox, potrebbero essere disponibili strumenti di copia dataBox. A questo punto, non sono consigliati per le migrazioni alle condivisioni file di Azure perché non copiano i file con la massima fedeltà a DataBox. Usare invece RoboCopy.

All'arrivo di DataBox, le condivisioni SMB di cui è stato effettuato il pre-provisioning saranno disponibili per ogni account di archiviazione specificato al momento dell'ordinamento.

  • Se i file vengono inseriti in una condivisione file di Azure Premium, sarà presente una condivisione SMB per ogni account di archiviazione premium "Archiviazione file".
  • Se i file vengono inseriti in un account di archiviazione standard, saranno presenti tre condivisioni SMB per account di archiviazione standard (GPv1 e GPv2). Solo le condivisioni file che terminano con _AzFiles sono rilevanti per la migrazione. Ignorare eventuali condivisioni BLOB di blocchi e pagine.

Seguire la procedura descritta nella documentazione di Azure DataBox:

  1. Connessione a Data Box
  2. Copiare i dati in Data Box
  3. Preparare DataBox per la partenza in Azure

La documentazione di DataBox collegata specifica un comando RoboCopy. Tuttavia, il comando non è adatto per mantenere la fedeltà completa del file e della cartella. Usare invece questo comando:

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 prossima sezione RoboCopy.
  • Per altre informazioni su come ridimensionare in modo appropriato il numero /MT:ndi thread, ottimizzare la velocità di RoboCopy e fare di RoboCopy un buon vicino nel data center, vedere la sezione Risoluzione dei problemi di RoboCopy.

Suggerimento

In alternativa a Robocopy, Data Box ha creato un servizio di copia dei 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: Recuperare RoboCopy dal NAS

Dopo che DataBox segnala che tutti i file e le cartelle sono stati inseriti nelle condivisioni file di Azure pianificate, è possibile continuare con questa fase. È necessario recuperare RoboCopy solo se i dati sul NAS potrebbero essere stati modificati dopo l'avvio della copia di DataBox. In alcuni scenari in cui si usa una condivisione per scopi di archiviazione, è possibile arrestare le modifiche alla condivisione nel NAS fino al completamento della migrazione. È anche possibile soddisfare i requisiti aziendali impostando condivisioni NAS in sola lettura durante la migrazione.

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

In questo passaggio verranno eseguiti processi RoboCopy per recuperare le condivisioni cloud con le modifiche più recenti sul NAS dal momento in cui sono state copiate tramite fork le condivisioni in DataBox. Questo recupero RoboCopy può finire rapidamente o richiedere un po', a seconda della quantità di varianza che si è verificata sulle condivisioni NAS.

Eseguire la prima copia locale nella cartella di destinazione di Windows Server:

  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 in Windows Server temporaneo
  4. Avviare la copia usando RoboCopy come descritto

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

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

Quando si è pronti, vedere l'articolo Usare una condivisione file di Azure con Windows e montare la condivisione file di Azure per cui si vuole avviare il recupero di RoboCopy nas.

Robocopy

Il comando RoboCopy seguente copia solo le differenze (file e cartelle aggiornati) dall'archiviazione NAS 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 avanza come previsto.

Cut-over utente

Quando si esegue il comando RoboCopy per la prima volta, gli utenti e le applicazioni accedono ancora ai file nel NAS e possono potenzialmente modificarli. È possibile che RoboCopy abbia elaborato una directory, passi alla successiva e quindi un utente nel percorso di origine (NAS) aggiunge, modifica o elimina un file che ora non verrà elaborato in questa esecuzione di RoboCopy corrente. 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.

Una 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.

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 RoboCopy. Raccoglierà eventuali modifiche, che potrebbero essere state perse. Quanto tempo dura 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 Di Windows Server ed eventualmente modificare la distribuzione DFS-N in modo che punti al file. 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 corrispondono automaticamente man mano che gli utenti esistono in Active Directory e RoboCopy copia i file e i metadati a massima fedeltà. Se sono stati usati utenti locali nel NAS, è necessario ricreare questi utenti come utenti locali di Windows Server ed eseguire il mapping dei SID esistenti RoboCopy spostati in Windows Server ai SID dei nuovi utenti locali di Windows Server.

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

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

Risoluzione dei problemi

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 copiano l'esempio di 1 TiB di file di piccole dimensioni notevolmente più veloci 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 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:

  • 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, ovvero normali. 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.

Passaggi successivi

Sono disponibili altre informazioni sulle condivisioni file di Azure. Gli articoli seguenti illustrano le opzioni avanzate, le procedure consigliate e contengono anche la Guida alla risoluzione dei problemi. Questi articoli si collegano alla documentazione della condivisione file di Azure in base alle esigenze.