Planning voor een Azure Files Sync-implementatie

Azure File Sync is een service waarmee u verschillende Azure-bestandsshares kunt opslaan op een on-premises Windows Server- of cloud-VM.

In dit artikel maakt u kennis met concepten en functies van Azure File Sync. Zodra u bekend bent met Azure File Sync, kunt u overwegen de Implementatiehandleiding van Azure File Sync te volgen om deze service uit te proberen.

De bestanden worden opgeslagen in de cloud in Azure-bestandsshares. Azure-bestandsshares kunnen op twee manieren worden gebruikt: door deze serverloze Azure-bestandsshares (SMB) rechtstreeks te koppelen of door On-premises Azure-bestandsshares in de cache op te slaan met behulp van Azure File Sync. Welke implementatieoptie u kiest, verandert de aspecten die u moet overwegen bij het plannen van uw implementatie.

• Directe koppeling van een Azure-bestandsshare: Omdat Azure Files SMB-toegang biedt, kunt u Azure-bestandsshares on-premises of in de cloud koppelen met behulp van de standaard-SMB-client die beschikbaar is in Windows, macOS en Linux. Omdat Azure-bestandsshares serverloos zijn, is het implementeren voor productiescenario's niet nodig om een bestandsserver of NAS-apparaat te beheren. Dit betekent dat u geen softwarepatches hoeft toe te passen of fysieke schijven te wisselen.

• Cache Azure-bestandsshare on-premises met Azure File Sync: Met Azure File Sync kunt u de bestandsshares van uw organisatie centraliseren in Azure Files, terwijl u de flexibiliteit, prestaties en compatibiliteit van een on-premises bestandsserver houdt. Azure File Sync transformeert een on-premises (of cloud) Windows Server in een snelle cache van uw Azure-bestandsshare.

Beheerconcepten

Een Azure File Sync-implementatie heeft drie fundamentele beheerobjecten:

• Azure-bestandsshare: een Azure-bestandsshare is een serverloze cloudbestandsshare, die het cloudeindpunt van een Azure File Sync-synchronisatierelatie biedt. Bestanden in een Azure-bestandsshare kunnen rechtstreeks worden geopend met SMB of het FileREST-protocol, hoewel we u aanmoedigen om voornamelijk toegang te krijgen tot de bestanden via de Windows Server-cache wanneer de Azure-bestandsshare wordt gebruikt met Azure File Sync. Dit komt doordat Azure Files momenteel geen efficiënt mechanisme voor wijzigingsdetectie heeft, zoals Windows Server heeft, waardoor het rechtstreeks wijzigen van de Azure-bestandsshare tijd kost om terug te geven aan de servereindpunten.
• Servereindpunt: het pad op de Windows Server dat wordt gesynchroniseerd met een Azure-bestandsshare. Dit kan een specifieke map op een volume of de hoofdmap van het volume zijn. Meerdere servereindpunten kunnen op hetzelfde volume aanwezig zijn als hun naamruimten elkaar niet overlappen.
• Synchronisatiegroep: het object dat de synchronisatierelatie definieert tussen een cloudeindpunt of Azure-bestandsshare en een servereindpunt. Eindpunten binnen een synchronisatiegroep worden onderling synchroon gehouden. Als u bijvoorbeeld twee verschillende sets bestanden hebt die u wilt beheren met Azure File Sync, maakt u twee synchronisatiegroepen en voegt u verschillende eindpunten toe aan elke synchronisatiegroep.

Beheerconcepten voor Azure-bestandsshares

Azure-bestandsshares worden geïmplementeerd in opslagaccounts. Dat zijn objecten op het hoogste niveau die een gedeelde opslagpool vertegenwoordigen. Deze opslagpool kan worden gebruikt om meerdere bestandsshares en andere opslagresources, zoals blobcontainers, wachtrijen of tabellen, te implementeren. Alle opslagresources die in een opslagaccount worden geïmplementeerd, delen de limieten die van toepassing zijn op dat opslagaccount. Zie Azure Files-schaalbaarheids- en prestatiedoelen voor huidige opslagaccountlimieten.

Er zijn twee belangrijke soorten opslagaccounts die u voor Azure Files-implementatie gaat gebruiken:

• Opslagaccounts voor algemeen gebruik versie 2 (GPv2): met GPv2-opslagaccounts kunt u Azure-bestandsshares implementeren op hardware op basis van standard/harde schijven (HDD). Naast het opslaan van Azure-bestandsshares kunnen GPv2-opslagaccounts andere opslagresources, zoals blobcontainers, wachtrijen of tabellen, opslaan.
• FileStorage-opslagaccounts: Met FileStorage-opslagaccounts kunt u Azure-bestandsshares implementeren op premium-/SSD-hardware op basis van ssd's. FileStorage-accounts kunnen alleen worden gebruikt voor het opslaan van Azure-bestandsshares. Er kunnen geen andere opslagresources (blobcontainers, wachtrijen, tabellen enz.) worden geïmplementeerd in een FileStorage-account. Alleen FileStorage-accounts kunnen zowel SMB- als NFS-bestandsshares implementeren.

Er zijn verschillende andere typen opslagaccounts die u kunt tegenkomen in Azure Portal, PowerShell of CLI. Twee typen opslagaccounts, BlockBlobStorage- en BlobStorage-opslagaccounts, mogen geen Azure-bestandsshares bevatten. De andere twee typen opslagaccounts die u mogelijk ziet, zijn GPv1-opslagaccounts (versie 1 voor algemeen gebruik) en klassieke opslagaccounts. Beide typen kunnen Azure-bestandsshares bevatten. Hoewel GPv1-opslagaccounts en klassieke opslagaccounts Azure-bestandsshares kunnen bevatten, zijn de meeste nieuwe functies van Azure Files alleen beschikbaar in GPv2-en FileStorage-opslagaccounts. Daarom raden we u aan om alleen GPv2- en FileStorage-opslagaccounts te gebruiken voor nieuwe implementaties en om GPv1-opslagaccounts en klassieke opslagaccounts bij te werken als deze al in uw omgeving aanwezig zijn.

Azure File Sync-beheerconcepten

Synchronisatiegroepen worden geïmplementeerd in Opslagsynchronisatieservices. Dit zijn objecten op het hoogste niveau die servers registreren voor gebruik met Azure File Sync en de synchronisatiegroeprelaties bevatten. De opslagsynchronisatieserviceresource is een peer van de opslagaccountresource en kan op dezelfde manier worden geïmplementeerd in Azure-resourcegroepen. Een opslagsynchronisatieservice kan synchronisatiegroepen maken die Azure-bestandsshares bevatten tussen meerdere opslagaccounts en meerdere geregistreerde Windows-servers.

Voordat u een synchronisatiegroep in een opslagsynchronisatieservice kunt maken, moet u eerst een Windows Server registreren bij de opslagsynchronisatieservice. Hiermee maakt u een geregistreerd serverobject dat een vertrouwensrelatie vertegenwoordigt tussen uw server of cluster en de opslagsynchronisatieservice. Als u een opslagsynchronisatieservice wilt registreren, moet u eerst de Azure File Sync-agent op de server installeren. Een afzonderlijke server of cluster kan slechts bij één opslagsynchronisatieservice tegelijk worden geregistreerd.

Een synchronisatiegroep bevat één cloudeindpunt of Azure-bestandsshare en ten minste één servereindpunt. Het servereindpuntobject bevat de instellingen voor het configureren van de mogelijkheid voor cloudlagen , die de cachemogelijkheid van Azure File Sync biedt. Als u wilt synchroniseren met een Azure-bestandsshare, moet het opslagaccount met de Azure-bestandsshare zich in dezelfde Azure-regio bevinden als de opslagsynchronisatieservice.

Belangrijk

U kunt wijzigingen aanbrengen in de naamruimte van elk cloudeindpunt of servereindpunt in de synchronisatiegroep en uw bestanden laten synchroniseren met de andere eindpunten in de synchronisatiegroep. Als u rechtstreeks een wijziging aanbrengt in het cloudeindpunt (Azure-bestandsshare), moeten wijzigingen eerst worden gedetecteerd door een Azure File Sync-wijzigingsdetectietaak. Een wijzigingsdetectietaak wordt slechts eenmaal per 24 uur gestart voor een cloudeindpunt. Zie veelgestelde vragen over Azure Files voor meer informatie.

Houd rekening met het aantal opslagsynchronisatieservices dat nodig is

In een vorige sectie wordt de kernresource besproken die moet worden geconfigureerd voor Azure File Sync: een opslagsynchronisatieservice. Een Windows Server kan slechts worden geregistreerd bij één opslagsynchronisatieservice. Daarom is het vaak raadzaam om slechts één opslagsynchronisatieservice te implementeren en alle servers erop te registreren.

Maak alleen meerdere opslagsynchronisatieservices als u het volgende hebt:

• afzonderlijke sets servers die nooit gegevens met elkaar moeten uitwisselen. In dit geval wilt u het systeem ontwerpen om bepaalde sets servers uit te sluiten die moeten worden gesynchroniseerd met een Azure-bestandsshare die al wordt gebruikt als een cloudeindpunt in een synchronisatiegroep in een andere opslagsynchronisatieservice. Een andere manier om dit te bekijken, is dat Windows-servers die zijn geregistreerd bij een andere opslagsynchronisatieservice, niet kunnen worden gesynchroniseerd met dezelfde Azure-bestandsshare.
• een behoefte aan meer geregistreerde servers of synchronisatiegroepen dan één opslagsynchronisatieservice kan ondersteunen. Bekijk de Azure File Sync-schaaldoelen voor meer informatie.

Plan voor evenwichtige synchronisatietopologieën

Voordat u resources implementeert, is het belangrijk om te plannen wat u gaat synchroniseren op een lokale server, met welke Azure-bestandsshare. Door een plan te maken, kunt u bepalen hoeveel opslagaccounts, Azure-bestandsshares en synchronisatiebronnen u nodig hebt. Deze overwegingen zijn nog steeds relevant, zelfs als uw gegevens zich momenteel niet op een Windows Server bevinden of de server die u op lange termijn wilt gebruiken. De sectie Migratie kan helpen bij het bepalen van de juiste migratiepaden voor uw situatie.

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.

Overwegingen voor Windows-bestandsserver

Als u de synchronisatiemogelijkheid op Windows Server wilt inschakelen, moet u de downloadbare agent voor Azure File Sync installeren. De Azure File Sync-agent biedt twee hoofdonderdelen: FileSyncSvc.exede windows-achtergrondservice die verantwoordelijk is voor het controleren van wijzigingen op de servereindpunten en het initiëren van synchronisatiesessies, en StorageSync.syseen bestandssysteemfilter waarmee cloudlagen en snel herstel na noodgevallen mogelijk zijn.

Besturingssysteemvereisten

Azure File Sync wordt ondersteund met de volgende versies van Windows Server:

Versie	Ondersteunde SKU's	Ondersteunde implementatieopties
Windows Server 2025	Azure, Datacenter, Essentials, Standard en IoT	Volledig en kerngeheugen
Windows Server 2022	Azure, Datacenter, Essentials, Standard en IoT	Volledig en kerngeheugen
Windows Server 2019	Datacenter, Essentials, Standard en IoT	Volledig en kerngeheugen
Windows Server 2016	Datacenter, Essentials, Standard en Storage Server	Volledig en kerngeheugen
Windows Server 2012 R2*	Datacenter, Essentials, Standard en Storage Server	Volledig en kerngeheugen

*Vereist downloaden en installeren van Windows Management Framework (WMF) 5.1. Het juiste pakket voor downloaden en installeren voor Windows Server 2012 R2 is Win8.1AndW2K12R2-KB*******-x64.msu.

Toekomstige versies van Windows Server worden toegevoegd wanneer ze worden uitgebracht.

Belangrijk

We raden u aan alle servers die u gebruikt met Azure File Sync up-to-date te houden met de nieuwste updates van Windows Update.

Minimale systeembronnen

Azure File Sync vereist een server, fysiek of virtueel, met ten minste één CPU, minimaal 2 GiB geheugen en een lokaal gekoppeld volume dat is geformatteerd met het NTFS-bestandssysteem.

Belangrijk

Als de server wordt uitgevoerd op een virtuele machine waarvoor dynamisch geheugen is ingeschakeld, moet de VM worden geconfigureerd met minimaal 2048 MiB geheugen.

Voor de meeste productieworkloads raden we u niet aan om een Azure File Sync-synchronisatieserver te configureren met alleen de minimale vereisten. Zie Aanbevolen systeembronnen voor meer informatie.

Aanbevolen systeembronnen

Net als bij elke serverfunctie of -toepassing worden de vereisten voor de systeemresources voor Azure File Sync bepaald door de schaal van de implementatie; voor grotere implementaties op een server zijn meer systeembronnen vereist. Voor Azure File Sync wordt de schaal bepaald door het aantal objecten in de servereindpunten en het verloop van de gegevensset. Eén server kan servereindpunten hebben in meerdere synchronisatiegroepen en het aantal objecten dat wordt vermeld in de volgende tabel accounts voor de volledige naamruimte waaraan een server is gekoppeld.

Bijvoorbeeld: servereindpunt A met 10 miljoen objecten + servereindpunt B met 10 miljoen objecten = 20 miljoen objecten. Voor deze voorbeeldimplementatie raden we 8 CPU's aan, 16 GiB geheugen voor een stabiele status en (indien mogelijk) 48 GiB geheugen voor de eerste migratie.

Naamruimtegegevens worden om prestatieredenen opgeslagen in het geheugen. Daarom vereisen grotere naamruimten meer geheugen om goede prestaties te behouden en vereist een groter verloop meer CPU om te verwerken.

In de volgende tabel hebben we zowel de grootte van de naamruimte als een conversie naar capaciteit voor typische algemene bestandsshares opgegeven, waarbij de gemiddelde bestandsgrootte 512 KiB is. Als uw bestandsgroottes kleiner zijn, kunt u overwegen om extra geheugen toe te voegen voor dezelfde hoeveelheid capaciteit. Baseer uw geheugenconfiguratie op de grootte van de naamruimte.

Grootte van naamruimte: bestanden en mappen (miljoenen)	Typische capaciteit (TiB)	CPU-kernen	Aanbevolen geheugen (GiB)
3	1.4	2	8 (eerste synchronisatie)/ 2 (normaal verloop)
5	2.3	2	16 (eerste synchronisatie)/ 4 (normaal verloop)
10	4.7	4	32 (eerste synchronisatie)/ 8 (normaal verloop)
30	14.0	8	48 (eerste synchronisatie)/ 16 (normaal verloop)
50	23.3	16	64 (eerste synchronisatie)/ 32 (normaal verloop)
100*	46.6	32	128 (eerste synchronisatie)/ 32 (normaal verloop)

*Het synchroniseren van meer dan 100 miljoen bestanden en mappen wordt niet aanbevolen. Dit is een zachte limiet op basis van onze geteste drempelwaarden. Zie Azure File Sync-schaaldoelen voor meer informatie.

Tip

Initiële synchronisatie van een naamruimte is een intensieve bewerking en we raden u aan meer geheugen toe te wijzen totdat de initiële synchronisatie is voltooid. Dit is niet vereist, maar kan de eerste synchronisatie versnellen.

Normaal verloop is 0,5% van de naamruimte die per dag verandert. Voor een hoger verloop kunt u overwegen om meer CPU toe te voegen.

Evaluatie-cmdlet

Voordat u Azure File Sync implementeert, moet u evalueren of deze compatibel is met uw systeem met behulp van de Azure File Sync-evaluatie-cmdlet. Met deze cmdlet wordt gecontroleerd op mogelijke problemen met uw bestandssysteem en gegevensset, zoals niet-ondersteunde tekens of een niet-ondersteunde besturingssysteemversie. Deze controles hebben betrekking op de meeste, maar niet alle functies die hieronder worden genoemd; we raden u aan de rest van deze sectie zorgvuldig door te lezen om ervoor te zorgen dat uw implementatie soepel verloopt.

De evaluatie-cmdlet kan worden geïnstalleerd door de Az PowerShell-module te installeren, die kan worden geïnstalleerd door de instructies hier te volgen: Azure PowerShell installeren en configureren.

Gebruik

U kunt het evaluatieprogramma op verschillende manieren aanroepen: u kunt de systeemcontroles, de gegevenssetcontroles of beide uitvoeren. Om zowel het systeem- als de gegevenssetcontroles uit te voeren:

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

Alleen uw gegevensset testen:

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

Alleen systeemvereisten testen:

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

De resultaten weergeven in CSV:

$validation = Invoke-AzStorageSyncCompatibilityCheck C:\DATA
$validation.Results | Select-Object -Property Type, Path, Level, Description, Result | Export-Csv -Path C:\results.csv -Encoding utf8

Compatibiliteit van bestandssysteem

Azure File Sync wordt alleen ondersteund op rechtstreeks gekoppelde NTFS-volumes. Direct gekoppelde opslag of DAS op Windows Server betekent dat het Besturingssysteem Windows Server eigenaar is van het bestandssysteem. DAS kan worden geleverd via het fysiek koppelen van schijven aan de bestandsserver, het koppelen van virtuele schijven aan een bestandsserver-VM (zoals een VM die wordt gehost door Hyper-V) of zelfs via iSCSI.

Alleen NTFS-volumes worden ondersteund; ReFS, FAT, FAT32 en andere bestandssystemen worden niet ondersteund.

In de volgende tabel ziet u de interopstatus van ntfs-bestandssysteemfuncties:

Functie	Ondersteuningsstatus	Opmerkingen
ACL’s (toegangsbeheerlijsten)	Volledig ondersteund	Discretionaire toegangsbeheerlijsten in Windows-stijl blijven behouden door Azure File Sync en worden afgedwongen door Windows Server op servereindpunten. ACL's kunnen ook worden afgedwongen bij het rechtstreeks koppelen van de Azure-bestandsshare, maar hiervoor is extra configuratie vereist. Zie de sectie Identiteit voor meer informatie.
Harde koppelingen	Overgeslagen
Symbolische koppelingen	Overgeslagen
Koppelpunten	Gedeeltelijk ondersteund	Koppelpunten kunnen de hoofdmap van een servereindpunt zijn, maar ze worden overgeslagen als ze zich in de naamruimte van een servereindpunt bevinden.
Kruispunten	Overgeslagen	Bijvoorbeeld de mappen Distributed File System DfrsrPrivate en DFSRoots.
Reparsepunten	Overgeslagen
NTFS-compressie	Gedeeltelijk ondersteund	Azure File Sync biedt geen ondersteuning voor servereindpunten op een volume waarop de SVI-map (System Volume Information) is gecomprimeerd.
Sparse-bestanden	Volledig ondersteund	Synchronisatie van bestanden parseren (worden niet geblokkeerd), maar ze worden als een volledig bestand met de cloud gesynchroniseerd. Als de bestandsinhoud in de cloud (of op een andere server) verandert, wordt het bestand niet meer geparseerd wanneer de wijziging wordt gedownload.
Alternatieve gegevensstromen (ADS)	Behouden, maar niet gesynchroniseerd	Classificatietags die zijn gemaakt door de infrastructuur voor bestandsclassificatie, worden bijvoorbeeld niet gesynchroniseerd. Bestaande classificatietags voor bestanden op elk van de servereindpunten blijven ongewijzigd.

Azure File Sync slaat ook bepaalde tijdelijke bestanden en systeemmappen over:

Bestand/map	Notitie
pagefile.sys	Bestand dat specifiek is voor het systeem
Desktop.ini	Bestand dat specifiek is voor het systeem
thumbs.db	Tijdelijk bestand voor miniaturen
ehthumbs.db	Tijdelijk bestand voor mediaminiaturen
~$*.*	Tijdelijk Office-bestand
*.Tmp	Tijdelijk bestand
*.laccdb	Access DB-vergrendelingsbestand
635D02A9D91C401B97884B82B3BCDAEA.*	Intern synchronisatiebestand
\Systeemvolumegegevens	Map specifiek voor volume
$RECYCLE. VUILNISBAK	Map
\SyncShareState	Map voor synchronisatie
. SystemShareInformation	Map voor synchronisatie in Azure-bestandsshare

Notitie

Hoewel Azure File Sync ondersteuning biedt voor het synchroniseren van databasebestanden, zijn databases geen goede werkbelasting voor synchronisatieoplossingen (waaronder Azure File Sync), omdat de logboekbestanden en databases samen moeten worden gesynchroniseerd en ze om verschillende redenen kunnen worden gesynchroniseerd die tot beschadiging van de database kunnen leiden.

Bedenk hoeveel vrije ruimte u nodig hebt op uw lokale schijf

Overweeg bij het gebruik van Azure File Sync hoeveel vrije ruimte u nodig hebt op de lokale schijf waarop u een servereindpunt wilt hebben.

Met Azure File Sync moet u rekening houden met de volgende ruimte op uw lokale schijf:

• Als cloudlagen zijn ingeschakeld:

  • Reparsepunten voor gelaagde bestanden
  • Azure File Sync-metagegevensdatabase
  • Azure File Sync heatstore
  • Volledig gedownloade bestanden in uw hot cache (indien aanwezig)
  • Beleidsvereisten voor vrije ruimte voor volume

• Als cloudlagen zijn uitgeschakeld:

  • Volledig gedownloade bestanden
  • Azure File Sync heatstore
  • Azure File Sync-metagegevensdatabase

We gebruiken een voorbeeld om te laten zien hoe u een schatting maakt van de hoeveelheid vrije ruimte die nodig is op uw lokale schijf. Stel dat u uw Azure File Sync-agent hebt geïnstalleerd op uw Virtuele Azure Windows-machine en een servereindpunt op schijf F wilt maken. U hebt 1 miljoen bestanden en u wilt ze allemaal, 100.000 mappen en een schijfclustergrootte van 4 KiB. De schijfgrootte is 1000 GiB. U wilt cloudopslaglagen inschakelen en uw volumevrije ruimtebeleid instellen op 20%.

1. NTFS wijst een clustergrootte toe voor elk van de gelaagde bestanden. 1 miljoen bestanden * 4 KiB-clustergrootte = 4.000.000 KiB (4 GiB)

   Notitie

   Als u volledig wilt profiteren van cloudlagen, is het raadzaam om kleinere NTFS-clustergrootten (minder dan 64KiB) te gebruiken, omdat elk gelaagd bestand een cluster in beslag neemt. Ook wordt de ruimte die wordt bezet door gelaagde bestanden toegewezen door NTFS. Daarom wordt deze niet weergegeven in een gebruikersinterface.

2. Synchronisatiemetagegevens nemen een clustergrootte per item in beslag. (1 miljoen bestanden + 100.000 mappen) * 4 KiB-clustergrootte = 4.400.000 KiB (4,4 GiB)
3. Azure File Sync heatstore neemt 1.1 KiB per bestand in beslag. 1 miljoen bestanden * 1,1 KiB = 1.100.000 KiB (1,1 GiB)
4. Volumevrij ruimtebeleid is 20%. 1000 GiB * 0,2 = 200 GiB

In dit geval heeft Azure File Sync ongeveer 209.500.000 KiB (209,5 GiB) ruimte nodig voor deze naamruimte. Voeg deze hoeveelheid toe aan eventuele extra vrije ruimte die u wilt gebruiken om te achterhalen hoeveel vrije ruimte er nodig is voor deze schijf.

Failoverclustering

1. Failoverclustering van Windows Server wordt ondersteund door Azure File Sync voor de implementatieoptie Bestandsserver voor algemeen gebruik. Zie Een geclusterde bestandsserver met twee knooppunten implementeren voor meer informatie over het configureren van de functie 'Bestandsserver voor algemeen gebruik' op een failovercluster.
2. Het enige scenario dat wordt ondersteund door Azure File Sync is Een Windows Server-failovercluster met geclusterde schijven
3. Failoverclustering wordt niet ondersteund op scale-out bestandsserver voor toepassingsgegevens (SOFS) of op CSV's (Geclusterde gedeelde volumes) of lokale schijven.

Notitie

De Azure File Sync-agent moet worden geïnstalleerd op elk knooppunt in een failovercluster, zodat synchronisatie correct werkt.

Gegevensontdubbeling

Windows Server 2025, Windows Server 2022, Windows Server 2019 en Windows Server 2016
Gegevensontdubbeling wordt ondersteund, ongeacht of cloudlagen zijn ingeschakeld of uitgeschakeld op een of meer servereindpunten op het volume voor Windows Server 2016, Windows Server 2019, Windows Server 2022 en Windows Server 2025. Door gegevensontdubbeling in te schakelen op een volume waarvoor cloudlagen zijn ingeschakeld, kunt u meer bestanden on-premises opslaan zonder dat u meer opslag hoeft in te richten.

