Vysvětlení výkonu Azure Files

  • Článek

Azure Files může splňovat požadavky na výkon pro většinu aplikací a případů použití. Tento článek vysvětluje různé faktory, které můžou mít vliv na výkon sdílených složek, a jak optimalizovat výkon sdílených složek Azure pro vaši úlohu.

Platí pro

Typ sdílené složky SMB NFS
Sdílené složky úrovně Standard (GPv2), LRS/ZRS Yes No
Sdílené složky úrovně Standard (GPv2), GRS/GZRS Yes No
Sdílené složky úrovně Premium (FileStorage), LRS/ZRS Yes Yes

Glosář

Před přečtením tohoto článku je užitečné porozumět některým klíčovým pojmům souvisejícím s výkonem úložiště:

  • Vstupně-výstupní operace za sekundu (IOPS)

    Počet operací IOPS nebo vstupně-výstupních operací za sekundu měří počet operací systému souborů za sekundu. Termín "vstupně-výstupní operace" je v dokumentaci Azure Files vzájemně propojený s termíny "operace" a "transakce".

  • Velikost vstupně-výstupních operací

    Velikost vstupně-výstupních operací, někdy označovaná jako velikost bloku, je velikost požadavku, kterou aplikace používá k provedení jedné vstupně-výstupní operace v úložišti. V závislosti na aplikaci se může velikost vstupně-výstupních operací pohybovat od velmi malých velikostí, jako jsou 4 KiB, až po mnohem větší velikosti. Velikost vstupně-výstupních operací hraje hlavní roli v dosažitelné propustnosti.

  • Propustnost

    Propustnost měří počet bitů přečtených z úložiště nebo zápisů do úložiště za sekundu a měří se v mebibajtech za sekundu (MiB/s). Pokud chcete vypočítat propustnost, vynásobte IOPS velikostí vstupně-výstupních operací. Například 10 000 IOPS × 1 Velikost vstupně-výstupních operací MiB = 10 GiB/s, zatímco 10 000 IOPS × 4 velikost vstupně-výstupních operací KiB = 38 MiB/s.

  • Latence

    Latence je synonymem pro zpoždění a obvykle se měří v milisekundách (ms). Existují dva typy latence: end-to-end latence a latence služby. Další informace najdete v tématu Latence.

  • Hloubka fronty

    Hloubka fronty je počet čekajících vstupně-výstupních požadavků, které může prostředek úložiště zpracovat v libovolném okamžiku. Další informace najdete v tématu Hloubka fronty.

Volba úrovně výkonu na základě vzorů využití

Azure Files poskytuje řadu úrovní úložiště, které pomáhají snižovat náklady tím, že umožňují ukládat data za odpovídající úroveň výkonu a ceny. Na nejvyšší úrovni nabízí Azure Files dvě úrovně výkonu: Standard a Premium. Sdílené složky úrovně Standard jsou hostované v úložném systému založeném na pevných diskových jednotkách (HDD), zatímco sdílené složky úrovně Premium jsou pro zajištění lepšího výkonu podporovány jednotkami SSD (Solid-State Drive). Sdílené složky Úrovně Standard mají několik úrovní úložiště (optimalizovaných pro transakce, horké a studené), mezi kterými můžete bezproblémově přecházet, abyste maximalizovali úložiště neaktivních uložených dat a ceny transakcí. Mezi úrovněmi Standard a Premium se ale nemůžete pohybovat bez fyzické migrace dat mezi různými účty úložiště.

Při volbě mezi sdílenými složkami úrovně Standard a Premium je důležité porozumět požadavkům očekávaného způsobu použití, který plánujete spustit na Azure Files. Pokud požadujete velké množství IOPS, extrémně rychlé přenosy dat nebo velmi nízkou latenci, měli byste zvolit prémiové sdílené složky Azure.

Následující tabulka shrnuje očekávané výkonnostní cíle mezi úrovněmi Standard a Premium. Podrobnosti najdete v tématu Azure Files cíle škálovatelnosti a výkonu.

Požadavky na model použití Standard Premium
Latence zápisu (jednociferné milisekundy) Yes Yes
Latence čtení (jednociferné milisekundy) No Yes

Sdílené složky Premium nabízejí model zřizování, který zaručuje následující profil výkonu na základě velikosti sdílené složky. Další informace najdete v tématu Zřízený model. Kredity shlukového přenosu se hromadí v kontejneru shlukového přenosu vždy, když provoz sdílené složky klesne pod směrný IOPS. Vytvořené kredity se používají později k povolení shlukování, když by operace překročily základní IOPS.

Kapacita (GiB) IOPS podle směrného plánu Shlukové IOPS Kredity shlukových shluků Propustnost (příchozí přenos dat + výchozí přenos dat)
100 3,100 Až 10 000 24,840,000 110 MiB/s
500 3 500 Až 10 000 23,400,000 150 MiB/s
1,024 4,024 Až 10 000 21,513,600 203 MiB/s
5,120 8,120 Až 15 360 26,064,000 613 MiB/s
10,240 13,240 Až 30 720 62,928,000 1 125 MiB/s
33,792 36,792 Až 100 000 227,548,800 3 480 MiB/s
51,200 54,200 Až 100 000 164,880,000 5 220 MiB/s
102,400 100 000 Až 100 000 0 10 340 MiB/s

Kontrolní seznam k výkonu

Ať už posuzujete požadavky na výkon pro novou nebo stávající úlohu, porozumění vzorcům využití vám pomůže dosáhnout předvídatelného výkonu. Obraťte se na správce úložiště nebo vývojáře aplikací a zjistěte následující vzory použití.

  • Citlivost latence: Otevírají uživatelé soubory nebo pracují s virtuálními plochami, které běží na Azure Files? Jedná se o příklady úloh, které jsou citlivé na latenci čtení a mají také vysokou viditelnost pro koncové uživatele. Tyto typy úloh jsou vhodnější pro prémiové sdílené složky Azure, které můžou poskytovat latenci na jednu milisekundu pro operace čtení i zápisu (< 2 ms pro malou velikost vstupně-výstupních operací).

  • Požadavky na vstupně-výstupní operace za sekundu a propustnost: Sdílené složky úrovně Premium podporují větší limity IOPS a propustnosti než standardní sdílené složky. Další informace najdete v tématu Cíle škálování sdílených složek .

  • Doba trvání a frekvence úloh: U krátkých (minut) a občasných (hodinových) úloh je méně pravděpodobné, že dosáhnou horních limitů výkonu sdílených složek úrovně Standard ve srovnání s dlouhotrvajícími a často se vyskytujícími úlohami. U sdílených složek Úrovně Premium je doba trvání úlohy užitečná při určování správného profilu výkonu, který se má použít na základě velikosti zřizování. V závislosti na tom, jak dlouho musí úloha shlukovat a jak dlouho trvá pod standardními IOPS, můžete určit, jestli nahromadíte dostatek kreditů pro shlukování, abyste mohli konzistentně uspokojit úlohy ve špičkách. Nalezení správného zůstatku sníží náklady v porovnání s nadměrným zřizováním sdílené složky. Běžnou chybou je spouštění testů výkonnosti jen na několik minut, což je často zavádějící. Pokud chcete získat realistický přehled o výkonu, nezapomeňte testovat s dostatečně vysokou frekvencí a dobou trvání.

  • Paralelizace úloh: U úloh, které provádějí operace paralelně, například prostřednictvím více vláken, procesů nebo instancí aplikací ve stejném klientovi, poskytují sdílené složky úrovně Premium jasnou výhodu oproti standardním sdíleným složkám: SMB Multichannel. Další informace najdete v tématu Zlepšení výkonu sdílené složky Azure protokolu SMB .

  • Distribuce operací rozhraní API: Jsou metadata úloh náročná na operace otevření/zavření souborů? To je běžné u úloh, které provádějí operace čtení u velkého počtu souborů. Viz Náročné úlohy metadat nebo oboru názvů.

Latence

Při úvahách o latenci je důležité nejprve pochopit, jak se latence určuje pomocí Azure Files. Nejběžnějšími měřeními jsou latence spojená s komplexní latencí a metrikami latence služby . Použití těchto transakčních metrik může pomoct identifikovat problémy s latencí nebo sítěmi na straně klienta tím, že určíte, kolik času provoz aplikace stráví přenosem do a z klienta.

  • End-to-end latence (SuccessE2ELatency) je celková doba potřebná k provedení transakce z klienta, přes síť, do služby Azure Files a zpět ke klientovi.

  • Latence služby (SuccessServerLatency) je doba potřebná k tomu, aby transakce byla dokončena pouze v rámci služby Azure Files. Nezahrnuje latenci klienta ani sítě.

    Diagram porovnávající latenci klienta a latenci služby pro Azure Files

Rozdíl mezi hodnotami SuccessE2ELatency a SuccessServerLatency je latence, kterou pravděpodobně způsobuje síť nebo klient.

Latenci klienta je běžné zaměňovat s latencí služby (v tomto případě Azure Files výkonu). Pokud například latence služby hlásí nízkou latenci a end-to-end hlásí velmi vysokou latenci požadavků, znamená to, že se veškerý čas tráví přenosem do a z klienta, a ne ve službě Azure Files.

