Eseguire la migrazione da Linux a una distribuzione cloud ibrida con Sincronizzazione file di Azure

Questo articolo sulla migrazione è uno dei diversi elementi chiave NFS e Sincronizzazione file di Azure. Verificare se questo articolo si applica allo scenario:

• Origine dati: Archiviazione collegata alla rete (NAS)
• Route di migrazione: Linux Server con SAMBA ⇒ Windows Server 2012R2 o versione successiva ⇒ sincronizzazione con condivisioni file di Azure
• Memorizzazione nella cache dei file locali: Sì, l'obiettivo finale è una distribuzione Sincronizzazione file di Azure.

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

Sincronizzazione file di Azure funziona nelle istanze di Windows Server con archiviazione collegata diretta (DAS). Non supporta la sincronizzazione da e verso client Linux o una condivisione SMB (Server Message Block) remoto o condivisioni NFS (Network File System).

Di conseguenza, la trasformazione dei servizi file in una distribuzione ibrida rende necessaria una migrazione a Windows Server. Questo articolo illustra la pianificazione e l'esecuzione di tale migrazione.

Si applica a

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

Obiettivi della migrazione

L'obiettivo è spostare le condivisioni presenti nel server Samba Linux in un'istanza di Windows Server. Usare quindi Sincronizzazione file di Azure per una distribuzione cloud ibrida. Questa migrazione deve essere eseguita in modo da garantire l'integrità dei dati di produzione e della disponibilità durante la migrazione. Quest'ultimo richiede un tempo di inattività minimo, in modo che possa adattarsi o solo leggermente superiore a normali finestre di manutenzione.

Panoramica della migrazione

Come accennato nell'articolo panoramica della migrazione File di Azure, l'uso dello strumento di copia e dell'approccio corretto è importante. Il server Samba Linux espone le condivisioni SMB direttamente nella rete locale. Robocopy, integrato in Windows Server, è il modo migliore per spostare i file in questo scenario di migrazione.

Se non si esegue Samba nel server Linux e si vuole eseguire la migrazione di cartelle a una distribuzione ibrida in Windows Server, è possibile usare strumenti di copia Linux anziché Robocopy. Tenere presente le funzionalità di fedeltà dello strumento di copia. Esaminare la sezione Nozioni di base sulla migrazione nell'articolo Panoramica della migrazione per informazioni su come cercare in uno strumento di copia.

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

In questo passaggio si determinerà il numero di condivisioni file di Azure necessarie. Un'unica 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 agli utenti e alle app. Il modo più semplice per visualizzare questo scenario consiste nell'immaginare una condivisione locale che esegue il mapping di 1:1 a una condivisione file di Azure. Se si ha un numero sufficiente di condivisioni, sotto 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 non è spesso necessario. Prendere in considerazione le opzioni seguenti.

Raggruppamento di condivisioni

Ad esempio, se il reparto risorse umane (HR) ha 15 condivisioni, è consigliabile archiviare tutti i dati hr in una singola condivisione file di Azure. L'archiviazione di più condivisioni locali in una condivisione file di Azure non impedisce di creare le normali condivisioni SMB 15 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 in 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 del volume

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

La sincronizzazione della radice del volume non è sempre l'opzione migliore. Esistono vantaggi per la sincronizzazione di più posizioni. In questo modo, ad esempio, consente di mantenere inferiore il numero di elementi per ambito di sincronizzazione. Testiamo 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 di dollari in una singola quota. La configurazione di Sincronizzazione file di Azure con un numero inferiore di elementi non è utile solo per la sincronizzazione dei file. Un numero inferiore di elementi offre anche scenari come questi:

• L'analisi iniziale del contenuto cloud può essere completata più velocemente, che a sua volta riduce l'attesa che lo spazio dei nomi venga visualizzato 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ò velocizzare 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 presenti, consultare lo strumento TreeSize di JAM Software GmbH.

Approccio strutturato a una mappa di distribuzione

Prima di distribuire l'archiviazione cloud in un passaggio successivo, è importante creare una mappa tra cartelle locali e condivisioni file di Azure. Questo mapping informa il numero di risorse del gruppo di sincronizzazione Sincronizzazione file di Azure di cui si eseguirà il 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ò essere sincronizzato con fino a 30 condivisioni file di Azure.

