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

✔️ Platí pro: Klasické sdílené složky SMB a NFS vytvořené s poskytovatelem prostředků Microsoft.Storage

✔️ Platí pro: sdílené složky vytvořené pomocí poskytovatele prostředků Microsoft.FileShares

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é ovlivňují výkon sdílené složky a jak optimalizovat výkon Azure Files pro vaši úlohu.

Glosář výkonu úložiště

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. V dokumentaci k Azure Files se termín „IO“ používá zaměnitelně s termíny „operace“ a „transakce“.

  • 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 × velikost I/O 1 MiB = 10 GiB/s, zatímco 10 000 IOPS × velikost I/O 4 KiB = 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é můžete použít k vyvážení výkonu a ceny: SSD a HDD. Úroveň médií pro sdílenou složku vyberete na úrovni účtu úložiště. Po vytvoření účtu úložiště v konkrétní vrstvě médií nemůžete přejít na jinou vrstvu médií, aniž byste museli ručně migrovat na novou sdílenou složku.

Když zvolíte mezi sdílenými složkami SSD a HDD, zvažte požadavky očekávaného způsobu využití, který plánujete spustit na Azure Files. Pokud potřebujete velké objemy vstupně-výstupních operací za sekundu, rychlost rychlého přenosu dat nebo nízkou latenci, zvolte 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 používají 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.

Osvědčené postupy z hlediska 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 (menší než 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 najdete v tématu Cíle škálování sdílené složky.

  • Doba trvání a frekvence úloh: Krátké (minuty) a občasné (hodinové) úlohy jsou méně pravděpodobné, že dosáhnou 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 pomáhá doba trvání úloh určit správný profil výkonu, který se má použít na základě zřízeného úložiště, IOPS a propustnosti. Běžnou chybou je provádění výkonnostních testů po dobu jen několika minut, což je často zavádějící. Pro realistický přehled o výkonu se ujistěte, že testujete na dostatečně vysoké frekvenci a délce.

  • 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. Další informace najdete v článku Zlepšení výkonu sdílené složky Azure Files přes protokol SMB.

  • 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. Další informace naleznete v tématu Metadata nebo jmenný prostor s vysokým zatížením.

  • Zónové umístění: Pomocí zónového umístění vyberte konkrétní zónu dostupnosti, ve které se nachází váš účet úložiště. Tato funkce umožňuje umístit virtuální počítače do stejné zóny dostupnosti jako úložiště, což může snížit latenci až o 30 procent. Tato funkce je aktuálně dostupná jenom pro účty úložiště SSD využívající místně redundantní úložiště (LRS) v podporovaných oblastech.

Latence

Když se nad latencí zamyslete, nejdřív porozumíte tomu, jak Azure Files určuje latenci. Nejběžnější měření jsou latence přidružená k celkové latenci a metrikám latence služeb. Pomocí těchto metrik transakcí můžete identifikovat latenci na straně klienta a síťové problémy tím, že ukazuje, 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 potřebná k dokončení transakce pouze v rámci Azure Files. Toto měření 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 ukazuje nízkou latenci a latence mezi koncovými body uvádí u požadavků velmi vysokou latenci, veškerý čas se spotřebuje při přenosu k klientovi a od klienta, a ne ve službě Azure Files.

Kromě toho, jak diagram znázorňuje, čím dál jste ze 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. Tato podmínka platí zejména při přístupu k Azure Files z místního prostředí. I když jsou možnosti jako Azure ExpressRoute ideální pro místní prostředí, 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é úložnými systémy vyvíjely od plotnových pevných disků (HDD; IDE, SATA, SAS) k polovodičovým zařízením (SSD, NVMe), vyvíjely se také tak, aby podporovaly vyšší hloubku front. Ú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. Vzhledem k tomu, že Azure Files je distribuovaná souborová služba, která se rozprostírá napříč tisíci uzly clusterů Azure a je navržena tak, aby provozovala úlohy ve velkém měřítku, sestavujte a testujte úlohy s velkou hloubkou fronty.

Velké hloubky fronty můžete dosáhnout několika různými způsoby. 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 znázorňuje různé kombinace, které můžete použít pro dosažení větší hloubky fronty. I když můžete překročit optimální hloubku fronty 64, nedoporučuje se. 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 32

Návod

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

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

Azure Files nejlépe funguje s vícevláknovými aplikacemi. Nejjednodušší způsob, jak pochopit, jak vícevláknové zpracování ovlivňuje výkon úlohy, je projít si scénář z hlediska vstupně-výstupních operací. V následujícím příkladu máte úlohu, která potřebuje co nejrychleji zkopírovat 10 000 malých souborů do 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 trvá přibližně 14 ms k vytvoření jednoho souboru 16 KiB ze šesti operací. Pokud aplikace s jedním vláknem chce přesunout 10 000 souborů do Azure sdílené složky, tato operace se přeloží na 140 000 ms (14 ms × 10 000) nebo 140 sekund, protože každý soubor se přesune postupně po jednom. 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 můžete snížit předchozí úlohu z 140 000 ms (140 sekund) na 17 500 ms (17,5 sekund). Jak ukazuje následující tabulka, když místo jednoho souboru současně přesunete osm souborů paralelně, můžete v 87,5% kratší dobu 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

Viz také

  • Last updated on