Regularne testy porównawcze wydajności woluminu usługi Azure NetApp Files dla systemu Linux

W tym artykule opisano testy porównawcze wydajności zapewniane przez usługę Azure NetApp Files dla systemu Linux z regularnym woluminem.

Obciążenia całego przesyłania strumieniowego plików (testy porównawcze skalowane w poziomie)

Celem testu skalowalnego w poziomie jest pokazanie wydajności woluminu usługi Azure NetApp File podczas skalowania w poziomie (lub zwiększania) liczby klientów generujących jednoczesne obciążenie do tego samego woluminu. Te testy są zwykle w stanie wypchnąć wolumin do krawędzi swoich limitów wydajności i wskazują na obciążenia, takie jak renderowanie multimediów, sztuczna inteligencja/uczenie maszynowe i inne obciążenia, które wykorzystują duże farmy obliczeniowe do wykonywania pracy.

Konfiguracja testu porównawczego o dużej skali operacji we/wy na poziomie operacji we/wy

Te testy porównawcze używały następujących elementów:

• Pojedynczy wolumin regularny usługi Azure NetApp Files 100-TiB z zestawem danych 1-TiB korzystającym z warstwy wydajności Ultra
• FIO (z ustawieniem i bez ustawienia randrepeat=0)
• Rozmiary bloków 4-KiB i 8-KiB
• 6 D32s_v5 maszyn wirtualnych z systemem RHEL 9.3
• NFSv3
• Ręczne QoS
• Opcje instalacji: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

Konfiguracja testu porównawczego o wysokiej przepływności skalowanej w poziomie

Te testy porównawcze używały następujących elementów:

• Pojedynczy wolumin regularny usługi Azure NetApp Files z zestawem danych 1-TiB korzystającym z warstwy wydajności Ultra FIO (z ustawieniem i bez ustawienia randrepeat=0)
• FIO (z ustawieniem i bez ustawienia randrepeat=0)
• 64-KiB i 256-KiB rozmiar bloku
• 6 D32s_v5 maszyn wirtualnych z systemem RHEL 9.3
• NFSv3
• Ręczne QoS
• Opcje instalacji: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

Konfiguracja testu porównawczego równoległego połączenia sieciowego (nconnect)

Te testy porównawcze używały następujących elementów:

• Pojedynczy wolumin regularny usługi Azure NetApp Files z zestawem danych 1-TiB korzystającym z warstwy wydajności Ultra
• FIO (z ustawieniem i bez ustawienia randrepeat=0)
• 4-KiB i 64-KiB wsize/rsize
• Pojedyncza maszyna wirtualna D32s_v4 z systemem RHEL 9.3
• NFSv3 z systemem i bez nconnect
• Opcje instalacji: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

Testy porównawcze skalowania w górę

Celem testu skalowania w górę jest pokazanie wydajności woluminu usługi Azure NetApp File podczas skalowania w górę (lub zwiększania) liczby zadań generujących jednoczesne obciążenie w wielu połączeniach TCP na jednym kliencie do tego samego woluminu (na przykład za pomocą nconnectpolecenia ).

Bez nconnectsystemu te obciążenia nie mogą wypychać limitów maksymalnej wydajności woluminu, ponieważ klient nie może wygenerować wystarczającej przepływności operacji we/wy lub sieci. Te testy zazwyczaj wskazują na to, co może występować w obciążeniach pojedynczego użytkownika, takich jak renderowanie multimediów, bazy danych, sztuczna inteligencja/uczenie maszynowe i ogólne udziały plików.

Testy porównawcze skalowania operacji we/wy na dużą skalę operacji we/wy na poziomie

W poniższych testach porównawczych przedstawiono wydajność osiągniętą dla usługi Azure NetApp Files z wysokim obciążeniem we/wy operacji we/wy przy użyciu:

• 32 klientów
• 4-KiB i 8-KiB losowe odczyty i zapisy
• Zestaw danych 1 TiB
• Współczynniki odczytu/zapisu w następujący sposób: 100%:0%, 90%:10%, 80%:20%itd.
• W przypadku buforowania systemu plików i bez systemu plików (przy użyciu funkcji randrepeat=0 FIO)

Aby uzyskać więcej informacji, zobacz Metodologia testowania.

Wyniki: 4 KiB, losowe, buforowanie klienta uwzględnione

W tym teściu porównawczym narzędzie FIO działało bez randrepeat opcji losowania danych. W związku z tym, nieokreślona ilość buforowania weszła w grę. Ta konfiguracja powoduje nieco lepszą ogólną liczbę wydajności niż testy uruchamiane bez buforowania przy użyciu całego stosu operacji we/wy.

Na poniższym wykresie testowanie pokazuje, że zwykły wolumin usługi Azure NetApp Files może obsłużyć od około 130 000 czystych losowych zapisów 4-KiB i około 460 000 czystych losowych operacji odczytu KiB podczas tego testu porównawczego. Kombinacja odczytu i zapisu dla obciążenia dostosowanego o 10% dla każdego przebiegu.

W miarę wzrostu liczby operacji we/wy odczytu i zapisu w kierunku dużego obciążenia zapisu łączna liczba operacji we/wy na operacje we/wy spada.

Wyniki: 4 KiB, losowe, wykluczone buforowanie klienta

W tym teściu porównawczym funkcja FIO została uruchomiona z ustawieniem randrepeat=0 w celu losowania danych, co zmniejsza wpływ buforowania na wydajność. Spowodowało to około 8% zmniejszenie liczby operacji we/wy zapisu i około 17% redukcji operacji we/wy odczytu i operacji OPS, ale wyświetla liczby wydajności bardziej reprezentatywne dla tego, co magazyn może rzeczywiście zrobić.

Na poniższym wykresie testowanie pokazuje, że zwykły wolumin usługi Azure NetApp Files może obsłużyć od około 120 000 czystych losowych zapisów 4-KiB i około 388 000 czystych losowych operacji odczytu 4 KiB. Mieszanka odczytu i zapisu dla obciążenia dostosowanego o 25% dla każdego przebiegu.

W miarę wzrostu liczby operacji we/wy odczytu i zapisu w kierunku dużego obciążenia zapisu łączna liczba operacji we/wy na operacje we/wy spada.

Wyniki: 8 KiB, losowe, wykluczone buforowanie klienta

Większe rozmiary odczytu i zapisu spowodują mniejszą łączną liczbę operacji we/wy na platformie OPS, ponieważ więcej danych można wysyłać przy użyciu każdej operacji. Rozmiar odczytu i zapisu 8 KiB został użyty do dokładniejszego symulowania tego, czego używają większość nowoczesnych aplikacji. Na przykład wiele aplikacji EDA korzysta z odczytów i zapisów 8-KiB.

W tym tezie porównawczym narzędzie FIO zostało uruchomione z randrepeat=0 poleceniem w celu losowania danych, aby zmniejszyć wpływ buforowania klienta. Na poniższym wykresie testowanie pokazuje, że zwykły wolumin usługi Azure NetApp Files może obsłużyć od około 111 000 czystych losowych zapisów 8-KiB i około 293 000 czystych losowych odczytów 8-KiB. Mieszanka odczytu i zapisu dla obciążenia dostosowanego o 25% dla każdego przebiegu.

W miarę wzrostu liczby operacji we/wy odczytu i zapisu w kierunku dużego obciążenia zapisu łączna liczba operacji we/wy na operacje we/wy spada.

Porównania równoległe

Aby zilustrować, jak buforowanie może wpływać na testy porównawcze wydajności, na poniższym wykresie przedstawiono łączną liczbę testów we/wy na platformie OPS dla testów 4-KiB z mechanizmami buforowania i bez ich przechowywania. Jak pokazano, buforowanie zapewnia niewielki wzrost wydajności dla operacji we/wy na platformie OPS dość spójny trend.

Określone przesunięcie, przesyłanie strumieniowe losowych obciążeń odczytu/zapisu: testy skalowania w górę przy użyciu równoległych połączeń sieciowych (nconnect)

Poniższe testy pokazują wysoki test porównawczy operacji we/wy przy użyciu jednego klienta z obciążeniami losowymi 4-KiB i zestawem danych 1-TiB. Wygenerowana kombinacja obciążenia używa za każdym razem innej głębokości operacji we/wy. Aby zwiększyć wydajność pojedynczego obciążenia klienta, nconnect opcja instalacji została użyta do poprawy równoległości w porównaniu z instalacjami klientów bez nconnect opcji instalacji.

W przypadku korzystania ze standardowego połączenia TCP, które zapewnia tylko jedną ścieżkę do magazynu, mniejsza łączna liczba operacji jest wysyłana na sekundę niż w przypadku, gdy instalacja może korzystać z nconnectwiększej liczby połączeń TCP (takich jak ) na punkt instalacji. W przypadku korzystania z nconnectprogramu całkowite opóźnienie operacji jest na ogół niższe. Te testy są również uruchamiane za pomocą randrepeat=0 polecenia , aby celowo uniknąć buforowania. Aby uzyskać więcej informacji na temat tej opcji, zobacz Metodologia testowania.

Wyniki: 4 KiB, losowe, z i bez nconnect, buforowanie wykluczone

Na poniższych wykresach przedstawiono porównanie równoległe odczytów i zapisów 4-KiB z elementami i bez nconnect wyróżniania ulepszeń wydajności w przypadku korzystania z nconnectprogramu : wyższe ogólne opóźnienia operacji we/wy, mniejsze opóźnienia.

Testy porównawcze o wysokiej przepływności

Poniższe testy porównawcze pokazują wydajność osiągniętą dla usługi Azure NetApp Files z obciążeniem o wysokiej przepływności.

Obciążenia o wysokiej przepływności są bardziej sekwencyjne i często mają duże obciążenie odczytem/zapisem z niskimi metadanymi. Przepływność jest zazwyczaj ważniejsza niż we/wy na platformie OPS. Te obciążenia zwykle wykorzystują większe rozmiary odczytu/zapisu (od 64K do 256K), które generują większe opóźnienia niż mniejsze rozmiary odczytu/zapisu, ponieważ większe ładunki będą naturalnie trwać dłużej.

Przykłady obciążeń o wysokiej przepływności obejmują:

• Repozytoria multimediów
• Obliczenia o wysokiej wydajności
• Sztuczna inteligencja/uczenie maszynowe/LLP

Poniższe testy pokazują test porównawczy o wysokiej przepływności przy użyciu zestawów danych 64-KiB i 256-KiB i 256-KiB. Zestaw obciążeń wygenerowany jednocześnie zmniejsza wartość procentową zestawu i pokazuje, czego można oczekiwać podczas korzystania z różnych współczynników odczytu/zapisu (na przykład 100%:0%, 90%:10%, 80%:20%itd.).

Wyniki: 64 KiB sekwencyjne we/wy, buforowanie uwzględnione

W tym teście porównawczym fiO uruchamiało logikę pętli, która bardziej agresywnie wypełniła pamięć podręczną, więc nieokreślona ilość buforowania wpływała na wyniki. Powoduje to nieco lepszą ogólną liczbę wydajności niż testy uruchamiane bez buforowania.

Na poniższym wykresie testowanie pokazuje, że zwykły wolumin usługi Azure NetApp Files może obsłużyć między około 4500MiB/s czystych sekwencyjnych operacji odczytu 64-KiB i około 1600MiB/s czystych zapisów sekwencyjnych 64-KiB. Mieszanka odczytu i zapisu dla obciążenia została skorygowana o 10% dla każdego przebiegu.

Wyniki: 64 Sekwencyjne we/wy KiB, wykluczone buforowanie

W tym teście porównawczym fio uruchamiało logikę pętli, która mniej agresywnie wypełniała pamięć podręczną. Buforowanie klienta nie wpływało na wyniki. Ta konfiguracja skutkuje nieco lepszymi liczbami wydajności zapisu, ale niższymi liczbami odczytu niż testy bez buforowania.

Na poniższym wykresie testowanie pokazuje, że zwykły wolumin usługi Azure NetApp Files może obsłużyć między około 3600MiB/s czystych sekwencyjnych operacji odczytu 64-KiB i około 2400MiB/s czystych zapisów sekwencyjnych 64-KiB. Podczas testów mieszana 50/50 wykazała łączną przepływność na równi z czystym obciążeniem odczytu sekwencyjnego.

Mieszanka odczytu i zapisu dla obciążenia została skorygowana o 25% dla każdego przebiegu.

Wyniki: 256 KiB sekwencyjne we/wy, buforowanie wykluczone

W tym teście fiO uruchamiało logikę pętli, która mniej agresywnie wypełniła pamięć podręczną, więc buforowanie nie wpływało na wyniki. Ta konfiguracja powoduje nieznacznie mniejsze liczby wydajności zapisu niż testy 64-KiB, ale wyższe liczby odczytu niż te same testy 64-KiB są uruchamiane bez buforowania.

Na poniższym wykresie testowanie pokazuje, że zwykły wolumin usługi Azure NetApp Files może obsłużyć między około 3500MiB/s czystych sekwencyjnych operacji odczytu 256-KiB i około 2500MiB/s czystych zapisów sekwencyjnych 256-KiB. Podczas testów mieszana 50/50 wykazała łączną przepływność wyższą niż obciążenie odczytu sekwencyjnego.

Mieszanka odczytu i zapisu dla obciążenia została skorygowana o 25% przyrostów dla każdego przebiegu.

Porównanie równoległe

Aby lepiej pokazać, jak buforowanie może wpływać na testy porównawcze wydajności, na poniższym wykresie przedstawiono łączną liczbę testów MiB/s dla 64-KiB z mechanizmami buforowania i bez wprowadzania w pamięci podręcznej. Buforowanie zapewnia początkowy niewielki wzrost wydajności dla łącznej liczby miB/s, ponieważ buforowanie zwykle poprawia odczyty bardziej niż zapisy. W miarę zmiany kombinacji odczytu/zapisu łączna przepływność bez buforowania przekracza wyniki korzystające z buforowania klienta.

Równoległe połączenia sieciowe (nconnect)

Poniższe testy pokazują wysoki test porównawczy operacji we/wy przy użyciu pojedynczego klienta z losowymi obciążeniami 64 KiB i zestawem danych 1-TiB. Wygenerowana kombinacja obciążenia używa za każdym razem innej głębokości operacji we/wy. Aby zwiększyć wydajność pojedynczego obciążenia klienta, nconnect opcja instalacji została użyta w celu zapewnienia lepszej równoległości w porównaniu z instalacjami klientów, które nie korzystały z nconnect opcji instalacji. Te testy były uruchamiane tylko z wykluczonym buforowaniem.

Wyniki: 64 KiB, sekwencyjne, wykluczone buforowanie, z i bez nconnect

Poniższe wyniki pokazują wyniki testu skalowania w górę podczas odczytywania i zapisywania w fragmentach 4-KiB w instalacji NFSv3 na jednym kliencie z i bez równoległości operacji (nconnect). Wykresy pokazują, że wraz ze wzrostem głębokości we/wy zwiększa się również liczba operacji we/wy. Jednak w przypadku korzystania ze standardowego połączenia TCP, które zapewnia tylko jedną ścieżkę do magazynu, mniejsza łączna liczba operacji jest wysyłana na sekundę niż w przypadku, gdy instalacja może korzystać z większej liczby połączeń TCP na punkt instalacji. Ponadto całkowite opóźnienie operacji jest zwykle niższe w przypadku korzystania z programu nconnect.

Porównanie równoległe (z i bez nconnect)

Na poniższych wykresach przedstawiono porównanie równoległe odczytów sekwencyjnych i zapisów 64-KiB z funkcjami i bez nconnect wyróżniania ulepszeń wydajności widocznych podczas korzystania nconnectz : większa ogólna przepływność, mniejsze opóźnienia.

Więcej informacji

• Metodologia testowania