Klostro → simpla administrado de cluster de OTP

Preskaŭ ĉiu sukcesa komerca aplikaĵo pli aŭ malpli frue eniras fazon, kie necesas horizontala skalo. En multaj kazoj, vi povas simple komenci novan kazon kaj redukti la ŝarĝan mezumon. Sed estas ankaŭ malpli bagatelaj kazoj, kie ni devas certigi, ke malsamaj nodoj scias unu pri la alia kaj zorge distribuas la laborŝarĝon.

Montriĝis tiel bonŝance ke erlang, kiun ni elektis pro sia agrabla sintakso kaj hype ĉirkaŭ ĝi, havas unuaklasan subteno por distribuitaj sistemoj. En teorio, ĉi tio sonas tute bagatela:

Mesaĝo pasanta inter procezoj sur malsamaj nodoj, same kiel inter ligiloj kaj monitoroj, estas travidebla [...]

En la praktiko, ĉio estas iom pli komplika. Distribuita erlang estis evoluigita kiam "ujo" signifis grandan feran skatolon por ekspedado, kaj "doker" estis simple sinonimo por bordisto. EN IP4 ekzistis multaj neokupitaj adresoj, retaj paŭzoj estis kutime kaŭzitaj de ratoj maĉantaj tra la kablo, kaj la meza funkciado de la produktadsistemo estis mezurita en jardekoj.

Nun ni ĉiuj estas nekredeble memsufiĉaj, pakitaj kaj distribuitaj erlang en medio kie dinamikaj IP-adresoj estas disdonitaj laŭ la principo de granda hazardo, kaj nodoj povas aperi kaj malaperi laŭ la kaprico de la maldekstra kalkano de la planilo. Eviti amasojn da kodo en ĉiu projekto prizorganta distribuitan erlang, por batali la malamikan medion, helpo necesas.

Примечание: Mi konscias ke ekzistas libcluster. Ĝi estas vere mojosa, ĝi havas pli ol mil stelojn, la aŭtoro estas fama en la komunumo, kaj ĉio tio. Se la metodoj ofertitaj de ĉi tiu pako por krei kaj prizorgi areton sufiĉas por vi, mi ĝojas por vi. Bedaŭrinde, mi bezonas multe pli. Mi volas kontroli la aranĝon detale kaj ne esti ekstera spektanto en la teatro de reorganizado de grapoloj.

postuloj

Kion mi persone bezonis estis biblioteko, kiu transprenus administradon de la areto kaj havus la jenajn trajtojn:

• travidebla laboro kun kaj malmola kodita listo de nodoj kaj dinamika malkovro per servoj erlang;
• plene funkcia revoko por ĉiu topologioŝanĝo (nodo tie, nodo ĉi tie, retmalstabileco, disiĝoj);
• travidebla interfaco por lanĉi areton kun longaj kaj mallongaj nomoj, kiel kun :nonode@nohost;
• Docker-subteno el la skatolo, sen devi skribi infrastrukturan kodon.

Ĉi-lasta signifas, ke post kiam mi testis la aplikaĵon loke en :nonode@nohost, aŭ en artefarite distribuita medio uzante test_cluster_task, mi nur volas kuri docker-compose up --scale my_app=3 kaj vidu kiel ĝi ekzekutas tri okazojn en docker sen ajnaj kodŝanĝoj. Mi ankaŭ volas dependajn aplikojn kiel mnesia - kiam la topologio ŝanĝiĝas, malantaŭ la scenoj ili rekonstruas la areton vive sen iu plia piedbato de la aplikaĵo.

Klostro ne estis celita esti biblioteko kapabla je ĉio de apogado de areto ĝis farado de kafo. Ĝi ne estas arĝenta kuglo kiu celas kovri ĉiujn eblajn kazojn, aŭ esti akademie kompleta solvo en la senco, ke teoriuloj de CS meti en ĉi tiun terminon. Ĉi tiu biblioteko estas dizajnita por servi tre klaran celon, sed plenumi sian ne tro grandan laboron perfekte. Ĉi tiu celo estos provizi kompletan travideblecon inter la loka evolua medio kaj distribuita elasta medio plena de malamikaj ujoj.

Elektita alproksimiĝo

