Ang CAP theorem ay ang pundasyon ng distributed systems theory. Siyempre, ang kontrobersya na nakapalibot dito ay hindi humupa: ang mga kahulugan dito ay hindi kanonikal, at walang mahigpit na patunay... Gayunpaman, matatag na nakatayo sa mga posisyon ng pang-araw-araw na sentido komun™, intuitively naming nauunawaan na ang theorem ay totoo.
Ang hindi lang halata ay ang kahulugan ng letrang "P". Kapag hinati ang cluster, magpapasya ito kung hindi tutugon hanggang sa maabot ang isang quorum, o ibabalik ang data na available. Depende sa mga resulta ng pagpipiliang ito, ang system ay inuri bilang alinman sa isang CP o isang AP. Si Cassandra, halimbawa, ay maaaring kumilos sa alinmang paraan, hindi depende kahit sa mga setting ng cluster, ngunit sa mga parameter ng bawat partikular na kahilingan. Ngunit kung ang sistema ay hindi "P" at ito ay nahati, ano?
Ang sagot sa tanong na ito ay medyo hindi inaasahan: ang isang CA cluster ay hindi maaaring hatiin.
Anong uri ng kumpol ito na hindi maaaring hatiin?
Ang isang kailangang-kailangan na katangian ng naturang cluster ay isang shared data storage system. Sa karamihan ng mga kaso, nangangahulugan ito ng pagkonekta sa isang SAN, na naglilimita sa paggamit ng mga solusyon sa CA sa malalaking negosyo na may kakayahang magpanatili ng isang imprastraktura ng SAN. Upang gumana ang maraming server sa parehong data, kinakailangan ang isang clustered file system. Ang ganitong mga file system ay makukuha sa mga portfolio ng HPE (CFS), Veritas (VxCFS) at IBM (GPFS).
Oracle RAC
Ang pagpipiliang Real Application Cluster ay unang lumitaw noong 2001 sa paglabas ng Oracle 9i. Sa naturang cluster, gumagana ang ilang instance ng server sa parehong database.
Maaaring gumana ang Oracle sa parehong clustered file system at sa sarili nitong solusyon - ASM, Automatic Storage Management.
Ang bawat kopya ay nagtatago ng sarili nitong journal. Ang transaksyon ay isinasagawa at ginawa ng isang pagkakataon. Kung nabigo ang isang instance, babasahin ng isa sa mga nabubuhay na cluster node (instances) ang log nito at ibinabalik ang nawalang data - sa gayo'y tinitiyak ang availability.
Ang lahat ng mga pagkakataon ay nagpapanatili ng kanilang sariling cache, at ang parehong mga pahina (mga bloke) ay maaaring nasa mga cache ng maraming mga pagkakataon sa parehong oras. Bukod dito, kung ang isang pagkakataon ay nangangailangan ng isang pahina at ito ay nasa cache ng isa pang pagkakataon, maaari itong makuha mula sa kapitbahay nito gamit ang mekanismo ng pagsasanib ng cache sa halip na magbasa mula sa disk.
Ngunit ano ang mangyayari kung kailangang baguhin ng isa sa mga pagkakataon ang data?
Ang kakaiba ng Oracle ay wala itong nakalaang serbisyo sa pag-lock: kung nais ng server na i-lock ang isang hilera, ang lock record ay direktang inilalagay sa pahina ng memorya kung saan matatagpuan ang naka-lock na hilera. Salamat sa diskarteng ito, ang Oracle ang kampeon sa pagganap sa mga monolitikong database: hindi kailanman nagiging bottleneck ang serbisyo sa pag-lock. Ngunit sa isang cluster configuration, ang ganitong arkitektura ay maaaring humantong sa matinding trapiko sa network at mga deadlock.
Kapag na-lock na ang isang record, inaabisuhan ng isang instance ang lahat ng iba pang pagkakataon na ang page na nag-iimbak ng record na iyon ay may eksklusibong hold. Kung ang isa pang pagkakataon ay kailangang baguhin ang isang tala sa parehong pahina, dapat itong maghintay hanggang ang mga pagbabago sa pahina ay ginawa, iyon ay, ang impormasyon ng pagbabago ay nakasulat sa isang journal sa disk (at ang transaksyon ay maaaring magpatuloy). Maaaring mangyari din na ang isang pahina ay papalitan nang sunud-sunod ng ilang mga kopya, at pagkatapos ay kapag isinusulat ang pahina sa disk kailangan mong malaman kung sino ang nag-iimbak ng kasalukuyang bersyon ng pahinang ito.
Ang random na pag-update ng parehong mga pahina sa iba't ibang mga RAC node ay nagiging sanhi ng pagbaba ng pagganap ng database, hanggang sa punto kung saan ang pagganap ng cluster ay maaaring mas mababa kaysa sa pagganap ng isang pagkakataon.
Ang tamang paggamit ng Oracle RAC ay ang pisikal na paghahati-hati ng data (halimbawa, gamit ang isang mekanismo ng partitioned table) at i-access ang bawat hanay ng mga partisyon sa pamamagitan ng isang nakalaang node. Ang pangunahing layunin ng RAC ay hindi pahalang na pag-scale, ngunit pagtiyak ng fault tolerance.
Kung ang isang node ay huminto sa pagtugon sa isang tibok ng puso, kung gayon ang node na naka-detect dito ay unang magsisimula ng isang pamamaraan ng pagboto sa disk. Kung ang nawawalang node ay hindi nabanggit dito, ang isa sa mga node ay aako ng responsibilidad para sa pagbawi ng data:
- "nag-freeze" ang lahat ng mga pahina na nasa cache ng nawawalang node;
- binabasa ang mga log (redo) ng nawawalang node at muling inilalapat ang mga pagbabagong naitala sa mga log na ito, sabay-sabay na tinitingnan kung ang ibang mga node ay may mga bagong bersyon ng mga pahinang binago;
- ibinabalik ang mga nakabinbing transaksyon.
Upang gawing simple ang paglipat sa pagitan ng mga node, ang Oracle ay may konsepto ng isang serbisyo - isang virtual na halimbawa. Ang isang instance ay maaaring maghatid ng maraming serbisyo, at ang isang serbisyo ay maaaring lumipat sa pagitan ng mga node. Ang isang application instance na naghahatid ng isang partikular na bahagi ng database (halimbawa, isang grupo ng mga kliyente) ay gumagana sa isang serbisyo, at ang serbisyo na responsable para sa bahaging ito ng database ay lilipat sa isa pang node kapag nabigo ang isang node.
IBM Pure Data Systems para sa mga Transaksyon
Ang isang cluster solution para sa DBMS ay lumitaw sa Blue Giant portfolio noong 2009. Sa ideolohikal, ito ang kahalili ng Parallel Sysplex cluster, na binuo sa "regular" na kagamitan. Noong 2009, inilabas ang DB2 pureScale bilang isang software suite, at noong 2012, nag-alok ang IBM ng appliance na tinatawag na Pure Data Systems for Transactions. Hindi ito dapat malito sa Pure Data Systems para sa Analytics, na hindi hihigit sa isang pinalitan ng pangalan na Netezza.
Sa unang sulyap, ang arkitektura ng pureScale ay katulad ng Oracle RAC: sa parehong paraan, maraming mga node ang konektado sa isang karaniwang sistema ng pag-iimbak ng data, at ang bawat node ay nagpapatakbo ng sarili nitong halimbawa ng DBMS na may sariling mga lugar ng memorya at mga log ng transaksyon. Ngunit, hindi tulad ng Oracle, ang DB2 ay may nakalaang serbisyo sa pag-lock na kinakatawan ng isang hanay ng mga proseso ng db2LLM*. Sa isang cluster configuration, inilalagay ang serbisyong ito sa isang hiwalay na node, na tinatawag na coupling facility (CF) sa Parallel Sysplex, at PowerHA sa Pure Data.
Nagbibigay ang PowerHA ng mga sumusunod na serbisyo:
- tagapamahala ng lock;
- pandaigdigang buffer cache;
- lugar ng interprocess na komunikasyon.
Upang maglipat ng data mula sa PowerHA patungo sa mga node ng database at pabalik, ginagamit ang malayuang pag-access sa memorya, kaya dapat suportahan ng cluster interconnect ang RDMA protocol. Maaaring gamitin ng PureScale ang parehong Infiniband at RDMA sa Ethernet.
Kung ang isang node ay nangangailangan ng isang pahina, at ang pahinang ito ay wala sa cache, kung gayon ang node ay humihiling ng pahina sa global cache, at kung wala ito, binabasa ito mula sa disk. Hindi tulad ng Oracle, ang kahilingan ay napupunta lamang sa PowerHA, at hindi sa mga kalapit na node.
Kung babaguhin ng isang instance ang isang row, ila-lock ito sa exclusive mode, at ang page kung saan matatagpuan ang row sa shared mode. Ang lahat ng mga kandado ay nakarehistro sa pandaigdigang lock manager. Kapag nakumpleto ang transaksyon, ang node ay nagpapadala ng mensahe sa lock manager, na kinokopya ang binagong pahina sa global cache, naglalabas ng mga lock, at nagpapawalang-bisa sa binagong pahina sa mga cache ng iba pang mga node.
Kung ang pahina kung saan matatagpuan ang binagong hilera ay naka-lock na, pagkatapos ay babasahin ng tagapamahala ng lock ang binagong pahina mula sa memorya ng node na gumawa ng pagbabago, bitawan ang lock, hindi wasto ang binagong pahina sa mga cache ng iba pang mga node, at ibigay ang lock ng page sa node na humiling nito.
"Dirty", iyon ay, binago, ang mga pahina ay maaaring isulat sa disk kapwa mula sa isang regular na node at mula sa PowerHA (castout).
Kung nabigo ang isa sa mga pureScale node, ang pagbawi ay limitado lamang sa mga transaksyong hindi pa nakumpleto sa oras ng pagkabigo: ang mga pahinang binago ng node na iyon sa mga nakumpletong transaksyon ay nasa global cache sa PowerHA. Ang node ay magre-restart sa isang pinababang configuration sa isa sa mga server sa cluster, ibabalik ang mga nakabinbing transaksyon at ilalabas ang mga lock.
Ang PowerHA ay tumatakbo sa dalawang server at ang master node ay kinokopya ang estado nito nang sabay-sabay. Kung nabigo ang pangunahing PowerHA node, patuloy na gagana ang cluster kasama ang backup na node.
Siyempre, kung i-access mo ang set ng data sa pamamagitan ng iisang node, magiging mas mataas ang pangkalahatang performance ng cluster. Maaaring mapansin ng PureScale na ang isang partikular na lugar ng data ay pinoproseso ng isang node, at pagkatapos ang lahat ng mga lock na nauugnay sa lugar na iyon ay lokal na ipoproseso ng node nang hindi nakikipag-ugnayan sa PowerHA. Ngunit sa sandaling sinubukan ng application na i-access ang data na ito sa pamamagitan ng isa pang node, magpapatuloy ang sentralisadong pagpoproseso ng lock.
Ang mga panloob na pagsubok ng IBM sa workload na 90% read at 10% write, na halos kapareho sa real-world production workloads, ay nagpapakita ng halos linear scaling hanggang sa 128 node. Ang mga kondisyon ng pagsubok, sa kasamaang-palad, ay hindi isiniwalat.
HPE NonStop SQL
Ang portfolio ng Hewlett-Packard Enterprise ay mayroon ding sarili nitong mataas na magagamit na platform. Ito ang NonStop platform, na inilabas sa merkado noong 1976 ng Tandem Computers. Noong 1997, ang kumpanya ay nakuha ng Compaq, na siya namang pinagsama sa Hewlett-Packard noong 2002.
Ginagamit ang NonStop upang bumuo ng mga kritikal na aplikasyon - halimbawa, pagproseso ng HLR o bank card. Ang platform ay inihahatid sa anyo ng isang software at hardware complex (appliance), na kinabibilangan ng mga computing node, isang data storage system at mga kagamitan sa komunikasyon. Ang ServerNet network (sa modernong mga sistema - Infiniband) ay nagsisilbi para sa pagpapalitan sa pagitan ng mga node at para sa pag-access sa data storage system.
Ang mga unang bersyon ng system ay gumagamit ng mga proprietary processor na naka-synchronize sa isa't isa: ang lahat ng mga operasyon ay isinagawa nang sabay-sabay ng ilang mga processor, at sa sandaling ang isa sa mga processor ay nagkamali, ito ay naka-off, at ang pangalawa ay patuloy na gumagana. Nang maglaon, lumipat ang system sa mga maginoo na processor (unang MIPS, pagkatapos ay Itanium at sa wakas x86), at ang iba pang mga mekanismo ay nagsimulang gamitin para sa pag-synchronize:
- mga mensahe: ang bawat proseso ng system ay may kambal na "anino", kung saan ang aktibong proseso ay pana-panahong nagpapadala ng mga mensahe tungkol sa katayuan nito; kung nabigo ang pangunahing proseso, ang proseso ng anino ay magsisimulang gumana mula sa sandaling natukoy ng huling mensahe;
- pagboto: ang sistema ng imbakan ay may espesyal na bahagi ng hardware na tumatanggap ng maraming magkakaparehong pag-access at ipapatupad lamang ang mga ito kung magkatugma ang mga pag-access; Sa halip na pisikal na pag-synchronize, ang mga processor ay gumagana nang asynchronous, at ang mga resulta ng kanilang trabaho ay inihahambing lamang sa mga sandali ng I/O.
Mula noong 1987, ang isang relational na DBMS ay tumatakbo sa NonStop platform - unang SQL/MP, at pagkatapos ay SQL/MX.
Ang buong database ay nahahati sa mga bahagi, at ang bawat bahagi ay responsable para sa sarili nitong proseso ng Data Access Manager (DAM). Nagbibigay ito ng mga mekanismo ng pag-record, pag-cache, at pag-lock ng data. Ang pagpoproseso ng data ay isinasagawa ng Mga Proseso ng Executor Server na tumatakbo sa parehong mga node gaya ng kaukulang mga tagapamahala ng data. Hinahati ng SQL/MX scheduler ang mga gawain sa mga executor at pinagsasama-sama ang mga resulta. Kapag kinakailangan na gumawa ng mga napagkasunduang pagbabago, ginagamit ang two-phase commit protocol na ibinigay ng library ng TMF (Transaction Management Facility).
Maaaring unahin ng NonStop SQL ang mga proseso upang ang mahabang analytical na mga query ay hindi makagambala sa pagpapatupad ng transaksyon. Gayunpaman, ang layunin nito ay tiyak ang pagproseso ng mga maiikling transaksyon, at hindi analytics. Ginagarantiyahan ng developer ang pagkakaroon ng NonStop cluster sa antas na limang "nines", ibig sabihin, ang downtime ay 5 minuto lamang bawat taon.
SAP-HANA
Ang unang stable na release ng HANA DBMS (1.0) ay naganap noong Nobyembre 2010, at ang SAP ERP package ay lumipat sa HANA noong Mayo 2013. Ang platform ay batay sa mga biniling teknolohiya: TREX Search Engine (paghahanap sa columnar storage), P*TIME DBMS at MAX DB.
Ang mismong salitang "HANA" ay isang acronym, High performance ANalytical Appliance. Ang DBMS na ito ay ibinibigay sa anyo ng code na maaaring tumakbo sa anumang x86 server, gayunpaman, ang mga pang-industriya na pag-install ay pinapayagan lamang sa mga sertipikadong kagamitan. Available ang mga solusyon mula sa HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Ang ilang mga pagsasaayos ng Lenovo ay nagpapahintulot pa nga ng operasyon nang walang SAN - ang papel ng isang karaniwang storage system ay nilalaro ng isang GPFS cluster sa mga lokal na disk.
Hindi tulad ng mga platform na nakalista sa itaas, ang HANA ay isang in-memory na DBMS, ibig sabihin, ang pangunahing data na imahe ay naka-imbak sa RAM, at tanging mga log at panaka-nakang snapshot ang isinusulat sa disk para sa pagbawi sakaling magkaroon ng sakuna.
Ang bawat HANA cluster node ay may pananagutan para sa sarili nitong bahagi ng data, at ang data map ay nakaimbak sa isang espesyal na bahagi – Name Server, na matatagpuan sa coordinator node. Ang data ay hindi nadoble sa pagitan ng mga node. Ang impormasyon sa pag-lock ay nakaimbak din sa bawat node, ngunit ang system ay may pandaigdigang deadlock detector.
Kapag kumonekta ang isang HANA client sa isang cluster, dina-download nito ang topology nito at pagkatapos ay direktang ma-access ang anumang node, depende sa kung anong data ang kailangan nito. Kung ang isang transaksyon ay nakakaapekto sa data ng isang solong node, maaari itong isagawa nang lokal ng node na iyon, ngunit kung ang data ng ilang mga node ay nagbabago, ang panimulang node ay nakikipag-ugnayan sa coordinator node, na nagbubukas at nagko-coordinate sa ipinamahagi na transaksyon, na ginagawa ito gamit ang isang na-optimize na two-phase commit protocol.
Ang coordinator node ay nadoble, kaya kung ang coordinator ay nabigo, ang backup na node ay agad na humalili. Ngunit kung nabigo ang isang node na may data, kung gayon ang tanging paraan upang ma-access ang data nito ay i-restart ang node. Bilang panuntunan, ang mga cluster ng HANA ay nagpapanatili ng isang ekstrang server upang ma-restart ang isang nawalang node dito sa lalong madaling panahon.
Pinagmulan: www.habr.com