Akatsen tolerantzia eta erabilgarritasun handia gai handiak dira, beraz, artikulu bereiziak eskainiko dizkiegu RabbitMQ eta Kafka-ri. Artikulu hau RabbitMQri buruzkoa da, eta hurrengoa Kafkari buruzkoa, RabbitMQ-rekin alderatuta. Artikulu luzea da, beraz, eroso egon zaitez.

Ikus ditzagun akatsen tolerantzia, koherentzia eta erabilgarritasun handiko (HA) estrategiak eta estrategia bakoitzak egiten dituen konpromezuak. RabbitMQ nodo multzo batean exekutatu daiteke, eta gero sistema banatu gisa sailkatzen da. Banatutako sistemei dagokienez, sarritan koherentziaz eta erabilgarritasunaz hitz egiten dugu.

Kontzeptu hauek sistema batek huts egiten duenean nola jokatzen duen deskribatzen dute. Sare-konexioaren hutsegitea, zerbitzariaren hutsegitea, disko gogorreko hutsegitea, zerbitzariaren aldi baterako erabilgarritasunik eza, zabor bilketagatik, pakete-galeragatik edo sareko konexioa moteltzeagatik. Horrek guztiak datuak galtzea edo gatazkak sor ditzake. Bihurtzen da ia ezinezkoa dela guztiz koherentea den sistema bat jartzea (datu-galerarik ez, datu-dibergentziarik gabe) eta erabilgarri (irakurketa eta idazketa onartuko duena) huts-egoera guztietan.

Koherentzia eta erabilgarritasuna espektroaren aurkako muturretan daudela ikusiko dugu, eta optimizatu zein bide aukeratu behar duzu. Albiste ona da RabbitMQ-rekin aukera hau posible dela. Palanka "nerdy" mota hauek dituzu oreka koherentzia handiagoa edo irisgarritasun handiagorantz aldatzeko.

Arreta berezia jarriko dugu berretsitako erregistroen ondorioz zein konfiguraziok datuak galtzen dituzten. Argitaletxe, artekari eta kontsumitzaileen artean erantzukizun kate bat dago. Behin mezua artekariari transmitituta, bere lana da mezua ez galtzea. Agenteak argitaletxeak mezua jaso duela aitortzen duenean, ez dugu espero galtzea. Baina ikusiko dugu hori benetan gerta daitekeela zure broker eta argitaratzailearen konfigurazioaren arabera.

Nodo bakarreko erresilientzia primitiboak

Ilara/bideratze erresistentea

RabbitMQ-n bi ilara mota daude: iraunkorrak eta ez iraunkorrak. Ilara guztiak Mnesia datu-basean gordetzen dira. Ilara iraunkorrak berriro iragartzen dira nodoa abiaraztean eta, horrela, berrabiarazten, sistemaren hutsegiteetan edo zerbitzarien hutsegiteetan bizirik irauten dute (datuak iraun bitartean). Horrek esan nahi du bideraketa (trukea) eta ilara erresistenteak direla deklaratzen duzun bitartean, ilara/bideratze azpiegitura sarera itzuliko dela.

Ilara lurrunkorrak eta bideratzea kentzen dira nodoa berrabiarazten denean.

Mezu iraunkorrak

Ilara bat iraunkorra izateak ez du esan nahi bere mezu guztiek nodo berrabiarazten dutenik iraungo dutenik. Argitaletxeak gisa ezarri dituen mezuak soilik iraunkorra (iraunkorra). Mezu iraunkorrak karga gehigarria sortzen dio brokerari, baina mezuak galtzea onartezina bada, ez dago beste aukerarik.

Arroza. 1. Iraunkortasun matrizea

Ilararen ispiluarekin multzokatzea

Agente baten galerari aurre egiteko, erredundantzia behar dugu. RabbitMQ nodo anitz konbina ditzakegu kluster batean, eta gero erredundantzia gehigarria gehitu nodo anitzen arteko ilarak errepikatuz. Honela, nodo batek huts egiten badu, ez ditugu datuak galtzen eta eskuragarri jarraituko dugu.

Ilararen ispilua:

• ilara nagusi bat (maisua), idazteko eta irakurtzeko agindu guztiak jasotzen dituena
• ilara nagusiko mezu eta metadatu guztiak jasotzen dituen ispilu bat edo gehiago. Ispilu hauek ez daude eskalatzeko, erredundantziarako baizik.

