Ciągle rosnąca ilość danych które produkujemy w cyfrowym świecie, zmusza coraz więcej firm do korzystania z klastrów Big Data. Niestety stworzenie taniej a zarazem niezawodnej, wydajnej i gwarantującej bezpieczeństwo naszych danych infrastruktury komputerowo sieciowej nie jest wcale takie proste. W dzisiejszym artykule przybliżymy kilka najwazniejszych zasad jakimi powinno się kierować budując swoje pierwsze rozwiązania Big Data.

Architektura systemów Big Data

Systemy Big Data są z natury systemami rozproszonego przetwarzania danych. Sama technologia używana w nich pozwala na uruchomienie na pojedynczym serwerze, jednak pełne możliwości i wydajność otrzymujemy dopiero po wdrożeniu klastra obliczeniowego składającego się z kilku węzłów. Większość literatury zaleca budowanie klastrów począwszy od 5 lub nawet 10 maszyn, mniejsze klastry nie wykorzystują w pełni skalowalności (np. baza HBase) oraz replikacji czy Erasure Coding (Hadoop). Rozwiązania Big Data o których mowa potrafią pracować w środowisku heterogenicznym (różne konfiguracje maszyn), co ułatwia skalowanie klastrów w przyszłości, co oznacza, że rozbudowy dokonujemy dokupując kolejne węzły obliczeniowe a nie wymieniając je na nowsze modele.

Maszyny z których budujemy taki klaster obliczeniowy dzielimy na dwa rodzaje, maszyny typu “master” sterujące pracą klastra i narzędzi, oraz maszyny typu “slave” na których instalowane są usługi robocze, wykonujące główną pracę. Na maszynach “master” znajdą się więc takie usługi jak Namenode (HDFS), ResourceManager (YARN), HMaster (HBase), History Server, Hive Metastore czy Oozie Server. Na maszynach “slave” będą instalowane takie usługi jak DataNode (HDFS), NodeManager (YARN) czy RegionServer (HBase). Usług “slave” jest znacznie mniej, ale są za to instalowane na każdej maszynie roboczej, których może być od kilku do nawet tysięcy.

Usługi “master” są zwykle pojedynczymi serwisami, choć dla ciągłości działania zaleca się instalowanie ich w trybie wysokiej dostępności (High Availability), co wymaga postawienia minimum dwóch maszyn typu “master” gdzie usługi będą powielone. W bardzo dużych klastrach wdraża się także tak zwaną federację pozwalającą dzielić obciążenie na wiele instancji. Wyjątkiem jest narzędzie ZooKeeper które należy instalować na nieparzystej liczbie węzłów.

Usługi typu “master”, z racji swojej dużej odpowiedzialności a zarazem małej ilości, są instalowane często na sprzęcie wyższej jakości (premium, enterprise) gwarantującym ich większą niezawodność i niezawodność. Wydajność tych maszyn zależy od wielkości klastra (np. im większe zużycie przestrzeni dyskowej na HDFSie tym większe zużycie pamięci RAM przez Namenode) oraz obciążenia (więcej węzłów obliczeniowych i klientów łączących się do klastra powoduje wzrost użycia CPU, RAM i transferu danych pomiędzy urządzeniami sieciowymi). Powoduje to niestety trudność w doborze parametrów sprzętowych, dlatego gdy nie wiemy jakie będzie spodziewane obciążenia, zaleca się kupno maszyn z dużym “zapasem” mocy obliczeniowej. Dla zwiększenia wydajności i niezawodności zaleca się także instalację systemu na dyskach SSD pod kontrolą RAID.

Usługi typu “slave”, z racji dużej ilości i optymalizacji kosztów, są instalowane na znacznie tańszym sprzęcie (tak zwane “commodity hardware”) gwarantującym optymalny stosunek ceny do wydajności. Tutaj także warto instalować system operacyjny i usługi na dyskach SSD pod kontrolą RAID, w celu przyśpieszenia działania aplikacji oraz zwiększenia niezawodności całego węzła. Maszyny typu “slave” oprócz przetwarzania danych (data locality) także składują dane, dlatego każda z nich powinna mieć dodatkowe dyski przeznaczone na ten cel, dla których nie stosuje się RAID, gdyż Hadoop pracuje w podejściu JBOD gwarantującym większą wydajność oraz replikację na poziomie wielu maszyn i szaf rackowych.

Można spotkać także praktykę gdzie na maszynach “master” instalowany jest system operacyjny z płatnym wsparciem (np. RHEL, SLES, Oracle Linux), zaś na maszynach typu “slave”, w celu minimalizacji kosztów, używany jest darmowy system (np. Fedora, CentOS, Debian).

W dużych klastrach usługi typu “master” można separować na oddzielne dedykowane serwery, zwiększając ich wydajność i niezależność od innych usług, w średnich klastrach instaluje się je na wspólnych maszynach, zaś w mniejszych wdrożeniach można pokusić się o użycie tych samych maszyn co usługi typu “slave” ograniczając koszta tylko do maszyn roboczych.

Rozwiązania Big Data największą wydajność osiągają na instalacji bezpośrednio na serwerze (bare metal), jednak dla zwiększenia elastyczności, spotyka się wdrożenia oparte o wirtualizację gdzie strata mocy obliczeniowej jest uwzględniona. W tym przypadku nie zaleca się wirtualizacji przestrzeni dyskowych lecz ich bezpośrednie przyłączenie do maszyny wirtualnej. Czasami spotyka się rozwiązania gdzie maszyny typu “master” są zwirtualizowane z użyciem macierzy dyskowych, zaś tylko maszyny robocze są instalowane bezpośrednio na serwerze (bare metal). Rozwiązanie to przenosi odpowiedzialność za przetrzymywane dane na sprzęt, który w większym stopniu dba o ich dostępność zmniejszając awaryjność na poziomie warstwy sprzętowej i dedykowanego systemu.

Dobór parametrów sprzętowych

Pamięć RAM

W dzisiejszych rozwiązaniach standardem pamięci RAM jest 256 GB RAM na węzeł, czasami 512 GB na węzeł lub nawet więcej, ale ta druga opcja niestety zwiększa cenę węzła i to znacząco (w propozycjach są różne wersje, zwiększenie pamięci RAM może wymuszać kupno droższego procesora). Powyższe wartości należy traktować jako zalecane najefektywniejsze (procesy obliczeniowe z użyciem takich narzędzi jak Apache Spark wymagają dużej ilości pamięci RAM), niemniej w wiele obecnych klastrów obliczeniowych jest zbudowana z węzłów gdzie wielkość pamięci RAM na węźle obliczeniowym waha się w przedziale np. 24 - 96 GB. Minimalna wielkość poniżej której nie zalecamy schodzić to 16 GB, przy czym warto zacząć budować swoje rozwiązania począwszy od 32 GB i stopniowo zwiększać.

Rdzenie obliczeniowe

Liczba rdzeni obliczeniowych to zwykle “im więcej tym lepiej”, choć w praktyce częściej korzystniej obliczeniowo (robiliśmy takie testy na różnych serwerach) sprawdza się mniejsza liczba mocniejszych rdzeni niż większa liczba słabszych rdzeni (zakładając łączną teoretyczną moc obliczeniową na podobnym poziomie). Procesory obsługujące dużą liczbę pamięci RAM i z większą ilością rdzeni są także znacznie droższe. Popularnym rozwiązaniem są klastry z węzłami po dwa procesory 4-8 rdzeni każdy (korzystne cenowo rozwiązanie). Należy aktywować hyper-threading oraz quick-path interconnect (QPI).

Dyski twarde

