Planning voor de implementatie van Azure Files Sync

De bestanden worden opgeslagen in de cloud in Azure-bestands shares. Azure-bestands shares kunnen op twee manieren worden gebruikt: door deze serverloze Azure-bestands shares (SMB) rechtstreeks te mounten of door Azure-bestands shares on-premises op te Azure File Sync. Met welke implementatieoptie u kiest, worden de aspecten gewijzigd die u moet overwegen bij het plannen van uw implementatie.

• Directe bevestiging van een Azure-bestands share: omdat Azure Files SMB-toegang biedt, kunt u Azure-bestands shares on-premises of in de cloud met behulp van de standaard SMB-client die beschikbaar is in Windows, macOS en Linux. Omdat Azure-bestands shares serverloos zijn, is voor implementatie voor productiescenario's geen beheer van een bestandsserver of NAS-apparaat vereist. Dit betekent dat u geen softwarepatches hoeft toe te passen of fysieke schijven hoeft te verwisselen.

• Azure-bestands delen on-premises in de cache opslaan met Azure File Sync: met Azure File Sync kunt u de bestands shares van uw organisatie centraliseren in Azure Files, terwijl de flexibiliteit, prestaties en compatibiliteit van een on-premises bestandsserver behouden blijven. Azure File Sync transformeert een on-premises (of cloud) Windows Server naar een snelle cache van uw Azure-bestands share.

Beheerconcepten

Een Azure File Sync-implementatie heeft drie fundamentele beheerobjecten:

• Azure-bestands share: een Azure-bestands share is een serverloze cloudbestands share die het cloud-eindpunt van een Azure File Sync synchronisatierelatie biedt. Bestanden in een Azure-bestands share zijn rechtstreeks toegankelijk met SMB of het FileREST-protocol, hoewel we u aansporen om voornamelijk toegang te krijgen tot de bestanden via de Windows Server-cache wanneer de Azure-bestands share wordt gebruikt met Azure File Sync. Dit komt doordat Azure Files momenteel geen efficiënt mechanisme voor wijzigingsdetectie heeft, zoals Windows Server heeft, dus het rechtstreeks doorgeven van wijzigingen aan de Azure-bestands share naar de server-eindpunten duurt even.
• Server-eindpunt: het pad op Windows server dat wordt gesynchroniseerd met een Azure-bestands share. Dit kan een specifieke map op een volume of de hoofdmap van het volume zijn. Er kunnen meerdere server-eindpunten op hetzelfde volume bestaan als hun naamruimten elkaar niet overlappen.
• Synchronisatiegroep: het object dat de synchronisatierelatie definieert tussen een cloud-eindpunt of Azure-bestands share en een server-eindpunt. 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-bestands delen

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 Schaalbaarheids- en prestatiedoelen voor Azure Files 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 managementconcepten

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 synchronisatiegroepsrelaties 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-synchronisatieservice kan synchronisatiegroepen maken die Azure-bestands shares bevatten voor meerdere opslagaccounts en meerdere geregistreerde Windows Servers.

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

Een synchronisatiegroep bevat één cloud-eindpunt of Azure-bestands share en ten minste één server-eindpunt. Het server-eindpuntobject bevat de instellingen waarmee de mogelijkheid voor cloudopslaglagen wordt geconfigureerd. Dit biedt de cachingmogelijkheid van Azure File Sync. Als u wilt synchroniseren met een Azure-bestands share, moet het opslagaccount met de Azure-bestands share zich in dezelfde Azure-regio als de Storage-synchronisatieservice.

Houd rekening met het aantal Storage synchronisatieservices dat nodig is

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

Maak alleen Storage synchronisatieservices als u het volgende hebt:

• afzonderlijke sets servers die nooit gegevens met elkaar mogen uitwisselen. In dit geval wilt u het systeem zo ontwerpen dat bepaalde sets servers worden uitgesloten voor synchronisatie met een Azure-bestands share die al wordt gebruikt als een cloud-eindpunt in een synchronisatiegroep in een andere Storage Sync-service. Een andere manier om dit te bekijken, is Windows servers die zijn geregistreerd bij een andere opslagsynchronisatieservice, niet kunnen synchroniseren met dezelfde Azure-bestands share.
• een behoefte aan meer geregistreerde servers of synchronisatiegroepen dan één synchronisatieservice Storage kan ondersteunen. Bekijk de Azure File Sync schaaldoelen voor meer informatie.

Synchronisatie-topologies met een goede balans plannen

Voordat u resources implementeert, is het belangrijk om te plannen wat u wilt synchroniseren op een lokale server, met welke Azure-bestands share. Als u een plan maakt, kunt u bepalen hoeveel opslagaccounts, Azure-bestands shares en synchronisatie-resources u nodig hebt. Deze overwegingen zijn nog steeds relevant, zelfs als uw gegevens zich momenteel niet op een Windows-server bevinden of op de server die u op de lange termijn wilt gebruiken. De migratiesectie kan helpen bij het bepalen van de juiste migratiepaden voor uw situatie.

