Planning voor de implementatie van Azure Files Sync

Interview and demo introducing Azure File Sync - click to play!

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

In dit artikel maakt u kennis met Azure File Sync concepten en functies. Zodra u bekend bent met Azure File Sync, kunt u overwegen de Azure File Sync implementatiehandleiding 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 tijdens het plannen van uw implementatie.

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

  • On-premises Azure-bestandsshare in cache opslaan met Azure File Sync: Azure File Sync kunt u de bestandsshares van uw organisatie centraliseren in Azure Files, terwijl de flexibiliteit, prestaties en compatibiliteit van een on-premises bestandsserver behouden blijven. Azure File Sync een on-premises (of cloud) Windows Server transformeert 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 tegenwoordig geen efficiënt mechanisme voor wijzigingsdetectie heeft, zoals Windows Server, waardoor het rechtstreeks doorvoeren van wijzigingen in de Azure-bestandsshare tijd kost om terug te geven aan de servereindpunten.
  • Servereindpunt: het pad op de Windows Server die wordt gesynchroniseerd met een Azure-bestandsshare. Dit kan een specifieke map op een volume of de hoofdmap van het volume zijn. Meerdere servereindpunten kunnen zich op hetzelfde volume bevinden 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 afzonderlijke 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:

  • GPv2-opslagaccounts (versie twee voor algemeen gebruik) : Met GPv2-opslagaccounts kunt u Azure-bestandsshares implementeren op (HDD-)hardware met een standaard/harde schijf. 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 (SSD-)hardware met een premium/solid-state schijf. 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 Storage Sync Services. Dit zijn objecten op het hoogste niveau die servers registreren voor gebruik met Azure File Sync en de synchronisatiegroeprelaties bevatten. De Storage Sync Service-resource is een peer van de opslagaccountresource en kan op dezelfde manier worden geïmplementeerd in Azure-resourcegroepen. Een Storage Sync Service kan synchronisatiegroepen maken die Azure-bestandsshares bevatten over meerdere opslagaccounts en meerdere geregistreerde Windows Servers.

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

Een synchronisatiegroep bevat één cloudeindpunt of Azure-bestandsshare en ten minste één servereindpunt. Het servereindpuntobject bevat de instellingen waarmee de mogelijkheid voor cloudopslaglagen wordt geconfigureerd. Dit biedt de cachemogelijkheid van Azure File Sync. Als u wilt synchroniseren met een Azure-bestandsshare, moet het opslagaccount met de Azure-bestandsshare zich in dezelfde Azure-regio bevinden als de Storage Sync-service.

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 Azure Files veelgestelde vragen voor meer informatie.

Houd rekening met het aantal Storage Sync Services dat nodig is

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

Maak alleen meerdere Storage Sync Services als u het volgende hebt:

  • afzonderlijke sets servers die nooit gegevens met elkaar moeten uitwisselen. In dit geval wilt u het systeem zodanig ontwerpen dat bepaalde sets servers worden uitgesloten die moeten worden gesynchroniseerd met een Azure-bestandsshare die al wordt gebruikt als een cloudeindpunt in een synchronisatiegroep in een andere Storage Synchronisatieservice. 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 Storage Sync Service 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 wilt 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 of de server bevinden die u op de 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-shares voor uw gebruikers en apps. De eenvoudigste manier om dit scenario te zien 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 Windows Server-exemplaar, raden we een toewijzing van 1:1 aan.

Als u meer dan 30 shares hebt, is het vaak onnodig om een on-premises share 1:1 toe te kennen aan een Azure-bestandsshare. 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, kunt u niet voorkomen 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 met 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. Er zijn voordelen voor het synchroniseren van meerdere locaties. Als u dit bijvoorbeeld doet, blijft het aantal items per synchronisatiebereik lager. We testen Azure-bestandsshares en Azure File Sync met 100 miljoen items (bestanden en mappen) per share. 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 het wachten tot de naamruimte op een server wordt weergegeven die is ingeschakeld voor Azure File Sync.
  • Herstel in de cloud vanuit een momentopname van een Azure-bestandsshare gaat 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 resources voor synchronisatiegroepen die 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.

    Eén standaard Azure-bestandsshare kan theoretisch de maximale prestaties verzadigen die een opslagaccount kan leveren. Als u meerdere shares in één opslagaccount plaatst, maakt u een gedeelde pool met IOPS en doorvoer voor deze shares. Als u van plan bent om alleen Azure File Sync aan deze bestandsshares toe te voegen, kan het groeperen van verschillende Azure-bestandsshares in hetzelfde opslagaccount geen probleem opleveren. Bekijk de prestatiedoelen voor Azure-bestandsshares voor meer inzicht in de relevante metrische gegevens. Deze beperkingen zijn niet van toepassing op Premium Storage, waarbij de prestaties expliciet worden ingericht en gegarandeerd voor elke share.

    Als u van plan bent om een app naar Azure te tillen die de Azure-bestandsshare systeemeigen gebruikt, hebt u mogelijk meer prestaties nodig van uw Azure-bestandsshare. Als dit type gebruik een mogelijkheid is, zelfs in de toekomst, kunt u het beste één standaard Azure-bestandsshare maken in een eigen opslagaccount.

  • Er is een limiet van 250 opslagaccounts per abonnement per Azure-regio.

Tip

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 alle 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 raadzaam 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 je ruimte om te groeien.

Het is mogelijk dat in uw situatie een set mappen logisch kan worden gesynchroniseerd met dezelfde Azure-bestandsshare (door gebruik te maken van de nieuwe algemene 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 op meer on-premises servers, waardoor u kunt synchroniseren met 30 meer Azure-bestandsshares per extra server.

Een toewijzingstabel maken

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

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

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


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

overwegingen voor Windows bestandsserver

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

Vereisten voor het besturingssysteem

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

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

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 waarop dynamisch geheugen is ingeschakeld, moet de VIRTUELE machine 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.

Net als bij elke serverfunctie of toepassing worden de systeemresourcevereisten voor Azure File Sync bepaald door de schaal van de implementatie; grotere implementaties op een server vereisen meer systeemresources. Voor Azure File Sync wordt de schaal bepaald door het aantal objecten op de servereindpunten en het verloop op de gegevensset. Eén server kan servereindpunten hebben in meerdere synchronisatiegroepen en 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, 16 GiB aan geheugen voor een stabiele status en (indien mogelijk) 48 GiB van het 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 meer 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 bestandsshares voor algemeen gebruik opgegeven, waarbij de gemiddelde bestandsgrootte 512 KiB is. Als uw bestandsgrootten 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 - mappen van bestanden & (miljoenen) Typische capaciteit (TiB) CPU-kernen Aanbevolen geheugen (GiB)
3 1.4 2 8 (eerste synchronisatie)/ 2 (typisch verloop)
5 2.3 2 16 (initiële synchronisatie)/ 4 (typisch verloop)
10 4.7 4 32 (eerste synchronisatie)/ 8 (typisch verloop)
30 14.0 8 48 (initiële synchronisatie)/ 16 (typisch verloop)
50 23.3 16 64 (initiële synchronisatie)/ 32 (typisch verloop)
100* 46.6 32 128 (eerste synchronisatie)/ 32 (typisch verloop)

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

Tip

De eerste 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 initiële synchronisatie versnellen.

Normaal verloop is 0,5% van de naamruimte die per dag wordt gewijzigd. 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. Deze cmdlet controleert op mogelijke problemen met uw bestandssysteem en gegevensset, zoals niet-ondersteunde tekens of een niet-ondersteunde versie van het besturingssysteem. De controles omvatten 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: Installeren en configureren Azure PowerShell.

Gebruik

U kunt het evaluatieprogramma op verschillende manieren aanroepen: u kunt de systeemcontroles, de gegevenssetcontroles of beide uitvoeren. De 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 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 Notities
ACL’s (toegangsbeheerlijsten) Volledig ondersteund Windows discretionaire toegangsbeheerlijsten 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.
Vaste koppelingen Overgeslagen
Symbolische koppelingen Overgeslagen
Koppelpunten Gedeeltelijk ondersteund Koppelpunten kunnen de hoofdmap van een servereindpunt zijn, maar ze worden overgeslagen als ze zijn opgenomen in de naamruimte van een servereindpunt.
Kruispunten Overgeslagen Bijvoorbeeld de mappen Distributed File System DfrsrPrivate en DFSRoots.
Reparsepunten Overgeslagen
NTFS-compressie Volledig ondersteund
Sparse-bestanden Volledig ondersteund Sparse bestanden synchroniseren (worden niet geblokkeerd), maar ze synchroniseren met de cloud als een volledig bestand. Als de bestandsinhoud in de cloud (of op een andere server) verandert, wordt het bestand niet meer geparseerd wanneer de wijziging wordt gedownload.
Alternatieve gegevens Streams (ADS) Behouden, maar niet gesynchroniseerd Classificatietags die zijn gemaakt door de infrastructuur voor bestandsclassificatie, worden bijvoorbeeld niet gesynchroniseerd. Bestaande classificatietags op 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
Duimschroef Tijdelijk bestand voor miniaturen
ehthumbs.db Tijdelijk bestand voor mediaminiaturen
~$*.* Office tijdelijk bestand
*.tmp Tijdelijk bestand
*.laccdb Toegang tot db-vergrendelingsbestand
635D02A9D91C401B97884B82B3BCDAEA.* Intern synchronisatiebestand
\System Volume Information Map specifiek voor volume
$RECYCLE. BIN Map
\SyncShareState Map voor synchronisatie

Bedenk hoeveel vrije ruimte u nodig hebt op uw lokale schijf

Wanneer u van plan bent Azure File Sync te gebruiken, moet u overwegen 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:

  • Wanneer opslag in cloudlagen is ingeschakeld:

    • Reparsepunten voor gelaagde bestanden
    • Azure File Sync metagegevensdatabase
    • Azure File Sync warmteopslag
    • 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 warmteopslag
    • Azure File Sync metagegevensdatabase

We gebruiken een voorbeeld om te laten zien hoe u de hoeveelheid vrije ruimte op uw lokale schijf kunt schatten. Stel dat u uw Azure File Sync-agent hebt geïnstalleerd op uw Azure Windows-VM en een servereindpunt wilt maken op schijf F. U hebt 1 miljoen bestanden en wilt alle bestanden, 100.000 mappen en een schijfclustergrootte van 4 KiB laagen. De schijfgrootte is 1000 GiB. U wilt cloudlagen inschakelen en uw volumeruimtebeleid 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

De ruimte die wordt bezet door gelaagde bestanden wordt toegewezen door NTFS. Daarom wordt deze niet weergegeven in een gebruikersinterface. 3. Synchronisatiemetagegevens nemen een clustergrootte per item in beslag. (1 miljoen bestanden + 100.000 mappen) * 4 KB clustergrootte = 4.400.000 KiB (4,4 GiB) 4. 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) 5. Volumeruimtebeleid is 20%. 1000 GiB * 0,2 = 200 GiB