Arroza. 2. Ilararen ispilua

Ispilua politika egokiak ezartzen du. Bertan erreplikazio-koefizientea eta baita ilarak kokatu behar diren nodoak ere hauta ditzakezu. Adibideak:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (maisu bat eta ispilu bat)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Argitaletxearen berrespena

Grabaketa koherentea lortzeko, argitaletxearen berrespenak behar dira. Horiek gabe, mezuak galtzeko arriskua dago. Berrespena bidaltzen zaio argitaratzaileari mezua diskoan idatzi ondoren. RabbitMQ-k mezuak diskoan idazten ditu ez jasotzean, aldizka baizik, ehunka milisegundoren inguruan. Ilara bat ispilu denean, aitorpen bat bidaltzen da ispilu guztiek mezuaren kopia diskoan idatzi ondoren soilik. Horrek esan nahi du baieztapenak erabiltzeak latentzia gehitzen duela, baina datuen segurtasuna garrantzitsua bada, beharrezkoak dira.

Hutsegiteko ilara

Agente bat irten edo huts egiten denean, nodo horretako ilara-buru guztiak (maisu) huts egiten dute harekin batera. Ondoren, klusterrak maisu bakoitzaren ispilu zaharrena hautatzen du eta maisu berri gisa sustatzen du.

Arroza. 3. Ispilu-ilara anitz eta haien politikak

Broker 3 behera doa. Kontuan izan Broker 2-ko Queue C ispilua maisu izateko sustatzen ari dela. Kontuan izan ere ispilu berri bat sortu dela Broker 1-en C ilaran. RabbitMQ beti saiatzen da zure politiketan zehaztutako erreplikazio-faktorea mantentzen.

Arroza. 4. 3. artekariak huts egiten du, eta C ilarak huts egiten du

Hurrengo Broker 1 erortzen da! Broker bakarra geratzen zaigu. Ilara B ispilua menperatzera sustatzen da.

Fig. 5

Broker 1 itzuli dugu. Datuek artekariaren galera eta berreskurapenetik zenbateraino irauten duten kontuan hartu gabe, ispilutako ilararen mezu guztiak berrabiarazten direnean baztertzen dira. Garrantzitsua da kontuan hartzea, ondorioak izango direlako. Laster aztertuko ditugu ondorio hauek. Beraz, Broker 1 klusterreko kide da berriro, eta klusterrak politikak betetzen saiatzen da eta, beraz, Broker 1-en ispiluak sortzen ditu.

Kasu honetan, Broker 1 galtzea erabatekoa zen, datuak bezalaxe, beraz, ispilu gabeko B Ilara erabat galdu zen.

Arroza. 6. Broker 1 zerbitzura itzultzen da

Broker 3 sarera itzuli da, beraz, A eta B ilarek bertan sortutako ispiluak berreskuratzen dituzte beren HA politikak asetzeko. Baina orain ilara nagusi guztiak nodo batean daude! Hau ez da aproposa, hobe da nodoen arteko banaketa uniformea. Zoritxarrez, hemen ez dago aukera handirik maisuak orekatzeko. Geroago itzuliko gara arazo honi, lehenik ilararen sinkronizazioa aztertu behar dugulako.

Arroza. 7. 3. artekaria zerbitzura itzultzen da. Ilara nagusi guztiak nodo batean!

Beraz, ispiluak erredundantzia eta akatsen tolerantzia nola ematen duten jakiteko ideia bat izan beharko zenuke. Horrek erabilgarritasuna bermatzen du nodo bakarraren hutsegitearen kasuan eta datuak galtzearen aurka babesten du. Baina oraindik ez dugu amaitu, errealitatean askoz konplikatuagoa baita.

sinkronizazio

Ispilu berri bat sortzean, mezu berri guztiak beti errepikatuko dira ispilu honetan eta beste edozeinetan. Ilara maisuan dauden datuei dagokienez, ispilu berri batean errepika ditzakegu, maisuaren kopia osoa bihurtuko dena. Lehendik dauden mezuak ez errepikatzea eta ilara nagusia eta ispilu berria denboran bat egiten uztea ere aukeratu dezakegu, mezu berriak buztanera iristen direla eta lehendik dauden mezuak ilara nagusiaren burua utziz.

Sinkronizazio hau automatikoki edo eskuz egiten da eta ilararen politika baten bidez kudeatzen da. Ikus dezagun adibide bat.

