Migreren van Nas (Network Attached Storage) naar een hybride cloudimplementatie met Azure File Sync

  • Artikel

Dit migratieartikel is een van de verschillende met de trefwoorden NAS en Azure File Sync. Controleer of dit artikel van toepassing is op uw scenario:

  • Gegevensbron: Network Attached Storage (NAS)
  • Migratieroute: NAS ⇒ Windows Server ⇒ uploaden en synchroniseren met Azure-bestandsshares
  • Bestanden on-premises opslaan in de cache: Ja, het uiteindelijke doel is een Azure File Sync-implementatie.

Als uw scenario anders is, bekijkt u de tabel met migratiehandleidingen.

Azure File Sync werkt op DAS-locaties (Direct Attached Storage) en biedt geen ondersteuning voor synchronisatie met NAS-locaties (Network Attached Storage). Dit feit maakt een migratie van uw bestanden nodig en dit artikel begeleidt u bij het plannen en uitvoeren van een dergelijke migratie.

Van toepassing op

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

Migratiedoelen

Het doel is om de SMB-bestandsshares op uw NAS-apparaat te verplaatsen naar een Windows Server en vervolgens Azure File Sync te gebruiken voor een hybride cloudimplementatie. Over het algemeen moeten migraties worden uitgevoerd op een manier die de integriteit van de productiegegevens en de beschikbaarheid ervan tijdens de migratie garandeert. Dit laatste vereist dat downtime tot een minimum wordt beperkt, zodat deze in de normale onderhoudsvensters past of slechts iets groter is dan de normale onderhoudsvensters.

Migratieoverzicht

Zoals vermeld in Migrate naar SMB Azure-bestandsshares, is het gebruik van het juiste kopieerprogramma en de juiste methode belangrijk. Uw NAS-apparaat maakt SMB-shares rechtstreeks in uw lokale netwerk beschikbaar. U kunt Azure Storage Mover of RoboCopy gebruiken om uw bestanden te verplaatsen.

Fase 1: Bepalen hoeveel Azure-bestandsshares u nodig hebt

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

Diagram that shows an example of a mapping table. Download the following file to experience and use the content of this image.

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.


Excel icon that sets the context for the download. Download een sjabloon voor naamruimtetoewijzing.

Fase 2: Een geschikte On-premises Windows Server inrichten

  • Maak een virtuele Windows Server 2022- of Windows Server 2019-machine of implementeer een fysieke server. Een Windows Server-failovercluster wordt ook ondersteund.

  • Direct Attached Storage (DAS inrichten of toevoegen in vergelijking met NAS, wat niet wordt ondersteund).

    De hoeveelheid opslagruimte die u inricht, kan kleiner zijn dan wat u momenteel op uw NAS-apparaat gebruikt. Voor deze configuratiekeuze moet u ook gebruikmaken van de cloudlaagfunctie van Azure File Sync. Wanneer u uw bestanden echter kopieert van de grotere NAS-ruimte naar het kleinere Windows Server-volume in een latere fase, moet u in batches werken:

    1. Een set bestanden verplaatsen die op de schijf past
    2. Bestandssynchronisatie en cloudlagen inschakelen
    3. Wanneer er meer vrije ruimte op het volume wordt gemaakt, gaat u verder met de volgende batch bestanden. U kunt ook de RoboCopy-opdracht bekijken in de sectie RoboCopy van dit artikel voor gebruik van de nieuwe /LFSM switch. Het gebruik /LFSM kan uw RoboCopy-taken aanzienlijk vereenvoudigen, maar het is niet compatibel met een aantal andere RoboCopy-switches waar u mogelijk van afhankelijk bent. Gebruik de /LFSM switch alleen wanneer de migratiebestemming lokale opslag is. Dit wordt niet ondersteund wanneer de bestemming een externe SMB-share is.

    U kunt deze batchverwerkingsmethode vermijden door de equivalente ruimte op de Windows Server in te richten die uw bestanden op het NAS-apparaat innemen. Overweeg ontdubbeling op NAS/Windows. Als u deze hoge hoeveelheid opslagruimte niet permanent wilt doorvoeren op uw Windows Server, kunt u de volumegrootte na de migratie verminderen en voordat u het beleid voor cloudlagen aanpast. Hiermee maakt u een kleinere on-premises cache van uw Azure-bestandsshares.

De resourceconfiguratie (berekening en RAM) van de Windows Server die u implementeert, is voornamelijk afhankelijk van het aantal items (bestanden en mappen) dat u gaat synchroniseren. We raden u aan om met een configuratie met hogere prestaties te gaan als u problemen ondervindt.

Meer informatie over het aanpassen van de grootte van een Windows Server op basis van het aantal items (bestanden en mappen) dat u moet synchroniseren.

Notitie

Het eerder gekoppelde artikel bevat een tabel met een bereik voor servergeheugen (RAM). U kunt zich richten op het kleinere getal voor uw server, maar verwacht dat de initiële synchronisatie aanzienlijk meer tijd kan duren.

Fase 3: De 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.

Fase 4: Azure-opslagbronnen implementeren

In deze fase raadpleegt u de toewijzingstabel uit fase 1 en gebruikt u deze om het juiste aantal Azure-opslagaccounts en bestandsshares in te richten.

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.

Fase 5: 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.

Fase 6: Azure File Sync configureren op de Windows Server

Uw geregistreerde on-premises Windows Server moet gereed zijn en zijn verbonden met internet voor dit proces.

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 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.

Belangrijk

Cloudlagen zijn de Azure File Sync-functie waarmee de lokale server minder opslagcapaciteit kan hebben dan in de cloud is opgeslagen, maar de volledige naamruimte beschikbaar is. Lokaal interessante (dynamische) gegevens worden ook lokaal in de cache opgeslagen voor snelle toegangsprestaties. Cloudlagen zijn een optionele functie per Azure File Sync-servereindpunt.

Waarschuwing

Als u minder opslag hebt ingericht op uw Windows-servervolume(s) dan uw gegevens die op het NAS-apparaat worden gebruikt, is cloudlagen verplicht. Als u cloudlagen niet inschakelt, maakt uw server geen ruimte vrij om alle bestanden op te slaan. Stel uw laagbeleid, tijdelijk voor de migratie, in op 99% vrije ruimte voor volumes. Zorg ervoor dat u terugkeert naar de instellingen voor cloudlagen nadat de migratie is voltooid en stel deze in op een nuttiger niveau voor de lange termijn.

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

Nadat alle servereindpunten zijn gemaakt, werkt synchronisatie. U kunt een testbestand maken en zien dat het wordt gesynchroniseerd vanaf uw serverlocatie naar de verbonden Azure-bestandsshare (zoals beschreven door het cloudeindpunt in de synchronisatiegroep).

Beide locaties, de servermappen en de Azure-bestandsshares zijn anders leeg en wachten op gegevens op beide locaties. In de volgende stap gaat u bestanden kopiëren naar de Windows Server voor Azure File Sync om ze naar de cloud te verplaatsen. Als u cloudlagen hebt ingeschakeld, begint de server vervolgens bestanden te tieren, als u onvoldoende capaciteit hebt op de lokale volumes.

Fase 7: Gegevens kopiëren met Behulp van Azure Storage Mover of RoboCopy

U kunt nu Azure Storage Mover of RoboCopy gebruiken om gegevens van uw NAS-apparaat naar uw Windows Server te kopiëren en Azure File Sync te gebruiken om de gegevens naar Azure-bestandsshares te verplaatsen. In deze handleiding wordt RoboCopy gebruikt voor de eerste kopie. Als u in plaats daarvan Azure Storage Mover wilt gebruiken, raadpleegt u Migreren naar SMB Azure-bestandsshares met behulp van Azure Storage Mover.

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

  • Identificeer de eerste locatie op uw NAS-apparaat.
  • Identificeer de overeenkomende map op de Windows Server waarop Azure File Sync al is geconfigureerd.
  • Start de kopie.

