Migratie van Storsimple 1200 naar Azure File Sync

  • Artikel

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 voor de lange termijn waarnaar StorSimple-apparaten kunnen worden gemigreerd. Dit artikel bevat de benodigde achtergrondkennis en migratiestappen voor een geslaagde migratie naar Azure File Sync.

Notitie

De StorSimple-service (inclusief de StorSimple-Apparaatbeheer voor de 8000- en 1200-serie en StorSimple Data Manager) heeft het einde van de ondersteuning bereikt. Het einde van de ondersteuning voor StorSimple is in 2019 gepubliceerd op de pagina's Microsoft LifeCycle Policy en Azure Communications . Aanvullende meldingen zijn verzonden via e-mail en gepost op de 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 Ja Nee
Standaardbestandsshares (GPv2), GRS/GZRS Ja Nee
Premium bestandsshares (FileStorage), LRS/ZRS Ja No

Azure File Sync

Azure File Sync is een Microsoft-cloudservice, gebaseerd op twee hoofdonderdelen:

  • Bestandssynchronisatie en cloudlagen.
  • Bestandsshares als systeemeigen opslag in Azure, die toegankelijk zijn via meerdere protocollen, zoals SMB en bestands-REST. 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 de betrouwbaarheid van bestanden, 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 voor het opslaan van algemene bestandsservergegevens en sommige toepassingsgegevens in de cloud.

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

Migratiedoelen

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

StorSimple 1200-migratiepad 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 is een Windows Server 2019.

Er zijn talloze alternatieve migratiepaden en het zou te lang zijn om ze allemaal te documenteren en te laten zien waarom ze risico's of nadelen hebben ten opzichte van de route die we als best practice in dit artikel aanbevelen.

Overzicht van migratieroute van de stappen hieronder in dit artikel.