Bi ispilu ilara ditugu. A ilara automatikoki sinkronizatzen da eta B ilara eskuz. Bi ilarak hamar mezu dituzte.

Arroza. 8. Sinkronizazio modu ezberdineko bi ilara

Orain Broker 3 galtzen ari gara.

Arroza. 9. Broker 3 erori zen

Broker 3 zerbitzura itzultzen da. Klusterrak ispilu bat sortzen du ilara bakoitzeko nodo berrian eta automatikoki sinkronizatzen du A Ilara berria maisuarekin. Hala ere, B Ilara berriaren ispiluak hutsik jarraitzen du. Horrela erredundantzia osoa dugu A ilaran eta ispilu bakarra lehendik dauden B ilaran.

Arroza. 10. A ilararen ispilu berriak lehendik dauden mezu guztiak jasotzen ditu, baina B ilararen ispilu berriak ez.

Bi ilaretan beste hamar mezu iristen dira. Ondoren, Broker 2 huts egiten du eta Ilara A ispilu zaharrenera itzultzen da, hau da, Broker 1n. Huts egiten duenean ez da daturik galtzen. B ilaran, hogei mezu daude maisuan eta hamar bakarrik ispiluan, ilara honek ez baititu inoiz jatorrizko hamar mezuak errepikatu.

Arroza. 11. A ilara itzultzen da Broker 1ra mezuak galdu gabe

Bi ilaretan beste hamar mezu iristen dira. Orain Broker 1 huts egiten du. Ilara A ispilura erraz aldatzen da mezuak galdu gabe. Hala ere, B ilara arazoak ditu. Une honetan erabilgarritasuna edo koherentzia optimiza ditzakegu.

Irisgarritasuna optimizatu nahi badugu, orduan politika ha-sustatu-porrotean bertan instalatu behar da beti.. Hau da balio lehenetsia, beraz, ezin duzu politika batere zehaztu. Kasu honetan, funtsean, sinkronizatu gabeko ispiluetan hutsegiteak onartzen ari gara. Honek mezuak galtzea eragingo du, baina ilarak irakurgarri eta idazteko moduan jarraituko du.

Arroza. 12. A ilara itzultzen da Broker 3ra mezuak galdu gabe. B ilara itzultzen da Broker 3ra hamar mezu galduta

Instalatu ere egin dezakegu ha-promote-on-failure esanahian sartu when-synced. Kasu honetan, ispilura itzuli beharrean, ilarak Broker 1 bere datuekin lineako modura itzultzen den arte itxarongo du. Itzuli ondoren, ilara nagusia Broker 1-era itzuliko da datu-galerarik gabe. Datuen segurtasunerako erabilgarritasuna sakrifikatu egiten da. Baina datuen galera osoa ere ekar dezakeen modu arriskutsua da, laster aztertuko duguna.

Arroza. 13. B ilara ez dago erabilgarri Broker 1 galdu ondoren

Galdetuko duzu: "Hobe al da inoiz sinkronizazio automatikoa erabiltzea?" Erantzuna da sinkronizazioa blokeo-eragiketa bat dela. Sinkronizazioan, ilara nagusiak ezin du irakurketa edo idazketa eragiketarik egin!

Ikus dezagun adibide bat. Orain ilara oso luzeak ditugu. Nola hazi daitezke halako tamainara? Hainbat arrazoirengatik:

• Ilarak ez dira aktiboki erabiltzen
• Abiadura handiko ilarak dira, eta oraintxe bertan kontsumitzaileak motelak dira
• Abiadura handiko ilarak dira, akats bat egon da eta kontsumitzaileak harrapatzen ari dira

Arroza. 14. Bi ilara handi sinkronizazio modu ezberdinekin

Orain Broker 3 erortzen da.

Arroza. 15. Broker 3 erortzen da, ilara bakoitzean maisu eta ispilu bat utziz

Broker 3 sarera itzultzen da eta ispilu berriak sortzen dira. Ilara nagusia A lehendik dauden mezuak ispilu berrian errepikatzen hasten da, eta denbora horretan Ilara ez dago erabilgarri. Bi ordu behar dira datuak errepikatzeko, eta ondorioz, bi ordu gelditzen dira Ilara honetan!

Hala ere, B ilarak erabilgarri jarraitzen du aldi osoan. Irisgarritasunagatik erredundantzia batzuk sakrifikatu zituen.

