W przypadku wszystkich testów wymienionych powyżej stanowisko testowe posiadało klientów opisanych w Tabeli 2 poniżej. Ponieważ liczba węzłów obliczeniowych dostępnych do testów wynosiła tylko 16, gdy wymagana była większa liczba wątków, wątki te były równomiernie rozmieszczone na węzłach obliczeniowych (tj. 32 wątki = 2 wątki na węzeł, 64 wątki = 4 wątki na węzeł, 128 wątków = 8 wątków na węzeł, 256 wątków = 16 wątków na węzeł, 512 wątków = 32 wątki na węzeł, 1024 wątki = 64 wątki na węzeł). Celem było zasymulowanie większej liczby jednoczesnych klientów przy ograniczonej liczbie dostępnych węzłów obliczeniowych. Ponieważ niektóre testy porównawcze obsługują dużą liczbę wątków, zastosowano maksymalną wartość do 1024 (określoną dla każdego testu), jednocześnie unikając nadmiernego przełączania kontekstu i innych powiązanych efektów ubocznych wpływających na wyniki wydajności.

Tabela2. Stanowisko testowe klienta

Wydajność sekwencyjna IOzone N klientów do N plików

Wydajność sekwencyjnego połączenia N klientów z N plikami została zmierzona przy użyciu IOzone w wersji 3.487. Wykonane testy obejmowały od pojedynczego wątku do 1024 wątków zwiększanych w potęgach dwójki.

Efekty buforowania na serwerach zostały zminimalizowane poprzez ustawienie puli stron GPFS na 16 GB i używanie plików większych niż dwukrotność tego rozmiaru. Ważne jest, aby zauważyć, że w przypadku GPFS ten edytowalny parametr ustawia maksymalną ilość pamięci używanej do buforowania danych, niezależnie od ilości zainstalowanej i wolnej pamięci RAM. Należy również zauważyć, że podczas gdy w poprzednich rozwiązaniach DellEMC HPC rozmiar bloku dla dużych transferów sekwencyjnych wynosi 1 MB, GPFS został sformatowany z blokami 8 MB i dlatego ta wartość jest używana w teście porównawczym w celu uzyskania optymalnej wydajności. Może to wyglądać na zbyt duże i pozornie marnować zbyt dużo miejsca, ale GPFS używa alokacji podbloku, aby zapobiec takiej sytuacji. W obecnej konfiguracji każdy blok został podzielony na 256 podbloków po 32 KB każdy.

Poniższe polecenia zostały użyte do wykonania testu porównawczego dla zapisów i odczytów, gdzie $Threads było zmienną z liczbą używanych wątków (od 1 do 1024 zwiększanych w potęgach dwójki), a threadlist było plikiem, który przydzielał każdy wątek do innego węzła, używając round robin, aby rozłożyć je równomiernie na 16 węzłów obliczeniowych.

Aby uniknąć możliwych efektów buforowania danych z klientów, łączny rozmiar danych plików był dwukrotnie większy niż łączna ilość pamięci RAM używanych klientów. Oznacza to, że ponieważ każdy klient ma 128 GB pamięci RAM, dla liczby wątków równej lub większej niż 16 wątków rozmiar pliku wynosił 4096 GB podzielonych przez liczbę wątków (zmienna $Size poniżej została użyta do zarządzania tą wartością). W przypadku mniej niż 16 wątków (co oznacza, że każdy wątek był uruchomiony na innym kliencie) rozmiar pliku został ustalony na dwukrotnie większą ilość pamięci na klienta, czyli 256 GB.

iozone -i0 -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./threadlist
iozone -i1 -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./threadlist

Rysunek 2. Wydajność sekwencyjna N do N

Na podstawie wyników możemy zaobserwować, że wydajność zapisu wzrasta wraz z liczbą używanych wątków, a następnie osiąga punkt wypłaszczenia na poziomie około 64 wątków dla zapisu i 128 wątków dla odczytów. Wydajność odczytu również szybko rośnie wraz z liczbą wątków, a następnie pozostaje stabilna do momentu osiągnięcia maksymalnej liczby wątków dozwolonej przez IOzone, a zatem wydajność sekwencyjna dużych plików jest stabilna nawet dla 1024 jednoczesnych klientów. Wydajność zapisu spada o około 10% przy 1024 wątkach. Ponieważ jednak klaster kliencki ma mniej rdzeni, nie ma pewności, czy spadek wydajności jest spowodowany wymianą i podobnym obciążeniem, którego nie obserwuje się w przypadku obracających się nośników (ponieważ opóźnienie NVMe jest bardzo niskie w porównaniu z obracającymi się nośnikami), czy też synchronizacja danych RAID 10 staje się wąskim gardłem. Potrzeba więcej klientów, aby wyjaśnić tę kwestię. Anomalię odczytów zaobserwowano w 64 wątkach, gdzie wydajność nie skalowała się z szybkością obserwowaną dla poprzednich punktów danych, a następnie w kolejnym punkcie danych przesuwała się do wartości bardzo zbliżonej do trwałej wydajności. Potrzebne są dalsze testy, aby znaleźć przyczynę takiej anomalii, ale wykracza to poza zakres tego wpisu.

Maksymalna wydajność odczytu dla odczytów była niższa od teoretycznej wydajności urządzeń NVMe (~102 GB/s) lub wydajności łączy EDR, nawet przy założeniu, że jedno łącze było najczęściej używane dla ruchu NVMe over fabric (4x EDR BW ~96 GB/s).
Nie jest to jednak niespodzianką, ponieważ konfiguracja sprzętowa nie jest zrównoważona w odniesieniu do urządzeń NVMe i IB HCA pod każdym gniazdem procesora. Jeden adapter CX6 znajduje się pod procesorem CPU1, podczas gdy procesor CPU2 ma wszystkie urządzenia NVMe i drugi adapter CX6. Wszelki ruch związany z pamięcią masową korzystający z pierwszego HCA musi korzystać z UPI, aby uzyskać dostęp do urządzeń NVMe. Ponadto każdy używany rdzeń procesora CPU1 musi mieć dostęp do urządzeń lub pamięci przypisanej do procesora 2, więc cierpi na tym lokalność danych i używane są łącza UPI. To może wyjaśniać redukcję maksymalnej wydajności w porównaniu z maksymalną wydajnością urządzeń NVMe lub prędkością łącza dla CX6 HCA. Alternatywą dla rozwiązania tego problemu jest zrównoważona konfiguracja sprzętowa, która oznacza zmniejszenie gęstości o połowę poprzez zastosowanie R740 z czterema gniazdami x16 i użyciem dwóch ekspanderów PCIe x16 w celu równomiernego rozmieszczenia urządzeń NVMe na dwóch procesorach oraz posiadanie jednego CX6 HCA pod każdym procesorem.

Wydajność sekwencyjna IOR N klientów do 1 pliku

Wydajność sekwencyjnego połączenia N klientów do pojedynczego współdzielonego pliku została zmierzona za pomocą IOR w wersji 3.3.0, wspomaganego przez OpenMPI v4.0.1 w celu uruchomienia benchmarku na 16 węzłach obliczeniowych. Wykonywane testy wahały się od jednego wątku do 512 wątków, ponieważ nie było wystarczającej liczby rdzeni dla 1024 lub więcej wątków. W tym teście porównawczym wykorzystano bloki 8 MB w celu uzyskania optymalnej wydajności. Poprzednia sekcja testu wydajności zawiera pełniejsze wyjaśnienie, dlaczego ma to znaczenie.

Efekty buforowania danych zostały zminimalizowane przez ustawienie puli stron GPFS na 16 GB, a całkowity rozmiar pliku był dwukrotnie większy niż całkowita ilość pamięci RAM w używanych klientach. Oznacza to, że ponieważ każdy klient ma 128 GB pamięci RAM, w przypadku liczby wątków równej lub większej niż 16 wątków rozmiar pliku wynosił 4096 GB, a taka sama część tej sumy została podzielona przez liczbę wątków (zmienna $Size poniżej została użyta do zarządzania tą wartością). W przypadkach z mniej niż 16 wątkami (co oznacza, że każdy wątek był uruchomiony na innym kliencie), rozmiar pliku był dwukrotnie większy niż ilość użytej pamięci na klienta razy liczba wątków, czyli innymi słowy, każdy wątek został poproszony o użycie 256 GB.

Poniższe polecenia zostały użyte do wykonania testu porównawczego dla zapisów i odczytów, gdzie $Threads było zmienną z liczbą używanych wątków (od 1 do 1024 zwiększanych w potęgach dwójki), a my_hosts.$Threads to odpowiedni plik, który przydzielał każdy wątek do innego węzła, używając round robin, aby rozłożyć je równomiernie na 16 węzłów obliczeniowych.

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -w -s 1 -t 8m -b $ G

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -r -s 1 -t 8m -b $ G

Rysunek 3. Wydajność sekwencyjna N do 1

Na podstawie wyników możemy zaobserwować, że wydajność odczytu i zapisu jest wysoka, niezależnie od ukrytej potrzeby mechanizmów blokujących, ponieważ wszystkie wątki mają dostęp do tego samego pliku. Wydajność ponownie rośnie bardzo szybko wraz z liczbą używanych wątków, a następnie osiąga punkt wypłaszczenia, który jest stosunkowo stabilny dla odczytów i zapisów aż do maksymalnej liczby wątków używanych w tym teście. Zwróć uwagę, że maksymalna wydajność odczytu wyniosła 51,6 GB/s przy 512 wątkach, ale punkt wypłaszczenia wydajności jest osiągany przy około 64 wątkach. Należy również zauważyć, że maksymalna wydajność zapisu 34,5 GB/s została osiągnięta przy 16 wątkach i osiągnęła punkt wypłaszczenia, który można zaobserwować aż do maksymalnej liczby używanych wątków.

Losowe małe bloki — wydajność IOzone N klientów do N plików

Wydajność losowego połączenia N klientów z N plikami została zmierzona przy użyciu IOzone w wersji 3.487. Wykonane testy obejmowały od pojedynczego wątku do 1024 wątków zwiększanych w potęgach dwójki.

Wykonywane testy wahały się od jednego wątku do 512 wątków, ponieważ nie było wystarczającej liczby rdzeni klienckich dla 1024 wątków. Każdy wątek korzystał z innego pliku, a wątki były przydzielane w systemie round robin na węzłach klienckich. W tym teście porównawczym wykorzystano bloki 4 kB do emulacji ruchu małych bloków i przy użyciu głębokości kolejki 16. Porównywane są wyniki zastosowania rozwiązania o dużych rozmiarach i zwiększenia pojemności.

Efekty buforowania zostały ponownie zminimalizowane poprzez ustawienie puli stron GPFS na 16 GB i aby uniknąć możliwych efektów buforowania danych z klientów, całkowity rozmiar danych plików był dwukrotnie większy niż całkowita ilość pamięci RAM w używanych klientach. Oznacza to, że ponieważ każdy klient ma 128 GB pamięci RAM, dla liczby wątków równej lub większej niż 16 wątków rozmiar pliku wynosił 4096 GB podzielonych przez liczbę wątków (zmienna $Size poniżej została użyta do zarządzania tą wartością). W przypadku mniej niż 16 wątków (co oznacza, że każdy wątek był uruchomiony na innym kliencie) rozmiar pliku został ustalony na dwukrotnie większą ilość pamięci na klienta, czyli 256 GB.

iozone -i0 -I -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./nvme_threadlist                                     <= Utwórz pliki sekwencyjnie
iozone -i2 -I -c -O -w -r 4k -s $ G -t $Threads -+n -+m ./nvme_threadlist                                      <= Wykonaj losowe odczyty i zapisy.

Rysunek 4. Wydajność losowa N do N

Na podstawie wyników możemy zaobserwować, że wydajność zapisu zaczyna się od wysokiej wartości 6 tys. operacji we/wy i stale rośnie do 1024 wątków, gdzie wydaje się, że osiąga punkt wypłaszczenia z ponad 5 mln operacji we/wy, jeśli można użyć więcej wątków. Z drugiej strony wydajność odczytu zaczyna się od 5 tys. operacji we/wy i wzrasta równomiernie wraz z liczbą używanych wątków (należy pamiętać, że liczba wątków jest podwajana dla każdego punktu danych) i osiąga maksymalną wydajność 7,3 mln operacji we/wy przy 1024 wątkach bez oznak osiągnięcia punktu wypłaszczenia. Korzystanie z większej liczby wątków będzie wymagało więcej niż 16 węzłów obliczeniowych, aby uniknąć głodu zasobów i nadmiernego zamieniania, które może obniżyć pozorną wydajność, podczas gdy węzły NVMe mogłyby w rzeczywistości utrzymać wydajność.

Wydajność metadanych w teście MDtest przy użyciu plików 4 kB

Wydajność metadanych została zmierzona za pomocą MDtest w wersji 3.3.0, wspomaganego przez OpenMPI v4.0.1 w celu uruchomienia benchmarku na 16 węzłach obliczeniowych. Wykonane testy obejmowały od pojedynczego wątku do 512 wątków. Test porównawczy został użyty tylko dla plików (bez metadanych katalogów), co pozwoliło uzyskać liczbę utworzeń, statystyk, odczytów i usunięć, które rozwiązanie może obsłużyć, a wyniki zostały porównane z rozwiązaniem o dużym rozmiarze.

Zastosowano opcjonalny moduł metadanych o wysokim zapotrzebowaniu, jednak w konfiguracji z jedną macierzą ME4024, choć duża konfiguracja testowana w tej pracy przewidywała dwie macierze ME4024. Powodem korzystania z tego modułu metadanych jest fakt, że obecnie te węzły NVMe są używane jako obiekty docelowe pamięci masowej tylko dla danych. Jednak węzły mogą być używane do przechowywania danych i metadanych, a nawet jako alternatywa flash dla modułu metadanych o wysokim zapotrzebowaniu, jeśli wymagają tego ekstremalne wymagania dotyczące metadanych. Konfiguracje te nie zostały przetestowane w ramach tych prac.

Ponieważ ten sam moduł metadanych o wysokim zapotrzebowaniu był używany do poprzednich testów porównawczych rozwiązania DellEMC Ready Solution dla rozwiązania pamięci masowej HPC PixStor, wyniki metadanych będą bardzo podobne w porównaniu z wynikami z poprzedniego wpisu. Z tego powodu nie przeprowadzono badania z pustymi plikami, a zamiast tego użyto plików 4 KB. Ponieważ pliki 4 KB nie mieszczą się w i-węźle wraz z informacjami o metadanych, węzły NVMe będą używane do przechowywania danych dla każdego pliku. W związku z tym MDtest może dać przybliżone wyobrażenie o wydajności małych plików dla odczytów i pozostałych operacji na metadanych.

Poniższe polecenie zostało użyte do wykonania testu porównawczego, gdzie $Threads było zmienną z liczbą używanych wątków (od 1 do 512 zwiększanych w potęgach dwójki), a my_hosts.$Threads to odpowiedni plik, który przydzielał każdy wątek do innego węzła, używając round robin, aby rozłożyć je równomiernie na 16 węzłów obliczeniowych. Podobnie jak w teście porównawczym losowych operacji IO, maksymalna liczba wątków została ograniczona do 512, ponieważ nie ma wystarczającej liczby rdzeni dla 1024 wątków, a przełączanie kontekstu wpłynęłoby na wyniki, zgłaszając liczbę niższą niż rzeczywista wydajność rozwiązania.

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F -w 4K -e 4K

Ponieważ na wyniki wydajności może mieć wpływ całkowita liczba operacji we/wy, liczba plików na katalog i liczba wątków, zdecydowano się utrzymać całkowitą liczbę plików na stałym poziomie 2 MB (2^21 = 2097152), liczbę plików na katalog na stałym poziomie 1024, a liczba katalogów zmieniała się wraz ze zmianą liczby wątków, jak pokazano w Tabeli 3.

Tabela 3. Mdtest — rozkład plików w katalogach

Rysunek 5. Wydajność metadanych — pliki 4 KB

Po pierwsze należy zauważyć, że wybrana skala była skalą logarytmiczną o podstawie 10, ponieważ umożliwiała porównywanie operacji, które różnią się o kilka rzędów wielkości; w przeciwnym razie niektóre operacje wyglądałyby jak płaska linia bliska 0 na skali liniowej. Wykres logarytmiczny o podstawie 2 mógłby być bardziej odpowiedni, ponieważ liczba wątków jest zwiększana w potęgach 2, ale wykres wyglądałby bardzo podobnie, a ludzie lepiej liczą i zapamiętują liczby oparte na potęgach 10.

System uzyskuje bardzo dobre wyniki, jak wcześniej informowano, przy czym operacje Stat osiągają szczytową wartość przy 64 wątkach przy prawie 6,9 mln operacji na sekundę, a następnie są zmniejszane w przypadku większej liczby wątków, osiągając punkt wypłaszczenia. Operacje Create osiągają maksymalną liczbę operacji na poziomie 113 tys./s przy 512 wątkach, dlatego oczekuje się, że będą nadal rosnąć, jeśli będzie używanych więcej węzłów klienckich (i rdzeni). Operacje Reads i Removes osiągnęły maksymalną liczbę 128 wątków, osiągając maksymalną wartość prawie 705 tys. operacji na sekundę dla Reads i 370 tys. operacji na sekundę dla Removes, a następnie osiągają punkt wypłaszczenia. Operacje Stat charakteryzują się większą zmiennością, ale po osiągnięciu wartości szczytowej wydajność nie spada poniżej 3,2 mln operacji na sekundę dla Stats. Operacje Create i Removal są bardziej stabilne, gdy osiągną punkt wypłaszczenia i utrzymują się powyżej 265 tys. operacji na sekundę dla Removal i 113 tys. operacji na sekundę dla Create. Wreszcie odczyty osiągają punkt wypłaszczenia z wydajnością powyżej 265 tys. operacji/s.

Wnioski i przyszłe prace

Węzły NVMe są ważnym dodatkiem do rozwiązania pamięci masowej HPC, ponieważ zapewniają bardzo wysoką wydajność z dobrą gęstością, bardzo wysoką wydajnością dostępu losowego i bardzo wysoką wydajnością sekwencyjną. Ponadto pojemność i wydajność rozwiązania skaluje się liniowo w miarę dodawania kolejnych modułów węzłów NVMe. Wydajność węzłów NVMe została przedstawiona w Tabeli 4. Powinna być stabilna, a wartości te można wykorzystać do oszacowania wydajności dla różnej liczby węzłów NVMe.
Należy jednak pamiętać, że każda para węzłów NVMe zapewni połowę dowolnej liczby przedstawionej w Tabeli 4.
Rozwiązanie to zapewnia klientom HPC bardzo niezawodny równoległy system plików wykorzystywany przez wiele klastrów HPC z listy Top 500. Ponadto zapewnia wyjątkowe możliwości wyszukiwania, zaawansowane monitorowanie i zarządzanie, a dodanie opcjonalnych bramek umożliwia udostępnianie plików za pośrednictwem wszechobecnych standardowych protokołów, takich jak NFS, SMB i innych, dowolnej liczbie klientów.

Tabela 4. Szczytowa i utrzymująca się wydajność dla 2 par węzłów NVMe

Ponieważ węzły NVMe były używane tylko do danych, ewentualne przyszłe prace mogą obejmować wykorzystanie ich do danych i metadanych oraz mieć niezależną warstwę opartą na pamięci flash z lepszą wydajnością metadanych ze względu na większą przepustowość i mniejsze opóźnienia urządzeń NVMe w porównaniu z dyskami SSD SAS3 znajdującymi się za kontrolerami RAID. Alternatywnie, jeśli klient ma bardzo wysokie wymagania dotyczące metadanych i potrzebuje rozwiązania bardziej zagęszczonego niż to, co może zapewnić moduł metadanych o wysokim zapotrzebowaniu, niektóre lub wszystkie urządzenia rozproszonej macierzy RAID 10 mogą być używane do metadanych w taki sam sposób, w jaki obecnie używane są urządzenia RAID 1 w ME4024.
Kolejny wpis na blogu, który zostanie opublikowany wkrótce, będzie zawierał opis węzłów PixStor Gateway, które umożliwiają podłączenie rozwiązania PixStor do innych sieci za pomocą protokołów NFS lub SMB i mogą skalować wydajność. Ponadto rozwiązanie wkrótce zostanie zaktualizowane do HDR100, a kolejny wpis na blogu poświęcony będzie tym pracom.