Migratie van Storsimple 1200 naar Azure File Sync

De StorSimple 1200-serie is een virtueel apparaat dat wordt uitgevoerd in een on-premises datacenter. Het is mogelijk om de gegevens van dit apparaat te migreren naar een Azure File Sync-omgeving. Azure File Sync is de standaard- en strategische Azure-service op lange termijn waarnaar StorSimple-apparaten kunnen worden gemigreerd. Dit artikel bevat de achtergrondkennis en migratiestappen voor een geslaagde migratie naar Azure File Sync.

Notitie

De StorSimple-service (inclusief de StorSimple-Apparaatbeheer voor de serie 8000 en 1200 en StorSimple Data Manager) heeft het einde van de ondersteuning bereikt. Het einde van de ondersteuning voor StorSimple is in 2019 gepubliceerd op de microsoft LifeCycle Policy - en Azure Communications-pagina's . Er zijn extra meldingen verzonden via e-mail en gepost in Azure Portal en in het StorSimple-overzicht. Neem contact op met Microsoft Ondersteuning voor meer informatie.

Van toepassing op

Bestands sharetype	SMB	NFS
Standaardbestandsshares (GPv2), LRS/ZRS
Standaardbestandsshares (GPv2), GRS/GZRS
Premium bestandsshares (FileStorage), LRS/ZRS

Azure File Sync

Azure File Sync is een Microsoft-cloudservice op basis van twee hoofdonderdelen:

• Bestandssynchronisatie en cloudlagen.
• Bestandsshares als systeemeigen opslag in Azure die toegankelijk zijn via meerdere protocollen, zoals SMB en FileREST. Een Azure-bestandsshare is vergelijkbaar met een bestandsshare op een Windows Server die u systeemeigen kunt koppelen als een netwerkstation. Het ondersteunt belangrijke aspecten van bestandskwaliteit, zoals kenmerken, machtigingen en tijdstempels. In tegenstelling tot StorSimple is er geen toepassing/service vereist voor het interpreteren van de bestanden en mappen die zijn opgeslagen in de cloud. De ideale en meest flexibele benadering is het opslaan van bestandsservergegevens voor algemeen gebruik en sommige toepassingsgegevens in de cloud.

Dit artikel is gericht op de migratiestappen. Als u meer wilt weten over Azure File Sync, raden we de volgende artikelen aan:

• Azure File Sync - overzicht
• Azure File Sync - implementatiehandleiding

Migratiedoelen

Het doel is om de integriteit van de productiegegevens te garanderen en de beschikbaarheid te garanderen. Dit laatste vereist dat downtime tot een minimum wordt beperkt, zodat deze in de normale onderhoudsvensters kan passen of slechts iets groter is dan de normale onderhoudsvensters.

Migratiepad StorSimple 1200 naar Azure File Sync

Een lokale Windows Server is vereist om een Azure File Sync-agent uit te voeren. De Windows Server kan minimaal een 2012R2-server zijn, maar idealiter een Windows Server 2019.

Er zijn talloze alternatieve migratiepaden en het zou te lang zijn voor een artikel om ze allemaal te documenteren en te illustreren waarom ze risico's of nadelen hebben ten opzichte van de route die we aanbevelen als aanbevolen procedure in dit artikel.

In de vorige afbeelding ziet u stappen die overeenkomen met secties in dit artikel.

Stap 1: Uw on-premises Windows Server en opslag inrichten

1. Maak een Windows Server 2019 - minimaal 2012R2 - als een virtuele machine (VM) of fysieke server. Een Windows Server-failovercluster wordt ook ondersteund.
2. Direct Attached Storage (DAS inrichten of toevoegen in vergelijking met NAS, wat niet wordt ondersteund). De grootte van de Windows Server-opslag moet gelijk zijn aan of groter zijn dan de grootte van de beschikbare capaciteit van uw virtuele StorSimple 1200-apparaat.

Stap 2: Uw Windows Server-opslag configureren

In deze stap wijst u uw StorSimple-opslagstructuur (volumes en shares) toe aan uw Windows Server-opslagstructuur. Als u van plan bent om wijzigingen aan te brengen in uw opslagstructuur, wat betekent dat het aantal volumes, de koppeling van gegevensmappen naar volumes of de submapstructuur boven of onder uw huidige SMB/NFS-shares ligt, is het nu de tijd om rekening te houden met deze wijzigingen. Het wijzigen van uw bestands- en mapstructuur nadat Azure File Sync is geconfigureerd, is lastig en moet worden vermeden. In dit artikel wordt ervan uitgegaan dat u 1:1 toedeelt, dus u moet rekening houden met uw toewijzingswijzigingen wanneer u de stappen in dit artikel volgt.

• Geen van uw productiegegevens moet eindigen op het Windows Server-systeemvolume. Cloudlagen worden niet ondersteund op systeemvolumes. Deze functie is echter vereist voor de migratie en continue bewerkingen als een StorSimple-vervanging.
• Richt hetzelfde aantal volumes in op uw Windows Server als op uw virtuele StorSimple 1200-apparaat.
• Configureer alle Windows Server-functies, -onderdelen en -instellingen die u nodig hebt. U wordt aangeraden windows Server-updates in te stellen om uw besturingssysteem veilig en up-to-date te houden. Op dezelfde manier raden we u aan om Microsoft Update te gebruiken om Microsoft-toepassingen up-to-date te houden, inclusief de Azure File Sync-agent.
• Configureer geen mappen of shares voordat u de volgende stappen leest.

Stap 3: De eerste Azure File Sync-cloudresource implementeren

U hebt uw Azure-abonnementsreferenties nodig om deze stap te voltooien.

De kernresource die moet worden geconfigureerd voor Azure File Sync wordt een opslagsynchronisatieservice genoemd. We raden u aan slechts één te implementeren voor alle servers die dezelfde set bestanden nu of in de toekomst synchroniseren. Maak alleen meerdere opslagsynchronisatieservices als u afzonderlijke sets servers hebt die nooit gegevens mogen uitwisselen. U hebt bijvoorbeeld servers die nooit dezelfde Azure-bestandsshare mogen synchroniseren. Anders is het gebruik van één opslagsynchronisatieservice de best practice.

Kies een Azure-regio voor uw opslagsynchronisatieservice die zich dicht bij uw locatie bevindt. Alle andere cloudresources moeten in dezelfde regio worden geïmplementeerd. Maak een nieuwe resourcegroep in uw abonnement waarin synchronisatie- en opslagresources zijn opgenomen om het beheer te vereenvoudigen.

Zie de sectie over het implementeren van de opslagsynchronisatieservice in het artikel over het implementeren van Azure File Sync voor meer informatie. Volg alleen deze sectie van het artikel. In latere stappen vindt u koppelingen naar andere secties van het artikel.

Stap 4: Koppel uw lokale volume- en mapstructuur aan Azure File Sync- en Azure-bestandsshareresources

In deze stap bepaalt u hoeveel Azure-bestandsshares u nodig hebt. Eén Windows Server-exemplaar (of cluster) kan maximaal 30 Azure-bestandsshares synchroniseren.

