Migreren van een Synology NAS naar een UniFi UNAS Pro 8 met Robocopy, SMB Multichannel en verrassende prestatie-valkuilen

Er zat een leuk stukje geschiedenis bij; in 2007 schreef ik een bericht genaamd "XCopy considered harmful - Robocopy or XXCopy or SyncBack." Mijn argument was destijds dat zodra je genoeg bestanden verplaatst, Windows Explorer tekortschiet en Robocopy een uitstekend alternatief is. Ik gebruikte destijds zelfs /Z, de hervatbare modus van Robocopy, omdat het nuttig was om een gedeeltelijk overgedragen bestand te kunnen hervatten bij onbetrouwbare verbindingen.

Bijna twintig jaar later bleek /Z een van de belangrijkste zaken te zijn die ik juist moest verwijderen, omdat het alles extreem traag maakte.

De migratie

De basisklus was eenvoudig. Ik had shares op de Synology, zoals: \\server\music

En overeenkomstige shares op de UNAS: \\UNAS-Pro-8\music

Aanvankelijk gebruikte ik Explorer, simpelweg omdat het voorhanden was. Dat duurde tot Explorer foutmeldingen begon te geven bij individuele bestanden: "The requested operation could not be completed due to a file system limitation"

Mijn eerste gedachte ging uit naar bestandsnamen. Bij NAS-migraties ontdek je vaak dat het ene bestandssysteem permissiever is dan het andere, en er waren bestandsnamen met haakjes en andere leestekens.

Toen faalde dit bestand: \\server\music\Athlete\Tourist\05 Wires.m4p

Er is niets exotisch aan 05 Wires.m4p, dus stapte ik over op Robocopy om meer informatie te krijgen. De kopieeractie stopte consequent op 92% en gaf Windows-fout 665: 92% New File 4.3 m 05 Wires.m4p ERROR 665 (0x00000299) Copying File The requested operation could not be completed due to a file system limitation

De vraag was nu niet langer "wat is er mis met die bestandsnaam?", maar "welk deel van het pad weigert dit bestand?". Ik kopieerde het bestand van de Synology naar mijn lokale Windows-bureaublad; dat werkte. Daarna kopieerde ik het lokale bestand van Windows naar de UNAS, en dat faalde met dezelfde melding over de bestandsbeperking. Dit isoleerde het probleem: de Synology kon het bestand lezen, Windows kon het opslaan, maar er was iets aan het wegschrijven van dit specifieke bestand naar de UNAS dat problemen veroorzaakte.

Alternate Data Streams (ADS)

NTFS-bestanden kunnen, naast de normale onbenoemde stream (de eigenlijke inhoud), benoemde Alternate Data Streams bevatten. Dit is een oude Windows-bestandsfunctie die ik al in 2003 en 2007 besprak, zoals de Zone.Identifier die Windows gebruikt om bij te houden waar een gedownload bestand vandaan komt. Windows kan deze streams tonen met DIR /R.

Ik voerde het volgende uit: dir /r "%USERPROFILE%\Desktop\05 Wires.m4p"

En kreeg dit resultaat: 11/30/2011 02:17 PM 4,576,368 05 Wires.m4p 360,456 05 Wires.m4p:01APIC_03.jpg:$DATA

Daar was het. Naast het normale muziekbestand van 4,5 MB zat er een benoemde datastroom van ongeveer 360 KB bij, genaamd 01APIC_03.jpg.

Dit verklaarde ook de vreemde fout op 92%. Robocopy was succesvol door de hoofdinhoud van het bestand gegaan en stuitte vervolgens op de aanvullende stream. Wat leek op een fout midden in een gewoon .m4p-bestand, gebeurde in werkelijkheid toen Windows probeerde de extra bestandsgegevens te verwerken.

Robocopy heeft ondersteuning voor precies deze situatie. Microsoft documenteert X als een van de /COPY-vlaggen, wat betekent: "negeer alternate data streams". Dus: /COPY:DATX betekent: kopieer de data, attributen en tijdstempels van het bestand, maar kopieer de alternatieve streams niet. /DCOPY:DATX past dit gedrag toe op mappen. Ik probeerde het bestand opnieuw:

