Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Cloudopslaglagen, een optionele functie van Azure File Sync, vermindert de hoeveelheid lokale opslag die nodig is, terwijl de prestaties van een on-premises bestandsserver behouden blijven.
Wanneer deze functie is ingeschakeld, worden alleen vaak geopende (dynamische) bestanden op uw lokale server opgeslagen. Niet vaak geopende (statische) bestanden worden gesplitst in naamruimte (bestands- en mapstructuur) en bestandsinhoud. De naamruimte wordt lokaal opgeslagen en de inhoud van het bestand wordt opgeslagen in een Azure-bestandspool in de cloud.
Wanneer een gebruiker een getiered bestand opent, haalt Azure File Sync naadloos de bestandsgegevens uit de Azure-bestandsshare op.
Hoe cloudlagen werken
Beleidsregels voor cloud-tiering
Wanneer u cloud-tiering inschakelt, zijn er twee beleidsregels die u kunt instellen om Azure File Sync te informeren wanneer 'cool' bestanden moeten worden getierd: het beleid voor vrije ruimte en het datumbeleid.
Beleid voor vrij beschikbare ruimte van volume
Het volumevrije ruimtebeleid vertelt Azure File Sync om koele bestanden naar de cloud te verplaatsen wanneer een bepaalde hoeveelheid ruimte op uw lokale schijf wordt gebruikt.
Als uw lokale schijfcapaciteit bijvoorbeeld 200 GiB is en u wilt dat ten minste 40 GiB van uw lokale schijfcapaciteit altijd vrij blijft, moet u het volumevrije ruimtebeleid instellen op 20%. Volumevrije ruimte is van toepassing op volumeniveau in plaats van op het niveau van afzonderlijke mappen of servereindpunten.
Datumbeleid
Met het datumbeleid worden koele bestanden naar de cloud verplaatst als ze gedurende x aantal dagen niet zijn geopend (gelezen of naar geschreven). Als u bijvoorbeeld merkt dat bestanden die langer dan 15 dagen zijn verlopen zonder dat ze worden geopend, doorgaans archiveringsbestanden zijn, moet u uw datumbeleid instellen op 15 dagen.
Zie Beleid voor Azure File Sync-cloud-tiering kiezen voor meer voorbeelden van hoe het beleid voor datumgebruik en vrije ruimte op volume samenwerken.
Windows Server-gegevensontdubbeling
Gegevensdeduplicatie wordt ondersteund op volumes met ingeschakelde cloud-tiering beginnende met Windows Server 2016. Zie Planning voor een Azure File Sync-implementatievoor meer informatie.
Heatmap voor cloudindeling
Azure File Sync bewaakt de bestandstoegang (lees- en schrijfbewerkingen) in de loop van de tijd en wijst een heatscore toe aan elk bestand op basis van hoe recent en vaak het bestand wordt geopend. Deze scores worden gebruikt om een 'heatmap' van uw naamruimte te bouwen op elk servereindpunt. Deze heatmap is een lijst met alle bestanden die worden gesynchroniseerd op een locatie waarop cloud-tiering is ingeschakeld, gesorteerd op hun heat-score. Recent geopende bestanden worden beschouwd als 'hot', terwijl bestanden die nauwelijks zijn aangeraakt en al enige tijd niet zijn geopend, als 'cool' worden beschouwd.
Om de relatieve positie van een afzonderlijk bestand in die heatmap te bepalen, gebruikt het systeem het maximum van de tijdstempels in de volgende volgorde: MAX (Laatste toegangstijd, Laatst gewijzigd tijdstip, Aanmaaktijd).
Normaal gesproken wordt de laatste toegangstijd bijgehouden en beschikbaar. Wanneer een nieuw servereindpunt wordt aangemaakt met ingeschakelde cloud-tiering, is er niet voldoende tijd verstreken om de bestandstoegang waar te nemen. Als er geen geldige laatste toegangstijd is, wordt in plaats daarvan de laatst gewijzigde tijd gebruikt om de relatieve positie in de heatmap te evalueren.
Het datumbeleid werkt op dezelfde manier. Zonder een laatste toegangstijd zal het datumbeleid op de laatst gewijzigde tijd reageren. Als dat niet beschikbaar is, valt deze terug op de tijd van het maken van een bestand. Na verloop van tijd ziet het systeem meer aanvragen voor toegang tot bestanden en wordt automatisch de zelf bijgehouden laatste toegangstijd gebruikt.
Opmerking
Cloudlagen zijn niet afhankelijk van de NTFS-functie voor het registreren van de laatste toegangstijd. Deze NTFS-functie is standaard uitgeschakeld en vanwege prestatieoverwegingen wordt u niet aangeraden deze functie handmatig in te schakelen. Bij cloud-laagindeling wordt de laatste toegangstijd afzonderlijk bijgehouden.
Proactief herinneren
Wanneer een bestand wordt aangemaakt of gewijzigd, kunt u proactief een bestand terughalen naar servers die u opgeeft. Proactief intrekken maakt het nieuwe of gewijzigde bestand direct beschikbaar voor gebruik op elke opgegeven server.
Een wereldwijd gedistribueerd bedrijf heeft bijvoorbeeld filialen in de VS en India. In de ochtend in de VS maken informatiewerkers een nieuwe map en bestanden voor een gloednieuw project en werken er de hele dag aan. Azure File Sync synchroniseert mappen en bestanden met de Azure-bestandsshare (cloudeindpunt). Informatiewerkers in India blijven werken aan het project in hun tijdzone. Wanneer ze in de ochtend aankomen, moet de lokale server met Azure File Sync in India deze nieuwe bestanden lokaal beschikbaar hebben, zodat het India-team efficiënt van een lokale cache kan werken. Als u deze modus inschakelt, moet de server de bestanden proactief intrekken zodra ze zijn gewijzigd of gemaakt in de Azure-bestandsshare, waardoor de bestandstoegangstijden worden verbeterd.
Als bestanden die naar de server zijn teruggehaald niet lokaal nodig zijn, kunnen onnodige terughaalacties het uitgaande verkeer en de kosten verhogen. Schakel daarom alleen proactief intrekken in wanneer u weet dat het vooraf invullen van de cache van een server met recente wijzigingen uit de cloud een positief effect heeft op gebruikers of toepassingen die de bestanden op die server gebruiken.
Het inschakelen van proactief intrekken kan ook leiden tot een verhoogd bandbreedtegebruik op de server en kan ertoe leiden dat andere relatief nieuwe inhoud op de lokale server agressief wordt gelaagd vanwege de toename van de bestanden die worden ingetrokken. Op zijn beurt kan gelaagdheid te snel leiden tot meer terugroepacties als de bestanden die gelaagd worden beschouwd als dynamisch door servers.
Zie Azure File Sync implementeren voor meer informatie over proactieve intrekking.
Gelaagd versus lokaal in cache opgeslagen bestandsgedrag
Cloud-tiering is de scheiding tussen de naamruimtescheiding (zoals bestandshiërarchie en bestandseigenschappen) en de bestandsinhoud.
Gelaagd bestand
Voor gelaagde bestanden is de grootte op schijf nul omdat de bestandsinhoud zelf niet lokaal wordt opgeslagen. Wanneer een bestand is getierd, vervangt het Azure File Sync-bestandssysteemfilter (StorageSync.sys) het bestand lokaal door een verwijzing die een reparsepunt wordt genoemd. Het reparsepunt vertegenwoordigt een URL naar het bestand in de Azure-bestandsshare. Een gelaagd bestand heeft zowel het offline kenmerk als het FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS kenmerk dat is ingesteld in NTFS, zodat toepassingen van derden gelaagde bestanden veilig kunnen identificeren.
Lokaal in cache opgeslagen bestand
Voor bestanden die zijn opgeslagen op een on-premises bestandsserver, is de grootte op schijf ongeveer gelijk aan de logische grootte van het bestand, omdat het hele bestand (bestandskenmerken + bestandsinhoud) lokaal wordt opgeslagen.
Het is ook mogelijk dat een bestand gedeeltelijk of gedeeltelijk wordt ingetrokken. In een gedeeltelijk gelaagd bestand wordt slechts een deel van het bestand opgeslagen op schijf. Mogelijk heeft u gedeeltelijk teruggehaalde bestanden op uw volume als deze bestanden slechts gedeeltelijk worden gelezen door toepassingen die streamingtoegang tot bestanden ondersteunen. Enkele voorbeelden zijn multimediaspelers en zip-hulpprogramma's. Azure File Sync is efficiënt en roept alleen de aangevraagde gegevens van de verbonden Azure-bestandsshare in.
Opmerking
Grootte vertegenwoordigt de logische grootte van het bestand. Grootte op schijf vertegenwoordigt de fysieke grootte van de bestandsstroom die is opgeslagen op de schijf.
Modus weinig schijfruimte
Schijven die servereindpunten hebben, kunnen om verschillende redenen ruimte tekortkomen, zelfs wanneer cloud-tiering is ingeschakeld. Deze redenen zijn onder andere:
- Gegevens die handmatig naar de schijf worden gekopieerd buiten het pad naar het servereindpunt
- Trage of vertraagde synchronisatie waardoor bestanden niet gelaagd worden
- Overmatige terugroepacties van gelaagde bestanden
Wanneer de schijfruimte opraakt, werkt Azure File Sync mogelijk niet goed en kan het zelfs onbruikbaar worden. Hoewel het niet mogelijk is voor Azure File Sync om deze gevallen volledig te voorkomen, is de modus voor onvoldoende schijfruimte (beschikbaar in versies van de Azure File Sync-agent vanaf 15.1) ontworpen om te voorkomen dat een servereindpunt deze situatie bereikt en de server er sneller uit komt.
Voor servereindpunten waarbij cloud-tiering is ingeschakeld, als de vrije ruimte op het volume onder de berekende drempelwaarde daalt, dan bevindt het volume zich in de schijfruimtetekortmodus.
In de modus weinig schijfruimte doet de Azure File Sync-agent twee dingen anders:
Proactive Tiering: in deze modus worden bestanden door de File Sync-agent proactiever naar de cloud overgebracht. De synchronisatieagent controleert of bestanden elke minuut worden gelaagd in plaats van de normale frequentie van elk uur. Laaging van het volumevrije ruimtebeleid vindt doorgaans niet plaats tijdens de eerste uploadsynchronisatie totdat het volledige uploaden is voltooid; In de modus weinig schijfruimte wordt lagen echter ingeschakeld tijdens de eerste uploadsynchronisatie en worden bestanden in aanmerking genomen voor lagen zodra het afzonderlijke bestand is geüpload naar de Azure-bestandsshare.
Niet-permanente terugroepacties: wanneer een gebruiker een gelaagd bestand opent, worden bestanden die rechtstreeks uit de Azure-bestandsshare worden teruggeroepen, niet op de schijf bewaard. Oproepen die door de
Invoke-StorageSyncFileRecallcmdlet worden geïnitieerd, zijn een uitzondering op deze regel en worden op de schijf opgeslagen.
Wanneer de hoeveelheid vrije ruimte de drempelwaarde overschrijdt, wordt azure File Sync automatisch teruggezet naar de normale status. De modus voor weinig schijfruimte is alleen van toepassing op servers met ingeschakelde cloud-tiering en respecteert altijd het beleid voor vrije ruimte op volumes.
Als een volume twee servereindpunten heeft, één met opslag-tiering ingeschakeld en één zonder opslag-tiering, dan is de modus weinig schijfruimte alleen van toepassing op het servereindpunt waarbij opslag-tiering is ingeschakeld.
Hoe wordt de drempelwaarde voor de modus met weinig schijfruimte berekend?
Bereken de drempelwaarde door minimaal de volgende drie getallen te gebruiken:
- 10% van volumegrootte in GiB
- Volume vrije ruimtebeleid in GiB
- 20 GiB
De volgende tabel bevat enkele voorbeelden van hoe de drempelwaarde wordt berekend en wanneer het volume zich in de modus met weinig schijfruimte bevindt.
| Volumegrootte | 10% volumegrootte | Beleid voor vrije opslagruimte in volume | Drempelwaarde = Min(10% van volumegrootte, volumevrij ruimtebeleid, 20 GB) | Vrije ruimte voor huidig volume | Is de modus voor weinig schijfruimte actief? | Reden |
|---|---|---|---|---|---|---|
| 100 GiB | 10 GiB | 7% (7 GiB) | 7 GiB = Min (10 GiB, 7 GiB, 20 GiB) | 9% (9 GiB) | Nee. | Huidige volume vrije ruimte (9 GiB) > drempelwaarde (7 GiB) |
| 100 GiB | 10 GiB | 7% (7 GiB) | 7 GiB = Min (10 GiB, 7 GiB, 20 GiB) | 5% (5 GiB) | Ja | Huidige volume vrije ruimte (5 GiB) < drempelwaarde (7 GiB) |
| 300 GiB | 30 GiB | 8% (24 GiB) | 20 GiB = Min (30 GiB, 24 GiB, 20 GiB) | 7% (21 GiB) | Nee. | Huidige volume vrije ruimte (21 GiB) > drempelwaarde (20 GiB) |
| 300 GiB | 30 GiB | 8% (24 GiB) | 20 GiB = Min (30 GiB, 24 GiB, 20 GiB) | 6% (18 GiB) | Ja | Huidige volume vrije ruimte (18 GiB) < drempelwaarde (20 GiB) |
Hoe werkt de modus voor weinig schijfruimte samen met het beleid voor vrije schijfruimte op volume?
De modus voor weinig schijfruimte respecteert altijd het volumevrije ruimtebeleid. De drempelwaardeberekening is ontworpen om ervoor te zorgen dat het volumevrije ruimtebeleid dat door de gebruiker is ingesteld, wordt gerespecteerd.
Wat is de meest voorkomende oorzaak voor servereindpunten die zich in de modus lage schijf bevinden?
De primaire oorzaak van de modus voor lage schijfprestaties is het kopiëren of verplaatsen van grote hoeveelheden gegevens naar de schijf waar een servereindpunt zich bevindt met tiering ingeschakeld.
Hoe kom ik uit de modus met weinig schijfruimte?
Hier volgen twee manieren om de modus lage schijf op het servereindpunt af te sluiten:
- De modus Lage schijf schakelt automatisch over naar normaal gedrag door het niet meer persistent maken van terugroep- en tieringbestanden, zonder tussenkomst.
- U kunt het proces handmatig versnellen door de volumegrootte te vergroten of ruimte vrij te maken buiten het servereindpunt.
Controleren of een server zich in de modus Onvoldoende schijfruimte bevindt?
- Als een servereindpunt zich in de modus lage schijf bevindt, wordt dit weergegeven in Azure Portal in de sectie Status van cloudlagen van het tabblad Fouten en probleemoplossing van het servereindpunt.
- Gebeurtenis-id 19000 wordt elke minuut vastgelegd in het gebeurtenislogboek Telemetrie voor elk servereindpunt. Gebruik deze gebeurtenis om te bepalen of het servereindpunt zich in de modus lage schijf bevindt (IsLowDiskMode = true). Het Telemetrie-gebeurtenislogboek bevindt zich in Gebeurtenisviewer onder Applicaties en Services\Microsoft\FileSync\Agent.