Teorema CAP minangka landasan teori sistem terdistribusi. Mesthine, kontroversi sing ana ing saubengé ora suda: definisi kasebut ora kanonik, lan ora ana bukti sing ketat... Nanging, kanthi mantep ing posisi akal sehat saben dina, kita kanthi intuisi ngerti manawa teorema kasebut bener.
Sing ora jelas yaiku artine aksara “P”. Nalika kluster dipérang, mutusaké apa ora nanggapi nganti quorum tekan, utawa kanggo menehi bali data sing kasedhiya. Gumantung ing asil pilihan iki, sistem diklasifikasikaké minangka salah siji CP utawa AP. Cassandra, contone, bisa nindakake salah siji cara, gumantung ora malah ing setelan kluster, nanging ing paramèter saben request tartamtu. Nanging yen sistem ora "P" lan pamisah, banjur apa?
Jawaban kanggo pitakonan iki rada ora dikarepke: klompok CA ora bisa pamisah.
Kluster apa iki sing ora bisa dipisahake?
Atribut indispensable saka kluster kasebut yaiku sistem panyimpenan data sing dienggo bareng. Ing mayoritas kasus, iki tegese nyambungake liwat SAN, sing mbatesi panggunaan solusi CA kanggo perusahaan gedhe sing bisa njaga infrastruktur SAN. Supaya macem-macem server bisa nggarap data sing padha, sistem file kluster dibutuhake. Sistem file kasebut kasedhiya ing portofolio HPE (CFS), Veritas (VxCFS) lan IBM (GPFS).
Oracle RAC
Opsi Cluster Aplikasi Nyata pisanan muncul ing 2001 kanthi release Oracle 9i. Ing kluster kasebut, sawetara conto server bisa digunakake karo database sing padha.
Oracle bisa nggarap sistem file clustered lan solusi dhewe - ASM, Manajemen Panyimpenan Otomatis.
Saben salinan nyimpen jurnal dhewe. Transaksi kasebut dileksanakake lan ditindakake kanthi siji conto. Yen instance gagal, salah sawijining simpul kluster sing isih urip (instance) maca log lan mulihake data sing ilang - saéngga njamin kasedhiyan.
Kabeh kedadean njaga cache dhewe, lan kaca sing padha (blok) bisa ana ing cache saka sawetara kedadean ing wektu sing padha. Menapa malih, yen siji Kayata perlu kaca lan ana ing cache saka Kayata liyane, iku bisa njaluk saka pepadhamu nggunakake mekanisme fusi cache tinimbang maca saka disk.
Nanging apa sing kedadeyan yen salah sawijining kedadeyan kudu ngganti data?
Keanehan Oracle yaiku ora duwe layanan ngunci darmabakti: yen server pengin ngunci baris, banjur rekaman kunci diselehake langsung ing kaca memori ing ngendi baris sing dikunci. Thanks kanggo pendekatan iki, Oracle minangka juara kinerja ing antarane database monolitik: layanan ngunci ora nate dadi bottleneck. Nanging ing konfigurasi kluster, arsitektur kasebut bisa nyebabake lalu lintas jaringan lan deadlocks sing kuat.
Sawise rekaman dikunci, sawijining conto bakal menehi kabar marang kabeh kedadeyan liyane yen kaca sing nyimpen rekaman kasebut nduweni ditahan eksklusif. Yen conto liyane kudu ngganti rekaman ing kaca sing padha, kudu ngenteni nganti owah-owahan kaca ditindakake, yaiku, informasi pangowahan ditulis ing jurnal ing disk (lan transaksi bisa terus). Bisa uga kedadeyan yen kaca bakal diganti kanthi pirang-pirang salinan, banjur nalika nulis kaca menyang disk, sampeyan kudu ngerteni sapa sing nyimpen versi kaca iki saiki.
Nganyari kanthi acak kaca sing padha ing macem-macem simpul RAC nyebabake kinerja database mudhun kanthi dramatis, nganti kinerja kluster bisa luwih murah tinimbang siji conto.
Panggunaan Oracle RAC sing bener yaiku kanggo misahake data kanthi fisik (contone, nggunakake mekanisme tabel partisi) lan ngakses saben partisi liwat simpul khusus. Tujuan utama RAC ora skala horisontal, nanging njamin toleransi kesalahan.
Yen simpul mandheg nanggapi deg-degan, mula simpul sing ndeteksi kasebut miwiti prosedur voting ing disk. Yen simpul sing ilang ora kacathet ing kene, salah sawijining simpul njupuk tanggung jawab kanggo pemulihan data:
- "freezes" kabeh kaca sing ana ing cache simpul sing ilang;
- maca log (redo) saka simpul sing ilang lan ngetrapake owah-owahan sing dicathet ing log kasebut, bebarengan mriksa apa simpul liya duwe versi kaca sing luwih anyar sing diganti;
- mbalek maneh transaksi sing ditundha.
Kanggo nyederhanakake ngalih ing antarane simpul, Oracle duwe konsep layanan - conto virtual. Kayata bisa nglayani pirang-pirang layanan, lan layanan bisa pindhah ing antarane simpul. Kayata aplikasi sing nglayani bagean tartamtu saka database (contone, klompok klien) dianggo karo siji layanan, lan layanan sing tanggung jawab kanggo bagean iki saka database pindhah menyang simpul liyane nalika simpul gagal.
Sistem Data Murni IBM kanggo Transaksi
Solusi cluster kanggo DBMS muncul ing portofolio Blue Giant ing 2009. Ideologically, iku penerus saka cluster Parallel Sysplex, dibangun ing peralatan "biasa". Ing 2009, DB2 pureScale dirilis minangka piranti lunak, lan ing 2012, IBM nawakake piranti sing diarani Sistem Data Murni kanggo Transaksi. Sampeyan kudu ora bingung karo Sistem Data Murni kanggo Analytics, sing ora luwih saka jeneng Netezza.
Sepisanan, arsitektur pureScale padha karo Oracle RAC: kanthi cara sing padha, sawetara simpul disambungake menyang sistem panyimpenan data umum, lan saben simpul nganggo conto DBMS dhewe kanthi wilayah memori lan log transaksi dhewe. Nanging, ora kaya Oracle, DB2 duwe layanan ngunci khusus sing diwakili dening sakumpulan proses db2LLM *. Ing konfigurasi kluster, layanan iki diselehake ing simpul sing kapisah, sing diarani fasilitas kopling (CF) ing Parallel Sysplex, lan PowerHA ing Data Murni.
PowerHA nyedhiyakake layanan ing ngisor iki:
- manajer kunci;
- cache buffer global;
- area komunikasi antar proses.
Kanggo nransfer data saka PowerHA menyang simpul database lan mburi, akses memori remot digunakake, supaya interkoneksi kluster kudu ndhukung protokol RDMA. PureScale bisa nggunakake Infiniband lan RDMA liwat Ethernet.
Yen simpul butuh kaca, lan kaca iki ora ana ing cache, banjur simpul kasebut njaluk kaca ing cache global, lan mung yen ora ana, maca saka disk. Ora kaya Oracle, panjaluk kasebut mung menyang PowerHA, lan ora menyang simpul tetanggan.
Yen conto bakal ngganti baris, iku ngunci ing mode eksklusif, lan kaca ngendi baris dumunung ing mode sambungan. Kabeh kunci didaftar ing manajer kunci global. Nalika transaksi rampung, simpul ngirim pesen menyang manajer kunci, sing nyalin kaca sing diowahi menyang cache global, ngeculake kunci, lan mbatalake kaca sing diowahi ing cache simpul liyane.
Yen kaca ing ngendi baris sing diowahi wis dikunci, manajer kunci bakal maca kaca sing diowahi saka memori simpul sing nggawe pangowahan, ngeculake kunci kasebut, mbatalake kaca sing diowahi ing cache simpul liyane, lan wenehi kunci kaca menyang simpul sing dijaluk.
"Reget", yaiku, diganti, kaca bisa ditulis menyang disk saka simpul biasa lan saka PowerHA (castout).
Yen salah siji saka node pureScale gagal, pemulihan diwatesi mung kanggo transaksi sing durung rampung nalika gagal: kaca sing diowahi dening simpul kasebut ing transaksi rampung ana ing cache global ing PowerHA. Node diwiwiti maneh ing konfigurasi suda ing salah sawijining server ing kluster, nggulung maneh transaksi sing ditundha lan ngeculake kunci.
PowerHA mlaku ing rong server lan simpul master niru kahanane kanthi bebarengan. Yen simpul PowerHA utami gagal, kluster kasebut terus beroperasi nganggo simpul serep.
Mesthi, yen sampeyan ngakses set data liwat simpul siji, kinerja sakabèhé kluster bakal luwih dhuwur. PureScale bisa uga sok dong mirsani manawa area data tartamtu diproses dening siji simpul, banjur kabeh kunci sing ana gandhengane karo wilayah kasebut bakal diproses sacara lokal dening simpul kasebut tanpa sesambungan karo PowerHA. Nanging sanalika aplikasi nyoba ngakses data iki liwat simpul liyane, proses kunci terpusat bakal diterusake.
Tes internal IBM babagan beban kerja 90% maca lan 10% nulis, sing meh padha karo beban kerja produksi ing donya nyata, nuduhake skala linier nganti 128 simpul. Kahanan tes, sayangé, ora dibeberke.
HPE NonStop SQL
Portofolio Hewlett-Packard Enterprise uga nduweni platform dhewe sing kasedhiya banget. Iki minangka platform NonStop, dirilis ing pasar ing taun 1976 dening Tandem Computers. Ing taun 1997, perusahaan kasebut dituku dening Compaq, sing banjur digabung karo Hewlett-Packard ing taun 2002.
NonStop digunakake kanggo mbangun aplikasi kritis - contone, HLR utawa pangolahan kertu bank. Platform kasebut dikirim ing wangun kompleks piranti lunak lan hardware (perkakas), sing kalebu simpul komputasi, sistem panyimpenan data lan peralatan komunikasi. Jaringan ServerNet (ing sistem modern - Infiniband) serves loro kanggo ijol-ijolan antarane simpul lan kanggo akses menyang sistem panyimpenan data.
Versi awal saka sistem digunakake pemroses tertutup sing padha diselarasake karo saben liyane: kabeh operasi dileksanakake synchronously dening sawetara prosesor, lan sanalika salah siji saka pemroses kesalahan, dipateni, lan kaloro terus bisa. Mengko, sistem kasebut ngalih menyang prosesor konvensional (pisanan MIPS, banjur Itanium lan pungkasane x86), lan mekanisme liyane wiwit digunakake kanggo sinkronisasi:
- pesen: saben proses sistem duwe kembar "bayangan", sing proses aktif ngirim pesen babagan status kasebut; yen proses utama gagal, proses bayangan wiwit digunakake saka wayahe ditemtokake dening pesen pungkasan;
- voting: sistem panyimpenan duwe komponen hardware khusus sing nampa macem-macem akses podho rupo lan kaleksanan mung yen akses cocog; Tinimbang sinkronisasi fisik, prosesor operate asynchronously, lan asil karya dibandhingake mung ing wektu I / O.
Wiwit 1987, DBMS relasional wis mlaku ing platform NonStop - pisanan SQL/MP, lan mengko SQL/MX.
Kabeh database dipérang dadi bagean, lan saben bagean tanggung jawab kanggo proses Data Access Manager (DAM) dhewe. Nyedhiyakake rekaman data, caching, lan mekanisme ngunci. Pangolahan data ditindakake dening Proses Server Pelaksana sing mlaku ing simpul sing padha karo manajer data sing cocog. Penjadwal SQL/MX mbagi tugas ing antarane para pelaksana lan nglumpukake asil. Yen perlu kanggo nggawe owah-owahan sing disepakati, protokol komit rong fase sing diwenehake dening perpustakaan TMF (Fasilitas Manajemen Transaksi) digunakake.
NonStop SQL bisa nggawe prioritas proses supaya pitakon analitis sing dawa ora ngganggu eksekusi transaksi. Nanging, tujuane yaiku ngolah transaksi singkat, lan dudu analytics. Pangembang njamin kasedhiyan kluster NonStop ing tingkat limang "sangang", yaiku, downtime mung 5 menit saben taun.
SAP-HANA
Rilis stabil pisanan saka HANA DBMS (1.0) ditindakake ing November 2010, lan paket SAP ERP pindhah menyang HANA ing Mei 2013. Platform kasebut adhedhasar teknologi sing dituku: TREX Search Engine (search in columnar storage), P*TIME DBMS lan MAX DB.
Tembung "HANA" dhewe minangka singkatan, High Performance ANalytical Appliance. DBMS iki diwenehake ing wangun kode sing bisa mbukak ing sembarang server x86, Nanging, panginstalan industri mung diijini ing peralatan certified. Solusi kasedhiya saka HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Sawetara konfigurasi Lenovo malah ngidini operasi tanpa SAN - peran sistem panyimpenan umum dimainake dening kluster GPFS ing disk lokal.
Boten kados platform kadhaptar ing ndhuwur, HANA minangka DBMS ing memori, yaiku gambar data utami disimpen ing RAM, lan mung log lan jepretan periodik sing ditulis ing disk kanggo pemulihan yen ana bilai.
Saben simpul kluster HANA tanggung jawab kanggo bagean data dhewe, lan peta data disimpen ing komponen khusus - Server Jeneng, sing ana ing simpul koordinator. Data ora diduplikasi ing antarane simpul. Informasi ngunci uga disimpen ing saben simpul, nanging sistem duwe detektor deadlock global.
Nalika klien HANA nyambung menyang kluster, ngundhuh topologi lan banjur bisa ngakses simpul langsung, gumantung saka data sing dibutuhake. Yen transaksi mengaruhi data simpul siji, mula bisa dieksekusi sacara lokal dening simpul kasebut, nanging yen data saka sawetara simpul diganti, simpul wiwitan ngontak simpul koordinator, sing mbukak lan ngoordinasi transaksi sing disebarake, nglakoni kanthi nggunakake protokol komit rong fase sing dioptimalake.
Node koordinator diduplikasi, dadi yen koordinator gagal, simpul serep langsung njupuk alih. Nanging yen simpul karo data gagal, banjur siji-sijine cara kanggo ngakses data kasebut yaiku miwiti maneh simpul kasebut. Minangka aturan, klompok HANA njaga server cadangan supaya bisa miwiti maneh simpul sing ilang kanthi cepet.
Source: www.habr.com