Téoréma CAP mangrupikeun landasan téori sistem terdistribusi. Tangtosna, éta masih kontroversial: definisina henteu kanonik, sareng teu aya bukti anu pasti. Nanging, dumasar kana akal sehat™, urang sacara intuitif ngartos yén téoréma éta leres.
Hiji-hijina anu teu jelas nyaéta harti hurup "P." Nalika hiji klaster misah, éta mutuskeun naha bakal cicing waé dugi ka kuorum kahontal atanapi mulangkeun data anu dipibanda. Gumantung kana hasil kaputusan ieu, sistem ieu digolongkeun kana CP atanapi AP. Cassandra, contona, tiasa kalakuanana dina dua arah, henteu gumantung kana setélan klaster tapi kana parameter unggal pamundut khusus. Tapi upami sistemna sanés "P" sareng misah, teras kumaha?
Jawaban kana patarosan ieu rada teu disangka-sangka: klaster CA teu tiasa dipisahkeun.
Gugusan naon ieu anu teu tiasa dipisahkeun?
Atribut penting tina klaster sapertos kitu nyaéta sistem panyimpenan data anu dibagi. Dina kalolobaan kasus, ieu hartosna sambungan ngalangkungan SAN, anu ngawatesan panggunaan solusi CA pikeun perusahaan ageung anu sanggup ngajaga infrastruktur SAN. Supados sababaraha server Pikeun tiasa dianggo sareng data anu sami, diperyogikeun sistem file klaster. Sistem file sapertos kitu sayogi dina portofolio HPE (CFS), Veritas (VxCFS), sareng IBM (GPFS).
Oracle RAC
Pilihan Real Application Cluster mimiti muncul dina taun 2001 nalika diluncurkeunana Oracle 9i. Dina cluster sapertos kitu, sababaraha conto sérver dianggo nganggo database anu sami.
Oracle tiasa dianggo sareng sistem file klaster sareng solusina nyalira – ASM, Manajemen Panyimpenan Otomatis.
Unggal instansi ngajaga logna sorangan. Transaksi dijalankeun sareng dilakukeun ku hiji instansi. Upami hiji instansi gagal, salah sahiji simpul klaster (instansi) anu salamet bakal maca logna sareng mulangkeun data anu leungit, sahingga mastikeun kasadiaan.
Sadaya instansi ngajaga cache sorangan, sareng halaman (blok) anu sami tiasa aya dina cache tina sababaraha instansi sacara simultan. Salajengna, upami hiji instansi peryogi halaman anu aya dina cache tina instansi anu sanés, éta tiasa nyandakna ti tatanggana nganggo fusi cache tinimbang macana tina disk.
Tapi kumaha upami salah sahiji instansi kedah ngarobih data?
Fitur unik Oracle nyaéta teu gaduh layanan konci khusus: upami server hoyong konci hiji baris, entri konci ditulis langsung kana halaman mémori dimana baris anu badé dikonci aya. Pendekatan ieu ngajantenkeun Oracle janten jawara kinerja di antara database monolitik: layanan konci henteu pernah janten hambatan. Nanging, dina konfigurasi klaster, arsitéktur ieu tiasa nyababkeun lalu lintas jaringan anu intensif sareng deadlock.
Sakali rékaman dikonci, hiji instansi bakal ngabéjaan sadaya instansi séjén yén kaca anu ngandung rékaman éta parantos dikonci sacara éksklusif. Upami instansi anu sanés kedah ngarobih rékaman dina kaca anu sami, éta kedah ngantosan dugi ka parobihan kana kaca éta dilakukeun, nyaéta, dugi ka inpormasi parobihan ditulis kana log disk (sanaos transaksi tiasa diteruskeun). Éta ogé tiasa yén hiji kaca dirobih sacara sekuensial ku sababaraha instansi, dina hal ieu, nalika kaca ditulis kana disk, éta kedah nangtukeun instansi mana anu nahan vérsi halaman ayeuna.
Ngamutahirkeun kaca anu sami sacara acak dina sababaraha simpul RAC anu béda nyababkeun kinerja database turun drastis, nepi ka kinerja klaster tiasa langkung handap tibatan hiji instansi.
Panggunaan Oracle RAC anu leres nyaéta pikeun ngabagi data sacara fisik (contona, nganggo mékanisme tabel anu dipartisi) sareng ngaksés unggal sét partisi ngalangkungan simpul khusus. Tujuan utama RAC sanés skalabilitas horizontal, tapi toleransi kasalahan.
Upami hiji node eureun ngaréspon kana denyut jantung, node anu mimiti ngadeteksi ieu bakal ngamimitian sora disk. Upami node anu leungit masih teu ngaréspon, salah sahiji node bakal tanggung jawab pikeun pamulihan data:
- "ngabekukeun" sadaya halaman anu aya dina cache tina node anu leungit;
- maca log redo tina node anu leungit sareng nerapkeun deui parobihan anu kacatet dina log ieu, bari mariksa naha node sanés gaduh vérsi halaman anu langkung énggal anu dirobih;
- ngabalikeun transaksi anu teu acan réngsé.
Pikeun ngagampangkeun failover antara node, Oracle ngenalkeun konsép layanan—instance virtual. Hiji instansi tiasa ngadukung sababaraha layanan, sareng layanan tiasa migrasi antara node. Instansi aplikasi anu ngadukung bagian khusus tina database (contona, sakelompok klien) tiasa dianggo sareng hiji layanan, sedengkeun layanan anu tanggung jawab pikeun bagian database éta migrasi ka node anu sanés upami hiji node gagal.
Sistem Data Murni IBM pikeun Transaksi
Hiji solusi klaster pikeun DBMS muncul dina portopolio Big Blue dina taun 2009. Sacara ideologis, éta mangrupikeun panerus klaster Parallel Sysplex, anu diwangun dina perangkat keras "umum". Dina taun 2009, DB2 pureScale, hiji suite perangkat lunak, dirilis, sareng dina taun 2012, IBM nawiskeun perangkat keras sareng perangkat lunak anu disebut Pure Data Systems for Transactions. Ieu teu kedah lieur sareng Pure Data Systems for Analytics, anu teu langkung ti Netezza anu diganti merekna.
Sekilas, arsitéktur pureScale téh sarupa jeung Oracle RAC: sababaraha node disambungkeun kana sistem panyimpenan babagi, sarta unggal node ngajalankeun instansi DBMS sorangan kalawan area memori sarta log transaksi sorangan. Sanajan kitu, teu kawas Oracle, DB2 miboga layanan konci husus, anu digambarkeun ku sakumpulan prosés db2LLM*. Dina konfigurasi klaster, layanan ieu disebarkeun ka node anu misah, anu disebut fasilitas gandeng (CF) dina Parallel Sysplex sarta PowerHA dina Pure Data.
PowerHA nyayogikeun jasa-jasa ieu:
- manajer blok;
- cache panyangga global;
- widang komunikasi antarprosés.
Aksés mémori jarak jauh dianggo pikeun mindahkeun data ti PowerHA ka simpul database sareng deui, janten interkoneksi klaster kedah ngadukung protokol RDMA. PureScale tiasa nganggo Infiniband sareng RDMA ngalangkungan Ethernet.
Upami hiji node peryogi halaman sareng éta henteu aya dina cache, éta bakal nyuhunkeun halaman éta ti cache global, sareng ngan upami éta henteu aya, éta bakal macana tina disk. Teu sapertos Oracle, pamundut éta ngan ukur ka PowerHA, sanés ka node tatangga.
Nalika hiji instansi ngarobih hiji baris, éta bakal ngonci éta dina modeu éksklusif sareng halaman anu ngandung baris éta dina modeu dibagikeun. Sadaya konci kadaptar dina manajer konci global. Nalika transaksi réngsé, node ngirim pesen ka manajer konci, anu nyalin halaman anu dirobih ka cache global, ngaleupaskeun konci, sareng ngabatalkeun halaman anu dirobih dina cache node anu sanés.
Upami halaman anu ngandung baris anu dirobih parantos dikonci, manajer konci bakal maca halaman anu dirobih tina mémori simpul anu ngadamel modifikasi, ngaleupaskeun konci, ngabatalkeun halaman anu dirobih dina cache simpul sanés, sareng mulangkeun konci halaman ka simpul anu nyuhunkeunana.
"Kotor", nyaéta, dirobah, kaca tiasa ditulis kana disk ti simpul biasa sareng PowerHA (castout).
Upami hiji node pureScale gagal, pamulihan ngan ukur diwatesan pikeun transaksi anu tacan dilakukeun nalika kagagalan: halaman anu dirobih ku node ieu dina transaksi anu réngsé disimpen dina cache global dina PowerHA. Node éta ngamimitian deui dina konfigurasi anu dipreteli dina salah sahiji server klaster, ngagulung deui transaksi anu teu dilakukeun, sareng ngaleupaskeun konci.
PowerHA jalan dina dua server, sareng node primér sacara sinkron ngaréplikasi kaayaanana. Upami node primér gagal, klaster PowerHA teras beroperasi dina node cadangan.
Tangtosna, ngaksés sét data ngalangkungan hiji simpul bakal ningkatkeun kinerja klaster sacara umum. PureScale malah tiasa ngadeteksi yén daérah data anu tangtu nuju diprosés ku hiji simpul, teras sadaya konci anu aya hubunganana sareng daérah éta bakal diprosés sacara lokal ku simpul éta, tanpa komunikasi sareng PowerHA. Nanging, pas aplikasi nyobian ngaksés data éta ngalangkungan simpul anu sanés, pamrosésan konci terpusat bakal diteruskeun deui.
Tés internal IBM, anu dilaksanakeun kalayan beban kerja 90% baca sareng 10% tulis, anu ampir sami sareng beban kerja produksi di dunya nyata, nunjukkeun skala ampir linier dugi ka 128 node. Hanjakalna, kaayaan tésna henteu diungkabkeun.
HPE NonStop SQL
Hewlett-Packard Enterprise ogé gaduh platform anu sayogi kalayan kualitas luhur. Éta nyaéta platform NonStop, anu diluncurkeun dina taun 1976 ku Tandem Computers. Dina taun 1997, perusahaan ieu diakuisi ku Compaq, anu teras ngahiji sareng Hewlett-Packard dina taun 2002.
NonStop dianggo pikeun ngawangun aplikasi anu penting pisan, sapertos HLR atanapi pamrosésan kartu bank. Platform ieu disayogikeun salaku alat perangkat keras sareng perangkat lunak, kalebet simpul komputasi, sistem panyimpen data, sareng alat komunikasi. Jaringan ServerNet (Infiniband dina sistem modéren) ngalayanan pikeun komunikasi antara simpul sareng pikeun aksés kana sistem panyimpen data.
Vérsi awal sistem ieu nganggo prosesor proprietary anu disinkronkeun silih: sadaya operasi dilakukeun sacara sinkron ku sababaraha prosesor, sareng upami hiji prosesor gagal, éta bakal pareum, sedengkeun anu sanésna teraskeun operasi. Engkéna, sistem éta ngalih ka prosesor konvensional (mimiti MIPS, teras Itanium, sareng pamustunganana x86), sareng mékanisme sanésna dianggo pikeun sinkronisasi:
- Pesen: Unggal prosés sistem ngagaduhan kembar "kalangkang", anu prosés aktifna sacara périodik ngirim pesen ngeunaan statusna; upami prosés utama gagal, prosés kalangkang mimiti dijalankeun ti momen anu ditangtukeun ku pesen terakhir;
- Pamilihan: Sistem panyimpenan ngagaduhan komponén perangkat keras khusus anu nampi sababaraha pamundut anu idéntik sareng ngaéksekusi éta ngan upami pamundutna cocog; tinimbang disinkronkeun sacara fisik, prosesor beroperasi sacara asinkron, sareng hasil padamelanna dibandingkeun ngan ukur dina titik I/O.
Ti saprak 1987, platform NonStop parantos ngajalankeun DBMS relasional – mimitina SQL/MP teras SQL/MX.
Sakabéh database dibagi kana sababaraha bagian, anu masing-masing dikokolakeun ku prosés Data Access Manager (DAM) sorangan. Éta ngatur rékaman data, caching, sareng koncian. Pamrosésan data dikokolakeun ku Prosés Server Executor anu dijalankeun dina node anu sami sareng manajer data anu saluyu. Penjadwal SQL/MX ngabagi tugas antara para eksekutor sareng ngahijikeun hasilna. Nalika parobihan anu konsisten diperyogikeun, protokol commit dua fase anu disayogikeun ku perpustakaan TMF (Transaction Management Facility) dianggo.
NonStop SQL tiasa ngutamakeun prosés supados pamundut analitis anu panjang henteu ngaganggu palaksanaan transaksi. Nanging, tujuanana nyaéta pikeun ngolah transaksi pondok, sanés analitik. Pamekar ngajamin kasadiaan klaster NonStop dina lima "salapan," anu hartosna downtime ngan ukur lima menit per taun.
SAP-HANA
Rilis stabil munggaran HANA DBMS (1.0) lumangsung dina bulan Nopémber 2010, sareng pakét SAP ERP ngalih ka HANA dina bulan Méi 2013. Platform ieu dumasar kana téknologi anu diala: TREX Search Engine (panéangan dina panyimpenan kolom), P*TIME DBMS sareng MAX DB.
Kecap "HANA" sorangan mangrupa singgetan tina High Performance Analytical Appliance. DBMS ieu dikirimkeun salaku kode anu tiasa dijalankeun dina server x86 naon waé, tapi pamasangan produksi ngan diidinan dina perangkat keras anu disertifikasi. Solusi sayogi ti HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, sareng NEC. Sababaraha konfigurasi Lenovo malah ngamungkinkeun operasi tanpa SAN, kalayan klaster GPFS dina drive lokal anu janten panyimpenan anu dibagi.
Beda sareng platform anu didaptarkeun di luhur, HANA nyaéta DBMS dina mémori, anu hartosna gambar data primér disimpen dina RAM, sareng ngan ukur log sareng snapshot périodik anu ditulis kana disk pikeun pamulihan bencana.
Unggal simpul klaster HANA tanggung jawab kana bagian datana sorangan, sareng peta data disimpen dina komponén khusus — Server Ngaran — anu aya dina simpul koordinator. Data henteu diduplikasi antara simpul. Inpormasi konci ogé disimpen dina unggal simpul, tapi sistemna gaduh detektor deadlock global.
Nalika nyambung ka klaster HANA, klien ngaunduh topologi na teras tiasa langsung ngaksés simpul naon waé gumantung kana data anu diperyogikeun. Upami transaksi mangaruhan data dina hiji simpul, éta tiasa dieksekusi sacara lokal ku simpul éta. Nanging, upami data dina sababaraha simpul dirobih, simpul anu ngamimitian ngahubungi simpul koordinator, anu muka sareng koordinasi transaksi anu disebarkeun, ngalakukeunana nganggo protokol komitmen dua fase anu dioptimalkeun.
Node koordinator diduplikasi, janten upami koordinator gagal, node cadangan langsung ngambil alih. Nanging, upami node data gagal, hiji-hijina cara pikeun ngaksés datana nyaéta ku cara ngamimitian deui node éta. Biasana, klaster HANA ngajaga server cadangan pikeun ngamimitian deui node anu leungit gancang-gancang.
sumber: www.habr.com