• Una condivisione file di Azure viene distribuita in un account di archiviazione. Tale disposizione rende l'account di archiviazione una destinazione di scalabilità per i numeri di prestazioni come IOPS e velocità effettiva.

  Prestare attenzione alle limitazioni di I/O al secondo di un account di archiviazione durante la distribuzione di condivisioni file di Azure. Idealmente, è consigliabile eseguire il mapping delle condivisioni file 1:1 con gli account di archiviazione. Tuttavia, ciò potrebbe non essere sempre possibile a causa di vari limiti e restrizioni, sia dall'organizzazione che da Azure. Quando non è possibile avere una sola condivisione file distribuita in un account di archiviazione, prendere in considerazione quali condivisioni saranno altamente attive e quali condivisioni saranno meno attive per garantire che le condivisioni file più calde non vengano inserite nello stesso account di archiviazione.

  Se si prevede di sollevare 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 di Azure standard nel proprio account di archiviazione.

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

Suggerimento

A causa 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 raggruppate in esso, in una singola condivisione file di Azure. Questa tecnica consente di rimanere entro il limite di 30 sincronizzazioni di condivisione file di Azure per server.

Questo raggruppamento in una radice comune non influisce sull'accesso ai dati. Gli ACL rimangono così come sono. È sufficiente modificare tutti i percorsi di condivisione ,ad esempio condivisioni SMB o NFS, potrebbero essere presenti nelle cartelle del server locale ora modificate in una radice comune. Niente altro cambia.

Importante

Il vettore di scalabilità più importante per Sincronizzazione file di Azure è il numero di elementi (file e cartelle) che devono essere sincronizzati. Esaminare le destinazioni di scalabilità di Sincronizzazione file di Azure per altri dettagli.

È 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 viene testato con 100 milioni di elementi (file e cartelle) per condivisione. Ma spesso è preferibile mantenere il numero di elementi al di sotto di 20 milioni o 30 milioni di dollari in una singola condivisione. 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 ti darà spazio per crescere.

È possibile che, nella situazione, un set di cartelle possa essere sincronizzato logicamente con la stessa condivisione file di Azure (usando il nuovo approccio comune della cartella radice menzionato in precedenza). Tuttavia, potrebbe essere preferibile raggruppare le cartelle in modo che si sincronizzano con due anziché una condivisione file di Azure. È 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 sincronizzare tra altri server locali, aggiungendo la possibilità di sincronizzare con 30 altre condivisioni file di Azure per ogni server aggiuntivo.

Scenari comuni di sincronizzazione dei file e considerazioni

#	Scenario di sincronizzazione	Supportato	Considerazioni (o limitazioni)	Soluzione (o 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 solo la sincronizzazione con un gruppo di sincronizzazione. Un gruppo di sincronizzazione supporta solo un endpoint server per server registrato.	1) Iniziare con la sincronizzazione di un disco (il relativo volume radice) alla condivisione file di Azure di destinazione. A partire da un disco/volume più grande, sarà utile per i requisiti di archiviazione locali. Configurare il livello cloud per il livello di tutti i dati nel cloud, liberando quindi spazio sul disco del file server. Spostare i dati da altri volumi o condivisioni nel volume corrente che esegue la sincronizzazione. Continuare i passaggi uno per uno fino a quando tutti i dati vengono a livelli fino al cloud/migrato. 2) Destinazione di un volume radice (disco) alla volta. Usare il livello cloud per 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, la sincronizzazione e ripetere il processo. Nota: potrebbe essere necessario reinstallare l'agente. 3) Consigliare l'uso di più condivisioni file di Azure di destinazione (stesso account di archiviazione o diverso in base ai requisiti di prestazioni)
2	File server con volume singolo e più condivisioni nella stessa condivisione file di Azure di destinazione (consolidamento)	Sì	Non è possibile disporre di più endpoint server per ogni server registrato che si sincronizza 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, vedere Condividere il concetto di raggruppamento e la sincronizzazione del volume .
3	File server con più condivisioni e/o volumi in più condivisioni file di Azure in un account di archiviazione singolo (mapping di condivisione 1:1)	Sì	Un'unica 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. Operazioni di I/O al secondo e velocità effettiva vengono condivise tra condivisioni file. Mantenere il numero di elementi per gruppo di sincronizzazione entro 100 milioni di elementi (file e cartelle) per condivisione. Idealmente è meglio rimanere al di sotto di 20 o 30 milioni per condivisione.	1) Usare più gruppi di sincronizzazione (numero di gruppi di sincronizzazione = numero di condivisioni file di Azure da sincronizzare). 2) È possibile sincronizzare solo 30 condivisioni in questo scenario alla volta. Se nel file server sono presenti più di 30 condivisioni, usare il concetto di raggruppamento di condivisione e la sincronizzazione volume per ridurre il numero di cartelle radice o di primo livello all'origine. 3) Usare altri server Sincronizzazione file locali e suddividere/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 in un account di archiviazione diverso (mapping di condivisione 1:1)	Sì	Un'unica istanza di Windows Server (o cluster) può sincronizzare fino a 30 condivisioni file di Azure (stesso account di archiviazione o diverso). Mantenere il numero di elementi per gruppo di sincronizzazione entro 100 milioni di elementi (file e cartelle) per condivisione. Idealmente è meglio rimanere al di sotto di 20 o 30 milioni per condivisione.	Lo stesso approccio indicato in precedenza
5	Più file server con un singolo (volume o condivisione 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 in Scenario 1 sopra con considerazioni aggiuntive sulla destinazione di un 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 nella condivisione file di Azure.

Creare una tabella che registra i pensieri in modo da poterla 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 creare il mapping.

Scaricare un modello di mapping dello spazio dei nomi.

Fase 2: Effettuare il provisioning di un'istanza di Windows Server appropriata in locale

• Creare un'istanza di Windows Server 2019 come macchina virtuale o server fisico. Windows Server 2012 R2 è il requisito minimo. È supportato anche un cluster di failover di Windows Server.

• Effettuare il provisioning o aggiungere l'archiviazione collegata diretta (DAS). L'archiviazione NAS (Network Attached Storage) non è supportata.

  La quantità di archiviazione di cui si esegue il provisioning può essere inferiore a quella attualmente usata nel server Samba Linux, se si usa la funzionalità di suddivisione in livelli cloud Sincronizzazione file di Azure.

La quantità di archiviazione di cui si esegue il provisioning può essere inferiore a quella attualmente usata nel server Samba Linux. Questa scelta di configurazione richiede anche l'uso della funzionalità di sincronizzazione file di Azure a livelli cloud. Tuttavia, quando si copiano i file dallo spazio server Samba Linux più grande al volume windows Server più piccolo in una fase successiva, sarà necessario lavorare in batch:

1. Spostare un set di file che si adatta al disco.
2. Consentire la sincronizzazione dei file e il livello cloud.
3. Quando viene creato più spazio libero nel volume, procedere con il batch successivo di file. In alternativa, esaminare il comando RoboCopy nella prossima sezione RoboCopy per l'uso del nuovo /LFSM commutatore. L'uso /LFSM può semplificare significativamente i processi RoboCopy, ma non è compatibile con alcuni altri commutatori RoboCopy che potresti dipendere.

È possibile evitare questo approccio in batch eseguendo il provisioning dello spazio equivalente nell'istanza di Windows Server che i file occupano nel server Samba Linux. Valutare la possibilità di abilitare la deduplicazione in Windows. Se non si vuole eseguire il commit permanente di questa quantità elevata di archiviazione nell'istanza di Windows Server, è possibile ridurre le dimensioni del volume dopo la migrazione e prima di modificare i criteri di livelli cloud. In questo modo viene creata una cache locale più piccola delle condivisioni file di Azure.

La configurazione delle risorse (calcolo e RAM) dell'istanza di Windows Server distribuita dipende principalmente dal numero di elementi (file e cartelle) da sincronizzare. È consigliabile procedere con una configurazione con prestazioni superiori se si verificano problemi.

Informazioni su come ridimensionare un'istanza di Windows Server in base al numero di elementi (file e cartelle) da sincronizzare.

Nota

L'articolo collegato precedentemente presenta una tabella con un intervallo per la memoria del server (RAM). È possibile orientare verso il numero più piccolo per il server, ma si prevede che la sincronizzazione iniziale possa richiedere molto più tempo.

Fase 3: Distribuire la risorsa cloud 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 viene chiamata servizio di sincronizzazione archiviazione. È consigliabile distribuire solo uno per tutti i server che sincronizzano lo stesso set di file ora o in futuro. Creare più servizi di sincronizzazione archiviazione solo se sono presenti set distinti di server che non devono mai scambiare dati. Ad esempio, potrebbero essere presenti 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 posizione. 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 relativa alla distribuzione del servizio di sincronizzazione archiviazione nell'articolo sulla distribuzione di Sincronizzazione file di Azure. Seguire solo questa sezione dell'articolo. Sono disponibili collegamenti ad altre sezioni dell'articolo nei passaggi successivi.

Fase 4: Distribuire le risorse di archiviazione di Azure

In questa fase, consultare la tabella di mapping della fase 1 e usarla per effettuare il provisioning del numero corretto di account di archiviazione e condivisioni file di Azure.

Una condivisione file di Azure viene archiviata nel cloud in un account di archiviazione di Azure. Un altro livello di considerazioni sulle prestazioni si applica qui.

Se sono presenti condivisioni altamente attive (condivisioni usate da molti utenti e/o applicazioni), due condivisioni file di Azure potrebbero raggiungere il limite di prestazioni di un account di archiviazione.

Una procedura consigliata consiste nel distribuire gli account di archiviazione con una condivisione file ciascuno. È possibile raggruppare più condivisioni file di Azure nello stesso account di archiviazione se si dispone di condivisioni di archiviazione o si prevede un'attività giornaliera bassa.

Queste considerazioni si applicano maggiormente all'accesso al cloud diretto (tramite una macchina virtuale di Azure) rispetto a Sincronizzazione file di Azure. Se si prevede di usare solo Sincronizzazione file di Azure in queste condivisioni, il raggruppamento di più in un singolo account di archiviazione di Azure è corretto.

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

Nella fase precedente è stato determinato il numero appropriato di condivisioni. In questo passaggio è disponibile un mapping degli account di archiviazione alle condivisioni file. Distribuire ora il numero appropriato di account di archiviazione di Azure con il numero appropriato di condivisioni file di Azure.

Assicurarsi che l'area di ogni account di archiviazione sia la stessa e corrisponda all'area della risorsa del servizio di sincronizzazione archiviazione già distribuita.

Attenzione

Se si crea una condivisione file di Azure con un limite di 100 TiB, tale condivisione può usare solo opzioni di ridondanza dell'archiviazione con ridondanza della zona o archiviazione con ridondanza della zona. Considerare le esigenze di ridondanza dell'archiviazione prima di usare 100 condivisioni file TiB.

Le condivisioni file di Azure vengono comunque create con un limite di 5 TiB per impostazione predefinita. Seguire la procedura descritta in Creare una condivisione file di Azure per creare una condivisione file di grandi dimensioni.

Un'altra considerazione quando si distribuisce un account di archiviazione è la ridondanza di Archiviazione di Azure. Vedere Opzioni di ridondanza di Archiviazione di Azure.

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

Fase 5: Distribuire l'agente di Sincronizzazione file di Azure

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

La guida alla distribuzione spiega che è necessario disattivare La 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 di PowerShell necessari usando i comandi seguenti. Assicurarsi di installare il modulo completo e il provider NuGet quando viene richiesto di farlo.

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 utilizza qualsiasi 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 Sincronizzazione file di Azure.

Se si configura un proxy significa che è necessario 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 di 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. È invece possibile limitare il server per comunicare con spazi dei nomi DNS di livello superiore. Per altre informazioni, vedere Sincronizzazione file di Azure impostazioni proxy e firewall. Seguire le procedure consigliate per la rete.

Al termine dell'installazione guidata del server, verrà aperta una registrazione guidata 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: Sincronizzazione file di Azure'installazione dell'agente.

Usare l'agente più recente. È possibile scaricarlo dall'Area download Microsoft: .

Dopo aver completato correttamente l'installazione e la registrazione del server, è possibile verificare di aver completato correttamente questo passaggio. 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.

Fase 6: Configurare Sincronizzazione file di Azure nella distribuzione di Windows Server

L'istanza di Windows Server locale registrata deve essere pronta e connessa a Internet per questo processo.

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. In Sincronizzazione file di Azure terminologia, la condivisione file di Azure diventerà un endpoint cloud nella topologia di sincronizzazione descritta 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. Assicurarsi 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 (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

La suddivisione in livelli nel cloud è la funzionalità Sincronizzazione file di Azure che consente al server locale di avere una capacità di archiviazione inferiore a quella archiviata nel cloud, ma lo spazio dei nomi completo è disponibile. I dati interessanti localmente vengono memorizzati nella cache anche in locale per prestazioni di accesso rapido. Il cloud a livelli è una funzionalità facoltativa per ogni endpoint server Sincronizzazione file di Azure.

Avviso

Se è stato effettuato il provisioning di meno spazio di archiviazione nei volumi di Windows Server rispetto ai dati usati nel server Samba Linux, il cloud a livelli è obbligatorio. Se non si attiva la suddivisione in livelli cloud, il server non libera spazio per archiviare tutti i file. Impostare i criteri di suddivisione in livelli, temporaneamente per la migrazione, su spazio disponibile al 99% per un volume. Assicurarsi di tornare alle impostazioni di suddivisione in livelli nel cloud al termine della migrazione e impostare i criteri su un livello più utile per il lungo termine.

Ripetere i passaggi di creazione del gruppo di sincronizzazione e l'aggiunta della cartella del server corrispondente come endpoint server per tutte le condivisioni file di Azure e i percorsi del server che devono essere configurati per la sincronizzazione.

Dopo la creazione di tutti gli endpoint server, la sincronizzazione funziona. È possibile creare un file di test e visualizzarlo sincronizzato dal percorso del server alla condivisione file di Azure connessa , come descritto dall'endpoint cloud nel gruppo di sincronizzazione.

Entrambe le posizioni, le cartelle del server e le condivisioni file di Azure, sono altrimenti vuote e in attesa di dati. Nel passaggio successivo si inizierà a copiare i file nell'istanza di Windows Server per Sincronizzazione file di Azure di spostarli nel cloud. Se è stata abilitata la suddivisione in livelli cloud, il server inizierà a livelli i file se si esaurisce la capacità nei volumi locali.

Fase 7: Robocopy

L'approccio di migrazione di base consiste nell'usare Robocopy per copiare i file e usare Sincronizzazione file di Azure per eseguire la sincronizzazione.

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

1. Identificare la prima posizione nel server Samba Linux.
2. Identificare la cartella corrispondente nell'istanza di Windows Server in cui è già stato configurato Sincronizzazione file di Azure.
3. Avviare la copia usando Robocopy.

Il comando Robocopy seguente copia i file dalla risorsa di archiviazione del server Samba Linux alla cartella di destinazione di Windows Server. Windows Server lo sincronizza con le condivisioni file di Azure.

Se è stato effettuato il provisioning di meno spazio di archiviazione nell'istanza di Windows Server rispetto ai file accettati nel server Linux Samba, è stata configurata la suddivisione in livelli cloud. Man mano che il volume locale di Windows Server diventa pieno, il cloud a livelli avvierà e eseguirà la sincronizzazione dei file di livello già sincronizzati. Il cloud a livelli genererà spazio sufficiente per continuare la copia dal server Linux Samba. Il cloud a livelli controlla una volta all'ora per vedere cosa è stato sincronizzato e liberare spazio su disco per raggiungere i criteri di spazio libero del 99% per un volume.

È possibile che Robocopy sposta i file più velocemente di quanto sia possibile eseguire la sincronizzazione con il cloud e il livello in locale, causando l'esaurimento dello spazio su disco locale. Robocopy avrà quindi esito negativo. È consigliabile usare le condivisioni in una sequenza che impedisce il problema. Si consideri, ad esempio, di non avviare processi Robocopy per tutte le condivisioni contemporaneamente. In alternativa, prendere in considerazione lo spostamento di condivisioni che rientrano nella quantità corrente di spazio disponibile nell'istanza di Windows Server. Se il processo Robocopy non riesce, è sempre possibile eseguire di nuovo il comando purché si usi l'opzione mirror/purge seguente:

robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName> 

Commutatore	Significato
/MT:n	Consente l'esecuzione di Robocopy in multithreading. Il valore predefinito per n è 8. Il massimo è di 128 thread. Anche se un numero elevato di thread consente di saturare la larghezza di banda disponibile, non significa che la migrazione sarà sempre più veloce con più thread. I test con File di Azure indicano tra 8 e 20 mostra prestazioni bilanciate per un'esecuzione di copia iniziale. Le esecuzioni successive /MIR sono progressivamente interessate dal calcolo disponibile rispetto alla larghezza di banda di rete disponibile. Per le esecuzioni successive, il valore del conteggio dei thread dovrà avvicinarsi al numero di core del processore e al conteggio dei thread per core. Valutare se i core devono essere riservati ad altre eventuali attività di un server di produzione. I test con File di Azure hanno dimostrato che fino a 64 thread producono prestazioni ottimali, ma solo se i processori possono mantenerli attivi contemporaneamente.
/R:n	Numero massimo di nuovi tentativi per un file che non viene copiato al primo tentativo. Robocopy proverà n i tempi prima che il file non riesca definitivamente a copiare nell'esecuzione. È possibile ottimizzare le prestazioni dell'esecuzione: scegliere un valore pari a due o tre se si ritiene che i problemi di timeout abbiano causato errori in passato. Questo può essere più comune rispetto ai collegamenti WAN. Scegliere nessun nuovo tentativo o un valore di uno se si ritiene che il file non sia riuscito a copiare perché era attivamente in uso. Il tentativo di nuovo alcuni secondi dopo potrebbe non essere sufficiente per modificare lo stato in uso del file. Gli utenti o le app che mantengono aperto il file potrebbero richiedere più ore. In questo caso, accettare che il file non sia stato copiato e intercettarlo in una delle esecuzioni di Robocopy pianificate, potrebbe riuscire a copiare correttamente il file. Ciò consente all'esecuzione corrente di terminare più velocemente senza essere prolungati da molti tentativi che alla fine finiscono in una maggior parte degli errori di copia a causa di file ancora aperti oltre il timeout di ripetizione dei tentativi.
/W:n	Specifica il tempo in cui Robocopy rimane in attesa prima di provare a ripetere un'operazione di copia di un file che ha avuto esito negativo in un tentativo precedente. n è il numero di secondi di attesa tra i tentativi. /W:n viene spesso usato insieme a /R:n.
/B	Esegue Robocopy nella stessa modalità che verrebbe usata da un'applicazione di backup. Questa opzione consente a Robocopy di spostare i file per cui l'utente corrente non dispone delle autorizzazioni. L'opzione di backup dipende dall'esecuzione del comando Robocopy in una console con privilegi elevati di amministratore o in una finestra di PowerShell. Se si usa Robocopy per File di Azure, assicurarsi di montare la condivisione file di Azure usando la chiave di accesso dell'account di archiviazione e un'identità di dominio. In caso contrario, i messaggi di errore potrebbero non causare in modo intuitivo una risoluzione del problema.
/MIR	(Mirror da origine a destinazione.) Consente a Robocopy di copiare solo i delta tra origine e destinazione. Le sottodirectory vuote verranno copiate. Gli elementi (file o cartelle) modificati o non presenti nella destinazione verranno copiati. Gli elementi presenti nella destinazione ma non nell'origine verranno rimossi (eliminati) dalla destinazione. Quando si usa questa opzione, le strutture delle cartelle di origine e di destinazione devono essere identiche. La corrispondenza indica la copia dal livello di origine e cartella corretto al livello di cartella corrispondente nella destinazione. Solo a questo punto una copia "di recupero" può avere esito positivo. Quando l'origine e la destinazione non corrispondono, l'uso /MIR di causerà eliminazioni e recopies 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, la modifica dell'elenco di controllo di accesso potrebbe non essere stata rilevata da Robocopy e non trasferita nella posizione di destinazione.
/COPY:[copyflags]	La fedeltà della copia del file. Impostazione predefinita: /COPY:DAT. Flag di copia: = Data, = Attributes, = Timestamps, = Security = NTFS ACL, = Owner information, = A u diting information.Copy flags: D= Data, A= Attributes, T= Timestamps, S= Security = NTFS ACL, O= Owner information, U= Auditing information. Le informazioni di controllo non possono essere archiviate in una condivisione file di Azure.
/DCOPY:[copyflags]	Fedeltà per la copia delle directory. Impostazione predefinita: /DCOPY:DA. Flag di copia: D= Data, A= Attributes, T= Timestamps.
/NP	Specifica che non verrà visualizzato l'avanzamento della copia per ogni file e cartella. La visualizzazione dell'avanzamento riduce notevolmente le prestazioni di copia.
/NFL	Specifica che i nomi dei file non vengono registrati. Aumenta le prestazioni di copia.
/NDL	Specifica che i nomi delle directory non vengono registrati. Aumenta le prestazioni di copia.
/XD	Specifica le directory da escludere. Quando si esegue Robocopy nella radice di un volume, prendere in considerazione l'esclusione della cartella nascosta System Volume Information . Se usato come progettato, tutte le informazioni in sono specifiche del volume esatto in questo sistema esatto e possono essere ricompilate su richiesta. La copia di queste informazioni non sarà utile nel cloud o quando i dati vengono copiati in un altro volume di Windows. Lasciare indietro questo contenuto non deve essere considerato perdita di dati.
/UNILOG:<file name>	Scrive lo stato nel file di log come Unicode. Sovrascrive il log esistente.
/L	Solo per un'esecuzione di test I file devono essere elencati solo. Non verranno copiati o eliminati e non verranno applicati timestamp. Usato spesso con /TEE per l'output della console. I flag dello script di esempio, ad esempio /NP, /NFLe /NDL, potrebbero essere necessari per ottenere risultati di test documentati correttamente.
/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 libero insufficiente". Questo commutatore è 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 dal /LFSM:n formato del flag. Il parametro n viene specificato in base 2: nKB, nMBo nGB. Se /LFSM viene specificato senza alcun valore esplicito per il pavimento, il pavimento viene impostato sul 10% delle dimensioni del volume di destinazione. La modalità spazio libero insufficiente non è compatibile con /MT, /EFSRAWo /ZB. Il supporto per /B è stato aggiunto in Windows Server 2022. Per altre informazioni, vedere la sezione Windows Server 2022 e RoboCopy LFSM riportata di seguito per altre informazioni, tra cui informazioni dettagliate su un bug e una soluzione alternativa correlati.
/Z	Usare con cautelaCopia 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 cautelaUsa la modalità di riavvio. Se viene negato l'accesso, questa opzione usa la modalità di backup. Questa opzione riduce significativamente le prestazioni di copia a causa del checkpoint.

Importante

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

Fase 8: cut-over utente

Quando si esegue il comando Robocopy per la prima volta, gli utenti e le applicazioni accedono ancora ai file nel server Linux Samba e possono potenzialmente modificarli. È possibile che Robocopy abbia elaborato una directory e passi alla successiva, quindi un utente nel percorso di origine (Linux) aggiunge, modifica o elimina un file che ora non verrà elaborato in questa esecuzione corrente di Robocopy. Si tratta di un comportamento previsto.

La prima esecuzione consiste nello spostare la maggior parte dei dati nell'istanza di Windows Server e nel cloud tramite Sincronizzazione file di Azure. La prima copia può richiedere molto tempo, a seconda di:

• Larghezza di banda per il download.
• Larghezza di banda di caricamento.
• La velocità della rete locale e il numero di corrispondenze ottimali del numero di thread Robocopy.
• Numero di elementi (file e cartelle) che Robocopy e Sincronizzazione file di Azure necessario elaborare.

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

Termina più velocemente la seconda volta, perché deve trasportare solo le modifiche apportate dall'ultima esecuzione. Durante questo secondo, eseguire nuove modifiche può comunque accumularsi.

Ripetere questo processo fino a quando non si è soddisfatti che la quantità di tempo necessario per completare un'operazione Robocopy per una posizione specifica si trova all'interno di una finestra accettabile per i tempi di inattività.

Quando si considera il tempo di inattività accettabile e si è pronti a portare offline la posizione di Linux, è possibile modificare gli elenchi di controllo di accesso nella radice della condivisione in modo che gli utenti non possano più accedere alla posizione. In alternativa, è possibile eseguire qualsiasi altro passaggio appropriato che impedisca la modifica del contenuto in questa cartella nel server Linux.

Eseguire un ultimo round Robocopy. Raccoglierà tutte le modifiche che potrebbero essere state perse. Il tempo necessario per questo passaggio finale dipende dalla velocità dell'analisi Robocopy. È possibile stimare il tempo (uguale al tempo di inattività) misurando la durata dell'esecuzione precedente.

Creare una condivisione nella cartella Windows Server ed eventualmente modificare la distribuzione DFS-N in modo che punti a tale cartella. Assicurarsi di impostare le stesse autorizzazioni a livello di condivisione delle condivisioni SMB del server Linux Samba. Se sono stati usati utenti locali nel server Samba Linux, è necessario ricreare questi utenti come utenti locali di Windows Server. È anche necessario eseguire il mapping dei SID esistenti trasferiti da Robocopy all'istanza di Windows Server ai SID dei nuovi utenti locali di Windows Server. Se sono stati usati account e elenchi di controllo di accesso di Active Directory, Robocopy li sposterà così come sono e non è necessaria alcuna azione aggiuntiva.

È stata completata la migrazione di una condivisione o di un gruppo di condivisioni in una radice o in un volume comune (a seconda del mapping dalla fase 1).

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

Avviso

Dopo aver spostato tutti i dati dal server Linux Samba all'istanza di Windows Server e la migrazione è stata completata, tornare a tutti i gruppi di sincronizzazione nel portale di Azure. Modificare la percentuale di spazio disponibile per il volume di suddivisione in livelli nel cloud in modo che sia più adatto per l'utilizzo della cache, ad esempio il 20%.

I criteri per lo spazio disponibile nel volume a livelli cloud agisce a livello di volume con potenzialmente più endpoint server sincronizzati. Se si dimentica di regolare lo spazio disponibile in un solo endpoint server, la sincronizzazione continuerà ad applicare la regola più restrittiva e tenterà di mantenere lo spazio libero su disco al 99%. La cache locale potrebbe quindi non essere eseguita come previsto. Le prestazioni potrebbero essere accettabili se l'obiettivo è avere lo spazio dei nomi per un volume che contiene solo i dati di archiviazione a cui si accede raramente e si riserva il resto dello spazio di archiviazione per un altro scenario.

Risolvere problemi

Il problema più comune è che il comando Robocopy ha esito negativo con Volume completo sul lato Windows Server. Il cloud a livelli agisce una volta ogni ora per evacuare il contenuto dal disco locale di Windows Server sincronizzato. L'obiettivo è raggiungere lo spazio libero del 99% sul volume.

Consentire la sincronizzazione dello stato di avanzamento e della suddivisione in livelli cloud liberare spazio su disco. È possibile osservare che in Esplora file in Windows Server.

Quando l'istanza di Windows Server ha una capacità sufficiente, riesecuzione del comando risolverà il problema. Niente si rompe quando si entra in questa situazione, e si può andare avanti con fiducia. L'inconveniente di eseguire di nuovo il comando è l'unica conseguenza.

Controllare il collegamento nella sezione seguente per la risoluzione dei problemi di Sincronizzazione file di Azure.

Passaggi successivi

Sono disponibili altre informazioni sulle condivisioni file di Azure e sulle Sincronizzazione file di Azure. Gli articoli seguenti contengono opzioni avanzate, procedure consigliate e guida alla risoluzione dei problemi. Questi articoli si collegano alla documentazione di Condivisione file di Azure in base alle esigenze.

• panoramica di Sincronizzazione file di Azure
• Distribuire Sincronizzazione file di Azure
• Risoluzione dei problemi di Sincronizzazione file di Azure