Kļūdu tolerance un augsta pieejamÄ«ba ir lielas tÄmas, tÄpÄc RabbitMQ un Kafka veltÄ«sim atseviŔķus rakstus. Å is raksts ir par RabbitMQ, bet nÄkamais ir par Kafku salÄ«dzinÄjumÄ ar RabbitMQ. Å is ir garÅ” raksts, tÄpÄc jÅ«tieties Ärti.
ApskatÄ«sim kļūdu tolerances, konsekvences un augstas pieejamÄ«bas (HA) stratÄÄ£ijas un katras stratÄÄ£ijas radÄ«tos kompromisus. RabbitMQ var darboties mezglu klasterÄ«, un pÄc tam tiek klasificÄta kÄ izplatÄ«ta sistÄma. RunÄjot par izplatÄ«tajÄm sistÄmÄm, mÄs bieži runÄjam par konsekvenci un pieejamÄ«bu.
Å ie jÄdzieni apraksta, kÄ sistÄma darbojas, ja tÄ neizdodas. TÄ«kla savienojuma kļūme, servera kļūme, cietÄ diska kļūme, servera Ä«slaicÄ«ga nepieejamÄ«ba atkritumu savÄkÅ”anas, pakeÅ”u zuduma vai tÄ«kla savienojuma palÄninÄjuma dÄļ. Tas viss var izraisÄ«t datu zudumu vai konfliktus. IzrÄdÄs, ka praktiski nav iespÄjams izveidot sistÄmu, kas bÅ«tu gan pilnÄ«gi konsekventa (nav datu zuduma, ne datu novirzes), gan pieejama (pieÅems lasÄ«Å”anu un rakstÄ«Å”anu) visiem kļūmju scenÄrijiem.
MÄs redzÄsim, ka konsekvence un pieejamÄ«ba atrodas pretÄjÄ spektra galos, un jums ir jÄizvÄlas optimizÄÅ”anas veids. LabÄ ziÅa ir tÄ, ka ar RabbitMQ Ŕī izvÄle ir iespÄjama. Jums ir Å”Ädas ānervuā sviras, lai novirzÄ«tu lÄ«dzsvaru uz lielÄku konsekvenci vai lielÄku pieejamÄ«bu.
ÄŖpaÅ”u uzmanÄ«bu pievÄrsÄ«sim tam, kuras konfigurÄcijas izraisa datu zudumu apstiprinÄto ierakstu dÄļ. Starp izdevÄjiem, brokeriem un patÄrÄtÄjiem pastÄv atbildÄ«bas Ä·Äde. Kad ziÅojums ir nosÅ«tÄ«ts brokerim, viÅa uzdevums ir nepazaudÄt ziÅojumu. Kad starpnieks apstiprina, ka izdevÄjs ir saÅÄmis ziÅojumu, mÄs negaidÄm, ka tas tiks pazaudÄts. TaÄu mÄs redzÄsim, ka tas faktiski var notikt atkarÄ«bÄ no jÅ«su starpnieka un izdevÄja konfigurÄcijas.
Viena mezgla elastīguma primitīvas
ElastÄ«ga rinda/marÅ”rutÄÅ”ana
RabbitMQ ir divu veidu rindas: izturÄ«gas un neizturÄ«gas. Visas rindas tiek saglabÄtas Mnesia datubÄzÄ. NoturÄ«gas rindas tiek atkÄrtoti reklamÄtas mezgla palaiÅ”anas laikÄ, un tÄdÄjÄdi tÄs izdzÄ«vo restartÄÅ”anas, sistÄmas avÄrijas vai servera avÄrijas (ja vien tiek saglabÄti dati). Tas nozÄ«mÄ, ka tik ilgi, kamÄr jÅ«s paziÅosiet, ka marÅ”rutÄÅ”ana (apmaiÅa) un rinda ir elastÄ«ga, rindas/marÅ”rutÄÅ”anas infrastruktÅ«ra atkal bÅ«s tieÅ”saistÄ.
NepastÄvÄ«gÄs rindas un marÅ”rutÄÅ”ana tiek noÅemta, kad mezgls tiek restartÄts.
PastÄvÄ«gi ziÅojumi
Tas, ka rinda ir izturÄ«ga, nenozÄ«mÄ, ka visi tÄs ziÅojumi izdzÄ«vos pÄc mezgla restartÄÅ”anas. Tikai ziÅojumi, kurus izdevÄjs iestatÄ«jis kÄ elastÄ«ga (noturÄ«gs). PastÄvÄ«gi ziÅojumi rada papildu slodzi brokerim, taÄu, ja ziÅojumu zudums ir nepieÅemams, tad nav citas iespÄjas.
RÄ«si. 1. IlgtspÄjas matrica
KlasterizÄcija ar rindu spoguļoÅ”anu
Lai pÄrdzÄ«votu brokera zaudÄjumu, mums ir nepiecieÅ”ama atlaiÅ”ana. MÄs varam apvienot vairÄkus RabbitMQ mezglus klasterÄ« un pÄc tam pievienot papildu dublÄÅ”anu, atkÄrtojot rindas starp vairÄkiem mezgliem. TÄdÄ veidÄ, ja viens mezgls neizdodas, mÄs nezaudÄjam datus un paliekam pieejami.
Rindas spoguļoŔana:
- viena galvenÄ rinda (master), kas saÅem visas rakstÄ«Å”anas un lasÄ«Å”anas komandas
- viens vai vairÄki spoguļi, kas saÅem visus ziÅojumus un metadatus no galvenÄs rindas. Å ie spoguļi nav paredzÄti mÄrogoÅ”anai, bet gan tikai atlaiÅ”anai.
Rīsi. 2. Rindas spoguļoŔana
SpoguļoÅ”anu nosaka atbilstoÅ”Ä politika. TajÄ varat atlasÄ«t replikÄcijas koeficientu un pat mezglus, uz kuriem jÄatrodas rindai. PiemÄri:
ha-mode: allha-mode: exactly, ha-params: 2(viens meistars un viens spogulis)ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2
IzdevÄja apstiprinÄjums
Lai nodroÅ”inÄtu konsekventu ierakstÄ«Å”anu, ir nepiecieÅ”ami izdevÄja apstiprinÄjumi. Bez tiem pastÄv risks, ka ziÅojumi tiks pazaudÄti. PÄc ziÅojuma ierakstÄ«Å”anas diskÄ izdevÄjam tiek nosÅ«tÄ«ts apstiprinÄjums. RabbitMQ ieraksta ziÅojumus diskÄ nevis pÄc saÅemÅ”anas, bet periodiski, vairÄku simtu milisekundu apgabalÄ. Kad rinda tiek atspoguļota, apstiprinÄjums tiek nosÅ«tÄ«ts tikai pÄc tam, kad visi spoguļi ir arÄ« ierakstÄ«juÅ”i savu ziÅojuma kopiju diskÄ. Tas nozÄ«mÄ, ka apstiprinÄjumu izmantoÅ”ana palielina latentumu, bet, ja datu droŔība ir svarÄ«ga, tad tie ir nepiecieÅ”ami.
KļūmjpÄrlÄces rinda
Kad brokeris pÄrtrauc darbu vai avarÄ, visi Ŕī mezgla rindu vadÄ«tÄji (galvenie) kopÄ ar to avarÄ. PÄc tam klasteris atlasa katra meistara vecÄko spoguli un reklamÄ to kÄ jauno meistaru.
RÄ«si. 3. VairÄkas spoguļattÄlu rindas un to politikas
Brokeris 3 nokrÄ«t. Å emiet vÄrÄ, ka Broker 2 rindas C spogulis tiek paaugstinÄts par galveno. Å emiet vÄrÄ arÄ« to, ka ir izveidots jauns spogulis rindai C pakalpojumÄ Broker 1. RabbitMQ vienmÄr mÄÄ£ina uzturÄt jÅ«su politikÄs norÄdÄ«to replikÄcijas faktoru.
Rīsi. 4. Broker 3 neizdodas, izraisot rindas C kļūmi
NÄkamais Broker 1 krÄ«t! Mums ir palicis tikai viens brokeris. Rindas B spogulis tiek paaugstinÄts par galveno.
Att. 5
MÄs esam atgriezuÅ”i Broker 1. NeatkarÄ«gi no tÄ, cik labi dati saglabÄjas pÄc starpnieka zaudÄÅ”anas un atkopÅ”anas, restartÄjot tiek atmesti visi spoguļattÄlu rindas ziÅojumi. Tas ir svarÄ«gi atzÄ«mÄt, jo tam bÅ«s sekas. DrÄ«zumÄ aplÅ«kosim Ŕīs sekas. TÄtad Broker 1 tagad atkal ir klastera dalÄ«bnieks, un klasteris mÄÄ£ina ievÄrot politikas un tÄpÄc izveido spoguļus Broker 1.
Å ajÄ gadÄ«jumÄ Broker 1 zaudÄÅ”ana bija pilnÄ«ga, tÄpat kÄ dati, tÄpÄc neatspoguļotÄ rinda B tika pilnÄ«bÄ zaudÄta.
RÄ«si. 6. Brokeris 1 atgriežas darbÄ
Broker 3 atkal ir tieÅ”saistÄ, tÄpÄc rindas A un B saÅem atpakaļ tajÄ izveidotos spoguļus, lai izpildÄ«tu viÅu HA politikas. Bet tagad visas galvenÄs rindas ir vienÄ mezglÄ! Tas nav ideÄli, vienmÄrÄ«gs sadalÄ«jums starp mezgliem ir labÄks. DiemžÄl Å”eit nav daudz iespÄju, kÄ lÄ«dzsvarot meistarus. MÄs atgriezÄ«simies pie Ŕīs problÄmas vÄlÄk, jo mums vispirms ir jÄaplÅ«ko rindu sinhronizÄcija.
RÄ«si. 7. Brokeris 3 atgriežas darbÄ. Visas galvenÄs rindas vienÄ mezglÄ!
TÄpÄc tagad jums vajadzÄtu bÅ«t priekÅ”statam par to, kÄ spoguļi nodroÅ”ina atlaiÅ”anu un kļūdu toleranci. Tas nodroÅ”ina pieejamÄ«bu viena mezgla atteices gadÄ«jumÄ un aizsargÄ pret datu zudumu. Bet mÄs vÄl neesam pabeiguÅ”i, jo patiesÄ«bÄ tas ir daudz sarežģītÄk.
SinhronizÄcija
Veidojot jaunu spoguli, visi jaunie ziÅojumi vienmÄr tiks replicÄti Å”ajÄ spogulÄ« un citos. Kas attiecas uz esoÅ”ajiem datiem galvenajÄ rindÄ, mÄs varam tos replicÄt uz jaunu spoguli, kas kļūst par pilnÄ«gu galvenÄ kopiju. MÄs varam arÄ« izvÄlÄties nedublÄt esoÅ”os ziÅojumus un ļaut galvenajai rindai un jaunajam spoguļam saplÅ«st laikÄ, jaunajiem ziÅojumiem nonÄkot beigÄs un esoÅ”ajiem ziÅojumiem atstÄjot galvenÄs rindas galvgali.
Å Ä« sinhronizÄcija tiek veikta automÄtiski vai manuÄli, un tÄ tiek pÄrvaldÄ«ta, izmantojot rindas politiku. ApskatÄ«sim piemÄru.
Mums ir divas spoguļrindas. Rinda A tiek sinhronizÄta automÄtiski, un rinda B tiek sinhronizÄta manuÄli. AbÄs rindÄs ir desmit ziÅojumi.
RÄ«si. 8. Divas rindas ar dažÄdiem sinhronizÄcijas režīmiem
Tagad mÄs zaudÄjam Broker 3.
RÄ«si. 9. Brokeris 3 krita
Brokeris 3 atgriežas darbÄ. Klasteris izveido spoguli katrai rindai jaunajÄ mezglÄ un automÄtiski sinhronizÄ jauno rindu A ar galveno. TomÄr jaunÄs rindas B spogulis paliek tukÅ”s. TÄdÄ veidÄ mums ir pilnÄ«ga dublÄÅ”ana A rindÄ un tikai viens spogulis esoÅ”ajiem rindas B ziÅojumiem.
RÄ«si. 10. Jaunais rindas A spogulis saÅem visus esoÅ”os ziÅojumus, bet jaunais rindas B spogulis nesaÅem.
AbÄs rindÄs tiek saÅemti vÄl desmit ziÅojumi. PÄc tam brokeris 2 avarÄ, un rinda A atgriežas pie vecÄkÄ spoguļa, kas atrodas Broker 1. Ja tas neizdodas, dati netiek zaudÄti. RindÄ B ir divdesmit ziÅojumi galvenajÄ un tikai desmit ziÅojumi spogulÄ«, jo Ŕī rinda nekad nedublÄ sÄkotnÄjos desmit ziÅojumus.
RÄ«si. 11. Rinda A atgriežas pie Broker 1, nezaudÄjot ziÅojumus
AbÄs rindÄs tiek saÅemti vÄl desmit ziÅojumi. Tagad Broker 1 avarÄ. Rinda A viegli pÄrslÄdzas uz spoguli, nezaudÄjot ziÅojumus. TomÄr rindai B ir problÄmas. Å ajÄ brÄ«dÄ« mÄs varam optimizÄt pieejamÄ«bu vai konsekvenci.
Ja vÄlamies optimizÄt pieejamÄ«bu, tad politika ha-promote-on-failure jÄiestata iekÅ”Ä vienmÄr. Å Ä« ir noklusÄjuma vÄrtÄ«ba, tÄpÄc jÅ«s varat vienkÄrÅ”i nenorÄdÄ«t politiku vispÄr. Å ajÄ gadÄ«jumÄ mÄs bÅ«tÄ«bÄ pieļaujam kļūmes nesinhronizÄtos spoguļos. TÄdÄjÄdi ziÅojumi tiks zaudÄti, bet rinda paliks lasÄma un rakstÄma.
RÄ«si. 12. Rinda A tiek atgriezta atpakaļ uz Broker 3, nezaudÄjot ziÅojumus. Rinda B atgriežas pie Broker 3 ar desmit zaudÄtiem ziÅojumiem
Varam arÄ« uzstÄdÄ«t ha-promote-on-failure nozÄ«mÄ when-synced. Å ajÄ gadÄ«jumÄ tÄ vietÄ, lai atgrieztos pie spoguļa, rinda gaidÄ«s, lÄ«dz Broker 1 ar saviem datiem atgriezÄ«sies tieÅ”saistes režīmÄ. PÄc atgrieÅ”anÄs galvenÄ rinda atkal ir pieejama Broker 1 bez datu zudumiem. PieejamÄ«ba tiek upurÄta datu droŔībai. Bet tas ir riskants režīms, kas var pat izraisÄ«t pilnÄ«gu datu zudumu, ko mÄs tuvÄkajÄ laikÄ apskatÄ«sim.
RÄ«si. 13. Rinda B paliek nepieejama pÄc 1. brokera zaudÄÅ”anas
JÅ«s varat jautÄt: "Vai labÄk nekad neizmantot automÄtisko sinhronizÄciju?" Atbilde ir tÄda, ka sinhronizÄcija ir bloÄ·ÄÅ”anas darbÄ«ba. SinhronizÄcijas laikÄ galvenÄ rinda nevar veikt nekÄdas lasÄ«Å”anas vai rakstÄ«Å”anas darbÄ«bas!
ApskatÄ«sim piemÄru. Tagad mums ir ļoti garas rindas. KÄ viÅi var izaugt lÄ«dz tÄdam izmÄram? VairÄku iemeslu dÄļ:
- Rindas netiek aktīvi izmantotas
- TÄs ir Ätrgaitas rindas, un Å”obrÄ«d patÄrÄtÄji ir lÄni
- TÄs ir Ätrgaitas rindas, ir radusies kļūme, un patÄrÄtÄji to panÄk
RÄ«si. 14. Divas lielas rindas ar dažÄdiem sinhronizÄcijas režīmiem
Tagad Broker 3 krīt.
RÄ«si. 15. Brokeris 3 krÄ«t, atstÄjot katrÄ rindÄ vienu meistaru un spoguli
Broker 3 atgriežas tieÅ”saistÄ un tiek izveidoti jauni spoguļi. GalvenÄ rinda A sÄk replicÄt esoÅ”os ziÅojumus jaunajÄ spogulÄ«, un Å”ajÄ laikÄ rinda nav pieejama. Datu pavairoÅ”ana aizÅem divas stundas, kÄ rezultÄtÄ Å”ai rindai ir divas stundas dÄ«kstÄves!
TomÄr rinda B ir pieejama visu periodu. ViÅa upurÄja dažas atlaiÅ”anas pieejamÄ«bas dÄļ.
RÄ«si. 16. SinhronizÄcijas laikÄ rinda paliek nepieejama
PÄc divÄm stundÄm kļūst pieejama arÄ« rinda A, un tÄ var atkal sÄkt lasÄ«t un rakstÄ«t.
AtjauninÄjumi
Å Ä« bloÄ·ÄjoÅ”Ä darbÄ«ba sinhronizÄcijas laikÄ apgrÅ«tina klasteru atjauninÄÅ”anu ar ļoti lielÄm rindÄm. KÄdÄ brÄ«dÄ« galvenais mezgls ir jÄrestartÄ, kas nozÄ«mÄ vai nu pÄrslÄgÅ”anos uz spoguli, vai rindas atspÄjoÅ”anu, kamÄr serveris tiek jauninÄts. Ja izvÄlÄsimies pÄreju, mÄs zaudÄsim ziÅojumus, ja spoguļi netiks sinhronizÄti. PÄc noklusÄjuma brokera darbÄ«bas pÄrtraukuma laikÄ kļūmjpÄrlÄce uz nesinhronizÄtu spoguli netiek veikta. Tas nozÄ«mÄ, ka tiklÄ«dz brokeris atgriežas, mÄs nezaudÄjam nevienu ziÅojumu, vienÄ«gais kaitÄjums bija vienkÄrÅ”a rinda. UzvedÄ«bas noteikumus, kad brokeris ir atvienots, nosaka politika ha-promote-on-shutdown. Varat iestatÄ«t vienu no divÄm vÄrtÄ«bÄm:
always= ir iespÄjota pÄreja uz nesinhronizÄtiem spoguļiemwhen-synced= pÄreja tikai uz sinhronizÄtu spoguli, pretÄjÄ gadÄ«jumÄ rinda kļūst nelasÄma un neierakstÄma. Rinda atgriežas apkalpoÅ”anÄ, tiklÄ«dz atgriežas brokeris
TÄ vai citÄdi, ar lielÄm rindÄm ir jÄizvÄlas starp datu zudumu vai nepieejamÄ«bu.
Kad pieejamība uzlabo datu droŔību
Pirms lÄmuma pieÅemÅ”anas jÄÅem vÄrÄ vÄl viens sarežģījums. Lai gan automÄtiskÄ sinhronizÄcija ir labÄka atlaiÅ”anai, kÄ tÄ ietekmÄ datu droŔību? Protams, ar labÄku dublÄÅ”anu RabbitMQ ir mazÄka iespÄja zaudÄt esoÅ”os ziÅojumus, bet kÄ ir ar jaunajiem ziÅojumiem no izdevÄjiem?
Å eit jums jÄÅem vÄrÄ sekojoÅ”ais:
- Vai izdevÄjs varÄtu vienkÄrÅ”i atgriezt kļūdu un likt augÅ”Äjam pakalpojumam vai lietotÄjam vÄlÄk mÄÄ£inÄt vÄlreiz?
- Vai izdevÄjs var saglabÄt ziÅojumu lokÄli vai datu bÄzÄ, lai vÄlÄk mÄÄ£inÄtu vÄlreiz?
Ja izdevÄjs var tikai atmest ziÅojumu, tad faktiski pieejamÄ«bas uzlaboÅ”ana uzlabo arÄ« datu droŔību.
TÄdÄjÄdi ir jÄmeklÄ lÄ«dzsvars, un risinÄjums ir atkarÄ«gs no konkrÄtÄs situÄcijas.
ProblÄmas ar ha-promote-on-failure=when-synced
Ideja ha-promote-on-failure= kad-sinhronizÄts ir tas, ka mÄs novÄrÅ”am pÄreju uz nesinhronizÄtu spoguli un tÄdÄjÄdi izvairÄmies no datu zuduma. Rinda paliek nelasÄma vai rakstÄma. TÄ vietÄ mÄs cenÅ”amies atgÅ«t avarÄjuÅ”o brokeri ar neskartiem datiem, lai tas varÄtu atsÄkt darboties kÄ galvenais, nezaudÄjot datus.
Bet (un tas ir liels, bet), ja brokeris ir pazaudÄjis savus datus, tad mums ir liela problÄma: rinda ir zaudÄta! Visi dati ir pazuduÅ”i! Pat ja jums ir spoguļi, kas pÄrsvarÄ sasniedz galveno rindu, arÄ« Å”ie spoguļi tiek izmesti.
Lai atkÄrtoti pievienotu mezglu ar tÄdu paÅ”u nosaukumu, mÄs sakÄm klasterim aizmirst pazaudÄto mezglu (ar komandu rabbitmqctl aizmirst_kopas_node) un sÄciet jaunu brokeri ar tÄdu paÅ”u saimniekdatora nosaukumu. KamÄr klasteris atceras zaudÄto mezglu, tas atceras veco rindu un nesinhronizÄtos spoguļus. Kad klasterim tiek likts aizmirst bÄreÅu mezglu, tiek aizmirsta arÄ« Ŕī rinda. Tagad mums tas ir atkÄrtoti jÄdeklarÄ. MÄs zaudÄjÄm visus datus, lai gan mums bija spoguļi ar daļÄju datu kopu. LabÄk bÅ«tu pÄriet uz nesinhronizÄtu spoguli!
TÄpÄc manuÄla sinhronizÄcija (un neveiksme sinhronizÄcijÄ) kombinÄcijÄ ar ha-promote-on-failure=when-synced, manuprÄt, diezgan riskanti. Dokumenti saka, ka Ŕī opcija pastÄv datu droŔībai, taÄu tÄ ir abpusÄji griezÄ«gs nazis.
GalvenÄ lÄ«dzsvara atjaunoÅ”ana
KÄ solÄ«ts, mÄs atgriežamies pie problÄmas, kas saistÄ«ta ar visu meistaru uzkrÄÅ”anos vienÄ vai vairÄkos mezglos. Tas var notikt pat mainÄ«ga klastera atjauninÄÅ”anas rezultÄtÄ. TrÄ«s mezglu klasterÄ« visas galvenÄs rindas tiks uzkrÄtas vienÄ vai divos mezglos.
Meistaru lÄ«dzsvara atjaunoÅ”ana var bÅ«t problemÄtiska divu iemeslu dÄļ:
- Nav labu instrumentu, lai veiktu līdzsvaroŔanu
- Rindas sinhronizÄcija
LÄ«dzsvara atjaunoÅ”anai ir treÅ”Ä puse , kas oficiÄli netiek atbalstÄ«ts. Par treÅ”o puÅ”u spraudÅiem RabbitMQ rokasgrÄmatÄ : āSpraudnis nodroÅ”ina dažus papildu konfigurÄcijas un ziÅoÅ”anas rÄ«kus, taÄu RabbitMQ komanda to neatbalsta vai nepÄrbauda. Izmantojiet uz savu risku."
Ir vÄl viens triks, kÄ pÄrvietot galveno rindu, izmantojot HA politikas. RokasgrÄmatÄ minÄts priekÅ” Ŕī. Tas darbojas Å”Ädi:
- NoÅem visus spoguļus, izmantojot pagaidu politiku, kurai ir augstÄka prioritÄte nekÄ esoÅ”ajai HA politikai.
- Maina HA pagaidu politiku, lai izmantotu mezgla režīmu, norÄdot mezglu, uz kuru jÄpÄrsÅ«ta galvenÄ rinda.
- SinhronizÄ push migrÄcijas rindu.
- Kad migrÄÅ”ana ir pabeigta, pagaidu politika tiek dzÄsta. SÄkotnÄjÄ HA politika stÄjas spÄkÄ un tiek izveidots nepiecieÅ”amais spoguļu skaits.
NegatÄ«vÄ puse ir tÄda, ka Ŕī pieeja var nedarboties, ja jums ir lielas rindas vai stingras atlaiÅ”anas prasÄ«bas.
Tagad redzÄsim, kÄ RabbitMQ klasteri darbojas ar tÄ«kla nodalÄ«jumiem.
Savienojuma zudums
SadalÄ«tÄs sistÄmas mezgli ir savienoti ar tÄ«kla saitÄm, un tÄ«kla saites var un tiks atvienotas. PÄrtraukumu biežums ir atkarÄ«gs no vietÄjÄs infrastruktÅ«ras vai izvÄlÄtÄ mÄkoÅa uzticamÄ«bas. JebkurÄ gadÄ«jumÄ sadalÄ«tajÄm sistÄmÄm ir jÄspÄj ar tÄm tikt galÄ. Atkal mums ir izvÄle starp pieejamÄ«bu un konsekvenci, un atkal labÄ ziÅa ir tÄ, ka RabbitMQ nodroÅ”ina abas iespÄjas (tikai ne vienlaikus).
Izmantojot RabbitMQ, mums ir divas galvenÄs iespÄjas:
- Atļaut loÄ£isko dalÄ«jumu (smadzeÅu sadalÄ«Å”ana). Tas nodroÅ”ina pieejamÄ«bu, bet var izraisÄ«t datu zudumu.
- AtspÄjot loÄ£isko atdalÄ«Å”anu. Var izraisÄ«t Ä«slaicÄ«gu pieejamÄ«bas zudumu atkarÄ«bÄ no tÄ, kÄ klienti savienojas ar kopu. Var izraisÄ«t arÄ« pilnÄ«gu nepieejamÄ«bu divu mezglu klasterÄ«.
Bet kas ir loÄ£iskÄ atdalÄ«Å”ana? Tas notiek, kad klasteris sadalÄs divÄs daļÄs tÄ«kla savienojumu zuduma dÄļ. KatrÄ pusÄ spoguļi tiek paaugstinÄti par meistaru, lai galu galÄ vienÄ rindÄ bÅ«tu vairÄki meistari.
RÄ«si. 17. GalvenÄ rinda un divi spoguļi, katrs atseviÅ”Ä·Ä mezglÄ. Tad notiek tÄ«kla kļūme un viens spogulis tiek atvienots. AtdalÄ«tais mezgls redz, ka pÄrÄjie divi ir nokrituÅ”i, un reklamÄ savus spoguļus kapteinim. Tagad mums ir divas galvenÄs rindas, gan rakstÄmÄs, gan lasÄmÄs.
Ja izdevÄji nosÅ«ta datus abiem galvenajiem, mÄs iegÅ«stam divas atŔķirÄ«gas rindas kopijas.
RabbitMQ dažÄdie režīmi nodroÅ”ina pieejamÄ«bu vai konsekvenci.
IgnorÄÅ”anas režīms (noklusÄjums)
Å is režīms nodroÅ”ina pieejamÄ«bu. PÄc savienojuma zaudÄÅ”anas notiek loÄ£iska atdalÄ«Å”ana. PÄc savienojuma atjaunoÅ”anas administratoram ir jÄizlemj, kuram nodalÄ«jumam pieŔķirt prioritÄti. ZaudÄtÄja puse tiks restartÄta, un visi tajÄ pusÄ uzkrÄtie dati tiks zaudÄti.
RÄ«si. 18. TrÄ«s izdevÄji ir saistÄ«ti ar trim brokeriem. IekÅ”Äji klasteris visus pieprasÄ«jumus novirza uz galveno rindu pakalpojumÄ Broker 2.
Tagad mÄs zaudÄjam Brokeri 3. ViÅÅ” redz, ka citi brokeri ir atkrituÅ”i un paaugstina savu spoguli par meistaru. TÄdÄ veidÄ notiek loÄ£iska atdalÄ«Å”ana.
RÄ«si. 19.LoÄ£iskais dalÄ«jums (split-brain). Ieraksti atrodas divÄs galvenajÄs rindÄs, un abas kopijas atŔķiras.
SavienojamÄ«ba tiek atjaunota, bet loÄ£iskÄ atdalÄ«Å”ana paliek. Administratoram manuÄli jÄizvÄlas zaudÄtÄja puse. TÄlÄk norÄdÄ«tajÄ gadÄ«jumÄ administrators atsÄknÄ Broker 3. Visi ziÅojumi, kurus viÅam neizdevÄs pÄrsÅ«tÄ«t, tiek zaudÄti.
RÄ«si. 20. Administrators atspÄjo Broker 3.
RÄ«si. 21. Administrators palaiž brokeri 3 un tas pievienojas klasterim, zaudÄjot visus tur atstÄtos ziÅojumus.
Savienojuma zuduma laikÄ un pÄc tÄ atjaunoÅ”anas klasteris un Ŕī rinda bija pieejama lasÄ«Å”anai un rakstÄ«Å”anai.
AutomÄtiskÄs dziedinÄÅ”anas režīms
Darbojas lÄ«dzÄ«gi kÄ IgnorÄt režīms, izÅemot to, ka pats klasteris pÄc savienojuma sadalÄ«Å”anas un atjaunoÅ”anas automÄtiski izvÄlas zaudÄto pusi. ZaudÄtÄja puse atgriežas klasterÄ« tukÅ”a, un rinda zaudÄ visus ziÅojumus, kas tika nosÅ«tÄ«ti tikai uz Å”o pusi.
PauzÄjiet mazÄkuma režīmu
Ja mÄs nevÄlamies atļaut loÄ£isko sadalÄ«Å”anu, mÅ«su vienÄ«gÄ iespÄja ir atmest lasÄ«Å”anu un rakstÄ«Å”anu mazÄkajÄ pusÄ pÄc klastera nodalÄ«juma. Kad brokeris redz, ka tas atrodas mazÄkajÄ pusÄ, tas aptur darbu, tas ir, slÄdz visus esoÅ”os savienojumus un atsakÄs no jauniem. Reizi sekundÄ tas pÄrbauda savienojuma atjaunoÅ”anu. Kad savienojums ir atjaunots, tas atsÄk darbÄ«bu un pievienojas klasterim.
RÄ«si. 22. TrÄ«s izdevÄji ir saistÄ«ti ar trim brokeriem. IekÅ”Äji klasteris visus pieprasÄ«jumus novirza uz galveno rindu pakalpojumÄ Broker 2.
PÄc tam 1. un 2. brokeris atdalÄs no brokera 3. TÄ vietÄ, lai reklamÄtu savu spoguli par galveno, brokeris 3 aptur darbÄ«bu un kļūst nepieejams.
Rīsi. 23. Broker 3 aptur, atvieno visus klientus un noraida savienojuma pieprasījumus.
Kad savienojums ir atjaunots, tas atgriežas klasterī.
ApskatÄ«sim citu piemÄru, kur galvenÄ rinda atrodas brokerÄ« 3.
RÄ«si. 24. GalvenÄ rinda brokerÄ 3.
Tad notiek tÄds pats savienojuma zudums. Broker 3 pauzes, jo tas atrodas mazÄkajÄ pusÄ. No otras puses mezgli redz, ka Broker 3 ir nokritis, tÄpÄc vecÄkais spogulis no Brokers 1 un 2 tiek paaugstinÄts par meistaru.
RÄ«si. 25. PÄreja uz Broker 2, ja Broker 3 nav pieejams.
Kad savienojums ir atjaunots, brokeris 3 pievienosies klasterim.
RÄ«si. 26. Klasteris ir atgriezies normÄlÄ režīmÄ.
Å eit ir svarÄ«gi saprast, ka mÄs iegÅ«stam konsekvenci, taÄu varam arÄ« nodroÅ”inÄt pieejamÄ«bu, ja MÄs veiksmÄ«gi pÄrvedÄ«sim klientus uz lielÄko daļu sadaļas. LielÄkajai daļai situÄciju es personÄ«gi izvÄlÄtos Pause Minority režīmu, taÄu tas tieÅ”Äm ir atkarÄ«gs no konkrÄtÄ gadÄ«juma.
Lai nodroÅ”inÄtu pieejamÄ«bu, ir svarÄ«gi nodroÅ”inÄt, lai klienti veiksmÄ«gi izveidotu savienojumu ar resursdatoru. ApskatÄ«sim mÅ«su iespÄjas.
Klientu savienojamÄ«bas nodroÅ”inÄÅ”ana
Mums ir vairÄkas iespÄjas, kÄ novirzÄ«t klientus uz galveno klastera daļu vai darba mezgliem (pÄc viena mezgla kļūmes) pÄc savienojuma zaudÄÅ”anas. PirmkÄrt, atcerÄsimies, ka noteikta rinda ir mitinÄta noteiktÄ mezglÄ, bet marÅ”rutÄÅ”ana un politikas tiek replicÄtas visos mezglos. Klienti var izveidot savienojumu ar jebkuru mezglu, un iekÅ”ÄjÄ marÅ”rutÄÅ”ana viÅus novirzÄ«s tur, kur viÅiem ir jÄiet. Bet, kad mezgls ir apturÄts, tas noraida savienojumus, tÄpÄc klientiem ir jÄpievienojas citam mezglam. Ja mezgls nokrÄ«t, viÅÅ” vispÄr maz var darÄ«t.
MÅ«su iespÄjas:
- Klasterim var piekļūt, izmantojot slodzes lÄ«dzsvarotÄju, kas vienkÄrÅ”i pÄriet cauri mezgliem, un klienti mÄÄ£ina atkÄrtoti izveidot savienojumu, lÄ«dz tas ir izdevies. Ja mezgls nedarbojas vai ir apturÄts, mÄÄ£inÄjumi izveidot savienojumu ar Å”o mezglu neizdosies, bet nÄkamie mÄÄ£inÄjumi tiks novirzÄ«ti uz citiem serveriem (apkÄrtÄjÄ veidÄ). Tas ir piemÄrots Ä«stermiÅa savienojuma zuduma vai nolaistu servera gadÄ«jumÄ, kas tiks Ätri atjaunots.
- Piekļūstiet klasterim, izmantojot slodzes lÄ«dzsvarotÄju, un noÅemiet apturÄtos/neizdevuÅ”os mezglus no saraksta, tiklÄ«dz tie tiek atklÄti. Ja mÄs to darÄ«sim Ätri un klienti varÄs atkÄrtoti mÄÄ£inÄt izveidot savienojumu, mÄs sasniegsim pastÄvÄ«gu pieejamÄ«bu.
- Sniedziet katram klientam visu mezglu sarakstu, un klients nejauÅ”i izvÄlas vienu no tiem savienojuma laikÄ. Ja, mÄÄ£inot izveidot savienojumu, tiek parÄdÄ«ts kļūdas ziÅojums, tas pÄriet uz nÄkamo mezglu sarakstÄ, lÄ«dz tiek izveidots savienojums.
- NoÅemiet trafiku no neveiksmÄ«ga/apturÄta mezgla, izmantojot DNS. Tas tiek darÄ«ts, izmantojot nelielu TTL.
Atzinumi
RabbitMQ klasterÄÅ”anai ir savas priekÅ”rocÄ«bas un trÅ«kumi. NopietnÄkie trÅ«kumi ir Å”Ädi:
- pievienojoties klasterim, mezgli izmet savus datus;
- bloÄ·Äjot sinhronizÄciju, rinda kļūst nepieejama.
Visi sarežģītie lÄmumi izriet no Ŕīm divÄm arhitektÅ«ras iezÄ«mÄm. Ja RabbitMQ varÄtu saglabÄt datus, kad klasteris tiek atkÄrtoti pievienots, sinhronizÄcija bÅ«tu ÄtrÄka. Ja tas varÄtu nebloÄ·Ät sinhronizÄciju, tas labÄk atbalstÄ«tu lielas rindas. Å o divu problÄmu novÄrÅ”ana ievÄrojami uzlabotu RabbitMQ kÄ kļūmju izturÄ«gas un ļoti pieejamas ziÅojumapmaiÅas tehnoloÄ£ijas veiktspÄju. Es vilcinÄÅ”os ieteikt RabbitMQ ar klasterizÄciju Å”ÄdÄs situÄcijÄs:
- Neuzticams tīkls.
- Neuzticama krÄtuve.
- Ļoti garas rindas.
RunÄjot par augstas pieejamÄ«bas iestatÄ«jumiem, Åemiet vÄrÄ tÄlÄk minÄto.
ha-promote-on-failure=alwaysha-sync-mode=manualcluster_partition_handling=ignore(Vaiautoheal)- pastÄvÄ«gas ziÅas
- nodroÅ”inÄt klientu savienojumu ar aktÄ«vo mezglu, ja kÄds mezgls neizdodas
Lai nodroÅ”inÄtu konsekvenci (datu droŔību), Åemiet vÄrÄ Å”Ädus iestatÄ«jumus:
- IzdevÄjs apstiprina un manuÄli apstiprina patÄrÄtÄju puses
ha-promote-on-failure=when-synced, ja izdevÄji vÄlÄk var mÄÄ£inÄt vÄlreiz un ja jums ir ļoti uzticama krÄtuve! CitÄdi likt=always.ha-sync-mode=automatic(bet lielÄm neaktÄ«vÄm rindÄm var bÅ«t nepiecieÅ”ams manuÄlais režīms; arÄ« apsveriet, vai nepieejamÄ«bas dÄļ ziÅojumi netiks pazaudÄti)- ApturÄt mazÄkuma režīmu
- pastÄvÄ«gas ziÅas
MÄs vÄl neesam aptvÄruÅ”i visus defektu tolerances un augstas pieejamÄ«bas jautÄjumus; piemÄram, kÄ droÅ”i veikt administratÄ«vÄs procedÅ«ras (piemÄram, slÄ«doÅ”os atjauninÄjumus). Mums ir arÄ« jÄrunÄ par federÄciju un Shovel spraudni.
Ja esmu vÄl kaut ko palaidis garÄm, lÅ«dzu, dariet man zinÄmu.
SkatÄ«t arÄ« manu , kur es veicu haosu RabbitMQ klasterÄ«, izmantojot Docker un Blockade, lai pÄrbaudÄ«tu dažus Å”ajÄ rakstÄ aprakstÄ«tos ziÅojumu zaudÄÅ”anas scenÄrijus.
IepriekÅ”Äjie raksti sÄrijÄ:
Nr. 1 -
Nr. 2 -
Nr. 3 -
Avots: www.habr.com