Migreren van Linux naar een hybride cloudimplementatie met Azure File Sync

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

• Gegevensbron: Network Attached Storage (NAS)
• Migratieroute: Linux Server met SAMBA ⇒ Windows Server 2012R2 of hoger ⇒ synchroniseren met Azure-bestandsshare(s)
• 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 Windows Server-exemplaren met direct gekoppelde opslag (DAS). Het biedt geen ondersteuning voor synchronisatie van en naar Linux-clients of een externe SMB-share (Server Message Block) of NFS-shares (Network File System).

Als gevolg hiervan maakt het transformeren van uw bestandsservices naar een hybride implementatie een migratie naar Windows Server noodzakelijk. In dit artikel wordt u begeleid bij het plannen en uitvoeren van een dergelijke migratie.

Van toepassing op

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

Migratiedoelen

Het doel is om de shares die u op uw Linux Samba-server hebt, te verplaatsen naar een Windows Server-exemplaar. Gebruik vervolgens Azure File Sync voor een hybride cloudimplementatie. Deze migratie moet worden uitgevoerd op een manier die de integriteit van de productiegegevens en beschikbaarheid 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 het overzichtsartikel over Azure Files-migratie, is het gebruik van het juiste kopieerprogramma en de juiste benadering belangrijk. Uw Linux Samba-server biedt SMB-shares rechtstreeks in uw lokale netwerk weer. Robocopy, ingebouwd in Windows Server, is de beste manier om uw bestanden in dit migratiescenario te verplaatsen.

Als u Samba niet uitvoert op uw Linux-server en liever mappen wilt migreren naar een hybride implementatie op Windows Server, kunt u hulpprogramma's voor Linux-kopieerbewerkingen gebruiken in plaats van Robocopy. Houd rekening met de betrouwbaarheidsmogelijkheden van uw hulpprogramma voor kopiëren. Raadpleeg de sectie Basisbeginselen van migratie in het overzichtsartikel over migratie om te leren wat u zoekt in een kopieerprogramma.

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

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

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

Download een sjabloon voor naamruimtetoewijzing.

Fase 2: Een geschikt Windows Server-exemplaar on-premises inrichten

• Maak een Windows Server 2022-exemplaar als een virtuele machine of fysieke server. Windows Server 2012 R2 is de minimale vereiste. Een Windows Server-failovercluster wordt ook ondersteund.

• Direct Attached Storage (DAS) inrichten of toevoegen. Nas (Network Attached Storage) wordt niet ondersteund.

  De hoeveelheid opslagruimte die u inricht, kan kleiner zijn dan wat u momenteel op uw Linux-Samba-server gebruikt, als u de azure File Sync-cloudlaagfunctie gebruikt.

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

1. Verplaats een set bestanden die op de schijf past.
2. Laat File Sync en cloudlagen betrokken zijn.
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 volgende RoboCopy-sectie 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.

U kunt deze batchverwerkingsmethode vermijden door de equivalente ruimte in te richten op het Windows Server-exemplaar dat uw bestanden op de Linux Samba-server innemen. Overweeg ontdubbeling in te schakelen in Windows. Als u deze hoge hoeveelheid opslagruimte niet permanent wilt doorvoeren naar uw Windows Server-exemplaar, 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 (compute en RAM) van het Windows Server-exemplaar dat 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-exemplaar 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 Implementatie van Windows Server

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

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 gegevens worden ook lokaal in de cache opgeslagen voor snelle toegangsprestaties. Cloudlagen zijn een optionele functie voor elk Azure File Sync-servereindpunt.

Waarschuwing

Als u minder opslag hebt ingericht op uw Windows Server-volumes dan uw gegevens die worden gebruikt op de Linux Samba-server, 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 procent vrije ruimte voor een volume. Zorg ervoor dat u terugkeert naar de instellingen voor cloudlagen nadat de migratie is voltooid en stel het beleid in op een nuttiger niveau voor de lange termijn.

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

Nadat u alle servereindpunten hebt gemaakt, werkt de 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. In de volgende stap gaat u bestanden kopiëren naar het Windows Server-exemplaar voor Azure File Sync om ze naar de cloud te verplaatsen. Als u cloudlagen hebt ingeschakeld, begint de server bestanden te tieren als u onvoldoende capaciteit op de lokale volumes hebt.

Fase 7: Robocopy

De basismigratiebenadering is het gebruik van Robocopy om bestanden te kopiëren en Azure File Sync te gebruiken om de synchronisatie uit te voeren.

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

1. Identificeer de eerste locatie op uw Linux Samba-server.
2. Identificeer de overeenkomende map op het Windows Server-exemplaar waarop Azure File Sync al is geconfigureerd.
3. Start de kopie met Behulp van Robocopy.