In dit geval zou Azure File Sync ongeveer 209.500.000 KiB (209,5 GiB) ruimte nodig hebben voor deze naamruimte. Voeg deze hoeveelheid toe aan eventuele extra vrije ruimte die gewenst is om erachter te komen hoeveel vrije ruimte er nodig is voor deze schijf.

Failoverclustering

  1. Windows serverfailoverclustering 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 Windows serverfailovercluster met geclusterde schijven
  3. Failoverclustering wordt niet ondersteund op scale-out bestandsserver voor toepassingsgegevens (SOFS) of op geclusterde gedeelde volumes (CSV's) of lokale schijven.

Notitie

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

Gegevensontdubbeling

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 en Windows Server 2022. Als u gegevensontdubbeling inschakelt 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 cloudlagen zijn ingeschakeld, worden geoptimaliseerde bestanden binnen 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 gegevensontdubbeling garbagecollectiontaak 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 ontdubbeld.

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 cloudlagen worden uitgeschakeld.

Opmerkingen

  • Als gegevensontdubbeling is 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 gegevensontdubbeling MinimumFileAgeDays, 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 op 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, moet Windows Server 2019 of Windows Server 2022 de volgende stappen worden uitgevoerd ter ondersteuning gegevensontdubbeling en cloudlagen op hetzelfde volume:

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

    Opmerking: de Azure File Sync configuratie-instellingen op de server worden bewaard 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 op DFS-N-servers. U kunt de Azure File Sync-agent installeren op een of meer DFS-N-leden om gegevens tussen de servereindpunten en het cloudeindpunt te synchroniseren. Zie het overzicht van DFS-naamruimten voor meer informatie.

DFS-replicatie (DFS-R):omdat DFS-R en Azure File Sync beide replicatieoplossingen zijn, raden we u 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 voegen gegevens samen op één hubserver waarvoor u Azure File Sync wilt gebruiken.

Om Azure File Sync en DFS-R naast elkaar te laten werken:

  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

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 na het implementeren van de serverinstallatiekopieën en het voltooien van sysprep mini-setup.

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

Notitie

Windows clients worden teruggeroepen bij het doorzoeken van de bestandsshare als de instelling Bestandsnamen en inhoud altijd 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.

Prestatie en schaalbaarheid

Aangezien 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. Aangezien 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 de Azure Portal of SMB, worden niet onmiddellijk gedetecteerd en gerepliceerd, zoals wijzigingen in het servereindpunt. Azure Files nog geen wijzigingsmeldingen of logboeken heeft, 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, heeft Azure File Sync een geplande taak, een wijzigingsdetectietaak genoemd. Een wijzigingsdetectietaak inventariseert elk bestand in de bestandsshare en vergelijkt het 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 Azure File Sync metrische prestatiegegevens 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 synchronisatie. Wanneer u Azure File Sync gebruikt, is de algemene verwachting dat de meeste toegangen de Azure File Sync cacheservers doorlopen, in plaats van via de Azure-bestandsshare. Omdat de servereindpunten zich op Windows Server bevinden en Windows Server al lang AD- en Windows-achtige ACL's heeft ondersteund, hoeft er niets meer te worden gedaan dan ervoor te zorgen dat de Windows bestandsservers die zijn geregistreerd bij de Storage Sync Service 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 wijzigingen die rechtstreeks zijn aangebracht in de Azure-bestandsshare langer duren voordat ze met de servereindpunten in de synchronisatiegroep worden gesynchroniseerd, wilt u er mogelijk ook voor zorgen dat u uw AD-machtigingen voor uw bestandsshare rechtstreeks in de cloud kunt afdwingen. Hiervoor moet u uw opslagaccount koppelen aan uw on-premises AD, net zoals hoe uw Windows bestandsservers lid zijn van een domein. Zie Azure Files Overzicht van Active Directory voor meer informatie over het toevoegen van uw opslagaccount aan een Active Directory-account dat eigendom is van de klant.

Belangrijk

Domein dat lid is van uw opslagaccount aan Active Directory, 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 Storage Sync Service en Azure-bestandsshare met behulp van het Azure File Sync REST-protocol en het FileREST-protocol, die beide altijd HTTPS gebruiken via poort 443. SMB wordt nooit gebruikt om gegevens te uploaden of te downloaden tussen uw Windows Server en de Azure-bestandsshare. Omdat de meeste organisaties HTTPS-verkeer via poort 443 toestaan, 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 of de unieke wettelijke vereisten van uw organisatie 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:

  • Tunnel verkeer synchroniseren en uploaden/downloaden via uw ExpressRoute of Azure VPN.
  • Gebruik Azure Files en Azure-netwerkfuncties, zoals service-eindpunten en privé-eindpunten.
  • Configureer Azure File Sync ter ondersteuning van uw proxy in uw omgeving.
  • Netwerkactiviteit beperken vanaf Azure File Sync.

Tip

Als u wilt communiceren met uw Azure-bestandsshare via SMB, maar poort 445 wordt geblokkeerd, kunt u overwegen 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 Windows Server 2022 Azure Edition-VM met behulp van Azure File Sync. Zie SMB via QUIC voor meer informatie over deze optie met Azure File Sync.

Zie Azure File Sync overwegingen voor netwerken 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 at-rest-opslag van Windows Server, versleuteling tijdens overdracht tussen de Azure File Sync-agent en Azure en versleuteling in rest van uw gegevens in de Azure-bestandsshare.

Windows Server-at-rest versleuteling

Er zijn twee strategieën voor het versleutelen van gegevens op Windows Server die over 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 uit; ze kunnen indien gewenst samen worden gebruikt, omdat het doel van versleuteling anders is.

Als u versleuteling wilt bieden onder het bestandssysteem, biedt Windows Server BitLocker-Postvak IN. BitLocker is volledig transparant voor Azure File Sync. De belangrijkste reden om een versleutelingsmechanisme zoals BitLocker te gebruiken, is om fysieke exfiltratie van gegevens uit uw on-premises datacenter te voorkomen door iemand die de schijven steelt en om te voorkomen dat een niet-geautoriseerd besturingssysteem wordt gebruikt om niet-geautoriseerde lees-/schrijfbewerkingen naar uw gegevens uit te voeren. Zie het BitLocker-overzicht voor meer informatie over BitLocker.

Producten van derden die vergelijkbaar zijn met 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 naar alternatieve locaties kopiëren, 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

Azure File Sync service verwijdert de ondersteuning voor TLS1.0 en 1.1 op 1 augustus 2020. Alle ondersteunde Azure File Sync agentversies maken standaard 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 na 1-5-2020 worden alleen TLS1.2 en ondersteuning voor TLS1.0 en 1.1 verwijderd uit bestaande regio's op 1 augustus 2020. Zie de gids voor probleemoplossing voor meer informatie.

Azure File Sync agent communiceert met uw Storage Sync Service 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, Azure File Sync nog steeds alleen versleutelde kanalen gebruikt 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 vier verschillende opslaglagen: premium, geoptimaliseerd voor transacties, dynamisch en statisch. Hiermee kunt u uw shares aanpassen aan de prestaties en prijsvereisten van uw scenario:

  • Premium: Premium-bestandsshares worden ondersteund door SSD's (solid-state drives) en bieden consistente hoge prestaties en lage latentie in milliseconden 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).
  • Geoptimaliseerd voor transacties: Voor transacties geoptimaliseerde bestandsshares maken werkbelastingen mogelijk met veel transacties die niet de latentie hebben van Premium bestandsshares. Voor transactie geoptimaliseerde bestandsshares worden aangeboden voor standaard opslaghardware die wordt ondersteund door harde schijven. Transactiegeoptimaliseerd is vaak 'Standaard' genoemd, hoewel dit verwijst naar de opslagmedia in plaats van de laag zelf (de dynamische en statische lagen zijn ook 'standaard' lagen, omdat ze zich in standaard opslaghardware bevinden).
  • Dynamisch: Dynamische bestandsshares bieden opslag die is geoptimaliseerd voor scenario's met algemeen gebruik, bijvoorbeeld teamshares. Dynamische bestandsshares worden aangeboden via de standaardopslag die worden ondersteund door HDD's.
  • Statisch: Statische bestandsshares bieden kostenefficiënte opslag die is geoptimaliseerd voor online archieven. Statische bestandsshares worden aangeboden via de standaardopslag die worden ondersteund door HDD's.

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. Standaard bestandsshares, zoals geoptimaliseerde, dynamische en statische bestandsshares, worden geïmplementeerd in het opslagaccount voor algemeen gebruik versie 2 (GPv2) en zijn beschikbaar bij betalen als u gaat factureren.

Wanneer u een opslaglaag selecteer voor uw werkbelasting. kunt u uw prestatie- en gebruiksvereisten overwegen. Als voor uw werkbelasting een hogere latentie van één cijfer nodig is, 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.

Wanneer u een bestandsshare hebt gemaakt in een opslaglaag, kunt u die niet verplaatsen naar andere soorten opslagaccounts. 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.

Regionale beschikbaarheid

Standaardbestandsshares met een capaciteit van 100 TiB hebben bepaalde beperkingen.

  • Op dit moment worden alleen accounts met lokaal redundante opslag (LRS) en zone-redundante opslag (ZRS) ondersteund.
  • Wanneer u grote bestandsshares inschakelt, kunt u opslagaccounts niet converteren naar accounts met geografisch redundante opslag (GRS) of geografisch zone-redundante opslag (GZRS).
  • Wanneer u grote bestandsshares inschakelt, kunt u deze niet meer uitschakelen.

Beschikbaarheid van Azure File Sync-regio's

Zie Producten die beschikbaar zijn 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 uw gegevens in uw Azure-bestandsshares te beschermen tegen gegevensverlies of beschadiging, bewaren alle Azure-bestandsshares meerdere kopieën van elk bestand wanneer ze worden geschreven. Afhankelijk van de vereisten van uw werkbelasting, kan u aanvullende maten 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. Zo wordt u beschermd tegen gegevensverlies door hardwarefouten, zoals een beschadigd schijfstation. Als er zich echter een noodgeval voordoet, zoals brand of overstromingen in het datacenter, 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, maar deze kopieën zijn 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 de opslag wordt niet geaccepteerd totdat er naar de opslagclusters in alle drie de beschikbaarheidszones wordt geschreven.
  • Geografisch redundante opslag (GRS):met GRS hebt u twee regio's, een primaire en 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 die zijn verdeeld over twee Azure-regio's. In het geval van een grote ramp, zoals het permanente verlies van een Azure-regio als gevolg van een natuurramp of een andere soortgelijke gebeurtenis, voert Microsoft een failover uit en wordt de secundaire de primaire, die alle bewerkingen bedient. Omdat de replicatie tussen de primaire en secundaire regio's asynchroon is, gaan gegevens die nog niet zijn gerepliceerd naar de secundaire regio verloren in het geval van een ernstige ramp. U kunt ook een handmatige failover uitvoeren van een geografisch redundante opslagaccount.
  • Geografisch zone-redundante opslag (GZRS): u kunt GZRS zien alsof het lijkt op ZRS, maar met georedundantie. 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.

Standaard Azure-bestandsshares van maximaal 5 TiB ondersteunen alle vier redundantietypen. Standaardbestandsshares die groter zijn dan 5 TiB ondersteunen alleen LRS en ZRS. Premium Azure-bestandsshares ondersteunen alleen LRS en ZRS.

Opslagaccount voor algemeen gebruik versie 2 (GPv2) bieden twee aanvullende redundantie-opties die niet worden ondersteund door Azure Files: geografisch redundante opslag met leestoegang, vaak RA-GRS genoemd, en geografisch zone-redundante opslag met leestoegang, vaak RA-GZRS genoemd. U kunt Azure-bestandsshares inrichten in opslagaccounts waarin deze opties zijn ingesteld, maar Azure Files ondersteunt het lezen vanuit de secundaire regio niet. Azure-bestandsshares die in geografisch redundante of geografisch zone-redundante opslagaccounts met leestoegang worden geïmplementeerd, worden gefactureerd als respectievelijk geografisch redundante of geografisch zone-redundante opslag.

Belangrijk

Geografisch redundante en geografisch zone-redundante opslag hebben de mogelijkheid om handmatig failoveropslag naar de secundaire regio uit te voeren. We raden u aan dit niet buiten een noodgeval te doen 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 om de synchronisatie met het secundaire eindpunt te hervatten.

Migratie

Als u een bestaande Windows bestandsserver 2012R2 of hoger hebt, kan Azure File Sync direct 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 op network attached Storage (NAS) bevinden, zijn er verschillende mogelijke migratiemethoden om Azure File Sync met deze gegevens te gebruiken. Welke migratiebenadering u moet kiezen, is afhankelijk van waar uw gegevens zich momenteel bevinden.

Bekijk het overzichtsartikel Azure File Sync en Azure-bestandsshares, waar u gedetailleerde richtlijnen voor uw scenario kunt vinden.

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 kosten voor uitgaand verkeer. Gelaagde bestanden hebben het beveiligde Windows kenmerk FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS ingesteld en we raden u aan contact op te stellen met uw softwareleverancier om te leren hoe u hun oplossing configureert om het lezen van bestanden over te slaan met deze kenmerkenset (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 en worden niet gelaagd omdat ze niet voldoen aan de vereiste voor de grootte van lagen (>64 kb).

Notitie

Antivirusleveranciers kunnen de compatibiliteit tussen hun product en Azure File Sync controleren met behulp van de Azure File Sync antiviruscompatibiliteitstestsuite, die beschikbaar is om te downloaden in het Microsoft Downloadcentrum.

Backup

Als opslag in cloudlagen is ingeschakeld, moeten oplossingen die rechtstreeks een back-up maken van het servereindpunt of een VM waarop het servereindpunt zich bevindt, niet worden gebruikt. Door opslag in cloudlagen wordt alleen een subset van uw gegevens opgeslagen op het servereindpunt, waarbij de volledige gegevensset 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 er een FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS kenmerk is ingesteld) of worden ze teruggehaald naar schijf, wat resulteert in hoge kosten voor uitgaand verkeer. U wordt aangeraden een cloudback-upoplossing te gebruiken om rechtstreeks een back-up van de Azure-bestandsshare te maken. Zie Over back-ups van Azure-bestandsshares 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 opslag in cloudlagen is uitgeschakeld. Wanneer u een herstelbewerking uitvoert, gebruikt u de opties voor het herstellen 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. Herstel op volumeniveau vervangt geen nieuwere bestandsversies in de Azure-bestandsshare of andere servereindpunten.

Notitie

BmR-herstel (Bare-metal) kan onverwachte resultaten veroorzaken en wordt momenteel niet ondersteund.

Notitie

VSS-momentopnamen (inclusief 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 opslag in cloudlagen is ingeschakeld, worden uw heetste bestanden lokaal in de cache opgeslagen en worden de 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 teruggehaald 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 teruggehaald om de software de classificatie te laten zien.

Deze toenamen in zowel het aantal terugroepen als de hoeveelheid gegevens die wordt teruggehaald, 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: 14.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: 14.1.0.0

Upgradepaden

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

  1. Gebruik Azure File Sync functie voor automatische upgrade van agent 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 bijwerkt wanneer de momenteel geïnstalleerde agent bijna verloopt. Zie Automatisch levenscyclusbeheer voor agents voor meer informatie.
  2. Configureer Microsoft Update om agentupdates automatisch te downloaden en te installeren.
    Het is raadzaam om 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.
  4. Patch een bestaande Azure File Sync-agent met behulp van een Microsoft Update-patchbestand of een .msp-uitvoerbaar bestand. Het meest recente 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 in het vorige upgradepad wordt gebruikt. Als u een Microsoft Update-patch toepast, wordt er een in-place upgrade uitgevoerd van een Azure File Sync-installatie.
  5. Download het nieuwste installatieprogramma van de Azure File Sync agent vanuit het Microsoft Downloadcentrum.
    Als u een upgrade wilt uitvoeren van een bestaande Azure File Sync agentinstallatie, 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.

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 bij het beheer van de levenscyclus van agents door een kader te bieden waardoor uw agent niet kan verlopen of om een probleemloos te blijven, 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 binnen 21 dagen voor de vervaldatum en in het geselecteerde onderhoudsvenster een poging gestart om eenmaal per week een upgrade uit te voeren. Met deze optie hoeft u geen regelmatige Microsoft Update-patches te nemen.
  2. U kunt desgewenst 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 deze algemeen beschikbaar zijn. Dit is de aanbevolen, zorgeloze instelling die primaire agentversies en regelmatige updatepatches aan uw server biedt. Elke vrijgegeven agent is op GA-kwaliteit. Als u deze optie selecteert, zal Microsoft de nieuwste agentversie naar u laten vliegen. Geclusterde servers worden uitgesloten. Zodra de vlucht is voltooid, wordt de agent ook beschikbaar in het Microsoft Downloadcentrum aka.ms/AFS/agent.
De instelling voor automatische upgrade wijzigen

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

Open een PowerShell-console en navigeer naar de map waar u de synchronisatieagent hebt geïnstalleerd en importeer de server-cmdlets. Standaard ziet dit er 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

Garanties voor levenscyclus en wijzigingsbeheer van agents

Azure File Sync is een cloudservice, die voortdurend nieuwe functies en verbeteringen introduceert. Dit betekent dat een specifieke Azure File Sync agentversie alleen gedurende een beperkte tijd kan worden ondersteund. Om uw implementatie te vergemakkelijken, garanderen de volgende regels dat u voldoende tijd en melding 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 overlappen tussen de ondersteuning van primaire agentversies.
  • Waarschuwingen worden uitgegeven voor geregistreerde servers met een binnenkort verlopen agent ten minste drie maanden voordat deze is verlopen. U kunt controleren of een geregistreerde server een oudere versie van de agent gebruikt onder de sectie geregistreerde servers van een Storage Sync Service.
  • De levensduur van een secundaire agentversie is gebonden aan de bijbehorende primaire versie. Wanneer bijvoorbeeld agentversie 12.0.0.0 is ingesteld op verlopen, worden agentversies 12.*.*.* allemaal ingesteld om samen te verlopen.

Notitie

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

Volgende stappen