In de vorige afbeelding ziet u de stappen die overeenkomen met de 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 of fysieke server. Een Windows Server-failovercluster wordt ook ondersteund.
  2. Direct Attached Storage inrichten of toevoegen (DAS 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 de StorSimple-opslagstructuur (volumes en shares) toe aan uw Windows Server-opslagstructuur. Als u van plan bent om wijzigingen aan te brengen in uw opslagstructuur, dat wil zeggen het aantal volumes, de koppeling van gegevensmappen aan volumes of de submapstructuur boven of onder uw huidige SMB/NFS-shares, is het nu tijd om rekening te houden met deze wijzigingen. Het wijzigen van de 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 de toewijzingswijzigingen wanneer u de stappen in dit artikel uitvoert.

  • Geen van uw productiegegevens mag op het Windows Server-systeemvolume terechtkomen. Opslag in cloudlagen wordt 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. We raden u aan om windows serverupdates te gebruiken om uw besturingssysteem veilig en up-to-date te houden. Op dezelfde manier raden we u aan u aan te kiezen voor Microsoft Update 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

Als u deze stap wilt voltooien, hebt u de referenties van uw Azure-abonnement nodig.

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

Kies een Azure-regio voor uw opslagsynchronisatieservice die zich dicht bij uw locatie bevindt. Alle andere cloudresources moeten in dezelfde regio worden geïmplementeerd. Als u het beheer wilt vereenvoudigen, maakt u een nieuwe resourcegroep in uw abonnement die synchronisatie- en opslagresources bevat.

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: Uw lokale volume- en mapstructuur afstemmen op 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-bestanden met uw gebruikers en apps. De eenvoudigste manier om dit scenario voor te stellen, is door een on-premises share voor te stellen die 1:1 aan een Azure-bestandsshare toewijst. Als u een klein aantal shares hebt, lager dan 30 voor één Windows Server-exemplaar, raden we een 1:1-toewijzing aan.

Als u meer dan 30 shares hebt, is het vaak niet nodig om een on-premises share 1:1 toe te kennen aan een Azure-bestandsshare. Overweeg 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. Het opslaan van meerdere on-premises shares in één Azure-bestandsshare voorkomt 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 als submappen onder een gemeenschappelijke map ordent. Vervolgens synchroniseert u deze gemeenschappelijke map met 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 volumehoofdmap 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 biedt voordelen. Als u dit bijvoorbeeld doet, blijft het aantal items per synchronisatiebereik lager. We testen Azure-bestandsshares en Azure File Sync met 100 miljoen items (bestanden en mappen) per share. Een best practice is echter om te proberen 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 komt ook ten goede aan scenario's zoals deze:

  • De eerste scan van de inhoud in de cloud kan sneller worden uitgevoerd, waardoor de wachttijd voor de naamruimte op een server die is ingeschakeld voor Azure File Sync, wordt verkleind.
  • Herstellen aan de cloudzijde vanuit een momentopname van een Azure-bestandsshare gaat sneller.
  • Herstel na noodgeval 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 de TreeSize tool van JAM Software GmbH.

Een gestructureerde benadering van een implementatietoewijzing

Voordat u cloudopslag in een latere stap implementeert, is het belangrijk om een toewijzing te maken tussen on-premises mappen en Azure-bestandsshares. Met deze toewijzing wordt aangegeven hoeveel en welke Azure File Sync synchronisatiegroepresources u wilt 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. Door deze indeling wordt 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 aan opslagaccounts. Dit is echter niet altijd mogelijk vanwege verschillende limieten en beperkingen, zowel van uw organisatie als van Azure. Als het niet mogelijk is om slechts één bestandsshare te implementeren in één opslagaccount, 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 van uw Azure-bestandsshare nodig. 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 is een limiet van 250 opslagaccounts per abonnement per Azure-regio.

Tip

Op basis van deze informatie is het vaak nodig om meerdere mappen op het hoogste niveau op uw volumes te groepeer 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. Verder verandert er niets.

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 20 miljoen of 30 miljoen in één aandeel te houden. Splits uw naamruimte op in meerdere shares als u deze aantallen begint te overschrijden. U kunt meerdere on-premises shares blijven groeperen in dezelfde Azure-bestandsshare als u ongeveer onder deze getallen blijft. Deze oefening geeft je ruimte om te groeien.

Het is mogelijk dat in uw situatie een set mappen logisch kan worden gesynchroniseerd met dezelfde Azure-bestandsshare (met behulp van de nieuwe algemene basismapbenadering die eerder is genoemd). Maar het is misschien nog steeds 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 evenwichtig te houden op de server. U kunt ook uw on-premises shares splitsen en synchroniseren over meer on-premises servers, waardoor u de mogelijkheid hebt 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-doelbestandsshare (consolidatie) Nee Een Azure-doelbestandsshare (cloudeindpunt) ondersteunt alleen synchroniseren met één synchronisatiegroep.

Een synchronisatiegroep ondersteunt slechts één servereindpunt per geregistreerde server.		 1) Begin met het synchroniseren van één schijf (het hoofdvolume) naar de doel-Azure-bestandsshare. Beginnen met de grootste schijf/het grootste volume helpt bij de opslagvereisten on-premises. Configureer opslag in cloudlagen om alle gegevens in de cloud te tieren, waardoor ruimte op de bestandsserverschijf wordt vrijgemaakt. 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 naar de cloud/gemigreerd.
2) Richt één hoofdvolume (schijf) tegelijk. Gebruik opslag in cloudlagen om alle gegevens te tieren voor een Azure-bestandsshare. Verwijder het servereindpunt uit de synchronisatiegroep, maak het eindpunt opnieuw met het volgende hoofdvolume/de volgende hoofdschijf, synchroniseer en herhaal het proces. Opmerking: mogelijk moet de agent opnieuw worden geïnstalleerd.
3) Het gebruik van meerdere Azure-doelbestandsshares aanbevelen (hetzelfde of een ander opslagaccount op basis van prestatievereisten)
2 Bestandsserver met één volume en meerdere shares naar dezelfde Azure-doelbestandsshare (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 Groeperingsconcept delen en Volumesynchronisatie voor meer informatie.
3 Bestandsserver met meerdere shares en/of volumes naar meerdere Azure-bestandsshares onder één opslagaccount (1:1-sharetoewijzing) 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 het beste 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 Groeperingsconcept delen en Volumesynchronisatie om het aantal mappen op het hoofd- of hoogste niveau bij de bron te verminderen.
3) Gebruik extra File Sync servers 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 (1:1-sharetoewijzing) Ja Eén Windows Server-exemplaar (of cluster) kan maximaal 30 Azure-bestandsshares synchroniseren (hetzelfde of een ander opslagaccount).