robocopy "\\server\music\Athlete\Tourist" "\\UNAS-Pro-8\music\Athlete\Tourist" "05 Wires.m4p" /R:0 /W:0 /COPY:DATX /DCOPY:DATX /V

Dit was succesvol. Belangrijk is dat DATX geen metadata verwijdert die binnen een MP3, M4A, M4P of JPEG is opgeslagen. Het vertelt Robocopy enkel om geen aparte bestandssysteem-streams te reproduceren. In mijn geval waren deze extra streams niet nodig op de nieuwe NAS.

De kopie werkte, maar was traag

Zodra het ADS-probleem was opgelost, startte ik de grotere migratie met een conventioneel Robocopy-commando:

robocopy "\\server\music" "\\UNAS-Pro-8\music" /E /Z /MT:16 /R:2 /W:2 /COPY:DATX /DCOPY:DATX /XJ /TEE /LOG:"%USERPROFILE%\Desktop\synology-to-unas.log"

Het commando draaide, maar de prestaties waren inconsistent. Soms zag ik een paar honderd megabits per seconde, dan kelderde de snelheid weer. Kleine bestanden leken soms heel lang te blijven hangen. Ik vroeg me af of dit kwam door buffering, trage schijven, parity-berekeningen, het SMB-gedrag van de UNAS, of dat mijn Synology simpelweg zijn limiet had bereikt.

Ik begon met het testen van verschillende variabelen. Ik verlaagde het aantal threads en probeerde single-threaded; niets hielp. Toen verwijderde ik /Z.

De documentatie van Microsoft beschrijft /Z als de restartable mode, waardoor een onderbroken bestand kan worden hervat in plaats van opnieuw te beginnen. Wat ik was vergeten, is dat de huidige migratiehandleiding van Microsoft specifiek waarschuwt dat /Z voorzichtig gebruikt moet worden, omdat de extra logging die nodig is voor de hervatbaarheid de kopieersnelheid aanzienlijk kan verminderen.

Mijn succesvolle run voor de muziekcollectie gebruikte uiteindelijk: robocopy "\\server\music" "\\UNAS-Pro-8\music" /E /MT:4 /R:2 /W:2 /COPY:DATX /DCOPY:DATX /XJ /TEE /LOG:"%USERPROFILE%\Desktop\synology-to-unas-DATX.log"

De samenvatting van deze run was:

• Totaal bestanden: 15.940
• Gekopieerd: 6.991
• Overgeslagen: 8.949
• Fouten: 0
• Bytes gekopieerd: 47,917 GB
• Snelheid: 187.185.171 Bytes/sec.

De run die bijna 48 GB aan resterende data kopieerde, haalde gemiddeld ongeveer 187 MB/sec, zonder fouten. Hoewel dit geen gecontroleerde benchmark was, was het verschil groot genoeg om te concluderen dat /Z niet langer standaard in mijn LAN-migratiecommando's thuishoort. Op een stabiel lokaal netwerk begin ik zonder deze optie en voeg ik deze pas toe als de functionaliteit echt nodig is.

De nuttigheid van /MT (Multithreading)

De /MT:n optie van Robocopy voert kopieën uit met meerdere threads. Het ondersteunt waarden van 1 tot 128, waarbij acht threads de standaard is als er geen getal wordt opgegeven. Microsoft wijst erop dat meer threads niet automatisch leiden tot een snellere migratie en adviseert om het aantal threads af te stemmen op de werklast.

Dit werd logisch toen ik stopte met denken dat /MT:4 betekende dat "één bestand vier keer zo snel" werd gekopieerd.

Stel je een muziekcollectie voor met duizenden bestanden. Er komt werk kijken bij het openen van een bestand, het aanmaken van het doelfiles, het lezen en schrijven van de inhoud, het verwerken van metadata en het sluiten ervan. Bij een single-threaded kopie zijn er momenten waarop het netwerk of de opslag moet wachten tot een van deze operaties is voltooid. Door meerdere bestanden tegelijkertijd te verwerken, kan Robocopy dit werk overlappen.