Mogelijk hebt u meer mappen op uw volumes die u momenteel lokaal deelt als SMB deelt met uw gebruikers en apps. De eenvoudigste manier om dit scenario voor te stellen, is door een on-premises share te maken die 1:1 toewijst aan een Azure-bestandsshare. Als u een klein aantal shares hebt, lager dan 30 voor één Exemplaar van Windows Server, raden we u aan een toewijzing van 1:1 uit te voeren.

Als u meer dan 30 shares hebt, is het toewijzen van een on-premises share 1:1 aan een Azure-bestandsshare vaak overbodig. Houd rekening met de volgende opties.

Groeperen delen

Als uw hr-afdeling bijvoorbeeld 15 shares heeft, kunt u overwegen om alle HR-gegevens op te slaan in één Azure-bestandsshare. Als u meerdere on-premises shares opslaat in één Azure-bestandsshare, voorkomt u niet dat u de gebruikelijke 15 SMB-shares maakt op uw lokale Windows Server-exemplaar. Dit betekent alleen dat u de hoofdmappen van deze 15 shares ordent als submappen onder een gemeenschappelijke map. Vervolgens synchroniseert u deze algemene map naar een Azure-bestandsshare. Op die manier is slechts één Azure-bestandsshare in de cloud nodig voor deze groep on-premises shares.

Volumesynchronisatie

Azure File Sync ondersteunt het synchroniseren van de hoofdmap van een volume naar een Azure-bestandsshare. Als u de hoofdmap van het volume synchroniseert, gaan alle submappen en bestanden naar dezelfde Azure-bestandsshare.

Het synchroniseren van de hoofdmap van het volume is niet altijd de beste optie. Het synchroniseren van meerdere locaties heeft voordelen. Als u dit bijvoorbeeld doet, blijft het aantal items lager per synchronisatiebereik. We testen Azure-bestandsshares en Azure File Sync met 100 miljoen items (bestanden en mappen) per share. Maar een best practice is om het aantal onder de 20 miljoen of 30 miljoen in één aandeel te houden. Het instellen van Azure File Sync met een lager aantal items is niet alleen nuttig voor bestandssynchronisatie. Een lager aantal items biedt ook voordelen voor scenario's zoals deze:

• De eerste scan van de cloudinhoud kan sneller worden voltooid, waardoor de wachttijd voor de naamruimte wordt verlaagd op een server die is ingeschakeld voor Azure File Sync.
• Herstel aan de cloudzijde vanuit een momentopname van een Azure-bestandsshare is sneller.
• Herstel na noodgevallen van een on-premises server kan aanzienlijk versnellen.
• Wijzigingen die rechtstreeks in een Azure-bestandsshare (buiten synchronisatie) zijn aangebracht, kunnen sneller worden gedetecteerd en gesynchroniseerd.

Tip

Als u niet weet hoeveel bestanden en mappen u hebt, bekijkt u het hulpprogramma TreeSize van JAM Software GmbH.

Een gestructureerde benadering van een implementatieoverzicht

Voordat u cloudopslag in een latere stap implementeert, is het belangrijk om een kaart te maken tussen on-premises mappen en Azure-bestandsshares. Met deze toewijzing wordt aangegeven hoeveel resources en welke Azure File Sync-synchronisatiegroepsbronnen u gaat inrichten. Een synchronisatiegroep verbindt de Azure-bestandsshare en de map op uw server en brengt een synchronisatieverbinding tot stand.

Bekijk de volgende limieten en aanbevolen procedures om te bepalen hoeveel Azure-bestandsshares u nodig hebt. Als u dit doet, kunt u uw kaart optimaliseren.

• Een server waarop de Azure File Sync-agent is geïnstalleerd, kan worden gesynchroniseerd met maximaal 30 Azure-bestandsshares.

• Een Azure-bestandsshare wordt geïmplementeerd in een opslagaccount. Deze rangschikking maakt het opslagaccount een schaaldoel voor prestatienummers zoals IOPS en doorvoer.

  Let op de IOPS-beperkingen van een opslagaccount bij het implementeren van Azure-bestandsshares. In het ideale geval moet u bestandsshares 1:1 toewijzen met opslagaccounts. Dit is echter mogelijk niet altijd mogelijk vanwege verschillende limieten en beperkingen, zowel van uw organisatie als van Azure. Wanneer het niet mogelijk is om slechts één bestandsshare in één opslagaccount te implementeren, moet u overwegen welke shares zeer actief zijn en welke shares minder actief zijn om ervoor te zorgen dat de heetste bestandsshares niet samen in hetzelfde opslagaccount worden geplaatst.

  Als u van plan bent om een app naar Azure op te tillen die de Azure-bestandsshare systeemeigen gebruikt, hebt u mogelijk meer prestaties nodig van uw Azure-bestandsshare. Als dit type gebruik een mogelijkheid is, zelfs in de toekomst, kunt u het beste één standaard Azure-bestandsshare maken in een eigen opslagaccount.

• Er geldt een limiet van 250 opslagaccounts per abonnement per Azure-regio.

Tip

Gezien deze informatie is het vaak nodig om meerdere mappen op het hoogste niveau op uw volumes te groeperen in een nieuwe algemene hoofdmap. Vervolgens synchroniseert u deze nieuwe hoofdmap en alle mappen die u erin hebt gegroepeerd, naar één Azure-bestandsshare. Met deze techniek kunt u binnen de limiet van 30 Azure-bestandssharesynchronisaties per server blijven.

Deze groepering onder een algemene hoofdmap heeft geen invloed op de toegang tot uw gegevens. Uw ACL's blijven zoals ze zijn. U hoeft alleen sharepaden (zoals SMB- of NFS-shares) aan te passen die u mogelijk hebt op de lokale servermappen die u nu hebt gewijzigd in een algemene hoofdmap. Niets anders verandert.

Belangrijk

De belangrijkste schaalvector voor Azure File Sync is het aantal items (bestanden en mappen) dat moet worden gesynchroniseerd. Bekijk de Azure File Sync-schaaldoelen voor meer informatie.

Het is een best practice om het aantal items per synchronisatiebereik laag te houden. Dat is een belangrijke factor om rekening mee te houden bij het toewijzen van mappen aan Azure-bestandsshares. Azure File Sync wordt getest met 100 miljoen items (bestanden en mappen) per share. Maar het is vaak het beste om het aantal items onder de 20 miljoen of 30 miljoen in één aandeel te houden. Splits uw naamruimte in meerdere shares als u deze getallen begint te overschrijden. U kunt meerdere on-premises shares blijven groeperen in dezelfde Azure-bestandsshare als u ongeveer onder deze getallen blijft. Deze praktijk geeft u ruimte om te groeien.

Het is mogelijk dat een set mappen in uw situatie logisch kan worden gesynchroniseerd met dezelfde Azure-bestandsshare (met behulp van de nieuwe veelgebruikte basismapbenadering die eerder is genoemd). Maar het is misschien nog beter om mappen opnieuw te groeperen, zodat ze worden gesynchroniseerd met twee in plaats van één Azure-bestandsshare. U kunt deze methode gebruiken om het aantal bestanden en mappen per bestandsshare verdeeld te houden over de server. U kunt uw on-premises shares ook splitsen en synchroniseren over meer on-premises servers, en de mogelijkheid toevoegen om te synchroniseren met 30 meer Azure-bestandsshares per extra server.

