HBase
 sql >> Baza danych >  >> NoSQL >> HBase

Wysoka dostępność (Multi-AZ) dla operacyjnej bazy danych CDP

Operacyjna baza danych CDP (COD) to autonomiczna baza danych transakcyjnych obsługiwana przez Apache HBase i Apache Phoenix. Jest to jedna z głównych usług danych, która działa w chmurze publicznej Cloudera Data Platform (CDP). Możesz uzyskać dostęp do COD bezpośrednio z konsoli CDP. Dzięki COD programiści aplikacji mogą teraz wykorzystać możliwości HBase i Phoenix bez kosztów ogólnych, które często są związane z wdrażaniem i zarządzaniem. COD jest łatwe do udostępnienia i samozarządzania, co oznacza, że ​​programiści mogą udostępnić nową instancję bazy danych w ciągu kilku minut i szybko rozpocząć tworzenie prototypów. Autonomiczne funkcje, takie jak automatyczne skalowanie, automatyczne naprawianie i automatyczne dostrajanie, zapewniają, że nie trzeba się martwić o zarządzanie i administrowanie bazą danych.

W tym blogu podzielimy się, w jaki sposób operacyjna baza danych CDP może zapewnić wysoką dostępność dla Twoich aplikacji podczas uruchamiania w wielu strefach dostępności w AWS.

Aby w pełni zrozumieć, co wdrożenie Multi-AZ oznacza dla Twojej infrastruktury, ważne jest, aby rozpoznać, w jaki sposób Amazon Web Services jest skonfigurowany na całym świecie, a tym samym w jaki sposób zapewnia usługi redundancji bez względu na Twoją lokalizację. Jak wspomniano w oficjalnej dokumentacji Amazon, chmura AWS składa się z wielu regionów, które są fizycznymi lokalizacjami na całym świecie. Chociaż awarie AZ nie są oficjalnie śledzone, klienci Cloudera zgłaszali, że doświadczyli awarii AZ 1-2 razy w roku. Tak więc wdrożenia Multi-AZ stretch są wymagane, aby osiągnąć 99,95+% dostępności.

Każdy region składa się z kilku oddzielnych fizycznych centrów danych, znanych jako strefy dostępności (AZ) . Każdy AZ jest samodzielnym obiektem z własnym zasilaniem, łącznością i możliwościami sieciowymi. W większości regionów znajdują się 2-3 różne strefy dostępności, co zapewnia odpowiednią nadmiarowość w danym regionie (AZ jest reprezentowany przez kod regionu, po którym następuje identyfikator literowy; na przykład us-west-1a) .

Jednak ta nadmiarowość jest stosowana tylko do warstwy magazynowania (S3) i nie istnieje w przypadku maszyn wirtualnych używanych w instancji bazy danych. Gdyby coś spowodowało awarię strefy dostępności, w której znajdują się instancje serwera, baza danych przestałaby działać, ponieważ cała infrastruktura obliczeniowa byłaby w trybie offline.

W tym miejscu pojawia się wdrożenie Multi-AZ. Wdrożenie Multi-AZ oznacza, że ​​infrastruktura obliczeniowa dla serwerów głównych i regionalnych HBase jest rozproszona w wielu strefach dostępności, dzięki czemu w przypadku awarii jednej strefy dostępności tylko część serwerów regionalnych będzie dotyczy, a klienci automatycznie przełączą się na pozostałe serwery w dostępnych AZ. Podobnie zapasowy master (zakładając, że podstawowy master był w strefie AZ, w której wystąpiła awaria) automatycznie przejmie rolę uszkodzonego mastera, ponieważ jest wdrożony w oddzielnym AZ od głównego serwera master. Wszystko to odbywa się automatycznie, nie wymaga konfiguracji, zarządzania ani działań z punktu widzenia użytkownika/administratora. Po prostu działa, aby zapewnić, że aplikacja nie przestanie działać z powodu utraty jednego AZ.

Demo

Nowo utworzone bazy danych COD automatycznie wykorzystają wszystkie skonfigurowane strefy dostępności w środowisku. Dlatego tak ważne jest ustawienie środowiska ze strefami, z których chcielibyśmy korzystać.

Na przykład mamy środowisko z następującymi AZ:us-west-1a, us-west-1b i us-west-1c. Kiedy wdrażamy bazę danych COD, jest ona automatycznie wdrażana w sposób multi-AZ — nie ma nic do zrobienia! Zajrzyjmy za kulisy i zobaczmy, co jest na konsoli AWS.

COD zapewnia, że ​​węzły procesu roboczego są równomiernie rozłożone w skonfigurowanych strefach AZ. (Masters i Leader są również wdrażani w różnych AZ, aby zapewnić wysoką dostępność kworum ZooKeeper).

Apache HBase ma już wbudowane funkcje przełączania awaryjnego, więc w przypadku, gdy jeden AZ przejdzie w tryb offline, system jest już na miejscu, aby natychmiast i automatycznie kontynuować usługi Twojej bazy danych.

Aby dodać trochę więcej zabawy, przeprowadźmy prosty test obciążenia HBase podczas naszych testów. HBase ma wbudowane narzędzie do testowania obciążenia, którego możemy użyć do długotrwałych testów zapisu:

hbase ltt -write 10:1024:10 -num_keys 10000000

Zasymulujmy teraz awarię AZ i zobaczmy, co się stanie. Najprostszym sposobem, aby to zrobić, jest dodanie nowej listy ACL sieci, która wyłącza ruch przychodzący i wychodzący z danej podsieci wykonującej warunki podobne do rzeczywistej awarii AWS.

W pierwszej minucie nie widzimy nic szczególnie interesującego na stronie statusu, ponieważ z punktu widzenia COD baza danych jest nadal zdrowa.

Ale zauważyłem, że klient przestał robić postępy.

W ciągu 10-20 sekund Mistrz uświadamia sobie, że niektóre Serwery Regionów są martwe.

Jeśli awaria dotyczy aktywnego mastera, HBase automatycznie przełączy się na kopię zapasową, która przejmie rolę po 10-20 sekundach.

Awaria nie trwa zbyt długo, po 2-3 minutach i kilku przejściowych błędach regionu klient jest w stanie ponownie zrobić postęp. Master musiał przenieść martwe regiony na żywe serwery regionów.

Aby zasymulować koniec awarii, cofnijmy tworzenie listy ACL sieci, usuwając ją. Serwery regionalne łączą się z powrotem z Master.

Teraz jesteśmy z powrotem tam, gdzie zaczęliśmy. COD w pełni odzyskał sprawność po awarii. W żądaniach zapisu widzimy dwa spadki:pierwszy występuje, gdy klient przeszedł na pozostałe działające regiony serwerów, drugi nieco później ma miejsce, gdy system równoważenia obciążenia HBase przeniósł regiony z powrotem do ponownie podłączonych serwerów.

COD na HDFS

Obiektowa pamięć masowa w chmurze jest domyślną warstwą przechowywania dla COD i rozkłada dane w 3 strefach dostępności z tyłu i ponownie równoważy się za kulisami. HBase musi tylko wykonać pewne czynności porządkowe (przemianę regionów), aby obsługiwać regiony przez pozostałe serwery, dzięki czemu jest to stosunkowo szybka operacja.

W przypadku użycia o wysokiej wydajności COD obsługuje używanie HDFS jako podstawowej pamięci masowej. W tym paradygmacie wdrażania automatycznie konfigurujemy świadomość szafy HDFS pod kątem odporności na awarie, umieszczając jedną replikę blokową w innym stojaku i mapując stojaki na strefy dostępności. Zapewnia to dostępność danych w przypadku awarii przełącznika sieciowego lub partycji w klastrze. Tak więc zachowanie w powyższym demo jest bardzo podobne do tego, co można zobaczyć podczas wdrażania COD z HDFS.

Podsumowanie

Wdrożenie Multi-AZ ma kluczowe znaczenie dla wysoce dostępnych baz danych, a teraz COD obsługuje je w AWS jako podgląd techniczny za kulisami bez dodatkowych kosztów. Dzięki temu obciążenie operacyjne jest bardziej niezawodne i niezawodne bez dodatkowej konfiguracji. Będzie zarówno ogólnie dostępny, jak i wkrótce będzie obsługiwać dodatkowych dostawców chmury (Microsoft, Google).

Skontaktuj się z zespołem ds. kont Cloudera, jeśli chcesz dowiedzieć się więcej o tym, jak przeprowadzić migrację z wdrożenia HBase do operacyjnej bazy danych CDP w chmurze publicznej lub zabierz ją na przejażdżkę testową Cloudera.


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Tworzenie aplikacji do uczenia maszynowego za pomocą środowiska pracy i operacyjnej bazy danych Cloudera Data Science, część 1:Konfiguracja i podstawy

  2. HDFS Disk Balancer Wprowadzenie, operacje i funkcje

  3. Przegląd replikacji Apache HBase

  4. Wtyczka Cloudera Replication umożliwia replikację x-platform dla Apache HBase

  5. Instrukcje:testowanie aplikacji HBase przy użyciu popularnych narzędzi