Migreren van Linux naar een hybride cloudimplementatie met Azure File Sync

  • Artikel

Dit migratieartikel is een van de vele met de 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-bestandsshares
  • Bestanden on-premises in cache opslaan: 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, een externe SMB-share (Server Message Block) of NFS-shares (Network File System).

Als gevolg hiervan is het transformeren van uw bestandsservices in 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 Ja Nee
Standaardbestandsshares (GPv2), GRS/GZRS Ja Nee
Premium bestandsshares (FileStorage), LRS/ZRS Ja No

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 de downtime tot een minimum wordt beperkt, zodat deze in normale onderhoudsvensters past of deze slechts lichtjes overschrijdt.

Migratieoverzicht

Zoals vermeld in het artikel overzicht van Azure Files migratie, is het belangrijk om het juiste hulpprogramma en de juiste methode voor kopiëren te gebruiken. Uw Linux Samba-server maakt SMB-shares rechtstreeks beschikbaar in uw lokale netwerk. Robocopy, ingebouwd in Windows Server, is de beste manier om uw bestanden te verplaatsen in dit migratiescenario.

Als u Samba niet uitvoert op uw Linux-server en u liever mappen wilt migreren naar een hybride implementatie op Windows Server, kunt u Linux-hulpprogramma's voor kopiëren gebruiken in plaats van Robocopy. Houd rekening met de betrouwbaarheidsmogelijkheden van uw kopieerprogramma. Raadpleeg de sectie Basisprincipes van migratie in het artikel migratieoverzicht voor meer informatie over waar u op moet letten 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 Exemplaar van Windows Server (of cluster) kan maximaal 30 Azure-bestandsshares synchroniseren.

Mogelijk hebt u meer mappen op uw volumes die u momenteel lokaal deelt als SMB-shares 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 Exemplaar van Windows Server, 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 stellen 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. Het betekent alleen dat u de hoofdmappen van deze 15 shares ordent als submappen onder een gemeenschappelijke map. Vervolgens synchroniseert u deze algemene map met een Azure-bestandsshare. Op die manier is er 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 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 biedt ook voordelen voor scenario's zoals deze:

  • De eerste scan van de inhoud in de cloud kan sneller worden voltooid, waardoor er minder lang moet worden gewacht tot de naamruimte wordt weergegeven op een server die is ingeschakeld voor Azure File Sync.
  • 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. Deze toewijzing geeft aan hoeveel en welke Azure File Sync synchronisatiegroepresources u gaat inrichten. Een synchronisatiegroep verbindt de Azure-bestandsshare met de map op uw server en brengt een synchronisatieverbinding tot stand.

Bekijk de volgende limieten en best practices 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 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 in één opslagaccount te hebben geïmplementeerd, 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 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 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 gemeenschappelijke 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 de 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 de 20 miljoen of 30 miljoen in één aandeel te houden. Splits uw naamruimte 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 aantallen 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.

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

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

  • Direct gekoppelde opslag (DAS) inrichten of toevoegen. Network Attached Storage (NAS) wordt niet ondersteund.

    De hoeveelheid opslag die u inricht, kan kleiner zijn dan wat u momenteel gebruikt op uw Linux Samba-server, als u de functie Azure File Sync cloudlaag gebruikt.

De hoeveelheid opslagruimte die u inricht, kan kleiner zijn dan wat u momenteel gebruikt op uw Linux Samba-server. Voor deze configuratiekeuze moet u ook gebruikmaken van de cloudlaagfunctie van Azure File Syncs. Wanneer u echter uw bestanden 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 bestandssynchronisatie en cloudlagen inschakelen.
  3. Wanneer er meer vrije ruimte is gemaakt op het volume, gaat u verder met de volgende batch bestanden. U kunt ook de RoboCopy-opdracht in de sectie RoboCopy controleren op het gebruik van de nieuwe /LFSM switch. Het gebruik /LFSM kan uw RoboCopy-taken aanzienlijk vereenvoudigen, maar het is niet compatibel met sommige andere RoboCopy-switches waar u mogelijk afhankelijk van bent.

U kunt deze batchverwerking voorkomen door de equivalente ruimte in te richten op het Windows Server-exemplaar dat uw bestanden in beslag nemen op de Linux Samba-server. Overweeg ontdubbeling in te schakelen in Windows. Als u deze grote hoeveelheid opslag niet permanent wilt doorvoeren naar uw Windows Server-exemplaar, kunt u de volumegrootte verminderen na de migratie 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 wilt synchroniseren. Als u zich zorgen maakt, raden we u aan een configuratie met hogere prestaties te gebruiken.

Lees hoe u de grootte van een Windows Server-exemplaar kunt aanpassen 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

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.

Fase 4: Azure Storage-resources implementeren

In deze fase raadpleegt u de toewijzingstabel van 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 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.

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

Fase 6: Azure File Sync configureren op de Windows Server-implementatie

Uw geregistreerde on-premises Windows Server-exemplaar moet gereed zijn en verbonden zijn 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 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.

Belangrijk

Cloudopslaglagen is de Azure File Sync functie waarmee de lokale server minder opslagcapaciteit heeft dan is opgeslagen in de cloud, maar de volledige naamruimte beschikbaar heeft. Lokaal interessante gegevens worden ook lokaal opgeslagen in de cache voor snelle toegangsprestaties. Cloudopslaglagen is 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 op de Linux Samba-server worden gebruikt, is opslag in cloudlagen verplicht. Als u cloudopslag niet inschakelt, maakt uw server geen ruimte vrij om alle bestanden op te slaan. Stel uw lagenbeleid tijdelijk in voor de migratie 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 het toevoegen van de overeenkomende servermap als servereindpunt voor alle Azure-bestandsshares en -serverlocaties die moeten worden geconfigureerd voor synchronisatie.

