Peaaegu iga edukas ärirakendus jõuab varem või hiljem faasi, kus on vaja horisontaalset skaleerimist. Paljudel juhtudel saate lihtsalt käivitada uue eksemplari ja vähendada koormuse keskmist. Kuid on ka vähem triviaalseid juhtumeid, kus peame tagama, et erinevad sõlmed teavad üksteist ja jaotavad hoolikalt töökoormust.
See osutus nii õnnelikuks saadud, mille valisime selle meeldiva süntaksi ja selle ümber oleva hype tõttu, on esmaklassiline
Sõnumite edastamine erinevate sõlmede protsesside, samuti linkide ja monitoride vahel on läbipaistev […]
Praktikas on kõik veidi keerulisem. Levitatud saadud töötati välja, kui "konteiner" tähendas suurt raudkasti laevanduseks ja "dokk" oli lihtsalt longshoremani sünonüüm. IN IP4 asustamata aadresse oli palju, võrgukatkestusi põhjustasid tavaliselt kaablit läbi närinud rotid ning tootmissüsteemi keskmist tööaega mõõdeti aastakümnetes.
Nüüd oleme kõik uskumatult isemajandavad, pakitud ja levitatud saadud keskkonnas, kus dünaamilised IP-aadressid jagatakse välja suure juhuslikkuse põhimõttel ning sõlmed võivad tekkida ja kaduda planeerija vasaku kanna suva järgi. Et vältida hunnikute viisi standardkoodi igas projektis, mis töötab hajutatud saadud, vaenuliku keskkonna vastu võitlemiseks on abi vaja.
Märkus: Olen teadlik, et on olemas libcluster
Nõuded
Mina isiklikult vajasin raamatukogu, mis võtaks üle klastri haldamise ja millel oleks järgmised omadused:
- läbipaistev töö nii kõvakodeeritud sõlmede loendiga kui ka teenuste kaudu dünaamilise avastamisega saadud;
- täielikult funktsionaalne tagasihelistamine iga topoloogiamuudatuse jaoks (sõlm seal, sõlm siin, võrgu ebastabiilsus, lõhenemised);
- läbipaistev liides pikkade ja lühikeste nimedega klastri käivitamiseks, nagu ka
:nonode@nohost
; - Dockeri tugi karbist väljas, ilma infrastruktuuri koodi kirjutamata.
Viimane tähendab, et pärast seda, kui testisin rakendust kohapeal :nonode@nohost
, või kunstlikult hajutatud keskkonnas kasutades test_cluster_task
docker-compose up --scale my_app=3
ja vaadake, kuidas see käivitab Dockeris kolm eksemplari ilma koodi muutmata. Soovin ka selliseid sõltuvaid rakendusi mnesia
- kui topoloogia muutub, ehitavad nad kulisside taga klastri reaalajas uuesti üles ilma rakenduse lisalöögita.
Klooster ei olnud mõeldud raamatukoguks, mis oleks võimeline kõike alates klastri toetamisest kuni kohvi valmistamiseni. See ei ole hõbekuul, mille eesmärk on katta kõik võimalikud juhtumid või olla akadeemiliselt terviklik lahendus selles mõttes, et teoreetikud CS sellesse terminisse panna. See raamatukogu on loodud täitma väga selget eesmärki, kuid täidab oma mitte liiga suurt ülesannet suurepäraselt. See eesmärk on tagada täielik läbipaistvus kohaliku arenduskeskkonna ja hajutatud elastse keskkonna vahel, mis on täis vaenulikke konteinereid.
Valitud lähenemine
Klooster on ette nähtud käitamiseks rakendusena, kuigi kogenud kasutajad saavad klastri käsitsi kokkupanemise ja hooldusega töötada otse käivitades Cloister.Manager
sihtrakenduse juhendajapuus.
Rakendusena käivitamisel tugineb raamatukogu sellele config
, millest loetakse välja järgmised põhiväärtused:
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
Ülaltoodud parameetrid tähendavad sõna otseses mõttes järgmist: Klooster kasutatakse OTP rakenduse jaoks :my_app
, kasutab erlangi teenuse avastamine sõlmede ühendamiseks vähemalt kolm ja MyApp.Listener
moodul (rakendamine @behaviour Cloister.Listener
Selle konfiguratsiooniga rakendus Klooster tahe MyApp.Listener.on_state_change/2
%Cloister.Monitor{status: :up}
, mis tähendab: "Tere, klaster on kokku pandud."
Enamikul juhtudel paigaldamine consensus: 3
on optimaalne, sest isegi kui eeldame, et sõlme loob rohkem ühendust, siis tagasihelistamine toimub status: :rehashing
→ status: :up
mis tahes äsja lisatud või eemaldatud sõlmes.
Arendusrežiimis käivitamisel peate lihtsalt seadistama consensus: 1
и Klooster jätab hea meelega klastri kokkupaneku ootamise vahele, kui seda näeb :nonode@nohost
Või :node@host
Või :[email protected]
- sõltuvalt sellest, kuidas sõlm oli konfigureeritud (:none | :shortnames | :longnames
).
Hajutatud rakenduste haldus
Hajutatud rakendused, mis ei ole vaakumis, sisaldavad tavaliselt hajutatud sõltuvusi, nt mnesia
. Meil on lihtne nende ümberseadistamisega tegeleda sama tagasihelistamisega on_state_change/2
. Siin on näiteks üksikasjalik kirjeldus, kuidas ümber seadistada mnesia
lennult sisse
Kasutamise peamine eelis Klooster on see, et see teeb kõik vajalikud toimingud klastri taastamiseks pärast topoloogia muutmist kapoti all. Rakendus lihtsalt töötab juba ettevalmistatud hajutatud keskkonnas, kõik sõlmed on ühendatud, olenemata sellest, kas me teame IP-aadresse ja seega ka sõlmede nimesid ette või on need dünaamiliselt määratud/muudetud. See ei nõua absoluutselt mingeid spetsiaalseid dokkeri konfiguratsiooniseadeid ja rakenduste arendaja vaatenurgast pole vahet, kas töötada hajutatud keskkonnas või lokaalses keskkonnas. :nonode@nohost
. Selle kohta saate rohkem lugeda artiklist
Kuigi topoloogiamuudatuste keerukas käsitlemine on kohandatud rakenduse kaudu võimalik MyApp.Listener
, võib alati esineda äärejuhtumeid, kus need teegi piirangud ja konfiguratsiooni kallutatused osutuvad rakendamise nurgakivideks. Pole hullu, võtke lihtsalt ülaltoodu libcluster
, mis on üldisema otstarbega, või isegi madala taseme klastriga ise hakkama saada. Selle kooditeegi eesmärk ei ole katta kõiki võimalikke stsenaariume, vaid kasutada kõige tavalisemat stsenaariumit ilma tarbetu valu ja tülika kopeerimis-kleepimiseta.
Märkus: siinkohal oli originaalis fraas "Happy clustering!" ja Yandex, millega ma tõlgin (ma ei pea ise sõnaraamatuid läbi käima), pakkus mulle võimalust "Happy clustering!" Paremat tõlget on ehk võimatu ette kujutada, eriti praeguse geopoliitilise olukorra valguses.
Allikas: www.habr.com