Rozwiązanie Dell EMC Ready dla pamięci masowej HPC PixStor — rozszerzenie pojemności

None

Spis treści

1. Wprowadzenie
   1. Architektura rozwiązania
   2. Elementy rozwiązania
2. Charakterystyka wydajności
   1. Sekwencyjne klienty IOzone Performance N do plików N
   2. Sekwencyjne klienty IOR Performance N do 1 pliku
   3. Losowe małe bloki klientów IOzone Performance N do plików N
   4. Wydajność metadanych z MDtest przy użyciu pustych plików
   5. Wydajność metadanych z MDtest przy użyciu 4 plików KiB
3. Wnioski i przyszłe prace

 

---

Wprowadzenie

Dzisiejsze środowiska HPC zwiększają zapotrzebowanie na bardzo szybką pamięć masową, która również często wymaga dużej pojemności i rozproszonego dostępu za pośrednictwem kilku standardowych protokołów, takich jak NFS, SMB i inne. Te wymagania hpc wysokiego popytu są zazwyczaj objęte równoległymi systemami plików, które zapewniają jednoczesny dostęp do jednego pliku lub zestawu plików z wielu węzłów, bardzo wydajnie i bezpiecznie rozprowadzając dane do wielu jednostek LUN na kilku serwerach.

 

---

Architektura rozwiązania

Ten blog to rozwiązanie równoległego systemu plików (PFS) dla środowisk HPC, rozwiązanie DellEMC Ready dla pamięci masowej HPC PixStor, w którym macierze POWERVault ME484 EBOD służą do zwiększenia pojemności rozwiązania. Rysunek 1 Przedstawia architekturę referencyjną przedstawiającą rozszerzenia pojemności SAS do istniejących macierzy pamięci masowej PowerVault ME4084.
Rozwiązanie PixStor obejmuje szeroki ogólny równoległy system plików znany również jako skala spektrum jako komponent PFS, a także wiele innych komponentów oprogramowania Arcastream, takich jak zaawansowana analiza, uproszczona administracja i monitorowanie, wydajne wyszukiwanie plików, zaawansowane możliwości bramy i wiele innych.


Rysunek 1. Architektura referencyjna.

 

---

Elementy rozwiązania

Planowane jest wydanie tego rozwiązania z najnowszymi skalowalnymi procesorami Intel Xeon Xeon drugiej generacji, tj. procesorami Cascade Lake, a niektóre serwery będą korzystać z najszybszej dostępnej pamięci RAM (2933 MT/s). Jednak ze względu na obecny sprzęt, który jest dostępny do pracy nad złośliwym rozwiązaniem w celu charakterystyki wydajności, serwery ze skalowalnymi procesorami Intel Xeon Xeon pierwszej generacji a.k.a. Procesory Skylake, a w niektórych przypadkach wolniejsze pamięci RAM, były używane do charakterystyki tego systemu. Ponieważ wąskie gardło rozwiązania znajduje się w kontrolerach SAS macierzy DellEMC PowerVault ME40x4, po wymianie procesorów i pamięci RAM Skylake na docelowe procesory Cascade Lake i szybszą pamięć RAM nie oczekuje się znacznej wydajności. Ponadto rozwiązanie zostało zaktualizowane do najnowszej wersji PixStor (5.1.1.4), która obsługuje RHEL 7.7 i OFED 4.7 w celu charakterystyki systemu.

Ze względu na wcześniej opisaną sytuację Tabela 1 zawiera listę głównych elementów rozwiązania, ale po wprowadzeniu rozbieżności w kolumnie pierwszy opis znajdują się komponenty używane w momencie wydania, a zatem dostępne dla klientów, a ostatnia kolumna to komponenty faktycznie używane do charakterystyki wydajności rozwiązania. Dyski wymienione dla danych (12 TB NLS) i metadanych (960 Gb SSD) są używane do charakterystyki wydajności, a szybsze dyski mogą zapewniać lepsze losowe IOPS i mogą poprawić operacje tworzenia/usuwania metadanych.

Na koniec, aby uzyskać pełność, została dołączona lista możliwych dysków twardych i dysków SSD metadanych metadanych, która jest oparta na dyskach obsługiwanych zgodnie z wyliczeniem w macierzy obsługi DellEMC PowerVault ME4, dostępnej online.

Tabela 1 Elementy używane w momencie wydania i używane w łóżku testowym

Element rozwiązania		W momencie wydania	Podstawka testowa
Połączenia wewnętrzne		Gigabitowy Ethernet Dell Networking S3048-ON
Podsystem przechowywania danych		Od 1x do 4 dysków Dell EMC PowerVault ME4084 1x do 4 dysków twardych Dell EMC PowerVault ME484 (jeden na ME4084) 80–12 TB 3,5-calowych dysków twardych NL SAS3, opcje 900 GB @15K, 1,2 TB @10K, 1,8 TB @10K, 2,4 TB @10K, 4 TB NLS, 8 TB NLS, 10 TB NLS, 12 TB NLS.     8 jednostek LUN, liniowe 8+2 RAID 6, rozmiar fragmentu 512 KB. 4 dyski SSD SAS3 1,92 TB do metadanych — 2 dyski RAID 1 (lub 4 dyski zapasowe globalnego dysku twardego, jeśli używany jest opcjonalny moduł metadanych o wysokim zapotrzebowaniu)
Opcjonalny podsystem pamięci masowej metadanych o wysokim zapotrzebowaniu		1x do 2 dysków Dell EMC PowerVault ME4024 (4 dyski ME4024, tylko duża konfiguracja) 24 dyski SSD SAS3 960 GB 2,5" (opcje 480 GB, 960 GB, 1,92 TB) 12 jednostek LUN, liniowa macierz RAID 1.
Kontrolery pamięci masowej RAID		SAS 12 Gb/s
Pojemność zgodnie z konfiguracją		Raw: 8064 TB (7334 TiB lub 7,16 PB) sformatowane ~ 6144 GB (5588 TiB lub 5,46 PB)
Procesor	Gateway	2x Intel Xeon Gold 6230 2,1 GB, 20°C/40 W, 10,4 GT/s, 27,5 MB pamięci podręcznej, Turbo, HT (125 W), DDR4-2933	Nie dotyczy
	Metadane o wysokim zapotrzebowaniu		2x Intel Xeon Gold 6136, 3,0 GHz, 12 rdzeni
	Węzeł pamięci masowej		2x Intel Xeon Gold 6136, 3,0 GHz, 12 rdzeni
	Węzeł zarządzania	2x Intel Xeon Gold 5220 2,2G, 18C/36 W, 10,4 GT/s, 24,75 MB pamięci podręcznej, Turbo, HT (125 W), DDR4-2666	2 procesory Intel Xeon Gold 5118, 2,30 GHz, 12 rdzeni
Pamięć	Gateway	12 modułów RDIMM 16 GB 2933 MT/s (192 GB)	Nie dotyczy
	Metadane o wysokim zapotrzebowaniu		24 moduły RDIMM 16 GB 2666 MT/s (384 GB)
	Węzeł pamięci masowej		24 moduły RDIMM 16 GB 2666 MT/s (384 GB)
	Węzeł zarządzania	12 modułów DIMM 16 GB, 2666 MT/s (192 GB)	12 modułów RDIMM 8 GB 2666 MT/s (96 GB)
System operacyjny		Red Hat Enterprise Linux 7.6	Red Hat Enterprise Linux 7.7
Wersja jądra		3.10.0-957.12.2.el7.x86_64	3.10.0-1062.9.1.el7.x86_64
Oprogramowanie PixStor		5.1.0.0	5.1.1.4
Skala spektrum (GPFS)		5.0.3	5.0.4-2
Wydajna łączność sieciowa		Mellanox ConnectX-5 Dual-Port InfiniBand EDR/100 GbE i 10 GbE	Mellanox ConnectX-5 InfiniBand EDR
Przełącznik o wysokiej wydajności		2x Mellanox SB7800 (HA — nadmiarowy)	1x Mellanox SB7700
Wersja OFED		Mellanox OFED-4.6-1.0.1.0	Mellanox OFED-4.7-3.2.9
Dyski lokalne (system operacyjny i analiza/monitorowanie)		Wszystkie serwery oprócz węzła zarządzania 3 dyski SSD 480 GB SAS3 (RAID1 + HS) dla systemu operacyjnego Kontroler PERC H730P RAID Węzeł zarządzania 3 dyski SSD 480 GB SAS3 (RAID1 + HS) dla systemu operacyjnego Kontroler RAID PERC H740P	Wszystkie serwery oprócz węzła zarządzania 2x 300 GB SAS3 15K (RAID 1) dla systemu operacyjnego Kontroler RAID PERC H330 Węzeł zarządzania 5x 300 GB SAS3 15K (RAID 5) do systemu operacyjnego i analizy/monitorowania Kontroler RAID PERC H740P
Zarządzanie systemami		iDRAC 9 Enterprise + DellEMC OpenManage	iDRAC 9 Enterprise + DellEMC OpenManage

 

---

Charakterystyka wydajności

Aby określić to nowe rozwiązanie Ready Solution, użyliśmy sprzętu określonego w ostatniej kolumnie Tabeli 1, w tym opcjonalnego modułu metadanych High Demand. W celu oceny wydajności rozwiązania użyto następujących testów porównawczych:

• Sekwencyjne IOzone N-N
• Sekwencyjne IOR od 1 do 1
• Losowe IOzone
• Test MDtest

 W przypadku wszystkich powyższych testów porównawczych w stanowisku testowym klienty były wymienione w tabeli 2 poniżej. Ponieważ liczba węzłów obliczeniowych dostępnych do testowania wynosiła tylko 16, kiedy wymagana była większa liczba wątków, wątki te były równomiernie rozproszone w 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 symulacje większej liczby równoczesnych klientów z ograniczoną liczbą węzłów obliczeniowych. Ponieważ testy porównawcze obsługują dużą liczbę wątków, użyto maksymalnej wartości do 1024 (określonej dla każdego testu), jednocześnie unikając nadmiernego przełączania kontekstowego i innych powiązanych skutków ubocznych, które nie wpływają na wyniki wydajności.

Tabela 2. Podstawka testowa klienta

Liczba węzłów klienckich	16
Węzeł kliencki	C6320
Procesory na węzeł kliencki	2 x 18 rdzeni Intel(R) Xeon(R) Gold E5-2697v4 przy 2,30 GHz
Pamięć na węzeł klienta	12 modułów RDIMM 16 GB 2400 MT/s
BIOS	2.8.0
Jądro systemu operacyjnego	3.10.0-957.10.1
Wersja GPFS	5.0.3

 

---

Sekwencyjne klienty IOzone Performance N do plików N

Wydajność sekwencyjnych klientów N do N została zmierzona na podstawie wersji 3.487 IOzone. Wykonywane testy różnią się w zależności od jednego wątku do 1024 wątków, a wyniki rozwiązania o zwiększonej pojemności (4x ME4084s + 4x ME484s) są kontrastowane z rozwiązaniami o dużych rozmiarach (4x ME4084). Efekty buforowania zostały zminimalizowane przez ustawienie puli stronicowania GPFS na 16 GB, a przy użyciu plików większych niż dwa razy większy rozmiar. Należy pamiętać, że w przypadku GPFS, które można dostroić, 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ż pamiętać, że podczas gdy w poprzednich rozwiązaniach DellEMC HPC rozmiar bloku dla dużych transferów sekwencyjnych wynosi 1 MIB, GPFS został sformatowany z 8 blokami MiB, a zatem wartość ta jest używana w testie porównawczym w celu zapewnienia optymalnej wydajności. Może to wydawać się zbyt duże i widocznie marnować zbyt dużo miejsca, ale GPFS używa alokacji podblokowania, aby zapobiec tej sytuacji. W bieżącej 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 zapisu i odczytu, gdzie wątki były zmienną z liczbą używanych wątków (od 1 do 1024 przy użyciu dwóch), a threadlist był plikiem, który przydzielał każdy wątek w innym węźle, używając kolistego robin do równomiernego rozłożenia ich na 16 węzłach obliczeniowych.

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

Rysunek 2.  Wydajność


sekwencyjna od N do NZ wyników można zauważyć, że wydajność rośnie bardzo szybko wraz z liczbą używanych klientów, a następnie osiąga warstwę stabilną, aż do osiągnięcia maksymalnej liczby wątków dozwolonych przez IOzone, a zatem duża wydajność sekwencyjna plików jest stabilna nawet w przypadku równoczesnych klientów 1024. Należy pamiętać, że wydajność odczytu i zapisu przynosiła po podwójnie wysoką liczbę dysków. Maksymalna wydajność odczytu była ograniczona przez przepustowość dwóch łączy IB EDR używanych w węzłach pamięci masowej, począwszy od 8 wątków, a macierze ME4 mogą mieć dodatkową wydajność. Należy również pamiętać, że maksymalna wydajność zapisu wzrosła z maksymalnie 16,7 do 20,4 GB/s przy 64 i 128 wątkach i jest bliżej maksymalnej specyfikacji macierzy ME4 (22 GB/s).

W tym miejscu należy pamiętać, że tryb pracy preferowany przez GPFS jest rozproszony, a rozwiązanie zostało sformatowane w celu korzystania z takiego trybu. W tym trybie bloki są przydzielane od samego początku działania w pseudo losowy sposób, rozprowadzając dane na całej powierzchni każdego dysku twardego. Choć oczywistą wadą jest mniejsza początkowa maksymalna wydajność, wydajność ta jest utrzymywana dość stale, niezależnie od ilości miejsca używanego w systemie plików. W przeciwieństwie do innych równoległych systemów plików, które początkowo korzystają z zewnętrznych ścieżek, które mogą pomieścić więcej danych (sektorów) na rewolucję dyskową i dlatego mają najwyższą możliwą wydajność, jaką mogą zapewnić dyski twarde, ale ponieważ system wykorzystuje więcej miejsca, używane są ścieżki wewnętrzne z mniejszą ilością danych na rewolucję, co skutkuje zmniejszeniem wydajności.

 

---

Sekwencyjne klienty IOR Performance N do 1 pliku

Wydajność sekwencyjnych klientów N do jednego udostępnionego pliku została zmierzona w wersji IOR 3.3.0, wspomaganej przez OpenMPI 4.0.1 w celu uruchomienia testu porównawczego dla 16 węzłów obliczeniowych. Testy różniły się w zależności od jednego wątku do 512 wątków (ponieważ nie było wystarczającej liczby rdzeni dla 1024 wątków), a wyniki są kontrastowane z rozwiązaniem bez rozszerzenia pojemności.
Efekty buforowania zostały zminimalizowane przez ustawienie puli stronicowania GPFS na 16 GB, a przy użyciu plików większych niż dwa razy większy rozmiar. W testach porównawczych wykorzystano 8 bloków MIB w celu uzyskania optymalnej wydajności. W poprzedniej sekcji testów wydajności przedstawiono bardziej szczegółowe wyjaśnienie tych kwestii.

Poniższe polecenia zostały użyte do wykonania testu porównawczego dla zapisu i odczytu, gdzie wątki były zmienną z liczbą używanych wątków (od 1 do 1024 przy użyciu dwóch), a my_hosts.$Threads jest odpowiednim plikiem, który przydzielał każdy wątek na innym węźle za pomocą okrężnego do równomiernego rozłożenia ich w 16 węzłach 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 128G 

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 128G

Rysunek 3. Wydajność sekwencyjna

od N do 1 Z wyników można ponownie zauważyć, że dodatkowe dyski zapewniają wydajność odczytu i zapisu. Wydajność rośnie ponownie bardzo szybko wraz z liczbą używanych klientów, a następnie osiąga plateau, który jest dość stabilny dla odczytu i zapisu aż do maksymalnej liczby wątków używanych w tym teście. Należy pamiętać, że maksymalna wydajność odczytu wyniosła 24,8 GB/s przy 16 wątkach, a wąskie gardło było interfejsem InfiniBand EDR, a macierze ME4 nadal miały dodatkową wydajność. Od tego momentu wydajność odczytu zmniejszała się od tej wartości, aż do osiągnięcia plateau na poziomie około 23,8 GB/s. Należy również pamiętać, że maksymalna wydajność zapisu 19,3 została osiągnięta w przypadku 8 wątków i osiągnięcia płaskowyżu.
 

---

Losowe małe bloki klientów IOzone Performance N do plików N

Wydajność losowych klientów N do plików N została zmierzona na podstawie fio w wersji 3.7 zamiast tradycyjnego Iozone. Celem, jak podano w poprzednim blogu, było wykorzystanie większej głębokości kolejki w celu zbadania maksymalnej możliwej wydajności macierzy ME4084 (wcześniejsze testy dla różnych rozwiązań ME4 wykazały, że macierze ME4084 wymagają większego nacisku we/wy, który Iozone może dostarczyć w celu osiągnięcia losowych limitów we/wy).

Testy różniły się w zależności 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 używał innego pliku, a wątki zostały przypisane do okrężnego w węzłach klienckich. W testach porównawczych wykorzystano 4 bloki KiB do emulacji ruchu w małych blokach i przy użyciu głębokości kolejki 16. Wyniki z rozwiązania o dużych rozmiarach i rozszerzenia pojemności zostały porównane.

Efekty buforowania zostały ponownie zminimalizowane przez ustawienie puli stronicowania GPFS na 16 Gb i dwa razy większą wartość przy użyciu plików. W pierwszej sekcji testów wydajności znajduje się pełniejsze wyjaśnienie, dlaczego jest to skuteczne w przypadku GPFS.

 
Rysunek 4.  Od N do N Wydajność

losowa Z wyników można zauważyć, że wydajność zapisu zaczyna się od wysokiej wartości 29.1K IOps i stale wzrasta do 64 wątków, gdzie wydaje się osiągać płaską wartość około 40 000 IOps. Wydajność odczytu rozpoczyna się od 1,4 K IOps i zwiększa wydajność niemal liniowo z liczbą używanych klientów (należy pamiętać, że liczba wątków jest podwojona dla każdego punktu danych) i osiąga maksymalną wydajność IOPS 25,6 K przy 64 wątkach, gdzie wydaje się być blisko osiągnięcia płaskowyżu. Użycie większej liczby wątków wymaga więcej niż 16 węzłów obliczeniowych w celu uniknięcia niedoboru zasobów i niższej widocznej wydajności, gdzie macierze mogą faktycznie utrzymać wydajność.

 

---

Wydajność metadanych z MDtest przy użyciu pustych plików

Wydajność metadanych została zmierzona za pomocą testu MDtest w wersji 3.3.0, wspomaganego przez OpenMPI 4.0.1 w celu przeprowadzenia testu porównawczego dla 16 węzłów obliczeniowych. Wykonywane testy różnią się w zależności od jednego wątku do 512 wątków. Test porównawczy był używany tylko w przypadku plików (brak metadanych katalogów), uzyskiwania liczby tworzonych, statystyk, odczytów i usuwania rozwiązania, a wyniki były kontrastowane z rozwiązaniem o dużym rozmiarze.

Aby prawidłowo ocenić rozwiązanie w porównaniu z innymi rozwiązaniami pamięci masowej DellEMC HPC i poprzednimi wynikami na blogu, użyto opcjonalnego modułu metadanych High Demand, ale z jedną macierzą ME4024, nawet jeśli duża konfiguracja i przetestowane w tej pracy zostały wyznaczone do obsługi dwóch modeli ME4024. Ten moduł metadanych o wysokim zapotrzebowaniu może obsługiwać do czterech macierzy ME4024 i zaleca się zwiększenie liczby macierzy ME4024 do 4 przed dodaniem kolejnego modułu metadanych. Dodatkowe macierze ME4024 powinny zwiększać wydajność metadanych liniowo z każdą dodatkową macierzą, z wyjątkiem operacji stat (i odczytów pustych plików), ponieważ liczby są bardzo wysokie, w pewnym momencie procesory staną się wąskim gardłem, a wydajność nie będzie nadal zwiększać się liniowo.

Poniższe polecenie zostało użyte do wykonania testu porównawczego, w którym wątki były zmienną z liczbą używanych wątków (od 1 do 512 przy użyciu dwóch), a my_hosts.$Threads jest odpowiednim plikiem, który przydzielił każdy wątek na innym węźle za pomocą okrężnego do równomiernego rozłożenia ich między 16 węzłami obliczeniowymi. Podobnie jak w przypadku testu porównawczego Random 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 kontekstowe wpłynie 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

Ponieważ wyniki wydajności mogą mieć wpływ na łączną liczbę IOPS, liczbę plików na katalog i liczbę wątków, postanowiono zachować stałą łączną liczbę plików do 2 plików MIB (2^21 = 2097152), liczbę plików na katalog naprawioną w 1024, a liczba katalogów była różna w miarę zmiany liczby wątków, jak pokazano w tabeli 3.

Tabela 3:  MDtest — dystrybucja plików w katalogach

Liczba wątków	Liczba katalogów na wątek	Łączna liczba plików
1	2048	2,097,152
2	1024	2,097,152
4	512	2,097,152
8	256	2,097,152
16	128	2,097,152
32	64	2,097,152
64	32	2,097,152
128	16	2,097,152
256	8	2,097,152
512	4	2,097,152
1024	2	2,097,152

Rysunek 5. Wydajność metadanych — puste pliki

Po pierwsze, należy pamiętać, że wybrana skala była logarytmiczna z bazą 10, aby umożliwić porównanie operacji o różnicy kilku zamówień wielkości; W przeciwnym razie niektóre operacje wyglądają jak płaska linia zbliżona do 0 na normalnym wykresie. Wykres dziennika z bazą 2 może być bardziej odpowiedni, ponieważ liczba wątków jest zwiększona przy zasilaniu 2, ale wykres wygląda bardzo podobnie, a ludzie mają tendencję do obsługi i zapamiętywania lepszych liczb w oparciu o moc 10.
System uzyskuje bardzo dobre wyniki, a operacje Stat i Read osiągają wartość szczytową odpowiednio 64 wątków, odpowiednio prawie 11 MLN operacji/s i 4,7 mln operacji/s. Operacje usuwania uzyskały maksymalnie 170,6 tys. operacji przy 16 wątkach, a operacje Create osiągnęły najwyższy poziom 32 wątków przy 222,1 tys. operacji. Operacje stat i odczytu są bardziej zmienne, ale po osiągnięciu maksymalnej wartości wydajność nie spada poniżej 3 MB operacji dla statystyk i operacji 2 MLN dla odczytów. Tworzenie i usuwanie są bardziej stabilne po osiągnięciu płaskowyżu i pozostają powyżej 140 000 operacji do usunięcia i 120 tys. operacji do utworzenia. Należy zauważyć, że dodatkowe dyski nie mają wpływu na większość operacji metadanych na pustych plikach, zgodnie z oczekiwaniami.
 

---

Wydajność metadanych z MDtest przy użyciu 4 plików KiB

Ten test jest niemal identyczny z poprzednim, z wyjątkiem tego, że zamiast pustych plików użyto małych plików 4 KB. 
Poniższe polecenie zostało użyte do wykonania testu porównawczego, w którym wątki były zmienną z liczbą używanych wątków (od 1 do 512 przy użyciu dwóch), a my_hosts.$Threads jest odpowiednim plikiem, który przydzielił każdy wątek na innym węźle za pomocą okrężnego do równomiernego rozłożenia ich między 16 węzłami obliczeniowymi.

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

Rysunek 6.  Wydajność metadanych — małe pliki (4K)

System uzyskuje bardzo dobre wyniki dla operacji stat i usuwania, które osiągają wartość szczytową odpowiednio 256 wątków z 8,2 MLN operacji/s i 400 000 operacji/s. Operacje odczytu uzyskały maksimum 44,8 tys. operacji/s, a operacje Create osiągnęły najwyższy poziom dzięki 68,1 tys. operacji/s, zarówno przy 512 wątkach. Operacje stat i usuwania są bardziej zmienne, ale po osiągnięciu maksymalnej wartości wydajność nie spada poniżej 3 MB operacji dla statystyk i operacji 280 tys. operacji do usunięcia. Tworzenie i odczytywanie ma mniejsze odchylenia i stale rośnie wraz ze wzrostem liczby wątków. Jak można zauważyć, dodatkowe dyski rozszerzeń pojemności zapewniają jedynie minimalną zmianę wydajności metadanych.
Ponieważ te liczby dotyczą modułu metadanych z jednym modułem ME4024, wydajność zwiększy się dla każdej dodatkowej macierzy ME4024, jednak nie można po prostu przyjąć liniowego wzrostu dla każdej operacji. O ile cały plik nie pasuje do węzła dla takiego pliku, do przechowywania plików 4K zostaną wykorzystane cele danych na me4084, co ograniczy wydajność do pewnego stopnia. Ponieważ rozmiar węzła wynosi 4 KB i nadal musi przechowywać metadane, w środku zmieszczą się tylko pliki około 3 KB, a każdy plik większy będzie wykorzystywać cele danych.
 

---

Wnioski i przyszłe prace

Rozwiązanie o zwiększonej pojemności było w stanie poprawić wydajność, nie tylko w przypadku dostępu losowego, ale nawet dla wydajności sekwencyjnej. Było to oczekiwane, ponieważ tryb rozproszony działa jak dostęp losowy, a posiadanie większej liczby dysków pozwala na poprawę. Wydajność, którą można omówić w Tabeli 4, powinna być stabilna z pustego systemu plików do prawie pełnego zapełnienia. Ponadto rozwiązanie jest skalowane w zakresie pojemności i wydajności liniowo w miarę dodawania większej liczby modułów węzłów pamięci masowej, a podobny wzrost wydajności można oczekiwać od opcjonalnego modułu metadanych o wysokim zapotrzebowaniu. To rozwiązanie zapewnia klientom HPC bardzo niezawodny równoległy system plików używany przez wiele klastrów HPC top 500. Ponadto zapewnia wyjątkowe możliwości wyszukiwania, zaawansowane monitorowanie i zarządzanie, a dodanie opcjonalnych bram umożliwia udostępnianie plików za pośrednictwem standardowych protokołów niestandardowych, takich jak NFS, SMB i innych klientów do tylu klientów.

Tabela 4  Najwyższa i utrzymująca się wydajność

	Najwyższa wydajność		Trwała wydajność
	Napisz	Read	Napisz	Read
Duże sekwencyjne klienty N do plików N	20,4 GB/s	24,2 GB/s	20,3 GB/s	24 GB/s
Duże sekwencyjne klienty N do jednego udostępnionego pliku	19,3 GB/s	24,8 GB/s	19,3 GB/s	23,8 GB/s
Losowe małe bloki N klientów do plików N	40 KIOps	25,6 Iops	40.0KIOps	19.3KiOps
Metadane Utwórz puste pliki	We/wy 169,4 tys. obr./min		We/wy 123,5 tys. obr./min
Puste pliki metadanych Stat	We/wy 11 mln		IOps 3,2 mln
Metadane Odczyt pustych plików	IOps 4,7 mln		IOps 2,4 mln
Metadane Usuń puste pliki	IOps 170,6 tys. obr./min		IOps 156,5 tys. obr./min
Metadane Utwórz pliki 4 Kb	IOps 68,1 tys. obr./min		IOps 68,1 tys. obr./min
Pliki Metadanych Stat 4KiB	IOps 8,2 mln		We/wy 3 mln
Metadane Odczyt plików 4 Kb	IOps 44,8 tys. obr./min		IOps 44,8 tys. obr./min
Metadane Usuń pliki 4 Kb	400 tys. IOps		We/wy 280 tys. obr./min

Ponieważ rozwiązanie jest przeznaczone do wydania z procesorami Cascade Lake i szybszą pamięcią RAM, po ostatecznej konfiguracji systemu zostaną przeprowadzone pewne kontrole wydajności. Przetestuj opcjonalny moduł metadanych wysokiego zapotrzebowania z co najmniej 2 plikami ME4024s i 4KiB, aby lepiej udokumentować skalę wydajności metadanych w przypadku realizacji celów danych. Ponadto wydajność węzłów bramy będzie mierzona i raportowana wraz z odpowiednimi wynikami z kontroli na miejscu w nowym blogu lub w opracowaniach technicznych. Wreszcie planowane jest przetestowanie i udostępnienie większej liczby komponentów rozwiązań w celu zapewnienia jeszcze większej liczby możliwości.