Cloister → preprosto upravljanje gruče OTP

Skoraj vsaka uspešna poslovna aplikacija prej ali slej preide v fazo, ko je potrebno horizontalno skaliranje. V mnogih primerih lahko preprosto zaženete nov primerek in zmanjšate povprečje obremenitve. Obstajajo pa tudi manj nepomembni primeri, ko moramo zagotoviti, da različna vozlišča poznajo drug drugega in skrbno porazdelijo delovno obremenitev.

Izkazalo se je tako posrečeno, da pridobljeno, ki smo ga izbrali zaradi prijetne sintakse in pompa okoli njega, ima prvovrsten podpora za porazdeljene sisteme. V teoriji se to sliši povsem trivialno:

Prehod sporočil med procesi na različnih vozliščih, kot tudi med povezavami in monitorji, je pregleden […]

V praksi je vse malo bolj zapleteno. Porazdeljeno pridobljeno je bil razvit, ko je "kontejner" pomenil veliko železno škatlo za pošiljanje, "docker" pa je bil preprosto sinonim za obalnega delavca. IN IP4 bilo je veliko nezasedenih naslovov, prekinitve omrežja so običajno povzročile podgane, ki so pregriznile kabel, povprečni čas delovanja produkcijskega sistema pa so merili v desetletjih.

Zdaj smo vsi neverjetno samozadostni, zapakirani in tekoče porazdeljeni pridobljeno v okolju, kjer se dinamični naslovi IP delijo po načelu velike naključnosti in se vozlišča lahko pojavijo in izginejo po volji leve pete razporejevalnika. Da bi se izognili kupom standardne kode v vsakem projektu, ki izvaja porazdeljeno pridobljeno, za boj proti sovražnemu okolju je potrebna pomoč.

Obvestilo: Zavedam se, da obstaja libcluster. Res je kul, ima več kot tisoč zvezdic, avtor je znan v skupnosti in vse to. Če so vam metode, ki jih ponuja ta paket za ustvarjanje in vzdrževanje gruče, dovolj, sem vesel za vas. Na žalost potrebujem veliko več. Želim podrobno nadzorovati nastavitev in ne biti zunanji gledalec v gledališču reorganizacije grozdov.

Zahteve

Osebno sem potreboval knjižnico, ki bi prevzela upravljanje gruče in bi imela naslednje lastnosti:

• pregledno delo tako s trdo kodiranim seznamom vozlišč kot z dinamičnim odkrivanjem prek storitev pridobljeno;
• popolnoma delujoč povratni klic za vsako spremembo topologije (vozlišče tam, vozlišče tukaj, nestabilnost omrežja, razcepi);
• pregleden vmesnik za zagon gruče z dolgimi in kratkimi imeni, kot pri :nonode@nohost;
• Podpora za Docker takoj, brez pisanja infrastrukturne kode.

Slednje pomeni, da potem, ko sem aplikacijo testiral lokalno v :nonode@nohost, ali v umetno porazdeljenem okolju z uporabo test_cluster_task, hočem samo teči docker-compose up --scale my_app=3 in si oglejte, kako izvede tri primerke v dockerju brez sprememb kode. Želim tudi odvisne aplikacije, kot je mnesia - ko se topologija spremeni, v zakulisju znova zgradijo gručo v živo brez kakršnega koli dodatnega udarca s strani aplikacije.

Samostan ni bil mišljen kot knjižnica, ki bi bila sposobna vsega, od podpore grozdu do priprave kave. To ni srebrna paleta, katere cilj je pokriti vse možne primere, ali biti akademsko popolna rešitev v smislu, ki ga teoretiki iz CS v ta izraz. Ta knjižnica je zasnovana tako, da služi zelo jasnemu namenu, vendar odlično opravi svoje ne preveč veliko delo. Ta cilj bo zagotoviti popolno preglednost med lokalnim razvojnim okoljem in porazdeljenim elastičnim okoljem, polnim sovražnih vsebnikov.

Izbran pristop