Klostro estas celita esti rulita kiel aplikaĵo, kvankam progresintaj uzantoj povas labori kun kunigo kaj prizorgado de la areto permane per rekte funkciado. Cloister.Manager en la kontrola arbo de la cela aplikaĵo.

Kiam ĝi funkcias kiel aplikaĵo, la biblioteko dependas de config, el kiu ĝi legas la sekvajn bazajn valorojn:

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

La supraj parametroj signifas laŭvorte la jenon: Klostro uzata por OTP-apliko :my_app, uzoj erlanga servo malkovro por konekti nodojn, almenaŭ tri, kaj MyApp.Listener modulo (efektiviganta @behaviour Cloister.Listener) estas agordita por ricevi sciigojn pri topologiaj ŝanĝoj. Detala priskribo de la kompleta agordo troviĝas en dokumentado.

Kun ĉi tiu agordo, la aplikaĵo Klostro estos lanĉo en etapoj, prokrastante la procezon komenci la ĉefan aplikaĵon ĝis konsento estas atingita (tri nodoj estas konektitaj kaj konektitaj, kiel en la supra ekzemplo.) Ĉi tio donas al la ĉefa aplikaĵo la ŝancon supozi, ke kiam ĝi komenciĝas, la areto jam disponeblas. Kiam ajn la topologio ŝanĝiĝas (estos multaj el ili, ĉar la nodoj ne komenciĝas tute sinkrone), la prizorganto estos nomita MyApp.Listener.on_state_change/2. Plej ofte ni faras agon kiam ni ricevas statusmesaĝon %Cloister.Monitor{status: :up}, kio signifas: "Saluton, la areto estas kunmetita."

Plejofte, instalado consensus: 3 estas optimuma ĉar eĉ se ni atendas pli da nodoj konektiĝi, la revoko trairos status: :rehashing → status: :up sur iu nove aldonita aŭ forigita nodo.

Kiam vi komencas en disvolva reĝimo, vi nur bezonas agordi consensus: 1 и Klostro feliĉe preterlasos la atendon por amaso-asembleo kiam li vidos :nonode@nohostaŭ :node@hostaŭ :[email protected] - depende de kiel la nodo estis agordita (:none | :shortnames | :longnames).

Distribuita Aplika Administrado

Distribuitaj aplikoj ne en vakuo kutime inkluzivas distribuitajn dependecojn, kiel ekzemple mnesia. Estas facile por ni trakti ilian reagordon de la sama revoko on_state_change/2. Jen, ekzemple, detala priskribo pri kiel reagordi mnesia sur la flugo enen dokumentado Klostro.

La ĉefa avantaĝo de uzado Klostro estas ke ĝi faras ĉiujn necesajn operaciojn por rekonstrui la areton post topologioŝanĝo sub la kapuĉo. La aplikaĵo simple funkcias en jam preta distribuita medio, kun ĉiuj nodoj konektitaj, sendepende de ĉu ni konas la IP-adresojn kaj tial la nodnomojn anticipe, aŭ ili estis dinamike asignitaj/ŝanĝitaj. Ĉi tio postulas absolute neniujn specialajn agordojn de docker kaj de la vidpunkto de programisto de aplikaĵo, ne ekzistas diferenco inter funkcii en distribuita medio aŭ funkcii en loka. :nonode@nohost. Vi povas legi pli pri tio en dokumentado.

Kvankam kompleksa manipulado de topologioŝanĝoj estas ebla per kutima efektivigo MyApp.Listener, ĉiam povas ekzisti randkazoj kie tiuj bibliotekaj limigoj kaj konfiguraciaj biasoj pruvas esti la bazŝtonoj de efektivigo. Estas bone, nur prenu la supre libcluster, kiu estas pli ĝeneraluzebla, aŭ eĉ manipuli la malaltnivelan areton mem. La celo de ĉi tiu kodbiblioteko estas ne kovri ĉiun eblan scenaron, sed uzi la plej oftan scenaron sen nenecesa doloro kaj maloportuna kopi-gluo.

Notu: ĉi-momente en la originalo estis la frazo "Feliĉa grupigo!", kaj Yandex, per kiu mi tradukas (mi ne devas mem trairi vortarojn), proponis al mi la opcion "Feliĉa grupigo!" Eble ne eblas imagi pli bonan tradukon, precipe konsiderante la nunan geopolitikan situacion.

fonto: www.habr.com