Veelvoorkomende scenario's en overwegingen voor bestandssynchronisatie

#	Synchronisatiescenario	Ondersteund	Overwegingen (of beperkingen)	Oplossing (of tijdelijke oplossing)
1	Bestandsserver met meerdere schijven/volumes en meerdere shares naar dezelfde Azure-bestandsshare (samenvoeging)	Nee	Een azure-doelbestandsshare (cloudeindpunt) ondersteunt alleen synchronisatie met één synchronisatiegroep. Een synchronisatiegroep ondersteunt slechts één servereindpunt per geregistreerde server.	1) Begin met het synchroniseren van één schijf (het hoofdvolume) naar de Azure-bestandsshare. Beginnend met de grootste schijf/het grootste volume helpt bij de opslagvereisten on-premises. Configureer cloudlagen om alle gegevens in de cloud te tieren, waardoor ruimte vrij is op de bestandsserverschijf. Verplaats gegevens van andere volumes/shares naar het huidige volume dat wordt gesynchroniseerd. Ga één voor één door met de stappen totdat alle gegevens zijn gelaagd tot in de cloud/gemigreerd. 2) Doel één hoofdvolume (schijf) tegelijk. Gebruik cloudlagen om alle gegevens in een laag te plaatsen voor de Azure-bestandsshare. Verwijder het servereindpunt uit de synchronisatiegroep, maak het eindpunt opnieuw met het volgende hoofdvolume/de volgende schijf, synchroniseer en herhaal het proces. Opmerking: mogelijk is het opnieuw installeren van de agent vereist. 3) Het gebruik van meerdere Doel-Azure-bestandsshares (hetzelfde of een ander opslagaccount op basis van prestatievereisten) aanbevelen
2	Bestandsserver met één volume en meerdere shares naar dezelfde Azure-bestandsshare (consolidatie)	Ja	Er kunnen niet meerdere servereindpunten per geregistreerde server worden gesynchroniseerd met dezelfde Azure-doelbestandsshare (hetzelfde als hierboven)	Synchroniseer de hoofdmap van het volume met meerdere shares of mappen op het hoogste niveau. Raadpleeg het concept groeperen delen en volumesynchronisatie voor meer informatie.
3	Bestandsserver met meerdere shares en/of volumes naar meerdere Azure-bestandsshares onder één opslagaccount (toewijzing van 1:1 share)	Ja	Eén Windows Server-exemplaar (of cluster) kan maximaal 30 Azure-bestandsshares synchroniseren. Een opslagaccount is een schaaldoel voor prestaties. IOPS en doorvoer worden gedeeld tussen bestandsshares. Houd het aantal items per synchronisatiegroep binnen 100 miljoen items (bestanden en mappen) per share. Idealiter is het raadzaam om onder de 20 of 30 miljoen per aandeel te blijven.	1) Gebruik meerdere synchronisatiegroepen (aantal synchronisatiegroepen = aantal Azure-bestandsshares om mee te synchroniseren). 2) In dit scenario kunnen slechts 30 shares tegelijk worden gesynchroniseerd. Als u meer dan 30 shares op die bestandsserver hebt, gebruikt u het concept sharegroepering en volumesynchronisatie om het aantal hoofdmappen of mappen op het hoogste niveau bij de bron te verminderen. 3) Gebruik aanvullende bestandssynchronisatieservers on-premises en splits/verplaats gegevens naar deze servers om beperkingen op de Windows-bronserver te omzeilen.
4	Bestandsserver met meerdere shares en/of volumes naar meerdere Azure-bestandsshares onder een ander opslagaccount (toewijzing van 1:1 share)	Ja	Eén Windows Server-exemplaar (of cluster) kan maximaal 30 Azure-bestandsshares (hetzelfde of een ander opslagaccount) synchroniseren. Houd het aantal items per synchronisatiegroep binnen 100 miljoen items (bestanden en mappen) per share. Idealiter is het raadzaam om onder de 20 of 30 miljoen per aandeel te blijven.	Dezelfde benadering als hierboven
5	Meerdere bestandsservers met één (hoofdvolume of share) met dezelfde Azure-bestandsshare (samenvoeging)	Nee	Een synchronisatiegroep kan geen cloudeindpunt (Azure-bestandsshare) gebruiken dat al is geconfigureerd in een andere synchronisatiegroep. Hoewel een synchronisatiegroep servereindpunten op verschillende bestandsservers kan hebben, kunnen de bestanden niet verschillen.	Volg de richtlijnen in scenario 1 hierboven met extra aandacht voor het instellen van één bestandsserver tegelijk.

Een toewijzingstabel maken

Gebruik de vorige informatie om te bepalen hoeveel Azure-bestandsshares u nodig hebt en in welke delen van uw bestaande gegevens de Azure-bestandsshare terechtkomt.

Maak een tabel waarin uw gedachten worden vastgelegd, zodat u ernaar kunt verwijzen wanneer dat nodig is. Georganiseerd blijven is belangrijk omdat u eenvoudig details van uw toewijzingsplan kwijtraakt wanneer u veel Azure-resources tegelijk inricht. Download het volgende Excel-bestand om te gebruiken als sjabloon om uw toewijzing te helpen maken.

Download een sjabloon voor naamruimtetoewijzing.

Stap 5: Azure-bestandsshares inrichten

Een Azure-bestandsshare wordt opgeslagen in de cloud in een Azure-opslagaccount. Hier is een ander prestatieniveau van toepassing.

Als u zeer actieve shares hebt (shares die door veel gebruikers en/of toepassingen worden gebruikt), kunnen twee Azure-bestandsshares de prestatielimiet van een opslagaccount bereiken.

Een best practice is het implementeren van opslagaccounts met één bestandsshare. U kunt meerdere Azure-bestandsshares in hetzelfde opslagaccount groeperen als u archiveringsshares hebt of als u een lage dagelijkse activiteit verwacht.

Deze overwegingen zijn meer van toepassing op directe cloudtoegang (via een Azure-VM) dan op Azure File Sync. Als u van plan bent om alleen Azure File Sync op deze shares te gebruiken, is het prima om meerdere te groeperen in één Azure-opslagaccount.

Als u een lijst met uw shares hebt gemaakt, moet u elke share toewijzen aan het opslagaccount waarin deze zich bevinden.

In de vorige fase hebt u het juiste aantal shares bepaald. In deze stap hebt u een toewijzing van opslagaccounts aan bestandsshares. Implementeer nu het juiste aantal Azure-opslagaccounts met het juiste aantal Azure-bestandsshares erin.

Zorg ervoor dat de regio van elk van uw opslagaccounts hetzelfde is en overeenkomt met de regio van de opslagsynchronisatieserviceresource die u al hebt geïmplementeerd.

Let op

Als u een Azure-bestandsshare met een limiet van 100 TiB maakt, kan die share alleen lokaal redundante opslag of zone-redundante opslagredundantieopties gebruiken. Houd rekening met uw opslagredundantie voordat u 100 TiB-bestandsshares gebruikt.