Samostan je namenjen izvajanju kot aplikacija, čeprav lahko napredni uporabniki delajo s sestavljanjem in vzdrževanjem gruče ročno z neposrednim zagonom Cloister.Manager v nadzorniškem drevesu ciljne aplikacije.

Ko se izvaja kot aplikacija, se knjižnica zanaša na config, iz katerega razbere naslednje osnovne vrednosti:

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

Zgornji parametri pomenijo dobesedno naslednje: Samostan uporablja se za aplikacijo OTP :my_app, uporablja odkrivanje storitve erlang za povezavo vozlišč, vsaj tri, in MyApp.Listener modul (izvedba @behaviour Cloister.Listener) je konfiguriran za prejemanje obvestil o spremembah topologije. Podroben opis celotne konfiguracije najdete v dokumentacijo.

S to konfiguracijo aplikacija Samostan bo zagon po stopnjah, odloži postopek zagona glavne aplikacije, dokler ni doseženo soglasje (tri vozlišča so povezana in povezana, kot v zgornjem primeru.) To daje glavni aplikaciji možnost, da domneva, da je gruča ob zagonu že na voljo. Kadarkoli se topologija spremeni (veliko jih bo, ker se vozlišča ne zaženejo popolnoma sinhrono), bo poklican upravljalnik MyApp.Listener.on_state_change/2. Večino časa izvedemo dejanje, ko prejmemo sporočilo o statusu %Cloister.Monitor{status: :up}, kar pomeni: "Pozdravljeni, grozd je sestavljen."

V večini primerov namestitev consensus: 3 je optimalen, ker tudi če pričakujemo, da se bo povezalo več vozlišč, bo povratni klic potekal status: :rehashing → status: :up na katerem koli na novo dodanem ali odstranjenem vozlišču.

Ko začnete v razvojnem načinu, morate samo nastaviti consensus: 1 и Samostan bo z veseljem preskočil čakanje na sestavljanje grozda, ko bo videl :nonode@nohostAli :node@hostAli :[email protected] - odvisno od konfiguracije vozlišča (:none | :shortnames | :longnames).

Upravljanje porazdeljenih aplikacij

Porazdeljene aplikacije, ki niso v vakuumu, običajno vključujejo porazdeljene odvisnosti, kot je npr mnesia. Za nas je enostavno obravnavati njihovo rekonfiguracijo iz istega povratnega klica on_state_change/2. Tukaj je na primer podroben opis, kako ponovno konfigurirati mnesia na hitro noter dokumentacijo Samostan.

Glavna prednost uporabe Samostan je, da izvede vse potrebne operacije za ponovno izgradnjo gruče po spremembi topologije pod pokrovom. Aplikacija preprosto teče v že pripravljenem distribuiranem okolju, pri čemer so povezana vsa vozlišča, ne glede na to, ali poznamo IP naslove in s tem imena vozlišč vnaprej ali pa so bila dinamično dodeljena/spremenjena. To ne zahteva prav nobenih posebnih konfiguracijskih nastavitev dockerja in z vidika razvijalca aplikacij ni razlike med izvajanjem v porazdeljenem okolju ali izvajanjem v lokalnem. :nonode@nohost. Več o tem si lahko preberete v dokumentacijo.

Čeprav je zapleteno ravnanje s spremembami topologije možno z izvedbo po meri MyApp.Listener, lahko vedno obstajajo robni primeri, ko se te omejitve knjižnice in konfiguracijske pristranskosti izkažejo za temelje implementacije. V redu je, samo vzemite zgoraj libcluster, ki je bolj splošnega namena, ali celo sami upravljate z nizkonivojsko gručo. Cilj te knjižnice kode ni pokriti vseh možnih scenarijev, ampak uporabiti najpogostejši scenarij brez nepotrebne bolečine in okornega kopiranja in lepljenja.

Opomba: na tej točki v izvirniku je bil stavek "Srečno gručevanje!", Yandex, s katerim prevajam (ni mi treba brskati po slovarjih), mi je ponudil možnost "Srečno gručevanje!" Boljšega prevoda si morda ni mogoče zamisliti, sploh v luči trenutne geopolitične situacije.

Vir: www.habr.com