Migrazione di StorSimple 8100 e 8600 a Sincronizzazione file di Azure

La serie StorSimple 8000 include le appliance fisiche 8100 o 8600 fisiche e locali e i relativi componenti del servizio cloud. Anche le appliance virtuali StorSimple 8010 e 8020 sono descritte in questa guida alla migrazione. È possibile eseguire la migrazione dei dati da una di queste appliance alle condivisioni file di Azure con sincronizzazione file di Azure facoltativa. Sincronizzazione file di Azure è il servizio di Azure predefinito e strategico a lungo termine che sostituisce la funzionalità locale di StorSimple. Questo articolo fornisce le informazioni generali e i passaggi di migrazione necessari per una corretta migrazione a Sincronizzazione file di Azure.

Nota

Il servizio StorSimple (incluso Gestione dispositivi StorSimple per serie 8000 e 1200 e StorSimple Data Manager) ha raggiunto la fine del supporto. La fine del supporto per StorSimple è stata pubblicata nel 2019 nelle pagine Criteri del ciclo di vita Microsoft e Comunicazioni di Azure. Alcune notifiche aggiuntive sono state inviate tramite posta elettronica e pubblicate nel portale di Azure e nella panoramica di StorSimple. Per altri dettagli, contattare il supporto tecnico Microsoft.

Questo video offre una panoramica di:

• File di Azure
• Sincronizzazione file di Azure
• Confronto tra StorSimple e File di Azure
• Panoramica dello strumento di migrazione e del processo di StorSimple Data Manager

Fase 1: Preparare la migrazione

Questa sezione contiene i passaggi da eseguire all'inizio della migrazione dai volumi StorSimple alle condivisioni file di Azure.

Questo video illustra quanto segue:

• Selezione del livello di archiviazione
• Selezione delle opzioni di ridondanza dell'archiviazione
• Confronto tra la selezione dell'accesso diretto alla condivisione e Sincronizzazione file di Azure
• Chiave e numero di serie del servizio StorSimple
• Migrazione del backup del volume StorSimple
• Mapping di volumi e condivisioni StorSimple alle condivisioni file di Azure
• Raggruppamento di condivisioni all'interno di condivisioni file di Azure
• Considerazioni sul mapping
• Foglio di lavoro per la pianificazione della migrazione
• Foglio di calcolo per mapping dello spazio dei nomi

Inventario

Quando si inizia a pianificare la migrazione, identificare prima di tutto tutte le appliance e i volumi StorSimple di cui è necessario eseguire la migrazione. Successivamente, è possibile scegliere il percorso di migrazione migliore.

• Le appliance fisiche StorSimple (serie 8000) usano questa guida alla migrazione.
• Le appliance virtuali StorSimple (serie 1200) usano una guida alla migrazione diversa.

Riepilogo dei costi di migrazione

Le migrazioni alle condivisioni file di Azure dai volumi StorSimple tramite processi di migrazione in una risorsa StorSimple Data Manager sono gratuite. Altri costi potrebbero essere sostenuti durante e dopo una migrazione:

• Uscita di rete: i file StorSimple risiedono in un account di archiviazione all'interno di un'area di Azure specifica. Se si effettua il provisioning delle condivisioni file di Azure di cui si esegue la migrazione in un account di archiviazione nella stessa area di Azure, non si applicano costi in uscita. Tuttavia, se si spostano i file in un account di archiviazione in un'area diversa come parte di questa migrazione, verranno applicati costi in uscita.
• Transazioni di condivisione file di Azure: quando i file vengono copiati in una condivisione file di Azure (come parte di una migrazione o all'esterno di una), i costi delle transazioni si applicano come file e metadati vengono scritti. Come procedura consigliata, avviare la condivisione file di Azure nel livello ottimizzato per le transazioni durante la migrazione. Passare al livello desiderato al termine della migrazione. Le fasi descritte in questo articolo descrivono questa operazione nel punto appropriato.
• Modificare un livello di condivisione file di Azure: modifica del livello delle transazioni dei costi di una condivisione file di Azure. Nella maggior parte dei casi, è più conveniente seguire i consigli del punto precedente.
• Costo di archiviazione: quando la migrazione inizia a copiare i file in una condivisione file di Azure, l'archiviazione viene usata e fatturata. I backup migrati diventano snapshot di condivisione file di Azure. Gli snapshot di condivisione file utilizzano solo la capacità di archiviazione per le differenze che contengono.
• StorSimple: fino a quando non si esegue il deprovisioning dei dispositivi StorSimple e degli account di archiviazione, i costi di StorSimple per l'archiviazione, i backup e le appliance continueranno a verificarsi.

Confronto tra accesso diretto alla condivisione e Sincronizzazione file di Azure

Le condivisioni file di Azure aprono un nuovo mondo di opportunità per strutturare la distribuzione dei servizi file. Una condivisione file di Azure è una condivisione SMB nel cloud che è possibile configurare per consentire agli utenti di accedere direttamente tramite il protocollo SMB con l'autenticazione Kerberos familiare e le autorizzazioni NTFS esistenti (ACL di file e cartelle) che funzionano in modo nativo. Altre informazioni sull'accesso basato sull'identità alle condivisioni file di Azure.

Un'alternativa all'accesso diretto è Sincronizzazione file di Azure. Sincronizzazione file di Azure è un analogico diretto per la capacità di StorSimple di memorizzare nella cache i file usati di frequente in locale.

Sincronizzazione file di Azure è un servizio cloud Microsoft basato su due componenti principali:

• Sincronizzazione dei file e suddivisione in livelli cloud per creare una cache di accesso alle prestazioni in qualsiasi Windows Server.
• Condivisioni file come archiviazione nativa in Azure a cui è possibile accedere tramite più protocolli, ad esempio SMB e file REST.

Le condivisioni file di Azure mantengono importanti aspetti relativi alla fedeltà dei file, ad esempio attributi, autorizzazioni e timestamp. Con le condivisioni file di Azure, non è più necessario che un'applicazione o un servizio interpreti i file e le cartelle archiviati nel cloud. È possibile accedervi in modo nativo tramite protocolli e client familiari. Le condivisioni file di Azure consentono di archiviare i dati del file server per utilizzo generico e i dati dell'applicazione nel cloud.

Questo articolo è incentrato sui passaggi di migrazione. Per altre informazioni su Sincronizzazione file di Azure prima della migrazione, vedere gli articoli seguenti:

• Guida alla pianificazione di Sincronizzazione file di Azure
• Guida alla distribuzione di Sincronizzazione file di Azure

Chiave di crittografia dei dati del servizio StorSimple

Quando si configura per la prima volta l'appliance StorSimple, viene generata una chiave di crittografia dei dati del servizio e viene richiesto di archiviare in modo sicuro la chiave. Questa chiave viene usata per crittografare tutti i dati nell'account di archiviazione di Azure associato in cui l'appliance StorSimple archivia i file.

La chiave di crittografia dei dati del servizio è necessaria per una corretta migrazione. Recuperare questa chiave dai record, una per ogni appliance nell'inventario.

Se non è possibile trovare le chiavi nei record, è possibile generare una nuova chiave dall'appliance. Ogni appliance ha una chiave di crittografia univoca.

Modificare la chiave DEK del servizio

Le chiavi DEK del servizio vengono utilizzate per crittografare dati riservati dei clienti, ad esempio credenziali di account di archiviazione, che vengono inviate dal servizio StorSimple Manager al dispositivo StorSimple. Occorre modificare queste chiavi periodicamente, se l'organizzazione IT dispone di un criterio di rotazione delle chiavi nei dispositivi di archiviazione. Il processo di modifica della chiave può essere leggermente diverso a seconda che ci sia una o più dispositivi gestiti dal servizio StorSimple Manager. Per altre informazioni, vedere Sicurezza e protezione dei dati di StorSimple.

La modifica della chiave DEK del servizio è un processo che prevede 3 fasi:

1. Usando gli script di Windows PowerShell per Azure Resource Manager, autorizzare un dispositivo a modificare la chiave DEK del servizio.
2. Mediante Windows PowerShell per StorSimple, si consente di avviare la modifica della chiave DEK del servizio.
3. Se si dispone di più di un dispositivo StorSimple, è necessario aggiornare la chiave DEK del servizio in altri dispositivi.

Passaggio 1: Usare uno script di Windows PowerShell per autorizzare un dispositivo a modificare la chiave DEK del servizio

In genere, l'amministratore dei dispositivi richiede all'amministratore del servizio di autorizzare un dispositivo a modificare le chiavi DEK del servizio. L'amministratore del servizio autorizza quindi il dispositivo a modificare la chiave.

Questo passaggio viene eseguito usando lo script basato su Azure Resource Manager. L'amministratore del servizio può selezionare un dispositivo idoneo per l'autorizzazione. Il dispositivo viene quindi autorizzato ad avviare il processo di modifica della chiave DEK del servizio.

Per altre informazioni sull'uso dello script, vedere Authorize-ServiceEncryptionRollover.ps1

Quali dispositivi possono essere autorizzati a modificare le chiavi DEK del servizio?

Per essere autorizzato ad avviare le modifiche alla chiave DEK del servizio, un dispositivo deve soddisfare i criteri seguenti:

• Il dispositivo deve essere online per essere idoneo per l'autorizzazione di modifica della chiave DEK del servizio.
• È possibile autorizzare di nuovo lo stesso dispositivo dopo 30 minuti se la modifica della chiave non è stata avviata.
• È possibile autorizzare un dispositivo diverso, purché la modifica della chiave non sia stata avviata dal dispositivo autorizzato in precedenza. Dopo che il nuovo dispositivo è stato autorizzato, il dispositivo precedente non può avviare la modifica.
• Non è possibile autorizzare un dispositivo mentre è in corso il rollover della chiave DEK del servizio.
• È possibile autorizzare un dispositivo quando alcuni dei dispositivi registrati con il servizio hanno eseguito il rollover della crittografia mentre altri no.

Passaggio 2: Usare Windows PowerShell per StorSimple per avviare la modifica della chiave DEK del servizio

Questo passaggio viene eseguito nell'interfaccia di Windows PowerShell per StorSimple nel dispositivo StorSimple autorizzato.

Nota

Non è possibile eseguire operazioni nel portale di Azure del servizio StorSimple Manager fino a quando il rollover della chiave non viene completato.

Se si usa la console seriale del dispositivo per la connessione all'interfaccia di Windows PowerShell,seguire questa procedura.

Per avviare la modifica della chiave DEK del servizio

1. Selezionare l'opzione 1 per eseguire l'accesso completo.

2. Al prompt dei comandi digitare:

   Invoke-HcsmServiceDataEncryptionKeyChange

3. Dopo che il cmdlet è stato completato, si otterrà una nuova chiave DEK del servizio. Copiare e salvare la chiave per l'uso nel passaggio 3 di questo processo. Questa chiave verrà usata per aggiornare tutti i dispositivi rimanenti registrati con il servizio StorSimple Manager.

   Nota

   Questo processo deve essere avviato entro quattro ore dall'autorizzazione di un dispositivo StorSimple.

   La nuova chiave viene quindi inviata al servizio affinché ne venga effettuato il push a tutti i dispositivi registrati con il servizio. Nel dashboard del servizio verrà visualizzato un avviso. Il servizio disabiliterà tutte le operazioni nei dispositivi registrati e l'amministratore dei dispositivi dovrà quindi aggiornare la chiave DEK del servizio negli altri dispositivi. Tuttavia, i flussi di I/O (invio di dati dagli host al cloud) non verranno interrotti.

   Se nel servizio è registrato un unico dispositivo, il processo di rollover è completo ed è possibile ignorare il passaggio successivo. Se nel servizio sono registrati più dispositivi, andare al passaggio 3.

Passaggio 3: Aggiornare la chiave DEK del servizio in altri dispositivi StorSimple

Questa procedura deve essere eseguita nell'interfaccia di Windows PowerShell del dispositivo StorSimple se vi sono più dispositivi registrati per il servizio StorSimple Manager. La chiave ottenuta nel passaggio 2 deve essere usata per aggiornare tutti i dispositivi StorSimple rimanenti registrati con il servizio StorSimple Manager.

Eseguire i passaggi seguenti per aggiornare la chiave DEK del servizio nel dispositivo.

Per aggiornare la chiave di crittografia dei dati del servizio nei dispositivi fisici

1. Usare Windows PowerShell per StorSimple per connettersi alla console. Selezionare l'opzione 1 per eseguire l'accesso completo.
2. Al prompt dei comandi digitare: Invoke-HcsmServiceDataEncryptionKeyChange – ServiceDataEncryptionKey
3. Specificare la chiave DEK ottenuta nel Passaggio 2: Usare Windows PowerShell per StorSimple per avviare la modifica della chiave DEK del servizio.

Per aggiornare la chiave di crittografia dei dati del servizio in tutte le appliance cloud 8010/8020

1. Scaricare e configurare lo script di PowerShell Update-CloudApplianceServiceEncryptionKey.ps1.
2. Aprire PowerShell e al prompt dei comandi digitare: Update-CloudApplianceServiceEncryptionKey.ps1 -SubscriptionId [subscription] -TenantId [tenantid] -ResourceGroupName [resource group] -ManagerName [device manager]

Questo script garantisce che la chiave di crittografia dei dati del servizio sia configurata in tutte le appliance cloud 8010/8020 nel servizio Gestione dispositivi.

Attenzione

Quando si decide come connettersi all'appliance StorSimple, tenere presente quanto segue:

• La connessione tramite una sessione HTTPS è l'opzione più sicura e consigliata.
• La connessione diretta alla console seriale del dispositivo è protetta ma la connessione alla console seriale sugli switch di rete non lo è.
• Le connessioni di sessione HTTP sono un'opzione, ma sono non crittografate. Non sono consigliabili, a meno che non vengano usate all'interno di una rete chiusa e attendibile.

Limitazioni note

StorSimple Data Manager e le condivisioni file di Azure presentano alcune limitazioni da considerare prima di iniziare, in quanto possono impedire una migrazione:

• Sono supportati solo i volumi NTFS dell'appliance StorSimple. I volumi ReFS non sono supportati.
• Non è supportato nessun volume posizionato in dischi dinamici di Windows Server.
• Il servizio non funziona con volumi crittografati con BitLocker o con Deduplicazione dati abilitata.
• Non è possibile eseguire la migrazione dei backup di StorSimple danneggiati.
• Le opzioni di rete speciali, ad esempio firewall o comunicazioni solo endpoint privato, non possono essere abilitate nell'account di archiviazione di origine in cui sono archiviati i backup StorSimple, né nell'account di archiviazione di destinazione che contiene le condivisioni file di Azure.

Fedeltà dei file

Se nessuna delle limitazioni in Limitazioni note impedisce una migrazione, esistono ancora limitazioni su ciò che può essere archiviato nelle condivisioni file di Azure.

La fedeltà dei file si riferisce alla moltitudine di attributi, timestamp e dati che compongono un file. In una migrazione, la fedeltà dei file è una misura della quantità di informazioni sull'origine (volume StorSimple) che può essere convertita (migrata) nella condivisione file di Azure di destinazione.

File di Azure supporta un subset delle proprietà del file NTFS. Vengono migrati elenchi di controllo di accesso di Windows, metadati comuni e alcuni timestamp.

Gli elementi seguenti non impediscono una migrazione, ma causeranno problemi per singolo elemento durante una migrazione:

• Timestamp: l'ora di modifica del file non verrà impostata. Attualmente è di sola lettura sul protocollo REST. Il timestamp dell'ultimo accesso in un file non verrà spostato, perché non è un attributo supportato nei file archiviati in una condivisione file di Azure.
• I flussi di dati alternativi non possono essere archiviati nelle condivisioni file di Azure. I file che contengono flussi di dati alternativi verranno copiati, ma i flussi di dati alternativi vengono rimossi dal file nel processo.
• I collegamenti simbolici, i collegamenti rigidi, le giunzioni e i punti di analisi vengono ignorati durante una migrazione. La copia dei log di migrazione elenca ogni elemento ignorato e un motivo.
• Impossibile copiare i file crittografati EFS. I log di copia mostrano che l'elemento non è stato copiato con "Accesso negato".
• I file danneggiati vengono ignorati. I log di copia potrebbero elencare errori diversi per ogni elemento danneggiato nel disco StorSimple: "La richiesta ha avuto esito negativo a causa di un errore hardware irreversibile del dispositivo" o "Il file o la directory è danneggiato o illeggibile" o "La struttura dell'elenco di controllo di accesso (ACL) non è valida".
• I singoli file di dimensioni superiori a 4 TiB vengono ignorati.
• Le lunghezze del percorso del file devono essere uguali o inferiori a 2048 caratteri. I file e le cartelle con percorsi più lunghi vengono ignorati.
• I punti di analisi vengono ignorati. I punti di analisi di SIS/Deduplicazione dati Microsoft o quelli di terze parti non possono essere risolti dal motore di migrazione e impediranno una migrazione dei file e delle cartelle interessati.

La sezione relativa alla risoluzione dei problemi alla fine di questo articolo include altri dettagli per i codici di errore a livello di elemento e di processo di migrazione e, ove possibile, le relative opzioni di mitigazione.

Backup dei volumi StorSimple

StorSimple offre backup differenziali a livello di volume. Anche le condivisioni file di Azure hanno questa possibilità, denominata snapshot di condivisione.

I processi di migrazione possono spostare solo i backup, mai i dati dal volume live. Di conseguenza, il backup più recente è più vicino ai dati in tempo reale e pertanto deve sempre far parte dell'elenco dei backup da spostare in una migrazione.

Decidere se è necessario spostare eventuali backup meno recenti durante la migrazione. È consigliabile mantenere l'elenco il più piccolo possibile in modo che i processi di migrazione siano completati più velocemente.

Per identificare i backup critici di cui è necessario eseguire la migrazione, creare un elenco di controllo dei criteri di backup. Ad esempio:

• Backup più recente.
• Un backup al mese per 12 mesi.
• Un backup all'anno per tre anni.

Quando si creano i processi di migrazione, è possibile usare questo elenco per identificare i backup esatti del volume StorSimple di cui è necessario eseguire la migrazione per soddisfare i requisiti.

È consigliabile sospendere tutti i criteri di conservazione dei backup StorSimple prima di selezionare un backup per la migrazione. La migrazione dei backup può richiedere diversi giorni o settimane. StorSimple offre criteri di conservazione dei backup che eliminano i backup. I backup selezionati per questa migrazione potrebbero essere eliminati prima di poter eseguire la migrazione.

Attenzione

La selezione di più di 50 backup del volume StorSimple non è supportata.

Eseguire il mapping dei volumi StorSimple esistenti alle condivisioni file di Azure

In questo passaggio verrà determinato il numero di condivisioni file di Azure necessarie. Una singola istanza di Windows Server (o cluster) può sincronizzare fino a 30 condivisioni file di Azure.

Potrebbero essere presenti più cartelle nei volumi attualmente condivisi in locale come condivisioni SMB per gli utenti e le app. Il modo più semplice per eseguire l'immagine di questo scenario consiste nell'immaginare una condivisione locale che esegue il mapping 1:1 a una condivisione file di Azure. Se si dispone di un numero sufficientemente piccolo di condivisioni, inferiore a 30 per una singola istanza di Windows Server, è consigliabile eseguire un mapping 1:1.

Se sono presenti più di 30 condivisioni, il mapping di una condivisione locale 1:1 a una condivisione file di Azure spesso non è necessario. Valutare le opzioni seguenti.

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. L'archiviazione di più condivisioni locali in un’unica condivisione file di Azure non impedisce di creare le 15 condivisioni SMB normali nell'istanza locale di Windows Server. Significa solo che si organizzano le cartelle radice di queste 15 condivisioni come sottocartelle in una cartella comune. Si sincronizza, quindi, questa cartella comune con una condivisione file di Azure. In questo modo, è necessaria solo una singola condivisione file di Azure nel cloud per questo gruppo di condivisioni locali.

Sincronizzazione di volumi

Sincronizzazione file di Azure supporta la sincronizzazione della radice di un volume con una condivisione file di Azure. Se si sincronizza la radice del volume, tutte le sottocartelle e i file passeranno nella stessa condivisione file di Azure.

La sincronizzazione della radice del volume non è sempre l'opzione migliore. La sincronizzazione di più posizioni offre alcuni vantaggi. In questo modo, ad esempio, è possibile mantenere inferiore il numero di elementi per ambito di sincronizzazione. Vengono testate le condivisioni file di Azure e Sincronizzazione file di Azure con 100 milioni di elementi (file e cartelle) per condivisione. Ma una procedura consigliata consiste nel cercare di mantenere il numero inferiore a 20 milioni o 30 milioni in una singola quota. La configurazione di Sincronizzazione file di Azure con un numero inferiore di elementi non è utile solo per la sincronizzazione file. Un numero inferiore di elementi offre benefici anche in scenari come i seguenti:

• L'analisi iniziale del contenuto cloud può essere completata più rapidamente, riducendo a sua volta l'attesa della visualizzazione dello spazio dei nomi in un server abilitato per Sincronizzazione file di Azure.
• Il ripristino lato cloud da uno snapshot di condivisione file di Azure sarà più veloce.
• Il ripristino di emergenza di un server locale può accelerare notevolmente.
• Le modifiche apportate direttamente in una condivisione file di Azure (al di fuori della sincronizzazione) possono essere rilevate e sincronizzate più velocemente.

Suggerimento

Se non si conosce il numero di file e cartelle esistenti, consultare lo strumento TreeSize di JAM Software GmbH.

Approccio strutturato a una mappa di distribuzione

Prima di distribuire l'archiviazione nel cloud in un passaggio successivo, è importante creare una mappa tra le cartelle locali e le condivisioni file di Azure. Questo mapping consentirà di appurare quante e quali risorse del gruppo di sincronizzazione di Sincronizzazione file di Azure verranno sottoposte a provisioning. Un gruppo di sincronizzazione collega la condivisione file di Azure e la cartella nel server e stabilisce una connessione di sincronizzazione.

Per decidere il numero di condivisioni file di Azure necessarie, esaminare i limiti e le procedure consigliate seguenti. In questo modo, sarà possibile ottimizzare la mappa.

• Un server in cui è installato l'agente di Sincronizzazione file di Azure può eseguire la sincronizzazione con un massimo di 30 condivisioni file di Azure.

• Una condivisione file di Azure viene distribuita in un account di archiviazione. Questa disposizione rende l'account di archiviazione una destinazione di scalabilità per i numeri correlati alle prestazioni come operazioni di I/O al secondo e velocità effettiva.

  Quando si distribuiscono condivisioni file di Azure, prestare attenzione alle limitazioni di un account di archiviazione in termini di operazioni di I/O al secondo. L’ideale sarebbe eseguire il mapping 1:1 delle condivisioni file con gli account di archiviazione. Tuttavia, ciò non sempre è possibile, a causa dei diversi limiti e restrizioni imposti dalla propria organizzazione e da Azure. Quando non è possibile distribuire una sola condivisione file per account di archiviazione, valutare quali condivisioni saranno particolarmente attive e quali lo saranno meno, in modo da non inserire le condivisioni file più utilizzate nello stesso account di archiviazione.

  Se si prevede di trasferire un'app in Azure che userà la condivisione file di Azure in modo nativo, potrebbe essere necessario ottenere prestazioni più elevate dalla condivisione file di Azure. Se questo tipo di uso è una possibilità, anche in futuro, è consigliabile creare una singola condivisione file standard di Azure nel proprio account di archiviazione.

• Esiste un limite di 250 account di archiviazione per sottoscrizione e area di Azure.

Suggerimento

Alla luce di queste informazioni, spesso diventa necessario raggruppare più cartelle di primo livello nei volumi in una nuova directory radice comune. Si sincronizza, quindi, questa nuova directory radice e tutte le cartelle in essa raggruppate in una singola condivisione file di Azure. Questa tecnica consente di rimanere entro il limite di 30 sincronizzazioni di condivisioni file di Azure per server.

Questo raggruppamento in una radice comune non influisce sull'accesso ai dati. Gli ACL non vengono modificati. È sufficiente modificare i percorsi di condivisione (come condivisioni SMB o NFS) nelle cartelle del server locale che ora sono state modificate in una radice comune. Non occorrono altre modifiche.

Importante

Il vettore di scala più importante per Sincronizzazione file di Azure è il numero di elementi (file e cartelle) che devono essere sincronizzati. Per informazioni più dettagliate, esaminare Obiettivi di scalabilità di Sincronizzazione file di Azure.

È consigliabile mantenere basso il numero di elementi per ambito di sincronizzazione. Questo è un fattore importante da considerare nel mapping delle cartelle alle condivisioni file di Azure. Sincronizzazione file di Azure è testato con 100 milioni di elementi (file e cartelle) per condivisione. Molte volte, tuttavia, è preferibile cercare di mantenere il numero di elementi al di sotto di 20 milioni o 30 milioni in una singola quota. Suddividere lo spazio dei nomi in più condivisioni se si inizia a superare questi numeri. È possibile continuare a raggruppare più condivisioni locali nella stessa condivisione file di Azure se si rimane approssimativamente al di sotto di questi numeri. Questa pratica fornirà spazio per la crescita.

È possibile che, nella propria situazione, un set di cartelle possa essere sincronizzato logicamente con la stessa condivisione file di Azure (usando il nuovo approccio comune alle cartelle radice menzionato in precedenza). Potrebbe essere preferibile, tuttavia, raggruppare le cartelle in modo che vengano sincronizzate con due condivisioni file di Azure anziché una sola. È possibile usare questo approccio per mantenere bilanciato il numero di file e cartelle per condivisione file nel server. È anche possibile suddividere le condivisioni locali e la sincronizzazione tra più server locali, aggiungendo la possibilità di eseguire la sincronizzazione con altre 30 condivisioni file di Azure per ogni server aggiuntivo.

Scenari e considerazioni comuni di sincronizzazione dei file

#	Scenario di sincronizzazione	Supportata	Considerazioni (o limitazioni)	Soluzione (soluzione alternativa)
1	File server con più dischi/volumi e più condivisioni nella stessa condivisione file di Azure di destinazione (consolidamento)	No	Una condivisione file di Azure di destinazione (endpoint cloud) supporta la sincronizzazione con un solo gruppo di sincronizzazione. Un gruppo di sincronizzazione supporta un solo endpoint server per ogni server registrato.	1) Iniziare con la sincronizzazione di un solo disco (relativo volume radice) alla condivisione file di Azure di destinazione. Cominciare dal disco/volume più grande sarà utile per i requisiti di archiviazione locale. Configurare il cloud a livelli per suddividere in livelli tutti i dati nel cloud, liberando spazio sul disco del file server. Spostare i dati da altri volumi/condivisioni nel volume corrente che esegue la sincronizzazione. Continuare i passaggi uno per uno fino a quando tutti i dati vengono suddivisi in livelli nel cloud o nella migrazione. 2) Specificare come destinazione un solo volume radice (disco) alla volta. Usare il cloud a livelli per suddividere in livelli tutti i dati per la condivisione file di Azure di destinazione. Rimuovere l'endpoint server dal gruppo di sincronizzazione, ricreare l'endpoint con il volume/disco radice successivo, sincronizzare e ripetere il processo. Nota: potrebbe essere necessario reinstallare l'agente. 3) Consigliare l'uso di più condivisioni file di Azure di destinazione (account di archiviazione identico o diverso in base ai requisiti di prestazioni)
2	File server con singolo volume e più condivisioni nella stessa condivisione file di Azure di destinazione (consolidamento)	Sì	Non è possibile avere più endpoint server per ogni server registrato che esegue la sincronizzazione con la stessa condivisione file di Azure di destinazione (uguale a quella precedente)	Sincronizzare la radice del volume che contiene più condivisioni o cartelle di primo livello. Per altre informazioni, fare riferimento a Concetto di raggruppamento delle condivisioni e Sincronizzazione di volumi.
3	File server con più condivisioni e/o volumi in più condivisioni file di Azure con un singolo account di archiviazione (mapping 1:1 della condivisione)	Sì	Una singola istanza di Windows Server (o cluster) può sincronizzare fino a 30 condivisioni file di Azure. Un account di archiviazione è una destinazione di scalabilità per le prestazioni. Le operazioni di I/O al secondo e la velocità effettiva vengono condivise tra le condivisioni file. Mantenere il numero di elementi per gruppo di sincronizzazione entro 100 milioni di elementi (file e cartelle) per condivisione. L’ideale sarebbe rimanere al di sotto di 20 o 30 milioni di elementi per condivisione.	1) Usare più gruppi di sincronizzazione (numero di gruppi di sincronizzazione = numero di condivisioni file di Azure da sincronizzare). 2) In questo scenario è possibile sincronizzare solo 30 condivisioni alla volta. Se esistono più di 30 condivisioni in tale file server, usare il Concetto di raggruppamento delle condivisioni e Sincronizzazione di volumi per ridurre il numero di cartelle radice o di primo livello nell'origine. 3) Usare server di Sincronizzazione file aggiuntivi in locale e dividere/spostare i dati in questi server per aggirare le limitazioni nel server Windows di origine.
4	File server con più condivisioni e/o volumi in più condivisioni file di Azure con un account di archiviazione differente (mapping 1:1 della condivisione)	Sì	Una singola istanza di Windows Server (o cluster) può sincronizzare fino a 30 condivisioni file di Azure (account di archiviazione identico o differente). Mantenere il numero di elementi per gruppo di sincronizzazione entro 100 milioni di elementi (file e cartelle) per condivisione. L’ideale sarebbe rimanere al di sotto di 20 o 30 milioni di elementi per condivisione.	Stesso approccio illustrato in precedenza
5	Più file server con singolo (condivisione o volume radice) nella stessa condivisione file di Azure di destinazione (consolidamento)	No	Un gruppo di sincronizzazione non può usare l'endpoint cloud (condivisione file di Azure) già configurato in un altro gruppo di sincronizzazione. Anche se un gruppo di sincronizzazione può avere endpoint server in file server diversi, i file non possono essere distinti.	Seguire le indicazioni riportate nello scenario 1 precedente con considerazioni aggiuntive sulla destinazione di un solo file server alla volta.