Azure-bestandsshares worden standaard nog steeds gemaakt met een limiet van 5 TiB. Volg de stappen in Een Azure-bestandsshare maken om een grote bestandsshare te maken.

Een andere overweging bij het implementeren van een opslagaccount is de redundantie van Azure Storage. Zie de opties voor Azure Storage-redundantie.

De namen van uw resources zijn ook belangrijk. Als u bijvoorbeeld meerdere shares voor de HR-afdeling groeperen in een Azure-opslagaccount, moet u het opslagaccount de juiste naam opgeven. Op dezelfde manier moet u, wanneer u uw Azure-bestandsshares een naam krijgt, namen gebruiken die vergelijkbaar zijn met de namen die zijn gebruikt voor hun on-premises tegenhangers.

Instellingen voor een opslagaccount

Er zijn veel configuraties die u kunt maken in een opslagaccount. De volgende controlelijst moet worden gebruikt voor de configuratie van uw opslagaccount. U kunt bijvoorbeeld de netwerkconfiguratie wijzigen nadat de migratie is voltooid.

• Firewall en virtuele netwerken: uitgeschakeld: configureer geen IP-beperkingen of beperk de toegang tot een specifiek virtueel netwerk. Het openbare eindpunt van het opslagaccount wordt gebruikt tijdens de migratie. Alle IP-adressen van Virtuele Azure-machines moeten zijn toegestaan. U kunt het beste firewallregels voor het opslagaccount configureren na de migratie.
• Privé-eindpunten: ondersteund: u kunt privé-eindpunten inschakelen, maar het openbare eindpunt wordt gebruikt voor de migratie en moet beschikbaar blijven.

Stap 6: Doelmappen voor Windows Server configureren

In de vorige stappen hebt u alle aspecten overwogen die de onderdelen van uw synchronisatietopologieën bepalen. Nu is het tijd om de server voor te bereiden op het ontvangen van bestanden voor uploaden.

Maak alle mappen die elk worden gesynchroniseerd met hun eigen Azure-bestandsshare. Het is belangrijk dat u de mapstructuur volgt die u eerder hebt gedocumenteerd. Als u bijvoorbeeld hebt besloten om meerdere lokale SMB-shares te synchroniseren in één Azure-bestandsshare, moet u deze onder een gemeenschappelijke hoofdmap op het volume plaatsen. Maak nu deze doelhoofdmap op het volume.

Het aantal Azure-bestandsshares dat u inricht, moet overeenkomen met het aantal mappen dat u in deze stap hebt gemaakt, plus het aantal volumes dat u wilt synchroniseren op hoofdniveau.

Stap 7: De Azure File Sync-agent implementeren

In deze sectie installeert u de Azure File Sync-agent op uw Windows Server-exemplaar.

In de implementatiehandleiding wordt uitgelegd dat u verbeterde beveiliging van Internet Explorer moet uitschakelen. Deze beveiligingsmaatregel is niet van toepassing op Azure File Sync. Als u dit uitschakelt, kunt u zonder problemen verifiëren bij Azure.

Open PowerShell. Installeer de vereiste PowerShell-modules met behulp van de volgende opdrachten. Installeer de volledige module en de NuGet-provider wanneer u hierom wordt gevraagd.

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

Als u problemen ondervindt met het bereiken van internet vanaf uw server, is het nu de tijd om ze op te lossen. Azure File Sync maakt gebruik van een beschikbare netwerkverbinding met internet. Het vereisen van een proxyserver om internet te bereiken, wordt ook ondersteund. U kunt nu een proxy voor de hele machine configureren of tijdens de installatie van de agent een proxy opgeven die alleen door Azure File Sync wordt gebruikt.

Als het configureren van een proxy betekent dat u uw firewalls voor de server moet openen, is deze benadering mogelijk acceptabel voor u. Nadat u de serverregistratie hebt voltooid, ziet u aan het einde van de serverinstallatie de exacte eindpunt-URL's in Azure waarmee Azure File Sync moet communiceren voor de regio die u hebt geselecteerd. Het rapport geeft ook aan waarom communicatie nodig is. U kunt het rapport gebruiken om de firewalls rond de server te vergrendelen voor specifieke URL's.

U kunt ook een meer conservatieve benadering gebruiken waarbij u de firewalls niet breed opent. U kunt in plaats daarvan de server beperken om te communiceren met DNS-naamruimten op een hoger niveau. Zie azure File Sync-proxy- en firewallinstellingen voor meer informatie. Volg uw eigen best practices voor netwerken.

Aan het einde van de installatiewizard van de server wordt een wizard serverregistratie geopend. Registreer de server bij de Azure-resource van uw opslagsynchronisatieservice van eerder.

Deze stappen worden uitgebreid beschreven in de implementatiehandleiding, waaronder de PowerShell-modules die u als eerste moet installeren: installatie van de Azure File Sync-agent.

Gebruik de nieuwste agent. U kunt het downloaden via het Microsoft Downloadcentrum: Azure File Sync Agent.

Na een geslaagde installatie en serverregistratie kunt u bevestigen dat u deze stap hebt voltooid. Ga naar de opslagsynchronisatieserviceresource in Azure Portal. Ga in het linkermenu naar Geregistreerde servers. U ziet dat uw server daar wordt vermeld.

Stap 8: Synchronisatie configureren

Deze stap verbindt alle resources en mappen die u tijdens de vorige stappen hebt ingesteld op uw Windows Server-exemplaar.

1. Meld u aan bij het Azure-portaal.
2. Zoek de opslagsynchronisatieserviceresource.
3. Maak een nieuwe synchronisatiegroep in de Storage Sync Service-resource voor elke Azure-bestandsshare. In Azure File Sync-terminologie wordt de Azure-bestandsshare een cloudeindpunt in de synchronisatietopologie die u beschrijft met het maken van een synchronisatiegroep. Wanneer u de synchronisatiegroep maakt, geeft u deze een vertrouwde naam zodat u kunt herkennen welke set bestanden daar wordt gesynchroniseerd. Zorg ervoor dat u verwijst naar de Azure-bestandsshare met een overeenkomende naam.
4. Nadat u de synchronisatiegroep hebt gemaakt, wordt er een rij voor deze weergegeven in de lijst met synchronisatiegroepen. Selecteer de naam (een koppeling) om de inhoud van de synchronisatiegroep weer te geven. U ziet uw Azure-bestandsshare onder Cloud-eindpunten.
5. Zoek de knop Servereindpunt toevoegen. De map op de lokale server die u hebt ingericht, wordt het pad voor dit servereindpunt.

Waarschuwing

Zorg ervoor dat u cloudlagen inschakelt. Dit is vereist als uw lokale server niet voldoende ruimte heeft om de totale grootte van uw gegevens op te slaan in de StorSimple-cloudopslag. Stel uw laagbeleid tijdelijk in op 99% vrije ruimte voor volumes en wijzig het in een redelijker niveau nadat de migratie is voltooid.

Herhaal de stappen voor het maken en toevoegen van de overeenkomende servermap als een servereindpunt voor alle Azure-bestandsshares/-serverlocaties die moeten worden geconfigureerd voor synchronisatie.

Stap 9: Uw bestanden kopiëren

De basismigratiebenadering is een RoboCopy van uw virtuele StorSimple-apparaat naar uw Windows Server en Azure File Sync naar Azure-bestandsshares.

Voer de eerste lokale kopie uit naar de doelmap van Windows Server:

• Identificeer de eerste locatie op uw virtuele StorSimple-apparaat.
• Identificeer de overeenkomende map op de Windows Server waarop Azure File Sync al is geconfigureerd.
• De kopie starten met RoboCopy

Met de volgende RoboCopy-opdracht worden bestanden uit uw StorSimple Azure-opslag teruggehaald naar uw lokale StorSimple en verplaatst u ze vervolgens naar de doelmap van Windows Server. De Windows Server synchroniseert deze met de Azure-bestandsshare(s). Naarmate het lokale Windows Server-volume vol raakt, worden cloudlagen geactiveerd en worden bestanden gelaagd die al zijn gesynchroniseerd. Met cloudlagen wordt voldoende ruimte gegenereerd om de kopie van het virtuele StorSimple-apparaat voort te zetten. In cloudlagen wordt eenmaal per uur gecontroleerd wat er is gesynchroniseerd en om schijfruimte vrij te maken om de vrije ruimte van 99% te bereiken.

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> 

Switch	Betekenis
/MT:n	Met Robocopy kunnen meerdere threads worden uitgevoerd. De standaardwaarde n is 8. Het maximum is 128 threads. Hoewel een hoog aantal threads helpt de beschikbare bandbreedte te verzadigen, betekent dit niet dat uw migratie altijd sneller is met meer threads. Tests met Azure Files geven aan dat tussen 8 en 20 evenwichtige prestaties worden weergegeven voor een eerste kopieerbewerking. Volgende /MIR uitvoeringen worden geleidelijk beïnvloed door de beschikbare rekenkracht versus de beschikbare netwerkbandbreedte. Voor volgende uitvoeringen moet u de waarde van het aantal threads nauwkeuriger overeen laten komen met het aantal processorkernen en het aantal threads per kern. Overweeg of kernen moeten worden gereserveerd voor andere taken die een productieserver mogelijk heeft. Tests met Azure Files hebben aangetoond dat maximaal 64 threads een goede prestaties opleveren, maar alleen als uw processors ze tegelijkertijd in leven kunnen houden.
/R:n	Het Maximum aantal nieuwe pogingen voor een bestand dat niet kan worden gekopieerd bij de eerste poging. Robocopy probeert n tijden voordat het bestand permanent niet kan worden gekopieerd in de uitvoering. U kunt de prestaties van uw uitvoering optimaliseren: kies een waarde van twee of drie als u denkt dat time-outproblemen in het verleden fouten hebben veroorzaakt. Dit kan vaker voorkomen via WAN-koppelingen. Kies geen nieuwe poging of een waarde als u denkt dat het bestand niet kan worden gekopieerd omdat het actief in gebruik was. Als u het een paar seconden later opnieuw probeert, is het mogelijk niet voldoende om de status in gebruik van het bestand te wijzigen. Gebruikers of apps die het bestand openen houden, hebben mogelijk uren meer tijd nodig. In dit geval is het accepteren van het bestand niet gekopieerd en in een van uw geplande, volgende Robocopy-uitvoeringen, mogelijk geslaagd om het bestand uiteindelijk te kopiëren. Dit helpt de huidige uitvoering sneller te voltooien zonder te worden verlengd door veel nieuwe pogingen die uiteindelijk in een meerderheid van de kopieerfouten terechtkomen omdat bestanden nog steeds zijn geopend na de time-out voor opnieuw proberen.
/W:n	Specificeert de tijd dat Robocopy wacht voordat wordt geprobeerd een bestand te kopiëren dat niet is gekopieerd tijdens een vorige poging. n is het aantal seconden dat moet worden gewacht tussen nieuwe pogingen. /W:n wordt vaak samen met /R:n.
/B	Voert Robocopy uit in dezelfde modus die een back-uptoepassing zou gebruiken. Met deze switch kan Robocopy bestanden verplaatsen waarvoor de huidige gebruiker geen machtigingen heeft. De back-upswitch is afhankelijk van het uitvoeren van de Robocopy-opdracht in een console met verhoogde beheerdersrechten of PowerShell-venster. Als u Robocopy voor Azure Files gebruikt, moet u ervoor zorgen dat u de Azure-bestandsshare koppelt met behulp van de toegangssleutel voor het opslagaccount versus een domeinidentiteit. Als u dat niet doet, leiden de foutberichten mogelijk niet intuïtief tot een oplossing van het probleem.
/MIR	(Sspiegelen van bron naar doel.) Hiermee kan Robocopy alleen delta's kopiëren tussen bron en doel. Lege submappen worden gekopieerd. Items (bestanden of mappen) die zijn gewijzigd of die niet bestaan in het doel, worden gekopieerd. Items die aanwezig zijn in het doel, maar niet in de bron, worden opgeschoond (verwijderd) uit het doel. Wanneer u deze switch gebruikt, moeten de bron- en doelmapstructuren exact overeenkomen. Vergelijking betekent dat u kopieert van het juiste bron- en mapniveau naar het overeenkomende mapniveau op het doel. Alleen dan kan een 'inhaalkopie' succesvol zijn. Wanneer de bron en het doel niet overeenkomen, leidt het gebruik /MIR tot grootschalige verwijderingen en nieuwe bereiken.
/IT	Zorgt dat de betrouwbaarheid behouden blijft in bepaalde spiegelscenario's. Als een bestand bijvoorbeeld een wijziging in een ACL en een kenmerkupdate tussen twee Robocopy-uitvoeringen ondervindt, wordt het gemarkeerd als verborgen. Zonder /ITkan de ACL-wijziging worden gemist door Robocopy en niet worden overgedragen naar de doellocatie.
/COPY:[copyflags]	De fidelity van de kopie van het bestand. Standaard: /COPY:DAT. Copy flags: D= Data, A= Attributes, T= Timestamps, S= Security = NTFS ACL's, O= Owner information, U= Auditing information. Controlegegevens kunnen niet worden opgeslagen in een Azure-bestandsshare.
/DCOPY:[copyflags]	Fidelity voor de kopie van mappen. Standaard: /DCOPY:DA. Copy flags: D= Data, A= Attributes, T= Timestamps.
/NP	Geeft aan dat de voortgang van de kopie voor elk bestand en elke map niet wordt weergegeven. Als de voortgang wordt weergegeven, zullen de prestaties aanzienlijk verminderen.
/NFL	Hiermee geeft u op dat bestandsnamen niet aan het logboek moeten worden toegevoegd. Verbetert de kopieerprestaties.
/NDL	Hiermee geeft u op dat mapnamen niet aan het logboek moeten worden toegevoegd. Verbetert de kopieerprestaties.
/XD	Hiermee geeft u mappen die moeten worden uitgesloten. Wanneer Robocopy wordt uitgevoerd op de hoofdmap van een volume, kunt u overwegen om de verborgen System Volume Information map uit te sluiten. Indien gebruikt zoals ontworpen, is alle informatie in die informatie specifiek voor het exacte volume op dit exacte systeem en kan worden herbouwd op aanvraag. Het kopiëren van deze informatie is niet handig in de cloud of wanneer de gegevens ooit worden gekopieerd naar een ander Windows-volume. Als u deze inhoud achterlaat, mag niet worden beschouwd als gegevensverlies.
/UNILOG:<file name>	Hiermee wordt de status naar het logboekbestand geschreven als Unicode. (Hiermee wordt het bestaande logboek overschreven.)
/L	Alleen voor een testuitvoeringsbestanden worden alleen weergegeven. Ze worden niet gekopieerd, niet verwijderd en krijgen geen tijdstempel. Vaak gebruikt met /TEE voor console-uitvoer. Vlaggen uit het voorbeeldscript, zoals /NP, /NFLen /NDL, moeten mogelijk worden verwijderd om u goed gedocumenteerde testresultaten te bereiken.
/LFSM	Alleen voor doelen met gelaagde opslag. Niet ondersteund wanneer de bestemming een externe SMB-share is. Hiermee geeft u op dat Robocopy werkt in de modus 'weinig vrije ruimte'. Deze switch is alleen nuttig voor doelen met gelaagde opslag die mogelijk geen lokale capaciteit meer heeft voordat Robocopy is voltooid. Het is specifiek toegevoegd voor gebruik met een doel dat is ingeschakeld voor opslag in cloudlagen van Azure File Sync. Het kan onafhankelijk van Azure File Sync worden gebruikt. In deze modus wordt Robocopy onderbroken wanneer een bestandskopie ervoor zorgt dat de vrije ruimte van het doelvolume onder de 'bodem'-waarde gaat. Deze waarde kan worden opgegeven door de /LFSM:n vorm van de vlag. De parameter n is opgegeven in basis 2: nKB, nMBof nGB. Als /LFSM deze is opgegeven zonder expliciete vloerwaarde, wordt de vloer ingesteld op 10 procent van de grootte van het doelvolume. De modus Weinig vrije ruimte is niet compatibel met /MT, /EFSRAWof /ZB. Ondersteuning voor /B is toegevoegd in Windows Server 2022. Zie de sectie Windows Server 2022 en RoboCopy LFSM hieronder voor meer informatie over een gerelateerde fout en tijdelijke oplossing.
/Z	Gebruik voorzichtig Bestanden kopiëren in de modus voor opnieuw opstarten. Deze switch wordt alleen aanbevolen in een instabiele netwerkomgeving. Het vermindert de kopieerprestaties aanzienlijk vanwege extra logboekregistratie.
/ZB	Gebruik voorzichtig de modus Opnieuw opstarten. Deze optie gebruikt de back-upmodus als de toegang is geweigerd. Deze optie vermindert de kopieerprestaties aanzienlijk vanwege controlepunten.

Belangrijk

U wordt aangeraden een Windows Server 2022 te gebruiken. Wanneer u een Windows Server 2019 gebruikt, moet u ervoor zorgen dat op het laatste patchniveau of ten minste KB5005103 besturingssysteemupdate is geïnstalleerd. Het bevat belangrijke oplossingen voor bepaalde Robocopy-scenario's.

Wanneer u de RoboCopy-opdracht voor het eerst uitvoert, hebben uw gebruikers en toepassingen nog steeds toegang tot de StorSimple-bestanden en -mappen en kunnen ze mogelijk wijzigingen aanbrengen. Het is mogelijk dat RoboCopy een map heeft verwerkt, naar de volgende map is verplaatst en vervolgens een gebruiker op de bronlocatie (StorSimple) een bestand toevoegt, wijzigt of verwijdert dat nu niet wordt verwerkt in deze huidige RoboCopy-uitvoering. Dat is prima.

De eerste uitvoering gaat over het verplaatsen van het grootste deel van de gegevens naar on-premises, naar uw Windows Server en het maken van back-ups naar de cloud via Azure File Sync. Dit kan lang duren, afhankelijk van:

• uw downloadbandbreedte
• de intrekkingssnelheid van de StorSimple-cloudservice
• de uploadbandbreedte
• het aantal items (bestanden en mappen) dat door een van beide services moet worden verwerkt

Zodra de eerste uitvoering is voltooid, voert u de opdracht opnieuw uit.

De tweede keer dat het sneller wordt voltooid, omdat het alleen wijzigingen moet transporteren die zijn opgetreden sinds de laatste uitvoering. Deze wijzigingen zijn waarschijnlijk al lokaal voor de StorSimple, omdat ze recent zijn. Dit vermindert de tijd verder omdat de noodzaak van terugroepen vanuit de cloud wordt verminderd. Nog steeds kunnen er nieuwe wijzigingen worden verzameld tijdens deze tweede uitvoering.

Herhaal dit proces totdat u tevreden bent dat de benodigde tijd een acceptabele hoeveelheid downtime is.

Wanneer u rekening houdt met de acceptabele downtime en u bereid bent om de StorSimple-locatie offline te halen, doet u dit nu. Verwijder bijvoorbeeld de SMB-share zodat geen gebruiker toegang heeft tot de map of voer een andere geschikte stap uit om te voorkomen dat inhoud in deze map op StorSimple kan worden gewijzigd.

Voer een laatste RoboCopy-ronde uit. Hiermee worden eventuele wijzigingen opgehaald die mogelijk zijn gemist. Hoe lang deze laatste stap duurt, is afhankelijk van de snelheid van de RoboCopy-scan. U kunt een schatting maken van de tijd (die gelijk is aan uw downtime) door te meten hoe lang de vorige uitvoering duurde.

Maak een share in de map Windows Server en pas de DFS-N-implementatie mogelijk aan zodat deze verwijst. Zorg ervoor dat u dezelfde machtigingen op shareniveau instelt als voor uw StorSimple SMB-share.

U bent nu klaar met het migreren van een share of groep shares naar een gemeenschappelijke hoofdmap of -volume, afhankelijk van wat u eerder hebt toegewezen.

U kunt proberen een aantal van deze kopieën parallel uit te voeren. Het is raadzaam om het bereik van één Azure-bestandsshare tegelijk te verwerken.

Waarschuwing

Zodra u alle gegevens van u StorSimple naar de Windows Server hebt verplaatst en uw migratie is voltooid: Ga terug naar alle synchronisatiegroepen in Azure Portal en pas de waarde van het volume vrije ruimtepercentage in cloudlagen aan op iets dat beter geschikt is voor cachegebruik, bijvoorbeeld 20%.

Het beleid voor vrije ruimte in cloudlagen fungeert op volumeniveau met mogelijk meerdere servereindpunten die ermee worden gesynchroniseerd. Als u vergeet de vrije ruimte op zelfs één servereindpunt aan te passen, blijft de synchronisatie de meest beperkende regel toepassen en probeert 99% vrije schijfruimte te behouden en wordt de lokale cache niet uitgevoerd zoals verwacht. Tenzij het uw doel is om alleen de naamruimte te hebben voor een volume dat alleen zelden toegankelijk is, archiveringsgegevens, moet u het beleid voor vrije ruimte op elk servereindpunt aanpassen.

Problemen oplossen

Het meest waarschijnlijke probleem dat u kunt tegenkomen, is dat de RoboCopy-opdracht mislukt met 'Volume vol' aan de zijde van Windows Server. Als dat gebeurt, is uw downloadsnelheid waarschijnlijk beter dan uw uploadsnelheid. Opslag in cloudlagen werkt één keer per uur om inhoud te evacueren vanaf de lokale Windows Server-schijf die is gesynchroniseerd.

Laat de voortgang van de synchronisatie en opslag in cloudlagen schijfruimte vrijmaken. U kunt dat zien in Bestandenverkenner op uw Windows Server.

Wanneer uw Windows Server voldoende beschikbare capaciteit heeft, wordt het probleem opgelost door de opdracht opnieuw uit te voeren. Niets breekt als je in deze situatie komt en je kunt met vertrouwen verder gaan. Het ongemak van het opnieuw uitvoeren van de opdracht is het enige gevolg.

Mogelijk ondervindt u ook andere problemen met Azure File Sync. Als dat gebeurt, raadpleegt u de handleiding voor het oplossen van problemen met Azure File Sync.

Snelheid en slagingspercentage van een bepaalde RoboCopy-uitvoering zijn afhankelijk van verschillende factoren:

• IOPS op de bron- en doelopslag
• de beschikbare netwerkbandbreedte tussen bron en doel
• de mogelijkheid om bestanden en mappen in een naamruimte snel te verwerken
• het aantal wijzigingen tussen RoboCopy-uitvoeringen
• de grootte en het aantal bestanden dat u moet kopiëren

Overwegingen voor IOPS en bandbreedte

In deze categorie moet u rekening houden met de mogelijkheden van de bronopslag, de doelopslag en het netwerk waarmee ze worden verbonden. De maximale doorvoer wordt bepaald door de traagste van deze drie onderdelen. Zorg ervoor dat uw netwerkinfrastructuur is geconfigureerd ter ondersteuning van optimale overdrachtssnelheden naar de beste mogelijkheden.

Let op

Hoewel kopiëren zo snel mogelijk mogelijk is, is vaak het meest gewenst, kunt u het gebruik van uw lokale netwerk en NAS-apparaat overwegen voor andere, vaak bedrijfskritieke taken.

Het kopiëren zo snel mogelijk is mogelijk niet wenselijk wanneer er een risico bestaat dat de migratie beschikbare resources kan in beslag kunnen maken.

• Overweeg wanneer het het beste in uw omgeving is om migraties uit te voeren: overdag, buiten kantooruren of in het weekend.
• Overweeg ook QoS te netwerken op een Windows Server om de RoboCopy-snelheid te beperken.
• Vermijd onnodig werk voor de migratiehulpprogramma's.

RoboCopy kan vertragingen tussen pakketten invoegen door de /IPG:n switch op te geven waar n wordt gemeten in milliseconden tussen RoboCopy-pakketten. Het gebruik van deze switch kan helpen bij het vermijden van het gebruik van resources op zowel I/O-beperkte apparaten als overvolle netwerkkoppelingen.

/IPG:n kan niet worden gebruikt voor nauwkeurige netwerkbeperking tot een bepaalde Mbps. Gebruik in plaats daarvan QoS voor Windows Server-netwerk. RoboCopy is volledig afhankelijk van het SMB-protocol voor alle netwerkbehoeften. Het gebruik van SMB is de reden waarom RoboCopy de netwerkdoorvoer zelf niet kan beïnvloeden, maar het gebruik ervan kan vertragen.

Een vergelijkbare gedachteregel is van toepassing op de IOPS die op de NAS is waargenomen. De clustergrootte op het NAS-volume, pakketgrootten en een matrix van andere factoren beïnvloeden de waargenomen IOPS. Het introduceren van vertraging tussen pakketten is vaak de eenvoudigste manier om de belasting van de NAS te beheren. Test meerdere waarden, bijvoorbeeld van ongeveer 20 milliseconden (n=20) naar veelvouden van dat getal. Zodra u een vertraging hebt geïntroduceerd, kunt u evalueren of uw andere apps nu naar verwachting kunnen werken. Met deze optimalisatiestrategie kunt u de optimale RoboCopy-snelheid in uw omgeving vinden.

Verwerkingssnelheid

RoboCopy doorkruist de naamruimte waarnaar wordt verwezen en evalueert elk bestand en elke map voor kopiëren. Elk bestand wordt geëvalueerd tijdens een eerste kopie en tijdens inhaalkopieën. Herhaalde uitvoeringen van RoboCopy /MIR op dezelfde bron- en doelopslaglocaties. Deze herhaalde uitvoeringen zijn handig om downtime voor gebruikers en apps te minimaliseren en om het algehele slagingspercentage van gemigreerde bestanden te verbeteren.

Er wordt vaak standaard rekening gehouden met bandbreedte als de meest beperkende factor in een migratie, en dat kan waar zijn. Maar de mogelijkheid om een naamruimte op te sommen, kan de totale tijd beïnvloeden om nog meer te kopiëren voor grotere naamruimten met kleinere bestanden. Houd er rekening mee dat het kopiëren van 1 TiB van kleine bestanden aanzienlijk langer duurt dan het kopiëren van 1 TiB van minder maar grotere bestanden, ervan uitgaande dat alle andere variabelen hetzelfde blijven. Daarom kan er sprake zijn van trage overdracht als u een groot aantal kleine bestanden migreert. Dit is normaal gedrag.

De oorzaak van dit verschil is de verwerkingskracht die nodig is om een naamruimte te doorlopen. RoboCopy ondersteunt kopieën met meerdere threads via de /MT:n parameter waarbij n staat voor het aantal threads dat moet worden gebruikt. Houd bij het inrichten van een machine die specifiek is bedoeld voor RoboCopy, rekening met het aantal processorkernen en de relatie met het aantal threads dat ze bieden. De meest voorkomende zijn twee threads per kern. Het aantal kernen en threads van een machine is een belangrijk gegevenspunt om te bepalen welke waarden voor meerdere threads /MT:n u moet opgeven. Overweeg ook hoeveel RoboCopy-taken u parallel wilt uitvoeren op een bepaalde computer.

Meer threads kopiëren ons 1 TiB-voorbeeld van kleine bestanden aanzienlijk sneller dan minder threads. Tegelijkertijd levert de extra investering op onze 1 TiB van grotere bestanden mogelijk geen proportionele voordelen op. Een hoog aantal threads probeert tegelijkertijd meer grote bestanden via het netwerk te kopiëren. Deze extra netwerkactiviteit verhoogt de kans dat de doorvoer- of opslag-IOPS wordt beperkt.

Tijdens een eerste RoboCopy in een leeg doel of een differentiële uitvoering met veel gewijzigde bestanden, bent u waarschijnlijk beperkt door de netwerkdoorvoer. Begin met een hoog aantal threads voor een eerste uitvoering. Een hoog aantal threads, zelfs buiten de momenteel beschikbare threads op de machine, helpt de beschikbare netwerkbandbreedte te verzadigen. Volgende /MIR-uitvoeringen worden geleidelijk beïnvloed door het verwerken van items. Minder wijzigingen in een differentiële uitvoering betekenen minder transport van gegevens via het netwerk. Uw snelheid is nu afhankelijk van de mogelijkheid om naamruimteitems te verwerken dan ze via de netwerkkoppeling te verplaatsen. Voor volgende uitvoeringen moet u de waarde voor het aantal threads vergelijken met het aantal processorkernen en het aantal threads per kern. Overweeg of kernen moeten worden gereserveerd voor andere taken die een productieserver mogelijk heeft.

