Cloister → menaxhim të thjeshtë të klashtës OTP

Praktikisht çdo aplikacion të suksesshëm të biznesit njëherë ose një tjetër kalon në një fazë kur kërkohet shkallëzim horizontal. Në shumë raste, thjesht mund të startoni një instancë të re dhe të ulni mesataren e ngarkesës. Por ka edhe raste më pak triviale, kur duhet të sigurohemi që nodet e ndryshme të dinë për njëra-tjetrën dhe të shpërndajnë ngarkesën e punës në mënyrë të rregullt.

Më ka ndodhur t'i qëlloj erlang, që ne e zgjodhëm për sintaksën e tij të këndshme dhe bujën rreth tij, ka mbështetje të klasit të parë për sistemet e shpërndara. Në teori, kjo tingëllon tërësisht triviale:

Shkëmbimi i mesazheve ndërmjet proceseve në nodet e ndryshme, si dhe midis referencave dhe monitorëve është i qartë […]

Në praktikë, gjithçka është pak më e komplikuar. Shkëmbimi i erlang u zhvillua kur «konteiner» do të thoshte një kuti të madhe metalike për transport, dhe «dockers» ishin thjesht sinonime të ngarkuesve portualë. Në IP4 kishte shumë adresa të papërdorura, në ndarjet rrjetike — zakonisht ishin fajtorët grykës të minjve që shqyenin kabujt, dhe koha mesatare e punës së sistemit në prodhim mathej me dekada.

Tani ne jemi gjithçka të jashtëzakonshme vetë-mjaftueshëm, të paketuar, dhe ekzekutojmë një erlang në një mjedis ku adresat IP dinamike shpërndahen sipas parimit të rastit të madh, dhe nodet mund të shfaqen dhe të humbasin sipas dëshirës së këmbës së majtë të planifikuesit. Për të shmangur një grumbull kodesh standard në çdo projekt që ekzekuton një erlang, për të luftuar kundër ambientit armiqësor, kërkohet ndihmë.

Shënim: unë e di që ekziston libcluster. Ai është në të vërtetë i shkëlqyer, ka më shumë se një mijë yje, autori është i njohur në komunitet, e gjithçka tjetër. Nëse ju mjaftojnë mënyrat e ofruara nga ky paketë për të krijuar dhe mbajtur një klasht, gëzohem për ju. Mua, fatkeqësisht, më duhet shumë më shumë. Dua të kontrolloj konfigurimin në detaje dhe të mos jem një shikues nga larg në teatrin e riformatimit të klashtës.

Kërkesat

Çfarë më duhej mua personalisht ishte një bibliotekë që do të merrte përsipër menaxhimin e klashtës dhe do të kishte këto veçori:

• funksionim i qartë si me një listë të koduar të nodave, ashtu edhe me zbulim dinamik përmes shërbimeve erlang;
• callback të plotë për çdo ndryshim në topologji (nodi këtu, nodi aty, paqëndrueshmëri rrjeti, ndarjet);
• ndërfaqe e qartë për të nisur një kluster me emra të gjatë dhe të shkurtër, ashtu si me :nonode@nohost;
• mbështetje Docker nga kutia, pa nevojën për të shkruar kod infrastrukturor.

Kjo do të thotë se, pasi e kam testuar aplikacionin lokal në :nonode@nohost, ose në një mjedis të shpërndarë në mënyrë artificiale me ndihmën e test_cluster_task, dua vetëm të nis docker-compose up --scale my_app=3 dhe të shoh si ekzekuton tre raste në Docker pa ndonjë ndryshim në kod. Po ashtu, dua që aplikacionet e varura, siç është mnesia — kur topologjia ndryshon, prapa skenave të rindërtohet klusteri në mënyrë të drejtpërdrejtë pa ndonjë shtysë të madhe nga aplikacioni.

Cloister nuk është menduar si një bibliotekë që mund të bëjë gjithçka: nga mbështetje për kluster deri te përgatitja e kafesë. Nuk është një plumb argjendi që synon të mbajë nën kontroll të gjitha rastet e mundshme, ose të jetë një zgjidhje akademike e plotë në kuptimin që teoricienët e CS i japin këtij termi. Kjo bibliotekë ka për qëllim të shërbejë një qëllim shumë të qartë, por të ekzekutojë punët e saj të vogla me përsosmëri. Ky qëllim do të jetë sigurimi i transparencës së plotë midis mjedisit lokal të zhvillimit dhe mjedisit të shpërndarë elastik, i mbushur me kontejnerë armiqësorë.

Qasja e zgjedhur

Cloister pritet të niset si aplikacion, megjithatë përdoruesit e përvojës mund të punojnë me ndërtimin dhe mbështetje (assembly and maintenance) të klustrit manualisht, duke nisur drejtpërdrejt Cloister.Manager në pemën e supervizorëve të aplikacionit të synuar.

