Cloister → menaxhim i thjeshtë i klasterit OTP

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ë për sistemet e shpërndara. 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 libcluster. Ë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 test_cluster_task, 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 ndryshuar

Parametrat 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 @behaviour Cloister.Listener) është konfigurimi për të marrë njoftime për ndryshimet në topologji. Përshkrimi i detajuar i konfiguracionit të plotë mund të gjendet në dokumentacion.

Me këtë konfigurim, aplikacioni Cloister do të nisë në faza, 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 MyApp.Listener.on_state_change/2. 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ë dokumentacion Cloister.

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ë dokumentacion.

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