Ir al contenido principal
  • Realice pedidos rápida y fácilmente.
  • Vea los pedidos y haga el seguimiento del estado del envío.
  • Cree una lista de sus productos y acceda a ella

PowerScale, Isilon OneFS: Testowanie wydajności HBase w Isilon

Resumen: W tym artykule przedstawiono testy porównawcze wydajności w klastrze Isilon X410 przy użyciu pakietu testów porównawczych YCSB i CDH 5.10.

Este artículo se aplica a: Este artículo no se aplica a: Este artículo no está vinculado a ningún producto específico. En este artículo no se identifican todas las versiones de los productos.

Síntomas

Niewymagany

Causa

Niewymagany

Resolución

UWAGA: Ten temat jest częścią korzystania z Hadoop z OneFS Info Hub. 


Wprowadzenie

Przeprowadziliśmy serię testów porównawczych wydajności w klastrze Isilon X410 przy użyciu pakietu testów porównawczych YCSB i CDH 5.10.

Środowisko laboratoryjne CAE POC zostało skonfigurowane z 5 węzłami Isilon x410 z obsługą oneFS 8.0.0.4 i nowszych testów porównawczych przesyłania strumieniowego dużych bloków NFS 8.0.1.1 oczekujemy 5x ~700 MB/s zapisów (3,5 GB/s) i 5x ~1 GB/s odczytów (5 GB/s) dla teoretycznych łącznych maksimów w każdym z tych testów.

(9) węzłami obliczeniowymi są serwery Dell PowerEdge FC630 z systemem CentOS 7.3.1611 każdy skonfigurowany z 2 procesorami CentOS 18C/36T-Intel Xeon® E5-2697 v4 przy 2,30 GHz z 512 GB pamięci RAM. Lokalna pamięć masowa ma 2 dyski SSD w macierzy RAID 1 sformatowane jako XFS zarówno dla systemu operacyjnego, jak i plików scratch space/spill.

Były też trzy dodatkowe serwery brzegowe, które były używane do napędzania obciążenia YCSB.

Sieć zaplecza między węzłami obliczeniowymi i Isilon to 10 Gb/s z zestawem ramek Jumbo Frame (MTU = 9162) dla kart sieciowych i portów przełącznika.

SLN319167_en_US__1i_isilon_1arch_kb_v1a
 
CDH 5.10 został skonfigurowany do uruchamiania w strefie dostępu na Isilon, konta usług zostały utworzone w lokalnym dostawcy Isilon i lokalnie w plikach klienta /etc/passwd. Wszystkie testy zostały przeprowadzone przy użyciu podstawowego użytkownika testowego bez specjalnych uprawnień.

Statystyki Isilon były monitorowane przy użyciu pakietu IIQ i Grafana/Data Insights. Statystyki CDH były monitorowane za pomocą Cloudera Manager, a także Grafana.


Wstępne testowanie

Pierwsza seria testów miała na celu określenie odpowiednich parametrów po stronie HBASE, które wpłynęły na ogólny wynik. Do wygenerowania obciążenia dla HBASE użyto narzędzia YCSB. Ten początkowy test został przeprowadzony przy użyciu jednego klienta (serwera brzegowego) przy użyciu fazy "ładowania" YCSB i 40 milionów wierszy. Tabela ta została usunięta przed każdym uruchomieniem.
 

ycsb load hbase10 -P workloads/workloada1 -p table='ycsb_40Mtable_nr' -p columnfamily=family -threads 256 -p recordcount=40000000

hbase.regionserver.maxlogs — maksymalna liczba plików dziennika zapisu (WAL). Wartość pomnożona przez rozmiar bloku HDFS (dfs.blocksize) to rozmiar wal, który musi zostać powtórzony w przypadku awarii serwera. Ta wartość jest odwrotnie proporcjonalna do częstotliwości opróżniania do dysku.

hbase.wal.regiongrouping.numgroups — w przypadku korzystania z wielu HDFS WAL jako WALProvider ustawia liczbę dzienników zapisu przed uruchomieniem każdego serwera regionu. Powoduje taką liczbę potoków HDFS. Zapisy dla danego regionu dotyczą tylko jednego potoku, rozprowadzając całkowite obciążenie serwera regionu.