In deze stap bepaalt u hoeveel Azure-bestands shares u nodig hebt. Eén Windows Server-exemplaar (of cluster) kan maximaal 30 Azure-bestands shares 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 in beeld te brengen, is door een on-premises share te maken die 1:1 toeziet aan een Azure-bestands share. Als u een klein genoeg aantal shares hebt, minder dan 30 voor één Windows Server-exemplaar, raden we een 1:1-toewijzing aan.

Als u meer dan 30 shares hebt, is het toewijzen van een on-premises share 1:1 aan een Azure-bestands share vaak niet nodig. Overweeg de volgende opties.

Groeperen delen

Als uw HR-afdeling (Human Resources) bijvoorbeeld 15 shares heeft, kunt u overwegen om alle HR-gegevens op te slaan in één Azure-bestands share. Als u meerdere on-premises shares opslaat in één Azure-bestands share, voorkomt dit niet dat u de gebruikelijke 15 SMB-shares op uw lokale Windows Server-exemplaar kunt maken. Dit betekent alleen dat u de hoofdmappen van deze 15 shares organiseert als submappen onder een gemeenschappelijke map. Vervolgens synchroniseert u deze algemene map naar een Azure-bestands share. Op die manier is er slechts één Azure-bestands share 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-bestands share. Als u de hoofdmap van het volume synchroniseert, gaan alle submappen en bestanden naar dezelfde Azure-bestands share.

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-bestands shares en Azure File Sync met 100 miljoen items (bestanden en mappen) per share. Maar een best practice is om het aantal onder 20 miljoen of 30 miljoen in één share te houden. Het instellen Azure File Sync een lager aantal items is niet alleen nuttig voor bestandssynchronisatie. Een lager aantal items biedt ook voordelen voor scenario's als deze:

• De initiële scan van de cloudinhoud kan sneller worden voltooid, waardoor de wachttijd afneemt tot de naamruimte wordt weergegeven op een server die is ingeschakeld voor Azure File Sync.
• Herstel aan de cloudzijde vanuit een momentopname van een Azure-bestands share gaat sneller.
• Herstel na noodherstel van een on-premises server kan aanzienlijk versnellen.
• Wijzigingen die rechtstreeks in een Azure-bestands share (buiten synchronisatie) worden aangebracht, kunnen sneller worden gedetecteerd en gesynchroniseerd.

Een gestructureerde benadering van een implementatiekaart

Voordat u cloudopslag in een latere stap implementeert, is het belangrijk om een kaart te maken tussen on-premises mappen en Azure-bestands shares. Met deze toewijzing wordt bepaald hoeveel en Azure File Sync synchronisatiegroepsbronnen die u wilt inrichten. Een synchronisatiegroep verbindt de Azure-bestands share en de map op uw server met elkaar en brengt een synchronisatieverbinding tot stand.

Als u wilt bepalen hoeveel Azure-bestands shares u nodig hebt, bekijkt u de volgende limieten en best practices. 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-bestands shares.

• Een Azure-bestands share wordt geïmplementeerd in een opslagaccount. Door deze rangschikking wordt het opslagaccount een schaaldoel voor prestatienummers zoals IOPS en doorvoer.

  Eén standaard Azure-bestands share kan theoretisch de maximale prestaties verzadigen die een opslagaccount kan leveren. Als u meerdere shares in één opslagaccount plaats, maakt u een gedeelde pool van IOPS en doorvoer voor deze shares. Als u van plan bent om alleen Azure File Sync aan deze bestands shares te koppelen, zal het groeperen van verschillende Azure-bestands shares in hetzelfde opslagaccount geen probleem vormen. Bekijk de prestatiedoelen voor Azure-bestands delen 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 verplaatsen die de Azure-bestands share native gaat gebruiken, hebt u mogelijk meer prestaties van uw Azure-bestands share nodig. Als dit type gebruik een mogelijkheid is, is het zelfs in de toekomst het beste om één standaard Azure-bestands share te maken in een eigen opslagaccount.

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

Het is een best practice 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-bestands shares. Azure File Sync is getest met 100 miljoen items (bestanden en mappen) per share. Maar het is vaak het beste om het aantal items in één share onder de 20 miljoen of 30 miljoen te houden. Splits uw naamruimte in meerdere shares als u deze aantallen begint te overschrijden. Als u ongeveer onder deze getallen blijft, kunt u meerdere on-premises shares in dezelfde Azure-bestands share blijven groepen. Deze praktijk biedt u ruimte om te groeien.

