Hello, Habr! Ipinakita ko sa iyong pansin ang isang pagsasalin ng artikulo ni Andrew Beekhof.
Mas gusto ng maraming tao ang dalawang-node na cluster dahil mukhang mas simple ang mga ito sa konsepto at 33% din na mas mura kaysa sa kanilang mga three-node na katapat. Bagama't medyo posible na pagsamahin ang isang mahusay na kumpol ng dalawang node, sa karamihan ng mga kaso, dahil sa hindi isinasaalang-alang na mga sitwasyon, ang ganitong pagsasaayos ay lilikha ng maraming hindi halatang mga problema.
Ang unang hakbang sa paglikha ng anumang sistemang may mataas na kakayahang magamit ay ang paghahanap at pagtatangka na alisin ang mga indibidwal na punto ng kabiguan, kadalasang dinadaglat bilang SPoF (isang punto ng kabiguan).
Dapat tandaan na imposibleng maalis ang lahat ng posibleng panganib ng downtime sa anumang sistema. Nagmumula ito sa katotohanan na ang isang tipikal na depensa laban sa panganib ay ang pagpapakilala ng ilang kalabisan, na humahantong sa pagtaas ng pagiging kumplikado ng system at ang paglitaw ng mga bagong punto ng pagkabigo. Samakatuwid, una kaming gumawa ng isang kompromiso at tumuon sa mga kaganapan na nauugnay sa mga indibidwal na punto ng kabiguan, at hindi sa mga kadena ng mga nauugnay at, samakatuwid, lalong hindi gaanong posibleng mga kaganapan.
Dahil sa mga trade-off, hindi lamang namin hinahanap ang SPoF, kundi pati na rin ang pagbabalanse ng mga panganib at kahihinatnan, bilang resulta kung saan ang konklusyon ng kung ano ang kritikal at kung ano ang hindi ay maaaring mag-iba para sa bawat deployment.
Hindi lahat ay nangangailangan ng mga alternatibong tagapagtustos ng kuryente na may mga independiyenteng linya ng kuryente. Bagama't nagbunga ang paranoia para sa hindi bababa sa isang customer nang makita ng kanilang pagsubaybay ang isang may sira na transpormer. Ang customer ay tumawag sa telepono na sinusubukang alertuhan ang power company hanggang sa sumabog ang sira na transformer.
Ang natural na panimulang punto ay ang pagkakaroon ng higit sa isang node sa system. Gayunpaman, bago mailipat ng system ang mga serbisyo sa nabubuhay na node pagkatapos ng kabiguan, sa pangkalahatan ay kailangan nitong tiyakin na ang mga serbisyong inililipat ay hindi aktibo sa ibang lugar.
Walang downside sa isang two-node cluster kung ang isang pagkabigo ay nagreresulta sa parehong mga node na naghahatid ng parehong static na website. Gayunpaman, magbabago ang mga bagay kung ang resulta ay ang parehong partido ay independiyenteng namamahala sa isang nakabahaging pila ng trabaho o nagbibigay ng hindi koordinadong pag-access sa pagsulat sa isang kinopya na database o nakabahaging file system.
Samakatuwid, upang maiwasan ang katiwalian ng data bilang resulta ng isang pagkabigo ng node - umaasa kami sa isang bagay na tinatawag "dissociation" (bakod).
Ang prinsipyo ng dissociation
Sa gitna ng prinsipyo ng dissociation ay ang tanong: maaari bang maging sanhi ng katiwalian ng data ang isang nakikipagkumpitensyang node? Kung sakaling ang data corruption ay malamang na senaryo, ang isang magandang solusyon ay ang paghiwalayin ang node mula sa parehong mga papasok na kahilingan at patuloy na storage. Ang pinakakaraniwang diskarte sa pag-disassociation ay ang pagdiskonekta sa mga maling node.
Mayroong dalawang kategorya ng mga pamamaraan ng dissociation, na tatawagin ko tuwid ΠΈ hindi direkta, ngunit pareho silang matatawag aktibo ΠΈ pasibo. Ang mga direktang pamamaraan ay kinabibilangan ng mga aksyon sa bahagi ng mga nakaligtas na kapantay, tulad ng pakikipag-ugnayan sa isang IPMI (Intelligent Platform Management Interface) o iLO (isang mekanismo para sa pamamahala ng mga server sa kawalan ng pisikal na pag-access sa kanila) na device, habang ang mga hindi direktang pamamaraan ay umaasa sa nabigong node upang kahit papaano ay makilala na ito ay nasa isang hindi malusog na estado (o hindi bababa sa pumipigil sa ibang mga miyembro mula sa pagbawi) at signal tungkol sa pangangailangang idiskonekta ang nabigong node.
Tumutulong ang korum kapag gumagamit ng parehong direkta at hindi direktang mga pamamaraan.
Direktang paghihiwalay
Sa kaso ng direktang paghihiwalay, maaari naming gamitin ang quorum upang maiwasan ang mga karera ng dissociation kung sakaling magkaroon ng pagkabigo sa network.
Sa konsepto ng quorum, may sapat na impormasyon sa system (kahit na hindi kumokonekta sa mga kapantay nito) para awtomatikong malaman ng mga node kung dapat nilang simulan ang paghihiwalay at/o pagbawi.
Kung walang korum, ang magkabilang panig ng isang network divide ay wastong ipagpalagay na ang kabilang panig ay patay na at magsisikap na ihiwalay ang isa. Sa pinakamasamang kaso, pinamamahalaan ng parehong partido na isara ang buong cluster. Ang isang alternatibong senaryo ay isang deathmatch, isang walang katapusang loop ng mga node na umuusbong, hindi nakikita ang kanilang mga kapantay, nire-reboot ang mga ito, at sinisimulan ang pagbawi upang mag-reboot lamang kapag ang kanilang mga kapantay ay sumusunod sa parehong lohika.
Ang problema sa paghihiwalay ay ang pinakamadalas na ginagamit na mga device ay nagiging hindi available dahil sa parehong mga kaganapan sa pagkabigo na gusto naming i-target para sa pagbawi. Karamihan sa mga IPMI at iLO card ay naka-install sa mga host na sinusubaybayan nila at, bilang default, ginagamit ang parehong network, na nagiging sanhi ng paniniwala ng mga target na host na offline ang ibang mga host.
Sa kasamaang palad, ang mga operating feature ng IPMI at iLo device ay bihirang isinasaalang-alang sa oras ng pagbili ng kagamitan.
Hindi direktang paghihiwalay
Mahalaga rin ang korum para sa pamamahala ng hindi direktang pagkakahiwalay; kung gagawin nang tama, maaaring payagan ng korum ang mga nakaligtas na ipagpalagay na ang mga nawawalang node ay lilipat sa isang ligtas na estado pagkatapos ng isang tiyak na tagal ng panahon.
Sa pagsasaayos na ito, nire-reset ang timer ng watchdog ng hardware bawat N segundo kung hindi mawawala ang korum. Kung ang timer (karaniwan ay maraming multiple ng N) ay mag-e-expire, ang device ay nagsasagawa ng hindi magandang power down (hindi shutdown).
Ang diskarte na ito ay napaka-epektibo, ngunit kung walang korum ay walang sapat na impormasyon sa loob ng cluster upang pamahalaan ito. Hindi madaling sabihin ang pagkakaiba sa pagitan ng pagkawala ng network at pagkabigo ng peer node. Ang dahilan kung bakit mahalaga ito ay na kung walang kakayahang mag-iba sa pagitan ng dalawang kaso, napipilitan kang piliin ang parehong pag-uugali sa parehong mga kaso.
Ang problema sa pagpili ng isang mode ay walang paraan ng pagkilos na nagpapalaki ng kakayahang magamit at pinipigilan ang pagkawala ng data.
- Kung pipiliin mong ipagpalagay na ang isang peer node ay aktibo ngunit sa katunayan ay nabigo, ang cluster ay hindi kinakailangang ihinto ang mga serbisyong tatakbo upang mabayaran ang pagkawala ng mga serbisyo mula sa nabigong peer node.
- Kung magpasya kang ipagpalagay na ang isang node ay down, ngunit ito ay isang network failure lamang at sa katunayan ang remote node ay gumagana, pagkatapos ay sa pinakamahusay na ikaw ay nagsa-sign up para sa ilang hinaharap na manu-manong pagkakasundo ng mga resultang set ng data.
Anuman ang heuristic na ginagamit mo, ito ay walang kuwenta upang lumikha ng isang pagkabigo na maaaring maging sanhi ng magkabilang panig upang mabigo o maging sanhi ng cluster upang isara ang mga nabubuhay na node. Ang hindi paggamit ng korum ay tunay na nag-aalis sa kumpol ng isa sa pinakamakapangyarihang kasangkapan sa arsenal nito.
Kung walang ibang alternatibo, ang pinakamahusay na diskarte ay ang isakripisyo ang pagkakaroon (dito ang may-akda ay tumutukoy sa CAP theorem). Ang mataas na kakayahang magamit ng sirang data ay hindi nakakatulong sa sinuman, at ang manu-manong pag-reconcile ng iba't ibang set ng data ay hindi rin masaya.
Korum
Napakaganda ng Quorum, tama ba?
Ang tanging downside ay upang magkaroon ito sa isang cluster na may N miyembro, kailangan mong magkaroon ng koneksyon sa pagitan ng N/2+1 ng iyong mga node na natitira. Na hindi posible sa isang dalawang node cluster pagkatapos mabigo ang isang node.
Na sa huli ay nagdadala sa atin sa pangunahing problema sa dalawang node:
Walang katuturan ang Quorum sa dalawang node cluster, at kung wala ito imposibleng mapagkakatiwalaan na matukoy ang kurso ng aksyon na nagpapalaki ng kakayahang magamit at pumipigil sa pagkawala ng data
Kahit na sa isang sistema ng dalawang node na konektado sa pamamagitan ng isang crossover cable, imposibleng tiyak na makilala sa pagitan ng isang network outage at isang pagkabigo ng kabilang node. Ang hindi pagpapagana ng isang dulo (ang posibilidad na, siyempre, ay proporsyonal sa distansya sa pagitan ng mga node) ay sapat na upang mapawalang-bisa ang anumang pagpapalagay na ang kalusugan ng link ay katumbas ng kalusugan ng kasosyong node.
Gumagawa ng dalawang-node cluster
Minsan ang kliyente ay hindi o hindi gustong bumili ng ikatlong node, at napipilitan kaming maghanap ng alternatibo.
Pagpipilian 1 - Duplicate na paraan ng paghihiwalay
Ang iLO o IPMI device ng isang node ay kumakatawan sa isang punto ng pagkabigo dahil, kung mabibigo ito, hindi ito magagamit ng mga nakaligtas upang dalhin ang node sa isang ligtas na estado. Sa isang cluster ng 3 o higit pang mga node, maaari nating pagaanin ito sa pamamagitan ng pagkalkula ng quorum at paggamit ng isang hardware watchdog (isang hindi direktang mekanismo ng disassociation, gaya ng tinalakay kanina). Sa kaso ng dalawang node, dapat naming gamitin ang network power distribution units (PDUs) sa halip.
Pagkatapos ng isang pagkabigo, ang survivor ay unang sumusubok na makipag-ugnayan sa pangunahing disassociation device (naka-embed na iLO o IPMI). Kung ito ay matagumpay, magpapatuloy ang pagbawi gaya ng dati. Kung nabigo lamang ang iLO/IPMI device ay maa-access ang PDU; kung matagumpay ang pag-access, maaaring magpatuloy ang pagbawi.
Siguraduhing ilagay ang PDU sa ibang network kaysa sa trapiko ng cluster, kung hindi, haharangin ng isang solong network failure ang pag-access sa parehong mga disassociation device at haharangan ang pagpapanumbalik ng mga serbisyo.
Dito maaari mong itanong - ang PDU ba ay isang punto ng kabiguan? Kung saan ang sagot ay, siyempre ito ay.
Kung mahalaga sa iyo ang panganib na ito, hindi ka nag-iisa: ikonekta ang parehong mga node sa dalawang PDU at sabihin sa clustering software na gamitin pareho kapag pinapagana ang mga node sa on at off. Ang cluster ay nananatiling aktibo ngayon kung ang isang PDU ay namatay, at ang pangalawang pagkabigo ng alinman sa isa pang PDU o ang IPMI device ay kinakailangan upang harangan ang pagbawi.
Opsyon 2 - Pagdaragdag ng Arbiter
Sa ilang mga sitwasyon, habang teknikal na posible ang duplicate na paraan ng disassociation, mahirap ito sa pulitika. Maraming kumpanya ang gustong magkaroon ng ilang paghihiwalay sa pagitan ng mga administrator at mga may-ari ng application, at ang mga administrator ng network na may kamalayan sa seguridad ay hindi palaging masigasig tungkol sa pagbabahagi ng mga setting ng access ng PDU sa sinuman.
Sa kasong ito, ang inirerekomendang alternatibo ay lumikha ng isang neutral na third party na maaaring makadagdag sa pagkalkula ng korum.
Sa kaganapan ng isang pagkabigo, ang isang node ay dapat na makita ang mga airwave ng kanyang peer o arbiter upang maibalik ang mga serbisyo. Kasama rin sa arbiter ang isang disconnect function kung makikita ng parehong node ang arbiter ngunit hindi makita ang isa't isa.
Dapat gamitin ang opsyong ito kasabay ng isang hindi direktang paraan ng paghihiwalay, gaya ng timer ng hardware watchdog, na naka-configure na pumatay ng makina kung mawalan ito ng koneksyon sa peer at arbiter node nito. Kaya, ang isang survivor ay maaaring makatuwirang ipagpalagay na ang peer node nito ay nasa isang secure na estado pagkatapos mag-expire ang timer ng watchdog ng hardware.
Ang praktikal na pagkakaiba sa pagitan ng isang arbiter at isang ikatlong node ay ang isang arbiter ay nangangailangan ng mas kaunting mga mapagkukunan upang gumana at maaaring potensyal na maghatid ng higit sa isang cluster.
Opsyon 3 - Salik ng tao
Ang pangwakas na diskarte ay para sa mga nakaligtas na magpatuloy sa pagpapatakbo ng anumang mga serbisyo na kanilang pinapatakbo na, ngunit hindi magsimula ng mga bago hanggang sa malutas mismo ang problema (pag-restore ng network, pag-reboot ng node) o ang isang tao ay mananagot para sa manu-manong pagkumpirma na ang kabilang panig ay patay na.
Opsyon ng bonus
Nabanggit ko bang maaari kang magdagdag ng pangatlong node?
Dalawang rack
Para sa kapakanan ng argumento, magpanggap tayo na nakumbinsi kita sa mga merito ng ikatlong node, ngayon ay dapat nating isaalang-alang ang pisikal na pag-aayos ng mga node. Kung ang mga ito ay nakalagay (at pinapagana) sa parehong rack, ito rin ay bumubuo ng SPoF, at isa na hindi malulutas sa pamamagitan ng pagdaragdag ng pangalawang rack.
Kung ito ay nakakagulat, isaalang-alang kung ano ang mangyayari kung ang isang rack na may dalawang node ay nabigo, at kung paano ang nabubuhay na node ay magkakaiba sa pagitan ng iyon at ng isang pagkabigo sa network.
Ang maikling sagot ay hindi ito posible, at muli ay hinaharap namin ang lahat ng mga problema sa dalawang-node na kaso. O nakaligtas:
- binabalewala ang korum at maling pagtatangka na simulan ang pagpapanumbalik sa panahon ng pagkawala ng network (ang kakayahang kumpletuhin ang paghihiwalay ay ibang kuwento at depende sa kung ang PDU ay kasangkot at kung sila ay may kapangyarihan sa alinman sa mga rack), o
- nirerespeto ang quorum at dinidiskonekta nang maaga kapag nabigo ang peer node nito
Sa anumang kaso, ang dalawang rack ay hindi mas mahusay kaysa sa isa, at ang mga node ay dapat makatanggap ng mga independiyenteng supply ng kuryente o ipamahagi sa tatlo (o higit pa, depende sa kung gaano karaming mga node ang mayroon ka) rack.
Dalawang data center
Sa puntong ito, maaaring naisin ng mga mambabasa na hindi na nanganganib na isaalang-alang ang pagbawi sa sakuna. Ano ang mangyayari kapag ang isang asteroid ay tumama sa parehong data center sa aming tatlong node na kumalat sa tatlong magkakaibang rack? Malinaw na Masamang Bagay, ngunit depende sa iyong mga pangangailangan, maaaring hindi sapat ang pagdaragdag ng pangalawang data center.
Kung nagawa nang tama, ang pangalawang data center ay nagbibigay sa iyo (at makatuwirang gayon) ng napapanahon at pare-parehong kopya ng iyong mga serbisyo at ng kanilang data. Gayunpaman, tulad ng sa dalawang-node, dalawang-rack na mga sitwasyon, walang sapat na impormasyon sa system upang matiyak ang maximum na kakayahang magamit at maiwasan ang katiwalian (o mga pagkakaiba sa set ng data). Kahit na may tatlong node (o rack), ang pamamahagi ng mga ito sa dalawang data center lang ay nag-iiwan sa system na hindi mapagkakatiwalaang gumawa ng tamang desisyon kung sakaling magkaroon ng isang (mas malamang na ngayon) na kaganapan na hindi maaaring makipag-usap ng magkabilang partido.
Hindi ito nangangahulugan na ang solusyon sa dalawahang data center ay hindi kailanman angkop. Madalas gusto ng mga kumpanya na magkaroon ng kamalayan ang isang tao bago gawin ang pambihirang hakbang ng paglipat sa isang backup na data center. Tandaan lang na kung gusto mong i-automate ang outage, kakailanganin mo ng pangatlong data center para magkaroon ng kahulugan ang quorum (direkta man o sa pamamagitan ng arbiter), o hahanap ka ng paraan para mapagkakatiwalaang isara ang buong data. gitna.
Pinagmulan: www.habr.com