Rozwiązanie Dell EMC Ready dla pamięci masowej HPC PixStor

Artykuł napisany przez Mario Gallegosa z HPC and AI Innovation Lab w październiku 2019 r.

Spis treści

1. Wprowadzenie
   1. Architektura rozwiązania
   2. Elementy rozwiązania
2. Charakterystyka wydajności
   1. Wydajność sekwencyjna IOzone N klientów do N plików
   2. Wydajność sekwencyjna IOR N klientów do 1 pliku
   3. Losowe małe bloki — wydajność IOzone N klientów do N plików
   4. Wydajność metadanych w teście MDtest przy użyciu pustych plików
   5. Wydajność metadanych w teście MDtest przy użyciu plików 4 kB
   6. Wydajność metadanych przy użyciu testu MDtest z plikami 3K
3. Zaawansowana analiza
4. Wnioski i przyszłe prace

Wprowadzenie

Architektura rozwiązania

Elementy rozwiązania

Charakterystyka wydajności

•     IOzone N do N sekwencyjne
•     IOR N do 1 sekwencyjne
•     IOzone losowe
•     MDtest
  
  W przypadku wszystkich testów porównawczych wymienionych powyżej, stanowisko testowe miało klientów opisanych w Tabeli 2 poniżej. Ponieważ liczba węzłów obliczeniowych dostępnych do testowania wynosiła 16, gdy wymagana była większa liczba wątków, te wątki były równomiernie rozłożone na węzły obliczeniowe (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 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), unikając jednocześnie nadmiernego przełączania kontekstu i innych powiązanych skutków ubocznych wpływających na wyniki wydajności.
  
  Tabela 2: Stanowisko testowe klienta

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

   

  ---

  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. Przeprowadzone testy wahały się od pojedynczego wątku do 1024 wątków. 
  Efekty buforowania 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 pamiętać, że w przypadku GPFS, który jest przestrajalny, 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 HPC Dell EMC rozmiar bloku dla dużych transferów sekwencyjnych wynosił 1 MiB, GPFS był sformatowany z 8 blokami MiB, dlatego wartość ta 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 KiB każdy. 
  Następujące polecenia zostały użyte do wykonania testu porównawczego zapisu i odczytu, gdzie wątki były zmienną z liczbą używanych wątków (od 1 do 1024 zwiększaną w potęgach dwójki), a lista wątków była plikiem, który alokował każdy wątek w innym węźle, używając działania okrężnego do równomiernego rozłożenia ich na 16 węzłów obliczeniowych.

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

  
  Rysunek 2.  Wydajność
  
  
  sekwencyjna od N do N Na podstawie wyników możemy zaobserwować, że wydajność rośnie bardzo szybko wraz z liczbą używanych klientów, a następnie osiąga plateau, które jest stabilne do momentu osiągnięcia maksymalnej liczby wątków, na którą zezwala IOzone, a zatem wydajność sekwencyjna dużych plików jest stabilna nawet dla 1024 jednoczesnych klientów. Należy zauważyć, że maksymalna wydajność odczytu wynosiła 23 GB/s przy 32 wątkach, a wąskim gardłem był najprawdopodobniej interfejs EDR InfiniBand, podczas gdy macierze ME4 nadal miały dostępną dodatkową wydajność. Zauważ również, że maksymalna wydajność zapisu 16,7 została osiągnięta nieco wcześniej przy 16 wątkach i jest najwyraźniej niska w porównaniu ze specyfikacją macierzy ME4.
  W tym miejscu należy pamiętać, że preferowany tryb działania GPFS jest rozproszony, a rozwiązanie zostało sformatowane tak, aby z niego korzystać. W tym trybie bloki są przydzielane od samego początku w sposób pseudolosowy, rozprowadzając dane po całej powierzchni każdego dysku twardego. Podczas gdy oczywistą wadą jest mniejsza początkowa maksymalna wydajność, wydajność ta jest utrzymywana na dość stałym poziomie, niezależnie od tego, ile miejsca jest używane w systemie plików. W przeciwieństwie do innych równoległych systemów plików, które początkowo używają zewnętrznych ścieżek, które mogą pomieścić więcej danych (sektorów) na obrót dysku, a zatem mają najwyższą możliwą wydajność, jaką mogą zapewnić dyski twarde, ale gdy system wykorzystuje więcej miejsca, używane są wewnętrzne ścieżki z mniejszą ilością danych na obrót, co w konsekwencji zmniejsza wydajność. 
  
   

  ---

  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. Przeprowadzone testy wahały się od pojedynczego wątku do 1024 wątków.
  Efekty buforowania zostały zminimalizowane poprzez ustawienie puli stron GPFS na 16 GB i używanie plików większych niż dwukrotność tego rozmiaru. 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 tych kwestii. 
  Następujące polecenia zostały użyte do wykonania testu porównawczego zapisu i odczytu, gdzie wątki były zmienną z liczbą używanych wątków (od 1 do 1024 zwiększaną w potęgach dwójki), a my_hosts.$Threads jest odpowiednim plikiem, który alokował każdy wątek w innym węźle, używając algorytmu 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 --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 Na podstawie wyników możemy zaobserwować, że wydajność ponownie rośnie bardzo szybko wraz z liczbą używanych klientów, a następnie osiąga plateau, które jest półstabilne dla odczytów i bardzo stabilne dla zapisu aż do maksymalnej liczby wątków używanych w tym teście. W związku z tym wydajność sekwencyjna dużych współdzielonych plików jest stabilna nawet w przypadku 1024 równoczesnych klientów. Należy zauważyć, że maksymalna wydajność odczytu wynosiła 23,7 GB/s przy 16 wątkach i bardzo prawdopodobne, że wąskim gardłem był interfejs EDR InfiniBand, podczas gdy macierze ME4 nadal miały dostępną dodatkową wydajność. Ponadto wydajność odczytu spadała od tej wartości aż do osiągnięcia plateau na poziomie około 20,5 GB/s, z chwilowym spadkiem do 18,5 GB/s przy 128 wątkach. Podobnie należy zauważyć, że maksymalna wydajność zapisu 16,5 została osiągnięta przy 16 wątkach i jest najwyraźniej niska w porównaniu ze specyfikacją macierzy ME4.
   

  ---

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

  Wydajność losowych N klientów do N plików została zmierzona za pomocą IOzone w wersji 3.487. Przeprowadzone testy wahały się od pojedynczego wątku do 1024 wątków. W tym teście porównawczym wykorzystano bloki 4 KiB do emulacji ruchu małych bloków.
  Efekty buforowania zostały zminimalizowane przez ustawienie puli stron GPFS przestrajalnej na 16 GiB i użycie plików dwa razy większych. Pierwsza sekcja testu wydajności zawiera pełniejsze wyjaśnienie, dlaczego jest to skuteczne w przypadku GPFS. 
  Następujące polecenie zostało użyte do wykonania testu porównawczego w trybie losowego we/wy zarówno dla zapisu, jak i odczytu, gdzie wątki były zmienną z liczbą używanych wątków (od 1 do 1024 zwiększaną w potęgach dwójki), a lista wątków była plikiem, który alokował każdy wątek w innym węźle, używając algorytmu okrężnego do równomiernego rozłożenia ich na 16 węzłów obliczeniowych.

  ./iozone -i2 -c -O -w -r 4K -s 32G -t $Threads -+n -+m ./threadlist

  
  Rysunek 4.  Wydajność
  
  losowa od N do N: Na podstawie wyników możemy zaobserwować, że wydajność zapisu zaczyna się od wysokiej wartości prawie 8,2 tys. IOPS i stale rośnie do 128 wątków, gdzie osiąga plateau i pozostaje blisko maksymalnej wartości 16,2 tys. IOPS. Z drugiej strony wydajność odczytu zaczyna się od bardzo małej liczby operacji we/wy na sekundę wynoszącej ponad 200 i zwiększa wydajność niemal liniowo wraz 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ść 20,4 tys. operacji we/wy na sekundę przy 512 wątkach bez oznak osiągnięcia maksimum. Jednak użycie większej liczby wątków w bieżących 16 węzłach obliczeniowych z dwoma procesorami CPU każdy i gdzie każdy procesor CPU ma 18 rdzeni, ma ograniczenie polegające na tym, że nie ma wystarczającej liczby rdzeni, aby uruchomić maksymalną liczbę wątków IOzone (1024) bez ponoszenia kosztów przełączania kontekstu (16 x 2 x 18 = 576 rdzeni), co znacznie ogranicza wydajność. Przyszły test z większą liczbą węzłów obliczeniowych może sprawdzić, jaką wydajność odczytu losowego można osiągnąć z 1024 wątkami z IOzone lub IOR może być użyty do zbadania zachowania z ponad 1024 wątkami.
  
   

  ---

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

  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), uzyskując liczbę utworzenia, statystyk, odczytów i usunięć, które rozwiązanie może obsłużyć.
  Aby prawidłowo ocenić rozwiązanie w porównaniu z innymi rozwiązaniami pamięci masowej HPC firmy Dell EMC, użyto opcjonalnego modułu metadanych High Demand Metadata Module, ale z jedną macierzą ME4024, nawet jeśli duża konfiguracja i przetestowana w tej pracy została wyznaczona jako posiadająca dwa 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. Oczekuje się, że dodatkowe macierze ME4024 zwiększą wydajność metadanych liniowo z każdą dodatkową macierzą, może z wyjątkiem operacji Stat (i odczytów dla pustych plików), ponieważ liczby są bardzo wysokie, w pewnym momencie procesory staną się wąskim gardłem i wydajność nie będzie nadal rosła liniowo.
  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

  
  Ponieważ na wyniki wydajności może mieć wpływ łączna liczba operacji we/wy na sekundę, liczba plików na katalog i liczba wątków, zdecydowano się zachować stałą łączną liczbę plików do 2 plików MiB (2^21 = 2097152), liczbę plików na katalog ustaloną na 1024, a liczbę katalogów zmieniającą się wraz ze zmianą liczby wątków, jak pokazano w Tabeli 3.
  
  Tabela 3:  Dystrybucja plików MDtest 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, zwróć uwagę, że wybrana skala była logarytmiczna o podstawie 10, aby umożliwić porównanie 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 normalnym wykresie. Wykres logarytmiczny o podstawie 2 mógłby być bardziej odpowiedni, ponieważ liczba wątków jest zwiększona w potęgach liczby 2, ale wykres wyglądałby dość podobnie, a ludzie mają tendencję do obsługi i zapamiętywania lepszych liczb w oparciu o potęgi liczby 10.
  
  
  System uzyskuje bardzo dobre wyniki, gdy operacje Stat i Read osiągają maksymalną wartość przy 64 wątkach z odpowiednio 11,2 mln operacji na sekundę i 4,8 mln operacji na sekundę. Operacje usuwania osiągnęły maksymalną wartość 169,4 tys. operacji na sekundę przy 16 wątkach, a operacje tworzenia osiągnęły maksymalną wartość 512 wątków przy 194,2 tys. operacji na sekundę. Operacje Stat i Read charakteryzują się większą zmiennością, ale po osiągnięciu wartości szczytowej wydajność nie spada poniżej 3 mln operacji na sekundę dla Stat i 2 mln operacji na sekundę dla Read. Tworzenie i usuwanie są bardziej stabilne, gdy osiągną plateau i utrzymują się powyżej 140 tys. operacji/s w przypadku usuwania i 120 tys. operacji/s w przypadku tworzenia.
   

  ---

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

  Ten test jest prawie identyczny z poprzednim, z tą różnicą, że zamiast pustych plików użyto małych plików o rozmiarze 4 kB. 
  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.

  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 Removal, osiągając szczytową wartość na poziomie 128 wątków z odpowiednio 7,7 mln operacji na sekundę i 1 mln operacji na sekundę. Operacje usuwania osiągnęły maksymalną wartość 37,3 tys. operacji na sekundę, a operacje tworzenia osiągnęły maksymalną wartość 55,5 tys. operacji na sekundę, obie przy 512 wątkach. Operacje statystyk i usuwania mają większą zmienność, ale gdy osiągną wartość szczytową, wydajność nie spada poniżej 4 mln operacji na sekundę w przypadku statystyk i 200 tys. operacji na sekundę w przypadku usuwania. Operacje Create i Read mają mniejszą zmienność i rosną wraz ze wzrostem liczby wątków.
  Ponieważ liczby te dotyczą modułu metadanych z pojedynczą macierzą ME4024, wydajność wzrośnie dla każdej dodatkowej macierzy ME4024, jednak nie możemy po prostu założyć liniowego wzrostu dla każdej operacji. O ile cały plik nie mieści się w inode dla takiego pliku, cele danych na ME4084 będą używane do przechowywania plików 4K, ograniczając do pewnego stopnia wydajność. Ponieważ rozmiar i-węzła wynosi 4 kB i nadal musi przechowywać metadane, tylko pliki o rozmiarze około 3 kB zmieszczą się w środku, a każdy plik większy niż ten będzie wykorzystywał cele danych.
   

  ---

  Wydajność metadanych przy użyciu testu MDtest z plikami 3K

  Ten test jest prawie identyczny z poprzednimi, z tą różnicą, że użyto małych plików o wielkości 3KiB. Główna różnica polega na tym, że pliki te mieszczą się całkowicie w i-węźle. W związku z tym węzły pamięci masowej i ich ME4084 nie są używane, co zwiększa ogólną szybkość poprzez używanie tylko nośników SSD do przechowywania danych i ograniczenie dostępu do sieci. 
  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.

  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 3K -e 3K

   

  
  Rysunek 7. Wydajność metadanych - Małe pliki (3K)
  
  System uzyskuje bardzo dobre wyniki dla operacji Stat i Read, osiągając szczytową wartość na poziomie 256 wątków z odpowiednio 8,29 mln operacji na sekundę i 5,06 mln operacji na sekundę. Operacje usuwania osiągnęły maksymalną wartość 609 tys. operacji na sekundę przy 128 wątkach, a operacje tworzenia osiągnęły szczyt przy 78 tys. operacji na sekundę przy 512 wątkach. Operacje Stat i Read mają większą zmienność niż operacje tworzenia i usuwania. Usunięcie ma niewielki spadek wydajności dla dwóch wyższych punktów wątków, co sugeruje, że trwała wydajność po 128 wątkach będzie nieco ponad 400 tys. operacji na sekundę. Liczba tworzonych wątków stale rosła do 512, ale wygląda na to, że osiąga plateau, więc maksymalna wydajność może nadal wynosić poniżej 100 tys. operacji/s.
  Ponieważ małe pliki, takie jak te, są przechowywane w całości w module metadanych opartym na dysku SSD, aplikacje wymagające doskonałej wydajności małych plików mogą korzystać z jednego lub więcej opcjonalnych modułów metadanych o wysokim zapotrzebowaniu w celu zwiększenia wydajności małych plików. Jednak pliki, które mieszczą się w i-węźle, są małe według obecnych standardów. Ponadto, ponieważ cele metadanych wykorzystują macierze RAID1 ze stosunkowo małymi dyskami SSD (maksymalny rozmiar to 19,2 TB), pojemność będzie ograniczona w porównaniu z węzłami pamięci masowej. Dlatego należy zachować ostrożność, aby uniknąć zapełniania celów metadanych, co może powodować niepotrzebne awarie i inne problemy.
   

  ---

  Zaawansowana analiza

  Wśród możliwości PixStor monitorowanie systemu plików za pomocą zaawansowanej analityki może być niezbędne, aby znacznie uprościć administrację, pomagając proaktywnie lub reaktywnie znajdować problemy lub potencjalne problemy. Następnie pokrótce omówimy niektóre z tych możliwości.
  Rysunek 8 przedstawia użyteczne informacje dotyczące pojemności systemu plików. Po lewej stronie znajduje się łączna ilość zajętego miejsca w systemie plików oraz dziesięciu pierwszych użytkowników na podstawie wykorzystanej pojemności systemu plików. Po prawej stronie znajduje się widok historyczny z pojemnością używaną w ciągu wielu lat, a następnie dziesięć najczęściej używanych typów plików i dziesięć najlepszych zestawów plików, oba oparte na wykorzystanej pojemności, w formacie podobnym do wykresów Pareto (bez wierszy dla sum skumulowanych). Dzięki tym informacjom można łatwo znaleźć użytkowników, którzy otrzymują więcej niż należny im udział w systemie plików, trendy wykorzystania pojemności, aby pomóc w podjęciu decyzji o przyszłym wzroście pojemności, które pliki zajmują większość miejsca lub jakie projekty zajmują większość pojemności.
  
  
  Rysunek 8.  PixStor Analytics - Widok
  
  pojemności Rysunek 9 przedstawia widok liczby plików z dwoma bardzo przydatnymi sposobami znajdowania problemów. Pierwsza połowa ekranu zawiera dziesięciu najlepszych użytkowników na wykresie kołowym oraz dziesięć pierwszych typów plików i dziesięć najlepszych zestawów plików (pomyśl o projektach) w formacie podobnym do wykresów Pareto (bez wierszy dla sum skumulowanych), wszystkie oparte na liczbie plików. Informacje te można wykorzystać do udzielenia odpowiedzi na kilka ważnych pytań. Na przykład, jacy użytkownicy monopolizują system plików, tworząc zbyt wiele plików, jaki typ pliku tworzy koszmar metadanych lub jakie projekty zużywają większość zasobów.
  Dolna połowa ma histogram z liczbą plików (częstotliwość) dla rozmiarów plików przy użyciu 5 kategorii dla różnych rozmiarów plików. Można to wykorzystać, aby zorientować się w rozmiarach plików używanych w systemie plików, które w połączeniu z typami plików mogą być użyte do podjęcia decyzji, czy kompresja będzie korzystna.
  
  
  Rysunek 9.  PixStor Analytics - Widok liczby plików

  
  
   

  ---

  Wnioski i przyszłe prace

  Obecne rozwiązanie było w stanie zapewnić dość dobrą wydajność, która powinna być stabilna niezależnie od zajętego miejsca (ponieważ system został sformatowany w trybie rozproszonym), co widać w tabeli 4. Co więcej, rozwiązanie skaluje się pod względem pojemności i wydajności liniowo wraz z dodawaniem kolejnych modułów węzłów pamięci masowej, a podobnego wzrostu wydajności można oczekiwać od opcjonalnego modułu metadanych o wysokim zapotrzebowaniu. 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 inne, dowolnej liczbie klientów.
  
  Tabela 4  Szczytowa i trwała wydajność
  
   

  	Szczytowa wydajność		Utrzymująca się wydajność
  	Write	Read	Write	Read
  Duży sekwencyjny N klientów do N plików	16,7 GB/s	23 GB/s	16,5 GB/s	20,5 GB/s
  Duży sekwencyjny N klientów do jednego udostępnionego pliku	16,5 GB/s	23,8 GB/s	16,2 GB/s	20,5 GB/s
  Losowe małe bloki N klientów do N plików	15,8 tys. kart na sekundę	20,4 tys. pakietów na sekundę	15,7 tys. kart na sekundę	20,4 tys. pakietów na sekundę
  Metadane puste pliki Create	169,4 tys. IOPs		127,2 tys. IOps
  Metadane puste pliki Stat	11,2 mln IOps		3,3 mln IOps
  Metadane puste pliki Read	4,8 mln IOps		2,4 mln IOPs
  Metadane puste pliki Remove	194,2 tys. IOps		144,8 tys. IOps
  Metadane pliki 4 kB Create	55,4 tys. IOps		55,4 tys. IOps
  Metadane pliki 4 kB Stat	6,4 mln IOps		4 mln IOps
  Metadane pliki 4 kB Read	37,3 tys. IOps		37,3 tys. IOps
  Metadane pliki 4 kB Remove	1 mln IOps		219,5 tys. IOps

  
  
  Ponieważ rozwiązanie ma zostać wydane z procesorami Cascade Lake i szybszą pamięcią RAM, gdy system będzie miał ostateczną konfigurację, zostaną przeprowadzone wyrywkowe kontrole wydajności. Przetestowanie opcjonalnego modułu metadanych High Demand Module z co najmniej 2x ME4024 i plikami 4 kB jest konieczne, aby lepiej udokumentować, jak skaluje się wydajność metadanych, gdy zaangażowane są cele danych. Ponadto wydajność węzłów bramy zostanie zmierzona i zgłoszona wraz z wszelkimi istotnymi wynikami kontroli na miejscu w nowym blogu lub białej księdze. Wreszcie, planowane jest przetestowanie i wydanie kolejnych komponentów rozwiązania, aby zapewnić jeszcze więcej możliwości.

  ---