Praktikisht çdo aplikacion biznesi të suksesshëm në një moment të caktuar kalon në një fazë ku kërkohet shkallëzim horizontal. Në shumë raste, mjafton të nisni një instancë të re dhe të ulni ngarkesën mesatare. Por ka edhe raste më pak banale, kur duhet të sigurohemi që node të ndryshme të dinë për njëra-tjetrën dhe të shpërndajnë ngarkesën e punës me kujdes.
Ka ndodhur që erlang, i cili u zgjodh për sintaksën e tij të këndshme dhe për bujën që e rrethon, ka mbështetje të klasit të parë . Në teori, kjo tingëllon krejtësisht banale:
ShkĂ«mbimi i mesazheve midis proceseve nĂ« node tĂ« ndryshme, si dhe midis lidhjeve dhe monitorĂ«ve, Ă«shtĂ« i dukshĂ«m [âŠ]
Në praktikë, gjërat janë paksa më të komplikuara. Sistemi i shpërndarë erlang u zhvillua kur "kontejner" nënkuptonte një kuti të madhe metalike për transport, ndërsa "docker" ishte thjesht një sinonim për ngarkuesin e portit. Në IP4 kishte shumë adresa të papërdorura, ndërsa çarjet në rrjet zakonisht shkaktoheshin nga minjtë që mërmërinin kabllot, dhe koha mesatare e disponueshmërisë së një sistemi prodhimi mathej me dekada.
Tani ne jemi krejtë të paimagjinueshëm vetëqëndrues, të paketuar, dhe duke nisur një mjedis të shpërndarë erlang në një ambient ku IP-të dinamike shpërndahen sipas parimit të rastit të madh, dhe nyjat mund të shfaqen dhe zhduken sipas dëshirës së majtë të planifikuesit. Për të shmangur një përmbytje kodesh standard në çdo projekt që nis një erlang, për t'u përballur me një ambient armiqësor, kërkohet ndihma.
ShĂ«nim: e di qĂ« ekziston . ĂshtĂ« vĂ«rtet e madhe, ka mĂ« shumĂ« se njĂ« mijĂ« yje, autori Ă«shtĂ« i njohur nĂ« komunitet, dhe gjithçka tjetĂ«r. NĂ«se ju mjafton mĂ«nyrat qĂ« ofron ky paketĂ« pĂ«r ndĂ«rtimin dhe mbĂ«shtetje tĂ« njĂ« klasteri â unĂ« gĂ«zohem pĂ«r ju. Mua, fatkeqĂ«sisht, mĂ« nevojitet shumĂ« mĂ« tepĂ«r. Dua tĂ« menaxhoj konfigurimin nĂ« detaje dhe tĂ« mos jem njĂ« vĂ«zhgues i huaj nĂ« teatrin e riorganizimit tĂ« klasterit.
KĂ«rkesat
Ajo që më nevojitej personalisht ishte një bibliotekë që do të merrte përsipër menaxhimin e klasterit dhe do të kishte këto karakteristika:
- funksionimi transparent si me një listë nyjesh të koduar fort, ashtu edhe me zbulim dinamik përmes shërbimeve erlang;
- callback funksional në çdo ndryshim të topologjisë (nyje këtu, nyje atje, paqartësi në rrjet, shpërthime);
- ndërfaqe e qartë për të nisur një klasër me emra të gjatë e të shkurtër, ashtu si me
:nonode@nohost; - mbështetje për Docker "out of the box", pa nevojën për të shkruar kod infrastrukture.
Kjo do tĂ« thotĂ« se, pasi e testova aplikacionin lokalisht nĂ« :nonode@nohost, ose nĂ« njĂ« mjedis tĂ« artifikuar tĂ« shpĂ«rndarĂ« me ndihmĂ«n e , dua tĂ« thjesht filloj docker-compose up --scale my_app=3 dhe tĂ« shoh si funksionon me tre instanca nĂ« Docker pa asnjĂ« ndryshim nĂ« kod. UnĂ« gjithashtu dua qĂ« aplikacionet e varura, si p.sh. mnesia â kur topologjia ndryshon, pas skenĂ«s tĂ« rindĂ«rtojĂ« klasrin nĂ« mĂ«nyrĂ« tĂ« gjallĂ« pa ndonjĂ« shtysĂ« shtesĂ« nga aplikacioni.
Cloister nuk është menduar si një bibliotekë që mund të bëjë gjithçka: nga mbështetje për klastra deri te përgatitja e kafesë. Kjo nuk është një plumb argjendi që synon të kapë të gjitha rastet, ose të jetë një zgjidhje akademike e plotë në kuptimin që teoricienët e CS investojnë në këtë termin. Kjo bibliotekë synon të shërbejë një qëllim shumë të qartë, por të kryejnë punën e saj të vogël më së miri. Ky qëllim do të jetë të sigurojë transparencë të plotë midis mjedisit lokal të zhvillimit dhe mjedisit të elastik të distribuar, të mbushur me enë armiqësore.
Qasja e zgjedhur
Cloister parashihet të ekzekutohet si një aplikacion, megjithatë përdoruesit e avancuar mund të punojnë me ndërtimin dhe mbështetje (assembly and maintenance) të klasterit manualisht, duke e nisur atë direkt Cloister.Manager në pemën e supervizorëve të aplikacionit të synuar.
Kur ekzekutohet si aplikacion, biblioteka mbështetet në config, nga ku lexon këto vlera kryesore:
config :cloister,
otp_app: :my_app,
sentry: :"cloister.local", # ose ~w|n1@foo n2@bar|a
consensus: 3, # numri i nyjeve për tu konsideruar
# që klasteri është aktiv
listener: MyApp.Listener # dëgjuesi që do të thirret kur
# rrethi ka ndryshuarParametrat e mësipërm nënkuptojnë fjalë për fjalë: Cloister përdoret për aplikacionin OTP :my_app, përdor zbulimin e shërbimit erlang për të lidhur nyje, të paktën tre, dhe MyApp.Listener moduli (implementon ) është konfigurimi për të marrë njoftime për ndryshimet në topologji. Përshkrimi i detajuar i konfiguracionit të plotë mund të gjendet në .
Me këtë konfigurim, aplikacioni Cloister do të , duke vonuar procesin e nisjes së aplikacionit kryesor deri sa të arrihet konsensusi (tre nyje janë lidhur dhe lidhur, siç tregohet në shembullin e mësipërm.) Kjo i jep aplikacionit kryesor mundësinë të supozojë se, kur ai është nisur, klasteri është tashmë i disponueshëm. Me çdo ndryshim në topologji (do të jenë shumë, sepse nyjet nuk nisen plotësisht sinkronisht), do të thirret trajtuesi . Në shumicën e rasteve, ne kryejmë një veprim kur marrim një mesazh me gjendjen %Cloister.Monitor{status: :up}, që do të thotë: «Përshëndetje, klasteri është grumbulluar».
NĂ« shumicĂ«n e rasteve, vendosja consensus: 3 Ă«shtĂ« optimale, sepse edhe nĂ«se presim qĂ« tĂ« lidhen mĂ« shumĂ« nyje, ndihma do tĂ« kalojĂ« pĂ«rmes status: :rehashing â status: :up nĂ« çdo nyje tĂ« re tĂ« shtuar ose tĂ« hequr.
Kur niset nĂ« modalitetin e zhvillimit, mjafton tĂ« vendosni consensus: 1 dhe Cloister do tĂ« kalojĂ« me gĂ«zim mbi pritjen e grumbullimit tĂ« klasterit, duke parĂ« :nonode@nohost, ose :node@host, ose :node@host.domain â nĂ« varĂ«si tĂ« mĂ«nyrĂ«s se si Ă«shtĂ« konfigurua nyja (:none | :shortnames | :longnames).
Menaxhimi i aplikacioneve të shpërndara
Aplikacionet e shpërndara nuk ekzistojnë në vakuum dhe zakonisht përfshijnë varësi të shpërndara, siç janë mnesia. Ne kemi mundësi të lehta për ta trajtuar rinovimin e tyre nga e njëjta thirrje prapa on_state_change/2. Këtu, për shembull, është një përshkrim i detajuar se si të rinovoni mnesia në fluks në .
Përparësi kryesore e përdorimit të Cloister është se ai kryen të gjitha operacionet e nevojshme për rindërtimin e klasterit pas ndryshimit të topologjisë nën kapak. Aplikacioni thjesht fillon në një mjedis të shpërndarë të përgatitur më parë, me të gjitha nyjat e lidhura, pavarësisht nga fakti nëse ne e dimë adresën IP dhe, për rrjedhojë, emrat e nyjeve paraprakisht, apo ato janë caktuar/modifikuar dinamikisht. Kjo kërkon asnjë konfigurim të veçantë të dokers dhe nga pikëpamja e zhvilluesit të aplikacioneve, nuk ka ndonjë ndryshim mes ekzekutimit në një ambient të shpërndarë ose në lokal në :nonode@nohost. Më shumë për këtë mund të lexoni në .
Megjithëse përpunimi i ndërlikuar i ndryshimeve të topologjisë është i mundur përmes implementimit të tij MyApp.Listener, gjithmonë mund të ketë raste në kufi kur këto kufizime të bibliotekës dhe qasja e paragjykimeve ndaj konfigurimit dalin në mënyrë domethënëse në rrugën e zbatimit. Kjo është në rregull, thjesht merrni atë që u përmend më parë libcluster, e cila është më universale, ose madje përpunoni klasterin e nivelit të ulët vetë. Qëllimi i kësaj biblioteke kodi nuk është të kapë të gjitha skenaret e mundshme, por të përdorë skenarin më të zakonshëm pa dhimbje të panevojshme dhe kopjime të mëdha
Shënim: në këtë vend në origjinal ishte fraza «Happy clustering!», dhe Yandex, me të cilin po përkthej (nuk do të shkoj të kërkoj në fjalorë), më sugjeroi opsionin «Suksese në grumbullim!». Nuk mund të imagjinohet ndonjë përkthim më i mirë, sidomos në dritën e situatës aktuale gjeopolitike.
Burimi: habr.com
