Configuration Manager pokyny k velikosti a výkonu webu
Platí pro: Configuration Manager (Current Branch)
Configuration Manager vede v oboru v oblasti škálování a výkonu. Další dokumentace se zabývá maximálními podporovanými limity škálování a pokyny pro hardware pro spouštění lokalit v největších velikostech prostředí. Tento článek obsahuje doplňkové pokyny k výkonu pro prostředí všech velikostí. Tyto doprovodné materiály vám můžou pomoct přesněji odhadnout hardware, který potřebujete k nasazení Configuration Manager.
Tento článek se zaměřuje na největšího přispěvatele Configuration Manager kritických bodů výkonu: vstupní/výstupní subsystém disku nebo IOPS.
- Zobrazuje podrobnosti a výsledky testů zaměřené na IOPS.
- Dokumentuje, jak reprodukovat testy pomocí vlastního prostředí a hardwaru.
- Navrhuje požadavky na IOPS disku pro různá prostředí velikosti.
Metodologie testování výkonnosti
Configuration Manager můžete nasadit mnoha jedinečnými způsoby, ale je důležité pochopit několik proměnných v jakékoli diskuzi o velikosti. Jednou z proměnných je interval funkce, například inventarizační cyklus. Další proměnnou je počet uživatelů, nasazení softwaru nebo jiných objektů , na které systém odkazuje nebo nasazuje. Testování výkonnosti používá tyto proměnné jako součást zatížení. Zatížení generuje objekty obvyklou rychlostí pro podnikové zákazníky, kteří používají produkční nasazení v prostředích různých velikostí.
Poznámka
Data o využití zákazníků umožňují testovat sestavení aktuálních větví s nejběžnějšími scénáři, konfiguracemi a nastaveními pro většinu zákazníků. Doporučení v tomto článku vycházejí z těchto průměrů. Vaše prostředí se může lišit v závislosti na velikosti a konfiguraci vašeho prostředí. Obecně platí, že Configuration Manager vyžaduje zdravý rozum, pokud jde o objekty a intervaly. To, že můžete shromáždit každý soubor v systému nebo nastavit interval cyklu na jednu minutu, neznamená, že byste měli.
Následující části zvýrazňují některá klíčová nastavení a konfigurace, které se mají použít při testování a modelování potřeb zpracování pro velké podniky. Tyto pokyny pomáhají nastavit základní očekávání výkonu systému pro navrhované velikosti hardwaru.
Nastavení intervalů funkcí
Většina testování by měla používat výchozí intervaly pro klíčové cykly v systému. Například testování inventáře hardwaru probíhá jednou týdně s větším než výchozím souborem .mof . Některé opakující se intervaly funkcí, zejména cykly inventáře hardwaru a softwaru, můžou mít významný vliv na charakteristiky výkonu prostředí. Prostředí, která umožňují agresivní výchozí intervaly pro shromažďování dat, potřebují nadměrně vysoký hardware v přímém poměru k nárůstu aktivity. Řekněme například, že máte 25 000 desktopových klientů a chcete shromažďovat inventář hardwaru dvakrát rychleji, než je výchozí interval. Začněte nastavením velikosti hardwaru lokality, jako byste měli 50 000 klientů.
Objekty
Testy by měly používat horní průměr objektů, které velké podniky obvykle používají se systémem. Typické hodnoty jsou tisíce kolekcí a aplikací, které jsou nasazené pro stovky tisíc uživatelů nebo systémů. Testy by se měly spouštět současně na všech objektech v systému s těmito limity. Mnoho zákazníků používá několik funkcí, ale obecně nepoužívají všechny funkce produktu s těmito horními limity. Testování se všemi funkcemi produktu pomáhá zajistit nejlepší možný výkon celého systému a umožňuje vyrovnávací paměť pro funkce, které můžou někteří zákazníci používat nadprůměrně.
Načte
Testy by také měly běžet při větším než standardním průměrném denním zatížení pomocí simulací, které generují požadavky na využití ve špičce v systému. Jedním z příkladů je simulace zavedení oprav v úterý, aby se zajistilo, že systém může okamžitě vrátit data o dodržování předpisů aktualizací během těchto dnů aktivity ve špičce. Dalším příkladem je simulace aktivity webu během rozsáhlého výskytu malwaru, aby se zajistilo, že bude možné včasné oznámení a reakce. I když nasazené počítače s doporučenou velikostí můžou být v daný den nevyužité, extrémní situace vyžadují určitou vyrovnávací paměť pro zpracování.
Konfigurace
Spusťte testování na řadě fyzických hardwarů, hardwaru Hyper-V a Azure se kombinací podporovaných operačních systémů a SQL Server verzí. Vždy ověřte nejhorší případy pro podporovanou konfiguraci. Obecně platí, že technologie Hyper-V a Azure vrací srovnatelné výsledky výkonu s ekvivalentním fyzickým hardwarem, pokud jsou nakonfigurované podobně. Aktuální serverové operační systémy mají tendenci mít výkon, který je stejný nebo vyšší než starší verze operačního systému. I když všechny podporované platformy splňují minimální požadavky, nejnovější verze podpůrných produktů, jako je Windows a SQL Server obvykle dosáhnout ještě lepšího výkonu.
Největší variace pochází z SQL Server verzí, které se používají. Další informace o SQL Server verzích najdete v tématu Jakou verzi SQL Server mám spustit?.
Klíčové determinanty výkonu
Výkon Configuration Manager můžete testovat a měřit pomocí různých typů nastavení, a to různými způsoby a v různých velikostech lokalit. Následující nastavení a objekty můžou výrazně ovlivnit výkon. Nezapomeňte je vzít v úvahu při testování a modelování výkonu ve vašem prostředí.
Pozor
I když několik aspektů Configuration Manager má oficiální maximální hodnoty nebo limity uživatelského rozhraní, které brání nadměrnému používání, překročení těchto pokynů může mít významný nepříznivý vliv na výkon webu. Překročení doporučených úrovní nebo ignorování pokynů pro určení velikosti obvykle vyžaduje větší hardware a může způsobit, že vaše prostředí nebude udržitelné, dokud nezmenšíte frekvenci nebo počet různých objektů.
Inventář hardwaru
Pokud chcete otestovat výkon standardních hodnot, nastavte shromažďování inventáře hardwaru jednou týdně s výchozí velikostí souboru .mof plus přibližně 20 % dalších vlastností. Nepovolujte všechny vlastnosti a shromažďujte jenom vlastnosti, které skutečně potřebujete. Věnujte zvláštní pozornost při shromažďování vlastností, jako je dostupná virtuální paměť, které se budou vždy měnit s každým cyklem inventáře. Shromažďování těchto vlastností může způsobit nadměrné četnosti změn v každém cyklu inventáře z každého klienta.
Inventář softwaru
Pokud chcete otestovat výkon standardních hodnot, nastavte shromažďování inventáře softwaru na jednou týdně s pouze podrobnostmi o produktu . Shromažďování mnoha souborů může výrazně zatížit subsystém inventáře. Vyhněte se zadávání filtrů, které by mohly skončit shromažďováním tisíců souborů napříč mnoha klienty, jako *.exe*.dllje nebo .
Sbírky
Základní testování výkonu může zahrnovat několik tisíc kolekcí s různými druhy rozsahu, velikosti, složitosti a nastavení aktualizací. Výkon webu není přímou funkcí velkého počtu kolekcí na webu. Výkon je také křížovým produktem složitosti dotazů kolekcí, úplných a přírůstkových aktualizací a četnosti změn, závislostí mezi kolekcemi a počtu klientů v kolekcích.
Pokud je to možné, minimalizujte kolekce, které mají nákladné nebo složité dotazy na dynamická pravidla. U kolekcí, které vyžadují tyto typy pravidel, nastavte odpovídající intervaly aktualizací a časy aktualizací, aby se minimalizoval vliv opětovného vyhodnocení kolekce na systém. Například aktualizujte o půlnoci místo 8:00.
Povolením přírůstkových aktualizací v kolekcích zajistíte rychlé a včasné aktualizace členství v kolekcích. Ale i když jsou přírůstkové aktualizace efektivní, stále zatěžují systém. Vyvažte očekávanou frekvenci změn s potřebou aktualizací členství téměř v reálném čase. Řekněme například, že očekáváte vysokou četnost změn členů kolekce, ale nevyžadujete aktualizace členství téměř v reálném čase. Aktualizace kolekce s naplánovanou úplnou aktualizací v určitém intervalu je efektivnější a vytváří menší zatížení systému než povolení přírůstkových aktualizací.
Když povolíte přírůstkové aktualizace, omezte všechny plánované úplné aktualizace ve stejných kolekcích. Jedná se pouze o záložní metodu vyhodnocení, protože přírůstkové aktualizace by měly udržovat vaše členství v kolekci aktualizované téměř v reálném čase. Osvědčené postupy pro kolekce doporučují maximální celkový počet kolekcí pro přírůstkové aktualizace, ale jak je uvedeno v článku, vaše prostředí se může lišit v závislosti na mnoha faktorech.
Kolekce s pouze pravidly přímého členství a s limitující kolekcí, která neprovádí přírůstkové aktualizace, nevyžadují plánované úplné aktualizace. Zakažte plány aktualizací pro tyto typy kolekcí, abyste zabránili zbytečnému zatížení systému. Pokud limitující kolekce používá přírůstkové aktualizace, nemusí kolekce s pouze přímými pravidly členství odrážet aktualizace členství po dobu až 24 hodin nebo dokud neprobíhá plánovaná aktualizace.
I když to není osvědčený postup, některé organizace vytvářejí stovky nebo dokonce tisíce kolekcí v rámci různých obchodních procesů. Pokud k vytváření kolekcí používáte automatizaci, je důležité správně povolit všechny potřebné přírůstkové aktualizace. Minimalizujte a rozprostřete všechny plány aktualizací, abyste se vyhnuli kritickým bodům při vyhodnocování kolekce během jednoho časového období. Vytvořte pravidelný proces výmazu dat k odstranění nepoužívaných kolekcí, zejména pokud po nějaké době automaticky vytváříte kolekce, které už nepotřebujete.
Nezapomeňte, že Configuration Manager vytváří zásady pro všechny objekty v kolekcích, když na ně cílíte na úlohy, jako jsou nasazení. Změny členství, ať už prostřednictvím plánované aktualizace nebo přírůstkových aktualizací, můžou pro celý systém vytvořit mnohem více práce. Nejnovější buildy aktuálních větví mají speciální optimalizace zásad pro kolekce Všechny systémy a Všichni uživatelé. Při cílení na celý podnik použijte předdefinované kolekce místo klonování těchto předdefinovaných kolekcí.
Pokud chcete výkon kolekce prozkoumat ještě hlouběji, podívejte se na vyhodnocení kolekce v konzole nástroje . Další informace najdete v tématu Postup zobrazení vyhodnocení kolekce.
Metody zjišťování
Pro účely testování výkonu podle směrného plánu spouštět jednou týdně serverové metody zjišťování, které podle potřeby umožňují zjišťování rozdílu, aby se data během týdne udržovala aktuální. Testy by měly zjistit množství objektů úměrné simulované velikosti organizace. Test standardních hodnot výkonu pro zjišťování prezenčních signálů by se měl spouštět také jednou týdně.
Data zjišťování jsou globální data. Běžným problémem souvisejícím s výkonem je nesprávná konfigurace serverových metod zjišťování v hierarchii, což způsobuje duplicitní zjišťování stejných prostředků z více primárních lokalit. Pečlivě nakonfigurujte metody zjišťování, které optimalizují komunikaci s cílovou službou, jako jsou řadiče domény služby Active Directory, a zároveň se vyhnete duplikování stejného oboru zjišťování ve více primárních lokalitách.
Obecné pokyny pro změnu velikosti
Na základě předchozí metodologie testování výkonnosti uvádí následující tabulka obecné pokyny k minimálním hardwarovým požadavkům pro konkrétní počet spravovaných klientů. Tyto hodnoty by měly umožnit většině zákazníků se zadaným počtem klientů zpracovávat objekty dostatečně rychle pro správu zadané lokality. Výpočetní výkon se každoročně stále snižuje a některé z níže uvedených požadavků jsou pro moderní konfigurace hardwaru serveru malé. Hardware, který překračuje následující pokyny, proporcionálně zvyšuje výkon pro weby, které vyžadují vyšší výpočetní výkon nebo mají zvláštní vzory používání produktů.
| Desktopoví klienti | Typ nebo role webu | Jádra – poznámka 1 | Paměť (GB) | SQL Server přidělení paměti – poznámka 2 | IOPS: Doručená pošta – poznámka 3 | IOPS: SQL Server Poznámka 3 | Požadovaný prostor úložiště (GB) – poznámka 4 |
|---|---|---|---|---|---|---|---|
| 25 tisíc | Primární server nebo cas s rolí databázové lokality na stejném serveru | 6 | 24 | 65% | 600 | 1700 | 350 |
| 25 tisíc | Primární nebo CAS | 4 | 8 | 600 | 100 | ||
| Vzdálené SQL Server | 4 | 16 | 70% | 1700 | 250 | ||
| 50 tisíc | Primární server nebo cas s rolí databázové lokality na stejném serveru | 8 | 32 | 70% | 1200 | 2800 | 600 |
| 50 tisíc | Primární nebo CAS | 4 | 8 | 1200 | 200 | ||
| Vzdálené SQL Server | 8 | 24 | 70% | 2800 | 400 | ||
| 100 tisíc | Primární server nebo cas s rolí databázové lokality na stejném serveru | 12 | 64 | 70% | 1200 | 5000 | 1100 |
| 100 tisíc | Primární nebo CAS | 6 | 12 | 1200 | 300 | ||
| Vzdálené SQL Server | 12 | 48 | 80% | 5000 | 800 | ||
| 150 tisíc | Primární server nebo cas s rolí databázové lokality na stejném serveru | 16 | 96 | 70% | 1800 | 7400 | 1600 |
| 150 tisíc | Primární nebo CAS | 8 | 16 | 1800 | 400 | ||
| Vzdálené SQL Server | 16 | 72 | 90% | 7400 | 1200 | ||
| 700 tisíc | CAS s rolí lokality databáze na stejném serveru | 20+ | 128+ | 80% | 1800+ | 9000+ | 5000+ |
| 700 tisíc | Cas | 8+ | 16+ | 1800+ | 500+ | ||
| Vzdálené SQL Server | 16+ | 96+ | 90% | 9000+ | 4500+ | ||
| 5k | Sekundární lokalita | 4 | 8 | 500 | - | 200 | |
| 15 tisíc | Sekundární lokalita | 8 | 16 | 500 | - | 300 |
Poznámky k obecným pokynům pro změnu velikosti
Poznámka 1: Jádra
Configuration Manager spouští mnoho souběžných procesů, takže potřebuje určitý minimální počet jader procesoru pro různé velikosti lokality. I když jsou jádra každý rok rychlejší, je důležité zajistit, aby paralelně fungoval určitý minimální počet jader. Obecně platí, že jakýkoli procesor na úrovni serveru vytvořený po roce 2015 splňuje základní požadavky na výkon jader uvedených v tabulce. Configuration Manager využívá další jádra nad rámec doporučení. Jakmile budete mít minimální počet navrhovaných jader, upřednostněte investice do prostředků procesoru, abyste zvýšili rychlost stávajících jader. Nepřidávejte další pomalejší jádra. Například Configuration Manager má lepší výkon při úlohách zpracování klíčů se 16 rychlými jádry než s 24 pomalejšími jádry. Tento výkon předpokládá, že existuje dostatek dalších systémových prostředků, jako je disk IOPS.
Důležitý je také vztah mezi jádry a pamětí. Obecně platí, že méně než 3 až 4 GB paměti RAM na jádro snižuje celkovou kapacitu zpracování na SQL Serverech. Pokud je SQL Server společně s komponentami serveru lokality, potřebujete více paměti RAM na jádro.
Poznámka
Všechna testování nastaví schémata napájení počítače tak, aby umožňovala maximální spotřebu procesoru a výkon.
Poznámka 2: SQL Server přidělení paměti
Tuto hodnotu použijte ke konfiguraci maximální paměti serveru (v MB) ve vlastnostech SQL Server. Jedná se o procento z celkového množství paměti dostupné na serveru.
Nenakonfigurujte minimální a maximální hodnotu stejně. Tyto pokyny se konkrétně týká maximální paměti, kterou byste měli SQL Server povolit.
Poznámka 3: IOPS: Doručená pošta a IOPS: SQL
Tyto hodnoty odkazují na potřeby IOPS pro Configuration Manager a SQL Server logických jednotek. Sloupec IOPS: Doručená pošta zobrazuje požadavky na IOPS pro logickou jednotku s adresáři doručené pošty Configuration Manager. Sloupec IOPS: SQL zobrazuje celkové potřeby IOPS pro logické jednotky, které používají různé soubory SQL Server. Tyto sloupce se liší, protože tyto dvě jednotky by měly mít odlišné formátování. Další informace a příklady týkající se navrhovaných konfigurací disků SQL Server a osvědčených postupů pro soubory, včetně podrobností o rozdělení souborů mezi více svazky, najdete v nejčastějších dotazech k nastavení velikosti a výkonu webu.
Oba tyto sloupce IOPS používají data ze standardního nástroje Diskspd. Pokyny k duplikování těchto měření najdete v tématu Měření výkonu disku . Obecně platí, že jakmile splníte základní požadavky na procesor a paměť, má subsystém úložiště největší vliv na výkon lokality a vylepšení, která zde nabízí, přinese největší návratnost investic.
Poznámka 4: Vyžaduje se prostor úložiště.
Tyto reálné hodnoty se můžou lišit od ostatních zdokumentovaných doporučení. Tato čísla poskytujeme pouze jako obecné vodítko; individuální požadavky se mohou značně lišit. Před instalací lokality pečlivě naplánujte potřebné místo na disku. Předpokládejme, že část tohoto úložiště zůstává většinu času jako volné místo na disku. Tento prostor vyrovnávací paměti můžete použít ve scénáři obnovení nebo ve scénářích upgradu, které vyžadují volné místo na disku pro rozšíření instalačního balíčku. Váš web může vyžadovat větší úložiště pro shromažďování velkých objemů dat, delší dobu uchovávání dat a velké objemy obsahu distribuce softwaru. Tyto položky můžete také uložit na samostatné svazky s nižší propustností.
Měření výkonu disku
Standardní nástroj Diskspd můžete použít k poskytování standardizovaných návrhů pro IOPS, které vyžadují různá Configuration Manager prostředí. Následující testovací kroky a příkazové řádky sice nejsou vyčerpávající, ale poskytují jednoduchý a reprodukovatelný způsob odhadu propustnosti diskového subsystému serverů. Výsledky můžete porovnat s minimálními doporučenými vstupně-výstupními operacemi za sekundu v tabulce obecných pokynů pro určení velikosti .
Výsledky testů z různých druhů konfigurací hardwaru v testovacích prostředích najdete v tématu Ukázkové konfigurace disků. Data můžete použít jako přibližný výchozí bod při návrhu subsystému úložiště pro nové prostředí od začátku.
Testování IOPS disku
Stáhněte si nástroj Diskspd.
Ujistěte se, že máte alespoň 100 GB volného místa na disku. Zakažte všechny aplikace, které můžou rušit nebo způsobovat dodatečné zatížení disku, například aktivní antivirovou kontrolu adresáře, SQL nebo SMSExec.
Z příkazového řádku se zvýšenými oprávněními spusťte diskspd .
Spusťte nástroj dvakrát po sobě pro svazek, který chcete testovat. První test o velikosti 64 000 s náhodnými operacemi zápisu po dobu jedné minuty. Tento test ověří načítání mezipaměti kontroleru a přidělení místa na disku v případě, že se svazek dynamicky rozšiřuje. Zahoďte výsledky prvního testu. Druhý test by měl okamžitě následovat po prvním testu a provést stejné zatížení po dobu pěti minut.
K otestování svazku můžete například použít následující konkrétní příkazové řádky
G:.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.datZkontrolujte výstup z druhého testu a vyhledejte celkový počet vstupně-výstupních operací za sekundu ve sloupci Vstupně-výstupní operace . V následujícím příkladu je celkový počet 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 |
Příklady konfigurací disků
Následující tabulky ukazují výsledky spuštění testovacích kroků v tématu Měření výkonu disku s různými konfiguracemi testovacího prostředí. Tato data použijte jako přibližný výchozí bod při návrhu subsystému úložiště pro nové prostředí od začátku.
Fyzické počítače a Hyper-V
Hardware se neustále zlepšuje. Očekávejte, že novější generace hardwaru a různé kombinace hardwaru, jako jsou disky SSD a SÍTĚ SAN, překročí výkon uvedený níže. Tyto výsledky představují základní výchozí bod, který je potřeba zvážit při návrhu serveru nebo při diskuzi s dodavatelem hardwaru.
Následující tabulka ukazuje výsledky testů napříč různými diskovými subsystémy, včetně pevných disků založených na vřetenu a SSD, v různých konfiguracích testovací laboratoře. Všechny konfigurace formátují disky s 64k clustery a připojují je k řadiči disků podnikové třídy. Kromě počtu disků pole RAID mají každý z nich alespoň jeden náhradní disk.
| Typ disku | Počet disků bez +1 náhradního disku | RAID | Měřené IOPS |
|---|---|---|---|
| 15 tisíc SAS | 2 | 1 | 620 |
| 15 tisíc SAS | 4 | 10 | 1206 |
| 15 tisíc SAS | 6 | 10 | 1751 |
| 15 tisíc SAS | 8 | 10 | 2322 |
| 15 tisíc SAS | 10 | 10 | 2882 |
| 15 tisíc SAS | 12 | 10 | 3476 |
| 15 tisíc SAS | 16 | 10 | 4236 |
| 15 tisíc SAS | 20 | 10 | 5148 |
| 15 tisíc SAS | 30 | 10 | 7398 |
| 15 tisíc 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 |
Následující tabulka uvádí konkrétní zařízení použitá v tomto příkladu. Tyto informace nejsou doporučením pro konkrétní model nebo výrobce hardwaru.
| Typ disku | Model | Řadič RAID | Paměť a konfigurace mezipaměti |
|---|---|---|---|
| 15k RPM SAS HD | HP EH0300JDYTH | Inteligentní pole P822 | 2 GB, 20 % čtení / 80 % zápisu |
| SSD SATA | ATA MK0200GCTYV | Smart Array P420i | 1 GB, 20 % čtení / 80 % zápisu |
| SSD SAS | HP MO0800 JEFPB | Smart Array P420i | 1 GB, 20 % čtení / 80 % zápisu |
Výkon počítačů a disků Azure
Výkon disků Azure závisí na několika faktorech, jako je velikost virtuálního počítače Azure a počet a typ disků, které používá. Azure také neustále přidává nové typy počítačů a rychlosti disků, které se liší od následujícího grafu. Další informace o Configuration Manager spuštěných v Azure a další informace o tom, jak porozumět vstupně-výstupním operacím disku v Azure, najdete v nejčastějších dotazech k Configuration Manager v Azure.
Všechny disky jsou formátované s velikostí clusteru NTFS 64k a řádky s více než jedním diskem se konfigurují jako proklásané svazky pomocí nástroje Správa disků systému Windows.
| Virtuální počítač Azure | Disk Azure | Počet disků | Dostupné místo | Měřené IOPS | Omezující faktor |
|---|---|---|---|---|---|
| DS2/DS11 | P20 | 1 | 512 GB | 965 | Velikost virtuálního počítače Azure |
| DS2/DS11 | P20 | 2 | 1024 GB | 996 | Velikost virtuálního počítače Azure |
| DS2/DS11 | P30 | 1 | 1024 GB | 996 | Velikost virtuálního počítače Azure |
| DS2/DS11 | P30 | 2 | 2048 GB | 996 | Velikost virtuálního počítače Azure |
| DS3/DS12/F4S | P20 | 1 | 512 GB | 1994 | Velikost virtuálního počítače Azure |
| DS3/DS12/F4S | P20 | 2 | 1024 GB | 1992 | Velikost virtuálního počítače Azure |
| DS3/DS12/F4S | P30 | 1 | 1024 GB | 1993 | Velikost virtuálního počítače Azure |
| DS3/DS12/F4S | P30 | 2 | 2048 GB | 1992 | Velikost virtuálního počítače Azure |
| DS4/DS13/F8S | P20 | 1 | 512 GB | 2334 | Disk P20 |
| DS4/DS13/F8S | P20 | 2 | 1024 GB | 3984 | Velikost virtuálního počítače Azure |
| DS4/DS13/F8S | P20 | 3 | 1536 GB | 3984 | Velikost virtuálního počítače Azure |
| DS4/DS13/F8S | P30 | 1 | 1024 GB | 3112 | Disk P30 |
| DS4/DS13/F8S | P30 | 2 | 2048 GB | 3984 | Velikost virtuálního počítače Azure |
| DS4/DS13/F8S | P30 | 3 | 3072 GB | 3996 | Velikost virtuálního počítače Azure |
| DS5/DS14/F16S | P20 | 1 | 512 GB | 2335 | Disk P20 |
| DS5/DS14/F16S | P20 | 2 | 1024 GB | 4639 | Disk P20 |
| DS5/DS14/F16S | P20 | 3 | 1536 GB | 6913 | Disk P20 |
| DS5/DS14/F16S | P20 | 4 | 2048 GB | 7966 | Velikost virtuálního počítače Azure |
| DS5/DS14/F16S | P30 | 1 | 1024 GB | 3112 | Disk P30 |
| DS5/DS14/F16S | P30 | 2 | 2048 GB | 6182 | Disk P30 |
| DS5/DS14/F16S | P30 | 3 | 3072 GB | 7963 | Velikost virtuálního počítače Azure |
| DS5/DS14/F16S | P30 | 4 | 4096 GB | 7968 | Velikost virtuálního počítače Azure |
| DS15 | P30 | 1 | 1024 GB | 3113 | Disk P30 |
| DS15 | P30 | 2 | 2048 GB | 6184 | Disk P30 |
| DS15 | P30 | 3 | 3072 GB | 9225 | Disk P30 |
| DS15 | P30 | 4 | 4096 GB | 10200 | Velikost virtuálního počítače Azure |
Další informace o aktuálně dostupných discích najdete v tématu Výběr typu disku pro virtuální počítače Azure IaaS.