Cloister → menaxhim i thjeshtë i grupimeve OTP

Pothuajse çdo aplikim i suksesshëm biznesi herët a vonë hyn në një fazë ku kërkohet shkallëzim horizontal. Në shumë raste, thjesht mund të filloni një shembull të ri dhe të zvogëloni mesataren e ngarkesës. Por ka edhe raste më pak të parëndësishme ku duhet të sigurohemi që nyjet e ndryshme të dinë për njëra-tjetrën dhe të shpërndajnë me kujdes ngarkesën e punës.

Cloister → menaxhim i thjeshtë i grupimeve OTP

Doli aq me fat sa erlang, të cilin e zgjodhëm për sintaksën e këndshme dhe zhurmën rreth tij, ka një klas të parë mbështetje për sistemet e shpërndara. Në teori, kjo tingëllon krejtësisht e parëndësishme:

Mesazhi që kalon ndërmjet proceseve në nyje të ndryshme, si dhe ndërmjet lidhjeve dhe monitorëve, është transparent […]

Në praktikë, gjithçka është pak më e ndërlikuar. Shpërndarë erlang u zhvillua kur "konteiner" nënkuptonte një kuti të madhe hekuri për transportin, dhe "docker" ishte thjesht një sinonim për longshoreman. NË IP4 kishte shumë adresa të pabanuara, ndërprerjet e rrjetit zakonisht shkaktoheshin nga minjtë që përtypeshin përmes kabllos dhe koha mesatare e funksionimit të sistemit të prodhimit matej në dekada.

Tani ne të gjithë jemi tepër të vetë-mjaftueshëm, të paketuar dhe të shpërndarë erlang në një mjedis ku adresat IP dinamike shpërndahen sipas parimit të rastësisë së madhe, dhe nyjet mund të shfaqen dhe zhduken sipas dëshirës së thembra të majtë të planifikuesit. Për të shmangur grumbujt e kodit të bojlerplate në çdo projekt që ekzekuton një të shpërndarë erlang, për të luftuar mjedisin armiqësor, kërkohet ndihmë.

Shënim: Jam i vetëdijshëm që ka libcluster. Është vërtet fantastike, ka mbi një mijë yje, autori është i famshëm në komunitet dhe gjithçka. Nëse metodat e ofruara nga kjo paketë për krijimin dhe mirëmbajtjen e një grupi janë të mjaftueshme për ju, unë jam i lumtur për ju. Fatkeqësisht, kam nevojë për shumë më tepër. Dua të kontrolloj në detaje strukturën dhe të mos jem spektator i jashtëm në teatrin e riorganizimit të grupimeve.

Kërkesat

Ajo që më duhej personalisht ishte një bibliotekë që do të merrte përsipër menaxhimin e grupit dhe do të kishte këto karakteristika:

  • punë transparente si me një listë të koduar të nyjeve ashtu edhe me zbulimin dinamik përmes shërbimeve erlang;
  • Thirrje plotësisht funksionale për çdo ndryshim të topologjisë (nyja atje, nyja këtu, paqëndrueshmëria e rrjetit, ndarjet);
  • ndërfaqe transparente për nisjen e një grupi me emra të gjatë dhe të shkurtër, si me :nonode@nohost;
  • Mbështetje Docker jashtë kutisë, pa pasur nevojë të shkruani kodin e infrastrukturës.

Kjo e fundit do të thotë që pasi kam testuar aplikacionin në nivel lokal në :nonode@nohost, ose në një mjedis të shpërndarë artificialisht duke përdorur test_cluster_task, Unë thjesht dua të vrapoj docker-compose up --scale my_app=3 dhe shikoni se si ekzekuton tre instanca në docker pa ndonjë ndryshim kodi. Dua gjithashtu aplikacione të varura si mnesia - kur ndryshon topologjia, në prapaskenë ata rindërtojnë grupin drejtpërdrejt pa ndonjë goditje shtesë nga aplikacioni.

manastir nuk kishte për qëllim të ishte një bibliotekë e aftë për gjithçka, nga mbështetja e një grupi deri te përgatitja e kafesë. Nuk është një plumb argjendi që synon të mbulojë të gjitha rastet e mundshme, ose të jetë një zgjidhje e plotë akademikisht në kuptimin që teoricienët nga CS vënë në këtë term. Kjo bibliotekë është krijuar për t'i shërbyer një qëllimi shumë të qartë, por ta bëjë punën e saj jo shumë të madhe në mënyrë perfekte. Ky synim do të jetë sigurimi i transparencës së plotë midis mjedisit të zhvillimit lokal dhe një mjedisi elastik të shpërndarë plot me kontejnerë armiqësor.

Qasje e zgjedhur

