Halos lahat ng matagumpay na aplikasyon sa negosyo ay maaga o huli ay pumapasok sa isang yugto kung saan kinakailangan ang pahalang na pag-scale. Sa maraming kaso, maaari ka lang magsimula ng bagong instance at bawasan ang average ng load. Ngunit mayroon ding mas kaunting mga kaso kung saan kailangan nating tiyakin na alam ng iba't ibang mga node ang tungkol sa isa't isa at maingat na ipamahagi ang workload.
Napakaswerte pala niyan si erlang, na pinili namin para sa kaaya-ayang syntax at hype sa paligid nito, ay may unang klase . Sa teorya, ito ay tila walang halaga:
Ang pagpasa ng mensahe sa pagitan ng mga proseso sa iba't ibang mga node, pati na rin sa pagitan ng mga link at monitor, ay transparent [β¦]
Sa pagsasagawa, ang lahat ay medyo mas kumplikado. Naipamahagi si erlang ay binuo noong ang "container" ay nangangahulugang isang malaking bakal na kahon para sa pagpapadala, at ang "docker" ay isang kasingkahulugan lamang para sa longshoreman. SA IP4 mayroong maraming mga address na walang tao, ang network break ay kadalasang sanhi ng mga daga na ngumunguya sa cable, at ang average na uptime ng production system ay sinusukat sa mga dekada.
Ngayon lahat tayo ay hindi kapani-paniwalang sapat sa sarili, nakabalot, at tumatakbong ipinamahagi si erlang sa isang kapaligiran kung saan ang mga dynamic na IP address ay ibinibigay sa prinsipyo ng mahusay na randomness, at ang mga node ay maaaring lumitaw at mawala sa kapritso ng kaliwang takong ng scheduler. Upang maiwasan ang mga tambak ng boilerplate code sa bawat proyekto na nagpapatakbo ng isang ipinamamahagi si erlang, upang labanan ang pagalit na kapaligiran, kailangan ang tulong.
Nota: Alam kong meron . Ito ay talagang astig, ito ay may higit sa isang libong bituin, ang may-akda ay sikat sa komunidad, at lahat ng iyon. Kung ang mga pamamaraan na inaalok ng package na ito para sa paglikha at pagpapanatili ng isang cluster ay sapat na para sa iyo, masaya ako para sa iyo. Sa kasamaang palad, kailangan ko ng higit pa. Gusto kong kontrolin ang setup nang detalyado at hindi maging isang tagapanood sa labas sa teatro ng muling pagsasaayos ng kumpol.
Kinakailangan sa
Ang personal kong kailangan ay isang silid-aklatan na kukuha sa pamamahala ng kumpol at magkakaroon ng mga sumusunod na katangian:
- transparent na trabaho na may parehong hard-coded na listahan ng mga node at dynamic na pagtuklas sa pamamagitan ng mga serbisyo si erlang;
- fully functional callback para sa bawat pagbabago ng topology (node ββdoon, node dito, network instability, splits);
- transparent na interface para sa paglulunsad ng isang kumpol na may mahaba at maiikling pangalan, tulad ng sa
:nonode@nohost; - Suporta ng Docker sa labas ng kahon, nang hindi kinakailangang magsulat ng code ng imprastraktura.
Nangangahulugan ang huli na pagkatapos kong subukan ang application nang lokal sa :nonode@nohost, o sa isang artipisyal na ipinamahagi na kapaligiran gamit ang , gusto ko lang tumakbo docker-compose up --scale my_app=3 at tingnan kung paano ito nagpapatupad ng tatlong pagkakataon sa docker nang walang anumang pagbabago sa code. Gusto ko rin ng mga dependent application tulad ng mnesia - kapag nagbago ang topology, sa likod ng mga eksena ay muling binuo nila ang cluster nang live nang walang anumang karagdagang sipa mula sa application.
Cloister ay hindi nilayon na maging isang aklatan na may kakayahan sa lahat mula sa pagsuporta sa isang kumpol hanggang sa paggawa ng kape. Ito ay hindi isang pilak na bala na naglalayong masakop ang lahat ng posibleng mga kaso, o maging isang kumpletong solusyon sa akademya sa kahulugan na ang mga teorista mula sa CS ilagay sa terminong ito. Idinisenyo ang library na ito upang maghatid ng napakalinaw na layunin, ngunit gawin ang hindi masyadong malaking trabaho nito nang perpekto. Ang layuning ito ay upang magbigay ng kumpletong transparency sa pagitan ng lokal na kapaligiran sa pag-unlad at isang distributed na elastic na kapaligiran na puno ng masasamang lalagyan.
Pinili na diskarte
Cloister ay nilayon na patakbuhin bilang isang application, bagama't ang mga advanced na user ay maaaring gumana sa pagpupulong at pagpapanatili ng cluster nang manu-mano sa pamamagitan ng direktang pagtakbo Cloister.Manager sa puno ng superbisor ng target na aplikasyon.
Kapag tumakbo bilang isang application, umaasa ang library config, kung saan binabasa nito ang mga sumusunod na pangunahing halaga:
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 changedAng mga parameter sa itaas ay literal na nangangahulugang ang sumusunod: Cloister ginagamit para sa OTP application :my_app, gamit erlang service discovery upang ikonekta ang mga node, hindi bababa sa tatlo, at MyApp.Listener module (pagpapatupad ) ay naka-configure upang makatanggap ng mga abiso tungkol sa mga pagbabago sa topology. Ang isang detalyadong paglalarawan ng kumpletong pagsasaayos ay matatagpuan sa .
Gamit ang pagsasaayos na ito, ang application Cloister kalooban , inaantala ang proseso ng pagsisimula ng pangunahing aplikasyon hanggang sa maabot ang pinagkasunduan (tatlong node ang konektado at konektado, tulad ng halimbawa sa itaas.) Nagbibigay ito ng pagkakataon sa pangunahing aplikasyon na ipagpalagay na kapag nagsimula ito, magagamit na ang cluster. Sa tuwing nagbabago ang topology (magkakaroon ng marami sa kanila, dahil ang mga node ay hindi ganap na nagsisimulang magkasabay), ang handler ay tatawagin . Kadalasan, nagsasagawa kami ng pagkilos kapag nakatanggap kami ng status message %Cloister.Monitor{status: :up}, na nangangahulugang: "Kumusta, ang kumpol ay naka-assemble."
Sa karamihan ng mga kaso, pag-install consensus: 3 ay pinakamainam dahil kahit na inaasahan namin ang higit pang mga node na kumonekta, ang callback ay magpapatuloy status: :rehashing β status: :up sa anumang bagong idinagdag o tinanggal na node.
Kapag nagsimula sa mode ng pag-unlad, kailangan mo lamang itakda consensus: 1 ΠΈ Cloister ay masayang laktawan ang paghihintay para sa cluster assembly kapag nakita niya :nonode@nohostO :node@hostO :[email protected] - depende sa kung paano na-configure ang node (:none | :shortnames | :longnames).
Pamamahala ng Ibinahagi na Application
Ang mga ibinahagi na application na wala sa isang vacuum ay kadalasang may kasamang mga ibinahagi na dependency, gaya ng mnesia. Madali para sa amin na pangasiwaan ang kanilang muling pagsasaayos mula sa parehong callback on_state_change/2. Narito, halimbawa, ang isang detalyadong paglalarawan kung paano muling i-configure mnesia sa mabilisang papasok .
Ang pangunahing bentahe ng paggamit Cloister ay ginagawa nito ang lahat ng kinakailangang operasyon upang muling itayo ang cluster pagkatapos ng pagbabago sa topology sa ilalim ng hood. Ang application ay tumatakbo lamang sa isang nakahandang distributed na kapaligiran, kasama ang lahat ng mga node na konektado, hindi alintana kung alam natin ang mga IP address at samakatuwid ang mga pangalan ng node nang maaga, o sila ay dynamic na itinalaga/binago. Ito ay ganap na hindi nangangailangan ng mga espesyal na setting ng pagsasaayos ng docker at mula sa pananaw ng isang developer ng application, walang pagkakaiba sa pagitan ng pagtakbo sa isang distributed na kapaligiran o pagtakbo sa isang lokal. :nonode@nohost. Maaari mong basahin ang higit pa tungkol dito sa .
Bagama't ang kumplikadong paghawak ng mga pagbabago sa topology ay posible sa pamamagitan ng isang pasadyang pagpapatupad MyApp.Listener, maaaring palaging may mga gilid na kaso kung saan ang mga limitasyon sa library at mga bias sa pagsasaayos ay nagpapatunay na ang mga pundasyon ng pagpapatupad. Ok lang, kunin mo lang yung nasa itaas libcluster, na mas pangkalahatang layunin, o kahit na ikaw mismo ang humawak sa mababang antas na cluster. Ang layunin ng library ng code na ito ay hindi upang masakop ang bawat posibleng senaryo, ngunit gamitin ang pinakakaraniwang senaryo nang walang hindi kinakailangang sakit at masalimuot na copy-paste.
Tandaan: sa puntong ito sa orihinal ay mayroong pariralang "Maligayang pag-cluster!", at ang Yandex, kung saan ako nagsasalin (hindi ko na kailangang dumaan sa mga diksyunaryo mismo), ay nag-alok sa akin ng opsyon na "Maligayang pag-cluster!" Imposibleng isipin ang isang mas mahusay na pagsasalin, lalo na sa liwanag ng kasalukuyang geopolitical na sitwasyon.
Pinagmulan: www.habr.com