Teorem CAP ialah asas teori sistem teragih. Sudah tentu, kontroversi yang mengelilinginya tidak reda: takrifan di dalamnya bukan kanonik, dan tidak ada bukti yang tegas... Namun begitu, berdiri teguh di atas kedudukan akal sehat setiap hari, kami secara intuitif memahami bahawa teorem itu adalah benar.
Satu-satunya perkara yang tidak jelas ialah maksud huruf "P". Apabila kluster dibahagikan, ia memutuskan sama ada untuk tidak bertindak balas sehingga kuorum dicapai, atau untuk memberikan semula data yang tersedia. Bergantung pada keputusan pilihan ini, sistem dikelaskan sebagai sama ada CP atau AP. Cassandra, sebagai contoh, boleh bertindak dengan cara sama ada, tidak bergantung pada tetapan kluster, tetapi pada parameter setiap permintaan khusus. Tetapi jika sistem itu bukan "P" dan ia berpecah, maka apa?
Jawapan kepada soalan ini agak tidak dijangka: kluster CA tidak boleh berpecah.
Kelompok apakah ini yang tidak boleh berpecah?
Atribut yang sangat diperlukan bagi kluster tersebut ialah sistem penyimpanan data yang dikongsi. Dalam kebanyakan kes, ini bermakna menyambung melalui SAN, yang mengehadkan penggunaan penyelesaian CA kepada perusahaan besar yang mampu mengekalkan infrastruktur SAN. Untuk membolehkan berbilang pelayan berfungsi dengan data yang sama, sistem fail berkelompok diperlukan. Sistem fail sedemikian tersedia dalam portfolio HPE (CFS), Veritas (VxCFS) dan IBM (GPFS).
Oracle RAC
Pilihan Kluster Aplikasi Sebenar mula-mula muncul pada tahun 2001 dengan keluaran Oracle 9i. Dalam kluster sedemikian, beberapa contoh pelayan berfungsi dengan pangkalan data yang sama.
Oracle boleh berfungsi dengan kedua-dua sistem fail berkelompok dan penyelesaiannya sendiri - ASM, Pengurusan Storan Automatik.
Setiap salinan menyimpan jurnalnya sendiri. Urus niaga dilaksanakan dan dilakukan oleh satu contoh. Jika kejadian gagal, salah satu daripada nod kluster yang masih hidup (kejadian) membaca lognya dan memulihkan data yang hilang - dengan itu memastikan ketersediaan.
Semua kejadian mengekalkan cache mereka sendiri, dan halaman (blok) yang sama boleh berada dalam cache berbilang kejadian pada masa yang sama. Selain itu, jika satu contoh memerlukan halaman dan ia berada dalam cache contoh lain, ia boleh mendapatkannya daripada jirannya menggunakan mekanisme gabungan cache dan bukannya membaca dari cakera.
Tetapi apa yang berlaku jika salah satu keadaan perlu menukar data?
Keistimewaan Oracle ialah ia tidak mempunyai perkhidmatan penguncian khusus: jika pelayan ingin mengunci baris, maka rekod kunci diletakkan terus pada halaman memori di mana baris terkunci berada. Terima kasih kepada pendekatan ini, Oracle adalah juara prestasi di kalangan pangkalan data monolitik: perkhidmatan penguncian tidak pernah menjadi halangan. Tetapi dalam konfigurasi kluster, seni bina sedemikian boleh membawa kepada trafik rangkaian yang sengit dan kebuntuan.
Setelah rekod dikunci, tika memberitahu semua kejadian lain bahawa halaman yang menyimpan rekod itu mempunyai penahanan eksklusif. Jika contoh lain perlu menukar rekod pada halaman yang sama, ia mesti menunggu sehingga perubahan pada halaman dilakukan, iaitu, maklumat perubahan ditulis pada jurnal pada cakera (dan transaksi boleh diteruskan). Ia juga mungkin berlaku bahawa halaman akan diubah secara berurutan oleh beberapa salinan, dan kemudian apabila menulis halaman ke cakera anda perlu mengetahui siapa yang menyimpan versi semasa halaman ini.
Mengemas kini halaman yang sama secara rawak merentas nod RAC yang berbeza menyebabkan prestasi pangkalan data menurun secara mendadak, sehingga prestasi kluster boleh menjadi lebih rendah daripada satu kejadian.
Penggunaan Oracle RAC yang betul adalah untuk membahagikan data secara fizikal (contohnya, menggunakan mekanisme jadual pembahagian) dan mengakses setiap set partition melalui nod khusus. Tujuan utama RAC bukanlah penskalaan mendatar, tetapi memastikan toleransi kesalahan.
Jika nod berhenti bertindak balas kepada degupan jantung, maka nod yang mengesannya mula-mula memulakan prosedur pengundian pada cakera. Jika nod yang hilang tidak dinyatakan di sini, maka salah satu nod bertanggungjawab untuk pemulihan data:
- "membekukan" semua halaman yang berada dalam cache nod yang hilang;
- membaca log (buat semula) nod yang hilang dan menggunakan semula perubahan yang direkodkan dalam log ini, pada masa yang sama menyemak sama ada nod lain mempunyai versi halaman yang lebih terkini yang diubah;
- melancarkan semula urus niaga yang belum selesai.
Untuk memudahkan pertukaran antara nod, Oracle mempunyai konsep perkhidmatan - contoh maya. Satu contoh boleh memberi perkhidmatan berbilang dan perkhidmatan boleh bergerak antara nod. Contoh aplikasi yang menyediakan bahagian tertentu pangkalan data (contohnya, sekumpulan pelanggan) berfungsi dengan satu perkhidmatan, dan perkhidmatan yang bertanggungjawab untuk bahagian pangkalan data ini berpindah ke nod lain apabila nod gagal.
Sistem Data Tulen IBM untuk Transaksi
Penyelesaian kluster untuk DBMS muncul dalam portfolio Blue Giant pada tahun 2009. Secara ideologinya, ia adalah pengganti gugusan Sysplex Parallel, dibina di atas peralatan "biasa". Pada tahun 2009, DB2 pureScale telah dikeluarkan sebagai suite perisian, dan pada tahun 2012, IBM menawarkan perkakas yang dipanggil Sistem Data Tulen untuk Transaksi. Ia tidak boleh dikelirukan dengan Sistem Data Tulen untuk Analitis, yang tidak lebih daripada Netezza yang dinamakan semula.
Pada pandangan pertama, seni bina pureScale adalah serupa dengan Oracle RAC: dengan cara yang sama, beberapa nod disambungkan kepada sistem storan data biasa, dan setiap nod menjalankan contoh DBMS sendiri dengan kawasan memori dan log transaksinya sendiri. Tetapi, tidak seperti Oracle, DB2 mempunyai perkhidmatan penguncian khusus yang diwakili oleh satu set proses db2LLM*. Dalam konfigurasi kelompok, perkhidmatan ini diletakkan pada nod yang berasingan, yang dipanggil kemudahan gandingan (CF) dalam Sysplex Selari, dan PowerHA dalam Data Tulen.
PowerHA menyediakan perkhidmatan berikut:
- pengurus kunci;
- cache penimbal global;
- bidang komunikasi antara proses.
Untuk memindahkan data daripada PowerHA ke nod pangkalan data dan belakang, akses memori jauh digunakan, jadi sambung kluster mesti menyokong protokol RDMA. PureScale boleh menggunakan kedua-dua Infiniband dan RDMA melalui Ethernet.
Jika nod memerlukan halaman, dan halaman ini tiada dalam cache, maka nod meminta halaman dalam cache global, dan hanya jika ia tidak ada, membacanya dari cakera. Tidak seperti Oracle, permintaan itu hanya pergi ke PowerHA, dan bukan ke nod jiran.
Jika tika akan menukar baris, ia menguncinya dalam mod eksklusif dan halaman tempat baris itu terletak dalam mod kongsi. Semua kunci didaftarkan dalam pengurus kunci global. Apabila transaksi selesai, nod menghantar mesej kepada pengurus kunci, yang menyalin halaman yang diubah suai ke cache global, melepaskan kunci dan membatalkan halaman yang diubah suai dalam cache nod lain.
Jika halaman di mana baris yang diubah suai berada telah dikunci, maka pengurus kunci akan membaca halaman yang diubah suai dari memori nod yang membuat perubahan, melepaskan kunci, membatalkan halaman yang diubah suai dalam cache nod lain dan berikan kunci halaman kepada nod yang memintanya.
"Kotor", iaitu, diubah, halaman boleh ditulis ke cakera kedua-duanya dari nod biasa dan dari PowerHA (castout).
Jika salah satu nod pureScale gagal, pemulihan terhad kepada hanya transaksi yang belum selesai pada masa kegagalan: halaman yang diubah suai oleh nod tersebut dalam transaksi yang telah lengkap berada dalam cache global pada PowerHA. Nod dimulakan semula dalam konfigurasi yang dikurangkan pada salah satu pelayan dalam kelompok, melancarkan transaksi yang belum selesai dan melepaskan kunci.
PowerHA berjalan pada dua pelayan dan nod induk mereplikasi keadaannya secara serentak. Jika nod PowerHA utama gagal, kluster akan terus beroperasi dengan nod sandaran.
Sudah tentu, jika anda mengakses set data melalui satu nod, prestasi keseluruhan kluster akan lebih tinggi. PureScale bahkan dapat melihat bahawa kawasan tertentu data sedang diproses oleh satu nod, dan kemudian semua kunci yang berkaitan dengan kawasan itu akan diproses secara setempat oleh nod tanpa berkomunikasi dengan PowerHA. Tetapi sebaik sahaja aplikasi cuba mengakses data ini melalui nod lain, pemprosesan kunci berpusat akan disambung semula.
Ujian dalaman IBM pada beban kerja 90% membaca dan 10% menulis, yang hampir sama dengan beban kerja pengeluaran dunia sebenar, menunjukkan penskalaan hampir linear sehingga 128 nod. Syarat ujian, malangnya, tidak didedahkan.
SQL Tanpa Henti HPE
Portfolio Hewlett-Packard Enterprise juga mempunyai platformnya sendiri yang sangat tersedia. Ini ialah platform NonStop, dikeluarkan ke pasaran pada tahun 1976 oleh Tandem Computers. Pada tahun 1997, syarikat itu telah diambil alih oleh Compaq, yang seterusnya bergabung dengan Hewlett-Packard pada tahun 2002.
NonStop digunakan untuk membina aplikasi kritikal - contohnya, HLR atau pemprosesan kad bank. Platform ini dihantar dalam bentuk kompleks perisian dan perkakasan (perkakas), yang merangkumi nod pengkomputeran, sistem penyimpanan data dan peralatan komunikasi. Rangkaian ServerNet (dalam sistem moden - Infiniband) berfungsi untuk pertukaran antara nod dan untuk akses kepada sistem penyimpanan data.
Versi awal sistem menggunakan pemproses proprietari yang disegerakkan antara satu sama lain: semua operasi dilakukan secara serentak oleh beberapa pemproses, dan sebaik sahaja salah satu pemproses membuat ralat, ia dimatikan, dan yang kedua terus berfungsi. Kemudian, sistem bertukar kepada pemproses konvensional (MIPS pertama, kemudian Itanium dan akhirnya x86), dan mekanisme lain mula digunakan untuk penyegerakan:
- mesej: setiap proses sistem mempunyai kembar "bayangan", yang mana proses aktif secara berkala menghantar mesej tentang statusnya; jika proses utama gagal, proses bayangan mula berfungsi dari saat yang ditentukan oleh mesej terakhir;
- undian: sistem storan mempunyai komponen perkakasan khas yang menerima berbilang akses yang sama dan melaksanakannya hanya jika akses sepadan; Daripada penyegerakan fizikal, pemproses beroperasi secara tidak segerak, dan hasil kerja mereka dibandingkan hanya pada detik I/O.
Sejak tahun 1987, DBMS hubungan telah dijalankan pada platform NonStop - SQL/MP pertama, dan kemudian SQL/MX.
Seluruh pangkalan data dibahagikan kepada beberapa bahagian, dan setiap bahagian bertanggungjawab untuk proses Pengurus Akses Data (DAM) sendiri. Ia menyediakan rakaman data, caching dan mekanisme penguncian. Pemprosesan data dijalankan oleh Proses Pelayan Pelaksana yang berjalan pada nod yang sama dengan pengurus data yang sepadan. Penjadual SQL/MX membahagikan tugas antara pelaksana dan mengagregatkan hasilnya. Apabila perlu untuk membuat perubahan yang dipersetujui, protokol komit dua fasa yang disediakan oleh perpustakaan TMF (Transaction Management Facility) digunakan.
SQL NonStop boleh mengutamakan proses supaya pertanyaan analisis yang panjang tidak mengganggu pelaksanaan transaksi. Walau bagaimanapun, tujuannya adalah tepat untuk pemprosesan transaksi pendek, dan bukan analisis. Pembangun menjamin ketersediaan kluster NonStop pada tahap lima "sembilan", iaitu, masa henti hanya 5 minit setahun.
SAP-HANA
Keluaran stabil pertama HANA DBMS (1.0) berlaku pada November 2010, dan pakej SAP ERP bertukar kepada HANA pada Mei 2013. Platform ini berdasarkan teknologi yang dibeli: Enjin Carian TREX (cari dalam storan kolumnar), P*TIME DBMS dan MAX DB.
Perkataan "HANA" itu sendiri ialah akronim, Perkakas Analitik berprestasi tinggi. DBMS ini dibekalkan dalam bentuk kod yang boleh dijalankan pada mana-mana pelayan x86, bagaimanapun, pemasangan industri hanya dibenarkan pada peralatan yang diperakui. Penyelesaian tersedia daripada HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Beberapa konfigurasi Lenovo malah membenarkan operasi tanpa SAN - peranan sistem storan biasa dimainkan oleh kelompok GPFS pada cakera tempatan.
Tidak seperti platform yang disenaraikan di atas, HANA ialah DBMS dalam memori, iaitu imej data utama disimpan dalam RAM, dan hanya log dan syot kilat berkala ditulis ke cakera untuk pemulihan sekiranya berlaku bencana.
Setiap nod kluster HANA bertanggungjawab ke atas bahagian datanya sendiri, dan peta data disimpan dalam komponen khas β Pelayan Nama, yang terletak pada nod penyelaras. Data tidak diduplikasi antara nod. Maklumat penguncian juga disimpan pada setiap nod, tetapi sistem mempunyai pengesan kebuntuan global.
Apabila pelanggan HANA menyambung ke kluster, ia memuat turun topologinya dan kemudian boleh mengakses sebarang nod secara langsung, bergantung pada data yang diperlukannya. Jika transaksi mempengaruhi data satu nod, maka ia boleh dilaksanakan secara setempat oleh nod itu, tetapi jika data beberapa nod berubah, nod permulaan menghubungi nod penyelaras, yang membuka dan menyelaraskan transaksi yang diedarkan, melakukannya menggunakan protokol komit dua fasa yang dioptimumkan.
Nod penyelaras diduakan, jadi jika penyelaras gagal, nod sandaran segera mengambil alih. Tetapi jika nod dengan data gagal, maka satu-satunya cara untuk mengakses datanya adalah untuk memulakan semula nod. Sebagai peraturan, kelompok HANA mengekalkan pelayan ganti untuk memulakan semula nod yang hilang padanya secepat mungkin.
Sumber: www.habr.com