Cloister → ienfâldich OTP-klusterbehear

Hast elke suksesfolle saaklike applikaasje komt ier of letter in faze yn wêr't horizontale skaalfergrutting fereaske is. Yn in protte gefallen kinne jo gewoan in nij eksimplaar begjinne en it loadgemiddelde ferminderje. Mar der binne ek minder triviale gefallen dêr't wy moatte soargje dat ferskillende knopen witte oer inoar en soarchfâldich fersprieden de wurkdruk.

It waard sa lokkich dat krigen, dy't wy keas foar syn noflike syntaksis en hype om it, hat in earste-klasse stipe foar ferspraat systemen. Yn teory klinkt dit folslein triviaal:

Berjocht trochjaan tusken prosessen op ferskate knopen, lykas tusken keppelings en monitors, is transparant […]

Yn 'e praktyk is alles wat yngewikkelder. Ferspraat krigen waard ûntwikkele doe't "container" betsjutte in grutte izeren doaze foar skipfeart, en "doker" wie gewoan in synonym foar longshoreman. YN IP4 d'r wiene in protte net besette adressen, netwurkbreuken waarden meastentiids feroarsake troch rotten dy't troch de kabel kôgen, en de gemiddelde uptime fan it produksjesysteem waard yn tsientallen jierren mjitten.

No binne wy ​​allegear ongelooflijk selsfoarsjennend, ferpakt, en rinne ferspraat krigen yn in omjouwing dêr't dynamyske IP-adressen wurde útdield op it prinsipe fan grutte willekeurich, en knopen kinne ferskine en ferdwine op 'e wille fan' e lofter hak fan 'e planner. Om foar te kommen peallen fan boilerplate koade yn elk projekt rint in ferspraat krigen, om de fijannige omjouwing te bestriden, is help nedich.

remark: Ik bin bewust dat der is libcluster. It is echt cool, it hat mear as tûzen stjerren, de skriuwer is ferneamd yn 'e mienskip, en dat alles. As de metoaden oanbean troch dit pakket foar it meitsjen en ûnderhâlden fan in kluster genôch foar jo binne, bin ik bliid foar jo. Spitigernôch haw ik folle mear nedich. Ik wol de opset yn detail behearskje en gjin taskôger fan bûten wêze yn it teater fan klusterreorganisaasje.

easken

Wat ik persoanlik nedich wie in biblioteek dy't it behear fan it kluster soe oernimme en de folgjende eigenskippen soe hawwe:

• transparant wurk mei sawol in hurd-kodearre list fan knopen en dynamyske ûntdekking fia tsjinsten krigen;
• folslein funksjonele weromrop foar elke topologyferoaring (knooppunt dêr, knooppunt hjir, netwurkynstabiliteit, splits);
• transparante ynterface foar it lansearjen fan in kluster mei lange en koarte nammen, lykas mei :nonode@nohost;
• Docker-stipe út 'e doaze, sûnder ynfrastruktuerkoade te skriuwen.

Dat lêste betsjut dat nei't ik de applikaasje lokaal hifke yn :nonode@nohost, of yn in keunstmjittich ferspraat omjouwing mei help fan test_cluster_task, Ik wol gewoan rinne docker-compose up --scale my_app=3 en sjoch hoe't it trije eksimplaren útfiert yn docker sûnder koade feroarings. Ik wol ek ôfhinklike applikaasjes lykas mnesia - as de topology feroaret, bouwe se efter de skermen it kluster live wer op sûnder ekstra kick fan 'e applikaasje.

Kleaster wie net bedoeld om in bibleteek te wêzen dy't alles kin fan it stypjen fan in kluster oant it meitsjen fan kofje. It is gjin sulveren kûgel dy't as doel hat om alle mooglike gefallen te dekken, of in akademysk folsleine oplossing te wêzen yn 'e sin dat teoretici út CS set yn dizze term. Dizze bibleteek is ûntworpen om in heul dúdlik doel te tsjinjen, mar doch har net al te grutte baan perfekt. Dit doel sil wêze om folsleine transparânsje te leverjen tusken de pleatslike ûntwikkelingsomjouwing en in ferspraat elastyske omjouwing fol fijannige konteners.

Gekozen oanpak

Kleaster is bedoeld om te rinnen as in applikaasje, hoewol avansearre brûkers kinne wurkje mei assemblage en ûnderhâld fan it kluster mei de hân troch direkt te rinnen Cloister.Manager yn de tafersjochbeam fan 'e doelapplikaasje.