Arroza. 16. Ilara ez dago erabilgarri sinkronizazioan zehar

Bi ordu igaro ondoren, A ilara ere erabilgarri egongo da eta irakurketak eta idazketak onartzen has daiteke berriro.

Media

Sinkronizazioan blokeatzeko jokabide honek zaildu egiten du ilara oso handiak dituzten klusterrak eguneratzea. Noizbait, nodo nagusia berrabiarazi behar da, hau da, ispilu batera aldatu edo ilara desgaitu zerbitzaria berritzen ari den bitartean. Trantsizioa aukeratzen badugu, mezuak galduko ditugu ispiluak sinkronizatzen ez badira. Lehenespenez, artekariaren etenaldi batean, ez da sinkronizatu gabeko ispilu baten hutsegitea egiten. Horrek esan nahi du brokerra itzuli bezain laster ez dugula mezurik galtzen, kalte bakarra ilara soil bat besterik ez dela izan. Broker bat deskonektatzen denean jokabide-arauak politikak ezartzen ditu ha-promote-on-shutdown. Bi balio hauetako bat ezar dezakezu:

• always= sinkronizatu gabeko ispiluetarako trantsizioa gaituta dago
• when-synced= ispilu sinkronizatu batera igarotzea soilik, bestela ilara irakurezin eta idaztezin bihurtzen da. Ilara zerbitzura itzultzen da artekaria itzuli bezain laster

Modu batera edo bestera, ilara handiekin datuak galtzearen eta erabilgarritasunaren artean aukeratu behar duzu.

Eskuragarritasunak Datuen Segurtasuna Hobetzen duenean

Erabaki bat hartu aurretik kontuan hartu beharreko beste konplikazio bat dago. Sinkronizazio automatikoa erredundantziarako hobea den arren, nola eragiten du datuen segurtasunean? Jakina, erredundantzia hobearekin, RabbitMQ-k lehendik dauden mezuak galtzeko aukera gutxiago du, baina zer gertatzen da argitaletxeen mezu berriekin?

Hemen honako hau kontuan hartu behar duzu:

• Argitaletxeak errore bat itzul dezake eta gorako zerbitzua edo erabiltzailea geroago berriro saiatzea?
• Argitaletxeak gorde al dezake mezua lokalean edo datu-base batean geroago berriro saiatzeko?

Argitaletxeak mezua bakarrik baztertzen badu, orduan, hain zuzen ere, irisgarritasuna hobetzeak datuen segurtasuna ere hobetzen du.

Hala, oreka bilatu behar da, eta irtenbidea egoera zehatzaren araberakoa da.

Arazoak ha-promote-on-failure=sinkronizatuta dagoenean

Idea ha-sustatu-porrotean= sinkronizatuta dagoenean da sinkronizatu gabeko ispilu batera aldatzea eragozten dugula eta, ondorioz, datuak galtzea ekiditen dugula. Ilarak irakurezin edo idaztezin izaten jarraitzen du. Horren ordez, huts egin duen artekaria bere datuekin berreskuratzen saiatzen gara, datu-galerarik gabe maisu gisa funtzionatzen jarrai dezan.

Baina (eta hau baina handia da) artekariak bere datuak galdu baditu, arazo handi bat dugu: ilara galdu da! Datu guztiak desagertu dira! Gehienetan ilara nagusian harrapatzen duten ispiluak badituzu ere, ispilu horiek ere baztertzen dira.

Izen bereko nodo bat berriro gehitzeko, klusterari esango diogu galdutako nodoa ahazteko (komandoarekin rabbitmqctl forget_cluster_node) eta hasi broker berri bat ostalari-izen berarekin. Klusterrak galdutako nodoa gogoratzen duen bitartean, ilara zaharra eta sinkronizatu gabeko ispiluak gogoratzen ditu. Kluster bati nodo umezurtz bat ahazteko esaten zaionean, ilara hori ere ahaztu egiten da. Orain berriro deklaratu behar dugu. Datu guztiak galdu genituen, datu multzo partzial batekin ispiluak genituen arren. Hobe izango litzateke ispilu ez-sinkronizatu batera aldatzea!

Hori dela eta, eskuzko sinkronizazioa (eta sinkronizazioa huts egitea) batera ha-promote-on-failure=when-synced, nire ustez, nahiko arriskutsua. Dokumentuek diote aukera hau badagoela datuen segurtasunerako, baina aho biko labana da.

