Cloister → просто управление на OTP клъстер

Почти всяко успешно бизнес приложение рано или късно навлиза във фаза, в която е необходимо хоризонтално мащабиране. В много случаи можете просто да стартирате нов екземпляр и да намалите средното натоварване. Но има и по-малко тривиални случаи, в които трябва да гарантираме, че различните възли знаят един за друг и внимателно разпределят натоварването.

Оказа се такъв късмет, че ерланг, който избрахме заради приятния му синтаксис и шума около него, има първокласен поддръжка на разпределени системи. На теория това звучи напълно тривиално:

Преминаването на съобщения между процеси на различни възли, както и между връзки и монитори, е прозрачно […]

На практика всичко е малко по-сложно. Разпределен ерланг е разработен, когато „контейнер“ означава голяма желязна кутия за корабоплаване, а „докер“ е просто синоним на крайбрежник. IN IP4 имаше много незаети адреси, прекъсванията в мрежата обикновено бяха причинени от плъхове, които дъвчеха кабела, а средното време на работа на производствената система се измерваше в десетилетия.

Сега всички ние сме невероятно самодостатъчни, опаковани и работещи разпределени ерланг в среда, в която динамичните IP адреси се раздават на принципа на голяма произволност и възлите могат да се появяват и изчезват по прищявка на лявата пета на планировчика. За да избегнете купища шаблонен код във всеки проект, изпълняващ разпределен ерланг, за борба с враждебната среда е необходима помощ.

Внимание: Наясно съм, че има libcluster. Наистина е страхотно, има над хиляда звезди, авторът е известен в общността и всичко това. Ако предлаганите от този пакет методи за създаване и поддържане на клъстер са ви достатъчни, радвам се за вас. За съжаление имам нужда от много повече. Искам да контролирам настройката в детайли и да не бъда външен зрител в театъра на реорганизацията на клъстера.

Изисквания

Това, от което аз лично имах нужда, беше библиотека, която да поеме управлението на клъстера и да има следните свойства:

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

Последното означава, че след като тествах приложението локално в :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

Параметрите по-горе означават буквално следното: манастир използвани за OTP приложение :my_app, използва откриване на услуга erlang за свързване на възли, най-малко три, и MyApp.Listener модул (внедряване @behaviour Cloister.Listener) е конфигуриран да получава известия за промени в топологията. Подробно описание на пълната конфигурация можете да намерите в документация.

С тази конфигурация приложението манастир ще стартиране на етапи, забавяне на процеса на стартиране на основното приложение до постигане на консенсус (три възела са свързани и свързани, както в примера по-горе.) Това дава на основното приложение възможност да приеме, че когато стартира, клъстерът вече е наличен. Всеки път, когато топологията се промени (ще има много от тях, тъй като възлите не стартират напълно синхронно), манипулаторът ще бъде извикан MyApp.Listener.on_state_change/2. През повечето време извършваме действие, когато получим съобщение за състояние %Cloister.Monitor{status: :up}, което означава: „Здравейте, клъстерът е сглобен.“

В повечето случаи инсталация consensus: 3 е оптимално, защото дори да очакваме повече възли да се свържат, обратното извикване ще премине status: :rehashing → status: :up на всеки новодобавен или премахнат възел.

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

Управление на разпределени приложения

Разпределените приложения, които не са във вакуум, обикновено включват разпределени зависимости, като напр mnesia. За нас е лесно да се справим с тяхното преконфигуриране от същото обратно извикване on_state_change/2. Ето, например, подробно описание как да преконфигурирате mnesia в движение документация манастир.

Основното предимство на използването манастир е, че изпълнява всички необходими операции за възстановяване на клъстера след промяна на топологията под капака. Приложението просто работи във вече подготвена разпределена среда, като всички възли са свързани, независимо дали знаем IP адресите и следователно имената на възлите предварително, или те са били динамично присвоени/променени. Това не изисква абсолютно никакви специални настройки за конфигуриране на докери и от гледна точка на разработчик на приложения няма разлика между работа в разпределена среда или работа в локална. :nonode@nohost. Можете да прочетете повече за това в документация.

Въпреки че сложното обработване на промените в топологията е възможно чрез персонализирано внедряване MyApp.Listener, винаги може да има крайни случаи, при които тези библиотечни ограничения и отклонения в конфигурацията се оказват крайъгълните камъни на внедряването. Всичко е наред, просто вземете горното libcluster, което е с по-общо предназначение, или дори да управлявате сами клъстера на ниско ниво. Целта на тази кодова библиотека не е да покрие всеки възможен сценарий, а да използва най-често срещания сценарий без ненужна болка и тромаво копиране и поставяне.

Забележка: на този етап в оригинала имаше фразата "Happy clustering!", а Yandex, с който превеждам (не е нужно да минавам през речници), ми предложи опцията "Happy clustering!" Може би е невъзможно да си представим по-добър превод, особено в светлината на настоящата геополитическа ситуация.

Източник: www.habr.com