Houd het aantal items per synchronisatiegroep binnen 100 miljoen items (bestanden en mappen) per share. Idealiter is het het beste om onder de 20 of 30 miljoen per aandeel te blijven.		 Dezelfde aanpak als hierboven
5 Meerdere bestandsservers met één (hoofdvolume of share) naar dezelfde Azure-doelbestandsshare (consolidatie) 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 van elkaar verschillen.		 Volg de richtlijnen in Scenario 1 hierboven, met extra overweging om u op één bestandsserver tegelijk te richten.

Een toewijzingstabel maken

Diagram met een voorbeeld van een toewijzingstabel. Download het volgende bestand om de inhoud van deze afbeelding te bekijken en te gebruiken.

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

Maak een tabel waarin uw gedachten worden vastgelegd, zodat u deze kunt raadplegen wanneer dat nodig is. Georganiseerd blijven is belangrijk omdat het gemakkelijk kan zijn om details van uw toewijzingsplan kwijt te raken wanneer u veel Azure-resources tegelijk inricht. Download het volgende Excel-bestand om te gebruiken als sjabloon voor het maken van uw toewijzing.


Excel-pictogram waarmee de context voor het downloaden wordt ingesteld. 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 niveau van prestatieoverwegingen 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 om opslagaccounts met elk één bestandsshare te implementeren. U kunt meerdere Azure-bestandsshares in hetzelfde opslagaccount groeperen als u archiveringsshares hebt of als u er weinig dagelijkse activiteit in 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, kunt u er meerdere in één Azure-opslagaccount groeperen.

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

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.

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.

Waarschuwing

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

Azure-bestandsshares worden nog steeds standaard 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 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. Wanneer u uw Azure-bestandsshares een naam geeft, moet u ook namen gebruiken die vergelijkbaar zijn met de namen die worden gebruikt voor hun on-premises tegenhangers.

Instellingen voor een opslagaccount

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

  • Grote bestandsshares: ingeschakeld: grote bestandsshares verbeteren de prestaties en bieden u de mogelijkheid om maximaal 100TiB in een share op te slaan.
  • Firewall en virtuele netwerken: uitgeschakeld: configureer geen IP-beperkingen of beperk de toegang van het opslagaccount tot een specifiek VNET. Het openbare eindpunt van het opslagaccount wordt gebruikt tijdens de migratie. Alle IP-adressen van Azure-VM's moeten worden toegestaan. Het is raadzaam om na de migratie firewallregels voor het opslagaccount te configureren.
  • Privé-eindpunten: ondersteund: u kunt privé-eindpunten inschakelen, maar het openbare eindpunt wordt gebruikt voor de migratie en moet beschikbaar blijven.

Stap 6: Windows Server-doelmappen configureren

In de vorige stappen hebt u rekening gehouden met alle aspecten die bepalend zijn voor de onderdelen van uw synchronisatietopologieën. Het is nu tijd om de server voor te bereiden op het ontvangen van bestanden voor uploaden.

Maak alle mappen, die elk worden gesynchroniseerd met een 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 samen te synchroniseren tot één Azure-bestandsshare, moet u deze onder een gemeenschappelijke hoofdmap op het volume plaatsen. Maak deze doelhoofdmap nu op het volume.

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

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. Zorg ervoor dat u de volledige module en de NuGet-provider installeert wanneer u hierom wordt gevraagd.

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

