PowerStore: Skuteczne techniki oceny wydajności macierzy pamięci masowej

Uwaga: Test porównawczy jest prawidłowy tylko wtedy, gdy wszystko zostało skonfigurowane zgodnie z najlepszymi praktykami PowerStore i nie występują problemy z łącznością lub konfiguracją. W przeciwnym razie test prawdopodobnie wygeneruje nieistotne dane.

• Testuj przy użyciu zmiennych, które przypominają rzeczywiste obciążenie/środowisko. Należy pamiętać, że większość narzędzi to symulatory i nigdy nie osiągniemy 100% symulowanego rzeczywistego obciążenia produkcyjnego.
• Jeśli obciążenie jest bardzo szerokie, rozważ wykonanie wielu iteracji testów odczytu/zapisu z różnymi rozmiarami bloków i wzorcami dostępu.
• Używaj wielowątkowych i asynchronicznych operacji lub testów, aby zapewnić równoległą lub jednoczesną wydajność i upewnić się, że wykorzystywany jest ogólny potencjał zagregowanej przepływności. 
• Rozważ i przejrzyj standardowe branżowe testy porównawcze dla ocenianego sprzętu, ponieważ odnoszą się one do obciążenia produkcyjnego Twojej firmy.
• Należy unikać testowania pustego lub mało miejsca w systemie plików i/lub woluminach. Jeśli nie przydzielisz wstępnie miejsca dla obciążeń zapisu, podczas testu możesz zauważyć opóźnienie spowodowane alokacją miejsca w locie.
• Należy pamiętać o przetestowaniu opcji odczytu we/wy, ponieważ w większości środowisk jest ona zwykle dominująca. Należy pamiętać o utracie pakietów/ramek w infrastrukturze sieciowej podczas testowania.
• Sprawdź, czy przeprowadzasz test na wielu urządzeniach, aby zasymulować typowe środowisko z wieloma hostami lub klientami. Na przykład w przypadku urządzeń PowerStore prawidłowa liczba to 16 woluminów. Liczba woluminów zazwyczaj odpowiada liczbie używanych hostów lub klientów (fizycznych lub wirtualnych); W tym miejscu uzyskuje się współbieżność.

 

Narzędzia i symulatory testów porównawczych
Należy pamiętać, że większość narzędzi to symulatory i prawdopodobnie nigdy nie zostaną zasymulowane 100% rzeczywistego obciążenia produkcyjnego. Te narzędzia porównawcze służą do zorientowania się, jaka może być, powinna lub byłaby wydajność w określonych sytuacjach. Firma Dell nie jest właścicielem tych narzędzi i nie ponosi odpowiedzialności za jakiekolwiek problemy, które mogą być z nimi związane.

W każdej sytuacji testowania wydajności upewnij się, że używane są narzędzia z możliwościami asynchronicznymi i wielowątkowymi. Przykładami takich narzędzi są:

• Elastyczny tester we/wy (FIO)
• IOmeter
• Vdbench (wymaga konta Oracle)
• NFSometer (Tylko Fedora/NFS)
• Lista kontrolna wydajności NAS firmy Intel

 

Unikaj następujących typów testów:

• Kopiowanie i wklejanie
• Przeciągnij i upuść
• Kopia zapasowa pojedynczego systemu plików na dysku
• Testy DD
• Powiększ
• Powiększony
• mkfile (plik_mk)
• Rozpakowywanie i kompresowanie

Istnieją pewne rzeczy, o których należy pamiętać w większości scenariuszy oceny porównawczej. Ta sekcja nie zastępuje zrozumienia rozmiaru i charakterystyki obciążenia. Jeśli jednak nie masz danych z przeszłości i potrzebujesz przybliżonego oszacowania zachowania aplikacji w celu porównania możliwości PowerStore (a nie wydajności konkretnego obciążenia roboczego), weź pod uwagę następujące czynniki:

 

 

IODepth(głębokość kolejki)
Niska (lub niewystarczająco wysoka) głębokość we/wy może ograniczyć potencjalną przepustowość w zależności od sytuacji. W związku z tym należy zawsze sprawdzić, czy IOdepth jest wystarczająco wysokie, aby odzwierciedlić lub emulować wymagania dotyczące współbieżności obciążenia. Zbyt mała głębokość we/wy może nie wykorzystywać w pełni potencjału urządzenia. Należy również uważać na zbyt dużą głębokość we/wy, ponieważ może to spowodować znaczne kolejkowanie na urządzeniu, w wyniku czego mogą wystąpić dłuższe czasy reakcji w zależności od czasu serwisowania urządzenia. Może to odzwierciedlać to, jak może wyglądać przeciążony system.

W tym teście liczby są znacznie niższe, gdy istnieje IOdepth równy jeden w porównaniu z IOdepth czegoś bardziej rzeczywistego, takiego jak 64. Należy pamiętać, że dotyczy to macierzy all-flash, a zatem koncepcja ta jest postrzegana w swojej ekstremalnej, ale coraz bardziej powszechnej formie.

IOdepth=1" wynosi około ~30 000 operacji wejścia i wyjścia na sekundę (IOPS) dla testu.

 

"IOdepth=64" to około ~107 000 IOPS dla testu.

 

 

"IOdepth=256" to około ~142 000 IOPS dla testu.

 

 

Jak wspomniano, w większości konfiguracji wydajność jest osiągana przy określonej głębokości we/wy. W tym przypadku głębokość kolejki wynosi 512 i występuje tylko niewielki wzrost IOPS z głębokości we/wy wynoszącej 64".

IOdepth=512" jest to około ~146 000 IOPS śr. dla testu.

 

 


Asynchroniczne a synchroniczne
Stosowane są dwa główne silniki. Najpopularniejsze i zdecydowanie najbardziej wydajne pod względem wydajności są "asynchroniczne wejścia/wyjścia". Mniej wydajnym i mniej wydajnym silnikiem jest synchroniczne we/wy i jest zwykle używany w aplikacjach, które mają surowe wymagania dotyczące integralności i bezpieczeństwa danych. Synchroniczne wejścia/wyjścia można również znaleźć w technologiach replikacji bliskich zeru Recovery Point Objective (RPO). W testach wydajności i benchmarkingu z perspektywy hosta asynchroniczny oznacza, że potwierdzenie nie jest potrzebne dla pojedynczego wejścia/wyjścia, aby zażądać następnego wejścia/wyjścia. W przypadku obciążeń synchronicznych wymagane jest potwierdzenie dla operacji we/wy przed wydaniem następnego oraz potwierdzenie (ACK) dla każdego kolejnego żądanego we/wy. W związku z tym synchroniczne we/wy zwykle mają kolejkę 1 lub mniejszą i nigdy w pełni nie wykorzystują pełnego potencjału zasobu. Sprzężenie operacji synchronicznych z niską lub pojedynczą liczbą wątków może poważnie ograniczyć potencjał wydajności, dlatego zawsze sprawdzaj, czy wykonujesz testowanie asynchroniczne, a jeśli używasz testowania synchronicznego, pamiętaj o zastosowaniu wielu wątków, chyba że środowisko aplikacji wyraźnie wskaże, aby tego nie robić.

Async (Libaio — natywny system Linux async) = 1 wątek



Sync (synchroniczne we/wy):  

 

 

Liczba
wątkówWątki są ważne. Testowanie powinno być zawsze wykonywane przy użyciu wielu wątków, szczególnie w testach/obciążeniach synchronicznych. Jest to próba symulowania wielu iteracji zadania/testu na podstawie zachowania procesu aplikacji korporacyjnej. Wiele wątków w połączeniu z współbieżnymi działaniami to miejsca, w których osiągana jest zagregowana przepływność systemu. Większość silników asynchronicznych wykorzystuje wiele wątków, więc nie musisz się tak bardzo martwić o liczbę wątków. Bez wystarczającej liczby wątków podczas synchronicznych obciążeń roboczych można poważnie ograniczyć całkowitą potencjalną przepływność testu obciążenia dla systemu".

"Wielowątkowość" oznacza wiele wątków wykonujących pracę równolegle. Jeśli na przykład masz jedno urządzenie, które może obsłużyć 1000 operacji we/wy na sekundę w obciążeniu synchronicznym, oznacza to, że urządzenie ma czas odpowiedzi 1 ms bez kolejki (więc bez kolejki czas usługi i czas odpowiedzi powinny być synonimami). Oczywiście urządzenia z czasem reakcji 1 ms mogą wykonać znacznie więcej pracy niż 1000 IOPS, a osiąga się to poprzez układanie wielu wątków lub równoległych strumieni tego samego obciążenia. Tak więc, jeśli zwiększysz wątki (lub "rzeczy wykonujące tę konkretną pracę") do 10, teraz masz 10 pojedynczych wątków wykonujących operacje we/wy do urządzenia z prędkością 1 ms. Każdy pojedynczy wątek obciążenia nadal otrzymuje 1 ms, co oznacza, że każdy wątek nadal osiąga tylko 1000 IOPS, ale teraz cały "proces" lub "zadanie", które jest uruchamiane przez te wiele wątków, uzyskuje 10 000 IOPS.

Istnieją narzędzia i obciążenia, które mogą odpowiednio osiągnąć limity urządzenia za pomocą jednego wątku, a niektóre wymagają więcej. Podsumowując, podczas symulowania obciążenia synchronicznego chcesz mieć jak najwięcej wątków/procesów roboczych/strumieni bez wpływu na ogólny czas odpowiedzi. Jest moment, w którym zwiększenie liczby wątków przestaje przynosić pozytywny efekt (gdy urządzenie staje się w 100% zajęte). Ogólnie rzecz biorąc, w przypadku obciążeń asynchronicznych liczba wątków jest domyślnie obsługiwana. Na przykład poniżej nadal widać różnicę między 1 wątkiem a 10 dla obciążenia asynchronicznego, choć nie jest znacząca. Morał z tej historii jest taki, że w przypadku obciążeń asynchronicznych nie należy się tak bardzo martwić o wątki. 

Pojedynczy wątek w tym miejscu może osiągnąć 68 000 IOPS przy użyciu silnika "libaio" (asynchronicznego). 

 

Jeśli zwiększysz liczbę wątków (numjobs) do 10, nadal możesz zauważyć wzrost IOPS.

 

Jeśli chodzi o synchroniczne obciążenia robocze, chociaż jest to skrajny przypadek, możesz mieć dwa główne czynniki, które sprawiają, że test wydajności jest zły, a mianowicie synchroniczny charakter. 

wyślij I/O-1, poczekaj na ACK, wyślij I/O-2, poczekaj na ACK itd

 I brak możliwości układania wielu wątków w tym samym celu. 

job1=wyślij I/O-1 - job2=wyślij I/O-1 - job3=wyślij I/O-1..... job1=pobierz ack, wyślij I/O-2 - job2=pobierz ack, wyślij I/O-2 - job3= pobierz ack, wyślij I/O-2 itd

Flaga bezpośrednia

W przypadku niektórych narzędzi, zwłaszcza *nix-based tools/OS, może pojawić się opcja "Direct I/O". Może to być używane z silnikami "asynchronicznymi" i nie należy go mylić z "synchronicznymi" wejściami/wyjściami. W niektórych narzędziach bez określonej tej flagi można zapisywać w pamięci podręcznej serwera, a nie bezpośrednio na dysku. To, co host chce zrobić, to ominąć własną pamięć podręczną i zapisać bezpośrednio na dysku. Jest to istotny czynnik podczas testowania pamięci masowej. Kiedy masz ustawioną flagę "direct", technicznie zapisujesz na dysku, chociaż "disk" w tym przypadku jest tak naprawdę pamięcią podręczną. Jest to nadal akceptowalne do celów testowych, ponieważ nawet przy prawidłowym obciążeniu nadal symulujesz i dokładnie naśladujesz, jak to obciążenie zachowuje się w rzeczywistym środowisku, ponieważ obciążenie produkcyjne również trafi do pamięci podręcznej przed odesłaniem potwierdzenia. (Nie czuj się oszukany tylko dlatego, że w grę wchodzą dane dotyczące wydajności pamięci podręcznej, a nie tylko wrzecion zaplecza).

 

Przepustowość (MB/s) a przepływność (IOPS)

Istnieją dwie główne perspektywy, które można przetestować. Przepływność w świecie sieci i wydajności zwykle odnosi się do transferu danych, jednak w środowisku SAN/blokowym często używa się "przepływności" do reprezentowania IOPS. W związku z tym należy najpierw zrozumieć charakterystykę obciążenia, które jest testowane.

Przepustowość (MB/s) - Przepustowość to miara danych, które można zmieścić jednocześnie (lub w przedziale X, zwykle "na sekundę") w potoku lub systemie. Oznacza to, że mierzy ilość danych, które zostały przesłane w danym okresie czasu. Chociaż przepustowość i IOPs nie wykluczają się wzajemnie, możesz mieć wyższe lub niższe liczby przepustowości przy tej samej liczbie IOPS, wszystko zależy od rozmiaru bloku. Pamiętaj, że prędkość nie jest mierzona za pomocą przepustowości, szybkość jest czymś zupełnie innym i chociaż wpływa na przepustowość, zwykle jest to coś, czego nie można kontrolować przy obciążeniach o dużej przepustowości. W związku z tym, jeśli testujesz przepustowość, zawsze używaj większych bloków (w granicach rozsądku), aby dane na we/wy były większe niż w przypadku testowania IOPS, ponieważ większe bloki naturalnie będą obsługiwać dłużej. Jeśli, na przykład, chcesz osiągnąć 1 MB/s, ale używasz rozmiaru bloku 8 KB, musisz przesunąć około 125 IOPS, aby to osiągnąć. Jeśli jednak używasz bloków 512 KB, zajmie to tylko dwa (2) IOPS.
(Jeśli zachowasz 125 IOPS i nadal zwiększysz rozmiar bloku z 8 KB do 512 KB, teraz naciskasz 64 MB/s!)

Jednak ze względu na to, że w jednym porcie we/wy znajduje się więcej danych, "spakowanie" tego wejścia/wyjścia (znalezienie, połączenie i tak dalej) zajmuje zwykle więcej czasu. W związku z tym czasy obsługi mogą być naturalnie dłuższe. Czasami masz mniejszą kolejkę, więc Twoje czasy odpowiedzi, choć naturalnie wyższe, powinny być raczej zbliżone. Należy pamiętać, że chociaż czas reakcji odgrywa rolę w zakresie przepustowości, jaką można osiągnąć, wzrost ilości danych na operację we/wy zwykle przeważa nad nieznacznym wydłużeniem czasu odpowiedzi (RT) dla każdego typu operacji we/wy. Ponieważ czasy odpowiedzi są dłuższe, nie chcesz, aby obciążenia dużych bloków musiały być losowe. W związku z tym obciążenia robocze przepustowości są zwykle sekwencyjne. Po wprowadzeniu losowego charakteru do dużego obciążenia blokowego stała szybkość przesyłania danych jest stale przerywana, a użytkownik zaczyna odczuwać skutki nieco dłuższych czasów reakcji na we/wy.

Przepływność (IOPs) — przepływność/wydajność we/wy na sekundę to najczęstsza perspektywa w przypadku obciążeń małych bloków, zwłaszcza gdy stają się one bardziej losowe. Wszystko powyżej 32 KB-64 KB można uznać za duży blok. W przypadku przepływności najważniejsze są wyżej wymienione czynniki (takie jak liczba wątków, synchronizacja lub asynchroniczność, głębokość kolejki i tak dalej). Tutaj próbujesz zmierzyć nie to, ile danych możesz przesłać w przedziale X, ale raczej ile pojedynczych pakietów (żądań I/O) przenoszących te dane próbujesz obsłużyć (co x interwału). Środowiska takie jak OLTP (bankowość) nie dbają o to, ile danych mogą przesyłać, ponieważ ich ślad węglowy jest zwykle niewielki. Jednak te małe zbiory danych mogą być i zwykle są zajęte. Te zestawy danych mają duże pochylenie (odwołuje się do niewielkiej ilości miejsca, ale zmieniają się agresywnie i konsekwentnie). Małe pakiety danych zwykle zawierają tylko żądania zmiany/aktualizacji bloków z liczbowymi lub mniejszymi wartościami ciągów, a zatem duże pakiety I/O nie są wymagane. Jednak ze względu na charakter transakcji i fakt, że jest ich tak wiele, chcemy zweryfikować, czy jesteśmy w stanie nadążyć za każdym indywidualnym zapotrzebowaniem. Zazwyczaj im mniejszy rozmiar bloku, tym więcej operacji we/wy na sekundę można osiągnąć w danym scenariuszu, i chociaż małe obciążenia bloku są w większości związane z dostępem swobodnym, można osiągnąć jeszcze większą przepływność przy małych sekwencyjnych obciążeniach bloków. Jednak obciążenia sekwencyjne małych bloków są specyficzne i nie są tak powszechne, dlatego przetestuj te scenariusze tylko wtedy, gdy środowisko tego wymaga.