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

Речиси секоја успешна деловна апликација порано или подоцна влегува во фаза кога е потребно хоризонтално скалирање. Во многу случаи, можете едноставно да започнете нов пример и да го намалите просекот на оптоварување. Но, има и помалку тривијални случаи каде што треба да се погрижиме различните јазли да знаат еден за друг и внимателно да го дистрибуираат обемот на работа.

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

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

Во пракса, сè е малку покомплицирано. Дистрибуирани ерлаган беше развиен кога „контејнер“ означуваше голема железна кутија за превоз, а „докер“ беше едноставно синоним за долготрајниот човек. ВО IP4 имаше многу неискористени адреси, прекините на мрежата обично беа предизвикани од стаорци кои џвакаа низ кабли, а просечното време на работа на производствениот систем се мери со децении.

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

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

Барања

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

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

Последново значи дека откако ја тестирав апликацијата локално во :nonode@nohost, или во вештачки дистрибуирана средина користејќи test_cluster_task, само сакам да трчам docker-compose up --scale my_app=3 и видете како извршува три примери во docker без никакви промени на кодот. Сакам и зависни апликации како 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Или :node@host.domain - во зависност од тоа како е конфигуриран јазолот (:none | :shortnames | :longnames).

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

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

Главната предност на користењето Манастир е тоа што ги извршува сите потребни операции за обнова на кластерот по промена на топологијата под хауба. Апликацијата едноставно работи во веќе подготвена дистрибуирана околина, со сите јазли поврзани, без разлика дали однапред ги знаеме IP адресите и затоа имињата на јазлите или тие се динамички доделени/променети. Ова не бара апсолутно никакви посебни поставки за конфигурација на докерот и од гледна точка на развивачот на апликации, нема разлика помеѓу работи во дистрибуирана средина или работа во локална. :nonode@nohost. Можете да прочитате повеќе за ова во документација.

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

Забелешка: во овој момент во оригиналот имаше фраза „Среќно кластерирање!“, а Yandex, со кој преведувам (не мора сам да одам низ речници), ми ја понуди опцијата „Среќно кластерирање!“ Можеби е невозможно да се замисли подобар превод, особено во светло на моменталната геополитичка ситуација.

Извор: www.habr.com