Sdílet prostřednictvím

Vysvětlení a optimalizace výkonu sdílených složek Azure

  • Č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 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 Yes No
Sdílené složky úrovně Standard (GPv2), GRS/GZRS Yes No
Sdílené složky úrovně Premium (FileStorage), LRS/ZRS Ano Yes

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 "vstupně-výstupní operace" je propletitelný 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 naleznete v tématu Zřízený model. 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ě.

    Diagram porovnání latence klienta a latence služby pro Azure Files

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

Viz také