Creare una tabella di mapping

Usare le informazioni precedenti per determinare il numero di condivisioni file di Azure necessarie e quali parti dei dati esistenti finiranno nelle varie condivisioni file di Azure.

Creare una tabella che registra le considerazioni effettuate in modo da potervi fare riferimento quando è necessario. Rimanere organizzati è importante perché può essere facile perdere i dettagli del piano di mapping quando si esegue il provisioning di molte risorse di Azure contemporaneamente. Scaricare il file di Excel seguente da usare come modello per facilitare la creazione del mapping.

Scaricare un modello di mapping dello spazio dei nomi.

Numero di account di archiviazione

La migrazione trarrà probabilmente vantaggio dalla distribuzione di più account di archiviazione che contengono un numero inferiore di condivisioni file di Azure.

Se le condivisioni file sono altamente attive (usate da molti utenti o applicazioni), due condivisioni file di Azure potrebbero raggiungere il limite di prestazioni dell'account di archiviazione. Per questo motivo, è spesso preferibile eseguire la migrazione a più account di archiviazione, ognuno con le proprie condivisioni file e in genere non più di due o tre condivisioni per ogni account di archiviazione. È preferibile distribuire gli account di archiviazione con una sola condivisione file ciascuno. È possibile raggruppare più condivisioni file di Azure nello stesso account di archiviazione, se sono presenti condivisioni di archiviazione.

Queste considerazioni si applicano più a un accesso diretto al cloud (tramite una macchina virtuale o un servizio di Azure) rispetto a Sincronizzazione file di Azure. Se si prevede di usare esclusivamente Sincronizzazione file di Azure in queste condivisioni, il raggruppamento di più in un singolo account di archiviazione di Azure è corretto. In futuro, potrebbe essere necessario trasferire in modalità lift-and-shift un'app nel cloud che accederà direttamente a una condivisione file, in quanto questo scenario trarrà vantaggio dalla velocità effettiva e dalle operazioni di I/O al secondo più elevate. In alternativa, è possibile iniziare a usare un servizio in Azure che tragga vantaggio anche dalla velocità effettiva e dalle operazioni di I/O al secondo più elevate.

Dopo aver creato un elenco delle condivisioni, eseguire il mapping di ogni condivisione all'account di archiviazione in cui risiederà. Scegliere un'area di Azure e assicurarsi che ogni account di archiviazione e risorsa di Sincronizzazione file di Azure corrisponda all'area selezionata.

Importante

Non configurare ora le impostazioni di rete e firewall per gli account di archiviazione. Impostare queste configurazioni a questo punto renderebbe impossibile una migrazione. Configurare queste impostazioni di archiviazione di Azure al termine della migrazione.

Impostazioni account di archiviazione

Esistono molte configurazioni che è possibile eseguire in un account di archiviazione. Usare l'elenco di controllo seguente per confermare le configurazioni dell'account di archiviazione. È possibile modificare la configurazione di rete al termine della migrazione.

• Firewall e reti virtuali: Disabilitato: non configurare restrizioni IP o limitare l'accesso dell'account di archiviazione a una rete virtuale specifica. L'endpoint pubblico dell'account di archiviazione viene usato durante la migrazione. Tutti gli indirizzi IP dalle macchine virtuali di Azure devono essere consentiti. È consigliabile configurare le regole del firewall nell'account di archiviazione dopo la migrazione. Configurare sia gli account di archiviazione di origine che di destinazione in questo modo.
• Endpoint privati: Supportato: è possibile abilitare gli endpoint privati, ma l'endpoint pubblico viene usato per la migrazione e deve rimanere disponibile. Questo vale sia per gli account di archiviazione di origine che per gli account di archiviazione di destinazione.

Riepilogo della fase 1

Alla fine della fase 1:

• È disponibile una buona panoramica dei dispositivi e dei volumi StorSimple.
• Il servizio Data Manager è pronto per accedere ai volumi StorSimple nel cloud perché è stata recuperata la chiave di crittografia dei dati del servizio per ogni dispositivo StorSimple.
• Si dispone di un piano per cui è necessario eseguire la migrazione di volumi e backup (se presenti oltre l'ultima versione).
• Si sa come eseguire il mapping dei volumi al numero appropriato di condivisioni file e account di archiviazione di Azure.

Fase 2: Distribuire risorse di archiviazione e migrazione di Azure

Questa sezione illustra le considerazioni sulla distribuzione dei diversi tipi di risorse necessari in Azure. Alcuni conterranno i dati dopo la migrazione e alcuni sono necessari esclusivamente per la migrazione. Non iniziare a distribuire le risorse fino a quando non è stato finalizzato il piano di distribuzione. È difficile, a volte impossibile, modificare alcuni aspetti delle risorse di Azure dopo la distribuzione.

Questo video illustra la distribuzione di:

• Account di archiviazione
• Sottoscrizioni e gruppi di risorse
• Account di archiviazione
• Tipi e nomi
• Prestazioni e dimensioni della condivisione
• Tipi di posizione e replica
• Condivisioni file di Azure
• Servizio StorSimple Data Manager

Distribuire gli account di archiviazione

È probabile che sia necessario distribuire diversi account di archiviazione di Azure. Ognuno conterrà un numero inferiore di condivisioni file di Azure, in base al piano di distribuzione. Passare al portale di Azure per distribuire gli account di archiviazione pianificati. Prendere in considerazione l'adesione alle impostazioni di base seguenti per qualsiasi nuovo account di archiviazione.

Importante

Non configurare le impostazioni di rete e firewall per gli account di archiviazione prima o durante la migrazione. Impostare tali configurazioni a questo punto renderebbe impossibile una migrazione. L'endpoint pubblico deve essere accessibile negli account di archiviazione di origine e di destinazione. La limitazione a intervalli IP specifici o reti virtuali non è supportata. È possibile modificare le configurazioni di rete dell'account di archiviazione al termine della migrazione.

Subscription

È possibile usare la stessa sottoscrizione usata per la distribuzione di StorSimple oppure usare una sottoscrizione diversa. L'unica limitazione è che la sottoscrizione deve trovarsi nello stesso tenant di Microsoft Entra della sottoscrizione StorSimple. È consigliabile spostare la sottoscrizione StorSimple nel tenant appropriato prima di avviare una migrazione. È possibile spostare l'intera sottoscrizione solo perché le singole risorse StorSimple non possono essere spostate in un tenant o una sottoscrizione diversa.

Gruppo di risorse

I gruppi di risorse in Azure supportano l'organizzazione delle risorse e le autorizzazioni di gestione dell'amministratore. vedere altre informazioni.

Nome account di archiviazione

Il nome dell'account di archiviazione diventerà parte di un URL usato per accedere alla condivisione file e presenta alcune limitazioni di carattere. Nella convenzione di denominazione considerare che i nomi degli account di archiviazione devono essere univoci nel mondo, consentire solo lettere minuscole e numeri, richiedere da 3 a 24 caratteri e non consentire caratteri speciali come trattini o caratteri di sottolineatura. Vedere le Regole di denominazione delle risorse di archiviazione di Azure.

Ufficio

L'area di Azure di un account di archiviazione è importante. Se si usa Sincronizzazione file di Azure, tutti gli account di archiviazione devono trovarsi nella stessa area della risorsa del servizio di sincronizzazione archiviazione. L'area di Azure selezionata deve essere vicina o centrale ai server e agli utenti locali. Dopo aver distribuito la risorsa, non è possibile modificarne l'area.

È possibile selezionare un'area diversa da cui si trovano attualmente i dati StorSimple (account di archiviazione), tuttavia, in caso affermativo, verranno applicati addebiti in uscita durante la migrazione. I dati lasceranno l'area StorSimple e immetteranno la nuova area dell'account di archiviazione. Non si applicano addebiti per la larghezza di banda se si è all'interno della stessa area di Azure.

Prestazioni

È possibile scegliere l'archiviazione Premium (SSD) per le condivisioni file di Azure o l'archiviazione standard. L'archiviazione Standard include diversi livelli per una condivisione file. L'archiviazione Standard è l'opzione più adatta per la maggior parte dei clienti che eseguono la migrazione da StorSimple.

• Scegliere Archiviazione Premium se sono necessarie le prestazioni di una condivisione file di Azure Premium.
• Scegliere l'archiviazione standard per i carichi di lavoro di file server per utilizzo generico, inclusi i dati ad accesso frequente e i dati di archiviazione. Scegliere anche l'archiviazione standard se l'unico carico di lavoro nella condivisione nel cloud sarà Sincronizzazione file di Azure.
• Per le condivisioni file Premium, scegliere condivisioni file nella creazione guidata dell'account di archiviazione.

Replica

Sono disponibili diverse impostazioni di replica. Scegliere solo tra le due opzioni seguenti:

• Archiviazione con ridondanza locale (LRS).
• Archiviazione con ridondanza della zona (ZRS), che non è disponibile in tutte le aree di Azure.

Nota

L'archiviazione con ridondanza geografica e l'archiviazione con ridondanza geografica della zona non sono supportate.

Condivisioni file di Azure

Dopo aver creato gli account di archiviazione, passare alla sezione Condivisione file degli account di archiviazione e distribuire il numero appropriato di condivisioni file di Azure in base al piano di migrazione dalla fase 1. Prendere in considerazione l'adesione alle impostazioni di base seguenti per le nuove condivisioni file in Azure.

Nome
Sono supportati lettere minuscole, numeri e trattini.

Quota
La quota qui è paragonabile a una quota rigida SMB in un'istanza di Windows Server. La procedura consigliata consiste nel non impostare una quota in questo caso perché la migrazione e altri servizi avranno esito negativo quando viene raggiunta.

Livelli
Selezionare Transazione ottimizzata per la nuova condivisione file. Durante la migrazione verranno eseguite molte transazioni. È più conveniente modificare il livello in un secondo momento con il livello più adatto al carico di lavoro.

StorSimple Data Manager

La risorsa di Azure che contiene i processi di migrazione è denominata StorSimple Data Manager. Selezionare Nuova risorsa e cercarla. Selezionare Crea.

Questa risorsa temporanea viene usata per l'orchestrazione. Eseguirne il deprovisioning al termine della migrazione. Assicurarsi di distribuirla nella stessa sottoscrizione, gruppo di risorse e area dell'account di archiviazione StorSimple.

Sincronizzazione file di Azure

Con Sincronizzazione file di Azure è possibile aggiungere la memorizzazione nella cache locale dei file a cui si accede più di frequente. Analogamente alle capacità di memorizzazione nella cache di StorSimple, la funzionalità di suddivisione in livelli cloud di Sincronizzazione file di Azure offre una latenza di accesso locale in combinazione con il controllo migliorato sulla capacità della cache disponibile nell'istanza di Windows Server e nella sincronizzazione multisito. Se l'obiettivo è disporre di una cache locale, nella rete locale preparare una macchina virtuale Windows Server (sono supportati anche server fisici e cluster di failover) con capacità di archiviazione collegata diretta sufficiente.

Importante

Non configurare ancora Sincronizzazione file di Azure. La distribuzione di Sincronizzazione file di Azure non deve essere avviata prima della fase 4 di una migrazione.

Riepilogo della fase 2

Alla fine della fase 2, saranno stati distribuiti gli account di archiviazione e tutte le condivisioni file di Azure. Si avrà anche una risorsa di StorSimple Data Manager. Questi ultimi verranno usati nella fase 3 quando si configurano i processi di migrazione.

Fase 3: Creare ed eseguire un processo di migrazione

Questa sezione descrive come configurare un processo di migrazione ed eseguire il mapping delle directory in un volume StorSimple che deve essere copiato nella condivisione file di Azure di destinazione selezionata.

Questo video illustra quanto segue:

• Creazione di un processo di migrazione
• Riepilogo
• Origine
• Selezione dei backup dei volumi di cui eseguire la migrazione
• Destinazione
• Mapping delle directory
• Regole semantiche
• Esecuzione di un processo di migrazione
• Eseguire la definizione del processo
• Visualizzazione dello stato del processo
• Esecuzione di processi in parallelo
• Interpretazione dei file di log

Per iniziare, passare a StorSimple Data Manager, trovare Definizioni di processo nel menu e selezionare + Definizione processo. Il tipo di archiviazione di destinazione corretto è il valore predefinito: Condivisione file di Azure.

Nome definizione processo
Questo nome deve indicare il set di file da spostare. Assegnargli un nome simile a quello della condivisione file di Azure è una procedura consigliata.

Posizione in cui viene eseguito il processo
Quando si seleziona un'area, è necessario selezionare la stessa area dell'account di archiviazione StorSimple o, se non è disponibile, un'area vicina.

Origine

Sottoscrizione di origine
Selezionare la sottoscrizione in cui archiviare la risorsa Gestione dispositivi StorSimple.

Risorsa StorSimple
Selezionare Gestione dispositivi StorSimple con cui è registrata l'appliance.

Chiave di crittografia dei dati del servizio
Controllare questa sezione precedente in questo articolo nel caso in cui non sia possibile individuare la chiave nei record.

Dispositivo
Selezionare il dispositivo StorSimple che contiene il volume di cui si vuole eseguire la migrazione.

Volume
Selezionare il volume di origine. Successivamente si deciderà se eseguire la migrazione dell'intero volume o delle sottodirectory nella condivisione file di Azure di destinazione.

Backup del volume
È possibile Selezionare i backup del volume per scegliere backup specifici da spostare come parte di questo processo. Una prossima sezione dedicata di questo articolo illustra in dettaglio il processo.

Destinazione

Selezionare la sottoscrizione, l'account di archiviazione e la condivisione file di Azure come destinazione di questo processo di migrazione.

Mapping delle directory

Una sezione dedicata in questo articolo illustra tutti i dettagli pertinenti.

Selezione dei backup dei volumi di cui eseguire la migrazione

Esistono aspetti importanti relativi alla scelta dei backup di cui è necessario eseguire la migrazione:

• I processi di migrazione possono spostare solo i backup, non i dati del volume attivo. Il backup più recente è quindi più vicino ai dati in tempo reale e deve sempre trovarsi nell'elenco dei backup spostati in una migrazione. Quando si apre la finestra di dialogo Selezione backup, è selezionato per impostazione predefinita.
• Assicurarsi che il backup più vicino sia recente per mantenere il delta della condivisione live il più piccolo possibile. Potrebbe essere opportuno attivare e completare manualmente un altro backup del volume prima di creare un processo di migrazione. Un piccolo delta per la condivisione live migliora l'esperienza di migrazione. Se questo delta può essere zero, vale a dire che non sono state apportate altre modifiche al volume StorSimple dopo l'esecuzione del backup più recente nell'elenco, il cut-over dell'utente sarà drasticamente semplificato e velocizzato.
• I backup devono essere riprodotti nella condivisione file di Azure dal meno recente al più recente. Un backup meno recente non può essere "ordinato" nell'elenco dei backup nella condivisione file di Azure dopo l'esecuzione di un processo di migrazione. È pertanto necessario assicurarsi che l'elenco di backup sia completo prima di creare un processo.
• Questo elenco di backup in un processo non può essere modificato dopo la creazione del processo, anche se il processo non è mai stato eseguito.
• Per selezionare i backup, il volume StorSimple di cui si vuole eseguire la migrazione deve essere online.

Per selezionare i backup del volume StorSimple per il processo di migrazione, scegliere Selezionare i backup del volume nel modulo di creazione del processo.

Quando si apre il pannello di selezione del backup, viene separato in due elenchi. Nel primo elenco vengono visualizzati tutti i backup disponibili. È possibile espandere e restringere il set di risultati filtrando per un intervallo di tempo specifico. (vedere la sezione successiva)

Un backup selezionato verrà visualizzato come disattivato e aggiunto a un secondo elenco nella metà inferiore del pannello. Il secondo elenco visualizza tutti i backup selezionati per la migrazione. È anche possibile rimuovere nuovamente un backup selezionato per errore.

Attenzione

È necessario selezionare tutti i backup di cui si vuole eseguire la migrazione. Non è possibile aggiungere backup meno recenti in un secondo momento. Non è possibile modificare il processo per modificare la selezione dopo la creazione del processo.

Per impostazione predefinita, l'elenco viene filtrato per visualizzare i backup del volume StorSimple negli ultimi sette giorni. Il backup più recente è selezionato per impostazione predefinita, anche se non è stato eseguito negli ultimi sette giorni. Per i backup meno recenti, usare il filtro intervallo di tempo nella parte superiore del pannello. È possibile selezionare un filtro esistente o impostare un intervallo di tempo personalizzato per filtrare solo i backup eseguiti durante questo periodo.

Attenzione

La selezione di più di 50 backup del volume StorSimple non è supportata. I processi con un numero elevato di backup potrebbero non riuscire. Assicurarsi che i criteri di conservazione dei backup non eliminino un backup selezionato prima di poter eseguire la migrazione.

Mapping delle directory

Il mapping delle directory è facoltativo per il processo di migrazione. Se si lascia vuota la sezione, tutti i file e le cartelle nella radice del volume StorSimple verranno spostati nella radice della condivisione file di Azure di destinazione. Nella maggior parte dei casi, l'archiviazione del contenuto di un intero volume in una condivisione file di Azure non è l'approccio migliore. Spesso è preferibile suddividere il contenuto di un volume tra più condivisioni file in Azure. Se non è già stato creato un piano, vedere prima Eseguire il mapping del volume StorSimple alle condivisioni file di Azure.

Come parte del piano di migrazione, si potrebbe aver deciso che le cartelle in un volume StorSimple devono essere suddivise tra più condivisioni file di Azure. In questo caso, è possibile eseguire questa suddivisione:

1. Definendo più processi per eseguire la migrazione delle cartelle in un unico volume. Ognuno avrà la stessa origine del volume StorSimple, ma una condivisione file di Azure diversa come destinazione.
2. Specificando con precisione le cartelle del volume StorSimple di cui è necessario eseguire la migrazione nella condivisione file specificata usando la sezione Mapping delle directory del modulo di creazione del processo e seguendo la semantica di mapping specifica.

Importante

I percorsi e le espressioni di mapping in questo modulo non possono essere convalidati quando il modulo viene inviato. Se i mapping vengono specificati in modo non corretto, un processo potrebbe non riuscire completamente o produrre un risultato indesiderato. In questo caso, in genere è consigliabile eliminare la condivisione file di Azure, ricrearla e quindi correggere le istruzioni di mapping in un nuovo processo di migrazione per la condivisione. L'esecuzione di un nuovo processo con istruzioni di mapping fisse può correggere le cartelle omesse e inserirle nella condivisione esistente. Tuttavia, solo le cartelle omesse a causa di errori di ortografia del percorso possono essere risolte in questo modo.

Elementi semantici

Un mapping viene espresso da sinistra a destra: [\percorso di origine] > [\percorso di destinazione].

Carattere semantico	Significato
\	Indicatore del livello radice.
>	Operatore [origine] e [target-mapping].
| o RETURN (nuova riga)	Separatore di due istruzioni di mapping delle cartelle. In alternativa, è possibile omettere questo carattere e selezionare INVIO per ottenere l'espressione di mapping successiva sulla propria riga.

Esempi

Sposta il contenuto della cartella Dati utente nella radice della condivisione file di destinazione:

\User data > \

Sposta l'intero contenuto del volume in un nuovo percorso nella condivisione file di destinazione:

\ > \Apps\HR tracker

Sposta il contenuto della cartella di origine in un nuovo percorso nella condivisione file di destinazione:

\HR resumes-Backup > \Backups\HR\resumes

Ordina più percorsi di origine in una nuova struttura di directory:

\HR\Candidate Tracker\v1.0 > \Apps\Candidate tracker
\HR\Candidates\Resumes > \HR\Candidates\New
\Archive\HR\Old Resumes > \HR\Candidates\Archived

Regole semantiche

• Specificare sempre i percorsi di cartella relativi al livello radice.
• Iniziare ogni percorso della cartella con un indicatore di livello radice "\".
• Non includere lettere di unità.
• Quando si specificano più percorsi, i percorsi di origine o di destinazione non possono sovrapporsi:
  esempio di sovrapposizione percorso di origine non valido:
  \cartella\1 > \cartella
  \cartella\1\2 > \cartella2
  Esempio di sovrapposizione percorso di destinazione non valido:
  \cartella > \
  \cartella2 > \
  
• Le cartelle di origine che non esistono vengono ignorate.
• Vengono create strutture di cartelle che non esistono nella destinazione.
• Come Windows, i nomi delle cartelle non fanno distinzione tra maiuscole e minuscole, ma le conservano.

Nota

Il contenuto della cartella \System Volume Information e $Recycle.Bin nel volume StorSimple non verranno copiati dal processo di migrazione.

Eseguire un processo di migrazione

I processi di migrazione sono elencati in Definizioni di processo nella risorsa di Data Manager distribuita in un gruppo di risorse. Nell'elenco delle definizioni di processo selezionare il processo da eseguire.

Nel pannello del processo visualizzato è possibile visualizzare lo stato corrente del processo e un elenco di backup selezionati. L'elenco dei backup viene ordinato in base al meno recente e verrà eseguita la migrazione alla condivisione file di Azure in questo ordine.

Inizialmente, il processo di migrazione avrà lo stato: Mai eseguito.
Quando si è pronti, avviare il processo di migrazione. Selezionare l'immagine per una versione con una risoluzione superiore.
Quando viene eseguita correttamente la migrazione di un backup, verrà creato uno snapshot automatico della condivisione file di Azure. La data di backup originale del backup di StorSimple viene inserita nella sezione Commenti dello snapshot della condivisione file di Azure. L'utilizzo di questo campo consente di visualizzare quando è stato originariamente eseguito il backup dei dati rispetto al momento in cui è stato creato lo snapshot della condivisione file.

Attenzione

I backup devono essere elaborati dal meno recente al più recente. Dopo aver creato un processo di migrazione, non è possibile modificare l'elenco dei backup del volume StorSimple selezionati. Non avviare il processo se l'elenco di backup non è corretto o incompleto. Eliminare il processo e crearne uno nuovo con i backup corretti selezionati. Per ogni backup selezionato, controllare le pianificazioni di conservazione. I backup potrebbero essere eliminati da uno o più criteri di conservazione prima di poter eseguire la migrazione.

Errori per elemento

I processi di migrazione hanno due colonne nell'elenco dei backup che elencano eventuali problemi che potrebbero essersi verificati durante la copia:

• Errori di copia
  Questa colonna elenca i file o le cartelle che devono essere stati copiati ma non sono stati copiati. Questi errori sono spesso recuperabili. Quando un backup elenca i problemi relativi agli elementi in questa colonna, esaminare i log di copia. Se è necessario eseguire la migrazione di questi file, selezionare Ripeti backup. Questa opzione diventa disponibile al termine dell'elaborazione del backup. La sezione Gestione di un processo di migrazione illustra in modo più dettagliato le opzioni disponibili.
• File non supportati
  Questa colonna elenca file o cartelle di cui non è possibile eseguire la migrazione. Archiviazione di Azure presenta limitazioni nei nomi di file, nelle lunghezze del percorso e nei tipi di file che attualmente o logicamente non possono essere archiviati in una condivisione file di Azure. Un processo di migrazione non verrà sospeso per questi tipi di errori. Il nuovo tentativo di migrazione del backup non modifica il risultato. Quando un backup elenca i problemi relativi agli elementi in questa colonna, esaminare i log di copia e prendere nota. Se tali problemi si verificano nell'ultimo backup e si è rilevato nel log di copia che l'errore è dovuto a un nome file, alla lunghezza del percorso o a un altro problema che si è verificato, è possibile risolvere il problema nel volume StorSimple attivo, eseguire un backup del volume StorSimple e creare un nuovo processo di migrazione con solo tale backup. È quindi possibile eseguire la migrazione di questo spazio dei nomi risolto, che diventerà la versione più recente/dinamica della condivisione file di Azure. Si tratta di un processo manuale e dispendioso in termini di tempo. Esaminare attentamente i log di copia e valutare se ne vale la pena.

Questi log di copia sono file *.csv che elencano gli elementi dello spazio dei nomi riusciti e gli elementi che non sono stati copiati. Gli errori vengono suddivisi ulteriormente nelle categorie descritte in precedenza. Dal percorso del file di log è possibile trovare i log per i file non riusciti cercando "failed". Il risultato deve essere un set di log per i file che non sono stati copiati. Ordinare questi log in base alle dimensioni. Potrebbero essere presenti log aggiuntivi di dimensioni pari a 17 byte. Questi sono vuoti e possono essere ignorati. Con un ordinamento, è possibile concentrarsi sui log con il contenuto.

Lo stesso processo si applica per i file di log che registrano copie riuscite.

Gestire un processo di migrazione

I processi di migrazione hanno gli stati seguenti:

• Mai eseguito
  Un nuovo processo definito ma mai eseguito.
• In attesa
  Un processo in questo stato è in attesa del provisioning delle risorse nel servizio di migrazione. Passa automaticamente a uno stato diverso quando è pronto.
• Non riuscito
  Un processo non riuscito ha generato un errore irreversibile che impedisce l'elaborazione di più backup. Non è previsto che un processo entri in questo stato. Una richiesta di supporto è il miglior corso d'azione.
• Annullato / Annullamento in corso
  Processo di migrazione completo o singoli backup all'interno del processo possono essere annullati. I backup annullati non verranno elaborati perché un processo di migrazione annullato interromperà l'elaborazione dei backup. Ricordare che l'annullamento di un processo richiederà molto tempo. Ciò non impedisce di creare un nuovo processo. L'azione migliore consiste nel consentire a un processo di raggiungere lo stato Annullato. È possibile ignorare i processi non riusciti o annullati o eliminarli in un secondo momento. Non è necessario eliminare i processi prima di poter eliminare la risorsa di Data Manager alla fine della migrazione di StorSimple.

In esecuzione

Un processo in esecuzione sta attualmente elaborando un backup. Fare riferimento alla tabella nella metà inferiore del pannello per vedere quale backup è in corso di elaborazione e quali potrebbero essere già stati migrati.
I backup già migrati hanno una colonna con un collegamento a un log di copia. Se un backup segnala errori, è consigliabile esaminarne il log di copia.

Sospeso

Un processo di migrazione viene sospeso quando è necessaria una decisione. Questa condizione abilita due pulsanti di comando nella parte superiore del pannello:
Scegliere Ritenta backup quando il backup mostra i file che avrebbero dovuto essere spostati ma non lo sono stati (colonna Errore copia).
Scegliere Ignora backup quando manca il backup (eliminato dal criterio dopo aver creato il processo di migrazione) o quando il backup è danneggiato. È possibile trovare informazioni dettagliate sull'errore nel pannello visualizzato quando si fa clic sul backup non riuscito.

Quando si ignora o ritenta il backup corrente, il servizio di migrazione creerà un nuovo snapshot nella condivisione file di Azure di destinazione. Potrebbe essere necessario eliminare quello precedente in un secondo momento, perché è probabile che sia incompleto.

Completo e Completo con avvisi

Un processo di migrazione è elencato come Completo quando tutti i backup del processo sono stati elaborati correttamente.
Completo con avvisi è uno stato che si verifica quando:

• Si è verificato un problema ripristinabile. Questo backup viene contrassegnato come avente esito positivo parziale o non riuscito.
• Si è deciso di continuare con il processo sospeso ignorando il backup con i problemi. (Si è scelto Ignora backup anziché Ritenta backup)

Se il processo di migrazione viene completato con avvisi, è consigliabile esaminare sempre il log di copia per i backup pertinenti.

Eseguire processi in parallelo

Probabilmente si avranno più volumi StorSimple, ognuno con le proprie condivisioni di cui è necessario eseguire la migrazione a una condivisione file di Azure. È importante comprendere quanto è possibile fare in parallelo. Esistono limitazioni che non vengono applicate nell'esperienza utente e degraderanno o inibiranno una migrazione completa se i processi vengono eseguiti contemporaneamente.

Non esistono limiti per la definizione dei processi di migrazione. È possibile definire lo stesso volume di origine StorSimple, la stessa condivisione file di Azure, tra le stesse appliance StorSimple o diverse. Tuttavia, l'esecuzione presenta limitazioni:

• È possibile eseguire contemporaneamente un solo processo di migrazione con lo stesso volume di origine StorSimple.
• È possibile eseguire contemporaneamente un solo processo di migrazione con la stessa condivisione file di Azure di destinazione.
• Prima di avviare il processo successivo, assicurarsi che uno dei processi precedenti si trovi in copy stage e mostri lo stato di avanzamento dello spostamento dei file per almeno 30 minuti.
• È possibile eseguire fino a quattro processi di migrazione in parallelo per gestione dispositivi StorSimple, purché si rispettino le regole precedenti.

Quando si tenta di avviare un processo di migrazione, vengono controllate le regole precedenti. Se sono in esecuzione processi, potrebbe non essere possibile avviare un nuovo processo. Verrà visualizzato un avviso che elenca il nome dei processi attualmente in esecuzione che devono essere completati prima di poter avviare il nuovo processo.

Suggerimento

È consigliabile controllare regolarmente i processi di migrazione nella scheda Definizione processo della risorsa di Data Manager per verificare se uno di essi è stato sospeso ed è necessario completare l'input.

Riepilogo della fase 3

Alla fine della fase 3, si eseguirà almeno uno dei processi di migrazione dai volumi StorSimple alle condivisioni file di Azure. Con l'esecuzione è stata eseguita la migrazione dei backup specificati in snapshot di condivisione file di Azure. È ora possibile concentrarsi sulla configurazione di Sincronizzazione file di Azure per la condivisione (una volta completati i processi di migrazione per una condivisione) o l'accesso diretto alla condivisione file per gli information worker e le app nella condivisione file di Azure.

Fase 4: Accedere alle condivisioni file di Azure

Esistono due strategie principali per accedere alle condivisioni file di Azure:

• Sincronizzazione file di Azure: distribuire sincronizzazione file di Azure in un'istanza locale di Windows Server. Sincronizzazione file di Azure offre tutti i vantaggi di una cache locale, proprio come StorSimple.
• Accesso diretto alla condivisione: Distribuire l'accesso diretto alla condivisione. Usare questa strategia se lo scenario di accesso per una determinata condivisione file di Azure non trarrà vantaggio dalla memorizzazione nella cache locale o se non si ha più la possibilità di ospitare un'istanza di Windows Server locale. In questo caso, gli utenti e le app continueranno ad accedere alle condivisioni SMB tramite il protocollo SMB. Queste condivisioni non si trovano più in un server locale, ma direttamente nel cloud.

È necessario aver già deciso quale opzione è migliore nella Fase 1 di questa guida.

La parte restante di questa sezione è incentrata sulle istruzioni di distribuzione.

Questo video illustra quanto segue:

• Approcci per accedere alle condivisioni file di Azure
• Sincronizzazione file di Azure
• Accesso diretto alla condivisione
• Distribuzione di Sincronizzazione file di Azure
• Distribuire la risorsa cloud di Sincronizzazione file di Azure
• Distribuire un'istanza di Windows Server locale
• Preparazione dell'istanza di Windows Server per Sincronizzazione file di Azure
• Configurazione di Sincronizzazione file di Azure nell'istanza di Windows Server
• Monitoraggio della sincronizzazione iniziale
• Test di Sincronizzazione file di Azure
• Creazione delle condivisioni SMB

Come distribuire Sincronizzazione file di Azure

È il momento di distribuire una parte di Sincronizzazione file di Azure.

1. Creare la risorsa cloud Sincronizzazione file di Azure.
2. Distribuire l'agente Sincronizzazione file di Azure nel server locale.
3. Registrare il server con la risorsa cloud.

Non creare ancora gruppi di sincronizzazione. La configurazione della sincronizzazione con una condivisione file di Azure deve avvenire solo dopo il completamento dei processi di migrazione in una condivisione file di Azure. Se si inizia a usare Sincronizzazione file di Azure prima del completamento della migrazione, la migrazione risulterà inutilmente difficile perché non sarà possibile indicare facilmente quando era il momento di avviare un cut-over.

Distribuire la risorsa cloud di Sincronizzazione file di Azure

Per completare questo passaggio, sono necessarie le credenziali della sottoscrizione di Azure.

La risorsa principale da configurare per Sincronizzazione file di Azure è denominata Servizio di sincronizzazione archiviazione. È consigliabile una sola distribuzione per tutti i server che sincronizzano lo stesso set di file ora o in futuro. Creare più servizi di sincronizzazione archiviazione solo se esistono set distinti di server che non devono mai scambiare dati. Ad esempio, potrebbero esistere server che non devono mai sincronizzare la stessa condivisione file di Azure. In caso contrario, l'uso di un singolo Servizio di sincronizzazione archiviazione è la procedura consigliata.

Scegliere un'area di Azure per il Servizio di sincronizzazione archiviazione vicino alla propria località. Tutte le altre risorse cloud devono essere distribuite nella stessa area. Per semplificare la gestione, creare un nuovo gruppo di risorse nella sottoscrizione che ospita risorse di sincronizzazione e archiviazione.

Per altre informazioni, vedere la sezione sulla distribuzione del Servizio di sincronizzazione archiviazione nell'articolo sulla distribuzione di Sincronizzazione file di Azure. Seguire solo questa sezione dell'articolo. Nei passaggi successivi saranno disponibili collegamenti ad altre sezioni dell'articolo.

Suggerimento

Per modificare l'area di Azure in cui si trovano i dati al termine della migrazione, distribuire il servizio di sincronizzazione archiviazione nella stessa area degli account di archiviazione di destinazione per questa migrazione.

Distribuire un'istanza di Windows Server locale

• Creare Windows Server 2019 (almeno 2012R2) come macchina virtuale o server fisico. È supportato anche un cluster di failover di Windows Server. Non riutilizzare il server front-end di StorSimple 8100 o 8600.
• Effettuare il provisioning o aggiungere l'archiviazione collegata diretta. L'archiviazione collegata alla rete non è supportata.

È consigliabile assegnare alla nuova istanza di Windows Server una quantità di spazio di archiviazione uguale o superiore rispetto all'appliance StorSimple 8100 o 8600 disponibile localmente per la memorizzazione nella cache. Si userà l'istanza di Windows Server nello stesso modo in cui è stata usata l'appliance StorSimple. Se ha la stessa quantità di spazio di archiviazione dell'appliance, l'esperienza di memorizzazione nella cache dovrebbe essere simile, se non uguale. È possibile aggiungere o rimuovere spazio di archiviazione dall'istanza di Windows Server. Questa funzionalità consente di ridimensionare le dimensioni del volume locale e la quantità di spazio di archiviazione locale disponibile per la memorizzazione nella cache.

Preparare l'istanza di Windows Server per la sincronizzazione file

In questa sezione viene installato l'agente di Sincronizzazione file di Azure nell'istanza di Windows Server.

La guida alla distribuzione spiega che è necessario disattivare Configurazione sicurezza avanzata di Internet Explorer. Questa misura di sicurezza non è applicabile con Sincronizzazione file di Azure. La disattivazione consente di eseguire l'autenticazione in Azure senza problemi.

Aprire PowerShell. Installare i moduli PowerShell necessari usando i comandi seguenti. Accertarsi di installare il modulo completo e il provider NuGet quando viene chiesto.

Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync

Se si verificano problemi durante il raggiungimento di Internet dal server, è il momento di risolverli. Sincronizzazione file di Azure usa qualunque connessione di rete disponibile a Internet. È supportata anche la richiesta di un server proxy per raggiungere Internet. È possibile configurare ora un proxy a livello di computer o, durante l'installazione dell'agente, specificare un proxy che verrà usato solo da Sincronizzazione file di Azure.

Se la configurazione un proxy implica la necessità di aprire i firewall per il server, questo approccio potrebbe essere accettabile per l'utente. Al termine dell'installazione del server, dopo aver completato la registrazione del server, un report di connettività di rete mostrerà gli URL degli endpoint esatti in Azure con cui Sincronizzazione file di Azure deve comunicare per l'area selezionata. Il report indica anche perché è necessaria la comunicazione. È possibile usare il report per bloccare i firewall intorno al server a URL specifici.

È anche possibile adottare un approccio più conservativo in cui non si aprono i firewall. È possibile, invece, limitare il server a comunicare con spazi dei nomi DNS di livello superiore. Per altre informazioni, vedere Impostazioni di proxy e firewall di Sincronizzazione file di Azure. Seguire le procedure di rete consigliate.

Al termine dell'installazione guidata del server, verrà aperta una procedura guidata di registrazione del server. Registrare il server nella risorsa di Azure del servizio di sincronizzazione archiviazione precedente.

Questi passaggi sono descritti in modo più dettagliato nella guida alla distribuzione, che include i moduli di PowerShell da installare per primi: Installazione dell'agente di Sincronizzazione file di Azure.

Usare l'agente più recente. È possibile scaricarlo dall'Area download MicrosoftAgente di Sincronizzazione file di Azure.

Dopo aver completato correttamente l'installazione e la registrazione del server, è possibile controllare se questo passaggio è stato completato correttamente. Passare alla risorsa del Servizio di sincronizzazione archiviazione nel portale di Azure. Nel menu a sinistra, passare a Server registrati. Verrà visualizzato l'elenco del server.

Configurare Sincronizzazione file di Azure nell'istanza di Windows Server

Per questo processo, l'istanza di Windows Server locale registrata deve essere pronta e connessa a Internet.

Importante

Prima di procedere, è necessario completare la migrazione di file e cartelle StorSimple nella condivisione file di Azure. Assicurarsi che non siano state apportate altre modifiche alla condivisione file.

Questo passaggio collega tutte le risorse e le cartelle configurate nell'istanza di Windows Server durante i passaggi precedenti.

1. Accedere al portale di Azure.
2. Individuare la risorsa del Servizio di sincronizzazione archiviazione.
3. Creare un nuovo gruppo di sincronizzazione all'interno della risorsa del Servizio di sincronizzazione archiviazione per ogni condivisione file di Azure. Nella terminologia di Sincronizzazione file di Azure, la condivisione file di Azure diventerà un endpoint cloud nella topologia di sincronizzazione che si sta descrivendo con la creazione di un gruppo di sincronizzazione. Quando si crea il gruppo di sincronizzazione, assegnargli un nome familiare in modo da riconoscere il set di file sincronizzato. Accertarsi di fare riferimento alla condivisione file di Azure con un nome corrispondente.
4. Dopo aver creato il gruppo di sincronizzazione, verrà visualizzata una riga nell'elenco dei gruppi di sincronizzazione. Selezionare il nome (un collegamento) per visualizzare il contenuto del gruppo di sincronizzazione. La condivisione file di Azure verrà visualizzata in Endpoint cloud.
5. Individuare il pulsante Aggiungi endpoint server. La cartella nel server locale di cui è stato effettuato il provisioning diventerà il percorso per questo endpoint server.

Importante

Assicurarsi di attivare la suddivisione in livelli nel cloud. Il cloud a livello è la funzionalità di Sincronizzazione file di Azure che consente al server locale di avere una capacità di archiviazione inferiore a quella archiviata nel cloud, ma ha lo spazio dei nomi completo disponibile. I dati interessanti localmente vengono memorizzati nella cache anche in locale per ottenere prestazioni veloci. Un altro motivo per attivare la suddivisione in livelli nel cloud in questo passaggio è che non si vuole sincronizzare il contenuto dei file in questa fase. Solo lo spazio dei nomi deve essere spostato in questo momento.

Distribuire l'accesso diretto alla condivisione

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 per Azure AD.

• Panoramica delle identità
• Come aggiunta a un dominio un account di archiviazione
• Panoramica della rete per le condivisioni file di Azure
• Come configurare gli endpoint pubblici e privati
• Come configurare una VPN da sito a sito
• Come configurare una VPN da punto a sito Windows
• Come configurare una VPN da punto a sito Linux
• Come configurare l'inoltro DNS
• Configurare DFS-N

Riepilogo della fase 4

Al termine di questa fase, sono stati creati ed eseguiti più processi di migrazione in StorSimple Data Manager. Tali processi hanno eseguito la migrazione di file e cartelle e dei relativi backup nelle condivisioni file di Azure. Sincronizzazione file di Azure è stata distribuita o sono stati preparati gli account di rete e archiviazione per l'accesso diretto alla condivisione.

Fase 5: Cutover utente

In questa fase si completerà la migrazione:

• Pianificare il tempo di inattività.
• È possibile recuperare le modifiche apportate agli utenti e alle app prodotte sul lato StorSimple mentre i processi di migrazione nella fase 3 sono stati eseguiti.
• Eseguire il failover degli utenti nella nuova istanza di Windows Server con Sincronizzazione file di Azure o nelle condivisioni file di Azure tramite accesso diretto alla condivisione.

Questo video illustra quanto segue:

• Passaggi da eseguire prima del cutover del carico di lavoro
• Esecuzione del cutover
• Passaggi successivi al cutover

Pianificare il tempo di inattività

Questo approccio alla migrazione richiede tempi di inattività per gli utenti e le app. L'obiettivo è mantenere il tempo di inattività minimo. Le considerazioni seguenti possono essere utili:

• Mantenere disponibili i volumi StorSimple durante l'esecuzione dei processi di migrazione.
• Al termine dell'esecuzione dei processi di migrazione dei dati per una condivisione, è possibile rimuovere l'accesso utente (almeno l'accesso in scrittura) dai volumi o dalle condivisioni StorSimple. Un'istanza di RoboCopy finale recupera la condivisione file di Azure. È quindi possibile eseguire il cutover degli utenti. La posizione in cui si esegue RoboCopy dipende dal fatto che si sia scelto di usare Sincronizzazione file di Azure o l'accesso diretto alla condivisione. La sezione successiva illustra l'argomento.
• Dopo aver completato il recupero di RoboCopy, si è pronti per esporre la nuova posizione agli utenti tramite la condivisione file di Azure direttamente o una condivisione SMB in un'istanza di Windows Server con Sincronizzazione file di Azure. Spesso una distribuzione DFS-N consentirà di eseguire un cutover in modo rapido ed efficiente. Manterrà gli indirizzi di condivisione esistenti coerenti e riporterà a un nuovo percorso contenente i file e le cartelle migrati.

Per i dati di archiviazione, è un approccio completamente funzionante per richiedere tempi di inattività nel volume (o nella sottocartella) di StorSimple, eseguire un altro backup del volume StorSimple, eseguire la migrazione e quindi aprire la destinazione della migrazione per l'accesso da parte di utenti e app. In questo modo si evita la necessità di un recupero RoboCopy. Tuttavia, questo approccio comporta una finestra di inattività prolungata che potrebbe estendersi a diversi giorni o più a seconda del numero di file e backup di cui è necessario eseguire la migrazione. Questa è probabilmente solo un'opzione possibile per i carichi di lavoro di archiviazione che possono eseguire senza accesso in scrittura per periodi di tempo prolungati.

Determinare quando lo spazio dei nomi è completamente sincronizzato con il server

Quando si usa Sincronizzazione file di Azure per una condivisione file di Azure, è importante determinare che l'intero spazio dei nomi ha terminato il download nel server prima di avviare un'istanza di RoboCopy locale. Il tempo necessario per scaricare lo spazio dei nomi dipende dal numero di elementi nella condivisione file di Azure. Esistono due metodi per determinare se lo spazio dei nomi è completamente arrivato nel server.

Azure portal

È possibile usare il portale di Azure per vedere quando lo spazio dei nomi è arrivato completamente.

• Accedere al portale di Azure e passare al gruppo di sincronizzazione. Controllare lo stato di sincronizzazione del gruppo di sincronizzazione e dell'endpoint server.
• La direzione interessante è il download. Se viene appena effettuato il provisioning dell'endpoint server, verrà visualizzato Sincronizzazione iniziale, che indica che lo spazio dei nomi è ancora inattivo. Dopo che lo stato passa a qualsiasi voce diversa da Sincronizzazione iniziale, lo spazio dei nomi verrà popolato completamente nel server.

È ora possibile procedere con un RoboCopy locale.

Visualizzatore eventi di Windows Server

È anche possibile usare il Visualizzatore eventi nell'istanza di Windows Server per indicare quando lo spazio dei nomi è completamente arrivato.

1. Aprire il Visualizzatore eventi e passare ad Applicazioni e servizi.
2. Individuare e aprire Microsoft\FileSync\Agent\Telemetry.
3. Cercare l'evento 9102 più recente, che corrisponde a una sessione di sincronizzazione completata.
4. Selezionare Dettaglie verificare che si stia esaminando un evento in cui il valore SyncDirection sia Download.
5. Per il momento in cui lo spazio dei nomi ha completato il download nel server, verrà visualizzato un singolo evento con Scenario, il valore FullGhostedSynce HResult = 0.
6. Se si perde questo evento, è anche possibile cercare altri eventi 9102 con SyncDirection = Download e Scenario = "RegularSync". La ricerca di uno di questi eventi indica anche che lo spazio dei nomi ha terminato il download e la sincronizzazione è stato eseguito fino alle normali sessioni di sincronizzazione, indipendentemente dal fatto che sia presente qualcosa da sincronizzare o meno in questo momento.

Un RoboCopy finale

A questo punto, esistono differenze tra l'istanza di Windows Server locale e l'appliance StorSimple 8100 o 8600.

1. È necessario recuperare le modifiche che gli utenti o le app hanno prodotto sul lato StorSimple durante la migrazione erano in corso.
2. Per i casi in cui si usa Sincronizzazione file di Azure: l'appliance StorSimple ha una cache popolata rispetto all'istanza di Windows Server con solo uno spazio dei nomi senza contenuto di file archiviato localmente in questo momento. L'ultima RoboCopy consente di avviare rapidamente la cache locale di Sincronizzazione file di Azure eseguendo il pull sul contenuto dei file memorizzato nella cache locale, così come è disponibile e può essere inserito nel server sincronizzazione file di Azure.
3. Alcuni file potrebbero essere stati lasciati indietro dal processo di migrazione a causa di caratteri non validi. In tal caso, copiarli nell'istanza di Windows Server abilitata per Sincronizzazione file di Azure. Successivamente, è possibile modificarli in modo che vengano sincronizzati. Se non si usa Sincronizzazione file di Azure per una determinata condivisione, è preferibile rinominare i file con caratteri non validi nel volume StorSimple. Eseguire quindi RoboCopy direttamente nella condivisione file di Azure.

Avviso

Robocopy in Windows Server 2019 ha riscontrato un problema che causava la nuova copia a livelli dei file di Sincronizzazione file di Azure nel server di destinazione dall'origine e il nuovo upload in Azure quando si usa la funzione /MIR. È consigliabile eseguire Robocopy in Windows Server diverso da 2019, ad esempio Windows Server 2016.

Avviso

Non avviare RoboCopy prima che il server disponga dello spazio dei nomi per una condivisione file di Azure scaricata completamente. Per altre informazioni, vedere Determinare quando lo spazio dei nomi è stato scaricato completamente nel server.

Si vogliono copiare solo i file modificati dopo l'ultima esecuzione del processo di migrazione e i file che non sono stati spostati in questi processi in precedenza. È possibile risolvere il problema relativo al motivo per cui non sono stati spostati in un secondo momento nel server, dopo il completamento della migrazione. Per altre informazioni, vedere Risoluzione dei problemi di Sincronizzazione file di Azure.

RoboCopy ha diversi parametri. Nell'esempio seguente viene illustrato un comando completato e un elenco di motivi per la scelta di questi parametri.

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. 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 si usa Robocopy per File di Azure, accertarsi di montare le condivisioni file di Azure usando la chiave di accesso dell'account di archiviazione e non usare 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 causerà 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 = NTFS ACL, O= Informazioni sul proprietario, U= 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. La copia di queste informazioni non sarà utile nel cloud o quando i dati vengono copiati in un altro volume di Windows. Lasciare questo contenuto dietro non deve essere considerato come 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 usato con /TEE per l'output della console. Potrebbe essere necessario rimuovere i flag dello script di esempio, come /NP, /NFL e /NDL, per ottenere risultati di test correttamente documentati.
/LFSM	Solo per le destinazioni con archiviazione a livelli. Non supportato quando la destinazione è una condivisione SMB remota. Specifica che Robocopy opera in "modalità spazio disponibile insufficiente". Questa operazione è utile solo per le destinazioni con archiviazione a livelli che potrebbero esaurire la capacità locale prima del completamento di Robocopy. È stata aggiunta appositamente per l'uso con una destinazione abilitata per cloud a livelli di Sincronizzazione file di Azure. Può essere usata indipendentemente da Sincronizzazione file di Azure. In questa modalità Robocopy viene sospeso ogni volta che lo spazio libero del volume di destinazione scende al di sotto di un valore minimo a causa di una copia del file. Questo valore può essere specificato dalla forma /LFSM:n del flag. Il parametro n è specificato in base 2: nKB, nMB o nGB. Se /LFSM viene specificato senza un valore di limite minimo esplicito, il limite minimo viene impostato sul 10% delle dimensioni del volume di destinazione. La modalità spazio libero insufficiente non è compatibile con /MT, /EFSRAW o /ZB. Il supporto per /B è stato aggiunto in Windows Server 2022. Vedere la sezione Windows Server 2022 e RoboCopy LFSM di seguito per altre informazioni, incluse informazioni dettagliate su un bug e una soluzione alternativa correlati.
/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

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

Quando si configurano le posizioni di origine e di destinazione del comando RoboCopy, assicurarsi di esaminare la struttura dell'origine e della destinazione per assicurarsi che corrispondano. Se è stata usata la funzionalità di mapping della directory del processo di migrazione, la struttura della directory radice potrebbe essere diversa dalla struttura del volume StorSimple. In questo caso, potrebbero essere necessari più processi RoboCopy, uno per ogni sottodirectory. Se non si è certi che il comando venga eseguito come previsto, è possibile usare il parametro /L, che simula il comando senza apportare effettivamente alcuna modifica.

Questo comando RoboCopy usa /MIR, quindi non sposta i file uguali (ad esempio file a livelli). Tuttavia, se si verifica un errore nel percorso di origine e di destinazione, /MIR elimina anche le strutture di directory nell'istanza di Windows Server o nella condivisione file di Azure che non sono presenti nel percorso di origine StorSimple. Devono corrispondere esattamente al processo RoboCopy per raggiungere l'obiettivo previsto di aggiornare il contenuto migrato con le modifiche più recenti apportate durante la migrazione.

Consultare il file di log RoboCopy per verificare se i file sono stati lasciati indietro. In caso di problemi, correggerli ed eseguire di nuovo il comando RoboCopy. Non effettuare il deprovisioning delle risorse StorSimple prima di risolvere i problemi in sospeso per i file o le cartelle di cui si è preoccupati.

Se non si usa Sincronizzazione file di Azure per memorizzare nella cache la condivisione file di Azure specifica in questione, ma si è scelto di usare l'accesso diretto alla condivisione:

1. Montare la condivisione file di Azure come unità di rete in un computer Windows locale.
2. Eseguire RoboCopy tra StorSimple e la condivisione file di Azure montata. Se i file non vengono copiati, correggere i nomi sul lato StorSimple per rimuovere caratteri non validi. Riprovare quindi RoboCopy. Il comando RoboCopy elencato in precedenza può essere eseguito più volte senza causare richiami non necessari a StorSimple.

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;
• Dimensioni e 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, 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 più desiderabile, 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 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 meno file più 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 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.

Più thread copieranno l'esempio di 1 TiB di file di piccole dimensioni in modo 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 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, 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 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
• 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. È possibile che si verifichino errori di copia. Si tratta di un evento 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. Infine, 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 contenuti da copiare, ma sono vincolate sempre più 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 la copia di file che non riesce perché i file sono in uso o a causa di problemi di timeout potrebbe essere completata correttamente in questo modo.

Windows Server 2022 e RoboCopy LFSM

L'opzione RoboCopy /LFSM può essere usata per evitare che un processo RoboCopy non riesca con un errore di volume completo. RoboCopy viene sospeso ogni volta che una copia di file porta lo spazio disponibile del volume di destinazione al di sotto di un valore limite.

Usare RoboCopy con Windows Server 2022. Solo questa versione di RoboCopy contiene importanti correzioni di bug e funzionalità che rendono il commutatore compatibile con i flag aggiuntivi necessari nella maggior parte delle migrazioni. Ad esempio, compatibilità con il flag /B.

/B segue 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.

In genere, RoboCopy può essere eseguito nell'origine, nella destinazione o in un terzo computer.

Importante

Se si intende usare /LFSM, RoboCopy deve essere eseguito nel server di Sincronizzazione file di Azure di destinazione di Windows Server 2022.

Si noti anche che con /LFSM è necessario usare anche un percorso locale per la destinazione, non un percorso UNC. Ad esempio, come percorso di destinazione, è consigliabile usare E:\Nomecartella anziché un percorso UNC come \\NomeServer\NomeCartella.

Attenzione

La versione attualmente disponibile di RoboCopy in Windows Server 2022 presenta un bug che causa il conteggio delle pause rispetto al conteggio degli errori per file. Applicare la soluzione alternativa seguente.

I flag /R:2 /W:1 consigliati aumentano la probabilità che la copia di un file non sia riuscito a causa di una pausa indotta da /LFSM. In questo esempio, se un file non è copiato dopo 3 pause perché /LFSM ha causato la sospensione, RoboCopy non completa la copia del file. La soluzione alternativa consiste nell'usare valori più elevati per /R:n e /W:n. Un buon esempio è /R:10 /W:1800 (10 tentativi di 30 minuti ciascuno). In questo modo, l'algoritmo di suddivisione in livelli di Sincronizzazione file di Azure deve avere il tempo necessario per creare spazio nel volume di destinazione.

Questo bug è stato risolto ma la correzione non è ancora disponibile pubblicamente. Controllare questo paragrafo per gli aggiornamenti sulla disponibilità della correzione e su come distribuirlo.

Cutover utente

Se si usa Sincronizzazione file di Azure, è probabile che sia necessario creare le condivisioni SMB in tale istanza di Windows Server abilitata per Sincronizzazione file di Azure corrispondente alle condivisioni presenti nei volumi StorSimple. È possibile caricare in anticipo questo passaggio e farlo in precedenza per non perdere tempo qui. Tuttavia, è necessario assicurarsi che prima di questo punto nessuno abbia accesso per causare modifiche all'istanza di Windows Server.

Se si dispone di una distribuzione DFS-N, è possibile puntare gli spazi dei nomi DFN ai nuovi percorsi delle cartelle del server. Se non si dispone di una distribuzione DFS-N e si è eseguito il front-end all'appliance 8100 o 8600 in locale con un'istanza di Windows Server, è possibile togliere tale server dal dominio. Aggiungere quindi la nuova istanza di Windows Server abilitata per Sincronizzazione file di Azure. Durante questo processo, assegnare al server lo stesso nome del server e gli stessi nomi di condivisione del server precedente in modo che il cutover rimanga trasparente per gli utenti, i criteri di gruppo e gli script.

Altre informazioni su DFS-N.

Fase 6: Deprovisioning

Quando si esegue il deprovisioning di una risorsa, si perde l'accesso alla configurazione di tale risorsa e ai relativi dati. Il deprovisioning non può essere annullato. Non procedere fino a quando non si è verificato che:

• La migrazione è stata completata.
• Non esistono dipendenze per i file, le cartelle o i backup dei volumi StorSimple che si sta per sottoporre a deprovisioning.

Prima di iniziare, è consigliabile osservare la nuova distribuzione di Sincronizzazione file di Azure nell'ambiente di produzione per un po'. Questo tempo dà la possibilità di risolvere eventuali problemi riscontrati. Dopo aver osservato la distribuzione di Sincronizzazione file di Azure per almeno alcuni giorni, è possibile iniziare a eseguire il deprovisioning delle risorse in questo ordine:

1. Effettuare il deprovisioning della risorsa di StorSimple Data Manager tramite il portale di Azure. Tutti i processi DTS verranno eliminati con essa. Non sarà possibile recuperare facilmente i log di copia. Se sono importanti, recuperarli prima del deprovisioning.
2. Assicurarsi che le appliance fisiche StorSimple siano state migrate e quindi annullarne la registrazione. Se non si è certi che sia stata eseguita la migrazione, non procedere. Se si esegue il deprovisioning di queste risorse mentre sono ancora necessarie, non sarà possibile recuperare i dati o la relativa configurazione.
   Facoltativamente, è possibile eseguire il deprovisioning della risorsa del volume StorSimple, che pulisce i dati nell'appliance. Questo processo può richiedere diversi giorni e non azzererà dal punto di vista forense i dati nell'appliance. Se questo è importante, gestire l'azzeramento del disco separatamente dal deprovisioning delle risorse e in base ai propri criteri.
3. Se non ci sono più dispositivi registrati in Gestione dispositivi StorSimple, è possibile procedere con la rimozione della risorsa di Gestione dispositivi stessa.
4. È ora possibile eliminare l'account di archiviazione StorSimple in Azure. Anche in questo caso, arrestare e confermare che la migrazione è stata completata e che nessun contenuto o utente dipende da questi dati prima di procedere.
5. Scollegare l'appliance fisica StorSimple dal data center.
6. Se si è proprietari dell'appliance StorSimple, è possibile riciclarla per PC. Se il dispositivo è in lease, informare il locatore e restituire il dispositivo in base alle esigenze.

La migrazione è stata completata.

---

Nota

Sono ancora presenti domande o si sono verificati problemi?
Il supporto tecnico è a disposizione:

Risoluzione dei problemi

Quando si usa il servizio di migrazione StorSimple Data Manager, un intero processo di migrazione o singoli file potrebbe non riuscire per diversi motivi. La sezione relativa alla fedeltà dei file include altri dettagli sugli scenari supportati o non supportati. Nelle tabelle seguenti sono elencati i codici di errore, i dettagli dell'errore e, dove possibile, le opzioni di mitigazione.

Errori a livello di processo

Fase	Error	Dettagli/Mitigazione
Backup	Impossibile trovare un backup per i parametri specificati	Il backup selezionato per l'esecuzione del processo non viene trovato al momento di "Stima" o "Copia". Assicurarsi che il backup sia ancora presente nel catalogo di backup di StorSimple. A volte i criteri di conservazione dei backup automatici eliminano i backup tra la selezione per la migrazione e l'esecuzione effettiva del processo di migrazione per questo backup. Valutare la possibilità di disabilitare le pianificazioni di conservazione dei backup prima di avviare una migrazione.
Stima Configurare il calcolo	Installazione delle chiavi di crittografia non riuscita	La ave di crittografia dei dati del servizion è corretta. Vedere la sezione relativa alla chiave di crittografia in questo articolo per altri dettagli e per informazioni sul recupero della chiave corretta.
	Errore batch	È possibile che l'avvio di tutta l'infrastruttura interna necessaria per eseguire una migrazione causi un problema. In questo processo sono coinvolti più servizi. Questi problemi si risolvono in genere quando si tenta di eseguire di nuovo il processo.
	Si è verificato un errore interno di StorSimple Manager. Attendere alcuni minuti e ripetere l'operazione. Se il problema persiste, contattare il supporto tecnico Microsoft. Codice errore: 1074161829	Questo errore generico presenta più cause, ma una possibilità rilevata è che la gestione dispositivi StorSimple ha raggiunto il limite di 50 appliance. Controllare se i processi eseguiti più di recente in Gestione dispositivi hanno improvvisamente iniziato a non riuscire con questo errore, il che suggerisce che si tratta del problema. La mitigazione di questo particolare problema consiste nel rimuovere tutte le appliance StorSimple 8001 offline create e usate dal servizio Data Manager. È possibile inviare un ticket di supporto o eliminarle manualmente nel portale. Assicurarsi di eliminare solo appliance serie 8001 offline.
Stima dei file	Processo di clonazione del volume non riuscito	Questo errore indica molto probabilmente che è stato specificato un backup danneggiato in qualche modo. Il servizio di migrazione non può montarlo o leggerlo. È possibile provare il backup manualmente o aprire un ticket di supporto.
	Non è possibile procedere perché il volume è in un formato non NTFS	Solo i volumi NTFS, non deduplicati, possono essere usati dal servizio di migrazione. Se si dispone di un volume formattato in modo diverso, ad esempio ReFS o un formato di terze parti, il servizio di migrazione non sarà in grado di eseguire la migrazione di questo volume. Vedere la sezione Limitazioni note.
	Contattare il supporto tecnico. Nessuna partizione appropriata trovata sul disco	Il disco StorSimple che dovrebbe avere il volume specificato per la migrazione non sembra avere una partizione per tale volume. Questo è insolito e può indicare un danneggiamento o un allineamento non corretto della gestione. L'unica opzione per analizzare ulteriormente questo problema consiste nell'inviare un ticket di supporto.
	Timeout	La fase di stima che non riesce con un timeout indica in genere un problema con l'appliance StorSimple o il backup del volume di origine lento e talvolta anche danneggiato. Se la ripetizione del backup non funziona, l'invio di un ticket di supporto è il miglior corso d'azione.
	Impossibile trovare il <percorso> file Impossibile trovare una parte del percorso	La definizione del processo consente di fornire un sottopercorso di origine. Questo errore viene visualizzato quando tale percorso non esiste. Ad esempio: \Share1 > \Share\Share1 In questo esempio è stato specificato \Share1 come sottopercorso nell'origine, con mapping a un altro sottopercorso nella destinazione. Tuttavia, il percorso di origine non esiste (è stato digitato in modo non corretto?) Nota: Windows mantiene le maiuscole e minuscole ma non dipende da maiuscole e minuscole. Ciò significa che specificare \Share1 e \share1 è equivalente. Inoltre, i percorsi di destinazione che non esistono verranno creati automaticamente.
	Questa richiesta non è autorizzata a eseguire questa operazione	Questo errore viene visualizzato quando l'account di archiviazione StorSimple di origine o l'account di archiviazione di destinazione con la condivisione file di Azure ha un'impostazione del firewall abilitata. È necessario consentire il traffico sull'endpoint pubblico e non limitarlo con altre regole del firewall. In caso contrario, il servizio trasformazione dati non sarà in grado di accedere a uno degli account di archiviazione, anche se è stato autorizzato. Disabilitare le regole del firewall ed eseguire di nuovo il processo.
Copia di file	L'account a cui si accede non supporta HTTP	Disabilitare il routing Internet nell'account di archiviazione di destinazione o usare l'endpoint di routing Microsoft.
	La condivisione specificata è piena	Se la destinazione è una condivisione file di Azure Premium, assicurarsi di aver effettuato il provisioning di capacità sufficiente per la condivisione. Il provisioning temporaneo è una pratica comune.

Errori a livello di elemento

Durante la fase di copia di un processo di migrazione, singoli elementi dello spazio dei nomi (file e cartelle) possono riscontrare errori. La tabella seguente elenca gli errori più comuni e suggerisce le opzioni di mitigazione quando possibile.

Fase	Error	Strategia di riduzione del rischio
Copia	-2146233088 Il server è occupato.	Eseguire di nuovo il processo se sono presenti troppi errori. Se sono presenti solo pochi errori, è possibile provare a eseguire di nuovo il processo, ma spesso una copia manuale degli elementi non riusciti può essere più veloce. Riprendere quindi la migrazione ignorando l'elaborazione del backup successivo.
	-2146233088 L'operazione non è stata completata nel tempo specificato.	Eseguire di nuovo il processo se sono presenti troppi errori. Se sono presenti solo pochi errori, è possibile provare a eseguire di nuovo il processo, ma spesso una copia manuale degli elementi non riusciti può essere più veloce. Riprendere quindi la migrazione ignorando l'elaborazione del backup successivo.
	Timeout caricamento o copia non avviata	Eseguire di nuovo il processo se sono presenti troppi errori. Se sono presenti solo pochi errori, è possibile provare a eseguire di nuovo il processo, ma spesso una copia manuale degli elementi non riusciti può essere più veloce. Riprendere quindi la migrazione ignorando l'elaborazione del backup successivo.
	-2146233029 L'operazione è stata annullata.	Eseguire di nuovo il processo se sono presenti troppi errori. Se sono presenti solo pochi errori, è possibile provare a eseguire di nuovo il processo, ma spesso una copia manuale degli elementi non riusciti può essere più veloce. Riprendere quindi la migrazione ignorando l'elaborazione del backup successivo.
	1920 Non è possibile accedere al file dal sistema.	Si tratta di un errore comune quando il motore di migrazione rileva un punto di analisi, un collegamento o una giunzione. Non sono supportate. Questi tipi di file non possono essere copiati. Vedere la sezione Limitazioni note e la sezione Fedeltà dei file in questo articolo.
	-2147024891 Accesso negato	Si tratta di un errore per i file crittografati, che risultano non accessibili sul disco. I file che possono essere letti dal disco ma semplicemente hanno contenuto crittografato non sono interessati e possono essere copiati. L'unica opzione consiste nel copiarli manualmente. È possibile trovare tali elementi montando il volume interessato ed eseguendo il comando seguente: get-childitem <path> [-Recurse] -Force -ErrorAction SilentlyContinue | Where-Object {$_.Attributes -ge "Encrypted"} | format-list fullname, attributes
	FileTime Win32 non valido. Nome parametro: fileTime	In questo caso, è possibile accedere al file ma non può essere valutato per la copia perché un timestamp da cui dipende il motore di migrazione è danneggiato o è stato scritto da un'applicazione in un formato non corretto. Non c'è molto da fare, perché non è possibile modificare il timestamp nel backup. Se conservare questo file è importante, ad esempio nella versione più recente (ultimo backup contenente questo file) copiare manualmente il file, correggere il timestamp e quindi spostarlo nella condivisione file di Azure di destinazione. Questa opzione non è ottimale, ma è un'opzione per i file ad alto valore in cui si vuole mantenere almeno una versione nella destinazione.
	-2146232798 L'handle Safe è stato chiuso	Spesso si verifica un errore temporaneo. Eseguire di nuovo il processo se sono presenti troppi errori. Se sono presenti solo pochi errori, è possibile provare a eseguire di nuovo il processo, ma spesso una copia manuale degli elementi non riusciti può essere più veloce. Riprendere quindi la migrazione ignorando l'elaborazione del backup successivo.
	-2147024413 Errore hardware irreversibile del dispositivo	Si tratta di un errore raro e non effettivamente segnalato per un dispositivo fisico, ma piuttosto delle appliance virtualizzate serie 8001 usate dal servizio di migrazione. L'appliance ha riscontrato un problema. I file con questo errore non impediscono alla migrazione di procedere al backup successivo. Ciò rende difficile eseguire una copia manuale o riprovare a eseguire il backup che contiene file con questo errore. Se i file lasciati indietro sono molto importanti o è presente un numero elevato di file, potrebbe essere necessario avviare nuovamente la migrazione di tutti i backup. Aprire un ticket di supporto per ulteriori indagini.
Elimina (eliminazione mirror)	La directory specificata non è vuota.	Questo errore si verifica quando la modalità di migrazione è impostata su mirror e nel processo che rimuove gli elementi dalla condivisione file di Azure si è verificato un problema che ha impedito l'eliminazione di elementi. L'eliminazione avviene solo nella condivisione live, non negli snapshot precedenti. L'eliminazione è necessaria perché i file interessati non sono nel backup corrente e pertanto devono essere rimossi dalla condivisione live prima dello snapshot successivo. Sono disponibili due opzioni: Opzione 1: montare la condivisione file di Azure di destinazione ed eliminare manualmente i file con questo errore. Opzione 2: è possibile ignorare questi errori e continuare a elaborare il backup successivo, sapendo però che la destinazione potrebbe non essere identica all'origine e potrebbe avere alcuni elementi aggiuntivi che non erano nel backup originale di StorSimple.
	Richiesta non valida	Questo errore indica che il file di origine presenta determinate caratteristiche che non è stato possibile copiare nella condivisione file di Azure. In particolare, potrebbero essere presenti caratteri di controllo invisibili in un nome file o 1 byte di un carattere a byte doppio nel nome file o nel percorso del file. È possibile usare i log di copia per ottenere i nomi dei percorsi, copiare i file in un percorso temporaneo, rinominare i percorsi per rimuovere i caratteri non supportati e quindi copiare con RoboCopy nuovamente nella condivisione file di Azure. È quindi possibile riprendere la migrazione ignorando il backup successivo da elaborare.

Passaggi successivi

• Comprendere la flessibilità dei criteri di cloud a livelli.
• Abilitare i Backup di Azure nelle condivisioni file di Azure per pianificare gli snapshot e definire le pianificazioni di conservazione dei backup.
• Se nel portale di Azure alcuni file non vengono sincronizzati in modo permanente, vedere la Guida alla risoluzione dei problemi per la procedura per risolvere questi problemi.