Nadat alle servereindpunten zijn gemaakt, werkt de synchronisatie. U kunt een testbestand maken en zien hoe dit 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 verder leeg en wachten op gegevens. In de volgende stap begint u met het kopiëren van bestanden naar het Windows Server-exemplaar voor Azure File Sync om ze naar de cloud te verplaatsen. Als u opslag in cloudlagen hebt ingeschakeld, begint de server bestanden te tieren als de capaciteit op de lokale volumes op is.

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

  1. Identificeer de eerste locatie op uw Linux Samba-server.
  2. Identificeer de overeenkomende map op het Windows Server-exemplaar waarop al Azure File Sync is geconfigureerd.
  3. Start het kopiëren 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 op de Linux Samba-server, hebt u opslag in cloudlagen geconfigureerd. Als het lokale Windows Server-volume vol raakt, worden cloudlagen gestart en worden bestanden die al zijn gesynchroniseerd, gelaagd. Cloudopslaglagen genereren voldoende ruimte om door te gaan met het kopiëren vanaf de Linux Samba-server. Opslag in cloudlagen wordt eenmaal per uur gecontroleerd om te zien 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 kunt synchroniseren met de cloud en lokaal laag, waardoor u onvoldoende lokale schijfruimte hebt. Robocopy mislukt dan. U wordt aangeraden de shares in een volgorde te doorlopen die het probleem voorkomt. Overweeg bijvoorbeeld om Robocopy-taken niet op hetzelfde moment te starten voor alle shares. U kunt ook shares verplaatsen die passen bij 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 voor n is 8. Het maximum is 128 threads. Hoewel een hoog aantal threads helpt om 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 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 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 tijdens 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 bestand 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 kan het accepteren dat het bestand niet is gekopieerd en het in een van uw geplande, volgende Robocopy-uitvoeringen wordt onderschept, het bestand uiteindelijk met succes kunnen kopiëren. Dit helpt de huidige uitvoering sneller te voltooien zonder te worden verlengd door veel nieuwe pogingen die uiteindelijk in een meerderheid van kopieerfouten eindigen omdat bestanden 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 doelniveau. Alleen dan kan een 'inhaalkopie' succesvol zijn. Wanneer bron en doel niet overeenkomen, leidt het gebruik /MIR tot grootschalige verwijderingen en nieuwe bereik's.
/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] Fidelity voor de kopie van directory's. 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 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 daar 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 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 mogen 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 u goed gedocumenteerde testresultaten te behalen.
/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 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, nMB, of nGB. Als /LFSM is opgegeven zonder expliciete basiswaarde, 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 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 voor 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.

Fase 8: Cut-over van gebruiker

Wanneer u de Robocopy-opdracht voor de eerste keer uitvoert, hebben uw gebruikers en toepassingen nog steeds toegang tot bestanden op de Linux Samba-server en worden deze mogelijk gewijzigd. Het is mogelijk dat Robocopy een map heeft verwerkt en doorgaat naar de volgende map, 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. Deze eerste kopie 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.

De tweede keer is het sneller voltooid, omdat alleen wijzigingen hoeven te worden doorgevoerd die zijn opgetreden sinds de laatste uitvoering. Tijdens deze seconde kunnen er nog steeds nieuwe wijzigingen worden uitgevoerd.

Herhaal dit proces totdat u tevreden bent dat de hoeveelheid tijd die nodig is om een Robocopy-bewerking voor een specifieke locatie te voltooien, binnen een acceptabel venster voor downtime valt.

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

Voer nog een laatste Robocopy-ronde uit. Eventuele gemiste wijzigingen worden 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 op uw SMB-shares van uw Linux Samba-server. 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 heeft verplaatst naar uw Windows Server-exemplaar toewijzen aan de SID's van uw nieuwe lokale Windows Server-gebruikers. Als u Active Directory-accounts en ACL's hebt gebruikt, worden deze door Robocopy verplaatst 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 een gemeenschappelijk volume (afhankelijk van uw toewijzing vanaf fase 1).

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

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

Het beleid voor vrije ruimte in cloudlagenvolume werkt op volumeniveau met mogelijk meerdere servereindpunten die vanuit het volume worden gesynchroniseerd. Als u vergeet om de vrije ruimte op zelfs één servereindpunt aan te passen, blijft de synchronisatie de meest beperkende regel toepassen en wordt geprobeerd de vrije schijfruimte op 99 procent te houden. De lokale cache werkt dan mogelijk niet zoals verwacht. De prestaties kunnen acceptabel zijn als u de naamruimte wilt hebben voor een volume dat slechts zelden geopende archiveringsgegevens bevat 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 wordt eenmaal per uur uitgevoerd om inhoud te evacueren van 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 dit 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. Er breekt niets als je in deze situatie komt en je kunt vol vertrouwen verdergaan. Het ongemak van het opnieuw uitvoeren van de opdracht is het enige gevolg.

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

Volgende stappen

Er is nog meer te ontdekken over Azure-bestandsshares en Azure File Sync. De volgende artikelen bevatten geavanceerde opties, best practices en hulp bij het oplossen van problemen. Deze artikelen bevatten, indien van toepassing, een koppeling naar documentatie voor Azure-bestandsshares .