manastir synohet të ekzekutohet si aplikacion, megjithëse përdoruesit e avancuar mund të punojnë me montimin dhe mirëmbajtjen e grupit manualisht duke ekzekutuar drejtpërdrejt Cloister.Manager në pemën mbikëqyrëse të aplikacionit të synuar.

Kur ekzekutohet si aplikacion, biblioteka mbështetet në config, nga i cili lexon vlerat themelore të mëposhtme:

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 changed

Parametrat e mësipërm nënkuptojnë fjalë për fjalë sa vijon: manastir përdoret për aplikimin OTP :my_app, përdor zbulimi i shërbimit erlang për të lidhur nyjet, të paktën tre, dhe MyApp.Listener moduli (në zbatim @behaviour Cloister.Listener) është konfiguruar për 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 manastir do të nisja në faza, duke vonuar procesin e nisjes së aplikacionit kryesor derisa të arrihet konsensusi (tre nyje janë të lidhura dhe të lidhura, si në shembullin e mësipërm.) Kjo i jep aplikacionit kryesor mundësinë të supozojë se kur të fillojë, grupi është tashmë i disponueshëm. Sa herë që ndryshon topologjia (do të ketë shumë prej tyre, sepse nyjet nuk fillojnë plotësisht në mënyrë sinkronike), mbajtësi do të thirret MyApp.Listener.on_state_change/2. Shumicën e kohës ne kryejmë një veprim kur marrim një mesazh statusi %Cloister.Monitor{status: :up}, që do të thotë: "Përshëndetje, grupi është mbledhur."

Në shumicën e rasteve, instalimi consensus: 3 është optimale sepse edhe nëse presim më shumë nyje të lidhen, kthimi i thirrjes do të kalojë status: :rehashingstatus: :up në çdo nyje të shtuar ose të hequr rishtazi.

Kur filloni në modalitetin e zhvillimit, thjesht duhet të vendosni consensus: 1 и manastir do ta kalojë me kënaqësi pritjen për montimin e grupit kur të shohë :nonode@nohostOse :node@hostOse :[email protected] - në varësi të mënyrës se si është konfiguruar nyja (:none | :shortnames | :longnames).

Menaxhimi i Aplikacioneve të Shpërndara

Aplikacionet e shpërndara jo në vakum zakonisht përfshijnë varësi të shpërndara, si p.sh mnesia. Është e lehtë për ne që të trajtojmë rikonfigurimin e tyre nga i njëjti kthim telefonimi on_state_change/2. Këtu, për shembull, është një përshkrim i detajuar se si të rikonfiguroni mnesia në fluturim në dokumentacionin manastir.

Avantazhi kryesor i përdorimit manastir është se ai kryen të gjitha operacionet e nevojshme për të rindërtuar grupin pas një ndryshimi të topologjisë nën kapuç. Aplikacioni thjesht funksionon në një mjedis të shpërndarë tashmë të përgatitur, me të gjitha nyjet të lidhura, pavarësisht nëse i dimë adresat IP dhe për rrjedhojë emrat e nyjeve paraprakisht, ose ato janë caktuar/ndryshuar në mënyrë dinamike. Kjo nuk kërkon absolutisht asnjë cilësim të veçantë të konfigurimit të dokerit dhe nga këndvështrimi i zhvilluesit të aplikacionit, nuk ka asnjë ndryshim midis ekzekutimit në një mjedis të shpërndarë ose ekzekutimit në një mjedis lokal. :nonode@nohost. Ju mund të lexoni më shumë rreth kësaj në dokumentacionin.

Megjithëse trajtimi kompleks i ndryshimeve të topologjisë është i mundur përmes një zbatimi të personalizuar MyApp.Listener, mund të ketë gjithmonë raste kur këto kufizime të bibliotekës dhe paragjykimet e konfigurimit provojnë të jenë gurët e themelit të zbatimit. Është në rregull, thjesht merrni sa më sipër libcluster, që është më për qëllime të përgjithshme, ose madje trajtoni vetë grupimin e nivelit të ulët. Qëllimi i kësaj biblioteke kodesh nuk është të mbulojë çdo skenar të mundshëm, por të përdorë skenarin më të zakonshëm pa dhimbje të panevojshme dhe copy-paste të rëndë.

Shenim: në këtë pikë në origjinal ishte fraza "Gëzuar grupim!", dhe Yandex, me të cilin përkthej (nuk duhet të kaloj vetë fjalorë), më ofroi opsionin "Gëzuar grupim!" Është ndoshta e pamundur të imagjinohet një përkthim më i mirë, veçanërisht në dritën e situatës aktuale gjeopolitike.

Burimi: www.habr.com

Shto një koment