SLN319167_en_US__2i_isilon_2thruvspipe_kb_v1a

SLN319167_en_US__3i_isilon_3latvspipe_kb_v1a
Celem filozofii było równoległienie jak największej liczby operacji zapisu, więc zwiększenie liczby WAL, a następnie liczba wątków (potoków) na wal pozwala to osiągnąć. Poprzednie dwa wykresy pokazują, że dla danej liczby dla "maxlogs" 128 lub 256 nie widać żadnych rzeczywistych zmian, co oznacza, że tak naprawdę nie wprowadzamy tej liczby od strony klienta. Nie zmieniaj liczby "potoków" na plik, choć trend wskazuje parametr wrażliwy na paralelizację. Następne pytanie brzmi: gdzie Isilon "sobie pomaga" dzięki we/wy dysku, sieci, procesorowi lub OneFS i możemy przyjrzeć się raportowi statystyk Isilon.

SLN319167_en_US__4i_isilon_4networkload_kb_v1a
 
Wykresy sieci i procesora informują nas, że klaster Isilon jest niedostatecznie używany i ma miejsce na więcej pracy. Procesor wynosi > 80%, a przepustowość sieci będzie przekraczać 3 GB/s.

SLN319167_en_US__5i_isilon_5proto_kb_v1a

Te wykresy pokazują statystyki protokołu HDFS i ich tłumaczenia przez OneFS. Operacje HDFS są wielokrotnościami pliku dfs.blocksize o rozmiarze 256 MB. Interesującą rzeczą jest to, że wykres "Heat" przedstawia operacje plików OneFS i widzisz korelację zapisów i blokad. W takim przypadku baza HBase dołącza pliki WAL, więc OneFS blokuje plik WAL dla każdego dołączonego zapisu. Czego możemy oczekiwać od stabilnych zapisów w klastrowanym systemie plików. Wydaje się, że przyczyniają się one do czynnika ograniczającego w tym zestawie testów.


Aktualizacje bazy danych

Ten następny test miał na celu przeprowadzenie pewnych eksperymentów w celu ustalenia, co dzieje się w skali, więc utworzono tabelę miliardów wierszy, która potrzebowała dobrej godziny, a następnie przeprowadzono uruchomienie YCSB, które zaktualizowało 10 milionów wierszy przy użyciu ustawień "workloada" (odczyt/zapis 50/50). Zostało to przeprowadzone na jednym kliencie, a także poszukiwano największej przepustowości, jaka mogłabym wygenerować, więc uruchomiłem to jako funkcję liczby wątków YCSB. Jedną z innych uwag było to, że wykonaliśmy pewne dostrajanie Isilon i przejdź do OneFS 8.0.1.1, który ma poprawki wydajności dla usługi węzła danych. Wzrost wydajności może być widoczny w porównaniu z poprzednim zestawem przebiegów. W przypadku tych uruchomień ustawiamy hbase.regionserver.maxlogs = 256 i hbase.wal.regiongrouping.numgroups = 20

SLN319167_en_US__6i_isilon_6table1_kb_v1a

SLN319167_en_US__7i_isilon_7table2_kb_v1a
SLN319167_en_US__8i_isilon_8table3_kb_v1a

Patrząc na te działanie, pierwszą rzeczą, jak widać, jest spadek przy dużej liczbie wątków. Zastanawia mnie, czy był to problem Isilon, czy problem po stronie klienta. W nadchodzących ustępach pojawią się dalsze testy. Ale można powiedzieć, że obsługa operacji 200K+ przy opóźnieniach aktualizacji wynoszących < 3 ms robi wrażenie. Każda z tych aktualizacji była szybka i mogłam wykonywać je jeden po drugim, a poniższy wykres pokazuje parzystą równowagę między węzłami Isilon dla tych uruchomień.

SLN319167_en_US__9i_isilon_9heat_kb_v1a

Na wykresie ciepła ponownie widać, że operacje plików są zapisami i blokadami odpowiadającymi charakterowi dołączeń procesów WAL.


Skalowanie serwera regionu

