Een Azure File Sync-implementatie plannen

Azure File Sync is een service die u kunt gebruiken om verschillende Azure-bestandsshares in de cache op te slaan op een on-premises Windows Server-exemplaar of virtuele machine in de cloud (VM).

In dit artikel maakt u kennis met concepten en functies van Azure File Sync. Nadat 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. U kunt Azure-bestandsshares op de volgende twee manieren gebruiken. Welke implementatieoptie u kiest, verandert de aspecten die u moet overwegen bij het plannen van uw implementatie.

• Een Azure-bestandsshare rechtstreeks koppelen met behulp van het SMB-protocol (Server Message Block): 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, hoeft u voor productiescenario's geen nas-apparaat (file server of network-attached storage) te beheren. Deze keuze betekent dat u geen softwarepatches hoeft toe te passen of fysieke schijven te wisselen.

• Een On-premises Azure-bestandsshare in de cache opslaan met behulp van 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-exemplaar in een snelle cache van uw Azure-bestandsshare.

Beheerconcepten

In Azure is een resource een beheerbaar item dat u maakt en configureert binnen uw Azure-abonnementen en -resourcegroepen. Resources worden aangeboden door resourceproviders, die beheerservices zijn die specifieke typen resources leveren. Als u Azure File Sync wilt implementeren, werkt u met twee belangrijke resources:

• Opslagaccounts, aangeboden door de Microsoft.Storage resourceprovider. Opslagaccounts zijn resources op het hoogste niveau die een gedeelde opslaggroep, IOPS en doorvoer vertegenwoordigen waarin u klassieke bestandsshares of andere opslagbronnen kunt implementeren, afhankelijk van het type opslagaccount. Alle opslagresources die in een opslagaccount worden geïmplementeerd, delen de limieten die van toepassing zijn op dat opslagaccount. Klassieke bestandsshares ondersteunen zowel de protocollen voor het delen van SMB- als NFS-bestanden, maar u kunt Azure File Sync alleen gebruiken met SMB-bestandsshares.

  Notitie

  Azure Files biedt ook ondersteuning voor het implementeren van bestandsshares als een Azure-resource op het hoogste niveau via de Microsoft.FileShares resourceprovider. Omdat deze bestandsshares momenteel echter alleen het NFS-protocol ondersteunen, worden ze niet ondersteund door Azure File Sync.

• Opslagsynchronisatieservices, aangeboden door de Microsoft.StorageSync resourceprovider. Opslagsynchronisatieservices fungeren als beheercontainers waarmee u Windows-bestandsservers kunt registreren en de synchronisatierelaties voor Azure File Sync kunt definiëren.

Beheerconcepten voor Azure-bestandsshares

Klassieke bestandsshares of bestandsshares die zijn geïmplementeerd in opslagaccounts, zijn de traditionele manier om bestandsshares voor Azure Files te implementeren. Ze ondersteunen alle belangrijke functies die Azure Files ondersteunt, waaronder SMB- en NFS-, SSD- en HDD-medialagen, elk redundantietype en in elke regio. Zie klassieke bestandsshares voor meer informatie over klassieke bestandsshares.

Er zijn twee soorten opslagaccounts die worden gebruikt voor klassieke bestandsshare-implementaties:

• Ingerichte opslagaccounts: Ingerichte opslagaccounts worden onderscheiden met behulp van het FileStorage type opslagaccount. Met ingerichte opslagaccounts kunt u ingerichte klassieke bestandsshares implementeren op SSD- of HDD-hardware. Ingerichte opslagaccounts kunnen alleen worden gebruikt voor het opslaan van klassieke bestandsshares en kunnen geen andere opslagbronnen gebruiken, zoals blobcontainers, wachtrijen en tabellen. Het is raadzaam om ingerichte opslagaccounts te gebruiken voor alle nieuwe klassieke bestandsshareimplementaties.
• Opslagaccounts voor betalen per gebruik: Opslagaccounts voor betalen per gebruik worden onderscheiden met behulp van het StorageV2 opslagaccounttype. Met opslagaccounts voor betalen per gebruik kunt u betalen per gebruik bestandsshares implementeren op HDD-gebaseerde hardware. Opslagaccounts voor betalen per gebruik kunnen worden gebruikt voor het opslaan van klassieke bestandsshares en andere opslagbronnen, zoals blobcontainers, wachtrijen of tabellen.

Azure File Sync-beheerconcepten

Binnen een opslagsynchronisatieservice kunt u het volgende implementeren:

• Geregistreerde servers, die een Windows-bestandsserver vertegenwoordigen met een vertrouwensrelatie met de opslagsynchronisatieservice. Geregistreerde servers kunnen een afzonderlijke server of een cluster zijn, maar een server/cluster kan slechts worden geregistreerd bij slechts één opslagsynchronisatieservice tegelijk.

• Synchronisatiegroepen, waarmee de synchronisatierelatie tussen een cloudeindpunt en een of meer servereindpunten wordt gedefinieerd. 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.

  • Cloudeindpunten, die Azure-bestandsshares vertegenwoordigen.
  • Servereindpunten, die paden vertegenwoordigen op geregistreerde servers die zijn gesynchroniseerd met Azure Files. Een geregistreerde server kan meerdere servereindpunten bevatten als hun naamruimten elkaar niet overlappen.

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), moet eerst een Wijzigingsdetectietaak van Azure File Sync wijzigingen detecteren. Een wijzigingsdetectietaak voor een cloudeindpunt wordt slechts één keer per 24 uur gestart. Zie veelgestelde vragen over Azure Files en Azure File Sync voor meer informatie.

Aantal benodigde opslagsynchronisatieservices

Een opslagsynchronisatieservice is de hoofdresource van Azure Resource Manager voor Azure File Sync. Hiermee worden synchronisatierelaties tussen uw Windows Server-installaties en Azure-bestandsshares beheerd. Elke opslagsynchronisatieservice kan meerdere synchronisatiegroepen en meerdere geregistreerde servers bevatten.

Elk Windows Server-exemplaar kan worden geregistreerd bij slechts één opslagsynchronisatieservice. Na de registratie kan de server deelnemen aan meerdere synchronisatiegroepen binnen die opslagsynchronisatieservice met behulp van een Resource Manager-principal om servereindpunten op de server te maken.

Wanneer u Azure File Sync-topologieën ontwerpt, moet u gegevens duidelijk isoleren op het niveau van de opslagsynchronisatieservice. Als uw bedrijf bijvoorbeeld afzonderlijke Azure File Sync-omgevingen voor twee afzonderlijke bedrijfseenheden vereist en u strikte gegevensisolatie tussen deze groepen nodig hebt, moet u voor elke groep een speciale opslagsynchronisatieservice maken. Vermijd het plaatsen van synchronisatiegroepen voor beide bedrijfsgroepen binnen dezelfde opslagsynchronisatieservice, omdat deze configuratie niet zorgt voor volledige isolatie.

Raadpleeg Azure-resourceproviders en -typen voor meer informatie over gegevensisolatie met behulp van afzonderlijke abonnementen of resourcegroepen in Azure.

Planning voor evenwichtige synchronisatietopologieën

Voordat u resources implementeert, is het belangrijk om te plannen wat u gaat synchroniseren op een lokale server en met welke Azure-bestandsshare. Door een plan te maken, kunt u bepalen hoeveel opslagaccounts, Azure-bestandsshares en synchronisatiebronnen u nodig hebt. Deze overwegingen zijn relevant, zelfs als uw gegevens zich momenteel niet op een Windows Server-exemplaar of op de server bevinden die u op lange termijn wilt gebruiken. De migratiesectie van dit artikel kan u 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 aan te raden.

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 hebt u 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 vanuit de cloud vanuit een momentopname van een Azure-bestandsshare verloopt sneller.
• Herstel na noodgevallen van een on-premises server kan aanzienlijk versnellen.
• Wijzigingen die rechtstreeks in een Azure-bestandsshare (buiten een synchronisatie) zijn aangebracht, kunnen sneller worden gedetecteerd en gesynchroniseerd.

Aanbeveling

Als u niet weet hoeveel bestanden en mappen u hebt, bekijkt u het hulpprogramma TreeSize van JAM Software.

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 uw kaart te optimaliseren en te bepalen hoeveel Azure-bestandsshares u nodig hebt:

• 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 wanneer u Azure-bestandsshares implementeert. In het ideale geval moet u bestandsshares 1:1 toewijzen met opslagaccounts. Deze toewijzing is echter mogelijk niet altijd mogelijk vanwege verschillende limieten en beperkingen, zowel van uw organisatie als van Azure. Wanneer u niet slechts één bestandsshare in één opslagaccount kunt implementeren, moet u overwegen welke shares zeer actief zijn en welke shares minder actief zijn. Plaats de heetste bestandsshares niet samen in hetzelfde opslagaccount.

  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.

Aanbeveling

Op basis van 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 mogelijk dat in uw situatie een set mappen logisch kan worden gesynchroniseerd met dezelfde Azure-bestandsshare (met behulp van de eerder genoemde algemene basisbenadering). Het is echter nog steeds beter om mappen opnieuw te groeperen, zodat ze worden gesynchroniseerd met twee Azure-bestandsshares in plaats van één. 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 op meer on-premises servers om de mogelijkheid om te synchroniseren met 30 meer Azure-bestandsshares per extra server toe te voegen.

Belangrijk

De belangrijkste schaalvector voor Azure File Sync is het aantal items (bestanden en mappen) dat moet worden gesynchroniseerd. Raadpleeg de Azure File Sync-schaaldoelen voor meer informatie.

Veelvoorkomende scenario's en overwegingen voor bestandssynchronisatie

Synchronisatiescenario	Ondersteund	Overwegingen (of beperkingen)	Oplossing (of tijdelijke oplossing)
Bestandsserver met meerdere schijven/volumes en meerdere shares met dezelfde Azure-doelbestandsshare (samenvoeging)	Nee	Een Azure-doelbestandsshare (cloudeindpunt) ondersteunt synchronisatie met slechts één synchronisatiegroep. Een synchronisatiegroep ondersteunt slechts één servereindpunt per geregistreerde server.	1) Begin met het synchroniseren van één schijf (het hoofdvolume) naar een Azure-doelbestandsshare. Beginnend met de grootste schijf/het grootste volume, helpt u bij de opslagvereisten on-premises. Configureer cloudlagen om alle gegevens in de cloud te tieren, zodat u ruimte vrij kunt maken op de schijf van de bestandsserver. 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 of gemigreerd. 2) Doel één hoofdvolume (schijf) tegelijk. Gebruik cloudlagen om alle gegevens in een laag te plaatsen op de Azure-doelbestandsshare. Verwijder het servereindpunt uit de synchronisatiegroep, maak het eindpunt opnieuw met het volgende hoofdvolume/de volgende schijf, synchroniseer en herhaal het proces. Houd er rekening mee dat u de agent mogelijk opnieuw moet installeren. 3) Het gebruik van meerdere Azure-doelbestandsshares (hetzelfde of een ander opslagaccount, op basis van prestatievereisten) aanbevelen.
Bestandsserver met één volume en meerdere shares met dezelfde Azure-doelbestandsshare (samenvoeging)	Ja	U kunt niet meerdere servereindpunten per geregistreerde server synchroniseren met dezelfde Azure-doelbestandsshare (hetzelfde als het vorige scenario).	Synchroniseer de hoofdmap van het volume met meerdere shares of mappen op het hoogste niveau.
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. U kunt het beste onder de 20 of 30 miljoen per aandeel 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 sharegroepering en volumesynchronisatie om het aantal hoofdmappen of mappen op het hoogste niveau op de bron te verminderen. 3) Gebruik aanvullende On-premises Azure File Sync-servers en splits of verplaats gegevens naar deze servers om beperkingen voor het Windows Server-bronexemplaren te omzeilen.
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. U kunt het beste onder de 20 of 30 miljoen per aandeel blijven.	Hetzelfde als de vorige benadering.
Meerdere bestandsservers met één hoofdvolume of share met dezelfde Azure-doelbestandsshare (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 het eerste scenario, waarbij u rekening moet houden met één bestandsserver tegelijk.
Topologie tussen huurders (gebruik van beheerde identiteit tussen huurders)	Nee	De opslagsynchronisatieservice, de serverresource (server met Azure Arc of azure-VM), de beheerde identiteit en de RBAC-toewijzingen in het opslagaccount moeten allemaal zich in dezelfde Microsoft Entra-tenant bevinden. Topologieën tussen tenants worden niet ondersteund.	Inrichtingen tussen tenants mislukken met verificatie en autorisatie, waardoor de server geen verbinding kan maken. Als u wilt doorgaan, moet u ervoor zorgen dat alle resources (Synchronisatieservice, server, beheerde identiteit en RBAC-toewijzingen) worden gemaakt in dezelfde Microsoft Entra-tenant.

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 het verliezen van details van uw toewijzingsplan eenvoudig kan gebeuren 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-bestandsservers

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.exe, de windows-achtergrondservice die verantwoordelijk is voor het controleren van wijzigingen op de servereindpunten en het initiëren van synchronisatiesessies
• StorageSync.sys, een bestandssysteemfilter dat cloudlagen en snel herstel na noodgevallen mogelijk maakt

Besturingssysteemvereisten

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

Versie	RTM-versie	Ondersteunde edities	Ondersteunde implementatieopties
Windows Server 2025	26100	Azure, Datacenter, Essentials, Standard en IoT	Volledig en kerngeheugen
Windows Server 2022	20348	Azure, Datacenter, Essentials, Standard en IoT	Volledig en kerngeheugen
Windows Server 2019	17763	Datacenter, Essentials, Standard en IoT	Volledig en kerngeheugen
Windows Server 2016	14393	Datacenter, Essentials, Standard en Storage Server	Volledig en kerngeheugen

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 al deze kenmerken:

• Ten minste één CPU.
• Minimaal 2 GiB geheugen. Als de server wordt uitgevoerd op een virtuele machine waarvoor dynamisch geheugen is ingeschakeld, configureert u de VIRTUELE machine met minimaal 2048 MiB aan geheugen.
• Een lokaal gekoppeld volume dat is geformatteerd met het NTFS-bestandssysteem.

Voor de meeste productieworkloads raden we u niet aan om een synchronisatieserver in Azure File Sync te configureren met alleen de minimale vereisten.

Aanbevolen systeembronnen

Net als elke serverfunctie of toepassing bepaalt de schaal van de implementatie de systeemresourcevereisten voor Azure File Sync. Grotere implementaties op een server vereisen meer systeembronnen.

Voor Azure File Sync bepaalt het aantal objecten in de servereindpunten en het verloop op de gegevensset de schaal. Eén server kan servereindpunten in meerdere synchronisatiegroepen hebben. Het aantal objecten in de volgende tabelaccounts 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. Vanwege deze configuratie vereisen grotere naamruimten meer geheugen om goede prestaties te behouden. Meer verloop vereist dat er meer CPU's worden verwerkt.

De volgende tabel bevat zowel de grootte van de naamruimte als een conversie naar capaciteit voor typische algemene bestandsshares, waarbij de gemiddelde bestandsgrootte 512 KiB is. Als uw bestandsgrootten kleiner zijn, kunt u overwegen om meer 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.

Aanbeveling

Initiële synchronisatie van een naamruimte is een intensieve bewerking. U wordt aangeraden meer geheugen toe te wijzen totdat de initiële synchronisatie is voltooid. Deze methode 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's 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 in dit artikel worden genoemd. We raden u aan de rest van deze sectie zorgvuldig door te lezen om ervoor te zorgen dat uw implementatie soepel verloopt.

U kunt de evaluatie-cmdlet installeren door de Az PowerShell-module te installeren. Zie Azure PowerShell installeren voor instructies.

Gebruik

U kunt het evaluatieprogramma aanroepen door systeemcontroles, gegevenssetcontroles of beide uit te voeren. Systeem- en gegevenssetcontroles uitvoeren:

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 een .csv-bestand:

$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 (DAS) op Windows Server betekent dat het Besturingssysteem Windows Server eigenaar is van het bestandssysteem. U kunt DAS opgeven door schijven fysiek toe te voegen aan de bestandsserver, virtuele schijven te koppelen aan een bestandsserver-VM (zoals een VM die wordt gehost door Hyper-V), of zelfs met behulp van iSCSI.

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

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

Functie	Ondersteuningsstatus	Opmerkingen
ACL’s (toegangsbeheerlijsten)	Volledig ondersteund	Azure File Sync behoudt discretionaire ACL's in Windows-stijl. Windows Server dwingt deze ACL's af op servereindpunten. U kunt ACL's ook afdwingen wanneer u de Azure-bestandsshare rechtstreeks aan het koppelen bent, maar voor deze methode is extra configuratie vereist. Zie de sectie Identiteit verderop in dit artikel 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 de naamruimte van een servereindpunt deze bevat.
Kruispunten	Overgeslagen	Voorbeelden zijn DFS (Distributed File System) DfrsrPrivate en DFSRoots mappen.
Reparsepunten	Overgeslagen
NTFS-compressie	Gedeeltelijk ondersteund	Azure File Sync biedt geen ondersteuning voor servereindpunten op een volume dat de SVI-map (System Volume Information) comprimeert.
Sparse-bestanden	Volledig ondersteund	Sparse bestanden synchroniseren (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 door infrastructuur voor bestandsclassificatie worden gemaakt, worden bijvoorbeeld niet gesynchroniseerd. Bestaande classificatietags voor bestanden op elk van de servereindpunten blijven ongewijzigd.

Notitie

NTFS-compressie met cloud-tiering

Het gebruik van NTFS-compressie op gelaagde bestanden kan aanzienlijke invloed hebben op de prestaties. Het wordt aanbevolen om cloud-tiering niet te gebruiken met gecomprimeerde bestanden.

Als gecomprimeerde bestanden al zijn getierd, moeten ze worden uitgepakt nadat de gegevens uit de cloud zijn teruggeroepen door het volgende uit te voeren:

Invoke-StorageSyncFileRecall -FilePath <path>
compact /U /S <filepath>

Het gebruik van NTFS-compressie op gelaagde bestanden kan aanzienlijke invloed hebben op de prestaties. Het wordt aanbevolen om cloud-tiering niet te gebruiken met gecomprimeerde bestanden.

U kunt bestanden opheffen met behulp van de compacte opdracht.

In Windows Server 2019 of hoger slaat het compact commando gelaagde bestanden over, dus u moet het bestand eerst terughalen voordat u het decomprimeert.

Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"
Invoke-StorageSyncFileRecall -FilePath <path>
compact /U /S <filepath>

Wanneer bestandsterugroepingen leiden tot problemen met weinig schijfruimte, moet u wachten tot de achtergrond-tiering in werking treedt en het bestand in de juiste tier plaatsen voordat u meer bestanden terugroept of het bestand opnieuw in de tier plaatsen na decomprimeren door de cmdlet uit te voeren.

Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"
Invoke-StorageSyncCloudTiering -Path <path>

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

Bestand/map	Notitie
pagefile.sys	Bestand dat specifiek is voor een systeem
Desktop.ini	Bestand dat specifiek is voor een systeem
thumbs.db	Tijdelijk bestand voor miniaturen
ehthumbs.db	Tijdelijk bestand voor mediaminiaturen
~$*.*	Tijdelijk Office-bestand
*.tmp	Tijdelijk bestand
*.laccdb	Access-databasevergrendelingsbestand
635D02A9D91C401B97884B82B3BCDAEA.*	Intern synchronisatiebestand
\System Volume Information	Map die specifiek is voor een volume
$RECYCLE.BIN	Map
\SyncShareState	Map voor synchronisatie
.SystemShareInformation	Map voor synchronisatie in een Azure-bestandsshare

Notitie

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

Vrije ruimte op uw lokale schijf

Wanneer u van plan bent om Azure File Sync te gebruiken, moet u overwegen hoeveel vrije ruimte u nodig hebt op de lokale schijf voor uw servereindpunt.

Met Azure File Sync moet u rekening houden met de volgende items die ruimte in beslag nemen op uw lokale schijf:

• Als cloudlagen zijn ingeschakeld:

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

• Als cloudlagen zijn uitgeschakeld:

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

In het volgende voorbeeld ziet u hoe u een schatting maakt van de hoeveelheid vrije ruimte die u nodig hebt op uw lokale schijf. Stel dat u uw Azure File Sync-agent hebt geïnstalleerd op uw Azure Windows-VM en dat u van plan bent een servereindpunt op schijf F te maken. U hebt 1 miljoen bestanden (en u wilt ze allemaal in een laag zetten), 100.000 mappen en een schijfclustergrootte van 4 KiB. De schijfgrootte is 1000 GiB. U wilt cloudlagen inschakelen en uw volumeruimtebeleid instellen op 20%.

• NTFS wijst een clustergrootte toe voor elk van de gelaagde bestanden:

  1 miljoen bestanden * 4 KiB-clustergrootte = 4.000.000 KiB (4 GiB)

  Om volledig te profiteren van cloudlagen, raden we u aan om kleinere NTFS-clustergrootten (minder dan 64 KiB) te gebruiken omdat elk gelaagd bestand een cluster in beslag neemt. Ntfs wijst ook de ruimte toe die gelaagde bestanden in beslag nemen. Deze ruimte wordt niet weergegeven in een gebruikersinterface.

• Synchronisatiemetagegevens nemen een clustergrootte per item in beslag:

  (1 miljoen bestanden + 100.000 mappen) * 4 KiB-clustergrootte = 4.400.000 KiB (4,4 GiB)

• 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)

• 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 vrije ruimte die u mogelijk nodig hebt voor deze schijf.

Failoverclustering

Azure File Sync biedt ondersteuning voor Windows Server-failoverclustering voor de bestandsserver voor implementatieopties voor algemeen gebruik . Zie Een geclusterde bestandsserver met twee knooppunten implementeren voor meer informatie over het configureren van de bestandsserver voor algemeen gebruik op een failovercluster.

Het enige scenario dat Azure File Sync ondersteunt, is een Windows Server-failovercluster met geclusterde schijven. Failoverclustering wordt niet ondersteund op Scale-Out Bestandsserver, CSV's (Cluster Shared Volumes) of lokale schijven.

Synchronisatie werkt alleen correct als de Azure File Sync-agent op elk knooppunt in een failovercluster is geïnstalleerd.

Gegevensontdubbeling

Windows Server 2025, Windows Server 2022, Windows Server 2019 en Windows Server 2016

Gegevensontdubbeling wordt ondersteund of cloudlagen zijn ingeschakeld of uitgeschakeld op een of meer servereindpunten op het volume voor Windows Server 2025, Windows Server 2022, Windows Server 2019 en Windows Server 2016. 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 u gegevensontdubbeling inschakelt op een volume waarvoor opslaglagen in de cloud zijn ingeschakeld, worden ontdubbeling geoptimaliseerde bestanden binnen de locatie van het servereindpunt op dezelfde manier gelaagd als een normaal bestand, op basis van de beleidsinstellingen voor cloudlagen. Nadat u de ontdubbelings geoptimaliseerde bestanden hebt gelaagd, wordt de garbagecollectiontaak voor gegevensontdubbeling automatisch uitgevoerd. Er wordt schijfruimte vrijgemaakt door overbodige segmenten te verwijderen waarnaar andere bestanden op het volume niet meer verwijzen.

In sommige gevallen waarin gegevensontdubbeling is geïnstalleerd, kan de beschikbare volumeruimte groter worden dan verwacht nadat de ontdubbeling garbagecollection is geactiveerd. In het volgende voorbeeld wordt beschreven hoe volumeruimte werkt:

1. Het beleid voor vrije ruimte voor cloudlagen is ingesteld op 20%.
2. Azure File Sync wordt gewaarschuwd wanneer vrije ruimte laag is (bijvoorbeeld 19%).
3. Lagen bepalen dat 1% meer ruimte vrij moet worden gemaakt, maar u wilt 5% extra, zodat u maximaal 25% (bijvoorbeeld 30 GiB) laagt.
4. De bestanden worden gelaagd totdat u 30 GiB bereikt.
5. Als onderdeel van interoperabiliteit met Gegevensontdubbeling start Azure File Sync garbagecollection aan het einde van de gelaagde sessie.

De volumebesparingen zijn alleen van toepassing op de server. Uw gegevens in de Azure-bestandsshare worden niet ontdubbeld.

Notitie

Als u gegevensontdubbeling wilt ondersteunen op volumes waarvoor cloudlagen zijn ingeschakeld op Windows Server 2019, moet u Windows Update installeren KB4520062 - oktober 2019 of een latere maandelijkse update voor rollup.

Windows Server 2012 R2

Azure File Sync biedt geen ondersteuning voor gegevensontdubbeling en cloudlagen op hetzelfde volume op Windows Server 2012 R2. Als u Gegevensontdubbeling inschakelt op een volume, moet u cloudlagen uitschakelen.

Opmerkingen

• Als u Gegevensontdubbeling installeert voordat u de Azure File Sync-agent installeert, is opnieuw opstarten vereist om gegevensontdubbeling en cloudlagen op hetzelfde volume te ondersteunen.

• Als u Gegevensontdubbeling inschakelt op een volume nadat u cloudlagen hebt ingeschakeld, optimaliseert de eerste optimalisatietaak voor ontdubbeling bestanden op het volume dat nog niet is gelaagd. Deze taak heeft 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 anders in aanmerking komen voor lagen, omdat de optimalisatietaak voor ontdubbeling toegang heeft tot de bestanden.

• Voor doorlopende ontdubbelingsoptimalisatietaken vertraagt de instelling MinimumFileAgeDays voor gegevensontdubbeling met het gegevensbeleid als het bestand nog niet is gelaagd.

  • Als de MinimumFileAgeDays instelling bijvoorbeeld 7 dagen is en het gegevensbeleid voor cloudlagen 30 dagen is, worden de bestanden met datumbeleidslagen na 37 dagen weergegeven.
  • Nadat Azure File Sync een bestand heeft gelaagd, 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 2025, Windows Server 2022, Windows Server 2019 of Windows Server 2016, moet u de volgende stappen uitvoeren om gegevensontdubbeling en cloudlagen op hetzelfde volume te ondersteunen:

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

  De azure File Sync-configuratie-instellingen van de server blijven behouden wanneer de agent wordt verwijderd en opnieuw wordt geïnstalleerd.

Gedistribueerd bestandssysteem

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

DFS-N

Azure File Sync wordt volledig ondersteund met de 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-R

Omdat DFS-R en Azure File Sync beide replicatieoplossingen zijn, raden we u aan om in de meeste gevallen DFS-R te vervangen door Azure File Sync. Maar in de volgende scenario's moet u DFS-R en Azure File Sync samen gebruiken:

• U migreert van een DFS-R-implementatie naar een Azure File Sync-implementatie. Zie Een DFS-R-implementatie 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:

• Azure File Sync-cloudlagen moeten worden uitgeschakeld op volumes met gerepliceerde DFS-R-mappen.
• Servereindpunten mogen niet worden geconfigureerd in dfs-R alleen-lezen replicatiemappen.
• 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-naamruimten en DFS-replicatie voor meer informatie.

Sysprep

Sysprep gebruiken 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 nadat u de serverinstallatiekopieën hebt geïmplementeerd en sysprep mini-installatie hebt voltooid.

Windows Zoeken

Als cloudlagen zijn ingeschakeld op een servereindpunt, slaat Windows Search bestanden over die gelaagd zijn en indexeert deze niet. Windows Search indexeert niet-gelaagde bestanden correct.

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

Andere HSM-oplossingen

Gebruik geen andere HSM-oplossingen (Hierarchical Storage Management) 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 deze factoren in uw infrastructuur:

• Windows Server en de onderliggende schijfconfiguratie
• Netwerkbandbreedte tussen de server en de Azure-opslag
• Bestandsgrootte
• Totale grootte van gegevensset
• Activiteit op de gegevensset

Azure File Sync werkt op bestandsniveau. De prestatiekenmerken van een oplossing op basis van Azure File Sync worden beter gemeten in het aantal objecten (bestanden en mappen) dat per seconde wordt verwerkt.

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

Identiteit

De beheerder die de server registreert en het cloudeindpunt maakt, moet lid zijn van de beheerrol Azure File Sync-beheerder, -eigenaar of -inzender voor de opslagsynchronisatieservice. U kunt deze rol configureren onder Toegangsbeheer (IAM) op de azure-portalpagina voor de opslagsynchronisatieservice.

Wanneer u de rol Azure File Sync-beheerder toewijst, volgt u deze stappen om de minimale bevoegdheden te garanderen.

1. Selecteer op het tabblad Voorwaarden de optie Toestaan dat gebruikers geselecteerde rollen toewijzen aan alleen geselecteerde principals (minder bevoegdheden).

2. Klik op Rollen en principals selecteren en selecteer vervolgens Actie toevoegen onder Voorwaarde 1.

3. Selecteer Roltoewijzing maken en klik vervolgens op Selecteren.

4. Selecteer Expressie toevoegen en selecteer Vervolgens Aanvraag.

5. Selecteer onder Kenmerkbron de roldefinitie-id onder Kenmerk en selecteer vervolgens ForAnyOfAnyValues:GuidEquals onder Operator.

6. Selecteer Rollen toevoegen. Voeg de rollen Lezer en Gegevenstoegang, Inzender voor opslagbestandsgegevens en Inzender voor opslagaccounts toe en selecteer Opslaan.

Azure File Sync werkt met uw standaard op Active Directory gebaseerde 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 Ondersteuning biedt voor Active Directory en Windows-ACL's, hebt u verder 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 ACL's naar alle servereindpunten.

Hoewel wijzigingen die rechtstreeks zijn aangebracht in de Azure-bestandsshare langer duren om te synchroniseren met de servereindpunten in de synchronisatiegroep, wilt u er ook voor zorgen dat u uw Active Directory-machtigingen voor uw bestandsshare rechtstreeks in de cloud kunt afdwingen. Als u deze configuratie wilt uitvoeren, moet u uw opslagaccount toevoegen aan uw on-premises Active Directory-exemplaar, net zoals uw Windows-bestandsservers lid zijn van een domein. Zie Overzicht van verificatie op basis van identiteiten van Azure Files voor SMB-toegang voor meer informatie over het toevoegen van een domein aan een Active Directory-exemplaar dat eigendom is van de klant.

Belangrijk

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

Networks

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. Beide protocollen gebruiken altijd HTTPS via poort 443. SMB wordt nooit gebruikt voor het uploaden of downloaden van gegevens tussen uw Windows Server-exemplaar en de Azure-bestandsshare. Omdat de meeste organisaties HTTPS-verkeer via poort 443 toestaan als vereiste voor het bezoeken van de meeste websites, is een speciale netwerkconfiguratie meestal niet vereist om Azure File Sync te implementeren.

Belangrijk

Azure File Sync biedt geen ondersteuning voor internetroutering. Azure File Sync ondersteunt de standaardoptie voor netwerkroutering, Microsoft-routering.

Op basis van het beleid van uw organisatie of de unieke wettelijke vereisten hebt u mogelijk meer beperkende communicatie met Azure nodig. Azure File Sync biedt 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 Azure ExpressRoute of een virtueel particulier azure-netwerk (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.

Als u wilt communiceren met uw Azure-bestandsshare via SMB, maar poort 445 is geblokkeerd, kunt u overwegen om SMB via QUIC te gebruiken. Deze methode biedt een VPN met nulconfiguratie voor SMB-toegang tot uw Azure-bestandsshares via 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-editie met behulp van Azure File Sync. Zie SMB via QUIC voor meer informatie over deze optie.

Zie Netwerkoverwegingen voor Azure File Sync voor Azure File Sync voor meer informatie over Azure File Sync en netwerken.

Versleuteling

Azure File Sync biedt drie versleutelingslagen: versleuteling op de inactieve opslag van Windows Server, versleuteling in transit tussen de Azure File Sync-agent en Azure, en versleuteling-at-rest voor uw gegevens in de Azure-bestandsshare.

Versleuteling van Windows Server-at-rest

Twee strategieën voor het versleutelen van gegevens op Windows Server werken in het algemeen met Azure File Sync:

• Versleuteling onder het bestandssysteem, zodat het bestandssysteem en alle gegevens die ernaar worden geschreven, worden versleuteld
• Versleuteling binnen de bestandsindeling zelf

Deze methoden sluiten elkaar niet wederzijds uit. U kunt ervoor kiezen om ze samen te gebruiken omdat het doel van versleuteling anders is.

Windows Server biedt een BitLocker-Postvak IN om versleuteling onder het bestandssysteem te bieden. BitLocker is volledig transparant voor Azure File Sync. De belangrijkste redenen voor het gebruik van een versleutelingsmechanisme zoals BitLocker zijn:

• Fysieke exfiltratie van gegevens uit uw on-premises datacenter voorkomen door iemand die de schijven steelt
• Voorkomen dat een niet-geautoriseerd besturingssysteem wordt ge sideloaden om niet-geautoriseerde lees- en schrijfbewerkingen uit te voeren naar uw gegevens

Zie het BitLocker-overzicht voor meer informatie.

Partnerproducten die op dezelfde manier werken als BitLocker, omdat ze zich onder het NTFS-volume bevinden, moeten volledig en 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 deze taak standaard uitvoeren, maar meestal niet.

Voorbeeldmethoden voor het versleutelen van de gegevensstroom van het bestand zijn Azure Information Protection, Azure Rights Management (Azure RMS) en Active Directory Rights Management Services. De belangrijkste reden om een versleutelingsmechanisme zoals Azure Information Protection of Azure RMS te gebruiken, is om exfiltratie van gegevens van uw bestandsshare te voorkomen door personen die het kopiëren naar alternatieve locaties (zoals een flashstation) of deze per e-mail verzenden naar een onbevoegde persoon. Wanneer de gegevensstroom van een bestand wordt 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- of partnerversleutelingsoplossingen die zich boven het bestandssysteem bevinden, maar onder de gegevensstroom van het bestand.

Versleuteling 'in transit'

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. Beide protocollen gebruiken altijd HTTPS via poort 443. Azure File Sync verzendt geen niet-versleutelde aanvragen via HTTP.

Azure-opslagaccounts bevatten een switch voor het vereisen van versleuteling tijdens overdracht. Deze schakeloptie is standaard ingeschakeld. Zelfs als de switch op het niveau van het opslagaccount is uitgeschakeld en 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 rechtstreeks communiceert met de Azure-bestandsshare. Een dergelijke toepassing moet worden uitgevoerd op een ouder besturingssysteem, zoals Windows Server 2008 R2 of een oudere Linux-distributie. Als de verouderde toepassing verbinding maakt met de Windows Server-cache van de bestandsshare, heeft het wijzigen van deze instelling geen effect.

We raden u ten zeerste aan om de versleuteling van gegevens in transit in te schakelen. Zie Veilige overdracht vereisen om beveiligde verbindingen te garanderen voor meer informatie over versleuteling tijdens overdracht.

Notitie

De Azure File Sync-service heeft de ondersteuning voor TLS 1.0 en 1.1 verwijderd op 1 augustus 2020. Alle ondersteunde versies van de Azure File Sync-agent maken standaard al gebruik van TLS 1.2. Mogelijk gebruikt u een eerdere versie van TLS als u TLS 1.2 hebt uitgeschakeld op uw server of als u een proxy gebruikt.

Als u een proxy gebruikt, raden we u aan de proxyconfiguratie te controleren. Azure File Sync-serviceregio's die na 1 mei 2020 zijn toegevoegd, ondersteunen alleen TLS 1.2. Zie de gids voor probleemoplossing voor meer informatie.

Versleuteling van Azure-bestandsshare-at-rest

Alle gegevens die zijn opgeslagen in Azure Files, worden in rust versleuteld via SSE (Azure Storage Service-Side Encryption). SSE werkt op dezelfde manier als BitLocker in Windows: gegevens worden versleuteld onder het bestandssysteemniveau.

Omdat gegevens worden versleuteld onder het bestandssysteem van de Azure-bestandsshare, omdat deze zijn gecodeerd op schijf, hebt u geen toegang nodig tot de onderliggende sleutel op de client om naar de Azure-bestandsshare te 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. Met door Microsoft beheerde sleutels bevat Microsoft de sleutels voor het versleutelen en ontsleutelen van de gegevens. Microsoft is verantwoordelijk voor het regelmatig roteren van deze 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. Met door de klant beheerde sleutels kunt u deze autorisatie op elk gewenst moment intrekken. Maar zonder deze autorisatie is uw Azure-bestandsshare niet meer toegankelijk via SMB of de FileREST-API.

Azure Files maakt gebruik van hetzelfde versleutelingsschema als de andere Azure Storage-services, zoals Azure Blob Storage. Zie Azure Storage-versleuteling voor data-at-rest voor meer informatie over Azure Storage SSE.

Opslaglagen

Azure Files biedt twee medialagen van opslag: SSD (solid-state disk) en harde schijf (HDD). Met deze lagen kunt u uw shares aanpassen aan de prestatie- en prijsvereisten van uw scenario:

• SSD (premium): SSD-bestandsshares bieden consistente hoge prestaties en lage latentie, binnen milliseconden met één cijfer voor de meeste I/O-bewerkingen, voor I/O-intensieve workloads. SSD-bestandsshares zijn geschikt voor een groot aantal workloads, zoals databases, websitehosting en ontwikkelomgevingen.

  U kunt SSD-bestandsshares gebruiken met zowel de SMB- als NFS-protocollen. SSD-bestandsshares zijn beschikbaar in de ingerichte v2 - en ingerichte v1-factureringsmodellen . SSD-bestandsshares bieden een SLA met een hogere beschikbaarheid dan HDD-bestandsshares.

• HDD (standaard): HDD-bestandsshares bieden een rendabele opslagoptie voor bestandsshares voor algemeen gebruik. HDD-bestandsshares zijn beschikbaar met de ingerichte v2 - en betalen per gebruik-factureringsmodellen , hoewel we het ingerichte v2-model aanbevelen voor nieuwe implementaties van bestandsshares. Zie de Azure SLA-pagina voor onlineservices voor informatie over de SLA.

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 on-premises SSD-opslagmedia gebruikt, zijn SSD-bestandsshares waarschijnlijk het meest geschikt. Als lage latentie niet zo belangrijk is, zijn HDD-bestandsshares mogelijk beter geschikt vanuit kostenperspectief. Lage latentie kan bijvoorbeeld minder zorgen hebben over teamshares die on-premises zijn gekoppeld vanuit Azure of on-premises in de cache zijn opgeslagen via Azure File Sync.

Nadat u een bestandsshare in een opslagaccount hebt gemaakt, kunt u deze niet rechtstreeks verplaatsen naar een andere medialaag. Als u bijvoorbeeld een HDD-bestandsshare naar de SSD-medialaag wilt verplaatsen, moet u een nieuwe SSD-bestandsshare maken en de gegevens van de oorspronkelijke share naar de nieuwe bestandsshare kopiëren.

Meer informatie over de SSD- en HDD-medialagen vindt u in De factureringsmodellen van Azure Files en inzicht in en optimalisatie van de prestaties van Azure-bestandsshares.

Beschikbaarheid van Azure File Sync-regio's

Zie Beschikbaarheid van producten per regio en zoek naar opslagaccounts voor regionale beschikbaarheid.

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

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

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

Redundantie

Om 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 de mate van redundantie selecteren. Azure Files ondersteunt momenteel de volgende opties voor gegevensredundantie:

• Lokaal redundante opslag (LRS): met lokale redundantie wordt elk bestand drie keer opgeslagen in een Azure-opslagcluster. Deze aanpak helpt u te beschermen tegen gegevensverlies als gevolg van hardwarefouten, zoals een ongeldig schijfstation. Als er echter een noodgeval optreedt, zoals brand of overstromingen in het datacenter, kunnen alle replica's van een opslagaccount dat gebruikmaakt van LRS verloren gaan of onherstelbaar zijn.

• Zone-redundante opslag (ZRS): Met zoneredundantie worden drie kopieën van elk bestand opgeslagen. Deze kopieën worden echter fysiek geïsoleerd in drie afzonderlijke opslagclusters in Azure-beschikbaarheidszones. Beschikbaarheidszones zijn unieke fysieke locaties in een Azure-regio. Elke zone bestaat uit een of meer datacenters die zijn uitgerust met onafhankelijke stroomvoorziening, 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 georedundantie hebt u 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.

  Georedundantie biedt zes kopieën van uw gegevens verspreid over de twee Azure-regio's. Als er een grote ramp optreedt, 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 en dient alle bewerkingen.

  Omdat de replicatie tussen de primaire en secundaire regio's asynchroon is, gaan gegevens die nog niet zijn gerepliceerd naar de secundaire regio verloren als er een grote noodgeval optreedt. U kunt ook een handmatige failover uitvoeren van een geografisch redundante opslagaccount.

• Geografisch zone-redundante opslag (GZRS):met redundantie op geo-zone 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 geozoneredundantie werkt hetzelfde als voor geo-redundantie.

HDD-bestandsshares ondersteunen alle vier de redundantietypen. SSD-bestandsshares ondersteunen alleen LRS en ZRS.

Opslagaccounts voor betalen per gebruik bieden twee andere redundantieopties die azure Files niet ondersteunt: geografisch redundante opslag met leestoegang (RA-GRS) en geografisch zone-redundante opslag met leestoegang (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 geografisch redundant of geografisch zone-redundant.

Belangrijk

Geografisch redundante en geografisch zone-redundante opslag kan handmatig een failover uitvoeren voor opslag naar de secundaire regio. We raden deze aanpak (buiten een noodgeval) niet aan wanneer u Azure File Sync gebruikt vanwege de verhoogde kans op gegevensverlies. Als er zich een noodgeval voordoet en u een handmatige failover van opslag wilt initiëren, moet u een ondersteuningsaanvraag openen bij Microsoft om Azure File Sync te laten synchroniseren met het secundaire eindpunt.

Migratie

Als u een bestaande bestandsserver in Windows Server 2012 R2 of hoger hebt, kunt u Azure File Sync rechtstreeks installeren. U hoeft geen gegevens naar een nieuwe server 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 op de 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 Migreren naar SMB Azure-bestandsshares voor gedetailleerde richtlijnen.

Antivirussoftware

Omdat antivirus werkt door bestanden te scannen op bekende schadelijke code, kan een antivirusproduct leiden tot het intrekken van gelaagde bestanden en hoge kosten voor uitgaand verkeer. Gelaagde bestanden hebben de beveiligde Windows-kenmerkset FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS . We raden u aan contact op te stellen met uw softwareleverancier om te leren hoe u de oplossing configureert om leesbestanden met deze kenmerkenset over te slaan. Velen doen het automatisch.

Tijdens scans op aanvraag slaan antivirusoplossingen Microsoft Defender en System Center Endpoint Protection automatisch het lezen van bestanden over waarvoor dit kenmerk is ingesteld. 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 teruggeroepen (gedownload) op de nieuwe server. Deze bestanden blijven op de nieuwe server staan en zijn niet gelaagd omdat ze niet voldoen aan de vereiste voor de grootte van lagen (meer dan 64 KiB).

Notitie

Microsoft Defender en System Center Endpoint Protection slaan alleen lezen over tijdens scans op aanvraag. Dit is niet van toepassing op realtime-beveiliging (RTP).

Antivirusleveranciers kunnen de compatibiliteit tussen hun producten en Azure File Sync controleren met behulp van de Azure File Sync Antivirus-compatibiliteitstestsuite in het Microsoft Downloadcentrum.

Reservekopie

Als u cloudlagen inschakelt, gebruikt u geen oplossingen die rechtstreeks een back-up maken van het servereindpunt of een VM die het servereindpunt bevat.

In cloudlagen wordt alleen een subset van uw gegevens opgeslagen op het servereindpunt. De volledige gegevensset bevindt zich in uw Azure-bestandsshare. Afhankelijk van de back-upoplossing die u gebruikt, zijn gelaagde bestanden:

• Overgeslagen en geen back-up gemaakt, omdat er een FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS kenmerk is ingesteld
• Teruggehaald naar schijf, wat resulteert in hoge uitgaande kosten

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 Files voor meer informatie. Of vraag uw back-upprovider of het ondersteuning biedt voor het maken van back-ups van Azure-bestandsshares.

Als u liever een on-premises back-upoplossing gebruikt, moet u de back-ups uitvoeren op een server in de synchronisatiegroep waarvoor cloudlagen zijn uitgeschakeld. Zorg ervoor dat er geen gelaagde bestanden zijn.

Wanneer u een herstelbewerking uitvoert, gebruikt u de optie voor herstellen op volume- of bestandsniveau. Bestanden die zijn hersteld via de optie voor herstellen op bestandsniveau, worden gesynchroniseerd met alle eindpunten in de synchronisatiegroep. 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-metalherstel, VM-herstel, systeemherstel (windows ingebouwd besturingssysteem herstellen) en herstel op bestandsniveau met de gelaagde versie kunnen onverwachte resultaten veroorzaken. (Herstellen op bestandsniveau vindt plaats wanneer back-upsoftware een back-up maakt van een gelaagd bestand in plaats van een volledig bestand.) Ze worden momenteel niet ondersteund wanneer cloudlagen zijn ingeschakeld.

Momentopnamen van Volume Shadow Copy Service (VSS), waaronder 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, kunt u om twee redenen hogere kosten voor cloudlagen inschakelen:

• Als cloudlagen zijn ingeschakeld, worden uw heetste bestanden lokaal in de cache opgeslagen. Uw coolste bestanden worden 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.
• Als de software voor gegevensclassificatie gebruikmaakt van de metagegevens in de gegevensstroom van een bestand, moet het bestand volledig worden ingetrokken voor de software om de classificatie te detecteren.

Deze toenames kunnen de kosten verhogen in zowel het aantal terugroepen als de hoeveelheid gegevens die worden ingetrokken.

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: 18.0.0.0.
• Secundaire agentversies worden ook patches genoemd en worden vaker uitgebracht dan primaire versies. Ze bevatten vaak oplossingen voor fouten en kleinere verbeteringen, maar geen nieuwe functies. Bijvoorbeeld: 18.2.0.0.

Paden bijwerken

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

• Gebruik de functie voor automatische updates van Azure File Sync om agentupdates te installeren: de Azure File Sync-agent wordt automatisch bijgewerkt. U kunt ervoor kiezen om de nieuwste agentversie te installeren wanneer deze beschikbaar is of wordt bijgewerkt wanneer de momenteel geïnstalleerde agent bijna is verlopen. Zie de volgende sectie, Automatisch beheer van de levenscyclus van de agent voor meer informatie.
• Configureer Microsoft Update voor het automatisch downloaden en installeren van agentupdates: 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.
• Gebruik AfsUpdater.exe om agentupdates te downloaden en installeren: het AfsUpdater.exe bestand 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.
• Patch een bestaande Azure File Sync-agent met behulp van een Microsoft Update-patchbestand of een uitvoerbaar MSP-bestand: u kunt het meest recente Azure File Sync-updatepakket downloaden uit de Microsoft Update-catalogus. Als u een .msp uitvoerbaar bestand uitvoert, wordt uw Azure File Sync-installatie bijgewerkt met dezelfde methode die door Microsoft Update automatisch wordt gebruikt. Als u een Microsoft Update-patch toepast, wordt een in-place update van een Azure File Sync-installatie uitgevoerd.
• Download het nieuwste installatieprogramma voor de Azure File Sync-agent: u kunt het installatieprogramma downloaden in 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. Agentinstellingen (bijvoorbeeld serverregistratie en servereindpunten) worden onderhouden wanneer de Azure File Sync-agent wordt verwijderd.

Notitie

De downgrade van de Azure File Sync-agent wordt niet ondersteund. Nieuwe versies bevatten vaak belangrijke wijzigingen wanneer ze worden vergeleken 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 werkt u bij naar de nieuwste beschikbare versie.

Automatisch beheer van de levenscyclus van de agent

De Azure File Sync-agent wordt automatisch bijgewerkt. U kunt een van de volgende modi selecteren en een onderhoudsvenster opgeven waarin de update op de server wordt uitgevoerd. Deze functie is ontworpen om u te helpen bij het beheer van de levenscyclus van agents door een kader te bieden dat voorkomt dat uw agent verloopt of waardoor uw agent niet kan worden verlopen of een probleemloze, blijf-huidige instelling mogelijk maakt.

• De standaardinstelling probeert te voorkomen dat de agent verloopt. Binnen 21 dagen na de geposte vervaldatum van een agent probeert de agent zichzelf bij te werken. Er wordt een updatepoging eenmaal per week gestart binnen 21 dagen vóór de vervaldatum en in het geselecteerde onderhoudsvenster. Houd er rekening mee dat deze optie de noodzaak voor het nemen van reguliere Microsoft Update-patches niet elimineert.

• U kunt selecteren dat de agent automatisch wordt bijgewerkt zodra er een nieuwe agentversie beschikbaar is. Deze mogelijkheid 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 deze algemeen beschikbaar zijn. Deze aanbevolen, probleemloze instelling biedt primaire agentversies en regelmatige updatepatches voor uw server. Elke vrijgegeven agent is in ga-kwaliteit.

  Als u deze optie selecteert, voert Microsoft de nieuwste agentversie naar u uit. Geclusterde servers worden uitgesloten. Nadat de flighting is voltooid, wordt de agent ook beschikbaar in Microsoft Update en het Microsoft Downloadcentrum.

De instelling voor automatische updates wijzigen

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

Open een PowerShell-console en ga naar de map waarin u de synchronisatieagent hebt geïnstalleerd en importeer vervolgens de server-cmdlets. Deze actie 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 updates van de agent wordt gewijzigd InstallLatestin, wordt de agent pas automatisch bijgewerkt wanneer de volgende agentversie wordt uitgevoerd. Als u wilt bijwerken naar een agentversie die klaar is met flighting, gebruikt u Microsoft Update of AfsUpdater.exe. Als u wilt controleren of er momenteel een agentversie wordt uitgevoerd, raadpleegt 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. Een specifieke versie van de Azure File Sync-agent kan slechts gedurende een beperkte tijd worden ondersteund. Om uw implementatie te vergemakkelijken, garanderen de volgende regels dat u voldoende tijd en meldingen hebt voor agentupdates in uw wijzigingsbeheerproces:

• Primaire agentversies worden ten minste 12 maanden vanaf de datum van de eerste release ondersteund.
• Er is een overlapping van ten minste 3 maanden tussen de ondersteuning van primaire agentversies.
• Waarschuwingen worden uitgegeven voor geregistreerde servers via een binnenkortto-be verlopen agent ten minste 3 maanden voordat deze verloopt. U kunt controleren of een geregistreerde server een oudere versie van de agent gebruikt in de sectie over geregistreerde servers in een opslagsynchronisatieservice.
• De levensduur van een secundaire agentversie is gebonden aan de bijbehorende primaire versie. Als bijvoorbeeld agentversie 18.0.0.0 is ingesteld op verlopen, verlopen agentversies 18.*.*.* allemaal samen.

Notitie

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

Verwante inhoud

• Azure File Sync-proxy- en firewallinstellingen
• Een SMB Azure-bestandsshare maken
• Azure Files SYNC implementeren
• Azure File Sync bewaken