Het is mogelijk dat in uw situatie een set mappen logisch kan worden gesynchroniseerd met dezelfde Azure-bestands share (met behulp van de nieuwe algemene basismapbenadering die eerder is genoemd). Maar het is misschien nog steeds beter om mappen opnieuw te groeperen, zodat ze worden gesynchroniseerd met twee in plaats van één Azure-bestands share. U kunt deze methode gebruiken om het aantal bestanden en mappen per bestands share evenwichtig te houden op de server. U kunt uw on-premises shares ook splitsen en synchroniseren over meer on-premises servers, zodat u per extra server met nog eens 30 Azure-bestands shares kunt synchroniseren.

Een toewijzingstabel maken

Gebruik de vorige informatie om te bepalen hoeveel Azure-bestands shares u nodig hebt en welke onderdelen van uw bestaande gegevens uiteindelijk in welke Azure-bestands share eindigen.

Maak een tabel die uw ideeën registreert, zodat u er naar kunt verwijzen wanneer dat nodig is. Georganiseerd blijven is belangrijk omdat u bij het inrichten van veel Azure-resources in één keer eenvoudig details van uw toewijzingsplan kwijt kunt raken. Download het volgende Excel-bestand om als sjabloon te gebruiken bij het maken van uw toewijzing.

Download een sjabloon voor naamruimtetoewijzing.

Windows overwegingen voor de bestandsserver

Als u de synchronisatiemogelijkheid op Windows Server wilt inschakelen, moet u de Azure File Sync agent installeren. De Azure File Sync-agent biedt twee hoofdonderdelen: , de achtergrond-Windows-service die verantwoordelijk is voor het bewaken van wijzigingen op de server-eindpunten en het initiëren van synchronisatiesessies, en , een bestandssysteemfilter dat opslag in cloudlagen en snel herstel na noodherstel mogelijk FileSyncSvc.exe StorageSync.sys maakt.

Vereisten voor het besturingssysteem

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

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

Minimale systeembronnen

Azure File Sync vereist een server, fysiek of virtueel, met ten minste één CPU en minimaal 2 GiB geheugen.

Voor de meeste productieworkloads wordt niet aangeraden om een Azure File Sync met alleen de minimale vereisten te configureren. Zie Aanbevolen systeemresources voor meer informatie.

Aanbevolen systeembronnen

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 systeembronnen. Voor Azure File Sync wordt de schaal bepaald door het aantal objecten op de server-eindpunten en het verloop van de gegevensset. Eén server kan server-eindpunten hebben in meerdere synchronisatiegroepen en het aantal objecten dat wordt vermeld in de volgende tabelaccounts voor de volledige naamruimte waar een server aan is gekoppeld.

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

Naamruimtegegevens worden uit prestatieoverwegingen opgeslagen in het geheugen. Daarom hebben grotere naamruimten meer geheugen nodig om goede prestaties te behouden en is voor meer verloop meer CPU nodig om te verwerken.

In de volgende tabel hebben we zowel de grootte van de naamruimte als een conversie naar capaciteit voor typische bestands shares 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.

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

• Een lokaal gekoppeld volume dat is geformatteerd met het NTFS-bestandssysteem.

Evaluatie-cmdlet

Voordat u Azure File Sync implementeert, moet u evalueren of het compatibel is met uw systeem met behulp van 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. De controles hebben betrekking op de meeste, maar niet op alle functies die hieronder worden vermeld; We raden u aan de rest van deze sectie zorgvuldig 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. Deze 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. 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 Windows Server-besturingssysteem 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 virtuele machine 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 interop-status van NTFS-bestandssysteemfuncties:

Azure File Sync worden ook bepaalde tijdelijke bestanden en systeemmappen overgeslagen:

Overweeg hoeveel vrije ruimte u nodig hebt op uw lokale schijf

Wanneer u van plan bent Azure File Sync te gebruiken, moet u rekening houden met hoeveel vrije ruimte u nodig hebt op de lokale schijf waarop u een server-eindpunt wilt hebben.

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

• Met cloudopslaglagen ingeschakeld:

  • Reparsepunten voor gelaagde bestanden
  • Azure File Sync metagegevensdatabase
  • Azure File Sync-heatstore
  • Volledig gedownloade bestanden in uw hot-cache (indien beschikbaar)
  • Vereisten voor het beleid voor vrije ruimte voor volumes

• Als opslag in cloudlagen is uitgeschakeld:

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

We gebruiken een voorbeeld om te illustreren hoe u de hoeveelheid vrije ruimte op uw lokale schijf kunt schatten. Stel dat u uw Azure File Sync hebt geïnstalleerd op uw Azure Windows-VM en van plan bent een server-eindpunt te maken op schijf F. U hebt 1 miljoen bestanden en wilt deze allemaal in lagen opslaan, 100.000 mappen en een schijfclustergrootte van 4 KiB. De schijfgrootte is 1000 GiB. U wilt opslag in cloudlagen inschakelen en uw beleid voor vrije volumeruimte 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)

