Klooster → lihtne OTP-klastri haldamine

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.

Klooster → lihtne OTP-klastri haldamine

See osutus nii õnnelikuks saadud, mille valisime selle meeldiva süntaksi ja selle ümber oleva hype tõttu, on esmaklassiline hajutatud süsteemide tugi. Teoreetiliselt kõlab see täiesti triviaalselt:

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. See on tõesti lahe, sellel on üle tuhande tähe, autor on kogukonnas kuulus ja kõik muu. Kui teile piisab selle paketi pakutavatest meetoditest klastri loomiseks ja hooldamiseks, on mul teie üle hea meel. Kahjuks vajan palju rohkem. Ma tahan seadistust üksikasjalikult kontrollida ja mitte olla klastri ümberkorraldamise teatri kõrvaltvaataja.

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, ma tahan lihtsalt joosta 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) on konfigureeritud vastu võtma märguandeid topoloogiamuudatuste kohta. Täieliku konfiguratsiooni üksikasjaliku kirjelduse leiate aadressilt dokumentatsioon.

Selle konfiguratsiooniga rakendus Klooster tahe käivitada etapiviisiliselt, viivitab põhirakenduse käivitamise protsessi konsensuse saavutamiseni (kolm sõlme on ühendatud ja ühendatud, nagu ülaltoodud näites.) See annab põhirakendusele võimaluse eeldada, et selle käivitamisel on klaster juba saadaval. Kui topoloogia muutub (neid on palju, sest sõlmed ei käivitu täiesti sünkroonselt), kutsutakse töötleja MyApp.Listener.on_state_change/2. Enamasti sooritame toimingu, kui saame olekuteate %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: :rehashingstatus: :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@nohostVõi :node@hostVõ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 dokumentatsioon Klooster.

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 dokumentatsioon.

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

Lisa kommentaar