Więcej niż jeden klaster

Zanim pojawił się YARN, ustalenie harmonogramu zadań było dość prymitywnym procesem z ograniczonymi możliwościami określania priorytetów zadań. Mając do dyspozycji YARN, można stosunkowo łatwo współdzielić zasoby klastra między kilka zadań działających równolegle. Ta właściwość YARN sprawia, że zarządzanie pojedynczym klastrem staje się znacznie prostszy, a w konsekwencji prowadzi do wyraźnej redukcji kosztów.

Mimo oczywistych korzyści płynących z YARN, jest kilka sytuacji, w których zarządzanie oddzielnymi klastrami Hadoopa ma uzasadnienie. Zaliczają się do nich:

• Optymalizacja zadań. Hadoop może obecnie realizować różne typy zadań, w tym MapReduce, interakcje z ustrukturyzowanymi danymi przypominające bazę danych SQL z użyciem takich narzędzi, jak Hive czy Impala lub obsługiwać transakcyjne systemy NoSQL z użyciem HBase czy Accumulo. Można też wymienić analitykę in-memory czy przetwarzanie strumieni danych. Każde z tych zadań ma nieco inne wymagania odnośnie przepustowości sieci, obciążenia procesorów, wykorzystania pamięci, dostępnej przestrzeni dyskowej czy szybkości operacji wejścia/wyjścia. Mimo że YARN odpowiada za przydzielanie zadań do dostępnych zasobów, w większości przypadków zakłada, że węzły w klastrze są sobie równe. Jednak nie jest to dobre założenie, jeśli węzły w klastrze mają różne parametry sprzętowe. Mimo że w jednym klastrze Hadoopa można uruchamiać różne zadania, posiadanie kilku klastrów może przynosić korzyści, jeśli budowa poszczególnych klastrów jest zoptymalizowana pod kątem realizacji określonych zadań.
• Wysoki poziom wykorzystania klastra. Jeśli posiadany klaster charakteryzuje się regularnym wysokim poziomem wykorzystania przez dwa lub więcej różnych zadań, warto rozważyć rozbudowę o dodatkowe zasoby lub utworzenie oddzielnego klastra.
• Rozdzielenie zadań. Hadoop jest coraz częściej używany do obsługi krytycznych aplikacji. Jednocześnie deweloperzy nadal testują nowe możliwości wykorzystania klastrów Hadoopa, sprawdzają nowe komponenty i przesuwają dalej granice tego, co można zrealizować z wykorzystaniem Hadoopa. W celu zapewnienia niezawodności kluczowych aplikacji, wielu praktyków woli oddzielić obsługiwane przez Hadoopa aplikacje biznesowe od działań deweloperskich, które mogą spowodować awarię klastra lub obarczyć go nieprzewidywalnymi obciążeniami. W większości przypadków prowadzenie dwóch niezależnych klastrów jest najprostszym sposobem, aby zapewnić rozdział między tymi dwoma typami zadań.
• Konkurencyjne cele biznesowe. Jeśli w firmie wiele działów korzysta z Hadoopa, ich zapotrzebowanie na zasoby klastra jest względem siebie konkurencyjne. Jeśli budżety są zdecentralizowane, a problem konkurencyjnych żądań nie zostanie rozwiązany polubownie, organizacje mogą zdecydować się na proste rozwiązanie – dać każdemu działowi do dyspozycji własny klaster.

Pozostałe sytuacje, w których można wziąć pod rozwagę utworzenie odrębnych klastrów Hadoop:

• Przywracanie po klęskach żywiołowych (Disaster Recovery). Można utrzymywać dwa oddzielne, ale zsynchronizowane klastry, dzięki czemu lokalizacja zapasowa może przejąć w całości wszystkie zadania, jeśli podstawowe centrum danych przestanie działać. Takie firmy, jak CloudVelox, coraz częściej oferują rozwiązania DR budowane na bazie chmury, ale większość inwestycji w tym obszarze skupia się na budowaniu zreplikowanej infrastruktury.
• Wymagania prawne. Takie branże, jak usługi finansowe, służba zdrowia czy producenci leków są objęci szeregiem regulacji prawnych, zarówno krajowych, jak i międzynarodowych. Te regulacje mogą wymagać przechowywania danych w określonych obszarach geograficznych, oddzielenia danych biznesowych od danych dotyczących innego obszaru biznesowego, czy nawet posiadania identycznych kopii przechowywanych w różnych lokalizacjach. Takie wymagania mogą oznaczać, że firma musi mieć więcej niż jeden klaster Hadoopa.
• Zadania Hadoop obejmują pozyskiwanie, przetwarzanie i analizę dużych ilości danych. Nawet w obrębie jednego centrum danych, gdzie szybkość transmisji w sieci lokalnej jest wysoka, a infrastruktura zoptymalizowana, realizacja wymienionych zadań może być wyzwaniem. Dla firm działających międzynarodowo wyzwania związane z ciągłym, powtarzającym się przenoszeniem znacznych ilości danych mogą okazać się zbyt poważnym problemem. W takich sytuacjach posiadanie oddzielnych klastrów Hadoopa w każdym regionie przetwarzającym dane jest uzasadnione.

Jak do tych okoliczności ma się koncepcja jeziora danych? Firmy mają wiele powodów, aby utrzymywać więcej niż jeden klaster Hadoopa. W takiej sytuacji jednym z poważnych wyzwań jest bardzo realne zagrożenie powstania duplikatów danych i tworzeniem odizolowanych obszarów. To są problemy, które koncepcja jeziora danych ma rozwiązać. Jeśli klaster Hadoopa jest zarządzany całkowicie niezależnie od pozostałych, przypisany do niego systemów plików HDFS również będzie domyślnie również oddzielony od pozostałych. W niektórych sytuacjach posiadanie oddzielnych klastrów Hadoopa zostanie poczytane za zaletę, ale w większości przypadków powoduje przede wszystkim dodatkowe problemy.

Zobacz również:

• IDC CIO Summit – potencjał drzemiący w algorytmach

Synchronizacja danych między lokalizacjami, niekiedy znacznie oddalonymi od siebie, jest powszechnym problemem, dotyczącym nie tylko Hadoopa. Powstał nawet cały segment firm oferujących narzędzia i procesy mające rozwiązać ten problem, zresztą z różnym skutkiem. Duże ilości danych przetwarzane w zadaniach Hadoopa jeszcze zwiększają złożoność tego wyzwania, ale jest kilka opcji replikacji między klastrami, które dają pewne efekty:

• Narzędzia działające na niskim, jak rsync, umożliwiają przyrostowe kopiowanie plików z jednego systemu plików do drugiego. Proste sumy kontrolne są wykorzystywane do weryfikowania, czy dane zostały skopiowane bez zmian. Jednakże przy ilościach danych składowanych w klastrach Hadoopa ciągłe wyliczanie sum kontrolnych i przenoszenie zmian między systemami powoduje tak duży narzut wydajności, że takie rozwiązanie może okazać się nieakceptowalne. W ekstremalnych przypadkach, kopiowanie zmian może być opóźnione o godziny, a nawet dni w stosunku do oryginalnych zmian, co nie wchodzi w grę w większości przypadków.
• Hadoop ma również wbudowane narzędzie DistCp (Distributed Copy), którego zadaniem jest kopiowanie danych w obrębie klastra oraz między klastrami. Najczęściej działa niezawodnie, ale w niektórych sytuacjach odczuwa się jego ograniczenia. Przykładowo, może nie rozpoznawać zmian w plikach, jeśli ich nazwy lub rozmiar nie zmieniły się. Również problemy z komunikacją sieciową między lokalizacjami mogą spowodować błędy, których DistCp nie skoryguje. Podstawowy proces kopiowania dużych plików między węzłami może spowodować nadmierne obciążenie sieci, a przez to obniżyć wydajność klastra.
• Dla danych pozyskiwanych spoza klastra można wykorzystać takie projekty związane z Hadoopem, jak Flume oraz Kafka. Ich zadaniem jest pilnowanie, aby nadchodzące dane były natychmiast kopiowane do dwóch lub więcej lokalizacji. Oba narzędzia są dobrze dostosowane do przetwarzania strumieni danych przychodzących ze zdalnych czujników czy też do importowania logów z zewnętrznych procesów monitorowania. Żadne nie jest jednak zoptymalizowane pod kątem przenoszenia danych między klastrami.

Alternatywnym rozwiązaniem jest połączenie w pulę zasobów dyskowych HDFS z różnych klastrów Hadoopa. W ten sposób powstanie współdzielona przestrzeń dyskowa, do której dostęp mają różne zasoby obliczeniowe, które nadal pozostają niezależne, pracując w różnych klastrach.

Większa moc obliczeniowa

Jedną z zalet takiego podejścia jest stworzenie warunków do zaprzęgnięcia do pracy pozostających w stanie bezczynności klastrów zapasowych. Jeśli w ramach DR wybudowano zapasową lokalizację, jej synchronizacja (replikacja danych z klastra Hadoopa) z lokalizacją produkcyjną wiąże się z zużyciem prądu i obciążeniem sieci. Jednak zasoby obliczeniowe w lokalizacji zapasowej są niewykorzystywane dopóki nie pojawiają się problemy w lokalizacji produkcyjnej i nastąpi przełączenie. Mając utworzoną wspólną pulę przestrzeni dyskowej, pamięci masowe w lokalizacji DR mogą być wykorzystywane do zapisu i odczytu. Można w nich zapisywać aktualizacje z podstawowego klastra, a także przesyłać do niego z powrotem zmiany zachodzące lokalnie. W takich warunkach użytkownik może zaprząc bezczynne, zapasowe węzły do przetwarzania danych, które można udostępnić innym działom biznesowym. Może to być rutynowe rozwiązanie lub sposób na tanie obsłużenie okazjonalnych skoków zapotrzebowania na zasoby obliczeniowe. Niektóre firmy z branży IT obsługują już klientów z silnie regulowanych branż, jak usługi finansowe, którzy testują wdrożenia bazujące na tej koncepcji.

Wspólne dyski, oddzielne procesory

To samo podejście można zastosować do pokonania wyzwań związanych z optymalizacją obsługi zadań. YARN odpowiada za alokację zadań do dostępnych zasobów w klastrze. Jednakże w swojej obecnie formie YARN nie zawsze potrafi efektywnie przydzielać poszczególne typy zadań do najbardziej odpowiednich dla nich zasobów. W efekcie priorytetowe zadania mogą wylądować na sprzęcie o niższej wydajności w stosunku do pozostałych węzłów klastra. Zadania, które potrzebują dużych ilości pamięci operacyjnej i szybszej sieci mogą trafić do maszyn nie mających takich cech, podczas gdy mniej wymagające zadania zostaną uruchomione na sprzęcie o lepszej konfiguracji.

Mając wszystkie dyski połączone w jedną, logiczną pulę, łatwiej daje się tworzyć małe, bardziej specjalizowane klastry, efektywniej realizujące przydzielane im zadania. Jeden klaster może być zoptymalizowany do przetwarzania strumieni danych, drugi do przetwarzania w pamięci operacyjnej, a trzeci do realizacji zadań o niższym priorytecie. Wszystkie trzy mogą współdzielić tę samą przestrzeń dyskową.

Kolejne kroki

Zadania realizowane przez Hadoopa stają się coraz bardziej skomplikowane, wyrafinowane i ważniejsze dla firm. Istniejące narzędzia do zarządzania klastrami, jak YARN czy

Oozie (umożliwia tworzenie harmonogramu zadań) dobrze odpowiadają potrzebom większości projektów. Jednakże nie sprawdzają się w niektórych przypadkach, jak DR, optymalizacja wykorzystania zasobów czy konieczność spełnienia wymagań prawnych. Te zastosowania i inne podobne będą coraz powszechniejsze w przyszłości. Wciąż czekamy, aż społeczność pracująca nad takimi komponentami Hadoopa, jak YARN i Oozie opracuje rozwiązania, które umożliwią pokonanie obecnych ograniczeń.

Rosnące zapotrzebowanie od firm mogących potencjalnie na tym skorzystać, szczególnie z branż regulowanych prawnie, bez wątpienia będzie napędzało rozwój nowych funkcjonalności. Potrzeba jednak czasu, żeby nowe projekty nabrały rozpędu. Dla komercyjnych dostawców jest to okazja, aby w krótkim i średnim terminie zaoferować rozwiązania dostosowane do tych grup klientów, które najbardziej odczuwają obecne ograniczenia Hadoopa.