Wanneer gegevensontdubbeling is ingeschakeld op een volume waarvoor opslag in cloudlagen is ingeschakeld, worden geoptimaliseerde bestanden op de locatie van het servereindpunt gelaagd op basis van een normaal bestand op basis van de beleidsinstellingen voor cloudlagen. Zodra de geoptimaliseerde bestanden voor ontdubbeling zijn gelaagd, wordt de garbagecollectiontaak voor gegevensontdubbeling automatisch uitgevoerd om schijfruimte vrij te maken door onnodige segmenten te verwijderen waarnaar niet meer wordt verwezen door andere bestanden op het volume.

Let op de volumebesparingen zijn alleen van toepassing op de server; uw gegevens in de Azure-bestandsshare worden niet gededumpt.

Notitie

Ter ondersteuning van gegevensontdubbeling op volumes waarvoor cloudlagen zijn ingeschakeld op Windows Server 2019, moet Windows Update KB4520062 - oktober 2019 of een latere maandelijkse rollup-update zijn geïnstalleerd.

Windows Server 2012 R2
Azure File Sync biedt geen ondersteuning voor gegevensontdubbeling en cloudlagen op hetzelfde volume op Windows Server 2012 R2. Als gegevensontdubbeling is ingeschakeld op een volume, moet opslag in cloudlagen worden uitgeschakeld.

Notes

• Als gegevensontdubbeling wordt geïnstalleerd voordat de Azure File Sync-agent wordt geïnstalleerd, is opnieuw opstarten vereist om gegevensontdubbeling en cloudlagen op hetzelfde volume te ondersteunen.

• Als gegevensontdubbeling is ingeschakeld op een volume nadat cloudlagen zijn ingeschakeld, optimaliseert de eerste optimalisatietaak voor ontdubbeling bestanden op het volume dat nog niet is gelaagd en heeft dit de volgende invloed op cloudlagen:

  • Het beleid voor vrije ruimte blijft bestanden tieren op basis van de vrije ruimte op het volume met behulp van de heatmap.
  • Het datumbeleid slaat lagen over van bestanden die mogelijk in aanmerking komen voor lagen vanwege de optimalisatietaak voor ontdubbeling die toegang heeft tot de bestanden.

• Voor doorlopende ontdubbelingsoptimalisatietaken worden cloudlagen met datumbeleid vertraagd door de instelling MinimumFileAgeDays voor gegevensontdubbeling als het bestand nog niet is gelaagd.

  • Voorbeeld: Als de instelling MinimumFileAgeDays zeven dagen is en het datumbeleid voor cloudlagen 30 dagen is, wordt het datumbeleid bestanden na 37 dagen gelaagd.
  • Opmerking: Zodra een bestand is gelaagd door Azure File Sync, slaat de optimalisatietaak voor ontdubbeling het bestand over.

• Als een server met Windows Server 2012 R2 waarop de Azure File Sync-agent is geïnstalleerd, wordt bijgewerkt naar Windows Server 2016, Windows Server 2019, Windows Server 2022 of Windows Server 2025, moeten de volgende stappen worden uitgevoerd om gegevensontdubbeling en cloudlagen op hetzelfde volume te ondersteunen:

  • Verwijder de Azure File Sync-agent voor Windows Server 2012 R2 en start de server opnieuw op.
  • Download de Azure File Sync-agent voor de nieuwe versie van het besturingssysteem (Windows Server 2016, Windows Server 2019, Windows Server 2022 of Windows Server 2025).
  • Installeer de Azure File Sync-agent en start de server opnieuw op.

  Opmerking: de configuratie-instellingen van Azure File Sync op de server blijven behouden wanneer de agent wordt verwijderd en opnieuw wordt geïnstalleerd.

Distributed File System (DFS)

Azure File Sync ondersteunt interop met DFS-naamruimten (DFS-N) en DFS-replicatie (DFS-R).

DFS-naamruimten (DFS-N):Azure File Sync wordt volledig ondersteund met DFS-N-implementatie. U kunt de Azure File Sync-agent installeren op een of meer bestandsservers om gegevens te synchroniseren tussen de servereindpunten en het cloudeindpunt en vervolgens DFS-N gebruiken om de naamruimteservice op te geven. Zie het overzicht van DFS-naamruimten en DFS-naamruimten met Azure Files voor meer informatie.

DFS-replicatie (DFS-R):omdat DFS-R en Azure File Sync beide replicatieoplossingen zijn, raden we in de meeste gevallen aan DFS-R te vervangen door Azure File Sync. Er zijn echter verschillende scenario's waarin u DFS-R en Azure File Sync samen wilt gebruiken:

• U migreert van een DFS-R-implementatie naar een Azure File Sync-implementatie. Zie Een DFS-replicatieimplementatie (DFS-R) migreren naar Azure File Sync voor meer informatie.
• Niet elke on-premises server die een kopie van uw bestandsgegevens nodig heeft, kan rechtstreeks met internet worden verbonden.
• Vertakkingsservers consolideren gegevens op één hubserver waarvoor u Azure File Sync wilt gebruiken.

Azure File Sync en DFS-R werken naast elkaar:

1. Azure File Sync-cloudlagen moeten worden uitgeschakeld op volumes met gerepliceerde DFS-R-mappen.
2. Servereindpunten mogen niet worden geconfigureerd in dfs-R alleen-lezen replicatiemappen.
3. Slechts één servereindpunt kan overlappen met een DFS-R-locatie. Meerdere servereindpunten die overlappen met andere actieve DFS-R-locaties kunnen leiden tot conflicten.

Zie het overzicht van DFS-replicatie voor meer informatie.

Sysprep

Het gebruik van sysprep op een server waarop de Azure File Sync-agent is geïnstalleerd, wordt niet ondersteund en kan leiden tot onverwachte resultaten. Agentinstallatie en serverregistratie moeten plaatsvinden na het implementeren van de serverinstallatiekopieën en het voltooien van de mini-installatiekopieën van sysprep.

Windows Search

Als cloudlagen zijn ingeschakeld op een servereindpunt, worden bestanden die gelaagd zijn overgeslagen en worden ze niet geïndexeerd door Windows Search. Niet-gelaagde bestanden worden correct geïndexeerd.

Notitie

Windows-clients veroorzaken herinneringen bij het doorzoeken van de bestandsshare als de instelling Bestandsnamen en inhoud altijd zoeken is ingeschakeld op de clientcomputer. Deze instelling is standaard uitgeschakeld.

Andere HSM-oplossingen (Hierarchical Storage Management)

Er moeten geen andere HSM-oplossingen worden gebruikt met Azure File Sync.

Prestaties en schaalbaarheid

Omdat de Azure File Sync-agent wordt uitgevoerd op een Windows Server-computer die verbinding maakt met de Azure-bestandsshares, zijn de effectieve synchronisatieprestaties afhankelijk van een aantal factoren in uw infrastructuur: Windows Server en de onderliggende schijfconfiguratie, netwerkbandbreedte tussen de server en de Azure-opslag, bestandsgrootte, totale grootte van de gegevensset en de activiteit op de gegevensset. Omdat Azure File Sync op bestandsniveau werkt, worden de prestatiekenmerken van een op Azure File Sync gebaseerde oplossing beter gemeten in het aantal objecten (bestanden en mappen) dat per seconde wordt verwerkt.

Wijzigingen die zijn aangebracht in de Azure-bestandsshare met behulp van Azure Portal of SMB, worden niet onmiddellijk gedetecteerd en gerepliceerd, zoals wijzigingen in het servereindpunt. Azure Files heeft geen wijzigingsmeldingen of logboeken, dus er is geen manier om automatisch een synchronisatiesessie te starten wanneer bestanden worden gewijzigd. Op Windows Server gebruikt Azure File Sync Windows USN-logboeken om automatisch een synchronisatiesessie te starten wanneer bestanden worden gewijzigd.

Als u wijzigingen in de Azure-bestandsshare wilt detecteren, kent Azure File Sync een geplande taak die een wijzigingsdetectietaak wordt genoemd. Een wijzigingsdetectietaak inventariseert elk bestand in de bestandsshare en vergelijkt dit vervolgens met de synchronisatieversie voor dat bestand. Wanneer de wijzigingsdetectietaak bepaalt dat bestanden zijn gewijzigd, start Azure File Sync een synchronisatiesessie. De wijzigingsdetectietaak wordt elke 24 uur gestart. Omdat de wijzigingsdetectietaak werkt door elk bestand in de Azure-bestandsshare op te sommen, duurt wijzigingsdetectie langer in grotere naamruimten dan in kleinere naamruimten. Voor grote naamruimten kan het langer dan één keer per 24 uur duren om te bepalen welke bestanden zijn gewijzigd.

Zie metrische gegevens over prestaties van Azure File Sync en Azure File Sync-schaaldoelen voor meer informatie

Identiteit

Azure File Sync werkt met uw standaard-AD-identiteit zonder speciale instellingen, behalve het instellen van de synchronisatie. Wanneer u Azure File Sync gebruikt, is de algemene verwachting dat de meeste toegangen via de Azure File Sync-cacheservers gaan in plaats van via de Azure-bestandsshare. Omdat de servereindpunten zich op Windows Server bevinden en Windows Server al lange tijd AD- en Windows-achtige ACL's heeft ondersteund, is er niets nodig om ervoor te zorgen dat de Windows-bestandsservers die zijn geregistreerd bij de opslagsynchronisatieservice lid zijn van een domein. Azure File Sync slaat ACL's op in de bestanden in de Azure-bestandsshare en repliceert deze naar alle servereindpunten.

Hoewel het synchroniseren van de servereindpunten in de synchronisatiegroep langer duurt voordat wijzigingen rechtstreeks in de Azure-bestandsshare zijn aangebracht, wilt u er ook voor zorgen dat u uw AD-machtigingen voor uw bestandsshare rechtstreeks in de cloud kunt afdwingen. Hiervoor moet u uw opslagaccount toevoegen aan uw on-premises AD, net zoals uw Windows-bestandsservers lid zijn van een domein. Zie het overzicht van Azure Files Active Directory voor meer informatie over het toevoegen van een domein dat lid is van uw opslagaccount aan een Active Directory-account van de klant.

Belangrijk

Domein dat uw opslagaccount aan Active Directory voegt, is niet vereist om Azure File Sync te implementeren. Dit is een strikt optionele stap waarmee de Azure-bestandsshare on-premises ACL's kan afdwingen wanneer gebruikers de Azure-bestandsshare rechtstreeks koppelen.

Netwerken

De Azure File Sync-agent communiceert met uw Opslagsynchronisatieservice en Azure-bestandsshare met behulp van het Azure File Sync REST-protocol en het FileREST-protocol, die beide altijd HTTPS via poort 443 gebruiken. SMB wordt nooit gebruikt voor het uploaden of downloaden van gegevens tussen uw Windows Server en de Azure-bestandsshare. Omdat de meeste organisaties HTTPS-verkeer via poort 443 toestaan, als vereiste voor het bezoeken van de meeste websites, is speciale netwerkconfiguratie meestal niet vereist om Azure File Sync te implementeren.

Belangrijk

Azure File Sync biedt geen ondersteuning voor internetroutering. De standaardoptie voor netwerkroutering, Microsoft-routering, wordt ondersteund door Azure File Sync.

Op basis van het beleid van uw organisatie of de unieke wettelijke vereisten hebt u mogelijk meer beperkende communicatie met Azure nodig. Daarom biedt Azure File Sync verschillende mechanismen voor het configureren van netwerken. Op basis van uw vereisten kunt u het volgende doen:

• Tunnelsynchronisatie en verkeer voor het uploaden/downloaden van bestanden via uw ExpressRoute of Azure VPN.
• Maak gebruik van Azure Files- en Azure-netwerkfuncties, zoals service-eindpunten en privé-eindpunten.
• Configureer Azure File Sync om uw proxy in uw omgeving te ondersteunen.
• Netwerkactiviteit beperken vanuit Azure File Sync.

Tip

Als u wilt communiceren met uw Azure-bestandsshare via SMB, maar poort 445 wordt geblokkeerd, kunt u overwegen om SMB via QUIC te gebruiken. Dit biedt zero-config 'SMB VPN' voor SMB-toegang tot uw Azure-bestandsshares met behulp van het QUIC-transportprotocol via poort 443. Hoewel Azure Files SMB niet rechtstreeks ondersteunt via QUIC, kunt u een lichtgewicht cache van uw Azure-bestandsshares maken op een Virtuele Windows Server 2022 Azure Edition-machine met behulp van Azure File Sync. Zie SMB via QUIC met Azure File Sync voor meer informatie over deze optie.

Zie Azure File Sync-netwerkoverwegingen voor meer informatie over Azure File Sync en netwerken.

Versleuteling

Wanneer u Azure File Sync gebruikt, zijn er drie verschillende versleutelingslagen om rekening mee te houden: versleuteling op de inactieve opslag van Windows Server, versleuteling in transit tussen de Azure File Sync-agent en Azure en versleuteling in rest van uw gegevens in de Azure-bestandsshare.

Versleuteling van Windows Server-at-rest

Er zijn twee strategieën voor het versleutelen van gegevens op Windows Server die in het algemeen werken met Azure File Sync: versleuteling onder het bestandssysteem, zodat het bestandssysteem en alle gegevens die ernaar worden geschreven, worden versleuteld en versleuteling binnen de bestandsindeling zelf. Deze methoden sluiten elkaar niet wederzijds uit; ze kunnen desgewenst samen worden gebruikt omdat het doel van versleuteling anders is.

Windows Server biedt BitLocker inbox om versleuteling onder het bestandssysteem te bieden. BitLocker is volledig transparant voor Azure File Sync. De belangrijkste reden voor het gebruik van een versleutelingsmechanisme zoals BitLocker is het voorkomen van fysieke exfiltratie van gegevens uit uw on-premises datacenter door iemand die de schijven steelt en om te voorkomen dat een niet-geautoriseerd besturingssysteem wordt ge sideloaden om niet-geautoriseerde lees-/schrijfbewerkingen uit te voeren op uw gegevens. Zie bitLocker-overzicht voor meer informatie over BitLocker.

Producten van derden die op dezelfde manier werken als BitLocker, omdat ze zich onder het NTFS-volume bevinden, moeten op dezelfde manier volledig transparant werken met Azure File Sync.

De andere belangrijkste methode voor het versleutelen van gegevens is het versleutelen van de gegevensstroom van het bestand wanneer de toepassing het bestand opslaat. Sommige toepassingen kunnen dit systeemeigen doen, maar dit is meestal niet het geval. Een voorbeeld van een methode voor het versleutelen van de gegevensstroom van het bestand is Azure Information Protection (AIP)/Azure Rights Management Services (Azure RMS)/Active Directory RMS. De belangrijkste reden om een versleutelingsmechanisme zoals AIP/RMS te gebruiken, is om gegevensexfiltratie van gegevens uit uw bestandsshare te voorkomen door personen die deze kopiëren naar alternatieve locaties, zoals een flashstation, of het e-mailen naar een onbevoegde persoon. Wanneer de gegevensstroom van een bestand is versleuteld als onderdeel van de bestandsindeling, blijft dit bestand versleuteld op de Azure-bestandsshare.

Azure File Sync werkt niet samen met NTFS Encrypted File System (NTFS EFS) of versleutelingsoplossingen van derden die zich boven het bestandssysteem bevinden, maar onder de gegevensstroom van het bestand.

Versleuteling 'in transit'

Notitie

De Azure File Sync-service heeft de ondersteuning voor TLS1.0 en 1.1 verwijderd op 1 augustus 2020. Alle ondersteunde versies van de Azure File Sync-agent maken standaard al gebruik van TLS1.2. Het gebruik van een eerdere versie van TLS kan optreden als TLS1.2 is uitgeschakeld op uw server of als er een proxy wordt gebruikt. Als u een proxy gebruikt, raden we u aan de proxyconfiguratie te controleren. Azure File Sync-serviceregio's die na 1-5-2020 zijn toegevoegd, bieden alleen ondersteuning voor TLS1.2. Zie de gids voor probleemoplossing voor meer informatie.

De Azure File Sync-agent communiceert met uw Opslagsynchronisatieservice en Azure-bestandsshare met behulp van het Azure File Sync REST-protocol en het FileREST-protocol, die beide altijd HTTPS via poort 443 gebruiken. Azure File Sync verzendt geen niet-versleutelde aanvragen via HTTP.

Azure-opslagaccounts bevatten een switch voor het vereisen van versleuteling tijdens overdracht, die standaard is ingeschakeld. Zelfs als de switch op het niveau van het opslagaccount is uitgeschakeld, wat betekent dat niet-versleutelde verbindingen met uw Azure-bestandsshares mogelijk zijn, gebruikt Azure File Sync nog steeds alleen versleutelde kanalen om toegang te krijgen tot uw bestandsshare.

De primaire reden voor het uitschakelen van versleuteling tijdens overdracht voor het opslagaccount is het ondersteunen van een verouderde toepassing die moet worden uitgevoerd op een ouder besturingssysteem, zoals Windows Server 2008 R2 of oudere Linux-distributie, die rechtstreeks met een Azure-bestandsshare praat. Als de verouderde toepassing met de Windows Server-cache van de bestandsshare praat, heeft het in-/uitschakelen van deze instelling geen effect.

We raden u ten zeerste aan ervoor te zorgen dat versleuteling van gegevens in transit is ingeschakeld.

Zie Veilige overdracht vereisen in Azure Storage voor meer informatie over versleuteling in-transit.

Versleuteling van Azure-bestandsshare-at-rest

Alle gegevens die zijn opgeslagen in Azure Files worden inactief versleuteld met behulp van Azure Storage Service Encryption (SSE). Versleuteling van de opslagservice werkt op dezelfde manier als BitLocker op Windows: gegevens worden versleuteld onder het bestandssysteemniveau. Omdat gegevens worden versleuteld onder het bestandssysteem van de Azure-bestandsshare (vanwege codering naar de schijf) hoeft u geen toegang te hebben tot de onderliggende sleutel op de client om naar de Azure-bestandsshare te kunnen lezen of schrijven. Inactieve versleuteling geldt voor zowel SMB- als NFS-protocollen.

Standaard worden gegevens die zijn opgeslagen in Azure Files versleuteld met door Microsoft beheerde sleutels. Bij door Microsoft beheerde sleutels heeft Microsoft de sleutels voor het versleutelen/ontsleutelen van de gegevens en is Microsoft verantwoordelijk voor het regelmatig rouleren van de sleutels. U kunt er ook voor kiezen om uw eigen sleutels te beheren. Dit geeft u controle over het roulatieproces. Als u ervoor kiest om uw bestandsshares te versleutelen met door de klant beheerde sleutels, is Azure Files gemachtigd om toegang te krijgen tot uw sleutels om te voldoen aan lees- en schrijfaanvragen van uw klanten. Bij door de klant beheerde sleutels kunt u deze autorisatie op elk gewenst moment intrekken, maar dit houdt wel in dat uw Azure-bestandsshare niet langer toegankelijk is via SMB of de FileREST-API.

Azure Files gebruikt hetzelfde versleutelingsschema als de andere Azure-opslagservices zoals Azure Blob Storage. Raadpleeg Azure storage encryption for data at rest (Azure Storage-versleuteling voor inactieve gegevens) voor meer informatie over Azure Storage Service Encryption (SSE).

Opslaglagen

Azure Files biedt twee verschillende medialagen voor opslag, SSD en HDD, waarmee u uw shares kunt aanpassen aan de prestatie- en prijsvereisten van uw scenario:

• SSD (Premium): Premium-bestandsshares worden gebruikt door SSD's (Solid State Drives) en bieden consistente hoge prestaties en lage latentie, binnen milliseconden met één cijfer voor de meeste IO-bewerkingen, voor IO-intensieve workloads. Premium-bestandsshares zijn geschikt voor een groot aantal werkbelastingen, zoals databases, hosting van websites en ontwikkelomgevingen. Premium-bestandsshares kunnen worden gebruikt in combinatie met SMB-protocollen (Server Message Block) en NFS-protocollen (Network File System). Premium bestandsshares worden geïmplementeerd in het FileStorage-opslagaccount en zijn alleen beschikbaar in een ingericht factureringsmodel. Raadpleeg Inzicht in inrichting voor premium bestandsshares voor meer informatie over ingerichte factureringsmodellen voor premium bestandsshares. Premium-bestandsshares bieden een SLA met een hogere beschikbaarheid dan standaardbestandsshares (zie 'Azure Files Premium Tier').

• HDD (Standard): Standard-bestandsshares maken gebruik van harde schijven (HDD's) en bieden een rendabele opslagoptie voor bestandsshares voor algemeen gebruik. Standaardbestandsshares worden geïmplementeerd in het opslagaccounttype algemeen gebruik versie 2 (GPv2). Zie de pagina Azure-serviceovereenkomsten (zie 'Opslagaccounts') voor meer informatie over de SLA. Standaardbestandsshares maken gebruik van een model voor betalen per gebruik dat prijzen op basis van gebruik biedt. Met de toegangslaag van een bestandsshare kunt u de opslagkosten aanpassen aan de IOPS-kosten om uw totale factuur te optimaliseren:

  • Geoptimaliseerde bestandsshares bieden de laagste prijs voor transactietransacties voor zware werkbelastingen waarvoor de lage latentie die wordt aangeboden door Premium-bestandsshares niet nodig is. Aanbevolen tijdens het migreren van gegevens naar Azure Files.
  • Dynamische bestandsshares bieden evenwichtige opslag- en transactieprijzen voor workloads die een goede meting van beide hebben.
  • Statische bestandsshares bieden de meest rendabele opslagprijzen voor opslagintensieve workloads.

Wanneer u een medialaag voor uw workload selecteert, moet u rekening houden met uw prestatie- en gebruiksvereisten. Als voor uw workload latentie van één cijfer is vereist of als u ssd-opslagmedia on-premises gebruikt, is de Premium-laag waarschijnlijk de beste keuze. Als lage latentie geen probleem is, bijvoorbeeld met teamshares die on-premises zijn gekoppeld aan Azure, of die zich on-premises in de cache bevinden met Azure File Sync, is standaardopslag mogelijk een betere keuze vanuit een kostenperspectief.

Nadat u een bestandsshare in een opslagaccount hebt gemaakt, kunt u deze niet verplaatsen naar lagen die exclusief zijn voor verschillende opslagaccounttypen. Als u bijvoorbeeld een voor transactie geoptimaliseerde bestandsshare verplaatst naar de premium laag, moet u een nieuwe bestandsshare maken in een FileStorage-opslagaccount en de gegevens kopiëren van uw oorspronkelijke share naar een nieuwe bestandsshare in het FileStorage-account. We raden aan AzCopy te gebruiken om gegevens tussen Azure-bestandsshares te kopiëren, maar u kunt ook hulpprogramma's gebruiken als robocopy op Windows of rsync voor macOS en Linux.

Raadpleeg Azure Files-facturering begrijpen voor meer informatie.

Beschikbaarheid van Azure File Sync-regio's

Zie Producten beschikbaar per regio voor regionale beschikbaarheid.

Voor de volgende regio's moet u toegang tot Azure Storage aanvragen voordat u Azure File Sync met deze regio's kunt gebruiken:

• Frankrijk - zuid
• Zuid-Afrika - west
• UAE - centraal

Als u toegang wilt aanvragen voor deze regio's, volgt u het proces in dit document.

Redundantie

Om de gegevens in uw Azure-bestandsshares te beschermen tegen gegevensverlies of beschadiging, worden in Azure Files meerdere kopieën van elk bestand opgeslagen terwijl ze worden geschreven. Afhankelijk van uw vereisten kunt u verschillende mate van redundantie selecteren. Azure Files ondersteunt momenteel de volgende opties voor gegevensredundantie:

• Lokaal redundante opslag (LRS):met LRS wordt elk bestand drie keer opgeslagen in een Azure-opslagcluster. Dit beschermt tegen gegevensverlies als gevolg van hardwarefouten, zoals een ongeldig schijfstation. Als een noodgeval, zoals brand of overstromingen, zich echter in het datacenter voordoet, kunnen alle replica's van een opslagaccount met LRS verloren gaan of onherstelbaar zijn.
• Zone-redundante opslag (ZRS):met ZRS worden drie kopieën van elk bestand opgeslagen. Deze kopieën worden echter fysiek geïsoleerd in drie afzonderlijke opslagclusters in verschillende Azure-beschikbaarheidszones. Beschikbaarheidszones zijn unieke, fysieke locaties binnen een Azure-regio. Elke zone bestaat uit een of meer datacenters die zijn uitgerust met onafhankelijke voeding, koeling en netwerken. Een schrijfbewerking naar opslag wordt pas geaccepteerd als deze naar de opslagclusters in alle drie de beschikbaarheidszones wordt geschreven.
• Geografisch redundante opslag (GRS):met GRS hebt u twee regio's, een primaire regio en een secundaire regio. Bestanden worden drie keer opgeslagen in een Azure-opslagcluster in de primaire regio. Schrijfbewerkingen worden asynchroon gerepliceerd naar een door Microsoft gedefinieerde secundaire regio. GRS biedt zes kopieën van uw gegevens verspreid over twee Azure-regio's. In het geval van een grote ramp, zoals het permanente verlies van een Azure-regio vanwege een natuurramp of een andere soortgelijke gebeurtenis, voert Microsoft een failover uit. In dit geval wordt de secundaire de primaire, die alle bewerkingen bedient. Omdat de replicatie tussen de primaire en secundaire regio's asynchroon is, gaan in het geval van een grote noodgeval de gegevens die nog niet naar de secundaire regio worden gerepliceerd, verloren. U kunt ook een handmatige failover uitvoeren van een geografisch redundante opslagaccount.
• Geografisch zone-redundante opslag (GZRS):u kunt GZRS beschouwen als ZRS, maar met geo-redundantie. Met GZRS worden bestanden drie keer opgeslagen in drie afzonderlijke opslagclusters in de primaire regio. Alle schrijfbewerkingen worden vervolgens asynchroon gerepliceerd naar een door Microsoft gedefinieerde secundaire regio. Het failoverproces voor GZRS werkt hetzelfde als GRS.

Standard Azure-bestandsshares tot 5 TiB ondersteunen alle vier de redundantietypen. Standaardbestandsshares die groter zijn dan 5 TiB bieden alleen ondersteuning voor LRS en ZRS. Premium Azure-bestandsshares ondersteunen alleen LRS en ZRS.

Opslagaccounts voor algemeen gebruik versie 2 (GPv2) bieden twee andere redundantieopties die azure Files niet ondersteunt: leesbare geografisch redundante opslag (RA-GRS) en leesbare geografisch zone-redundante opslag (RA-GZRS). U kunt Azure-bestandsshares inrichten in opslagaccounts met deze optieset, maar Azure Files biedt geen ondersteuning voor lezen vanuit de secundaire regio. Azure-bestandsshares die zijn geïmplementeerd in RA-GRS- of RA-GZRS-opslagaccounts, worden respectievelijk gefactureerd als GRS of GZRS.

Belangrijk

Geografisch redundante en geografisch zone-redundante opslag hebben de mogelijkheid om handmatig failover-opslag naar de secundaire regio uit te voeren. We raden u aan dit niet te doen buiten een noodgeval wanneer u Azure File Sync gebruikt vanwege de verhoogde kans op gegevensverlies. In het geval van een noodgeval waarin u een handmatige failover van opslag wilt initiëren, moet u een ondersteuningsaanvraag openen bij Microsoft om Azure File Sync te laten hervatten om de synchronisatie met het secundaire eindpunt te hervatten.

Migratie

Als u een bestaande Windows-bestandsserver 2012R2 of hoger hebt, kan Azure File Sync rechtstreeks worden geïnstalleerd, zonder dat u gegevens naar een nieuwe server hoeft te verplaatsen. Als u van plan bent om te migreren naar een nieuwe Windows-bestandsserver als onderdeel van de overstap naar Azure File Sync, of als uw gegevens zich momenteel in Network Attached Storage (NAS) bevinden, zijn er verschillende mogelijke migratiemethoden voor het gebruik van Azure File Sync met deze gegevens. Welke migratiebenadering u moet kiezen, is afhankelijk van waar uw gegevens zich momenteel bevinden.

Zie het overzichtsartikel over migratie van Azure File Sync en Azure-bestandsshares voor gedetailleerde richtlijnen.

Antivirus

Omdat antivirus werkt door bestanden te scannen op bekende schadelijke code, kan een antivirusproduct leiden tot het intrekken van gelaagde bestanden, wat resulteert in hoge uitgaande kosten. Gelaagde bestanden hebben de beveiligde Windows-kenmerkset FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS en we raden u aan contact op te stellen met uw softwareleverancier om te leren hoe u hun oplossing configureert om leesbestanden over te slaan met deze kenmerkset (veel doen dit automatisch).

De interne antivirusoplossingen van Microsoft, Windows Defender en System Center Endpoint Protection (SCEP), slaan beide het lezen van bestanden met deze kenmerken automatisch over. We hebben ze getest en een klein probleem geïdentificeerd: wanneer u een server toevoegt aan een bestaande synchronisatiegroep, worden bestanden die kleiner zijn dan 800 bytes teruggehaald (gedownload) op de nieuwe server. Deze bestanden blijven op de nieuwe server staan en worden niet gelaagd omdat ze niet voldoen aan de vereiste lagengrootte (>64 kB).

Notitie

Antivirusleveranciers kunnen de compatibiliteit tussen hun product en Azure File Sync controleren met behulp van de Azure File Sync Antivirus-compatibiliteitstestsuite, die kan worden gedownload in het Microsoft Downloadcentrum.

Backup

Als cloudlagen zijn ingeschakeld, mogen oplossingen die rechtstreeks een back-up maken van het servereindpunt of een VM waarop het servereindpunt zich bevindt, niet worden gebruikt. Cloudlagen zorgen ervoor dat alleen een subset van uw gegevens wordt opgeslagen op het servereindpunt, met de volledige gegevensset die zich in uw Azure-bestandsshare bevindt. Afhankelijk van de gebruikte back-upoplossing worden gelaagde bestanden overgeslagen en wordt er geen back-up van gemaakt (omdat ze het FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS kenmerk hebben ingesteld), of worden ze teruggeroepen naar schijf, wat resulteert in hoge kosten voor uitgaand verkeer. U wordt aangeraden een back-upoplossing voor de cloud te gebruiken om rechtstreeks een back-up van de Azure-bestandsshare te maken. Zie Back-up van Azure-bestandsshares voor meer informatie of neem contact op met uw back-upprovider om te zien of ze ondersteuning bieden voor het maken van back-ups van Azure-bestandsshares.

Als u liever een on-premises back-upoplossing gebruikt, moeten back-ups worden uitgevoerd op een server in de synchronisatiegroep waarvoor cloudlagen zijn uitgeschakeld en of er geen gelaagde bestanden zijn. Wanneer u een herstelbewerking uitvoert, gebruikt u de herstelopties op volume- of bestandsniveau. Bestanden die zijn hersteld met behulp van de optie voor herstellen op bestandsniveau, worden gesynchroniseerd met alle eindpunten in de synchronisatiegroep en bestaande bestanden worden vervangen door de versie die vanuit de back-up is hersteld. Herstelbewerkingen op volumeniveau vervangen geen nieuwere bestandsversies in de Azure-bestandsshare of andere servereindpunten.

Notitie

Bare-metal (BMR) herstellen, VM-herstel, systeemherstel (windows ingebouwd besturingssysteem herstellen) en herstel op bestandsniveau met de gelaagde versie (dit gebeurt wanneer back-upsoftware een gelaagd bestand maakt in plaats van een volledig bestand) kan onverwachte resultaten veroorzaken en momenteel niet worden ondersteund wanneer cloudlagen zijn ingeschakeld. VSS-momentopnamen (inclusief het tabblad Vorige versies) worden ondersteund op volumes waarvoor cloudlagen zijn ingeschakeld. U moet echter compatibiliteit met eerdere versies inschakelen via PowerShell. Meer informatie.

Gegevensclassificatie

Als u software voor gegevensclassificatie hebt geïnstalleerd, kan het inschakelen van cloudlagen leiden tot hogere kosten om twee redenen:

1. Als cloudlagen zijn ingeschakeld, worden uw heetste bestanden lokaal in de cache opgeslagen en worden uw coolste bestanden gelaagd naar de Azure-bestandsshare in de cloud. Als uw gegevensclassificatie regelmatig alle bestanden in de bestandsshare scant, moeten de bestanden die in de cloud zijn gelaagd, worden ingetrokken wanneer ze worden gescand.

2. Als de software voor gegevensclassificatie gebruikmaakt van de metagegevens in de gegevensstroom van een bestand, moet het bestand volledig worden ingetrokken om de software de classificatie te laten zien.

Deze toenamen in zowel het aantal terugroepacties als de hoeveelheid gegevens die worden ingetrokken, kan de kosten verhogen.

Updatebeleid Azure File Sync-agent

De Azure File Sync-agent wordt regelmatig bijgewerkt om nieuwe functionaliteit toe te voegen en problemen op te lossen. U wordt aangeraden de Azure File Sync-agent bij te werken naarmate er nieuwe versies beschikbaar zijn.

Primaire versus secundaire agentversies

• Primaire agentversies bevatten vaak nieuwe functies en hebben een toenemend aantal als eerste deel van het versienummer. Bijvoorbeeld: 17.0.0.0
• Secundaire agentversies worden ook wel patches genoemd en worden vaker uitgebracht dan primaire versies. Ze bevatten vaak oplossingen voor fouten en kleinere verbeteringen, maar geen nieuwe functies. Bijvoorbeeld: 17.2.0.0

Upgradepaden

Er zijn vijf goedgekeurde en geteste manieren om de azure File Sync-agentupdates te installeren.

1. Gebruik de functie voor automatische upgrade van de Azure File Sync-agent om agentupdates te installeren. De Azure File Sync-agent wordt automatisch bijgewerkt. U kunt ervoor kiezen om de meest recente agentversie te installeren wanneer deze beschikbaar is of bijwerkt wanneer de momenteel geïnstalleerde agent bijna is verlopen. Zie Het beheer van de levenscyclus van automatische agent voor meer informatie.
2. Configureer Microsoft Update om agentupdates automatisch te downloaden en te installeren. U wordt aangeraden elke Azure File Sync-update te installeren om ervoor te zorgen dat u toegang hebt tot de meest recente oplossingen voor de serveragent. Microsoft Update maakt dit proces naadloos door automatisch updates voor u te downloaden en te installeren.
3. Gebruik AfsUpdater.exe om agentupdates te downloaden en te installeren. De AfsUpdater.exe bevindt zich in de installatiemap van de agent. Dubbelklik op het uitvoerbare bestand om agentupdates te downloaden en te installeren. Afhankelijk van de releaseversie moet u de server mogelijk opnieuw opstarten.
4. Patch een bestaande Azure File Sync-agent met behulp van een Microsoft Update-patchbestand of een .msp-uitvoerbaar bestand. Het nieuwste Azure File Sync-updatepakket kan worden gedownload uit de Microsoft Update-catalogus. Als u een .msp-uitvoerbaar bestand uitvoert, wordt uw Azure File Sync-installatie bijgewerkt met dezelfde methode die automatisch door Microsoft Update wordt gebruikt. Het toepassen van een Microsoft Update-patch voert een in-place upgrade uit van een Azure File Sync-installatie.
5. Download het nieuwste installatieprogramma van de Azure File Sync-agent vanuit het Microsoft Downloadcentrum. Als u een bestaande installatie van een Azure File Sync-agent wilt bijwerken, verwijdert u de oudere versie en installeert u vervolgens de nieuwste versie van het gedownloade installatieprogramma. De serverregistratie, synchronisatiegroepen en andere instellingen worden onderhouden door het Azure File Sync-installatieprogramma.

Notitie

De downgrade van de Azure File Sync-agent wordt niet ondersteund. De nieuwe versies bevatten vaak belangrijke wijzigingen in vergelijking met de oude versies, waardoor het downgradeproces niet wordt ondersteund. Als u problemen ondervindt met uw huidige agentversie, neemt u contact op met de ondersteuning of upgrade naar de meest recente beschikbare versie.

Automatisch levenscyclusbeheer van agents

De Azure File Sync-agent wordt automatisch bijgewerkt. U kunt een van de twee modi selecteren en een onderhoudsvenster opgeven waarin de upgrade moet worden uitgevoerd op de server. Deze functie is ontworpen om u te helpen met het levenscyclusbeheer van de agent door een kader te bieden dat verhindert dat uw agent verloopt of waardoor u geen gedoe hoeft te maken, de huidige instelling te behouden.

1. De standaardinstelling probeert te voorkomen dat de agent verloopt. Binnen 21 dagen na de geposte vervaldatum van een agent probeert de agent zelf een upgrade uit te voeren. Er wordt een poging gestart om binnen 21 dagen vóór de vervaldatum een upgrade uit te voeren en in het geselecteerde onderhoudsvenster. Met deze optie hoeft u geen normale Microsoft Update-patches te nemen.
2. U kunt eventueel selecteren dat de agent automatisch wordt bijgewerkt zodra er een nieuwe agentversie beschikbaar is (momenteel niet van toepassing op geclusterde servers). Deze update vindt plaats tijdens het geselecteerde onderhoudsvenster en stelt uw server in staat om te profiteren van nieuwe functies en verbeteringen zodra ze algemeen beschikbaar zijn. Dit is de aanbevolen, probleemloze instelling die primaire agentversies en regelmatige updatepatches op uw server biedt. Elke vrijgegeven agent is in ga-kwaliteit. Als u deze optie selecteert, voert Microsoft de nieuwste agentversie naar u uit. Geclusterde servers worden uitgesloten. Zodra de flighting is voltooid, wordt de agent ook beschikbaar in Microsoft Update en Het Microsoft Downloadcentrum.

De instelling voor automatische upgrade wijzigen

In de volgende instructies wordt beschreven hoe u de instellingen wijzigt nadat u het installatieprogramma hebt voltooid, als u wijzigingen moet aanbrengen.

Open een PowerShell-console en navigeer naar de map waarin u de synchronisatieagent hebt geïnstalleerd en importeer vervolgens de server-cmdlets. Dit ziet er standaard ongeveer als volgt uit:

cd 'C:\Program Files\Azure\StorageSyncAgent'
Import-Module -Name .\StorageSync.Management.ServerCmdlets.dll

U kunt uitvoeren Get-StorageSyncAgentAutoUpdatePolicy om de huidige beleidsinstelling te controleren en te bepalen of u deze wilt wijzigen.

Als u de huidige beleidsinstelling wilt wijzigen in het vertraagde updatespoor, kunt u het volgende gebruiken:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

Als u de huidige beleidsinstelling wilt wijzigen in het directe updatespoor, kunt u het volgende gebruiken:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest -Day <day> -Hour <hour>

Notitie

Als flighting al is voltooid voor de nieuwste agentversie en het beleid voor automatische update van de agent is gewijzigd in InstallLatest, wordt de agent pas automatisch bijgewerkt nadat de volgende agentversie is gevlucht. Als u wilt bijwerken naar een agentversie die de flighting heeft voltooid, gebruikt u Microsoft Update of AfsUpdater.exe. Als u wilt controleren of er momenteel een agentversie wordt uitgevoerd, controleert u de sectie ondersteunde versies in de releaseopmerkingen.

Garanties voor levenscyclus van agents en wijzigingsbeheer

Azure File Sync is een cloudservice die voortdurend nieuwe functies en verbeteringen introduceert. Dit betekent dat een specifieke versie van de Azure File Sync-agent slechts gedurende een beperkte tijd kan worden ondersteund. Om uw implementatie te vergemakkelijken, garanderen de volgende regels dat u voldoende tijd en meldingen hebt voor agentupdates/upgrades in uw wijzigingsbeheerproces:

• Primaire agentversies worden ten minste zes maanden vanaf de datum van de eerste release ondersteund.
• We garanderen dat er ten minste drie maanden tussen de ondersteuning van primaire agentversies overlappen.
• Waarschuwingen worden afgegeven voor geregistreerde servers die ten minste drie maanden voor de vervaldatum een verlopen agent gebruiken. U kunt controleren of een geregistreerde server een oudere versie van de agent gebruikt in de sectie geregistreerde servers van een opslagsynchronisatieservice.
• De levensduur van een secundaire agentversie is gebonden aan de bijbehorende primaire versie. Als bijvoorbeeld agentversie 17.0.0.0 is ingesteld op verlopen, worden agentversies 17.*.*.* allemaal ingesteld om samen te verlopen.

Notitie

Als u een agentversie installeert met een vervaldatumwaarschuwing, wordt een waarschuwing weergegeven, maar slaagt u wel. Het installeren of verbinden met een verlopen agentversie wordt niet ondersteund en wordt geblokkeerd.

Volgende stappen

• Overweeg firewall- en proxyinstellingen
• Azure Files implementeren
• Azure Files SYNC implementeren
• Azure File Sync bewaken