Klooster → eenvoudige OTP-klusterbestuur

Byna elke suksesvolle besigheidsaansoek betree vroeër of later 'n fase waar horisontale skaal vereis word. In baie gevalle kan jy eenvoudig 'n nuwe instansie begin en die vraggemiddelde verminder. Maar daar is ook minder onbenullige gevalle waar ons moet verseker dat verskillende nodusse van mekaar weet en die werkslading versigtig moet versprei.

Dit het so gelukkig geblyk dat erlang, wat ons gekies het vir sy aangename sintaksis en hype daaromheen, het 'n eersteklas ondersteuning vir verspreide stelsels. In teorie klink dit heeltemal triviaal:

Boodskap wat oorgedra word tussen prosesse op verskillende nodusse, sowel as tussen skakels en monitors, is deursigtig […]

In die praktyk is alles 'n bietjie meer ingewikkeld. Versprei erlang is ontwikkel toe "houer" 'n groot ysterboks vir verskeping beteken het, en "doker" was bloot 'n sinoniem vir langkusman. IN IP4 daar was baie onbesette adresse, netwerkonderbrekings is gewoonlik veroorsaak deur rotte wat deur die kabel kou, en die gemiddelde uptyd van die produksiestelsel is in dekades gemeet.

Nou is ons almal ongelooflik selfversorgend, verpak en hardloop versprei erlang in 'n omgewing waar dinamiese IP-adresse op die beginsel van groot ewekansigheid uitgedeel word, en nodusse kan verskyn en verdwyn op die bevlieging van die linkerhak van die skeduleerder. Om hope boilerplate-kode te vermy in elke projek wat 'n verspreide erlang, om die vyandige omgewing te bekamp, ​​word hulp benodig.

Let daarop: Ek is bewus daarvan dat daar is libcluster. Dit is regtig gaaf, dit het meer as 'n duisend sterre, die skrywer is bekend in die gemeenskap, en dit alles. As die metodes wat hierdie pakket bied om 'n groepering te skep en in stand te hou, genoeg is vir jou, is ek bly vir jou. Ongelukkig het ek baie meer nodig. Ek wil die opset in detail beheer en nie 'n buitetoeskouer in die teater van kluster-herorganisasie wees nie.

Vereistes

Wat ek persoonlik nodig gehad het, was 'n biblioteek wat die bestuur van die groep sou oorneem en die volgende eienskappe sou hê:

• deursigtige werk met beide 'n hardgekodeerde lys nodusse en dinamiese ontdekking deur dienste erlang;
• ten volle funksionele terugbel vir elke topologieverandering (knooppunt daar, nodus hier, netwerkonstabiliteit, splitsing);
• deursigtige koppelvlak vir die bekendstelling van 'n groepering met lang en kort name, soos met :nonode@nohost;
• Docker-ondersteuning uit die boks, sonder om infrastruktuurkode te hoef te skryf.

Laasgenoemde beteken dat nadat ek die toepassing plaaslik getoets het in :nonode@nohost, of in 'n kunsmatig verspreide omgewing met behulp van test_cluster_task, Ek wil net hardloop docker-compose up --scale my_app=3 en kyk hoe dit drie gevalle in docker uitvoer sonder enige kodeveranderings. Ek wil ook afhanklike toepassings hê soos mnesia - wanneer die topologie verander, herbou hulle agter die skerms die groep regstreeks sonder enige bykomende skop van die toepassing.

klooster was nie bedoel om 'n biblioteek te wees wat in staat was tot alles van die ondersteuning van 'n groep tot koffiemaak nie. Dit is nie 'n silwer koeël wat daarop gemik is om alle moontlike gevalle te dek, of 'n akademies volledige oplossing te wees in die sin dat teoretici van CS in hierdie termyn geplaas word. Hierdie biblioteek is ontwerp om 'n baie duidelike doel te dien, maar doen sy nie te groot werk perfek nie. Hierdie doelwit sal wees om volledige deursigtigheid tussen die plaaslike ontwikkelingsomgewing en 'n verspreide elastiese omgewing vol vyandige houers te verskaf.

Gekose benadering