Tip

Vuistregel: De eerste RoboCopy-uitvoering die veel gegevens van een netwerk met een hogere latentie verplaatst, profiteert van het over-inrichten van het aantal threads (/MT:n). Volgende uitvoeringen kopiëren minder verschillen en de kans is groter dat de netwerkdoorvoer wordt beperkt tot de rekenbeperking. Onder deze omstandigheden is het vaak beter om het aantal RoboCopy-threads te vergelijken met de daadwerkelijk beschikbare threads op de machine. Overinrichting in dat scenario kan leiden tot meer contextverschuivingen in de processor, waardoor uw kopie mogelijk wordt vertraagd.

Vermijd onnodig werk

Vermijd grootschalige wijzigingen in uw naamruimte. Bijvoorbeeld het verplaatsen van bestanden tussen mappen, het wijzigen van eigenschappen op grote schaal of het wijzigen van machtigingen (NTFS ACL's). Met name ACL-wijzigingen kunnen een grote impact hebben omdat ze vaak een trapsgewijs wijzigingseffect hebben op bestanden die lager in de maphiërarchie zijn. Gevolgen kunnen zijn:

• uitgebreide Runtime van RoboCopy-taken omdat elk bestand en elke map die wordt beïnvloed door een wijziging in de ACL moet worden bijgewerkt
• het hergebruik van gegevens die eerder zijn verplaatst, moet mogelijk opnieuw worden gecopieerd. Er moeten bijvoorbeeld meer gegevens worden gekopieerd wanneer mapstructuren veranderen nadat bestanden al eerder zijn gekopieerd. Een RoboCopy-taak kan een naamruimtewijziging niet 'afspelen'. De volgende taak moet de bestanden die eerder naar de oude mapstructuur zijn verplaatst, leegmaken en de bestanden opnieuw uploaden in de nieuwe mapstructuur.

Een ander belangrijk aspect is het effectief gebruiken van het RoboCopy-hulpprogramma. Met het aanbevolen RoboCopy-script maakt en slaat u een logboekbestand op voor fouten. Er kunnen kopieerfouten optreden. Dat is normaal. Deze fouten maken het vaak nodig om meerdere rondes van een kopieerprogramma zoals RoboCopy uit te voeren. Een eerste uitvoering, bijvoorbeeld van een NAS naar DataBox of een server naar een Azure-bestandsshare. En een of meer extra uitvoeringen met de /MIR-switch om bestanden te vangen en opnieuw uit te voeren die niet zijn gekopieerd.

U moet voorbereid zijn om meerdere rondes van RoboCopy uit te voeren op basis van een bepaald naamruimtebereik. Opeenvolgende uitvoeringen worden sneller voltooid omdat ze minder te kopiëren zijn, maar steeds meer worden beperkt door de snelheid van de verwerking van de naamruimte. Wanneer u meerdere rondes uitvoert, kunt u elke ronde versnellen door RoboCopy niet onredelijk hard te laten proberen om alles in een bepaalde uitvoering te kopiëren. Deze RoboCopy-switches kunnen een aanzienlijk verschil maken:

• /R:n n = hoe vaak u een mislukt bestand opnieuw probeert te kopiëren en
• /W:n n = het aantal seconden dat moet worden gewacht tussen nieuwe pogingen

/R:5 /W:5 is een redelijke instelling die u naar wens kunt aanpassen. In dit voorbeeld wordt een mislukt bestand vijf keer opnieuw geprobeerd, met een wachttijd van vijf seconden tussen nieuwe pogingen. Als het bestand nog steeds niet kan worden gekopieerd, probeert de volgende RoboCopy-taak het opnieuw. Bestanden die vaak zijn mislukt omdat ze in gebruik zijn of vanwege time-outproblemen, kunnen uiteindelijk op deze manier worden gekopieerd.

Windows Server 2022 en RoboCopy LFSM

De RoboCopy-switch /LFSM kan worden gebruikt om te voorkomen dat een RoboCopy-taak mislukt met een volume vol fout. RoboCopy wordt onderbroken wanneer een bestandskopie ervoor zorgt dat de vrije ruimte van het doelvolume onder een 'floor'-waarde wordt geplaatst.

RoboCopy gebruiken met Windows Server 2022. Alleen deze versie van RoboCopy bevat belangrijke bugfixes en functies die ervoor zorgen dat de switch compatibel is met aanvullende vlaggen die nodig zijn voor de meeste migraties. Bijvoorbeeld compatibiliteit met de /B vlag.

/B voert RoboCopy uit in dezelfde modus die een back-uptoepassing zou gebruiken. Met deze schakeloptie kan RoboCopy bestanden verplaatsen waarvoor de huidige gebruiker geen machtigingen heeft.

RoboCopy kan normaal gesproken worden uitgevoerd op de bron-, doel- of derde computer.

Belangrijk

Als u van plan bent om te gebruiken /LFSM, moet RoboCopy worden uitgevoerd op de Azure File Sync-doelserver van Windows Server 2022.

Houd er ook rekening mee dat u met /LFSM u ook een lokaal pad voor de bestemming moet gebruiken, niet een UNC-pad. Als doelpad moet u bijvoorbeeld E:\Foldername gebruiken in plaats van een UNC-pad, zoals \\ServerName\FolderName.

Let op

De momenteel beschikbare versie van RoboCopy op Windows Server 2022 heeft een fout waardoor de pauzes worden geteld op basis van het aantal fouten per bestand. Pas de volgende tijdelijke oplossing toe.

De aanbevolen /R:2 /W:1 vlaggen verhogen de kans dat een bestand is mislukt vanwege een /LFSM geïnduceerde pauze. In dit voorbeeld, een bestand dat niet is gekopieerd na 3 pauzes, omdat /LFSM de onderbreking is veroorzaakt, zal RoboCopy het bestand onjuist laten mislukken. De tijdelijke oplossing hiervoor is het gebruik van hogere waarden voor /R:n en /W:n. Een goed voorbeeld is /R:10 /W:1800 (10 nieuwe pogingen van elk 30 minuten). Dit geeft het algoritme voor azure File Sync-lagen tijd om ruimte te maken op het doelvolume.

Deze fout is opgelost, maar de oplossing is nog niet openbaar beschikbaar. Bekijk deze alinea voor updates over de beschikbaarheid van de oplossing en hoe u deze implementeert.

---

Notitie

Hebt u nog steeds vragen of hebt u problemen ondervonden?
We zijn hier om u te helpen:

Relevante koppelingen

Migratie-inhoud:

• Migratiehandleiding voor StorSimple 8000-serie

Azure File Sync-inhoud:

• Overzicht van Azure File Sync
• Azure Files SYNC implementeren
• Probleemoplossingsgids voor Azure File Sync