In dit geval Azure File Sync voor deze naamruimte ongeveer 209.500.000 KiB (209,5 GiB) aan ruimte nodig. Voeg dit bedrag 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 Failoverclustering van servers wordt ondersteund Azure File Sync de implementatieoptie Bestandsserver voor algemeen gebruik.
2. Het enige scenario dat wordt ondersteund door Azure File Sync is Windows Server-failovercluster 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.

Gegevensontdubbeling

Windows Server 2016 en Windows Server 2019
Gegevens ontdubbeling wordt ondersteund ongeacht of opslag in cloudlagen is ingeschakeld of uitgeschakeld op een of meer server-eindpunten op het volume voor Windows Server 2016 en Windows Server 2019. Als u Gegevens ontdubbeling inschakelen op een volume met ingeschakelde cloudopslaglagen, kunt u meer bestanden on-premises in de cache opslaan zonder dat u meer opslagruimte inrichten.

Wanneer Gegevens ontdubbeling is ingeschakeld op een volume waarop opslag in cloudlagen is ingeschakeld, worden voor ontdubbeling geoptimaliseerde bestanden binnen de eindpuntlocatie van de server in lagen opgeslagen die vergelijkbaar zijn met een normaal bestand op basis van de beleidsinstellingen voor cloudopslaglagen. Zodra de voor ontdubbeling geoptimaliseerde bestanden in lagen zijn opgeslagen, wordt de garbage collection-taak voor gegevensverdubbeling automatisch uitgevoerd om schijfruimte vrij te maken door onnodige segmenten te verwijderen waarnaar niet meer wordt verwezen door andere bestanden op het volume.

Houd er rekening mee dat de volumebesparing alleen van toepassing is op de server; uw gegevens in de Azure-bestands share worden niet ontdubbeld.

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

Opmerkingen

• Als Gegevens ontdubbeling is geïnstalleerd voordat u de Azure File Sync-agent installeert, is opnieuw opstarten vereist om gegevens ontdubbeling en opslag in cloudlagen op hetzelfde volume te ondersteunen.

• Als Gegevens ontdubbeling is ingeschakeld op een volume nadat opslag in cloudlagen is ingeschakeld, optimaliseert de eerste optimalisatie van ontdubbeling bestanden op het volume dat nog niet in een laag is opgeslagen en heeft dit de volgende invloed op opslag in cloudlagen:

  • Beleid voor vrije ruimte blijft bestanden in lagen opslaan op basis van de vrije ruimte op het volume met behulp van de heatmap.
  • Met het datumbeleid wordt opslag in lagen overgeslagen van bestanden die mogelijk anderszins in aanmerking komen voor opslag in lagen omdat de ontdubbelingsoptimalisatie-taak toegang heeft tot de bestanden.

• Voor lopende optimalisatietaken voor ontdubbeling wordt opslag in cloudlagen met datumbeleid vertraagd door de instelling MinimumFileAgeDays voor gegevensverdubbeling als het bestand nog niet in lagen is opgeslagen.

  • Voorbeeld: als de instelling MinimumFileAgeDays zeven dagen is en het datumbeleid voor cloudopslaglagen 30 dagen is, worden met het datumbeleid bestanden na 37 dagen in lagen opgeslagen.
  • Opmerking: zodra een bestand is gelaagd op Azure File Sync, wordt het bestand overgeslagen met de optimalisatie van ontdubbeling.

• Als een server met Windows Server 2012 R2 met de Azure File Sync-agent is bijgewerkt naar Windows Server 2016 of Windows Server 2019, moeten de volgende stappen worden uitgevoerd om gegevensdeduplicatie en opslag in cloudlagen op hetzelfde volume te ondersteunen:

  • Verwijder de Azure File Sync voor Windows Server 2012 R2 en start de server opnieuw op.
  • Download de Azure File Sync agent voor de nieuwe serverbesturingssysteemversie (Windows Server 2016 of Windows Server 2019).
  • 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 samenwerking met DFS-naamruimten (DFS-N) en DSF-replicatie (DFS-R).

DFS-naamruimten (DFS-N): Azure File Sync wordt volledig ondersteund op DFS-N-servers. U kunt de Azure File Sync op een of meer DFS-N-leden installeren om gegevens te synchroniseren tussen de server-eindpunten en het cloud-eindpunt. Zie overzicht van DFS-naamruimten voor meer informatie.

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

• U migreert van een DFS-R-implementatie naar een Azure File Sync implementatie. Zie Migrate a DSF-replicatie (DFS-R) deployment to Azure File Sync (Een DFS-R)-implementatiemigreren naar Azure File Sync.
• 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 de Azure File Sync.