Met de volgende Robocopy-opdracht worden bestanden gekopieerd van de opslag van uw Linux Samba-server naar uw Windows Server-doelmap. Windows Server synchroniseert deze met de Azure-bestandsshares.

Als u minder opslag hebt ingericht op uw Windows Server-exemplaar dan uw bestanden in beslag nemen op de Linux Samba-server, hebt u cloudlagen geconfigureerd. Naarmate het lokale Windows Server-volume vol raakt, worden bestanden die al zijn gesynchroniseerd in cloudlagen gestart en gelaagd. Met cloudlagen wordt voldoende ruimte gegenereerd om de kopie van de Linux Samba-server voort te zetten. In cloudlagen wordt eenmaal per uur gecontroleerd wat er is gesynchroniseerd en om schijfruimte vrij te maken om het beleid van 99 procent vrije ruimte voor een volume te bereiken.

Het is mogelijk dat Robocopy bestanden sneller verplaatst dan u lokaal kunt synchroniseren met de cloud en laag, waardoor u geen lokale schijfruimte meer hebt. Robocopy mislukt dan. U wordt aangeraden de shares in een volgorde te doorlopen die het probleem voorkomt. Denk bijvoorbeeld aan het niet starten van Robocopy-taken voor alle shares tegelijk. U kunt ook shares verplaatsen die passen op de huidige hoeveelheid vrije ruimte op het Windows Server-exemplaar. Als uw Robocopy-taak mislukt, kunt u de opdracht altijd opnieuw uitvoeren zolang u de volgende optie voor spiegelen/opschonen gebruikt:

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 Linux Samba-server en kunnen ze worden gewijzigd. Het is mogelijk dat Robocopy een map heeft verwerkt en verdergaat met de volgende, waarna een gebruiker op de bronlocatie (Linux) 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-exemplaar en naar de cloud via Azure File Sync. Dit eerste exemplaar kan lang duren, afhankelijk van:

• Uw downloadbandbreedte.
• De uploadbandbreedte.
• De lokale netwerksnelheid en het aantal hoe optimaal het aantal Robocopy-threads overeenkomt.
• Het aantal items (bestanden en mappen) dat Robocopy en Azure File Sync moeten verwerken.

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

Het is sneller de tweede keer 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 hoeveelheid tijd die nodig is voor het voltooien van een Robocopy-bewerking voor een specifieke locatie binnen een acceptabel venster voor downtime valt.

Wanneer u denkt dat de downtime acceptabel is en u voorbereid bent om de Linux-locatie offline te halen, kunt u ACL's wijzigen in de hoofdmap van de share, zodat gebruikers geen toegang meer hebben tot de locatie. U kunt ook andere geschikte stappen uitvoeren om te voorkomen dat inhoud in deze map op uw Linux-server wordt gewijzigd.

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

Maak een share in de map Windows Server en pas de DFS-N-implementatie mogelijk aan zodat deze verwijst. Zorg ervoor dat u dezelfde machtigingen op shareniveau instelt als op uw Linux Samba-server-SMB-shares. Als u lokale gebruikers op uw Linux Samba-server hebt gebruikt, moet u deze gebruikers opnieuw maken als lokale gebruikers van Windows Server. U moet ook de bestaande SID's die Robocopy naar uw Windows Server-exemplaar heeft verplaatst, toewijzen aan de SID's van uw nieuwe lokale Gebruikers van Windows Server. Als u Active Directory-accounts en ACL's hebt gebruikt, verplaatst Robocopy deze als zodanig en is er geen verdere actie nodig.

U bent klaar met het migreren van een share of een groep shares naar een gemeenschappelijke hoofdmap of -volume (afhankelijk van uw toewijzing vanuit 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

Nadat u alle gegevens van uw Linux Samba-server naar het Windows Server-exemplaar hebt verplaatst en uw migratie is voltooid, keert u terug naar alle synchronisatiegroepen in Azure Portal. Pas het percentage vrije ruimte voor cloudopslagvolumes aan op iets dat beter geschikt is voor cachegebruik, zoals 20 procent.

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 de vrije schijfruimte op 99 procent te behouden. De lokale cache werkt mogelijk niet zoals verwacht. De prestaties kunnen acceptabel zijn als u de naamruimte wilt hebben voor een volume dat slechts zelden toegang heeft tot gearchiveerde gegevens en u de rest van de opslagruimte voor een ander scenario reserveert.

Problemen oplossen

Het meest voorkomende probleem is dat de Robocopy-opdracht mislukt met volume vol aan de Windows Server-zijde. 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 vrije ruimte van 99 procent op het volume te bereiken.

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

Wanneer uw Windows Server-exemplaar 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 bevatten geavanceerde opties, aanbevolen procedures en hulp bij het oplossen van problemen voor Azure File Sync.

• Overzicht van Azure File Sync
• Azure Files SYNC implementeren
• Problemen met Azure File Sync oplossen