Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Azure Files tillhandahåller fullständigt hanterade, skalbara SMB-filresurser som passar utmärkt för lagring av användarprofiler för virtuella skrivbord och diskavbildningar i molnet.
Vad är VDI?
VDI (Virtual Desktop Infrastructure) centraliserar skrivbordsmiljöer på servrar, vilket möjliggör säker fjärråtkomst och förenklad hantering mellan enheter. Azure Virtual Desktop (AVD) är Microsofts molnbaserade VDI-lösning som erbjuder skalbara Windows 10- och 11-skrivbord med flera sessioner med sömlös integrering i Microsoft 365 och Microsoft Entra ID, perfekt för distansarbete och säker resursåtkomst. Andra VDI-erbjudanden är Citrix/VMWare Horizon i Azure-infrastrukturen.
Varför Azure Files for VDI?
Azure Files är perfekt för VDI eftersom det tillhandahåller molnfilresurser som integreras sömlöst med FSLogix för lagring av användarprofiler eller App Attach för att lagra diskbilder för dynamisk programleverans. När de distribueras korrekt kan Azure Files minska infrastrukturkostnaderna, ge hög tillgänglighet, stödja säkerhet i företagsklass och leverera konsekventa prestanda för en smidig användarupplevelse över virtuella skrivbordssessioner.
Prestanda, skalning och kostnad
Azure Files erbjuder olika faktureringsmodeller, inklusive reserverade och betala per användning. Se Förstå Azure Files-fakturering.
Även om Azure Files har stöd för tusentals samtidiga användare av virtuella skrivbord från en enda filresurs är det viktigt att testa dina arbetsbelastningar korrekt mot storleken och typen av filresurs som du använder. Dina krav varierar beroende på antal användare och profilstorlek.
Virtuella skrivbord med hemkataloger kan dra nytta av cachelagring av metadata på SSD-filresurser.
Autentisering och auktorisering
Du måste använda identitetsbaserad autentisering och tilldela rätt behörigheter och Azure RBAC-roller så att användarna kan få säker åtkomst till sin profil eller sitt program.
Du kan använda någon av följande tre identitetskällor för att autentisera användare för att få åtkomst till Azure-filresursen:
Lokal Active Directory Domain Services (AD DS): Det här alternativet kräver att användare av virtuella skrivbord har obehindrat nätverksanslutning till domänkontrollanter.
Microsoft Entra Kerberos (endast hybrididentiteter): Det här alternativet kräver en befintlig AD DS-distribution, som sedan synkroniseras med din Microsoft Entra-klientorganisation så att Microsoft Entra-ID kan autentisera dina hybrididentiteter. Det passar bra för arbetsbelastningar för virtuella skrivbord eftersom det inte kräver att användarna har obehindrat nätverksanslutning till domänkontrollanter. Med det här alternativet kan du lagra profiler som kan nås av hybridanvändaridentiteter från Microsoft Entra-anslutna eller Microsoft Entra-hybridanslutna sessionsvärdar.
Microsoft Entra Domain Services: Om du inte har en AD DS och behöver autentisera molnbaserade identiteter väljer du det här alternativet.
Information om hur du konfigurerar lagringsbehörigheter finns i Konfigurera SMB-lagringsbehörigheter för FSLogix.
Tillgänglighet och haveriberedskap
Innan du väljer en Azure-region för din virtuella skrivbordsarbetsbelastning bör du vara medveten om dess regionala efterlevnads- och datahemvistkrav.
Se till att använda ett lagringskonto som finns i samma Azure-region och resursgrupp som din Azure Virtual Desktop-värdpool.
En annan viktig faktor i valet av region är svarstiden. Det är vanligtvis bäst att centralisera alla nödvändiga virtuella skrivbordsresurser, inklusive användarprofiler, i samma Azure-region och prenumeration som din Azure Virtual Desktop-värdpool. Om du distribuerar filresurser i en region som är långt ifrån dina användare kan det öka svarstiden och försämra prestandan. Det kan också öka kostnaden för dataöverföring mellan regioner.
Azure Files erbjuder både HDD-filresurser (standard) och SSD-filresurser (premium). Tänk på att SSD Azure-filresurser inte erbjuder geo-redundans. Mer information om de olika redundansalternativen som är tillgängliga för Azure Files finns i Redundans i Azure Files .
Storleksvägledning för Azure Files för Azure Virtual Desktop
I storskaliga VDI-miljöer kan tiotusentals användare behöva komma åt samma fil samtidigt, särskilt under programstarter och sessionsinstallationer. I dessa situationer kan handtag ta slut, särskilt om du använder en Azure-fildelning. Det här avsnittet beskriver hur olika typer av diskbilder förbrukar handtag och ger storleksvägledning baserat på den teknik du använder.
Azure Files stöder både FSLogix- och icke-FSLogix-profillagringsscenarier. Den här vägledningen ger rekommenderade filresurskonfigurationer baserat på antalet samtidiga användare av virtuella skrivbord, förväntad IOPS per användare och lagringstyp (HDD eller SSD). I allmänhet möjliggör FSLogix effektivare hanteringsanvändning jämfört med icke-FSLogix.
Tips/Råd
Azure Files har för närvarande en gräns på 2 000 samtidiga handtag per fil och katalog, och den här artikeln är skriven med den gränsen i åtanke. För SSD-filresurser är detta dock en mjuk gräns. Om du behöver skala utöver den här gränsen kan du aktivera cachelagring av metadata och registrera dig för ökade filhandtagsgränser (förhandsversion).
FSLogix-profilcontainrar
If you’re using FSLogix with Azure Virtual Desktop, är dina användarprofilbehållare antingen Virtuell Hårddisk (VHD) eller Hyper-V Virtuell Hårddisk (VHDX) och de monteras i en användarkontext, inte en systemkontext. Varje användare öppnar ett enda rotkataloghandtag som ska gå till fillagringen. Azure Files kan stödja maximalt 10 000 användare förutsatt att du har filresursen (\\storageaccount.file.core.windows.net\sharename) + profildirektory (%sid%_%username%) + profilbehållare (profile_%username.vhd(x)).
Om du når gränsen på 10 000 samtidiga handtag för rotkatalogen eller om användarna upplever dålig prestanda, kan du prova att använda en ytterligare Azure-filresursandel och distribuera containrarna mellan filresursandelarna.
Om du till exempel har 2 400 samtidiga användare behöver du 2 400 referenser i rotkatalogen (en för varje användare), vilket är under gränsen på 10 000 öppna referenser. För FSLogix-användare är det osannolikt att gränsen för öppna fil- och kataloghandtag nås. Om du har en enda FSLogix-profilbehållare per användare, skulle du bara använda två fil-/kataloghandtag: ett för profilmappen och ett för profilbehållarfilen. Om användarna har två containrar vardera (profil och ODFC) behöver du ytterligare ett handtag för ODFC-filen.
I följande tabell visas våra allmänna rekommendationer för FSLogix-profilcontainrar baserat på antalet samtidiga användare under dessa förhållanden:
- Varje användare har 1–2 containrar (profil + valfri Office-container)
- Handtag: ~2–3 per användare (rotkatalog, profil och eventuellt ODFC-container)
| Antal samtidiga FSLogix-användare | Rekommenderad fillagring | Anteckningar |
|---|---|---|
| Mindre än 2 000 användare | HDD betala per användning eller tilldelade v2-fildelningar | Acceptabelt för lätta arbetsbelastningar eller låg samtidig användning |
| 2 000–5 000 användare | 1–2 SSD-fildelningar med cachelagring av metadata | SSD förbättrar inloggningsprestanda; antalet hanteringar ligger fortfarande långt under 10 000 per enhet. |
| 5 000–10 000 användare | 2–4 SSD-filresurser, jämnt fördelade | Aktier måste partitioneras korrekt |
| Fler än 10 000 användare | Flera SSD-fildelningar med cachelagring av metadata och ökade filhandtagsgränser (förhandsversion) | Registrera dig för ökade referensgränser och aktivera cachelagring av metadata för storskaliga miljöer |
Icke-FSLogix-profillagring
Om du inte använder FSLogix kanske du använder roamerade användarprofiler eller mappomdirigering i Windows.
Anmärkning
Icke-FSLogix-profiler har en högre benägenhet att nå gränsen av 2 000 samtidiga händelser per katalog eller per fil. Om du behöver skala över den här gränsen kan du använda SSD-filresurser, aktivera cachelagring av metadata och registrera dig för ökade filhandtagsgränser (förhandsversion).
I följande tabell visas våra allmänna rekommendationer för lagring av icke-FSLogix-profiler baserat på antalet samtidiga användare under dessa förhållanden:
- Profildata lagras som många små filer/mappar
- Högre metadata-IOPS per användare
- Handtagsanvändningen är relativt hög (varje fil/mapp som används förbrukar ett handtag)
- Profilstorlek ~5 GiB
- Högsta IOPS: 50 IOPS/användare under inloggning, 20 IOPS/användare under stabilt tillstånd
| Antal samtidiga användare | Rekommenderad fillagring | Anteckningar |
|---|---|---|
| Färre än 400 användare | HDD-fildelningstjänster med betalning per användning | Lämplig för arbetsbelastningar med låg samtidighet med minimala IOPS-krav |
| 400–1 000 användare | HDD-etablerade v2-fillagringar eller flera HDD-betala-per-användning-fillagringar | Kan kräva justering för toppinloggningstoppar |
| 1 000–2 000 användare | SSD eller flera HDD-fildelningar | SSD:erna rekommenderas på grund av bättre svarstid för metadata |
| Fler än 2 000 användare | Flera SSD-fildelningar med cachelagring av metadata och ökade filhandtagsgränser (förhandsversion) | Viktigt för att undvika att hantera gränser och uppnå konsekventa inloggningsprestanda |
Bifoga app
Om du använder MSIX App attach eller App attach för att dynamiskt bifoga program kan du använda CimFS-filer (Composite Image File System) eller VHD/VHDX-filer för diskbilder. Oavsett vilket är skalbegränsningarna per virtuell maskin som monterar bilden, inte per användare. Antalet användare är irrelevant när man beräknar gränser för skalan. När en virtuell dator startas monteras diskavbildningen, även om det inte finns några användare.
App-anslutning med CimFS
Om du använder App-anslutning med CimFS, konsumerar diskavbildningarna endast handtag på diskavbildningsfilerna. De använder inte handtag på rotkatalogen eller katalogen som innehåller diskavbildningen. Eftersom en CimFS-bild är en kombination av .cim-filen och minst två andra filer, behöver du för varje VM som monterar diskbilden ett handtag för tre filer i katalogen. Så om du har 100 virtuella maskiner, behöver du 300 filhandtag.
Du kan få slut på filhandtag om antalet virtuella datorer per app överstiger 2 000. I det här fallet använder du ytterligare en Azure-filresurs eller aktiverar cachelagring av metadata för SSD-filresurser och registrerar dig för ökade filhandtagsgränser (förhandsversion).
Appanslutning med VHD/VHDX
Om du använder App attach med VHD/VHDX-filer monteras filerna i en systemkontext, inte i en användarkontext, och de delas och är skrivskyddade. Mer än ett handtag på VHDX-filen kan användas av ett anslutande system. För att hålla sig inom Azure Files skalbegränsningar måste antalet VMs multiplicerat med antalet appar vara mindre än 10 000, och antalet VMs per app får inte överskrida 2 000. Så begränsningen är vilken du når först.
I det här scenariot kan du nå gränsen per fil/katalog med 2 000 monteringar av en enda VHD/VHDX. Om delningen innehåller flera VHD/VHDX-filer kan du först stöta på kataloggränsen för rotmappen. För exempel, 100 VMs som monterar 100 delade VHDX-filer kommer att nå gränsen för 10,000 handtagsrotkatalog.
I ett annat exempel kräver 100 virtuella maskiner som använder 20 appar 2 000 handtag för rotkataloger (100 x 20 = 2 000), vilket ligger väl inom gränsen på 10 000 handtag för rotkataloger. Du behöver också ett filhandtag och ett katalog-/mapphandtag för varje virtuell dator som monterar VHD(X)-avbildningen, så 200 handtag i det här fallet (100 filhandtag + 100 kataloghandtag), vilket bekvämt ligger under gränsen på 2 000 handtag per fil/katalog.
Om du når gränserna för maximala samtidiga handtag för rotkatalogen, använd en ytterligare Azure-fildelning.
Om du når gränserna för maximala samtidiga referenser per fil/katalog använder du ytterligare en Azure-filresurs eller aktiverar cachelagring av metadata för SSD-filresurser och registrerar dig för ökade filhandtagsgränser (förhandsversion)..