W przypadku dysków twardych to obecnie najbardziej korzystnie cenowo wypadają jednostki po 3TB lub 4TB (w przeliczeniu kosztu zakupu 1TB powierzchni dyskowej), jednak w klastrach gdzie celujemy w ogromne ilości danych a niekoniecznie wielką moc obliczeniową, korzystniej jest zainstalować dyski o znacznie większej pojemności, np. 10TB. W większości przypadków dyski jakie zostały wybrane to SATA, jest to dużo tańsza alternatywa dla SAS. Dyski takie są ok. 2 razy tańsze, ale prawdopodobieństwo występowania błędów na dysku jest znacznie większe od rozwiązań SAS. Zalecenie takiego rozwiązania jest powiązane z architekturą Apache Hadoop, która dobrze radzi sobie z ryzykiem złego działania katalogu (dysku) lub całego noda (serwera). Dotychczasowe doświadczenie na jednym z większych klastrów obliczeniowych (~100 nodów, ~600 dysków enterprise SATA 3-4 TB (6 producentów) pokazuje, że na przestrzeni 5 lat pracy uległo awarii i wymianie ok. 40 dysków co wskazuje na opłacalność rozwiązania.

Z racji tego, że Hadoop i inne rozwiązania, korzystają z idei “JBOD” (Just a Box of Disks), zaleca się instalację kilku (np. 8 sztuk) lub nawet kilkunastu dysków per węzeł (np. 12 lub więcej). Użyte kontrolery RAID mają za zadanie obsłużyć mirroring na dyskach systemowych (tam gdzie było to możliwe to są dyski SSD) oraz wspomóc za pomocą cacheowania. Większość spotykanych rozwiązań korzysta średnio od 6 do 24 dysków na każdym węźle.

Hadoop Distributed File System obsługuje różne typy dysków (ARCHIVE, DISK, SSD and RAM_DISK) oraz wspiera różne polityki składowania danych (Hot, Warm, Cold, All_SSD, One_SSD and Lazy_Persist) przez co można zwiększyć wydajność klastra obliczeniowego instalując dodatkowo droższe ale znacznie szybsze dyski SSD. Dla pozostałych dysków tradycyjnych zaleca się skorzystać z wersji 7,200 RPM (modele 15,000 RPM są znacznie droższe i mnie opłacalne przez to).

Komunikacja sieciowa

Rozwiązania Big Data pracują w oparciu o ideę “Data Locality” nakazującą przetwarzanie danych tam gdzie są składowane (na tym serwerze, brak komunikacji sieciowej do macierzy i podobnych rozwiązań), jednak w przypadku niektórych analiz i algorytmów wymagana jest jak najwyższa prędkość komunikacji pomiędzy węzłami klastra obliczeniowego, dlatego mocno zalecana jest instalacja wysoko przepustowych kart sieciowych (10 Gigabit lub więcej) lub nawet większej liczby mediów komunikacyjnych (połączenia 1/4/10/40 GBps, połączenia kablem “miedzianym” lub światłowodem, łączenie interfejsów w grupy takie jak LACP)

Gwarancja producenta na sprzęt serwerowy

Przetwarzanie danych wiąże się z nasilonym dostępem do dysków, które są najbardziej narażonym elementem serwera na uszkodzenia. Rozsądnym wyborem jest przedłużenie gwarancji producenta na dyski na okres 5 lat. Po tym czasie wskazana będzie wymiana nośników na takie same w znacznie niższej cenie lub zakup dysków o większej pojemności.

Odporność na awarie: urządzenia sieciowe, zasilanie

Infrastruktura sieciowa w rozwiązaniach Big Data to kluczowy element komunikacji pomiędzy węzłami. Priorytetem jest zapewnienie możliwie największej przepustowości łącza pomiędzy węzłami. Przy większej ilości nodów należy zadbać o właściwe rozmieszczenie przełączników w infrastrukturze logicznej: węzły w obrębie jednej szafy rackowej powinny posiadać przełącznik sieciowy spięty z pozostałymi szafami rack umożliwiający komunikację z pozostałymi elementami sieci w przypadku uszkodzenia jakiegokolwiek urządzenia. Takie rozwiązanie należy również ująć w konfiguracji Data Nodów dopasowując kolejno topologie na poziomie połączeń w DC, strefy i połączenia bezpośredniego. Zaleceniem jest doprowadzenie więcej niż jednego źródła zasilania, aby brak pewnej części klastra nie wpływał znacząco na dalsze działanie systemu.

Dodatkowe materiały

Więcej na ten temat można znaleźć pod adresem:

• https://docs.hortonworks.com/HDPDocuments/HDP3/HDP-3.0.1/cluster-planning/content/conclusion.html
• https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.6.5/bk_command-line-installation/content/determine-hdp-memory-config.html
• https://spark.apache.org/docs/latest/hardware-provisioning.html
• https://hortonworks.com/blog/why-not-raid-0-its-about-time-and-snowflakes/
• https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/ArchivalStorage.html
• http://www.enterprisestorageforum.com/storage-networking/sas-vs-sata.html
• https://docs.hortonworks.com/HDPDocuments/HDP3/HDP-3.0.0/release-notes/content/removed_components.html