Rozwiązanie pamięci masowej Dell EMC HPC NFS — konfiguracja o wysokiej dostępności (NSS7.4-HA)

Spis treści

1. Omówienie rozwiązania
2. Architektura NSS7.4-HA
3. Porównanie komponentów rozwiązań NSS 7.4-HA i NSS 7.3-HA
4. Konfiguracja stanowiska testowego
5. NSS7.4-HA — podsumowanie wydajności we/wy
   • Sekwencyjne zapisy i odczyty IPoIB N-N
   • Losowe zapisy i odczyty IPoIB N-N
   • Operacje metadanych IPoIB
6. Wnioski
7. Odniesienia
   
    

---

Omówienie rozwiązania

Ten blog zawiera opis rozwiązania pamięci masowej Dell EMC HPC NFS w wersji 7.4 (NSS 7.4-HA), która wykorzystuje procesory Intel Xeon Scalable drugiej generacji o nazwie kodowej „Cascade Lake”.  Te ulepszone procesory Xeon są wyposażone w do 28 rdzeni, do 38,5 MB pamięci podręcznej ostatniego poziomu i sześć kanałów pamięci 2933 MT/s na gniazdo.  Kluczowe funkcje procesorów kaskadowych Lake są zintegrowane z atakami sprzętowymi na ataki z podparciem na kanał, za pomocą technologii Intel DL (VNNI) i pomocy technicznej w przypadku zwiększonej prędkości zegara i prędkości pamięci.

Kaskada Lake i jej poprzedników Skylake zawieraćfunkcję o nazwieADDDC (daptive double dram device Correction). Funkcja ADDDC jest wdrażana w czasie uruchomienia w celu dynamicznego mapowania nieprawidłowych urządzeń pamięci DRAM, przy jednoczesnym ciągłym zapewnieniu korekty Single Device Data Correction (SDDC) i obsłudze pamięci z korekcją błędów (ECC), co przekłada się na zwiększoną żywotność modułów DIMM. Ta funkcja jest aktywowana tylko w przypadku urządzeń DRAM x4 i nie działa, gdy w systemie znajdują się urządzenia x8 DRAM. Ponieważ najnowsza wersja NSS-HA 7.4 używa tylko 16 GB pamięci, co jest organizacją x8, funkcja ADDDC jest wyszarzona i nie jest dostępna w systemie BIOS. Jeśli jednak korzystasz z pamięci 32 GB, która jest X4, ADDDC będzie dostępna jako opcja tunable, a zaleca się, aby jej ustawienie było RAS wyłączone.

Zaleca się skonfigurowanie serwerów NFS przy użyciu profilu HPC zgodnie z opisem w sekcji "Charakterystyka systemu BIOS dla procesorów Intel kaskad Lake" oznacza to, że w systemie BIOS włączono obsługę klastrowanej podsieci, procesor logiczny wyłączony i profil systemu ustawiony na "wydajność". W przypadku uaktualniania istniejącego systemu należy upewnić się, że system BIOS zostanie najpierw zaktualizowany do wersji, która obsługuje procesory Cascade Lake, przed modernizacją procesorów do tej wersji. Zespół ds. inżynierii HPC w dziale HPC and AI Innovation Lab wykonał serię testów wydajności serwerów NSS wyposażonych w procesory Cascade Lake i porównał wyniki z wynikami uzyskanymi wcześniej dla rozwiązania NSS 7.3-HA, w którym była używana najnowsza wersja serwerów PowerEdge wyposażonych w procesory poprzedniej generacji Xeon z serii „Skylake-SP”. Wyniki testu porównawczego i porównanie są przedstawione w tym blogu.

NFS rozwiązanie pamięci masowej dostarczone przez Dell EMC jest zoptymalizowane i dostrojone do najlepszej wydajności.  Podczas konfigurowania rozwiązania NSS7.4-HA należy zwrócić uwagę na następujące najistotniejsze kwestie:

1. Minimalną wersją obsługiwanego systemu operacyjnego dla procesorów Cascade Lake jest Red Hat Enterprise Linux 7.6. Jednak w przypadku jądra w wersji 3.10.0-957.el7 udział NFS zawiesi zadanie, takie jak kworker, zużywając 100% mocy procesora. Przyczyną problemu jest utrata synchronizacji warstwy TCP ze stanem transportu warstw sunrpc. Ten problem został rozwiązany w pakiecie kernel-3.10.0-957.5.1.el7 i nowszych. Dlatego podstawowy system operacyjny używany w tym rozwiązaniu to RHEL 7.6, a używana wersja jądra to kernel-3.10.0-957.5.1.el7. Więcej informacji na ten temat można znaleźć na stronie https://access.redhat.com/solutions/3742871.
2. W przypadku rozwiązania NSS7.4-HA, o ile nie zainstalowano następujących pakietów, nie można uruchomić zasobu nfsserver, ponieważ usługa nfs-idmapd.service nie uruchamia się. Więcej informacji można znaleźć na stronie https://access.redhat.com/solutions/3746891.
   • resource-agents-4.1.1-12.el7_6.4
   • resource-agents-aliyun-4.1.1-12.el7_6.4
   • resource-agents-gcp-4.1.1-12.el7_6.4 lub nowszy.
3. W informacjach o wersji systemu RHEL 7.6 zwrócono uwagę na fakt, że błąd w warstwie we/wy systemu LVM powoduje uszkodzenie danych w pierwszych 128 kB, które można przyporządkować na woluminie fizycznym.  Problem został rozwiązany z w wersji lvm2-2.02.180-10.el7_6.2 i nowszych.  Dlatego należy upewnić się, że pakiet lvm2 jest zaktualizowany do najnowszej wersji. Jeśli aktualizacja pakietu lvm2 nie jest możliwa, sposobem obejścia może być nieużywanie poleceń LVM, które zmieniają metadane grupy woluminów (VG), takich jak lvcreate lub lvextend, gdy używane są woluminy logiczne w VG.

---

Architektura NSS7.4-HA

Na Rysunku 1 przedstawiono konstrukcję NSS7.4-HA. Z wyjątkiem niezbędnych aktualizacji oprogramowania oraz oprogramowania wewnętrznego, NSS7.4-HA i NSS7.3-HA korzystają z tej samej konfiguracji klastrów HA i konfiguracji pamięci masowej. Para serwerów NFS w konfiguracji aktywny-pasywny o wysokiej dostępności jest podłączona do pamięci PowerVault ME4084. W każdym serwerze NFS znajdują się dwie karty SAS. Każda karta ma kabel SAS do każdego kontrolera we współużytkowanej pamięci masowej, dzięki czemu awaria pojedynczej karty SAS lub kabla SAS nie wpływa na dostępność danych. (Szczegółowe informacje na temat konfiguracji można znaleźć w opracowaniu dotyczącym rozwiązania NSS7.3-HA). Architektura NSS7.4-HA

 

---

 

Porównanie komponentów rozwiązań NSS 7.4-HA i NSS 7.3-HA

Choć od czasu swojej premiery rozwiązania Dell NSS-HA otrzymały wiele ulepszeń sprzętowych i programowych mających na celu zapewnienie większej dostępności, wydajności i pojemność pamięci masowej, to architektura i wytyczne dotyczące wdrażania rozwiązań z rodziny NSS-HA nie zmieniły się. Najnowsza wersja i starsza wersja NSS7.3-HA współużytkują to samo zaplecze pamięci masowej, jakim jest Power Vault ME4084. Poniższa tabela zawiera porównanie komponentów najnowszego rozwiązania NSS7.4-HA i poprzedniego rozwiązania NSS7.3-HA.

 

W pozostałej części bloga przedstawione zostanie stanowisko testowe oraz informacje na temat wydajności we/wy rozwiązania NSS7.4-HA. Aby pokazać różnicę wydajności między rozwiązaniem NSS7.4-HA a poprzednią wersją, przedstawione są również odpowiednie dane dotyczące wydajności wersji NSS7.3-HA.

 

---

Konfiguracja stanowiska testowego

W tej części opisano stanowisko testowe używane do oceny wydajności i funkcjonalności rozwiązania NSS7.4-HA. Należy pamiętać, że procesory używane do testowania wydajności różnią się od procesorów wybranych dla rozwiązania, ponieważ nie otrzymano na czas procesorów Xeon Gold 6240. Planowane jest powtórzenie niektórych testów po udostępnieniu procesorów 6240 oraz zaktualizowanie tego raportu.
    

Tabela 4: NSS 7.4-HA konfiguracja klienta   

---

NSS7.4-HA — podsumowanie wydajności we/wy

W tej sekcji przedstawiono wyniki testów wydajności we/wy dla bieżącego rozwiązania NSS7.4. Wszystkie testy wydajności przeprowadzono w scenariuszu bezawaryjnym, aby zmierzyć maksymalną wydajność rozwiązania. Testy dotyczyły trzech typów wzorców we/wy: dużych odczytów i zapisów sekwencyjnych, małych odczytów i zapisów losowych oraz trzech operacji metadanych (file create, stat i remove). Podobnie jak w poprzedniej wersji NSS 7.3-HA, rozwiązanie korzysta z harmonogramu i/O i 256 NFS demonów.