Als u problemen ondervindt bij het bereiken van internet vanaf uw server, is dit het moment om deze op te lossen. Azure File Sync maakt gebruik van een beschikbare netwerkverbinding met internet. Het vereisen van een proxyserver om het 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 Azure File Sync gebruikt.

Als het configureren van een proxy betekent dat u uw firewalls voor de server moet openen, is deze benadering mogelijk acceptabel voor u. Aan het einde van de serverinstallatie, nadat u de serverregistratie hebt voltooid, ziet u in een rapport over netwerkconnectiviteit de exacte eindpunt-URL's in Azure waarmee Azure File Sync moet communiceren voor de regio die u hebt geselecteerd. In het rapport wordt ook aangegeven 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 kiezen waarbij u de firewalls niet breed opent. U kunt in plaats daarvan de server beperken tot communicatie met DNS-naamruimten op een hoger niveau. Zie proxy- en firewallinstellingen Azure File Sync voor meer informatie. Volg uw eigen best practices voor netwerken.

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

Deze stappen worden gedetailleerder beschreven in de implementatiehandleiding, die de PowerShell-modules bevat die u eerst moet installeren: Azure File Sync agentinstallatie.

Gebruik de meest recente 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 resource Opslagsynchronisatieservice in de Azure Portal. Ga in het linkermenu naar Geregistreerde servers. Uw server wordt daar 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 de Azure-portal.
  2. Zoek uw opslagsynchronisatieserviceresource.
  3. Maak een nieuwe synchronisatiegroep in de resource opslagsynchronisatieservice 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 er wordt gesynchroniseerd. Zorg ervoor dat u naar de Azure-bestandsshare verwijst met een overeenkomende naam.
  4. Nadat u de synchronisatiegroep hebt gemaakt, wordt er een rij voor 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 Cloudeindpunten.
  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 opslag in cloudlagen inschakelt. Dit is vereist als uw lokale server onvoldoende ruimte heeft om de totale grootte van uw gegevens op te slaan in de StorSimple-cloudopslag. Stel uw lagenbeleid tijdelijk in voor de migratie op 99% volume vrije ruimte.

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

Stap 9: Uw bestanden kopiëren

De basismigratie 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 uw Windows Server-doelmap:

  • Identificeer de eerste locatie op uw virtuele StorSimple-apparaat.
  • Identificeer de overeenkomende map op de Windows Server, waarop al Azure File Sync is geconfigureerd.
  • Het kopiëren starten met RoboCopy