Voor Azure File Sync en DFS-R naast elkaar werken:

1. Azure File Sync cloudopslaglagen moeten worden uitgeschakeld op volumes met DFS-R-gerepliceerde mappen.
2. Server-eindpunten mogen niet worden geconfigureerd op DFS-R alleen-lezen replicatiemappen.

Zie overzicht van DSF-replicatie voor meer informatie.

Sysprep

Het gebruik van sysprep op een server met de Azure File Sync agent wordt niet ondersteund en kan leiden tot onverwachte resultaten. Agentinstallatie en serverregistratie moeten plaatsvinden na het implementeren van de serverinstallatie-installatie en het voltooien van sysprep mini-setup.

Windows Search

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

Andere HSM-oplossingen (Hierarchical Storage Management)

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

Prestatie en schaalbaarheid

Omdat de Azure File Sync-agent wordt uitgevoerd op een Windows Server-computer die verbinding maakt met de Azure-bestands shares, 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, de bestandsgrootte, de totale grootte van de gegevensset en de activiteit op de gegevensset. Omdat Azure File Sync op bestandsniveau werkt, worden de prestatiekenmerken van een Azure File Sync-oplossing beter gemeten in het aantal objecten (bestanden en mappen) dat per seconde wordt verwerkt.

Wijzigingen in de Azure-bestands share met behulp van de Azure Portal of SMB worden niet onmiddellijk gedetecteerd en gerepliceerd als wijzigingen in het server-eindpunt. Azure Files nog geen wijzigingsmeldingen of logboeken hebt, is er dus geen manier om automatisch een synchronisatiesessie te starten wanneer bestanden worden gewijzigd. Op Windows Server maakt Azure File Sync gebruik Windows USN-logboeken om automatisch een synchronisatiesessie te starten wanneer bestanden worden gewijzigd

Als u wijzigingen in de Azure-bestands share wilt detecteren, Azure File Sync een geplande taak genaamd een wijzigingsdetectie-taak. Een wijzigingsdetectie-taak bevat elk bestand in de bestands share en vergelijkt dit vervolgens met de synchronisatieversie voor dat bestand. Wanneer de taak wijzigingsdetectie vaststelt dat bestanden zijn gewijzigd, Azure File Sync een synchronisatiesessie gestart. De taak voor wijzigingsdetectie wordt elke 24 uur gestart. Omdat de taak voor wijzigingsdetectie werkt door elk bestand in de Azure-bestands share te opsnoemen, duurt wijzigingsdetectie langer in grotere naamruimten dan in kleinere naamruimten. Voor grote naamruimten kan het langer dan één keer per 24 uur duren om te bepalen welke bestanden zijn gewijzigd.

Zie Metrische prestatiegegevens en Azure File Sync en schaaldoelen voor Azure File Sync 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 via de Azure File Sync-cachingservers gaan in plaats van via de Azure-bestands share. Omdat de server-eindpunten zich op Windows Server bevinden en Windows Server ad- en Windows-stijl ACL's al lange tijd ondersteunt, is er niets meer nodig dan ervoor te zorgen dat de Windows-bestandsservers die zijn geregistreerd bij de Storage Sync Service lid zijn van een domein. Azure File Sync worden ACL's opgeslagen in de bestanden in de Azure-bestands share en worden deze gerepliceerd naar alle server-eindpunten.

Hoewel het langer duurt om wijzigingen rechtstreeks in de Azure-bestands share te synchroniseren met de server-eindpunten in de synchronisatiegroep, kunt u er ook voor zorgen dat u uw AD-machtigingen ook rechtstreeks in de cloud kunt afdwingen voor uw bestands share. Hiervoor moet u uw opslagaccount toevoegen aan uw on-premises AD, net zoals uw Windows-bestandsservers lid zijn van een domein. Zie overzicht van Active Directory voor meer informatie over het toevoegen van uw opslagaccount aan een Active Directory van de klant Azure Files active directory.

Netwerken

De Azure File Sync-agent communiceert met uw Storage Sync-service en Azure-bestands share met behulp van het Azure File Sync REST-protocol en het FileREST-protocol, die beide altijd HTTPS via poort 443 gebruiken. SMB wordt nooit gebruikt voor het uploaden of downloaden van gegevens tussen uw Windows Server en de Azure-bestands share. Omdat de meeste organisaties HTTPS-verkeer via poort 443 toestaan, is een speciale netwerkconfiguratie meestal niet vereist voor het implementeren van Azure File Sync.