Konfiguracja 840TB (z surowego rozmiaru) była tworzona przy użyciu łączności z siecią IPoIB przez EDR. Do generowania obciążeń podczas testów wydajności używany był 32-węzłowy klaster obliczeniowy. Każde badanie było wykonywane nad zakresem klientów w celu przetestowania skalowalności rozwiązania.

W badaniach używa się wzorców IOzone i mdtest. IOzone był używany do testów sekwencyjnych i losowych. W przypadku testów sekwencyjnych używano rozmiaru żądania 1024 kB. Łączna ilość transferowanych danych wynosiła 2 TB, aby upewnić się, że pamięć podręczna serwera NFS była nasycona. Podczas testów losowych użyto rozmiaru żądania 4 kB, a każdy klient odczytywał i zapisywał plik 4 GB. Testy metadanych zostały przeprowadzone przy użyciu testu wydajności mdtest z OpenMPI i uwzględniały operacje file create, stat i remove. (Pełny spis poleceń użytych podczas testów znajduje się w Dodatku A opracowania dotyczącego NSS7.3-HA).

 

Sekwencyjne zapisy i odczyty IPoIB N-N

Do oceny sekwencyjnego odczytu i zapisu użyto testu IOzone w wersji 3.487 w trybie sekwencyjnego odczytu i zapisu. Testy przeprowadzono na wielu wątkach, rozpoczynając od 1 wątku, a następnie zwiększając liczbę wątków dwukrotnie, aż do 64. Przy każdej liczbie wątków wygenerowano taką samą liczbę plików, ponieważ ten test działa dla jednego pliku w wątku, lub przypadku N-N. Wybrano łączny rozmiar pliku 2 TB, który jest równo podzielony między liczbę wątków w danym teście.

Rysunek 2 przedstawia porównanie wydajności wejścia/wyjścia NSS 7.4-HA w wersji z systemem NSS 7.3-HA. Z rysunku wynika, że najnowsza wersja NSS7.4 i poprzednia wersja NSS7.3 mają podobną wydajność maksymalną z odczytem na poziomie ok. 7 GB/s oraz zapisem na poziomie ok. 5 GB/s. Jednak dla niektórych liczb wątków stwierdzono spadek wydajności zapisu o 15–20% w porównaniu z rozwiązaniem NSS7.3-HA. Obecnie trwa badanie tej różnicy w wydajności. Wydajność odczytu odnotowała wzrost o prawie 45% przy liczbie wątków 1 i 2 oraz 18% przy liczbie wątków 8. W przypadku liczby wątków większej niż 8 wydajność odczytu jest zbliżona do rozwiązania NSS 7.3-HA. Wzrost wydajności odczytu przy mniejszej liczbie wątków wynika prawdopodobnie z ograniczeń sprzętowych w procesorach Cascade Lake chroniących przed atakami z kanału bocznego. Wydajność dużych sekwencyjnych operacji we wy IPoIB




 

Losowe zapisy i odczyty IPoIB N-N

W celu oceny wydajności losowych operacji we/wy użyto testu IOzone w wersji 3.487 w trybie losowym. Testy przeprowadzono na liczbach wątków od 1 do 64, zwiększając kolejno liczbę wątków dwukrotnie. Rozmiar rekordu został wybrany jako 4 kB. Każdy klient odczytywał lub zapisywał plik 4 GB w celu zasymulowania niewielkich, losowych operacji dostępu do danych.  Ze względu na to, że klaster ma tylko węzły 32, to punkt danych 64-wątek został uzyskany 32 przy wykorzystaniu 2 kolejnych wątków.

Rysunek 3 przedstawia porównanie losowego zapisu i przeczytanej wydajności wejścia/wyjścia NSS 7.4-HA do NSS 7.3-HA. Z rysunku wynika, że wersja NSS7.4 ma podobną maksymalną wydajność zapisu jak wersja NSS7.3-HA, około 7300 IOPS.  W przypadku rozwiązania NSS7.4-HA dla małej liczby wątków (1 i 2) wydajność zapisu jest o około 14% mniejsza w porównaniu z poprzednią wersją rozwiązania, obecnie trwa badanie przyczyny takiej sytuacji.  Wydajność odczytu losowego wzrasta stale w wersji NSS7.4 i osiąga wartość maksymalną 16 607 IOPS dla 64 wątków. W poprzedniej wersji (NSS7.3-HA) maksymalna wydajność 28 811 IOPS została osiągnięta dla 32 wątków, co jest wartością o 42% wyższą niż maksymalna wydajność osiągana w przypadku losowych odczytów w rozwiązaniu NSS7.4-HA. Wydajność losowych operacji we/wy IPoIB



 

