Cloister → lihtne OTP klastrihaldus

Peaaegu iga eduka äritarkvara rakendus satub varem või hiljem faasi, kus on vajalik horisontaalne skaleerimine. Paljudes juhtudel piisab lihtsalt uue eksemplari käivitamisest ja keskmise koormuse vähendamisest. Kuid on ka vähem triviaalsetele juhtumeid, kus peame tagama, et erinevad sõlmed teaksid üksteisest ja jagaksid koormust hoolikalt.

Õnnestus, et erlang, mille valisime meeldiva süntaksi ja hype'i tõttu, pakub esmaklassilist toetust jaotatud süsteemidele. Teoorias kõlab see tegelikult triviaalsetena:

Sõnumite edastamine erinevate sõlmede protsesside vahel, samuti viidete ja monitoride vahel on läbipaistev […]

Praktiliselt on kõik natuke keerulisem. Jaotatud erlang arendati siis, kui „konteiner” tähendas nii suurt metallkast, mida kasutati transpordiks, ja „dokk” oli lihtsalt sõna sadama töötaja tähistamiseks. Ajal, mil IP4 oli palju vabu aadresse, olid võrgu katkestamiseks tavaliselt süüdlased närilised, kes olid kaableid läbi hammustanud, ja keskmine töökindluse aeg tootmissüsteemis mõõdeti aastakümnetes.

Nüüd oleme kõik uskumatult isemajandavad, pakitud ja käivitame jaotatud erlang keskkonnas, kus dünaamilisi IP-aadresse jagatakse suure juhuslikkuse põhimõttel ja sõlmed võivad ilmuda ja kaduda vastavalt planeerija soovile. Et vältida igas projektis, mis käivitab jaotatud erlang, peame me abistama vaenulikus keskkonnas.

Märkus: olen teadlik, et on olemas libcluster. See on tõesti vinge, sellel on üle tuhande tähe, autor on tuntud kogukonnas ja kõik see. Kui teile piisab sellest pakendist pakutud klastrite loomise ja haldamise viisidest — olen teie üle rõõmus. Kahjuks on mul vaja palju enam. Ma tahan hallata seadistust detailideni ja mitte olla kõrvaltvaataja klastrihalduse teatrisse.

Nõuded

Mida ma isiklikult vajas, oli teek, mis võtab enda peale klastrihalduse ja omab järgmisi omadusi:

• läbipaistev töö nii kõvasti kodeeritud sõlmede loendiga kui ka dünaamilise tuvastamise kaudu teenustest erlang;
• täisfunktsionaalne tagasiside iga topoloogiamuutuse korral (sõlm siia, sõlm sinna, võrgu ebastabiilsus, lõhed);
• läbipaistev liides klastrite käivitamiseks pikkade ja lühikeste nimedega, nagu ka :nonode@nohost;
• Dockeri tugi kohe olemas, ilma vajaduseta kirjutada infrastruktuuri koodi.

See tähendab, et pärast rakenduse testimist kohalikult :nonode@nohost, või kunstlikult jaotatud keskkonnas abiga test_cluster_task, tahan lihtsalt käivitada docker-compose up --scale my_app=3 ja näha, kuidas see täidab kolme eksemplari Dockeris ilma koodimuudatusteta. Samuti tahan, et sõltuvad rakendused, näiteks mnesia — kui topoloogia muutub, ehitataks klastrit tagasi ilma rakenduse vajaduseta täiendava „käepigistuse” järele.

Cloister ei olnud mõeldud raamatukoguna, mis suudab kõike: klastrite toimest kohvi valmistamiseni. See ei ole hõbedane kuul, mis püüab katta kõik võimalikud juhtumid, ega ole akadeemiliselt täielik lahendus selles mõttes, nagu teoreetikud CS investeerivad sellesse terminisse. See raamatukogu on loodud väga selgelt määratletud eesmärgi saavutamiseks, et täita oma mitte eriti suurt töömahtu ideaalselt. See eesmärk on tagada täielik läbipaistvus kohaliku arenduskeskkonna ja jaotatud paindliku keskkonna vahel, mis on täis vaenulikke konteinerid.

Valitud lähenemine

Cloister on mõeldud rakenduse käitamiseks, kuid kogenud kasutajad võivad klastrit käsitsi hallata ja hooldada (assembly and maintenance), käivitades selle otse Cloister.Manager sihtrakenduse superviisorite puus.