Berreoreka maisua

Agindu bezala, maisu guztiak nodo batean edo hainbatetan pilatzearen arazora itzuliko gara. Hau kluster eguneratzearen ondorioz ere gerta daiteke. Hiru nodoko kluster batean, ilara nagusi guztiak nodo batean edo bitan pilatuko dira.

Maisuak berriro orekatzea problematikoa izan daiteke bi arrazoirengatik:

• Ez dago erreminta onik oreka egiteko
• Ilararen sinkronizazioa

Hirugarren bat dago orekatzeko plugina, ofizialki onartzen ez dena. RabbitMQ eskuliburuko hirugarrenen pluginei buruz esan zuen: "Pluginak konfigurazio eta berri emateko tresna gehigarri batzuk eskaintzen ditu, baina RabbitMQ taldeak ez ditu onartzen edo egiaztatzen. Erabili zure ardurapean".

Badago beste trikimailu bat ilara nagusia HA politiken bidez mugitzeko. Eskuliburuak aipatzen du gidoia honetarako. Honela funtzionatzen du:

• Ispilu guztiak kentzen ditu lehendik dagoen HA politikak baino lehentasun handiagoa duen aldi baterako politika erabiliz.
• HA aldi baterako politika aldatzen du nodo modua erabiltzeko, ilara nagusia zein nodora transferitu behar den zehaztuz.
• Push migraziorako ilara sinkronizatzen du.
• Migrazioa amaitu ondoren, aldi baterako politika ezabatzen du. Hasierako HA politika indarrean jartzen da eta beharrezko ispilu kopurua sortzen da.

Alde txarra da ikuspegi honek agian ez duela funtzionatuko ilara handiak edo erredundantzia-eskakizun zorrotzak badituzu.

Orain ikus dezagun nola funtzionatzen duten RabbitMQ klusterrak sareko partizioekin.

Konektibitatearen galera

Banatutako sistema baten nodoak sare-loturen bidez konektatzen dira, eta sare-loturak deskonekta daitezke eta deskonektatu egingo dira. Etenaldien maiztasuna tokiko azpiegituraren edo hautatutako hodeiaren fidagarritasunaren araberakoa da. Nolanahi ere, sistema banatuak haiei aurre egiteko gai izan behar dute. Berriro ere eskuragarritasuna eta koherentziaren artean aukera dugu, eta berriro ere albiste ona da RabbitMQ-k bi aukerak eskaintzen dituela (ez aldi berean).

RabbitMQ-rekin bi aukera nagusi ditugu:

• Zatiketa logikoa baimendu (split-brain). Horrek erabilgarritasuna bermatzen du, baina datuak galtzea eragin dezake.
• Desgaitu bereizketa logikoa. Epe laburreko erabilgarritasuna galtzea eragin dezake bezeroak klusterera konektatzen diren moduaren arabera. Bi nodoko kluster batean erabilgarritasun osoa ere ekar dezake.

Baina zer da bereizketa logikoa? Hau da kluster bat bitan zatitzen denean sareko konexioak galtzeagatik. Alde bakoitzean, ispiluak maisu izatera igotzen dira, azkenean ilara bakoitzeko hainbat maisu egon daitezen.

Arroza. 17. Ilara nagusia eta bi ispilu, bakoitza nodo batean. Orduan sarearen hutsegite bat gertatzen da eta ispilu bat desegin egiten da. Banatutako nodoak beste biak erori direla ikusten du eta bere ispiluak maisuari sustatzen dizkio. Orain bi ilara nagusi ditugu, biak idazteko modukoak eta irakurgarriak.

Argitaletxeek bi maisuei datuak bidaltzen badituzte, ilararen bi kopia dibergente lortzen ditugu.

RabbitMQ-ren modu ezberdinek erabilgarritasuna edo koherentzia eskaintzen dute.

Ez ikusi modua (lehenetsia)

Modu honek irisgarritasuna bermatzen du. Konektibitatea galdu ondoren, bereizketa logikoa gertatzen da. Konektibitatea berrezarri ondoren, administratzaileak erabaki behar du zein partiziori eman lehentasuna. Galtzen duen aldea berrabiaraziko da eta alde horretan pilatutako datu guztiak galduko dira.