Met de volgende RoboCopy-opdracht worden bestanden uit uw StorSimple Azure-opslag teruggehaald naar uw lokale StorSimple en vervolgens verplaatst naar de Windows Server-doelmap. De Windows Server synchroniseert deze met de Azure-bestandsshare(s). Als het lokale Windows Server-volume vol raakt, worden cloudlagen geactiveerd en worden bestanden die al zijn gesynchroniseerd, gelaagd. Cloudopslaglagen genereren voldoende ruimte om de kopie van het virtuele StorSimple-apparaat voort te zetten. Opslag in cloudlagen wordt eenmaal per uur gecontroleerd om te zien wat er is gesynchroniseerd en om schijfruimte vrij te maken om de beschikbare 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 voor 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 gaat met meer threads. Tests met Azure Files geven aan dat tussen 8 en 20 evenwichtige prestaties tonen 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 goede prestaties leveren, 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 komt mogelijk vaker voor via WAN-koppelingen. Kies geen nieuwe poging of een waarde van een als u denkt dat het bestand niet kan worden gekopieerd omdat het actief in gebruik was. Een paar seconden later opnieuw proberen, is mogelijk niet voldoende tijd om de status van het bestand te wijzigen. Gebruikers of apps die het bestand geopend houden, hebben mogelijk uren meer tijd nodig. In dit geval is het accepteren van het bestand niet gekopieerd en kan het in een van uw geplande, volgende Robocopy-uitvoeringen uiteindelijk wel kopiëren. Dit helpt de huidige uitvoering sneller te voltooien zonder te worden verlengd door veel nieuwe pogingen die uiteindelijk eindigen in een meerderheid van kopieerfouten vanwege bestanden die na de time-out voor opnieuw proberen nog steeds zijn geopend.
/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 gebruikt in combinatie 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 een PowerShell-venster. Als u Robocopy gebruikt voor Azure Files, moet u ervoor zorgen dat u de Azure-bestandsshare koppelt met behulp van de toegangssleutel van het opslagaccount versus een domein-id. 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. Vergelijken betekent kopiëren van het juiste bron- en mapniveau naar het overeenkomende mapniveau op het doel. Alleen dan kan een 'inhaalkopie' succesvol zijn. Wanneer bron en doel niet overeenkomen, leidt het gebruik /MIR tot grootschalige verwijderingen en nieuwecopieën.
/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 /ITwordt de wijziging van de ACL mogelijk gemist door Robocopy en niet overgebracht 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] Betrouwbaarheid voor de kopie van directory's. Standaard: /DCOPY:DA. Kopieervlag: D= Gegevens, A= Kenmerken, T= Tijdstempels.
/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 moeten worden vastgelegd. Verbetert de kopieerprestaties.
/NDL Hiermee geeft u op dat mapnamen niet moeten worden vastgelegd. Verbetert de kopieerprestaties.
/XD Hiermee geeft u mappen die moeten worden uitgesloten. Wanneer u Robocopy uitvoert op de hoofdmap van een volume, kunt u overwegen de verborgen System Volume Information map uit te sluiten. Indien gebruikt zoals ontworpen, is alle informatie in de informatie specifiek voor het exacte volume op dit exacte systeem en kan opnieuw worden opgebouwd op aanvraag. Het kopiëren van deze informatie is niet handig in de cloud of wanneer de gegevens ooit naar een ander Windows-volume worden gekopieerd. Het achterlaten van deze inhoud mag niet worden beschouwd als gegevensverlies.
/UNILOG:<file name> Hiermee wordt de status naar het logboekbestand geschreven als Unicode. (Het bestaande logboek wordt overschreven.)
/L Alleen voor een testuitvoering
Bestanden moeten alleen worden 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 correct gedocumenteerde testresultaten te verkrijgen.
/LFSM Alleen voor doelen met gelaagde opslag. Niet ondersteund wanneer het doel 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 hebben 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 wordt opgegeven in basis 2: nKB, nMBof nGB. Als /LFSM is opgegeven zonder expliciete grondwaarde, 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, waaronder details over een gerelateerde fout en tijdelijke oplossing.
/Z Voorzichtig gebruiken
Kopieert bestanden in de modus voor opnieuw opstarten. Deze switch wordt alleen aanbevolen in een instabiele netwerkomgeving. Het vermindert de kopieerprestaties aanzienlijk vanwege extra logboekregistratie.
/ZB Voorzichtig gebruiken
Maakt gebruik van 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 meest recente patchniveau of ten minste besturingssysteemupdate KB5005103 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 deze mogelijk worden gewijzigd. Het is mogelijk dat RoboCopy een map heeft verwerkt, naar de volgende gaat 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 een back-up naar de cloud via Azure File Sync. Dit kan lang duren, afhankelijk van:

  • uw downloadbandbreedte
  • de terugroepsnelheid 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 is het sneller, omdat er alleen wijzigingen hoeven te worden doorgevoerd die zijn opgetreden sinds de laatste uitvoering. Deze wijzigingen zijn waarschijnlijk al lokaal in de StorSimple, omdat ze recent zijn. Dat verkort de tijd nog meer, omdat de noodzaak van terugroepen uit de cloud wordt verminderd. Tijdens deze tweede uitvoering kunnen zich nog steeds nieuwe wijzigingen ophopen.

Herhaal dit proces totdat u tevreden bent dat de hoeveelheid tijd die nodig is om te voltooien een acceptabele downtime is.

Wanneer u de downtime acceptabel acht 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 een andere passende stap kan uitvoeren die voorkomt dat inhoud in deze map op StorSimple wordt gewijzigd.

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

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