Op basis van het beleid of de unieke wettelijke vereisten van uw organisatie vereist u mogelijk meer beperkende communicatie met Azure. 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.
• Maak gebruik van Azure Files en Azure-netwerken zoals service-eindpunten en privé-eindpunten.
• Configureer Azure File Sync om uw proxy in uw omgeving te ondersteunen.
• Netwerkactiviteit vanuit Azure File Sync.

Zie netwerkoverwegingen Azure File Sync meer informatie Azure File Sync 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 in transit tussen de Azure File Sync-agent en Azure, en versleuteling op de rest van uw gegevens in de Azure-bestands share.

Windows Serverversleuteling in rust

Er zijn twee strategieën voor het versleutelen van gegevens op Windows Server die in het algemeen met Azure File Sync werken: versleuteling onder het bestandssysteem, zodat het bestandssysteem en alle gegevens die naar de server worden geschreven, worden versleuteld en versleuteling in 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, Windows Server het Postvak IN van BitLocker. 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 sideloadt om niet-geautoriseerde lees-/schrijfgegevens naar uw gegevens uit te voeren. Zie Overzicht van BitLocker voor meer informatie over BitLocker.

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

De andere hoofdmethode voor het versleutelen van gegevens is het versleutelen van de gegevensstroom van het bestand wanneer de toepassing het bestand opgeslagen. Sommige toepassingen kunnen dit zelf 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 bestands share te voorkomen door mensen die deze naar andere locaties kopiëren, zoals naar een flashstation, of door deze per e-mail naar een onbevoegde persoon te verzenden. Wanneer de gegevensstroom van een bestand is versleuteld als onderdeel van de bestandsindeling, blijft dit bestand versleuteld op de Azure-bestands share.

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

Versleuteling 'in transit'

Azure File Sync-agent communiceert met uw Storage Sync-service en Azure-bestands share 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 in transit, die standaard is ingeschakeld. Zelfs als de schakel op het niveau van het opslagaccount is uitgeschakeld, wat betekent dat niet-versleutelde verbindingen met uw Azure-bestands shares mogelijk zijn, gebruikt Azure File Sync nog steeds alleen versleutelde kanalen om toegang te krijgen tot uw bestands share.

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

We raden u ten zeerste aan ervoor te zorgen dat versleuteling van gegevens die onderweg zijn is ingeschakeld.

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

Versleuteling van Azure-bestandsdeel in rust

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.

Bestandsshares die geïmplementeerd zijn binnen GPv2-opslagaccounts, kunnen worden verplaatst tussen de standaardlagen (voor transactie geoptimaliseerd, dynamisch en statisch) zonder een nieuw opslagaccount te maken en gegevens migreren, maar er worden transactiekosten in rekening gebracht wanneer u uw laag veranderd. Wanneer u een bestandsshare van een dynamischere laag naar een statischere laag verplaatst, worden de schrijftransactiekosten voor de statischere laag in rekening gebracht voor elk bestand in de share. Wanneer u een bestandsshare verplaatst vaan een statischere laag naar een dynamischere laag, worden de leestransactiekosten in rekening gebracht voor elk bestand in de share.

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

Zie Beschikbare producten per regio voor regionale beschikbaarheid.

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

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

Volg het proces in dit document om toegang aan te vragen voor deze regio's.

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 zich echter een noodlot voordoet, zoals brand of overstromingen binnen het datacenter, kunnen alle replica's van een opslagaccount met LRS verloren gaan of onherkenbaar zijn.
• Zone-redundante opslag (ZRS): met ZRS zijn er 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. Schrijf schrijven worden asynchroon gerepliceerd naar een door Microsoft gedefinieerde secundaire regio. GRS biedt zes kopieën van uw gegevens, verspreid over twee Azure-regio's. In het geval van een grote ramp, zoals het permanente verlies van een Azure-regio als gevolg van een natuurramp of een andere vergelijkbare gebeurtenis, voert Microsoft een failover uit en wordt de secundaire regio de primaire regio, die alle bewerkingen verwerkt. 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 als ZRS, maar met geo-redundantie. Met GZRS worden bestanden drie keer opgeslagen in drie afzonderlijke opslagclusters in de primaire regio. Alle schrijfbewerkingen worden vervolgens asynchroon gerepliceerd naar een door Microsoft gedefinieerde secundaire regio. Het failoverproces voor GZRS werkt hetzelfde als GRS.

Standaard Azure-bestands shares van maximaal 5 TiB ondersteunen alle vier de redundantietypen. Standaardbestands shares die groter zijn dan 5 TiB ondersteunen alleen LRS en ZRS. Premium Azure-bestands shares 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.

Migratie

Als u een bestaande Windows-bestandsserver 2012R2 of nieuwer hebt, kunnen Azure File Sync direct worden geïnstalleerd, zonder dat u gegevens hoeft over te zetten naar een nieuwe server. Als u van plan bent om te migreren naar een nieuwe Windows-bestandsserver als onderdeel van de overstap op Azure File Sync, of als uw gegevens zich momenteel op NaS (Network Attached Storage) 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.