Rakenduse käivitamisel toetub raamatukogu edasi konsolideerimiseks ja aggregeerimiseks., kust loetakse järgmised peamised väärtused:

config :cloister,
  otp_app: :my_app,
  sentry: :"cloister.local", # või ~w|n1@foo n2@bar|a
  consensus: 3,              # sõlmede arv, mida arvestada
                             #    klaster on üles
  listener: MyApp.Listener   # kuulaja, mida kutsutakse, kui
                             #    ring on muutunud

Ülaltoodud parameetrid tähendavad laias laastus järgmist: Cloister kasutatakse OTP rakenduse jaoks :my_app, kasutab erlang teenuse avastamine sõlmede ühendamiseks, vähemalt kolm, ja MyApp.Listener moodul (realiseerib @behaviour Cloister.Listener) on seadistama teavitama topoloogiamuudatustest. Üksikasjalik teave täieliku konfiguratsiooni kohta on saadaval dokumentatsioonis.

Sellise konfiguratsiooni korral rakendus Cloister rakendatakse käivitub järk-järgult, lükates peamise rakenduse käivitamise protsessi edasi konsensuse saavutamiseni (kolm sõlme on ühendatud ja seotud, nagu eespool näidatud). See võimaldab peamisel rakendusel eeldada, et klaster on käivitumise hetkeks juba saadaval. Iga topoloogiamuutusega (neid tuleb palju, kuna sõlmed ei käivitu täiesti sünkroonselt) kutsub välja töötleja MyApp.Listener.on_state_change/2. Enamasti täidame toimingu, kui saame sõnumi olekuga %Cloister.Monitor{status: :up}, mis tähendab: „Hei, klaster on kokku pandud“.

Enamasti on seadistamine consensus: 3 optimaalne, sest isegi kui me ootame, et ühendatakse rohkem sõlmi, läbib tagasikutsumine läbi status: :rehashing → status: :up iga uue lisatud või eemaldatud sõlme korral.

Kujundusrežiimis piisab lihtsalt seadistamisest consensus: 1 ja Cloister kui rõõmsalt mööduvad ootes töötlemise hetkest, nähes :nonode@nohost, või :node@host, või :node@host.domain — sõltuvalt sellest, kuidas sõlm on seadistatud (:none | :shortnames | :longnames).

Jaotatud rakenduste haldamine

Jaotatud rakendused ei eksisteeri vaakumis, tavaliselt sisaldavad need ka jaotatud sõltuvusi, nagu mnesia. Meil on lihtne hallata nende ümberkonfigureerimist sama tagasikutsumise kaudu on_state_change/2. Siin on näiteks üksikasjalik kirjeldus, kuidas seadistada mnesia režiimis dokumentatsioonis Cloister.

Peamine eelis, millega Cloister on see, et see teostab kõik vajalikud klastriehituse operatsioonid peale topoloogia muutmist kapoti all. Rakendus käivitatakse lihtsalt juba ettevalmistatud jaotatud keskkonnas, kõigi ühendatud sõlmedega, olenemata sellest, kas me teame eelnevalt IP-aadresse ja seega ka sõlmede nimesid või on need dünaamiliselt määratud/muudetud. See ei nõua erilisi konfigureerimiseseadeid dockeris ja rakenduste arendaja seisukohalt ei ole mingit erinevust jaotatud keskkonnas või lokaalses keskkonnas käivitamisel :nonode@nohost. Üksikasjalikku teavet leiate dokumentatsioonis.

Kuigi keeruline topoloogia muutmine on võimalik läbi oma rakenduse elluviimise MyApp.Listener, alati võivad olla piirjuhtumid, kus nende teegi piirangud ja kallutatud lähenemine konfigureerimisele osutuvad takistuseks juurutamisel. See on okei, lihtsalt võtke eelmainitud. libcluster, mis on universaalsem, või isegi töötlege madala taseme klastrit ise. Selle kooditeegi eesmärk ei ole katab kõiki võimalikke stsenaariume, vaid kasutada kõige levinumat stsenaariumi ilma tarbetu valu ja mahukate kopeerimise ja kleepimisega.

Märkus: selle koha peal originaalis oli fraas «Happy clustering!», ja Yandex, kellelt ma tõlgin (ei viitsi ju sõnaraamatutesse kaevata), pakkus mulle variandi «Sõbralik klasterdamine!». Paremat tõlget, eriti arvestades praegust geopolitiilist olukorda, on raske ette kujutada.

Allikas: habr.com