U bent klaar met het migreren van een share/groep shares naar een gemeenschappelijke hoofdmap of een gemeenschappelijk volume. (Afhankelijk van wat u hebt toegewezen en besloten dat u naar dezelfde Azure-bestandsshare moet gaan.)

U kunt proberen een aantal van deze kopieën parallel uit te voeren. U wordt aangeraden het bereik van één Azure-bestandsshare tegelijk te verwerken.

Waarschuwing

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

Het beleid voor volume vrije ruimte in cloudlagen werkt op volumeniveau met mogelijk meerdere servereindpunten die van daaruit worden gesynchroniseerd. Als u vergeet de vrije ruimte op zelfs één servereindpunt aan te passen, blijft de synchronisatie de meest beperkende regel toepassen en wordt geprobeerd 99% vrije schijfruimte te behouden, waardoor de lokale cache niet werkt zoals u zou verwachten. Tenzij het uw doel is om alleen de naamruimte te hebben voor een volume dat slechts zelden geopende archiveringsgegevens bevat.

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 het geval is, is uw downloadsnelheid waarschijnlijk beter dan uw uploadsnelheid. Opslag in cloudlagen wordt eenmaal per uur uitgevoerd om inhoud te evacueren van de lokale Windows Server-schijf die is gesynchroniseerd.

Laat de voortgang van de synchronisatie en opslag in cloudlagen schijfruimte vrijmaken. U kunt dit 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. Er breekt niets als je in deze situatie komt en je kunt vol vertrouwen verdergaan. Ongemak van het opnieuw uitvoeren van de opdracht is het enige gevolg.

U kunt ook andere Azure File Sync problemen tegenkomen. Als dat gebeurt, raadpleegt u Azure File Sync gids voor probleemoplossing.

De snelheid en het slagingspercentage van een bepaalde RoboCopy-uitvoering zijn afhankelijk van verschillende factoren:

  • IOPS voor 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 maximaal mogelijke doorvoer wordt bepaald door de traagste van deze drie onderdelen. Zorg ervoor dat uw netwerkinfrastructuur zodanig is geconfigureerd dat optimale overdrachtssnelheden optimaal worden ondersteund.

Waarschuwing

Hoewel het vaak het meest gewenst is om zo snel mogelijk te kopiëren, moet u rekening houden met het gebruik van uw lokale netwerk en NAS-apparaat voor andere, vaak bedrijfskritieke taken.

Zo snel mogelijk kopiëren is mogelijk niet wenselijk wanneer het risico bestaat dat de migratie de beschikbare resources kan monopoliseren.

  • Overweeg wanneer het in uw omgeving het beste 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 om monopolisering van resources op zowel I/O-beperkte apparaten als overvolle netwerkkoppelingen te voorkomen.

/IPG:n kan niet worden gebruikt voor nauwkeurige netwerkbeperking tot een bepaalde Mbps. Gebruik in plaats daarvan Windows Server Network QoS. 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 gedachtegang geldt voor de IOPS die op de NAS worden waargenomen. De clustergrootte op het NAS-volume, pakketgrootten en een matrix van andere factoren zijn van invloed op de waargenomen IOPS. De introductie van vertraging tussen pakketten is vaak de eenvoudigste manier om de belasting van de NAS te beheersen. Test meerdere waarden, bijvoorbeeld van ongeveer 20 milliseconden (n=20) tot veelvouden van dat getal. Zodra u een vertraging invoert, kunt u evalueren of uw andere apps nu werken zoals verwacht. 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 kopie. Elk bestand wordt geëvalueerd tijdens een eerste kopie en tijdens inhaalkopieën. Bijvoorbeeld 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.

