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

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.

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.

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.


 
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.



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

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ń.



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).

 
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.  

 



 

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.

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.