Оперативна база данни на CDP (COD) е автономна транзакционна база данни, захранвана от Apache HBase и Apache Phoenix. Това е една от основните услуги за данни, която работи на Cloudera Data Platform (CDP) Public Cloud. Можете да получите достъп до COD директно от вашата CDP конзола. С COD разработчиците на приложения вече могат да използват силата на HBase и Phoenix без допълнителни разходи, които често са свързани с внедряването и управлението. COD е лесен за предоставяне и самоуправляващ се, което означава, че разработчиците могат да предоставят нов екземпляр на база данни за минути и да започнат бързо да създават прототипи. Автономните функции като автоматично мащабиране, автоматично заздравяване и автоматична настройка гарантират, че няма управление и администриране на базата данни, за които да се притеснявате.
В този блог ще споделим как CDP Operational Database може да осигури висока наличност за вашите приложения, когато работят в множество зони за наличност в AWS.
За да разберете напълно какво е разгръщане в няколко AZ означава за вашата инфраструктура, от решаващо значение е да разпознаете как са конфигурирани Amazon Web Services по целия свят и по този начин как предоставя услугите за резервиране, независимо от вашето местоположение. Както е обсъдено в официалната документация на Amazon, AWS Cloud се състои от редица региони, които са физически местоположения по целия свят. Докато прекъсванията в AZ не се проследяват официално, клиентите на Cloudera съобщават, че са имали прекъсвания в AZ 1-2 пъти годишно. Така че, за да се постигне 99,95+% наличност, е необходимо разтягане на няколко AZ.
Всеки регион включва редица отделни физически центрове за данни, известни като зони за достъпност (AZ) . Всеки AZ е самостоятелно съоръжение със собствена мощност, свързаност и възможности за работа в мрежа. Повечето региони са дом на 2-3 различни зони за наличност всяка, осигурявайки адекватно резервиране в рамките на даден регион (AZ е представен от код на региона, последван от идентификатор на буква; например us-west-1a) .
Това резервиране обаче се прилага само към слоя за съхранение (S3) и не съществува за виртуални машини, използвани за вашия екземпляр на база данни. Ако нещо доведе до прекъсване на зоната за достъпност, където се намират сървърните ви екземпляри, вашата база данни ще престане да функционира, тъй като цялата изчислителна инфраструктура ще бъде офлайн.
Тук идва разгръщането в няколко AZ. Разгръщането в няколко AZ означава, че изчислителната инфраструктура за главните и регионалните сървъри на HBase се разпределят в множество зони за достъпност, което гарантира, че когато една зона за достъпност има прекъсване, само част от регионалните сървъри ще бъдат засегнати и клиентите автоматично ще преминат към останалите сървъри в наличните AZ. По същия начин, резервният главен (ако приемем, че основният главен е бил в AZ с прекъсване) автоматично ще поеме ролята на неизправния главен, тъй като е разположен в отделна AZ от основния главен сървър. Всичко това е автоматично и не изисква настройка, управление и действия от потребителска/административна гледна точка. Той просто работи, за да гарантира, че приложението няма да претърпи прекъсване поради загуба на един AZ.
Демо
Новосъздадените COD бази данни автоматично ще се възползват от всички конфигурирани зони за наличност в средата. Ето защо е изключително важно да настроим средата със зоните, които бихме искали да използваме.
Например, имаме среда със следните AZ:us-west-1a, us-west-1b и us-west-1c. Когато разгръщаме база данни на COD, тя автоматично се разгръща по начин с няколко AZ – няма какво да се прави! Нека да проверим зад кулисите и да видим какво има на конзолата на AWS.
COD гарантира, че работните възли са еднакво разпределени между конфигурирани AZ. (Господарите и лидерът също са разположени в различни AZ, за да се осигури висока наличност за кворума ZooKeeper.)
Apache HBase вече има вградени възможности за преодоляване на срив, така че в случай, че един AZ излезе офлайн, системата вече е на място, за да продължи незабавно и автоматично услугите на вашата база данни.
За да добавим още малко забавление, нека проведем прост тест за натоварване на HBase по време на нашето тестване. HBase има вграден инструмент за тестване на натоварване, който можем да използваме за продължителен тест за писане:
hbase ltt -write 10:1024:10 -num_keys 10000000
Нека сега симулираме провал на AZ и да видим какво ще се случи. Най-лесният начин да направите това е да добавите нов мрежов ACL, който деактивира входящия и изходящия трафик на дадена подмрежа, изпълняваща условия, подобни на истинско прекъсване на AWS.
В първата минута не виждаме нищо особено интересно на страницата за състоянието, защото от гледна точка на COD базата данни все още е здрава.
Но забелязах, че клиентът е спрял да напредва.
След 10-20 секунди Капитанът разбира, че някои от регионалните сървъри са мъртви.
Ако прекъсването засегне активния главен, HBase автоматично ще премине към резервния, който поема ролята след 10-20 секунди..
Неуспехът не отнема много време, след 2-3 минути и някои преходни регионални грешки клиентът може да постигне напредък отново. Капитанът трябваше да прехвърли мъртвите региони към живи регионални сървъри.
За да симулираме края на прекъсването, нека отменим създаването на мрежов ACL, като го изтрием. Регионалните сървъри се свързват обратно към главния.
Сега се върнахме откъдето започнахме първоначално. COD се възстанови напълно от прекъсването. В заявките за запис можем да видим две спадове:първото е, когато клиентът премина към останалите живи регионални сървъри, второто малко по-късно е, когато балансиращото натоварване на HBase премести обратно регионите към повторно свързаните сървъри.
COD на HDFS
Обектното съхранение в облака е слоят за съхранение по подразбиране за COD и разпространява данни в 3 зони на наличност отзад и ще балансира отново зад кулисите. HBase трябва само да извърши малко домакинство (преход на региона), за да обслужва регионите от останалите сървъри, което прави това сравнително бърза операция.
За случаи на използване с висока производителност, COD поддържа използването на HDFS като основно хранилище. В тази парадигма за разгръщане ние автоматично конфигурираме осъзнаването на HDFS стелажа за отказоустойчивост, като поставим една блокова реплика на различен багажник и съпоставяме стелажите към зоните за наличност. Това осигурява наличност на данни в случай на повреда на мрежовия превключвател или дял в клъстера. Така че поведението в демонстрацията по-горе е много подобно на това, което бихте видели, когато разгръщате COD с HDFS.
Резюме
Внедряването в няколко AZ е от решаващо значение за високодостъпните бази данни и сега COD го поддържа в AWS като технически преглед зад кулисите без допълнителни разходи. Това прави вашето работно натоварване по-стабилно и надеждно с нулева допълнителна конфигурация. Скоро ще бъде общодостъпен и ще поддържа допълнителни доставчици на облак (Microsoft, Google).
Свържете се с екипа на вашия акаунт в Cloudera, ако се интересувате да научите повече за това как да мигрирате от внедряването на HBase към CDP оперативна база данни в публичния облак или се завъртете с Cloudera Test Drive.