Wannear't rinne as in applikaasje, de bibleteek fertrout op config, wêrfan it de folgjende basiswearden lêst:

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

De boppesteande parameters betsjutte letterlik it folgjende: Kleaster brûkt foar OTP-applikaasje :my_app, brûkt erlang tsjinst ûntdekking te ferbinen knopen, op syn minst trije, en MyApp.Listener module (implementearje @behaviour Cloister.Listener) is ynsteld om notifikaasjes te ûntfangen oer topologywizigingen. In detaillearre beskriuwing fan 'e folsleine konfiguraasje is te finen yn dokumintaasje.

Mei dizze konfiguraasje, de applikaasje Kleaster sil wêze lansearring yn stadia, it fertrage fan it proses fan it starten fan 'e haadapplikaasje oant konsensus wurdt berikt (trije knopen binne ferbûn en ferbûn, lykas yn it foarbyld hjirboppe.) Dit jout de haadapplikaasje de kâns om oan te nimmen dat as it begjint, it kluster al beskikber is. Wannear't de topology feroaret (d'r sille in protte fan wêze, om't de knopen net folslein syngroan begjinne), sil de handler neamd wurde MyApp.Listener.on_state_change/2. Meastentiids fiere wy in aksje út as wy in statusberjocht ûntfange %Cloister.Monitor{status: :up}, wat betsjut: "Hallo, it kluster is gearstald."

Yn de measte gefallen, ynstallaasje consensus: 3 is optimaal, om't sels as wy ferwachtsje dat mear knooppunten ferbine, sil de weromrop trochgean status: :rehashing → status: :up op elke nij tafoege of fuortsmiten knooppunt.

As jo ​​​​begjinne yn ûntwikkelingsmodus, moatte jo gewoan ynstelle consensus: 1 и Kleaster sil lokkich skip it wachtsjen foar kluster gearkomste doe't er sjocht :nonode@nohostof :node@hostof :[email protected] - ôfhinklik fan hoe't it knooppunt is konfigureare (:none | :shortnames | :longnames).

Ferspraat Application Management

Ferdielde applikaasjes dy't net yn in fakuüm binne, omfetsje normaal ferdielde ôfhinklikens, lykas mnesia. It is foar ús maklik om har rekonfiguraasje te behanneljen fanút deselde callback on_state_change/2. Hjir is bygelyks in detaillearre beskriuwing fan hoe't jo opnij konfigurearje mnesia op flean yn dokumintaasje Kleaster.

It wichtichste foardiel fan it brûken Kleaster is dat it alle nedige operaasjes útfiert om it kluster opnij op te bouwen nei in topologyferoaring ûnder de motorkap. De applikaasje rint gewoan yn in al taret ferspraat omjouwing, mei alle knopen ferbûn, likefolle oft wy kenne de IP-adressen en dus de node nammen fan tefoaren, of se binne dynamysk tawiisd / feroare. Dit fereasket perfoarst gjin spesjale docker-konfiguraasje-ynstellingen en út it eachpunt fan in applikaasje-ûntwikkelder is d'r gjin ferskil tusken rinnen yn in ferspraat omjouwing of rinnen yn in lokale. :nonode@nohost. Jo kinne mear oer dit lêze yn dokumintaasje.

Hoewol't komplekse ôfhanneling fan topology feroarings mooglik is troch in oanpaste ymplemintaasje MyApp.Listener, D'r kinne altyd rânegefallen wêze wêr't dizze biblioteekbeheinings en konfiguraasjefoaroardielen de hoekstiennen fan ymplemintaasje blike te wêzen. It is goed, nim gewoan it boppesteande libcluster, dat is mear algemien-doel, of sels behannelje it leech-nivo kluster sels. It doel fan dizze koadebibleteek is net om alle mooglike senario's te dekken, mar it meast foarkommende senario te brûken sûnder ûnnedige pine en omslachtige copy-paste.

Tink derom: op dit punt yn it orizjineel wie d'r de sin "Happy clustering!", en Yandex, wêrmei't ik oersette (ik hoech sels net troch wurdboeken te gean), bea my de opsje "Happy clustering!" In bettere oersetting is miskien net foar te stellen, benammen yn it ljocht fan de hjoeddeiske geopolitike sitewaasje.

Boarne: www.habr.com