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

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

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

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

На практика всичко е малко по-сложно. Разпределени erlang беше разработен, когато "контейнер" означаваше голям железен ящик за превоз, а "докер" беше просто синоним на портов работник. В IP4 имаше много незаети адреси, а за мрежовите разкъсвания обикновено бяха виновни гризачите, които прегризваха кабелите, а средното време за безотказна работа на производствена система се измерваше в десетилетия.

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

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

Изисквания

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

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

Последното означава, че след като тествам приложението локално в :nonode@nohost, или в изкуствено разпределена среда с помощта на test_cluster_task, искам просто да стартирам docker-compose up --scale my_app=3 и да видя как изпълнява три инстанции в Docker без никакви промени в кода. Искам също така зависимите приложения, например mnesia — когато топологията се променя, зад кулисите да преразпределят клъстера в реално време без никакви допълнителни натиски от приложението.

Cloister не е замислен като библиотека, способна на всичко: от поддръжка на клъстера до приготвяне на кафе. Това не е сребърна куршума, стремяща се да обхване всички възможни случаи, нито академично пълно решение в смисъла, който теоретиците от CS влагат в този термин. Тази библиотека е създадена, за да обслужва много ясна цел, но да изпълнява своя не толкова голям обем работа перфектно. Тази цел ще бъде да осигури пълна прозрачност между локалната среда за разработка и разпределената еластична среда, пълна с враждебни контейнери.

Избраният подход

Cloister предполага да се стартира като приложение, въпреки че опитни потребители могат да работят със сглобяването и поддръжката на клъстера ръчно, директно стартирайки Cloister.Manager в дървото на супервизорите на целевото приложение.

При стартиране като приложение, библиотеката разчита на config, откъдето изчита следните основни стойности:

config :cloister,
  otp_app: :my_app,
  sentry: :"cloister.local", # или ~w|n1@foo n2@bar|a
  consensus: 3,              # брой на възлите, които да се считат
                             #    клъстера е активен
  listener: MyApp.Listener   # слушател, който да бъде извикан, когато
                             #    пръстенът се е променил

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

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

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

При стартиране в режим на разработка, достатъчно е просто да зададете consensus: 1 и Cloister весело ще премине очакването за събиране на кластер, видявайки :nonode@nohost, или :node@host, или :node@host.domain — в зависимост от това как е била настроена възлът (:none | :shortnames | :longnames).

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

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

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

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

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

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