Ia negozio-aplikazio arrakastatsu guztiak lehenago edo beranduago eskala horizontala behar den fase batean sartzen dira. Kasu askotan, instantzia berri bat abiarazi eta kargaren batez bestekoa murriztu dezakezu. Baina kasu ez hain hutsalak ere badaude, non nodo ezberdinek elkarren berri dutela eta lan-karga arreta handiz banatzen dutela ziurtatu behar dugun.
Zorte handia izan zen erlang, bere inguruan sintaxi atseginagatik eta hypegatik aukeratu genuena, lehen mailakoa du . Teorian, hau guztiz hutsala dirudi:
Nodo ezberdinetako prozesuen artean, baita esteken eta monitoreen artean ere, mezuak gardenak dira [...]
Praktikan, dena apur bat konplikatuagoa da. Banatu erlang "container" bidalketa egiteko burdinazko kutxa handi bat esan nahi zuenean garatu zen, eta "docker" longshoreman-en sinonimoa besterik ez zen. IN IP4 erabili gabeko helbide asko zeuden, sarearen etenaldiak normalean arratoiak kableen bidez murtxikatzen zituzten eta ekoizpen-sistema baten batez besteko denbora hamarkadetan neurtzen zen.
Orain denok gara izugarri autosufizienteak, paketatuta eta banatuta martxan erlang IP helbide dinamikoak ausazkotasun handiaren printzipioaren arabera banatzen diren ingurune batean, eta programatzailearen ezker orpoaren kapritxoaren arabera nodoak agertu eta desager daitezke. Banatu bat exekutatzen ari den proiektu guztietan boilerplate kode pila saihesteko erlang, ingurune etsaiari aurre egiteko, laguntza behar da.
Kontuan izan: Badakit badagoela . Oso polita da, mila izar baino gehiago ditu, egilea famatua da komunitatean, eta hori guztia. Pakete honek kluster bat sortzeko eta mantentzeko eskaintzen dituen metodoak nahikoak bazaizkizu, pozik nago zuregatik. Zoritxarrez, askoz gehiago behar dut. Konfigurazioa zehatz-mehatz kontrolatu nahi dut eta ez izan kanpoko ikusle bat klusterren berrantolaketaren antzokian.
Baldintzak
Pertsonalki behar nuen liburutegi bat zen klusterraren kudeaketa bere gain hartuko zuena eta propietate hauek izango zituena:
- lan gardena nodoen zerrenda gogor batekin eta zerbitzuen bidez aurkikuntza dinamikoarekin erlang;
- Topologia aldaketa bakoitzerako deia guztiz funtzionala (nodoa han, nodoa hemen, sarearen ezegonkortasuna, zatiketak);
- interfaze gardena izen luzeak eta laburrak dituen cluster bat abiarazteko, hala nola
:nonode@nohost; - Docker-en laguntza kutxatik kanpo, azpiegitura kodea idatzi beharrik gabe.
Azken honek esan nahi du aplikazioa lokalean probatu ondoren :nonode@nohost, edo artifizialki banatutako ingurune batean erabiliz , korrika egin nahi dut docker-compose up --scale my_app=3 eta ikusi nola exekutatzen dituen hiru instantzia docker-en inolako kode aldaketarik gabe. Menpeko aplikazioak ere nahi ditut mnesia - Topologia aldatzen denean, eszenaren atzean klusterra zuzenean berreraikitzen dute aplikazioaren jaurtiketa gehigarririk gabe.
Klaustroa ez zen liburutegi bat izan nahi, kluster bati eusteko eta kafea prestatzeko gai dena egiteko. Ez da kasu posible guztiak estaltzea helburu duen zilarrezko bala, edo akademikoki konponbide osoa izatea, teorialariek duten zentzuan. CS termino honetan jarri. Liburutegi hau oso helburu argi bat betetzeko diseinatuta dago, baina bere lan ez oso handia primeran egiten du. Helburu hori izango da erabateko gardentasuna eskaintzea tokiko garapen-ingurunearen eta etsai-edukiontziz betetako ingurune elastiko banatu baten artean.
Aukeratutako planteamendua
Klaustroa aplikazio gisa exekutatu nahi da, nahiz eta erabiltzaile aurreratuek klusterraren muntaketa eta mantentze-lanak eskuz lan egin dezaketen zuzenean exekutatuz. Cloister.Manager xede aplikazioaren gainbegiratzaileen zuhaitzean.
Aplikazio gisa exekutatzen denean, liburutegia oinarritzen da config, eta bertatik honako oinarrizko balio hauek irakurtzen ditu:
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 changedGoiko parametroek literalki honako hau esan nahi dute: Klaustroa OTP aplikaziorako erabiltzen da :my_app, erabilerak Erlang zerbitzuaren aurkikuntza nodoak konektatzeko, hiru gutxienez, eta MyApp.Listener modulua (inplementazioa ) topologia aldaketei buruzko jakinarazpenak jasotzeko konfiguratuta dago. Konfigurazio osoaren deskribapen zehatza hemen aurki daiteke .
Konfigurazio honekin, aplikazioa Klaustroa izango da , aplikazio nagusia abiarazteko prozesua atzeratuz adostasuna lortu arte (hiru nodo konektatuta eta konektatzen dira, goiko adibidean bezala). Honek aukera ematen dio aplikazio nagusiari abiaraztean klusterra dagoeneko erabilgarri dagoela pentsatzeko. Topologia aldatzen den bakoitzean (asko izango dira, nodoak ez direlako guztiz sinkronoki hasten), kudeatzailea deituko da. . Gehienetan egoera mezu bat jasotzen dugunean ekintza bat egiten dugu %Cloister.Monitor{status: :up}, hau da: "Kaixo, multzoa muntatuta dago".
Kasu gehienetan, instalazioa consensus: 3 optimoa da, nodo gehiago konektatzea espero badugu ere, deiaren itzulera igaroko delako status: :rehashing → status: :up gehitu edo kendu berri den edozein nodotan.
Garapen moduan hastean, ezarri besterik ez duzu behar consensus: 1 и Klaustroa kluster muntatzeko itxaronaldia pozik saltatuko du ikusten duenean :nonode@nohostEdo :node@hostEdo :node@host.domain - nodoa nola konfiguratu zen arabera (:none | :shortnames | :longnames).
Banatutako aplikazioen kudeaketa
Hutsean ez dauden aplikazio banatuek normalean mendekotasun banatuak izaten dituzte, esaterako mnesia. Guretzat erraza da haien birkonfigurazioa dei berretik kudeatzea on_state_change/2. Hona hemen, adibidez, birkonfiguratu deskribapen zehatza mnesia sartu hegan .
Erabiltzearen abantaila nagusia Klaustroa da topologia-aldaketa baten ondoren cluster-a berreraikitzeko beharrezko eragiketa guztiak egiten dituela kanpaiaren azpian. Aplikazioa jada prestatuta dagoen ingurune banatu batean exekutatzen da, nodo guztiak konektatuta daudela, IP helbideak eta, beraz, nodoen izenak aldez aurretik ezagutzen ditugun ala ez, edo dinamikoki esleitu/aldatu diren kontuan hartu gabe. Honek ez du docker konfigurazio ezarpen berezirik behar eta aplikazioen garatzaileen ikuspuntutik, ez dago alderik ingurune banatu batean exekutatzeko edo tokiko batean exekutatzeko. :nonode@nohost. Honi buruz gehiago irakur dezakezu .
Topologia aldaketen kudeaketa konplexua inplementazio pertsonalizatu baten bidez posible bada ere MyApp.Listener, beti egon daitezke liburutegi-muga eta konfigurazio-alborapen horiek inplementazioaren oinarriak direla ertz-kasuak. Ongi dago, hartu goikoa libcluster, helburu orokorragoa dena, edo baita maila baxuko klusterra zuk zeuk kudeatu. Kode liburutegi honen helburua ez da agertoki posible guztiak estaltzea, agertokirik ohikoena erabiltzea alferrikako min eta kopiatu-itsatsi astuna gabe baizik.
Oharra: Jatorrizko puntu honetan "Happy clustering!" esaldia zegoen, eta Yandexek, horrekin itzultzen dudan (ez dut hiztegietatik pasatu beharrik), "Happy clustering!" aukera eskaini zidan. Agian ezinezkoa da itzulpen hoberik imajinatzea, batez ere egungo egoera geopolitikoa ikusita.
Iturria: www.habr.com