Voor deze specifieke collectie bleken vier threads optimaal. Zestien hielp niet merkbaar verder, en één thread was een verslechtering. Ik zou /MT niet als een magische waarde zien die in elk commando thuishoort; een map met 50.000 foto's vraagt immers om een andere werklast dan vier disk-images van 900 GB.

Daarnaast is er de kostenpost van logging. Microsoft adviseert om de output van Robocopy naar een logbestand te sturen bij multithreaded kopieën, en gebruikt in migratiehandleidingen switches zoals /NP, /NFL en /NDL wanneer doorvoersnelheid belangrijker is dan het zien scrollen van elke bestandsnaam.

Voor een migratie die ik niet actief volg, zou ik waarschijnlijk dit gebruiken: robocopy "\\server\share" "\\UNAS-Pro-8\share" /E /MT:4 /R:2 /W:2 /COPY:DATX /DCOPY:DATX /XJ /NP /NFL /NDL /LOG:"%USERPROFILE%\Desktop\nas-migration.log"

Grote bestanden en de valkuil van /J

Later begon ik met het kopiëren van bestanden van honderden gigabytes per stuk. Microsoft beschrijft /J als unbuffered I/O en beveelt dit aan voor grote bestanden, dus dat leek de logische keuze.

Met /J ingeschakeld vertraagde de NAS-naar-NAS overdracht echter dramatisch. Omdat ik een Windows-machine in het midden had, kon ik beide helften van de route apart testen. Ik kopieerde een van deze grote bestanden van de Synology naar mijn lokale machine; dat ging met ongeveer 250 MB/sec. De Synology was dus prima in staat om het bestand op hoge snelheid te lezen.

Ik verwijderde vervolgens /J uit het directe Robocopy-commando van Synology naar UNAS: robocopy "\\server\share" "\\UNAS-Pro-8\share" "huge-file.ext" /R:0 /W:0 /COPY:DATX /NP

En de snelheid keerde terug.

De conclusie is niet dat /J slecht is. Het is waarschijnlijk precies wat je wilt bij het kopiëren van lokale schijf naar lokale schijf. In dit geval was Windows echter tegelijkertijd aan het lezen van de ene SMB-server en schrijven naar de andere SMB-server, en op dit specifieke pad werkte buffered I/O veel beter. Dit is een goede herinnering dat command-line switches gedrag beschrijven, geen gegarandeerde prestatieverbeteringen.

De Synology was sneller dan gedacht (SMB Multichannel)

Op verschillende momenten gaf ik de verouderde Synology de schuld. Het is een oude machine met draaiende schijven, dus het was makkelijk om aan te nemen dat een paar honderd megabits per seconde alles was wat hij nog kon leveren. Toen herinnerde ik me dat de Synology vier 1 GbE-interfaces heeft en dat SMB 3 Multichannel ondersteunt.

SMB Multichannel stelt een SMB-sessie in staat om gelijktijdig meerdere netwerkpaden te gebruiken om de beschikbare bandbreedte te aggregeren. Windows maakt het eenvoudig om de actieve kanalen te inspecteren:

Get-SmbMultichannelConnection -ServerName server | Format-Table ServerName,Selected,ClientIpAddress,ServerIpAddress,ClientLinkSpeed,ServerLinkSpeed,CurrentChannels

Mijn machine rapporteerde dat alle vier de 1 GbE-interfaces op de Synology deelnamen aan de SMB-verbinding.

Mijn Windows-machine heeft momenteel een 2,5 GbE-adapter (10 gig komt eraan), en tijdens de snelle kopieeractie zag ik ongeveer 250 MB/sec binnenkomen vanaf de Synology. De Synology was dus niet beperkt tot de doorvoer van één gigabit Ethernet-verbinding; SMB Multichannel stond Windows toe om de vier beschikbare server-paden te gebruiken, terwijl de 2,5 GbE-link op de pc de beperkende factor werd.

Synology maakt hierbij een belangrijk onderscheid tussen SMB Multichannel en gewone link aggregation. Multichannel kan de SMB-prestaties voor één client verhogen door meerdere verbindingen te gebruiken, terwijl conventionele link aggregation over het algemeen gaat over de totale doorvoer over meerdere clients en services.

Ervaringen met rsync