We beschouwen bandbreedte vaak standaard als de meest beperkende factor in een migratie, en dat kan waar zijn. Maar de mogelijkheid om een naamruimte op te sommen, kan van invloed zijn op de totale tijd 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 de overdracht traag zijn als u een groot aantal kleine bestanden migreert. Dit is normaal.

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 dus bij het inrichten van een machine specifiek voor RoboCopy rekening met het aantal processorkernen en hun relatie tot het aantal threads dat ze opgeven. 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 /MT:n voor meerdere threads u moet opgeven. Houd ook rekening met het aantal RoboCopy-taken dat 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 resource-investering op onze 1 TiB aan grotere bestanden mogelijk geen proportionele voordelen op. Een hoog aantal threads probeert meer van de grote bestanden tegelijkertijd via het netwerk te kopiëren. Deze extra netwerkactiviteit verhoogt de kans dat het wordt beperkt door doorvoer of opslag-IOPS.

Tijdens een eerste RoboCopy naar een leeg doel of een differentiële uitvoering met veel gewijzigde bestanden, wordt u waarschijnlijk beperkt door uw netwerkdoorvoer. Begin met een hoog aantal threads voor een eerste uitvoering. Een hoog aantal threads, zelfs buiten uw momenteel beschikbare threads op de computer, 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 betekent minder transport van gegevens via het netwerk. Uw snelheid is nu meer afhankelijk van uw mogelijkheid om naamruimteitems te verwerken dan om ze via de netwerkkoppeling te verplaatsen. Voor volgende uitvoeringen moet u de waarde van het aantal threads afstemmen op het aantal processorkernen en het aantal threads per kern. Overweeg of kernen moeten worden gereserveerd voor andere taken die een productieserver kan hebben.

Tip

Vuistregel: de eerste RoboCopy-uitvoering, waarmee veel gegevens van een netwerk met een hogere latentie worden verplaatst, profiteert van een over-inrichting van het aantal threads (/MT:n). Volgende uitvoeringen kopiëren minder verschillen en de kans is groter dat u overgaat van beperkte netwerkdoorvoer naar beperkte rekenkracht. Onder deze omstandigheden is het vaak beter om het aantal RoboCopy-threads af te koppelen aan de daadwerkelijk beschikbare threads op de computer. Te veel inrichten 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 mappenhiërarchie staan. De gevolgen kunnen zijn:

  • uitgebreide runtime van RoboCopy-taak omdat elk bestand en elke map die wordt beïnvloed door een wijziging in de ACL moet worden bijgewerkt
  • gegevens die eerder zijn verplaatst, moeten mogelijk opnieuw worden gebruikt. 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, opschonen en de bestanden opnieuw uploaden in de nieuwe mapstructuur.

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

U moet voorbereid zijn om meerdere rondes van RoboCopy uit te voeren op een bepaald naamruimtebereik. Opeenvolgende uitvoeringen worden sneller voltooid omdat ze minder hoeven te kopiëren, maar worden steeds meer beperkt door de snelheid van het verwerken 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 = hoeveel seconden er 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. Vaak kunnen bestanden die zijn mislukt omdat ze in gebruik zijn of vanwege time-outproblemen 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 . RoboCopy wordt onderbroken wanneer een kopie van een bestand ertoe leidt dat de vrije ruimte van het doelvolume onder een 'vloer'-waarde komt.

RoboCopy gebruiken met Windows Server 2022. Alleen deze versie van RoboCopy bevat belangrijke bugfixes en functies die de overstap compatibel maken met aanvullende vlaggen die nodig zijn in 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.

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

Belangrijk

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

Houd er ook rekening mee dat u met /LFSM 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.

Waarschuwing

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

De aanbevolen /R:2 /W:1 vlaggen vergroten de kans dat een bestand mislukt vanwege een /LFSM geïnduceerde onderbreking. In dit voorbeeld zorgt een bestand dat niet is gekopieerd na 3 onderbrekingen omdat /LFSM de onderbreking is veroorzaakt, ervoor dat RoboCopy ten onrechte mislukt. 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). Hierdoor moet de Azure File Sync algoritme voor laaging tijd geven om ruimte te maken op het doelvolume.

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

Notitie

Hebt u nog vragen of hebt u problemen ondervonden?
We zijn er om u te helpen: Email adres in één woord: Azure Files migratie op microsoft dot com

Migratie-inhoud:

Azure File Sync inhoud: