Vysvětlení a optimalizace výkonu sdílených složek Azure
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 ovlivnit výkon sdílené složky 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 |  |
 |
| Sdílené složky úrovně Standard (GPv2), GRS/GZRS | |
|
| Sdílené složky úrovně Premium (FileStorage), LRS/ZRS | |
|
Slovník pojmů
Než si přečtete tento článek, je užitečné pochopit některé klíčové termíny týkající se výkonu úložiště:
Vstupně-výstupní operace za sekundu (IOPS)
Vstupně-výstupní operace za sekundu nebo vstupně-výstupní operace měří počet operací systému souborů za sekundu. Termín "V/V" je zaměnitelný s termíny "operace" a "transakce" v dokumentaci ke službě Azure Files.
Velikost vstupně-výstupních operací
V/V velikost, která se někdy označuje jako velikost bloku, je velikost požadavku, který aplikace používá k provedení jedné operace vstupu a výstupu (V/V) v úložišti. V závislosti na aplikaci může velikost vstupně-výstupních operací být v rozsahu od velmi malých velikostí, jako jsou například 4 KiB, až po mnohem větší velikosti. Velikost vstupně-výstupních operací hraje významnou roli při dosažitelné propustnosti.
Propustnost
Propustnost měří počet bitů přečtených nebo zapsaných do úložiště za sekundu a měří se v mebibajtech za sekundu (MiB/s). Pokud chcete vypočítat propustnost, vynásobte počet IOPS vstupně-výstupní velikostí. Například 10 000 IOPS * 1 velikost vstupně-výstupních operací MiB = 10 GiB/s, zatímco 10 000 IOPS * 4 KiB I/O velikost = 38 MiB/s.
Latence
Latence je synonymem zpoždění a obvykle se měří v milisekundách (ms). Existují dva typy latence: kompletní latence a latence služby. Další informace najdete v tématu Latence.
Hloubka fronty
Hloubka fronty je počet nevyřízených vstupně-výstupních požadavků, které může prostředek úložiště zpracovat najednou. Další informace najdete v tématu Hloubka fronty.
Výběr ú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 na odpovídající úrovni výkonu a ceny. Azure Files nabízí na nejvyšší úrovni dvě úrovně výkonu: Standard a Premium. Sdílené složky úrovně Standard jsou hostované v systému úložiště založeném na pevných discích (HDD), zatímco sdílené složky úrovně Premium jsou podporovány jednotkami SSD (Solid-State Drive) pro lepší výkon. Sdílené složky úrovně Standard mají několik úrovní úložiště (optimalizovaných transakcí, 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í. Nemůžete se ale přesouvat mezi úrovněmi Standard a Premium bez fyzické migrace dat mezi různými účty úložiště.
Při výběru 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 ve službě Azure Files. Pokud potřebujete velké objemy IOPS, extrémně rychlé rychlosti přenosu 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 standardem a premium. Podrobnosti najdete v tématu Škálovatelnost a výkonnostní cíle služby Azure Files.
| Požadavky na vzor využití | Standard | Premium |
|---|---|---|
| Latence zápisu (jednociferné milisekundy) | Ano | Yes |
| Latence čtení (jednociferné milisekundy) | No | Ano |
Sdílené složky Úrovně 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 ve zřízeném modelu v1. Nárazové kredity se hromadí v kbelíku s nárůstem, kdykoli je provoz sdílené složky nižší než základní IOPS. Vytvořené kredity se později použijí k povolení nárazového nárůstu, když operace překročí základní počet vstupně-výstupních operací za sekundu.
| Kapacita (GiB) | IOPS podle směrného plánu | Nárazové IOPS | Kredity s nárůstem kapacity | Propustnost (příchozí a 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 existující úlohu, pochopení vzorů využití vám pomůže dosáhnout předvídatelného výkonu. Pokud chcete zjistit následující vzory použití, obraťte se na správce úložiště nebo vývojáře aplikací.
Citlivost latence: Otevírají uživatelé soubory nebo pracují s virtuálními plochami, které běží ve službě 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 sdílené složky Azure úrovně Premium, které můžou poskytovat latenci v milisekundách pro operace čtení i zápisu (< 2 ms pro malou vstupně-výstupní velikost).
Požadavky na IOPS a propustnost: Sdílené složky 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: Krátké (minuty) a občasné (hodinové) úlohy budou méně pravděpodobné, že dosáhne horních limitů výkonu standardních sdílených složek v porovná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 se zatížení musí rozrůstat a jak dlouho utrácí pod základní IOPS, můžete určit, jestli se hromadí dostatek kreditů s nárůstem kapacity, abyste konzistentně uspokojili úlohy ve špičkách. Nalezení správného zůstatku sníží náklady oproti nadměrnému zřizování sdílené složky. Běžnou chybou je spustit testy výkonnosti jen několik minut, což je často zavádějící. Pokud chcete získat realistický pohled na výkon, nezapomeňte testovat dostatečně vysokou frekvenci a dobu 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í na 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 s operacemi otevření/zavření souboru těžké? To je běžné u úloh, které provádějí operace čtení s velkým počtem souborů. Viz Úlohy náročné na metadata nebo obor názvů.
Latence
Při úvahách o latenci je důležité nejprve pochopit, jak se latence určuje se službou Azure Files. Nejběžnější měření jsou latence přidružená k celkové latenci a metrikám latence služeb. Použití těchto metrik transakcí může pomoct identifikovat problémy s latencí na straně klienta nebo sítí tím, že určí, kolik času provoz aplikace stráví přenosy do a z klienta.
Celková latence (SuccessE2ELatency) je celková doba, po kterou transakce trvá provedení úplné odezvy z klienta, přes síť, do služby Azure Files a zpět do klienta.
Latence služby (SuccessServerLatency) je doba, po které transakce trvá odezvu pouze v rámci služby Azure Files. Nezahrnuje žádnou latenci klienta ani sítě.
Rozdíl mezi hodnotami SuccessE2ELatency a SuccessServerLatency je pravděpodobně latence způsobená sítí nebo klientem.
Latenci klienta je běžné zaměňovat s latencí služby (v tomto případě s výkonem služby Azure Files). Pokud například latence služby hlásí nízkou latenci a end-to-end hlásí velmi vysokou latenci požadavků, to naznačuje, že se veškerý čas stráví přenášeným do a z klienta, a ne ve službě Azure Files.
Kromě toho, jak diagram znázorňuje, čím dál nejste od služby, tím pomalejší bude latence a čím obtížnější bude dosáhnout limitů škálování výkonu u jakékoli cloudové služby. To platí zejména při přístupu ke službě 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ích prostředků a úložiště), které běží výhradně ve stejné oblasti Azure.
Tip
Použití virtuálního počítače v Azure k otestování výkonu mezi místním prostředím a Azure je efektivním a praktickým způsobem, jak využít možnosti sítě připojení k Azure. Často může být úloha zpomalována nedostatečně směrovaným nebo nesprávně směrovaným okruhem ExpressRoute nebo bránou 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 disky používané systémy úložiště se vyvinuly z diskových jednotek HDD (IDE, SATA, SAS) až po zařízení SSD, NVMe, vyvinuly se také tak, aby podporovaly větší hloubku fronty. Úloha skládající se z jednoho klienta, který sériově komunikuje s jedním souborem v rámci velké datové sady, je příkladem nízké hloubky fronty. Naproti tomu úloha, která podporuje paralelismus s více vlákny a více souborů, může snadno dosáhnout vysoké hloubky fronty. Protože Azure Files je distribuovaná souborová služba, která zahrnuje 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 vysokou hloubkou fronty.
Hloubky fronty lze 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 vláken (klienti * soubory * vlákna = hloubka fronty).
Následující tabulka ukazuje různé kombinace, které můžete použít k dosažení vyšší hloubky fronty. I když můžete překročit optimální hloubku fronty 64, nedoporučujeme ji. Pokud to uděláte, neuvidíte žádné další zvýšení výkonu a riskujete zvýšení latence kvůli sytosti protokolu TCP.
| Klienti | Soubory | Vlákna | Hloubka fronty |
|---|---|---|---|
| 1 | 1 | 1 | 1 |
| 1 | 0 | 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 je test úloh nebo srovnávacích testů více vláken s více soubory.
Jednovláknové a vícevláknové aplikace
Azure Files je nejvhodnější pro vícevláknové aplikace. Nejjednodušší způsob, jak pochopit dopad na výkon, který má více vláken na úlohu, je projít scénářem vstupně-výstupními operacemi. 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 rozdělí čas potřebný (v milisekundách) k vytvoření jednoho souboru KiB ve sdílené složce Azure na základě jednovláknové aplikace, která píše ve 4 velikostech bloků KiB.
| Vstupně-výstupní operace | Vytvořit | 4 KiB write | 4 KiB write | 4 KiB write | 4 KiB write | 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 z šesti operací trvalo přibližně 14 ms. Pokud chce aplikace s jedním vláknem přesunout 10 000 souborů do sdílené složky Azure, která se přeloží na 140 000 ms (14 ms * 10 000) nebo 140 sekund, protože každý soubor se postupně přesune 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é mezi sebou, jak je popsáno v předchozí části.
Použitím osmi vláken místo jednoho je možné výše uvedenou úlohu snížit z 140 000 ms (140 sekund) až na 17 500 ms (17,5 sekund). Jak ukazuje následující tabulka, když přesouváte osm souborů paralelně místo jednoho souboru najednou, můžete o 87,5 % méně času přesunout stejné množství dat.
| Vstupně-výstupní operace | Vytvořit | 4 KiB write | 4 KiB write | 4 KiB write | 4 KiB write | 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 |