Ik heb ook rsync geprobeerd. De Synology kan rsync leveren en UniFi Drive kan data ophalen van een rsync-server via de daemon-modus.

Ik testte dit met een aparte movie-share. Het werkte, maar ik haalde slechts ongeveer 67 MB/sec. Daarnaast zorgde het voor een mappenstructuur met extra nesting die ik achteraf had moeten opschonen.

Dit is geen argument dat rsync in het algemeen traag is, maar in deze specifieke Synology-naar-UNAS test was het het geval. Toen de Robocopy-route ongeveer 187 MB/sec haalde en exact de gewenste UNC-share structuur behield, was er weinig incentive om rsync als primair mechanisme te gebruiken.

Het resultaat was dat de indirecte route: Synology -> SMB -> Windows -> SMB -> UNAS aanzienlijk sneller was dan het direct laten overzetten van de twee NAS-apparaten via de rsync-implementatie van UniFi Drive. Mijn vermoeden is dat rsync geen gebruik maakte van de vier 1Gb-verbindingen.

Het uiteindelijke Robocopy-commando

Voor normale shares met veel bestanden is dit de versie waarmee ik nu zou beginnen:

robocopy "\\server\share" "\\UNAS-Pro-8\share" /E /MT:4 /R:2 /W:2 /COPY:DATX /DCOPY:DATX /XJ /NP /NFL /NDL /LOG:"%USERPROFILE%\Desktop\nas-migration.log"

De switches hebben de volgende functies:

• /E: Kopieer submappen, inclusief lege mappen.
• /MT:4: Gebruik vier threads voor het kopiëren.
• /R:2: Probeer een mislukte kopie twee keer opnieuw.
• /W:2: Wacht twee seconden tussen pogingen.
• /COPY:DATX: Kopieer data, attributen en tijdstempels, maar negeer ADS.
• /DCOPY:DATX: Pas dezelfde vlaggen toe op mappen.
• /XJ: Sluit junction points uit.
• /NP: Print geen percentage-voortgang.
• /NFL: Log niet elke bestandsnaam.
• /NDL: Log niet elke map.
• /LOG: Schrijf de output naar een bestand.

Ik heb bewust /Z weggelaten. Ook zou ik /J niet automatisch toevoegen; voor een workload die gedomineerd wordt door zeer grote bestanden zou ik eerst testen met en zonder deze optie. De waarde voor /MT is eveneens empirisch: vier werkte uitstekend hier, maar ik adviseer om te experimenteren met 1, 4 of 8 op basis van een representatief deel van de echte data.

Het resultaat controleren

Voor bestanden waarbij ik zeker wil weten dat de bestemming exact dezelfde bytes bevat als de bron, is PowerShell's Get-FileHash een handige laatste controle:

Get-FileHash "\\server\ nods\share\huge-file.ext" -Algorithm SHA256 Get-FileHash "\\UNAS-Pro-8\share\huge-file.ext" -Algorithm SHA256

Als de SHA-256 waarden overeenkomen, zijn de bestanden identiek. Voor enorme bestanden betekent dit dat het volledige bestand opnieuw gelezen moet worden aan beide kanten, dus ik doe dit alleen voor de meest waardevolle grote bestanden.

Conclusie

Wat deze migratie interessant maakte, was dat de symptomen meerdere plausibele verklaringen hadden. De UNAS heeft een nieuwe RAID-array, de Synology is oud, Windows fungeert als SMB-client in beide richtingen en de bestanden zijn over jaren door verschillende applicaties aangemaakt.

De uiteindelijke prestaties waren niet het resultaat van een "geheim snel Robocopy-commando" van een forum. Het kwam voort uit nadenken over welke functies ik daadwerkelijk nodig had en het verwijderen van functies die in andere scenario's nuttig zijn, maar in dit geval kostbaar waren.

/Z, /J en /MT zijn geen schuifregelaars voor prestaties; ze veranderen respectievelijk de hervatbaarheid, buffering en concurrency. Alternate Data Streams zijn echte data, zelfs als Explorer ze normaal gesproken verbergt. En SMB Multichannel kan een oude NAS met meerdere gigabit-interfaces veel krachtiger maken dan men op basis van één enkele Ethernet-poort zou vermoeden.