Met de volgende RoboCopy-opdracht worden bestanden van uw NAS-opslag gekopieerd naar de doelmap van Windows Server. De Windows Server synchroniseert deze met de Azure-bestandsshare(s).

Als u minder opslag op uw Windows Server hebt ingericht dan uw bestanden op het NAS-apparaat in beslag nemen, hebt u cloudlagen geconfigureerd. 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 NAS-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.

Het is mogelijk dat RoboCopy bestanden sneller verplaatst dan u lokaal kunt synchroniseren met de cloud en laag, waardoor er onvoldoende lokale schijfruimte beschikbaar is. In dit geval mislukt RoboCopy. U wordt aangeraden de shares in een reeks te doorlopen die dit voorkomt, bijvoorbeeld het niet starten van kopieertaken voor alle shares tegelijk of alleen het verplaatsen van shares die passen op de huidige hoeveelheid vrije ruimte op de Windows Server.

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.

Fase 8: Cut-over gebruiker

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

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

  • uw downloadbandbreedte
  • de uploadbandbreedte
  • de snelheid van het lokale netwerk en het aantal hoe optimaal het aantal RoboCopy-threads overeenkomt met het aantal RoboCopy-threads
  • het aantal items (bestanden en mappen) dat moet worden verwerkt door RoboCopy en Azure File Sync

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. Tijdens deze tweede uitvoering kunnen nieuwe wijzigingen nog steeds worden verzameld.

Herhaal dit proces totdat u tevreden bent dat de benodigde tijd voor het voltooien van een RoboCopy voor een specifieke locatie binnen een acceptabel venster voor downtime valt.

Wanneer u rekening houdt met de downtime die acceptabel is, moet u gebruikerstoegang tot uw NAS-shares verwijderen. U kunt dit doen door stappen uit te voeren waardoor gebruikers de bestands- en mapstructuur en inhoud niet kunnen wijzigen. Een voorbeeld is om uw DFS-naamruimte te laten verwijzen naar een niet-bestaande locatie of de hoofd-ACL's op de share te wijzigen.

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 op uw NAS SMB-share. Als u een nas van bedrijfsklasse hebt die lid is van een domein, komen de gebruikers-SID's automatisch overeen, omdat de gebruikers bestaan in Active Directory en RoboCopy bestanden en metagegevens met volledige beeldkwaliteit kopieert. Als u lokale gebruikers op uw NAS hebt gebruikt, moet u deze gebruikers opnieuw maken als lokale gebruikers van Windows Server en de bestaande SID's RoboCopy toewijzen aan uw Windows Server naar de SID's van uw nieuwe lokale gebruikers van Windows Server.

U bent klaar met het migreren van een share/groep shares naar een gemeenschappelijke hoofdmap of een gemeenschappelijke volume. (Afhankelijk van uw toewijzing uit fase 1)

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 uw NAS 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, waardoor de lokale cache niet werkt zoals verwacht. Tenzij u alleen de naamruimte wilt hebben voor een volume dat alleen zelden toegankelijk is, archiveringsgegevens en u de rest van de opslagruimte voor een ander scenario reserveert.

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. Opslag in cloudlagen werkt één keer per uur om inhoud te evacueren vanaf de lokale Windows Server-schijf die is gesynchroniseerd. Het doel is om uw 99% vrije ruimte op het volume te bereiken.

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.

Raadpleeg de koppeling in de volgende sectie voor het oplossen van problemen met Azure File Sync.

Volgende stappen

De volgende artikelen helpen u inzicht te krijgen in implementatieopties, aanbevolen procedures en stappen voor probleemoplossing.