Operacje metadanych IPoIB

Aby ocenić wydajność metadanych systemu, użyto narzędzia MDTest w wersji 1.9.3. Użyta dystrybucja MPI to OpenMPI w wersji 1.10.7.  Testy metadanych zostały przeprowadzone przez utworzenie 960 000 plików przy liczbie wątków do 32, a następnie zwiększenie liczby plików w celu przetestowania skalowalności rozwiązania, jak przedstawiono w Tabeli 5. Testy metadanych: Dystrybucja plików i katalogów między wątkami 

Liczba wątków	Liczba plików na katalog	Liczba katalogów na wątek	Łączna liczba plików
1	3000	320	960 000
2	3000	160	960 000
4	3000	80	960 000
8	3000	40	960 000
16	3000	20	960 000
32	3000	10	960 000
64	3000	8	1 536 000
128	3000	4	1 436 000
256	3000	4	3 072 000
512	3000	4	6 144 000

Na Rysunku 4, Rysunku 5 i Rysunku 6 przedstawiono odpowiednio wyniki operacji file create, stat i remove. Ponieważ klaster obliczeniowy HPC ma 32 węzły obliczeniowe, na poniższych wykresach każdy klient wykonywał maksymalnie jeden wątek na węzeł dla liczby do 32. W przypadku liczby klientów wynoszącej 64, 128, 256 i 512 każdy węzeł wykonał 2, 4, 8 lub 16 jednoczesnych operacji. Rysunek 4. IPoIB tworzenie

plików

Rysunek 5: Wydajność z dnia IPoIB



Rysunek 6: IPoIB FIE Remove Performance



 

---

Wnioski

W poniższej tabeli podsumowano zaobserwowane różnice wydajności rozwiązań NSS7.4 oraz NSS7.3.  Tabela 5: Porównanie wydajności rozwiązań NSS7.4 oraz NSS7.3

Pamięć masowa Dell EMC HPC NFS	NSS7.4-HA	NSS7.4-HA NSS7.3-HA
Maks. 1 MB zapisów: 1,4% spadku	4834 MB/s	4906 MB/s
Maks. Maksymalna wielkość odczytu z 1 MB: 0,7% spadku	7024 MB/s	7073 MB/s
Maksymalna wartość 4KB zapisów losowych: 0,7% spadku	7290 IOPS	7341 IOPS
Maksymalny odczyt 4KBa losowego: 42% spadku	16 607 IOPS	28 811 IOPS
Tworzenie operacji/drugi szczyt: 1,1% spadku	54 197 op/s	54 795 op/s
Operacje destatystyka/drugi szczyt: 35% spadku	522 231 op/s	808 317 op/s
Operacja wyjmowania/drugiego piku: 35% spadku	47 345 op/s	73 320 op/s

Z powyższych wyników można wyciągnąć wniosek, że obecne rozwiązanie NSS7.4-HA zapewnia porównywalną wydajność w porównaniu z poprzednią wersją NSS7.3-HA. Planujemy przeprowadzenie testów wydajności z procesorami Xeon Gold 6240 (18 rdzeni na procesor), aby dowiedzieć się, czy zmniejszenie wydajności odczytów losowych i zmniejszenie wydajności przy większej liczbie wątków dla operacji file stat i file remove można przypisać mniejszej liczbie rdzeni używanych w procesorach Xeon Gold 6244 (8 rdzeni na procesor) użytych w celu określenia wydajności rozwiązania NSS7.4-HA.

---

Odniesienia

Szczegółowe informacje na temat rozwiązań NSS-HA można znaleźć w naszych opublikowanych opracowaniach

 

•  Rozwiązanie pamięci masowej Dell HPC NFS — konfiguracja o wysokiej dostępności (NSS6.0-HA) z serwerami Dell PowerEdge trzynastej generacji, wersja NSS6.0-HA opublikowana w listopadzie 2014.
•  Rozwiązanie pamięci masowej Dell HPC NFS — konfiguracja o wysokiej dostępności (NSS7.0-HA), wersja NSS7.0-HA opublikowana w maju 2016.
•  Rozwiązanie Dell EMC Ready dla pamięci masowej HPC NFS, wersja NSS7.3-HA opublikowana w marcu 2019.