Kromě toho, jak znázorňuje diagram, čím dál budete od služby, tím pomalejší bude latence a tím obtížnější bude dosažení limitů škálování výkonu s libovolnou cloudovou službou. To platí zejména při přístupu k Azure Files z místního prostředí. I když jsou možnosti, jako je ExpressRoute, ideální pro místní prostředí, stále neodpovídají výkonu aplikace (výpočetní prostředky + úložiště), která běží výhradně ve stejné oblasti Azure.

Tip

Použití virtuálního počítače v Azure k testování výkonu mezi místním prostředím a Azure je efektivní a praktický způsob, jak vytvořit základ síťových možností připojení k Azure. Úlohu často může zpomalit poddimenzovaný nebo nesprávně směrovaný okruh ExpressRoute nebo brána VPN.

Hloubka fronty

Hloubka fronty je počet nevyřízených vstupně-výstupních požadavků, které může prostředek úložiště obsluhovat. Vzhledem k tomu, že se disky používané úložnými systémy vyvinuly od vřeten HDD (IDE, SATA, SAS) až po zařízení ssd (SSD, NVMe), vyvinuly se také tak, aby podporovaly větší hloubku front. Příkladem nízké hloubky fronty je úloha skládající se z jednoho klienta, který sériově pracuje s jedním souborem v rámci velké datové sady. Naproti tomu úloha, která podporuje paralelismus s více vlákny a více soubory, může snadno dosáhnout vysoké hloubky fronty. Vzhledem k tomu, že Azure Files je distribuovaná souborová služba, která pokrývá tisíce uzlů clusteru Azure a je navržená pro spouštění úloh ve velkém měřítku, doporučujeme vytvářet a testovat úlohy s velkou hloubkou front.

Vysoká hloubka fronty se dá dosáhnout několika různými způsoby v kombinaci s klienty, soubory a vlákny. Pokud chcete určit hloubku fronty pro vaši úlohu, vynásobte počet klientů počtem souborů počtem vláken (klienti * soubory * vlákna = hloubka fronty).

Následující tabulka znázorňuje různé kombinace, které můžete použít k dosažení větší hloubky fronty. I když můžete překročit optimální hloubku fronty 64, nedoporučujeme to. Pokud to uděláte, neuvidíte žádné další zvýšení výkonu a riskujete zvýšení latence kvůli nasycení protokolu TCP.

Klienti Soubory Vlákna Hloubka fronty
1 1 1 1
1 1 2 2
1 2 2 4
2 2 2 8
2 2 4 16
2 4 4 32
1 8 8 64
4 4 2 64

Tip

Pokud chcete dosáhnout horních limitů výkonu, ujistěte se, že test úloh nebo srovnávacích testů je vícevláknový a obsahuje více souborů.

Jednovláknové a vícevláknové aplikace

Azure Files je nejvhodnější pro vícevláknové aplikace. Nejjednodušším způsobem, jak porozumět dopadu více vláken na výkon úloh, je projít si scénář podle vstupně-výstupních operací. V následujícím příkladu máme úlohu, která potřebuje co nejrychleji zkopírovat 10 000 malých souborů do sdílené složky Azure nebo ze sdílené složky Azure.

Tato tabulka rozpisuje čas potřebný k vytvoření jednoho souboru 16 KiB ve sdílené složce Azure (v milisekundách) na základě aplikace s jedním vláknem, která píše ve 4 kiB blokech.

Vstupně-výstupní operace Vytvořit 4 zápis kiB 4 zápis kiB 4 zápis kiB 4 zápis kiB Zavřít Celkem
Vlákno 1 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

V tomto příkladu by vytvoření jednoho souboru 16 KiB ze šesti operací trvalo přibližně 14 ms. Pokud jednovláknová aplikace chce do sdílené složky Azure přesunout 10 000 souborů, znamená to 140 000 ms (14 ms × 10 000) nebo 140 sekund, protože každý soubor se přesouvá postupně po jednom. Mějte na paměti, že doba obsluhy jednotlivých požadavků je primárně určená tím, jak blízko jsou výpočetní prostředky a úložiště umístěné od sebe, jak je popsáno v předchozí části.

Když použijete osm vláken místo jednoho, můžete snížit výše uvedenou úlohu z 140 000 ms (140 sekund) na 17 500 ms (17,5 sekund). Jak ukazuje následující tabulka, když přesouváte osm souborů paralelně místo jednoho souboru, můžete přesunout stejné množství dat za 87,5 % kratší dobu.

Vstupně-výstupní operace Vytvořit 4 zápis kiB 4 zápis kiB 4 zápis kiB 4 zápis kiB Zavřít Celkem
Vlákno 1 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Vlákno 2 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Vlákno 3 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Vlákno 4 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Vlákno 5 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Vlákno 6 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Vlákno 7 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Vlákno 8 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

Viz také