Kur nise si aplikacion, biblioteka mbështetet në config, nga e cila lexon vlerat e mëposhtme kyçe:

config :cloister,
  otp_app: :my_app,
  sentry: :"cloister.local", # ose ~w|n1@foo n2@bar|a
  consensus: 3,              # numri i nyjeve për t'u marrë parasysh
                             #    klustri është aktiv
  listener: MyApp.Listener   # dëgjuesi që do të thirret kur
                             #    rrethi ka ndryshuar

Parametrat e mësipërm do të thonë në mënyrë të drejtpërdrejtë: Cloister përdoret për aplikacionin OTP :my_app, përdor zbulimin e shërbimit erlang për të lidhur nyjet, të paktën tre, dhe MyApp.Listener moduli (implementues i @behaviour Cloister.Listener) është i konfiguruar të marrë njoftime për ndryshimet e topologjisë. Një përshkrim i detajuar i konfigurimit të plotë mund të gjendet në dokumentacionin.

Me këtë konfigurim, aplikacioni Cloister do të do të nisët hap pas hapi, duke shmangetë procesin e fillimit të aplikacionit kryesor deri në arritjen e konsensusit (tri nyje të lidhura dhe të konektuar, siç është ilustruar më sipër). Kjo i jep mundësinë aplikacionit kryesor të supozojë se kur ai ka filluar, klasteri tashmë është në dispozicion. Me çdo ndryshim të topologjisë (do të ketë shumë, sepse nyjet nuk fillojnë plotësisht sinkron), do të thirret menaxheri MyApp.Listener.on_state_change/2. Në shumicën e rasteve, ne kryejmë një veprim kur marrim një mesazh me statusin %Cloister.Monitor{status: :up}, që do të thotë: "alo, klasteri është mbledhur."

Në shumicën e rasteve, vendosja consensus: 3 është optimale, sepse edhe nëse presim që më shumë nyje të lidhen, ripërgjigjja do të kalojë përmes status: :rehashing → status: :up në çdo nyje të re të shtuar ose të fshirë.

Kur nisni në modin e zhvillimit, mjafton të vendosni consensus: 1 dhe Cloister do të kalojë me gëzim pritjen e ndërtimit të klasterit, duke parë :nonode@nohost, ose :node@host, ose :node@host.domain — në varësi të mënyrës se si ishte konfiguruar nyja (:none | :shortnames | :longnames).

Menaxhimi i aplikacioneve të shpërndara

Aplikacionet e shpërndara në përgjithësi nuk janë në vakuum dhe zakonisht përfshijnë varësi të shpërndara, siç është mnesia. Na është e lehtë të përpunojmë ri-konfigurimin e tyre nga e njëjta ripërgjigjje on_state_change/2. Këtu, për shembull, një përshkrim i detajuar se si të ri-konfigurohet mnesia në flakë në dokumentacionin Cloister.

Avantazhi kryesor i përdorimit të Cloister është se ai kryen të gjitha operacionet e nevojshme për rindërtimin e klasterit pas ndryshimit të topologjisë në pjesën e brendshme. Aplikacioni thjesht niset në një mjedis të shpërndara të përgatitur tashmë, me të gjitha nyjet e lidhura, pavarësisht nëse e dimë adresën IP dhe, për rrjedhojë, emrat e nyjeve paraprakisht, ose ato ishin caktuar/d ndryshuar dinamikisht. Kjo kërkon pikërisht asnjë konfigurim të veçantë të Docker-it dhe nga pikëpamja e zhvilluesit të aplikacioneve, nuk ka asnjë dallim mes nisjes në një ambient të shpërndara ose lokal në :nonode@nohost. Për më shumë rreth kësaj mund të lexoni në dokumentacionin.

Megjithëse përpunimi kompleks i ndryshimeve të topologjisë është i mundur përmes një zbatimi të vetë, gjithmonë mund të ketë raste të kufizuara kur këto limite të bibliotekës dhe qasja e paragjykuar në konfigurim do të jenë një gur themeli në rrugën e zbatimit. Kjo është normale, thjesht merrni të përmendur më lart MyApp.Listener. libcluster, i cili është më universali, ose madje përpunoni një grup të nivelit të ulët vetë. Qëllimi i këtij libri kodi nuk është të përfshijë të gjitha skenarët e mundshëm, por të përdorë skenarin më të zakonshëm pa dhimbje të panevojshme dhe kopjim të bezdisshëm.

Vërejtje: në këtë vend në origjinal ishte fraza «Happy clustering!», dhe Yandex, për të cilin po përkthej (mos do të kërkoj në fjalorë vetë), më propozoi variantin «Shtë i lumtur grupimi!». Një përkthim më i mirë, ndoshta, veçanërisht në dritën e situatës aktuale gjeopolitike - dhe nuk mund të imagjinohet.

Burimi: habr.com