Następnym testem było ustalenie, w jaki sposób węzły Isilon (pięć z nich) będą radzić sobie z inną liczbą serwerów regionalnych. W tym miejscu został uruchomiony ten sam skrypt aktualizacji, który został uruchomiony podczas poprzedniego testu. Tabela z miliardami wierszy i 10 milionami wierszy zaktualizowanych przy użyciu "workloada" z jednym klientem i wątkami YCSB przy 51. Zachowaliśmy również to samo ustawienie w maxlogach i potokach (odpowiednio 256 i 20).

SLN319167_en_US__10i_isilon_10scaling1_kb_v1a

SLN319167_en_US__11i_isilon_11scaling2_kb_v1a
 
Wyniki są pouczające, ale nie zaskakują. Skalośny charakter bazy danych HBase w połączeniu ze skalownym charakterem Isilon i more==better. Jest to test, który zalecamy klientom uruchamianie w środowiskach w ramach własnych operacji zmiany rozmiaru. Może to spowodować zmniejszenie zwrotów, ale w tym przypadku mamy dziewięć serwerów nadrzędnych, które naciskają pięć węzłów Isilon i wygląda na to, że istnieje miejsce na więcej.


Więcej klientów

Ostatnie serie testów pochodzą z tego głębokiego ciemnego miejsca, co sprawia, że chcesz rozbić testowany system. W końcu jest to w pełni prawidłowa metoda naukowych, aby zatrzasnąć test, aż coś się zepsuje i wywoła, wiedząc, jakie są górne limity testowanych parametrów. W tej serii testów miałem dwa dodatkowe serwery, których mógłbym użyć do uruchomienia klienta, ponadto uruchomiłem dwa klienty YCSB na każdym z nich, co pozwoliłoby na skalowanie do sześciu klientów, z których każdy napędza 512 wątków, co stanowiłoby ogólnie 4096 wątków. Następnie utworzono dwie różne tabele, jedną z 4 miliardami wierszy podzielonymi na 600 regionów i jedną z 400 wierszami podzielonymi na 90 regionów.  

 SLN319167_en_US__12i_isilon_12clientscaling1_kb_v1a

SLN319167_en_US__13i_isilon_13clientscaling2_kb_v1a

 
SLN319167_en_US__14i_isilon_14clientscaling3_kb_v1a
Jak widać, rozmiar tabeli ma niewielkie znaczenie w tym teście. Przyjrzyjmy się ponownie wykresom temperatury Isilon, można zauważyć, że istnieje kilka procent różnicy w liczbie operacji plików, najczęściej wbudowanych w różnice między tabelą z czterema miliardami wierszy i 400 milionami wierszy.

SLN319167_en_US__15i_isilon_15row1_kb_v1a


Wnioski

HBase jest dobrym kandydatem do uruchomienia na Isilon, głównie ze względu na skalowalnej architektury. Baza HBase wykonuje wiele własnych buforów i dzieli tabelę na wiele regionów, dzięki którym baza HBase umożliwia skalowanie danych. Innymi słowy, zajmuje się własnymi potrzebami, a system plików jest dostępny w celu trwałości. Nie mogliśmy przeprowadzić testów obciążenia do momentu, w którym faktycznie coś zostało przerwane, ale jeśli przyjrzymy się czterem miliardom wierszy w konstrukcji bazy danych HBase i oczekujemy 800 000 operacji z mniejszymi niż 3 ms latencji, ta architektura ją obsługuje. Jeśli zauważysz, że nie wspomnę zbyt wiele więcej na temat żadnych zmian po stronie klienta, które można zastosować do samej bazy danych HBase, oczekuję, że wszystkie te poprawki będą nadal prawidłowe i wykraczają poza zakres tego testu.

 

Productos afectados

Isilon, PowerScale OneFS
Propiedades del artículo
Número de artículo: 000128942
Tipo de artículo: Solution
Última modificación: 20 sept 2023
Versión:  6
Encuentra las respuestas que necesitas con la ayuda de otros usuarios de Dell
Servicios de asistencia
Comprueba si tu dispositivo está cubierto por los servicios de asistencia.