Bekijk het artikel Azure File Sync azure file share migration overview (Overzicht van migratie van azure-bestanden en Azure-bestands delen) voor gedetailleerde richtlijnen voor uw scenario.

Antivirus

Omdat antivirus werkt door bestanden te scannen op bekende schadelijke code, kan een antivirusproduct leiden tot het terugroepen van gelaagde bestanden, wat leidt tot hoge kosten voor het verwijderen van gegevens. In versie 4.0 en hoger van de Azure File Sync-agent hebben gelaagde bestanden de Windows kenmerk FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS ingesteld. We raden u aan contact op te nemen met uw softwareleverancier om te leren hoe u hun oplossing kunt configureren om het lezen van bestanden met deze kenmerkset over te slaan (veel doen dit automatisch).

De in-house antivirusoplossingen van Microsoft, Windows Defender en System Center Endpoint Protection (SCEP), slaan beide automatisch leesbestanden over waarin dit kenmerk is ingesteld. We hebben deze getest en één 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 en worden niet gelaagd omdat ze niet voldoen aan de vereiste voor de opslaglaaggrootte (>64 kB).

Backup

Als opslag in cloudlagen is ingeschakeld, mogen oplossingen die rechtstreeks een back-up maken van het server-eindpunt of een VM waarop het server-eindpunt zich bevindt, niet worden gebruikt. Cloudopslaglagen zorgen ervoor dat er slechts een subset van uw gegevens wordt opgeslagen op het server-eindpunt, met de volledige gegevensset die zich in uw Azure-bestands share bewaard. Afhankelijk van de gebruikte back-upoplossing worden gelaagde bestanden overgeslagen en geen back-up gemaakt (omdat het FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS-kenmerk is ingesteld), of worden ze teruggeroepen naar de schijf, wat resulteert in hoge kosten voor het aantal uitkomende gegevens. U kunt het beste een back-upoplossing in de cloud gebruiken om rechtstreeks een back-up van de Azure-bestands share te maken. Zie Over back-ups van Azure-bestands delen of neem contact op met uw back-upprovider om te zien of deze ondersteuning biedt voor het maken van back-ups van Azure-bestands shares.

Als u liever een on-premises back-upoplossing gebruikt, moeten back-ups worden uitgevoerd op een server in de synchronisatiegroep die opslag in cloudlagen heeft uitgeschakeld. Wanneer u een herstel wilt uitvoeren, gebruikt u de herstelopties op volume- of bestandsniveau. Bestanden die zijn hersteld met de hersteloptie op bestandsniveau worden gesynchroniseerd met alle eindpunten in de synchronisatiegroep en bestaande bestanden worden vervangen door de versie die is hersteld vanuit een back-up. Herstel op volumeniveau vervangt geen nieuwere bestandsversies in de Azure-bestands share of andere server-eindpunten.

Gegevensclassificatie

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

1. Als opslag in cloudlagen is ingeschakeld, worden uw meest populaire bestanden lokaal in de cache opgeslagen en worden de coolste bestanden gelaagd naar de Azure-bestands share in de cloud. Als uw gegevensclassificatie regelmatig alle bestanden in de bestands share scant, moeten de bestanden die in een cloudlaag zijn opgeslagen, worden ingeroepen 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 ingeroepen om de software de classificatie te laten zien.

Deze toename in zowel het aantal terugroepen als de hoeveelheid gegevens die wordt ingeroepen, kan de kosten verhogen.

Updatebeleid Azure File Sync-agent

De Azure File Sync-agent wordt regel matig bijgewerkt om nieuwe functionaliteit toe te voegen en om problemen op te lossen. We raden u aan Microsoft Update te configureren voor het ophalen van updates voor de Azure File Sync-agent wanneer deze beschikbaar zijn.

Belangrijkste versus secundaire agent versies

• Belang rijke agent versies bevatten vaak nieuwe functies en hebben een verhoogd aantal als het eerste deel van het versie nummer. Bijvoorbeeld: * 2. * .**
• Secundaire agent versies worden ook wel ' patches ' genoemd en zijn vaker vrijgegeven dan primaire versies. Ze bevatten vaak fout oplossingen en kleinere verbeteringen, maar geen nieuwe functies. Bijvoorbeeld: * * . 3.**

Upgrade paden

Er zijn vier goedgekeurde en geteste manieren om de Azure File Sync agent-updates te installeren.

1. Eigen Configureer Microsoft Update om updates van de agent automatisch te downloaden en te installeren.
   We raden altijd aan om elke Azure File Sync update uit te voeren om ervoor te zorgen dat u toegang hebt tot de meest recente oplossingen voor de Server Agent. Microsoft Update maakt dit proces naadloos, door automatisch updates te downloaden en te installeren.