klooster is bedoel om as 'n toepassing uitgevoer te word, alhoewel gevorderde gebruikers met die samestelling en instandhouding van die groep handmatig kan werk deur direk te hardloop Cloister.Manager in die teikentoepassing se toesighouerboom.

Wanneer dit as 'n toepassing uitgevoer word, maak die biblioteek staat op config, waaruit dit die volgende basiese waardes lees:

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

Die parameters hierbo beteken letterlik die volgende: klooster gebruik vir OTP-toepassing :my_app, gebruik erlang diens ontdekking om nodusse te verbind, ten minste drie, en MyApp.Listener module (implementering @behaviour Cloister.Listener) is opgestel om kennisgewings oor topologieveranderinge te ontvang. 'n Gedetailleerde beskrywing van die volledige konfigurasie kan gevind word in dokumentasie.

Met hierdie opset, die toepassing klooster sal in fases bekendgestel word, vertraag die proses om die hooftoepassing te begin totdat konsensus bereik word (drie nodusse is verbind en verbind, soos in die voorbeeld hierbo.) Dit gee die hooftoepassing die geleentheid om te aanvaar dat wanneer dit begin, die groepering reeds beskikbaar is. Wanneer die topologie verander (daar sal baie van hulle wees, omdat die nodusse nie heeltemal sinchronies begin nie), sal die hanteerder geroep word MyApp.Listener.on_state_change/2. Meeste van die tyd voer ons 'n aksie uit wanneer ons 'n statusboodskap ontvang %Cloister.Monitor{status: :up}, wat beteken: "Hallo, die groep is saamgestel."

In die meeste gevalle, installasie consensus: 3 is optimaal, want selfs as ons verwag dat meer nodusse sal verbind, sal die terugbel deurgaan status: :rehashing → status: :up op enige nuut bygevoegde of verwyderde nodus.

As u in ontwikkelingsmodus begin, hoef u net te stel consensus: 1 и klooster sal met graagte die wag vir trossamestelling oorslaan wanneer hy sien :nonode@nohostOf :node@hostOf :[email protected] - afhangende van hoe die nodus opgestel is (:none | :shortnames | :longnames).

Verspreide toepassingsbestuur

Verspreide toepassings wat nie in 'n vakuum is nie, sluit gewoonlik verspreide afhanklikhede in, soos mnesia. Dit is maklik vir ons om hul herkonfigurasie te hanteer vanaf dieselfde terugbel on_state_change/2. Hier is byvoorbeeld 'n gedetailleerde beskrywing van hoe om te herkonfigureer mnesia aan die vlieg in dokumentasie klooster.

Die grootste voordeel van die gebruik klooster is dat dit al die nodige bewerkings uitvoer om die groep te herbou na 'n topologieverandering onder die enjinkap. Die toepassing loop eenvoudig in 'n reeds voorbereide verspreide omgewing, met alle nodusse gekoppel, ongeag of ons die IP-adresse en dus die nodusname vooraf ken, of hulle is dinamies toegewys/verander. Dit vereis absoluut geen spesiale docker-konfigurasie-instellings nie en vanuit 'n toepassingsontwikkelaar se oogpunt is daar geen verskil tussen hardloop in 'n verspreide omgewing of hardloop in 'n plaaslike een nie. :nonode@nohost. Jy kan meer hieroor lees in dokumentasie.

Alhoewel komplekse hantering van topologieveranderinge moontlik is deur 'n pasgemaakte implementering MyApp.Listener, kan daar altyd randgevalle wees waar hierdie biblioteekbeperkings en konfigurasievooroordele die hoekstene van implementering blyk te wees. Dit is reg, neem net die bogenoemde libcluster, wat meer algemeen-doel is, of hanteer selfs die lae-vlak cluster self. Die doel van hierdie kodebiblioteek is nie om elke moontlike scenario te dek nie, maar om die mees algemene scenario te gebruik sonder onnodige pyn en omslagtige copy-paste.

Let wel: op hierdie punt in die oorspronklike was daar die frase "Happy clustering!", en Yandex, waarmee ek vertaal (ek hoef nie self deur woordeboeke te gaan nie), het my die opsie "Happy clustering!" gebied! Dit is miskien onmoontlik om 'n beter vertaling voor te stel, veral in die lig van die huidige geopolitieke situasie.

Bron: will.com