Configuration Manager riktlinjer för webbplatsstorlek och prestanda
Gäller för: Konfigurationshanteraren (current branch)
Configuration Manager leder branschen i skala och prestanda. Annan dokumentation omfattar maximala skalningsgränser som stöds och maskinvaruriktlinjer för att köra platser i de största miljöstorlekarna. Den här artikeln ger kompletterande prestandavägledning för miljöer av alla storlekar. Den här vägledningen kan hjälpa dig att mer exakt uppskatta vilken maskinvara du behöver distribuera Configuration Manager.
Den här artikeln fokuserar på den största bidragsgivaren till Configuration Manager flaskhalsar för prestanda: undersystemet diskinmatning/utdata eller IOPS.
- Presenterar information och testresultat som fokuserar på IOPS
- Dokument om hur du återskapar testerna med dina egna miljöer och maskinvara
- Föreslår disk-IOPS-krav för olika storleksmiljöer
Metodik för prestandatest
Du kan distribuera Configuration Manager på många unika sätt, men det är viktigt att förstå några variabler i alla storleksdiskussioner. En variabel är funktionsintervall, till exempel en inventeringscykel. En annan variabel är antalet användare, programvarudistributioner eller andra objekt som systemet refererar till eller distribuerar. Prestandatestning tillämpar dessa variabler som en del av en belastning. Belastningen genererar objekt i en typisk takt för företagskunder som använder produktionsdistributioner i olika storleksmiljöer.
Obs!
Med kundanvändningsdata kan du testa aktuella grenbyggen med de vanligaste scenarierna, konfigurationerna och inställningarna för de flesta kunder. Rekommendationerna i den här artikeln baseras på dessa medelvärden. Dina upplevelser kan variera beroende på din miljöstorlek och konfiguration. I allmänhet kräver Configuration Manager sunt förnuft när det gäller objekt och intervall. Bara för att du kan samla in alla filer i ett system, eller ange intervallet för en cykel till en minut, betyder det inte att du bör göra det.
I följande avsnitt beskrivs några viktiga inställningar och konfigurationer som ska användas vid testning och modellering av bearbetningsbehov för stora företag. De här riktlinjerna hjälper dig att ange grundläggande systemprestandaförväntningar för de föreslagna maskinvarustorlekarna.
Inställningar för funktionsintervall
De flesta tester bör använda standardintervall för nyckelcyklerna i systemet. Maskinvaruinventeringstestning sker till exempel en gång i veckan med en .mof-fil som är större än standardvärdet. Vissa återkommande funktionsintervall, särskilt maskin- och programvaruinventeringscykler, kan ha betydande effekter på en miljös prestandaegenskaper. Miljöer som möjliggör aggressiva standardintervall för datainsamling behöver överdimensionerad maskinvara i direkt proportion till ökningen av aktiviteten. Anta till exempel att du har 25 000 skrivbordsklienter och vill samla in maskinvaruinventering två gånger snabbare än standardintervallet. Börja med att ändra storleken på webbplatsens maskinvara som om du hade 50 000 klienter.
Objekt
Tester bör använda det övre genomsnittet av de objekt som stora företag tenderar att använda med systemet. Typiska värden är tusentals samlingar och program som distribueras till hundratusentals användare eller system. Testerna bör köras samtidigt på alla objekt i systemet vid dessa gränser. Många kunder använder flera funktioner, men använder vanligtvis inte alla funktioner i produkten vid dessa övre gränser. Genom att testa med alla produktfunktioner får du bästa möjliga systemomfattande prestanda och ger en buffert för funktioner som vissa kunder kan använda över genomsnittet.
Massor
Tester bör också köras på större än standard genomsnittlig dagbelastning genom att göra simuleringar som genererar högsta användningskrav på systemet. Ett exempel är att simulera Patch Tuesday-distributioner för att se till att systemet snabbt kan returnera uppdateringsefterlevnadsdata under dessa dagar med hög aktivitet. Ett annat exempel är att simulera webbplatsaktivitet under ett omfattande utbrott av skadlig kod för att säkerställa att meddelanden och svar i tid är möjliga. Även om distribuerade datorer av den rekommenderade storleken kan vara underanvända en viss dag, kräver mer extrema situationer viss bearbetningsbuffert.
Konfigurationer
Kör testning på en rad fysiska maskinvara, Hyper-V och Azure-maskinvara, med en blandning av operativsystem som stöds och SQL Server versioner. Verifiera alltid de värsta fallen för konfigurationen som stöds. I allmänhet returnerar Hyper-V och Azure jämförbara prestandaresultat till motsvarande fysisk maskinvara när de konfigureras på liknande sätt. Aktuella serveroperativsystem tenderar att ha prestanda som är lika med eller bättre än tidigare operativsystemversioner. Alla plattformar som stöds uppfyller minimikraven, men vanligtvis ger de senaste versionerna av stödjande produkter som Windows och SQL Server ännu bättre prestanda.
Den största varianten kommer från de SQL Server versioner som används. Mer information om SQL Server versioner finns i Vilken version av SQL Server ska jag köra?.
Viktiga prestandabestämningsfaktorer
Du kan testa och mäta Configuration Manager prestanda med olika typer av inställningar, på olika sätt och i olika platsstorlekar. Följande inställningar och objekt kan påverka prestanda avsevärt. Tänk på dem när du testar och modellerar prestanda i din miljö.
Försiktighet
Även om få aspekter av Configuration Manager har officiella maxgränser eller gränser för användargränssnittet som förhindrar överdriven användning, kan det få betydande negativa effekter på en webbplats prestanda om man går längre än riktlinjerna. Att överskrida rekommenderade nivåer eller ignorera storleksvägledning kräver vanligtvis större maskinvara och kan göra din miljö ouppnåelig tills du minskar frekvensen eller antalet olika objekt.
Maskinvaruinventering
Om du vill testa baslinjeprestanda anger du insamling av maskinvaruinventering till en gång i veckan, med standardstorleken för .mof-filen plus cirka 20 % andra egenskaper. Aktivera inte alla egenskaper och samla bara in egenskaper som du faktiskt behöver. Var särskilt uppmärksam när du samlar in egenskaper, till exempel tillgängligt virtuellt minne, som alltid ändras för varje inventeringscykel. Om du samlar in dessa egenskaper kan det orsaka överdriven omsättning för varje inventeringscykel från varje klient.
Programvaruinventering
Om du vill testa baslinjeprestanda anger du insamling av programvaruinventering till en gång i veckan, med endast produktinformation . Insamling av många filer kan innebära en betydande belastning på inventeringsundersystemet. Undvik att ange filter som kan samla in tusentals filer på många klienter, till exempel *.exe eller *.dll.
Samlingar
Prestandatestning av baslinje kan innehålla flera tusen samlingar med olika typer av omfång, storlek, komplexitet och uppdateringsinställningar. Webbplatsprestanda är inte en direkt funktion av det omfattande antalet samlingar på en webbplats. Prestanda är också en korsprodukt av samlingarnas frågekomplexitet, fullständiga och inkrementella uppdateringar och ändringsfrekvens, beroenden mellan samlingar och antal klienter i samlingarna.
Om möjligt minimerar du samlingar som har dyra eller komplicerade dynamiska regelfrågor. För samlingar som kräver dessa typer av regler anger du lämpliga uppdateringsintervall och uppdateringstider för att minimera effekten av omvärdering av samlingen i systemet. Uppdatera till exempel vid midnatt i stället för 08:00.
Aktivering av inkrementella uppdateringar av samlingar garanterar snabba och snabba uppdateringar av samlingsmedlemskap. Men även om inkrementella uppdateringar är effektiva lägger de fortfarande belastningen på systemet. Balansera den ändringsfrekvens du förväntar dig med behovet av uppdateringar i nära realtid för medlemskap. Anta till exempel att du förväntar dig stora omsättningar i samlingsmedlemmar, men att du inte behöver medlemskapsuppdateringar i nära realtid. Det är mer effektivt och ger mindre belastning på systemet för att uppdatera samlingen med en schemalagd fullständig uppdatering vid något intervall, än för att aktivera inkrementella uppdateringar.
När du aktiverar inkrementella uppdateringar kan du minska alla schemalagda fullständiga uppdateringar i samma samlingar. De är bara en säkerhetskopieringsmetod för utvärdering, eftersom inkrementella uppdateringar bör hålla ditt samlingsmedlemskap uppdaterat nästan i realtid. Metodtips för samlingar rekommenderar ett maximalt antal samlingar för inkrementella uppdateringar, men som artikeln påpekar kan din upplevelse variera beroende på många faktorer.
Samlingar med endast regler för direkt medlemskap och med en begränsande samling som inte gör inkrementella uppdateringar behöver inte schemalagda fullständiga uppdateringar. Inaktivera uppdateringsscheman för dessa typer av samlingar för att förhindra onödig belastning på systemet. Om den begränsande samlingen använder inkrementella uppdateringar kan samlingar med endast regler för direkt medlemskap inte återspegla medlemskapsuppdateringar i upp till 24 timmar eller tills en schemalagd uppdatering äger rum.
Även om det inte är bästa praxis skapar vissa organisationer hundratals eller till och med tusentals samlingar som en del av olika affärsprocesser. Om du använder automatisering för att skapa samlingar är det viktigt att aktivera nödvändiga inkrementella uppdateringar korrekt. Minimera och sprida ut alla fullständiga uppdateringsscheman för att undvika frekventa platser för insamlingsutvärdering under en enda tidsperiod. Upprätta en regelbunden rensningsprocess för att ta bort oanvända samlingar, särskilt om du automatiskt skapar samlingar som du inte längre behöver efter en viss tid.
Kom ihåg att Configuration Manager skapar principer för alla objekt i dina samlingar när du riktar uppgifter som distributioner till dem. Medlemskapsändringar, antingen via schemalagd uppdatering eller inkrementella uppdateringar, kan skapa mycket mer arbete för hela systemet. De senaste aktuella grenbyggena har särskilda principoptimeringar för samlingarna Alla system och Alla användare. När du riktar in dig på hela företaget använder du de inbyggda samlingarna i stället för en klon av dessa inbyggda samlingar.
Om du vill undersöka insamlingsprestandan ännu djupare kan du visa samlingsutvärderingen i -konsolen. Mer information finns i Så här visar du samlingsutvärdering.
Identifieringsmetoder
För testning av baslinjeprestanda kör du serverbaserade identifieringsmetoder en gång i veckan och aktiverar deltaidentifiering efter behov för att hålla data uppdaterade under veckan. Testerna bör identifiera en objektkvantitet som är proportionell mot den simulerade företagsstorleken. Prestandabaslinjetestet för pulsslagsidentifiering bör också köras en gång i veckan.
Identifieringsdata är globala data. Ett vanligt prestandarelaterat problem är att felkonfigurera serverbaserade identifieringsmetoder i en hierarki, vilket orsakar dubblettidentifiering av samma resurser från flera primära platser. Konfigurera identifieringsmetoder noggrant för att optimera kommunikationen med måltjänsten, till exempel Active Directory-domänkontrollanter, samtidigt som du undviker duplicering av samma identifieringsomfång på flera primära platser.
Allmänna riktlinjer för storleksändring
Baserat på föregående metod för prestandatest ger följande tabell allmänna riktlinjer för minimikrav på maskinvara för specifika antal hanterade klienter. Dessa värden bör göra det möjligt för de flesta kunder med det angivna antalet klienter att bearbeta objekt tillräckligt snabbt för att administrera den angivna platsen. Datorkraften fortsätter att minska i pris varje år, och vissa av kraven nedan är små för moderna servermaskinvarukonfigurationer. Maskinvara som överskrider följande riktlinjer ökar proportionellt prestandan för webbplatser som kräver mer bearbetningskraft eller har särskilda produktanvändningsmönster.
| Skrivbordsklienter | Webbplatstyp/roll | Kärnor , anmärkning 1 | Minne (GB) | SQL Server minnesallokering Anmärkning 2 | IOPS: Inkorgar Anmärkning 3 | IOPS: SQL Server anmärkning 3 | Lagringsutrymme som krävs (GB) Anmärkning 4 |
|---|---|---|---|---|---|---|---|
| 25k | Primär eller CAS med databasplatsroll på samma server | 6 | 24 | 65% | 600 | 1700 | 350 |
| 25k | Primär eller CAS | 4 | 8 | 600 | 100 | ||
| Fjärr-SQL Server | 4 | 16 | 70% | 1700 | 250 | ||
| 50k | Primär eller CAS med databasplatsroll på samma server | 8 | 32 | 70% | 1200 | 2800 | 600 |
| 50k | Primär eller CAS | 4 | 8 | 1200 | 200 | ||
| Fjärr-SQL Server | 8 | 24 | 70% | 2800 | 400 | ||
| 100k | Primär eller CAS med databasplatsroll på samma server | 12 | 64 | 70% | 1200 | 5000 | 1100 |
| 100k | Primär eller CAS | 6 | 12 | 1200 | 300 | ||
| Fjärr-SQL Server | 12 | 48 | 80% | 5000 | 800 | ||
| 150k | Primär eller CAS med databasplatsroll på samma server | 16 | 96 | 70% | 1800 | 7400 | 1600 |
| 150k | Primär eller CAS | 8 | 16 | 1800 | 400 | ||
| Fjärr-SQL Server | 16 | 72 | 90% | 7400 | 1200 | ||
| 700k | CAS med databasplatsroll på samma server | 20+ | 128+ | 80% | 1800+ | 9000+ | 5000+ |
| 700k | Cas | 8+ | 16+ | 1800+ | 500+ | ||
| Fjärr-SQL Server | 16+ | 96+ | 90% | 9000+ | 4500+ | ||
| 5k | Sekundär plats | 4 | 8 | 500 | - | 200 | |
| 15k | Sekundär plats | 8 | 16 | 500 | - | 300 |
Anmärkningar om allmänna riktlinjer för storleksändring
Anmärkning 1: Kärnor
Configuration Manager kör många samtidiga processer, så behöver ett visst minsta antal CPU-kärnor för olika platsstorlekar. Även om kärnorna blir snabbare varje år är det viktigt att se till att ett visst minsta antal kärnor fungerar parallellt. I allmänhet uppfyller alla processorer på servernivå som produceras efter 2015 de grundläggande prestandabehoven för kärnorna som anges i tabellen. Configuration Manager utnyttjar andra kärnor utöver rekommendationerna. När du har minsta föreslagna kärnor prioriterar du cpu-resursinvesteringar för att öka hastigheten för befintliga kärnor. Lägg inte till fler, långsammare kärnor. Till exempel har Configuration Manager bättre prestanda för nyckelbearbetningsuppgifter med 16 snabba kärnor än med 24 långsammare kärnor. Den här prestandan förutsätter att det finns tillräckligt med andra systemresurser som disk-IOPS.
Relationen mellan kärnor och minne är också viktig. Att ha mindre än 3–4 GB RAM per kärna minskar i allmänhet den totala bearbetningskapaciteten på dina SQL-servrar. Du behöver mer RAM-minne per kärna när SQL Server samplaceeras med platsserverkomponenterna.
Obs!
Alla tester anger datorkraftsplaner för att tillåta maximal cpu-strömförbrukning och prestanda.
Anmärkning 2: SQL Server minnesallokering
Använd det här värdet för att konfigurera Maximalt serverminne (i MB) i egenskaperna för SQL Server. Det är procentandelen av den totala mängden minne som är tillgängligt på servern.
Konfigurera inte minimi- och maxvärdena på samma sätt. Den här vägledningen är specifikt för det maximala minne som du bör tillåta SQL Server allokera.
Anmärkning 3: IOPS: Inkorgar och IOPS: SQL
Dessa värden refererar till IOPS-behoven för Configuration Manager och SQL Server logiska enheter. Kolumnen IOPS: Inkorgar visar IOPS-kraven för den logiska enheten med Configuration Manager inkorgskataloger. Kolumnen IOPS: SQL visar det totala antalet IOPS-behov för de logiska enheter som olika SQL Server filer använder. Dessa kolumner är olika eftersom de två enheterna bör ha olika formatering. Mer information och exempel på föreslagna SQL Server diskkonfigurationer och metodtips för filer, inklusive information om att dela upp filer över flera volymer, finns i vanliga frågor och svar om webbplatsstorlek och prestanda.
Båda dessa IOPS-kolumner använder data från branschstandardverktyget Diskspd. Se Så här mäter du diskprestanda för instruktioner om hur du duplicerar dessa mått. I allmänhet, när du uppfyller grundläggande processor- och minneskrav, har underlagringssystemet störst inverkan på webbplatsens prestanda, och förbättringar här ger mest återbetalning för investeringar.
Obs! 4: Lagringsutrymme krävs
Dessa verkliga värden kan skilja sig från andra dokumenterade rekommendationer. Vi tillhandahåller endast dessa siffror som en allmän riktlinje. individuella krav kan variera kraftigt. Planera noggrant för diskutrymmesbehov före platsinstallationen. Anta att en del av det här lagringsutrymmet förblir som ledigt diskutrymme för det mesta. Du kan använda det här buffertutrymmet i ett återställningsscenario eller för uppgraderingsscenarier som behöver ledigt diskutrymme för paketexpansion. Din webbplats kan kräva mer lagring för stora mängder datainsamling, längre perioder av datakvarhållning och stora mängder programdistributionsinnehåll. Du kan också lagra dessa objekt på separata volymer med lägre dataflöde.
Mäta diskprestanda
Du kan använda branschstandardverktyget Diskspd för att ge standardiserade förslag på den IOPS som Configuration Manager miljöer i olika storlekar kräver. Även om de inte är uttömmande är följande teststeg och kommandorader ett enkelt och reproducerbart sätt att beräkna servrarnas dataflöde för diskundersystemet. Du kan jämföra dina resultat med den lägsta rekommenderade IOPS i tabellen med allmänna riktlinjer för storleksändring .
Testresultat från olika typer av maskinvarukonfigurationer i labbmiljöer finns i Exempel på diskkonfigurationer. Du kan använda data för en grov startpunkt när du utformar underlagringssystemet för en ny miljö från grunden.
Så här testar du disk-IOPS
Ladda ned diskspd-verktyget.
Kontrollera att du har minst 100 GB ledigt diskutrymme. Inaktivera appar som kan störa eller orsaka extra belastning på disken, till exempel aktiv antivirusgenomsökning av katalogen, SQL eller SMSExec.
Kör Diskspd från en upphöjd kommandotolk.
Kör verktyget två gånger i följd för den volym som du vill testa. Det första testet med en storlek på 64 000 med slumpmässiga skrivåtgärder i en minut. Det här testet validerar inläsning av kontrollantcache och diskutrymmesallokering, om volymen expanderas dynamiskt. Ignorera resultatet av det första testet. Det andra testet bör omedelbart följa det första testet och utföra samma belastning i fem minuter.
Använd till exempel följande specifika kommandorader för att testa
G:volymen.DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d60 -h -L G:\\test\testfile.dat del G:\\test\testfile.dat DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d300 -h -L G:\\test\testfile.datGranska utdata från det andra testet för att hitta det totala antalet IOPS i kolumnen I/O per s . I följande exempel är det totala antalet IOPS 3929,18.
Total IO | thread | bytes | I/Os | MB/s | I/O per s | AvgLat | LatStdDev | |--------|-------------|---------|--------|-----------|--------|-----------| | 1 | 9651814400 | 147275 | 30.68 | 490.92 | 16.294 | 10.210 | | 2 | 9676652544 | 147654 | 30.76 | 492.18 | 16.252 | 9.998 | | 3 | 9638248448 | 147068 | 30.64 | 490.23 | 16.317 | 10.295 | | 4 | 9686089728 | 147798 | 30.79 | 492.66 | 16.236 | 10.072 | | 5 | 9590931456 | 146346 | 30.49 | 487.82 | 16.398 | 10.384 | | 6 | 9677242368 | 147663 | 30.76 | 492.21 | 16.251 | 10.067 | | 7 | 9637330944 | 147054 | 30.64 | 490.18 | 16.319 | 10.249 | | 8 | 9692577792 | 147897 | 30.81 | 492.99 | 16.225 | 10.125 | | Total: | 77250887680 | 1178755 | 245.57 | 3929.18 | 16.286 | 10.176 |
Exempel på diskkonfigurationer
Följande tabeller visar resultat från körningen av teststegen i Så här mäter du diskprestanda med olika testlabbkonfigurationer. Använd dessa data för en grov startpunkt när du utformar underlagringssystemet för en ny miljö från grunden.
Fysiska datorer och Hyper-V
Maskinvaran förbättras alltid. Förvänta dig att nyare generationer av maskinvara och olika maskinvarukombinationer, till exempel SSD och SAN, överskrider de prestanda som anges nedan. Dessa resultat är en grundläggande utgångspunkt att tänka på när du utformar en server eller diskuterar med din maskinvaruleverantör.
I följande tabell visas testresultaten för olika diskundersystem, inklusive spindle- och SSD-baserade hårddiskar, i olika testlabbkonfigurationer. Alla konfigurationer formaterar diskarna med 64k-kluster och ansluter dem till en diskkontrollant i företagsklass. Förutom antalet RAID-matrisdiskar har de minst en extra disk.
| Disktyp | Antal diskar, inklusive +1 reservdisk | RAID | Uppmätt IOPS |
|---|---|---|---|
| 15k SAS | 2 | 1 | 620 |
| 15k SAS | 4 | 10 | 1206 |
| 15k SAS | 6 | 10 | 1751 |
| 15k SAS | 8 | 10 | 2322 |
| 15k SAS | 10 | 10 | 2882 |
| 15k SAS | 12 | 10 | 3476 |
| 15k SAS | 16 | 10 | 4236 |
| 15k SAS | 20 | 10 | 5148 |
| 15k SAS | 30 | 10 | 7398 |
| 15k SAS | 40 | 10 | 9913 |
| SSD SATA | 2 | 1 | 3300 |
| SSD SATA | 4 | 10 | 5542 |
| SSD SATA | 6 | 10 | 7201 |
| SSD SAS | 2 | 1 | 7539 |
| SSD SAS | 4 | 10 | 14346 |
| SSD SAS | 6 | 10 | 15607 |
I följande tabell visas de specifika enheter som används i det här exemplet. Den här informationen är inte en rekommendation för någon specifik maskinvarumodell eller tillverkare.
| Disktyp | Modell | RAID-styrenhet | Cacheminne och konfiguration |
|---|---|---|---|
| 15k RPM SAS HD | HP EH0300JDYTH | Smart matris P822 | 2 GB, 20 % läs/ 80 % skrivning |
| SSD SATA | ATA MK0200GCTYV | Smart matris P420i | 1 GB, 20 % läs/ 80 % skrivning |
| SSD SAS | HP MO0800 JEFPB | Smart matris P420i | 1 GB, 20 % läs/ 80 % skrivning |
Prestanda för Azure-datorer och diskar
Prestanda för Azure-diskar beror på flera faktorer, till exempel storleken på den virtuella Azure-datorn och antalet och typen av diskar som används. Azure lägger också ständigt till nya datortyper och diskhastigheter som skiljer sig från följande diagram. Mer information om Configuration Manager som körs i Azure och mer information om hur du förstår disk-I/O i Azure finns i Configuration Manager på vanliga frågor och svar om Azure.
Alla diskar är formaterade NTFS 64k klusterstorlek, och rader med mer än en disk konfigureras som randiga volymer via Windows Disk Management-verktyget.
| Virtuell Azure-dator | Azure-disk | Antal diskar | Tillgängligt utrymme | Uppmätt IOPS | Begränsningsfaktor |
|---|---|---|---|---|---|
| DS2/DS11 | P20 | 1 | 512 GB | 965 | Storlek på virtuella Azure-datorer |
| DS2/DS11 | P20 | 2 | 1 024 GB | 996 | Storlek på virtuella Azure-datorer |
| DS2/DS11 | P30 | 1 | 1 024 GB | 996 | Storlek på virtuella Azure-datorer |
| DS2/DS11 | P30 | 2 | 2 048 GB | 996 | Storlek på virtuella Azure-datorer |
| DS3/DS12/F4S | P20 | 1 | 512 GB | 1994 | Storlek på virtuella Azure-datorer |
| DS3/DS12/F4S | P20 | 2 | 1 024 GB | 1992 | Storlek på virtuella Azure-datorer |
| DS3/DS12/F4S | P30 | 1 | 1 024 GB | 1993 | Storlek på virtuella Azure-datorer |
| DS3/DS12/F4S | P30 | 2 | 2 048 GB | 1992 | Storlek på virtuella Azure-datorer |
| DS4/DS13/F8S | P20 | 1 | 512 GB | 2334 | P20-disk |
| DS4/DS13/F8S | P20 | 2 | 1 024 GB | 3984 | Storlek på virtuella Azure-datorer |
| DS4/DS13/F8S | P20 | 3 | 1536 GB | 3984 | Storlek på virtuella Azure-datorer |
| DS4/DS13/F8S | P30 | 1 | 1 024 GB | 3112 | P30-disk |
| DS4/DS13/F8S | P30 | 2 | 2 048 GB | 3984 | Storlek på virtuella Azure-datorer |
| DS4/DS13/F8S | P30 | 3 | 3 072 GB | 3996 | Storlek på virtuella Azure-datorer |
| DS5/DS14/F16S | P20 | 1 | 512 GB | 2335 | P20-disk |
| DS5/DS14/F16S | P20 | 2 | 1 024 GB | 4639 | P20-disk |
| DS5/DS14/F16S | P20 | 3 | 1536 GB | 6913 | P20-disk |
| DS5/DS14/F16S | P20 | 4 | 2 048 GB | 7966 | Storlek på virtuella Azure-datorer |
| DS5/DS14/F16S | P30 | 1 | 1 024 GB | 3112 | P30-disk |
| DS5/DS14/F16S | P30 | 2 | 2 048 GB | 6182 | P30-disk |
| DS5/DS14/F16S | P30 | 3 | 3 072 GB | 7963 | Storlek på virtuella Azure-datorer |
| DS5/DS14/F16S | P30 | 4 | 4 096 GB | 7968 | Storlek på virtuella Azure-datorer |
| DS15 | P30 | 1 | 1 024 GB | 3113 | P30-disk |
| DS15 | P30 | 2 | 2 048 GB | 6184 | P30-disk |
| DS15 | P30 | 3 | 3 072 GB | 9225 | P30-disk |
| DS15 | P30 | 4 | 4 096 GB | 10200 | Storlek på virtuella Azure-datorer |
Mer information om tillgängliga diskar finns i Välj en disktyp för virtuella Azure IaaS-datorer.