Omówienie i optymalizowanie wydajności udziału plików platformy Azure
Usługa Azure Files może spełniać wymagania dotyczące wydajności dla większości aplikacji i przypadków użycia. W tym artykule wyjaśniono różne czynniki, które mogą mieć wpływ na wydajność udziału plików i jak zoptymalizować wydajność udziałów plików platformy Azure dla obciążenia.
Dotyczy
| Typ udziału plików | SMB | NFS |
|---|---|---|
| Udziały plików w warstwie Standardowa (GPv2), LRS/ZRS |  |
 |
| Udziały plików w warstwie Standardowa (GPv2), GRS/GZRS | |
|
| Udziały plików w warstwie Premium (FileStorage), LRS/ZRS | |
|
Słownik
Przed przeczytaniem tego artykułu warto zrozumieć niektóre kluczowe terminy związane z wydajnością magazynu:
Operacje we/wy na sekundę (liczba operacji we/wy na sekundę)
Liczba operacji we/wy na sekundę lub operacji wejścia/wyjścia na sekundę mierzy liczbę operacji systemu plików na sekundę. Termin "We/Wy" jest niezmienny z terminami "operation" i "transaction" w dokumentacji usługi Azure Files.
Rozmiar we/wy
Rozmiar we/wy, czasami określany jako rozmiar bloku, jest rozmiarem żądania używanego przez aplikację do wykonywania pojedynczej operacji wejścia/wyjścia (we/wy) w magazynie. W zależności od aplikacji rozmiar we/wy może wahać się od bardzo małych rozmiarów, takich jak 4 KiB do znacznie większych rozmiarów. Rozmiar we/wy odgrywa ważną rolę w osiągalnej przepływności.
Throughput (Przepływność)
Przepływność mierzy liczbę bitów odczytanych lub zapisanych w magazynie na sekundę i jest mierzona w mebibajtach na sekundę (MiB/s). Aby obliczyć przepływność, pomnożyj liczbę operacji we/wy na sekundę według rozmiaru operacji we/wy. Na przykład 10 000 operacji we/wy na sekundę * 1 Rozmiar operacji we/wy MiB = 10 GiB/s, podczas gdy 10 000 operacji we/wy na sekundę * 4 Rozmiar operacji we/wy KiB = 38 MiB/s.
Opóźnienie
Opóźnienie jest synonimem opóźnienia i zwykle mierzone w milisekundach (ms). Istnieją dwa typy opóźnień: kompleksowe opóźnienie i opóźnienie usługi. Aby uzyskać więcej informacji, zobacz Opóźnienie.
Głębokość kolejki
Głębokość kolejki to liczba oczekujących żądań we/wy, które zasób magazynu może obsłużyć w dowolnym momencie. Aby uzyskać więcej informacji, zobacz Głębokość kolejki.
Wybieranie warstwy wydajności na podstawie wzorców użycia
Usługa Azure Files oferuje szereg warstw magazynowania, które pomagają zmniejszyć koszty, umożliwiając przechowywanie danych na odpowiednim poziomie wydajności i ceny. Na najwyższym poziomie usługa Azure Files oferuje dwie warstwy wydajności: Standardowa i Premium. Standardowe udziały plików są hostowane w systemie magazynu wspieranym przez dyski twarde (HDD), podczas gdy udziały plików w warstwie Premium są wspierane przez dyski półprzewodnikowe (SSD) w celu uzyskania lepszej wydajności. Standardowe udziały plików mają kilka warstw magazynowania (zoptymalizowane pod kątem transakcji, gorącą i chłodną), które można bezproblemowo przenosić między, aby zmaksymalizować dane magazynowane i ceny transakcji. Nie można jednak przechodzić między warstwami Standardowa i Premium bez fizycznego migrowania danych między różnymi kontami magazynu.
Podczas wybierania między udziałami plików w warstwie Standardowa i Premium ważne jest zrozumienie wymagań oczekiwanego wzorca użycia, który planujesz uruchomić w usłudze Azure Files. Jeśli potrzebujesz dużych ilości operacji we/wy na sekundę, bardzo szybkich szybkości transferu danych lub bardzo małych opóźnień, wybierz udziały plików platformy Azure w warstwie Premium.
W poniższej tabeli przedstawiono podsumowanie oczekiwanych celów wydajności między warstwą Standardowa i Premium. Aby uzyskać szczegółowe informacje, zobacz Cele dotyczące skalowalności i wydajności usługi Azure Files.
| Wymagania dotyczące wzorca użycia | Standardowa | Premium |
|---|---|---|
| Opóźnienie zapisu (liczba milisekund jednocyfrowych) | Tak | Tak |
| Opóźnienie odczytu (liczba milisekund jednocyfrowych) | Nie. | Tak |
Udziały plików w warstwie Premium oferują model aprowizacji, który gwarantuje następujący profil wydajności na podstawie rozmiaru udziału. Aby uzyskać więcej informacji, zobacz Aprowizowany model. Środki na wzrost kumulują się w zasobniku z serii, gdy ruch dla udziału plików znajduje się poniżej bazowej liczby operacji we/wy na sekundę. Środki uzyskane są używane później w celu włączenia skalowania, gdy operacje przekroczą liczbę operacji we/wy na sekundę wg planu bazowego.
| Pojemność (GiB) | Podstawowe operacje we/wy na sekundę | Operacje we/wy na sekundę | Środki na wzrost | Przepływność (ruch przychodzący i ruch wychodzący) |
|---|---|---|---|---|
| 100 | 3,100 | Do 10 000 | 24,840,000 | 110 MiB/s |
| 500 | 3500 | Do 10 000 | 23,400,000 | 150 MiB/s |
| 1,024 | 4,024 | Do 10 000 | 21,513,600 | 203 MiB/s |
| 5,120 | 8 120 | Do 15 360 | 26,064,000 | 613 MiB/s |
| 10,240 | 13,240 | Do 30 720 | 62,928,000 | 1125 MiB/s |
| 33,792 | 36,792 | Do 100 000 | 227,548,800 | 3480 MiB/s |
| 51,200 | 54,200 | Do 100 000 | 164,880,000 | 5220 MiB/s |
| 102,400 | 100 000 | Do 100 000 | 0 | 10 340 MiB/s |
Lista kontrolna wydajności
Niezależnie od tego, czy oceniasz wymagania dotyczące wydajności dla nowego, czy istniejącego obciążenia, zrozumienie wzorców użycia pomoże Ci osiągnąć przewidywalną wydajność. Skontaktuj się z administratorem magazynu lub deweloperem aplikacji, aby określić następujące wzorce użycia.
Czułość opóźnienia: czy użytkownicy otwierają pliki lub wchodzą w interakcje z pulpitami wirtualnymi, które działają w usłudze Azure Files? Są to przykłady obciążeń, które są wrażliwe na opóźnienie odczytu, a także mają wysoką widoczność dla użytkowników końcowych. Te typy obciążeń są bardziej odpowiednie dla udziałów plików platformy Azure w warstwie Premium, co może zapewnić jednosisekundowe opóźnienie zarówno dla operacji odczytu, jak i zapisu (< 2 ms dla małego rozmiaru operacji we/wy).
Wymagania dotyczące liczby operacji we/wy na sekundę i przepływności: udziały plików w warstwie Premium obsługują większe limity liczby operacji we/wy na sekundę i przepływności niż standardowe udziały plików. Aby uzyskać więcej informacji, zobacz Cele skalowania udziałów plików.
Czas trwania i częstotliwość obciążenia: krótkie (minuty) i rzadko (co godzinę) obciążenia będą mniej prawdopodobne, aby osiągnąć górne limity wydajności standardowych udziałów plików w porównaniu z długotrwałymi, często występującymi obciążeniami. W przypadku udziałów plików w warstwie Premium czas trwania obciążenia jest przydatny podczas określania prawidłowego profilu wydajności do użycia na podstawie rozmiaru aprowizacji. W zależności od tego, jak długo obciążenie musi być zwiększane i jak długo spędza ono poniżej bazowej liczby operacji we/wy na sekundę, możesz określić, czy gromadzisz wystarczająco dużo środków, aby spójnie zaspokoić obciążenie w godzinach szczytu. Znalezienie właściwej równowagi spowoduje zmniejszenie kosztów w porównaniu z nadmierną aprowizowaniem udziału plików. Typowym błędem jest uruchamianie testów wydajnościowych tylko przez kilka minut, co często jest mylące. Aby uzyskać realistyczny widok wydajności, pamiętaj, aby przetestować odpowiednio wysoką częstotliwość i czas trwania.
Równoległe obciążenia: w przypadku obciążeń, które wykonują operacje równolegle, takich jak wiele wątków, procesów lub wystąpień aplikacji na tym samym kliencie, udziały plików w warstwie Premium zapewniają wyraźną przewagę nad standardowymi udziałami plików: SMB Multichannel. Aby uzyskać więcej informacji, zobacz Zwiększanie wydajności udziału plików platformy Azure protokołu SMB.
Dystrybucja operacji interfejsu API: czy metadane obciążenia są duże z operacjami otwierania/zamykania plików? Jest to typowe w przypadku obciążeń, które wykonują operacje odczytu względem dużej liczby plików. Zobacz Duże obciążenie metadanych lub przestrzeni nazw.
Opóźnienie
Podczas myślenia o opóźnieniu ważne jest, aby najpierw zrozumieć, jak opóźnienie jest określane w usłudze Azure Files. Najbardziej typowe pomiary to opóźnienie skojarzone z metrykami całkowitego opóźnienia i opóźnienia usługi. Użycie tych metryk transakcji może pomóc zidentyfikować opóźnienia po stronie klienta i/lub problemy z siecią, określając, ile czasu ruch aplikacji spędza podczas przesyłania do i z klienta.
Całkowite opóźnienie (SuccessE2ELatency) to całkowity czas potrzebny na transakcję do wykonania pełnej rundy od klienta w całej sieci do usługi Azure Files i z powrotem do klienta.
Opóźnienie usługi (SuccessServerLatency) to czas potrzebny na transakcję tylko w ramach usługi Azure Files. Nie obejmuje to żadnego opóźnienia klienta ani sieci.
Różnica między wartościami SuccessE2ELatency i SuccessServerLatency jest prawdopodobnie spowodowana przez sieć i/lub klienta.
Często mylić opóźnienie klienta z opóźnieniem usługi (w tym przypadku wydajność usługi Azure Files). Jeśli na przykład opóźnienie usługi zgłasza małe opóźnienia, a kompleksowe zgłasza bardzo duże opóźnienie żądań, sugeruje to, że cały czas jest poświęcany na tranzyt do i z klienta, a nie w usłudze Azure Files.
Ponadto, jak pokazano na diagramie, tym dalej jesteś z dala od usługi, tym wolniejsze będzie opóźnienie i tym trudniej będzie osiągnąć limity skalowania wydajności z dowolną usługą w chmurze. Jest to szczególnie istotne w przypadku uzyskiwania dostępu do usługi Azure Files ze środowiska lokalnego. Chociaż opcje, takie jak ExpressRoute, są idealne dla środowiska lokalnego, nadal nie są zgodne z wydajnością aplikacji (obliczenia i magazyn), która działa wyłącznie w tym samym regionie świadczenia usługi Azure.
Napiwek
Używanie maszyny wirtualnej na platformie Azure do testowania wydajności między środowiskiem lokalnym a platformą Azure jest skutecznym i praktycznym sposobem odniesienia możliwości sieciowych połączenia z platformą Azure. Często obciążenie może zostać spowolnione przez niewymiarowy lub nieprawidłowo kierowany obwód usługi ExpressRoute lub bramę sieci VPN.
Głębokość kolejki
Głębokość kolejki to liczba oczekujących żądań we/wy, które może obsłużyć zasób magazynu. Ponieważ dyski używane przez systemy magazynowania ewoluowały od wrzecion HDD (IDE, SATA, SAS) do urządzeń półprzewodnikowych (SSD, NVMe), również ewoluowały, aby obsługiwać większą głębokość kolejki. Obciążenie składające się z pojedynczego klienta, który szeregowo wchodzi w interakcję z pojedynczym plikiem w dużym zestawie danych, jest przykładem niskiej głębokości kolejki. Natomiast obciążenie, które obsługuje równoległość z wieloma wątkami i wieloma plikami, może łatwo osiągnąć wysoką głębokość kolejki. Ponieważ usługa Azure Files to rozproszona usługa plików, która obejmuje tysiące węzłów klastra platformy Azure i jest przeznaczona do uruchamiania obciążeń na dużą skalę, zalecamy kompilowanie i testowanie obciążeń z dużą głębokością kolejki.
Wysoką głębokość kolejki można osiągnąć na kilka różnych sposobów w połączeniu z klientami, plikami i wątkami. Aby określić głębokość kolejki dla obciążenia, należy pomnożyć liczbę klientów przez liczbę plików według liczby wątków (klienci * pliki * wątki = głębokość kolejki).
W poniższej tabeli przedstawiono różne kombinacje, których można użyć do osiągnięcia większej głębokości kolejki. Chociaż można przekroczyć optymalną głębokość kolejki 64, nie zalecamy jej. Jeśli tak zrobisz, nie zobaczysz więcej zysków wydajności i ryzykujesz zwiększenie opóźnienia ze względu na nasycenie protokołu TCP.
| Klienci | Pliki | Wątki | Głębokość kolejki |
|---|---|---|---|
| 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 |
Napiwek
Aby osiągnąć górne limity wydajności, upewnij się, że obciążenie lub test porównawczy jest wielowątkowy z wieloma plikami.
Aplikacje pojedyncze i wielowątowe
Usługa Azure Files najlepiej nadaje się do obsługi aplikacji wielowątowych. Najprostszym sposobem zrozumienia wpływu na wydajność, jaki ma wielowątkowa obsługa obciążenia, jest zapoznanie się ze scenariuszem we/wy. W poniższym przykładzie mamy obciążenie, które musi jak najszybciej skopiować 10 000 małych plików do lub z udziału plików platformy Azure.
Ta tabela dzieli czas potrzebny (w milisekundach), aby utworzyć pojedynczy plik KiB 16 w udziale plików platformy Azure w oparciu o jednowątkową aplikację, która zapisuje w 4 rozmiarach bloków KiB.
| Operacja we/wy | Utwórz | 4 Zapis KiB | 4 Zapis KiB | 4 Zapis KiB | 4 Zapis KiB | Zamknij | Łącznie |
|---|---|---|---|---|---|---|---|
| Wątek 1 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
W tym przykładzie utworzenie pojedynczego pliku KiB z sześciu operacji zajęłoby około 14 ms. Jeśli jednowątkowa aplikacja chce przenieść 10 000 plików do udziału plików platformy Azure, przekłada się to na 140 000 ms (14 ms * 10 000) lub 140 sekund, ponieważ każdy plik jest przenoszony sekwencyjnie pojedynczo. Należy pamiętać, że czas obsługi każdego żądania zależy przede wszystkim od tego, jak blisko zasobów obliczeniowych i magazynu znajdują się nawzajem, zgodnie z opisem w poprzedniej sekcji.
Używając ośmiu wątków zamiast jednego, powyższe obciążenie można zmniejszyć z 140 000 ms (140 sekund) do 17 500 ms (17,5 sekund). Jak pokazano w poniższej tabeli, w przypadku przenoszenia ośmiu plików równolegle zamiast jednego pliku jednocześnie można przenieść tę samą ilość danych w 87,5% mniej czasu.
| Operacja we/wy | Utwórz | 4 Zapis KiB | 4 Zapis KiB | 4 Zapis KiB | 4 Zapis KiB | Zamknij | Łącznie |
|---|---|---|---|---|---|---|---|
| Wątek 1 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| Wątek 2 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| Wątek 3 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| Wątek 4 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| Wątek 5 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| Wątek 6 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| Wątek 7 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| Wątek 8 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |