Cloister → klusteri OTP lihtne haldamine

Peaaegu iga edukas äri rakendus satub varem või hiljem faasi, kus on vajalik horisontaalne skaleerimine. Paljusid juhtumeid saab lihtsalt uue eksemplari käivitamise kaudu vähendada keskmist koormust. Kuid esinevad ka vähem triviaalset juhtumit, kus peame tagama, et erinevad sõlmed tunneksid üksteist ja jaotaksid töökoormust hoolikalt.

Nii õnnestus, et erlang, mille me valisime meeldiva süntaksi ja hüppe tõttu, omab esmaklassilist toetust jaotatud süsteemidele. Teoorias kõlab see üldiselt triviaalne:

Sõnumite edastamine protsesside vahel erinevates sõlmedes, samuti viidete ja monitooringute vahel on läbipaistev […]

Praktiliselt on kõik veidi keerulisem. Jaotatud erlang loodi ajal, mil "konteiner" tähendas suurt metallkasti transportimiseks, ja "dokera" oli lihtsalt sadama koormajate sünonüüm. Ajal IP4 oli palju vabu aadresse, võrgukatkestustes – olid tavaliselt süüdi ratsutavad rottide, ja keskmine töökatkestusaja mõõtmine tootmisseadmes kestis aastakümneid.

Nüüd oleme kõik kujuteldavalt iseseisvad, pakitud ja käivitame jaotatud erlang keskkonnas, kus dünaamilised IP-aadressid jagatakse suure juhuslikkuse printsiibil ja sõlmed võivad ilmuda ja kaduda vastavalt plaanija vasaku jala soovile. Et vältida igas projektis šabloonkoodi kuhjumist, mis käivitab jaotatud erlang, vajame vaenuliku keskkonna vastu abi.

Märkus: Ma olen kursis, et on olemas libcluster. See on tõeliselt lahe, sellel on rohkem kui tuhat tähte, autor on tuntud kogukonnas ja kõik see. Kui teile piisab selle paketi pakutud viisidest klasteri loomise ja säilitamise osas – ma olen teie üle õnnelik. Kahjuks on mul vaja palju rohkem. Ma tahan hallata seadistusi detailides ja mitte olla kõrvaline vaataja klasteri ümberkorraldamise teatris.

Nõuded

Minu isiklikult vajalik raamatukogu on see, mis haldab klastrit ja millel on järgmised omadused:

• läbipaistev töö nii jäigalt kodeeritud sõlmede nimekirjaga kui ka dünaamilise avastamise kaudu teenuste kaudu erlang;
• täisfunktsionaalne tagasiside iga topoloogia muutuse korral (sõlm sinna, sõlm siia, võrgu ebastabiilsus, jagunemised);
• läbipaistev liides klastrite käivitamiseks pikkade ja lühikeste nimedega, nagu ka :nonode@nohost;
• Dockeri tugi sisaldub kohe, ilma vajaduseta kirjutada infrastruktuuri koodi.

See tähendab, et pärast seda, kui ma olen rakendust kohapeal testinud :nonode@nohost, või kunstlikult jaotatud keskkonnas kasutades test_cluster_task, soovin lihtsalt käivitada docker-compose up --scale my_app=3 ja näha, kuidas see käitab kolme instantsi Dockeris ilma koodimuudatusteta. Soovin ka, et sõltuvad rakendused, näiteks mnesia — kui topoloogia muutub, siis kulisside taga uuendatakse klastrit ilma täiendava tõuketa rakenduse poolt.

Cloister ei ole mõeldud kui raamatukogu, mis suudab teha kõike: klastritoetust kuni kohvi valmistamiseni. See ei ole hõbedane kuul, mis püüab katta kõiki võimalikke juhtumeid, ega olla akadeemiliselt täielik lahendus selles mõttes, mida teoreetikud CS sellesse mõistesse panustavad. See raamatukogu on mõeldud väga selge ülesande täitmiseks, kuid täidab oma mitte liiga suurt mahtu tööd ideaalselt. Selle ülesanne on tagada täielik läbipaistvus kohaliku arenduskeskkonna ja jaotatud elastse keskkonna vahel, mis on täis vaenulikke konteinerite.

Valitud lähenemine

Cloister on mõeldud käivitamiseks rakendusena, kuigi kogenud kasutajad võivad töötada klastrit käsitsi, käivitades Cloister.Manager sihtrakenduse superviisorite puus.

Rakenduse käivitamisel toetub raamatukogu failist, saadab need andmed serverisse, kust loetakse järgmised põhiväärtused:

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

Ülaltoodud parameetrid tähendavad sõna-sõnalt järgmist: Cloister kasutatakse OTP rakenduse :my_app, kasutab erlangi teenuse avastamist sõlmede ühendamiseks, vähemalt kolme, ja MyApp.Listener moodulit (mis implementeerib @behaviour Cloister.Listener) on konfigureeritud saama teateid topoloogia muutustest. Täieliku konfiguratsiooni üksikasjalikku kirjeldust leiate dokumentatsioon.

Selle konfiguratsiooniga rakendus Cloister see on käivitub järk-järgult, lükates peamise rakenduse käivitamise protsessi edasi, kuni saavutatakse kokkulepe (kolm sõlme on ühendatud ja ühendatud, nagu eespool toodi välja). See annab peamise rakenduse võimaluse eeldada, et kui see käivitub, on klaster juba saadaval. Iga topoloogia muutuse korral (neid tuleb olema palju, kuna sõlmed ei käivitu täielikult sünkroonselt) kutsutakse välja töötleja MyApp.Listener.on_state_change/2. Enamikul juhtudel teeme me toimingu, kui saame sõnumi olekuga %Cloister.Monitor{status: :up}, mis tähendab: „Tere, klaster on kokku pandud“.

Enamikul juhtudel on seadistus consensus: 3 optimaalne, kuna isegi kui ootame rohkem sõlmede ühendamist, läbib tagasiside status: :rehashing → status: :up iga uue lisatud või eemaldatud sõlmega.

Arendusrežiimis on lihtsalt piisav, kui seadistada consensus: 1 ja Cloister ja see möödub rõõmsalt klasterdamise ootusest, nähes :nonode@nohost, või :node@host, või :node@host.domain — sõltuvalt sellest, kuidas sõlme seadistati (:none | :shortnames | :longnames).

Jagatud rakenduste haldamine

Jagatud rakendused ei ole vaakumis, tavaliselt sisaldavad nad jagatud sõltuvusi, nagu mnesia. Meil on lihtne neid ümberkonfigureerida samast tagasisidest on_state_change/2. Siin on näiteks üksikasjalik juhend, kuidas ümber seadistada mnesia realtime-s dokumentatsioon Cloister.

Peamine eelis, mida pakub Cloister , on see, et see teostab kõik vajalikud klastrite tautumise operatsioonid pärast topoloogia muutmist kapoti all. Rakendus käivitub lihtsalt juba ettevalmistatud jagatud keskkonnas, kõigi ühendatud sõlmedega, sõltumata sellest, kas me teame IP-aadresse ja seetõttu sõlmede nimesid ette või on need dünaamiliselt määratud/muutunud. See ei nõua absoluutselt mingeid spetsiaalseid docker'i konfiguratsiooni seadistusi ja arendaja perspektiivist ei ole mingit vahet, kas käivitada jagatud keskkonnas või lokaalselt :nonode@nohost. Rohkem teavet selle kohta saab lugeda dokumentatsioon.

. Kuigi keeruline topoloogia muutuste töötlemine on võimalik läbi iseseisva rakenduse, võivad alati esineda äärmised juhud, kus nende raamatukogude piirangud ja kallutatud lähenemine konfiguratsioonile võivad olla takistuseks juurutamisel. See on normaalne, lihtsalt võtke eelpool mainitud MyApp.Listener, alati võivad olla piirangulised olukorrad, kus need raamatukogu piirangud ja kallutatud lähenemine konfiguratsioonile muutuvad takistuseks rakendamisel. See on täiesti normaalne, lihtsalt võtke eeltoodud libcluster, mis on universaalsem, või töötlege isegi madala taseme klastrit ise. Selle koodiraamatukogu eesmärk ei ole katta kõiki võimalikke stsenaariume, vaid kasutada kõige levinumat stsenaariumi ilma tarbetu vaevata ja mahukate kopeerimise ja kleepimisega.

Märkus: sellel kohal originaalis oli lause «Happy clustering!», ja Yandex, kellele ma tõlgin (ei hakka ju sõnaraamatutes tuhnima), pakkus mulle varianti «Sõbralik klasterdamine!». Paremat tõlget, eriti arvestades praegust geopolitiilist olukorda, on ilmselt raske ette kujutada.

Allikas: habr.com