2. Gebruik AfsUpdater.exe om agent updates te downloaden en te installeren.
   Het AfsUpdater.exe bevindt zich in de installatiemap van de agent. Dubbel klik op het uitvoer bare bestand om agent updates te downloaden en te installeren.
3. Een bestaande Azure File Sync agent patchen met behulp van een Microsoft Update patch-bestand of een MSP-bestand. Het meest recente Azure File Sync Update pakket kan worden gedownload uit de Microsoft Update catalogus.
   Als u een MSP-bestand uitvoert, wordt uw Azure File Sync-installatie bijgewerkt met dezelfde methode die automatisch wordt gebruikt door Microsoft Update in het vorige upgradepad. Bij het Toep assen van een Microsoft Update patch wordt een in-place upgrade van een Azure File Sync-installatie uitgevoerd.
4. Down load het nieuwste installatie programma voor Azure File Sync agent van het micro soft Download centrum.
   Als u een bestaande installatie van Azure File Sync agent wilt bijwerken, verwijdert u de oudere versie en installeert u de nieuwste versie van het gedownloade installatie programma. De registratie van de server, synchronisatie groepen en andere instellingen worden onderhouden door het Azure File Sync-installatie programma.

Beheer van automatische agent levenscyclus

Met Agent versie 6 heeft het bestand synchronisatie team een functie voor het automatisch bijwerken van de agent geïntroduceerd. U kunt een van de twee modi selecteren en een onderhouds venster opgeven waarin de upgrade wordt uitgevoerd op de server. Deze functie is ontworpen om u te helpen bij het beheer van de agent levenscyclus door ofwel een guardrail te bieden waardoor uw agent niet kan verlopen of geen problemen kan ondervinden. Blijf de huidige instelling.

1. Met de standaard instelling wordt geprobeerd te voor komen dat de agent verlopen. Binnen 21 dagen na de geboekte verval datum van een agent probeert de agent zelf een upgrade uit te voeren. Er wordt een poging gedaan om één keer per week een upgrade uit te voeren binnen 21 dagen vóór de verval datum en in het geselecteerde onderhouds venster. Met deze optie wordt niet voor komen dat regel matige Microsoft Update patches nodig zijn.
2. U kunt desgewenst selecteren dat de agent automatisch wordt bijgewerkt zodra er een nieuwe agent versie beschikbaar komt (momenteel niet van toepassing op geclusterde servers). Deze update vindt plaats tijdens het geselecteerde onderhouds venster en laat uw server van nieuwe functies en verbeteringen profiteren zodra deze algemeen beschikbaar is. Dit is de aanbevolen instelling voor het maken van een probleem, waarmee belang rijke agent versies en regel matige update patches naar uw server worden geleverd. Elke agent die wordt uitgebracht, is bij GA-kwaliteit. Als u deze optie selecteert, wordt de nieuwste versie van de agent naar u door micro soft geflighteerd. Geclusterde servers worden uitgesloten. Zodra de flighting is voltooid, wordt de agent ook beschikbaar gesteld in het micro soft Download centrum aka.MS/AFS/agent.

De instelling voor automatische upgrades wijzigen

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

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

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

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

Als u de huidige beleids instelling wilt wijzigen in het vertraagde update spoor, kunt u het volgende gebruiken:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

Als u de huidige beleids instelling wilt wijzigen in de onmiddellijke update track, kunt u het volgende gebruiken:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest

Garanties voor levens cyclus van agents en wijzigings beheer

Azure File Sync is een Cloud service waarmee voortdurend nieuwe functies en verbeteringen worden geïntroduceerd. Dit betekent dat een specifieke Azure File Sync agent versie alleen kan worden ondersteund voor een beperkte periode. Om uw implementatie te vergemakkelijken, worden de volgende regels gegarandeerd voldoende tijd en melding voor het uitvoeren van agent updates/upgrades in uw proces voor wijzigings beheer:

• Belang rijke agent versies worden ten minste zes maanden na de eerste release ondersteund.
• We garanderen dat er ten minste drie maanden bestaan tussen de ondersteuning van belang rijke agent versies.
• Er worden waarschuwingen gegeven voor geregistreerde servers met behulp van een binnenkort verlopen agent van ten minste drie maanden vóór de verval datum. U kunt controleren of een geregistreerde server een oudere versie van de agent gebruikt onder het gedeelte geregistreerde servers van een opslag synchronisatie service.
• De levens duur van een secundaire agent versie is gebonden aan de bijbehorende primaire versie. Bijvoorbeeld, als agent versie 3,0 wordt uitgebracht, versie 2 van agent. * worden allemaal ingesteld om te verlopen.

Volgende stappen

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