Кластер → једноставно управљање ОТП кластером

Скоро свака успешна пословна апликација пре или касније уђе у фазу у којој је потребно хоризонтално скалирање. У многим случајевима можете једноставно покренути нову инстанцу и смањити просек оптерећења. Али постоје и мање тривијални случајеви у којима морамо да обезбедимо да различити чворови знају једни за друге и да пажљиво распореде оптерећење.

Кластер → једноставно управљање ОТП кластером

Испало је тако срећно ерланг, који смо изабрали због његове пријатне синтаксе и узбуђења око ње, има прву класу подршка за дистрибуиране системе. У теорији, ово звучи потпуно тривијално:

Пролазак порука између процеса на различитим чворовима, као и између веза и монитора, је транспарентан […]

У пракси је све мало компликованије. Дистрибутед ерланг је развијено када је „контејнер“ значио велику гвоздену кутију за отпрему, а „доцкер“ је једноставно био синоним за бродара. ИН ИПКСНУМКС било је много незаузетих адреса, прекиде мреже обично су изазивали пацови који су жвакали кабл, а просечно време рада производног система мерено је деценијама.

Сада смо сви невероватно самодовољни, упаковани и дистрибуирани ерланг у окружењу где се динамичке ИП адресе деле на принципу велике насумице, а чворови се могу појавити и нестати по вољи леве пете планера. Да бисте избегли гомиле шаблонског кода у сваком пројекту који покреће дистрибуирани ерланг, за борбу против непријатељског окружења потребна је помоћ.

Приметити: Свестан сам да постоји libcluster. Заиста је кул, има преко хиљаду звездица, аутор је познат у друштву и све то. Ако су вам методе које нуди овај пакет за креирање и одржавање кластера довољне, драго ми је због вас. Нажалост, треба ми много више. Желим да детаљно контролишем поставку и да не будем спољни посматрач у театру реорганизације кластера.

Захтеви

Оно што ми је лично требало је библиотека која би преузела управљање кластером и која би имала следећа својства:

  • транспарентан рад са тврдо кодираном листом чворова и динамичким откривањем кроз услуге ерланг;
  • потпуно функционалан повратни позив за сваку промену топологије (чвор тамо, чвор овде, нестабилност мреже, поделе);
  • транспарентан интерфејс за покретање кластера са дугим и кратким именима, као с :nonode@nohost;
  • Подршка за Доцкер из кутије, без потребе за писањем инфраструктурног кода.

Ово последње значи да након што сам локално тестирао апликацију у :nonode@nohost, или у вештачки дистрибуираном окружењу користећи test_cluster_task, само желим да трчим docker-compose up --scale my_app=3 и погледајте како извршава три инстанце у Доцкер-у без икаквих промена кода. Такође желим зависне апликације као што су mnesia - када се топологија промени, иза кулиса они поново граде кластер уживо без икаквих додатних удараца из апликације.

Клаустра није била намењена да буде библиотека способна за све, од подржавања кластера до прављења кафе. То није сребрни метак који има за циљ да покрије све могуће случајеве, или да буде академски целовито решење у смислу да теоретичари из CS ставити у овај термин. Ова библиотека је дизајнирана да служи врло јасној сврси, али савршено ради свој не тако велики посао. Овај циљ ће бити да се обезбеди потпуна транспарентност између локалног развојног окружења и дистрибуираног еластичног окружења пуног непријатељских контејнера.

Одабрани приступ

Клаустра је намењен за покретање као апликација, иако напредни корисници могу да раде са склапањем и одржавањем кластера ручно директним покретањем Cloister.Manager у стаблу надзора циљне апликације.

Када се покреће као апликација, библиотека се ослања на config, из које чита следеће основне вредности:

config :cloister,
  otp_app: :my_app,
  sentry: :"cloister.local", # or ~w|n1@foo n2@bar|a
  consensus: 3,              # number of nodes to consider
                             #    the cluster is up
  listener: MyApp.Listener   # listener to be called when
                             #    the ring has changed

Горе наведени параметри буквално значе следеће: Клаустра користи се за ОТП апликацију :my_app, користи ерланг сервице дисцовери за повезивање чворова, најмање три, и MyApp.Listener модул (спровођење @behaviour Cloister.Listener) је конфигурисан да прима обавештења о променама топологије. Детаљан опис комплетне конфигурације можете пронаћи у документација.

Са овом конфигурацијом, апликација Клаустра воља лансирати у фазама, одлажући процес покретања главне апликације док се не постигне консензус (три чвора су повезана и повезана, као у горњем примеру.) Ово даје главној апликацији могућност да претпостави да је кластер већ доступан када се покрене. Кад год се топологија промени (биће их много, јер чворови не почињу потпуно синхроно), руковалац ће бити позван MyApp.Listener.on_state_change/2. Већину времена извршимо радњу када примимо статусну поруку %Cloister.Monitor{status: :up}, што значи: „Здраво, група је састављена.“

У већини случајева, инсталација consensus: 3 је оптималан јер чак и ако очекујемо да ће се повезати више чворова, повратни позив ће проћи status: :rehashingstatus: :up на било ком новододатом или уклоњеном чвору.

Када почињете у развојном режиму, само треба да подесите consensus: 1 и Клаустра са задовољством ће прескочити чекање за склапање кластера када види :nonode@nohostИли :node@hostИли :[email protected] - у зависности од тога како је чвор конфигурисан (:none | :shortnames | :longnames).

Управљање дистрибуираним апликацијама

Дистрибуиране апликације које нису у вакууму обично укључују дистрибуиране зависности, као нпр mnesia. Лако нам је да управљамо њиховом реконфигурацијом из истог повратног позива on_state_change/2. Ево, на пример, детаљног описа како да поново конфигуришете mnesia на лет у документација Клаустра.

Главна предност коришћења Клаустра је да обавља све неопходне операције да поново изгради кластер након промене топологије под хаубом. Апликација једноставно ради у већ припремљеном дистрибуираном окружењу, са свим чворовима повезаним, без обзира да ли знамо унапред ИП адресе, а самим тим и имена чворова, или су они динамички додељени/промењени. Ово не захтева апсолутно никаква посебна подешавања конфигурације доцкер-а и са тачке гледишта програмера апликације, нема разлике између покретања у дистрибуираном окружењу или рада у локалном. :nonode@nohost. Више о овоме можете прочитати у документација.

Иако је сложено руковање променама топологије могуће кроз прилагођену имплементацију MyApp.Listener, увек могу постојати ивични случајеви у којима се ова ограничења библиотеке и пристрасности у конфигурацији покажу као камен темељац имплементације. У реду је, само узми горе наведено libcluster, који је више опште намене, или чак сами рукујте кластером ниског нивоа. Циљ ове библиотеке кодова није да покрије сваки могући сценарио, већ да користи најчешћи сценарио без непотребног бола и гломазног цопи-пасте-а.

Напомена: у овом тренутку у оригиналу је била фраза „Срећно груписање!“, а Иандек, са којим преводим (не морам сам да пролазим кроз речнике), ми је понудио опцију „Срећно кластерисање!“ Бољи превод је можда немогуће замислити, посебно у светлу актуелне геополитичке ситуације.

Извор: ввв.хабр.цом

Додај коментар