Arroza. 18. Hiru argitaletxe hiru artekarirekin lotuta daude. Barruan, klusterrak Broker 2-ko ilara nagusira bideratzen ditu eskaera guztiak.

Orain Broker 3 galtzen ari gara. Beste artekari batzuk erori direla ikusten du eta bere ispilua maisuari sustatzen dio. Horrela gertatzen da bereizketa logikoa.

Arroza. 19. Zatiketa logikoa (split-brain). Erregistroak bi ilara nagusitan sartzen dira, eta bi kopiak aldendu egiten dira.

Konektibitatea berrezarri da, baina bereizketa logikoa mantentzen da. Administratzaileak eskuz hautatu behar du galtzen duen aldea. Beheko kasuan, administratzaileak Broker 3 berrabiarazten du. Igortzea lortu ez zuen mezu guztiak galtzen dira.

Arroza. 20. Administratzaileak Broker 3 desgaitzen du.

Arroza. 21. Administratzaileak Broker 3 abiarazten du eta klusterean sartzen da, bertan utzitako mezu guztiak galduz.

Konektibitatea galtzean eta zaharberritu ondoren, klusterra eta ilara hau irakurtzeko eta idazteko erabilgarri zeuden.

Autosendatzeko modua

Ez ikusi moduaren antzera funtzionatzen du, klusterrak berak automatikoki aukeratzen duela galtzen duen aldea izan ezik, konektibitatea zatitu eta leheneratu ondoren. Galtzen duen aldea klusterra hutsik itzultzen da, eta ilarak alde horretara soilik bidalitako mezu guztiak galtzen ditu.

Pausa gutxiengo modua

Ez badugu partizio logikoa baimendu nahi, orduan gure aukera bakarra irakurketak eta idazketak kluster partizioaren ondoren alde txikiagoan baztertzea da. Agenteak alde txikiagoan dagoela ikusten duenean, lana eten egiten du, hau da, dauden konexio guztiak ixten ditu eta berriei uko egiten die. Segundoan behin konexioa berreskuratu den egiaztatzen du. Konektibitatea berrezarritakoan, funtzionamenduari ekingo dio eta klusterean sartzen da.

Arroza. 22. Hiru argitaletxe hiru artekarirekin lotuta daude. Barruan, klusterrak Broker 2-ko ilara nagusira bideratzen ditu eskaera guztiak.

1. eta 2. artekariak 3. artekaritik banatzen dira. Beren ispilua maisu bihurtu beharrean, 3. artekariak eten egiten du eta ez dago erabilgarri.

Arroza. 23. Broker 3 pausatu egiten du, bezero guztiak deskonektatzen ditu eta konexio eskaerak baztertzen ditu.

Konektibitatea leheneratu ondoren, klusterera itzultzen da.

Ikus dezagun beste adibide bat non ilara nagusia Broker 3n dagoen.

Arroza. 24. Ilara nagusia Broker 3-n.

Orduan konektagarritasunaren galera bera gertatzen da. Broker 3 pausatzen da alde txikiagoan dagoelako. Beste aldean, nodoek Broker 3 erori dela ikusten dute, beraz, Brokers 1 eta 2 ispilu zaharragoa menperatzera igotzen da.

Arroza. 25. 2. artekarira igarotzea 3. artekaria erabilgarri ez badago.

Konektibitatea berrezartzen denean, Broker 3 klusterean sartuko da.

Arroza. 26. Klusterra funtzionamendu normalera itzuli da.

Hemen ulertzea garrantzitsua da koherentzia lortzen dugula, baina erabilgarritasuna ere lor dezakegula, bada Bezeroak arrakastaz transferituko ditugu atal gehienera. Egoera gehienetarako, pertsonalki Pausa Gutxiengoaren modua aukeratuko nuke, baina benetan kasu bakoitzaren araberakoa da.

Erabilgarritasuna ziurtatzeko, garrantzitsua da bezeroak ostalariarekin konektatzen direla ziurtatzea. Ikus ditzagun gure aukerak.

Bezeroaren Konektibitatea bermatzea

