Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
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
| Model správy | Model fakturace | Mediální vrstva | Přebytečnost | protokol SMB | NFS |
|---|---|---|---|---|---|
| Microsoft.Storage | Zprovozněno v2 | SSD (Premium) | Místní (LRS) |
|
|
| Microsoft.Storage | Zprovozněno v2 | SSD (Premium) | Zóna (ZRS) |
|
|
| Microsoft.Storage | Zprovozněno v2 | HDD (standard) | Místní (LRS) |
|
|
| Microsoft.Storage | Zprovozněno v2 | HDD (standard) | Zóna (ZRS) |
|
|
| Microsoft.Storage | Zprovozněno v2 | HDD (standard) | Geografie (GRS) |
|
|
| Microsoft.Storage | Zprovozněno v2 | HDD (standard) | GeoZone (GZRS) |
|
|
| Microsoft.Storage | Poskytnuto v1 | SSD (Premium) | Místní (LRS) |
|
|
| Microsoft.Storage | Poskytnuto v1 | SSD (Premium) | Zóna (ZRS) |
|
|
| Microsoft.Storage | Platba dle skutečné spotřeby | HDD (standard) | Místní (LRS) |
|
|
| Microsoft.Storage | Platba dle skutečné spotřeby | HDD (standard) | Zóna (ZRS) |
|
|
| Microsoft.Storage | Platba dle skutečné spotřeby | HDD (standard) | Geografie (GRS) |
|
|
| Microsoft.Storage | Platba dle skutečné spotřeby | HDD (standard) | GeoZone (GZRS) |
|
|
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ě:
Počet vstupně-výstupních operací za sekundu (IOPS)
IOPS, neboli vstupně-výstupní operace za sekundu, měří počet operací systému souborů za sekundu. Termín "vstup/výstup" je možné zaměnit s těmito termíny: "operace" a "transakce" v dokumentaci ke službě Azure Files.
Velikost vstupu/výstupu
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 malých velikostí, jako jsou například 4 KiB, až po 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 IOPS velikostí vstupů/výstupů. 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 size = 38 MiB/s.
Latence
Latence je synonymem zpoždění a měří se 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. Pro více informací si přečtěte Hloubka fronty.
Výběr vrstvy médií na základě vzorů použití
Azure Files poskytuje dvě úrovně médií úložiště, které umožňují vyrovnávat výkon a cenu: SSD a HDD. Vyberete úroveň médií sdílené složky na úrovni účtu úložiště a po vytvoření účtu úložiště v konkrétní vrstvě médií se nemůžete přesunout na druhou, aniž byste museli ručně migrovat na novou sdílenou složku.
Při výběru mezi sdílenými složkami SSD a HDD 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é množství vstupně-výstupních operací za sekundu, rychlost rychlého přenosu dat nebo nízkou latenci, měli byste zvolit sdílené složky SSD.
Následující tabulka shrnuje očekávané výkonnostní cíle pro sdílení souborů SSD a HDD. Podrobnosti najdete v tématu Škálovatelnost a výkonnostní cíle služby Azure Files.
| Požadavky na vzor využití | SSD | HDD |
|---|---|---|
| Latence zápisu (jednociferné milisekundy) | Ano | Ano |
| Latence čtení (jednociferné milisekundy) | Ano | Ne |
Sdílené složky SSD 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 zprovozněném modelu v1.
Kontrolní seznam 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.
Citlivost latence: Úlohy, které jsou citlivé na latenci čtení a mají vysokou viditelnost koncovým uživatelům, jsou vhodnější pro sdílené složky SSD, které můžou poskytovat latenci s jedním milisekundou pro operace čtení i zápisu (< 2 ms pro malou vstupně-výstupní velikost).
Požadavky na vstupně-výstupní operace za sekundu a propustnost: Sdílené složky SSD podporují větší limity IOPS a propustnosti než sdílené složky HDD. Další informace naleznete v sekci cíle škálování sdílených souborů.
Doba trvání a frekvence úloh: Krátké (minuty) a občasné (hodinové) úlohy jsou méně pravděpodobné, že dosáhne horních limitů výkonu sdílených složek HDD v porovnání s dlouhotrvajícími a často se vyskytujícími úlohami. U sdílených složek SSD je doba trvání úloh užitečná při určování správného profilu výkonu, který se má použít na základě zřízeného úložiště, IOPS a propustnosti. 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: Pro úlohy, 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 SSD jasnou výhodu oproti sdíleným složkám HDD: SMB Multichannel. Pro více informací si přečtěte Zvýšení výkonu sdílené složky protokolu SMB v Azure.
Distribuce operací rozhraní API: Úlohy náročné na metadata, jako jsou úlohy, které provádějí operace čtení s velkým počtem souborů, jsou vhodnější pro sdílené složky SSD. Viz Úlohy zatížené metadata nebo oborem 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ý čas, za který transakce vykoná úplnou cestu od klienta, přes síť, do služby Azure Files, a zpět ke klientovi.
Latence služby (SuccessServerLatency) je doba, kterou transakce potřebuje na zpracování pouze v rámci 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řenosem do a z klienta, a ne ve službě Azure Files.
Jak znázorňuje diagram, čím dál nejste od služby, tím pomalejší je latence a čím obtížnější je 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.
Návod
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. Nedostatečně směrované nebo nesprávně směrované okruhy ExpressRoute nebo brány VPN můžou výrazně zpomalit úlohy spuštěné ve službě Azure Files.
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. Jak se disky používané v systémech úložiště vyvinuly z jednotek HDD (IDE, SATA, SAS) na zařízení s pevným stavem (SSD, NVMe), vyvinuly se také tak, aby podporovaly vyšší 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.
Vysoké hloubky fronty lze dosáhnout několika různými způsoby ve spojení 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šší úrovně 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 | 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 |
Návod
Abyste dosáhli horních limitů výkonu, ujistěte se, že je vaše zátěž nebo srovnávací test vícevláknový a používá více souborů.
Jednovláknové a vícevláknové aplikace
Azure Files je nejvhodnější pro vícevláknové aplikace. Nejjednodušší způsob, jak pochopit, jaký dopad má vícevláknové zpracování na výkon úlohy, je projít scénářem z hlediska 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 rozděluje čas potřebný (v milisekundách) k vytvoření jednoho 16 KiB souboru ve sdílené složce Azure, na základě jednovláknové aplikace, která zapisuje ve velikosti bloků 4 KiB.
| Vstupně-výstupní operace | Vytvořit | 4 KiB zápis | 4 KiB zápis | 4 KiB zápis | 4 KiB zápis | 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, znamená to celkem 140 000 ms (14 ms * 10 000) nebo 140 sekund, protože každý soubor je přesunut postupně jeden po druhém. 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 zápis | 4 KiB zápis | 4 KiB zápis | 4 KiB zápis | 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 |