Hainbat aukera ditugu bezeroak nola bideratu klusterraren zati nagusira edo laneko nodoetara (nodo batek huts egin ondoren) konektibitatea galdu ondoren. Lehenik eta behin, gogoratu dezagun ilara zehatz bat nodo zehatz batean ostatatuta dagoela, baina bideratzea eta politikak nodo guztietan errepikatzen direla. Bezeroak edozein nodotara konekta daitezke, eta barne bideratzeak joan behar duten tokira bideratuko ditu. Baina nodo bat eteten denean, konexioak baztertzen ditu, beraz, bezeroak beste nodo batera konektatu behar dira. Nodoa erortzen bada, ezer gutxi egin dezake.

Gure aukerak:

• Klusterera nodoetatik igarotzen den karga-orekatzailea erabiliz atzitzen da eta bezeroak berriro konektatzen saiatzen da arrakasta arte. Nodo bat behera edo esekita badago, orduan nodo horretara konektatzeko saiakerak huts egingo du, baina ondorengo saiakerak beste zerbitzarietara joango dira (borondateka moduan). Hau egokia da epe laburreko konektagarritasuna galtzeko edo azkar berreskuratuko den zerbitzaria erorita.
• Sartu klusterera karga-orekatzaile baten bidez eta kendu esekita/huts egin duten nodoak zerrendatik detektatu bezain pronto. Hori azkar egiten badugu eta bezeroak konexioa berriro saiatzeko gai badira, etengabeko erabilgarritasuna lortuko dugu.
• Eman bezero bakoitzari nodo guztien zerrenda, eta bezeroak ausaz hautatzen du horietako bat konektatzean. Konektatzen saiatzean errore bat jasotzen badu, zerrendako hurrengo nodora mugitzen da konektatu arte.
• Kendu trafikoa huts egindako/esekitako nodo batetik DNS erabiliz. Hau TTL txiki bat erabiliz egiten da.

Findings

RabbitMQ clustering-ak bere abantailak eta desabantailak ditu. Desabantaila larrienak hauek dira:

• kluster batean sartzean, nodoek beren datuak baztertzen dituzte;
• sinkronizazioa blokeatzeak ilara erabilgarri ez izatea eragiten du.

Erabaki zail guztiak bi ezaugarri arkitektoniko horietatik datoz. RabbitMQ-k klusterra berriro elkartzen denean datuak gorde ditzake, orduan sinkronizazioa azkarragoa izango litzateke. Sinkronizazioa blokeatzeko gai izango balitz, hobe luke ilara handiak onartzen. Bi arazo hauek konpontzeak asko hobetuko luke RabbitMQ-ren errendimendua hutsegite-tolerantzia eta erabilgarritasun handiko mezularitza-teknologia gisa. Zalantza izango nuke RabbitMQ clustering-a gomendatzeko egoera hauetan:

• Sare fidagarria.
• Biltegiratze fidagarria.
• Ilara oso luzeak.

Erabilgarritasun handiko ezarpenei dagokienez, kontuan hartu honako hauek:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (Edo autoheal)
• mezu iraunkorrak
• ziurtatu bezeroak nodo aktibora konektatzen direla nodoren batek huts egiten duenean

Koherentzia lortzeko (datuen segurtasuna), kontuan hartu ezarpen hauek:

• Argitaletxearen baieztapenak eta eskuzko aitorpenak kontsumitzaileen aldetik
• ha-promote-on-failure=when-synced, argitaletxeek geroago berriro saia dezakete eta biltegiratze oso fidagarria baduzu! Bestela jarri =always.
• ha-sync-mode=automatic (baina ilara inaktibo handietarako eskuzko modua beharrezkoa izan daiteke; kontuan izan ere erabilgarritasunik ezak mezuak galtzea eragingo duen)
• Pausatu Gutxiengo modua
• mezu iraunkorrak

Oraindik ez ditugu akatsen tolerantziaren eta erabilgarritasun handiko gai guztiak landu; esate baterako, administrazio-prozedurak modu seguruan nola egin (adibidez, eguneratze iraunkorrak). Federazioaz eta Pala pluginaz ere hitz egin behar dugu.

Beste zerbait galdu badut, mesedez, jakinarazi.

Ikusi ere nire post, non RabbitMQ kluster batean hondamena egiten dudan Docker eta Blockade erabiliz, artikulu honetan deskribatutako mezu-galera agertoki batzuk probatzeko.

Serieko aurreko artikuluak:
1. zenbakia - habr.com/ru/company/itsumma/blog/416629
2. zenbakia - habr.com/ru/company/itsumma/blog/418389
3. zenbakia - habr.com/ru/company/itsumma/blog/437446

Iturria: www.habr.com