Satu-satunya hal yang tidak jelas adalah arti huruf "P". Ketika gugus dibagi, ia memutuskan apakah tidak akan menanggapi hingga kuorum tercapai, atau memberikan data yang ada. Bergantung pada hasil pemilihan ini, sistem diklasifikasikan sebagai CP atau AP. Cassandra, misalnya, dapat berperilaku seperti ini dan itu, tidak tergantung bahkan pada pengaturan cluster, tetapi pada parameter dari setiap permintaan khusus. Tetapi jika sistemnya bukan "P" dan telah terbelah, lalu apa?
Jawaban atas pertanyaan ini agak tidak terduga: kluster CA tidak dapat dipisahkan.
Apa cluster ini yang tidak dapat dipisahkan?
Atribut yang sangat diperlukan dari cluster tersebut adalah sistem penyimpanan data bersama. Dalam sebagian besar kasus, ini berarti menghubungkan melalui SAN, yang membatasi penggunaan solusi CA untuk perusahaan besar yang dapat menjadi host infrastruktur SAN. Agar beberapa server dapat bekerja dengan data yang sama, diperlukan sistem file berkerumun. Sistem file semacam itu ditemukan dalam portofolio HPE (CFS), Veritas (VxCFS) dan IBM (GPFS).
Oracle RAC
Opsi Real Application Cluster pertama kali muncul pada rilis 2001 Oracle 9i. Dalam cluster seperti beberapa contoh server bekerja dengan database yang sama.
Oracle dapat bekerja dengan sistem file cluster dan solusinya sendiri - ASM, Manajemen Penyimpanan Otomatis.
Setiap salinan membuat jurnalnya sendiri. Transaksi dijalankan dan dilakukan dalam satu contoh. Jika terjadi kegagalan instans, salah satu node kluster (instans) yang bertahan membaca log-nya dan memulihkan data yang hilang, sehingga memastikan ketersediaan.
Semua instance mempertahankan cache-nya sendiri, dan halaman (blok) yang sama dapat disimpan secara bersamaan di cache beberapa instance. Selain itu, jika halaman diperlukan oleh satu instance, dan berada di cache instance lain, halaman tersebut bisa mendapatkannya dari "tetangga" menggunakan mekanisme fusi cache alih-alih membaca dari disk.
Tetapi apa yang terjadi jika salah satu contoh perlu mengubah data?
Keunikan Oracle adalah bahwa ia tidak memiliki layanan penguncian khusus: jika server ingin mengunci sebuah baris, maka catatan kunci ditempatkan langsung di halaman memori tempat baris yang dikunci berada. Pendekatan ini menjadikan Oracle juara kinerja database monolitik: layanan kunci tidak pernah menjadi hambatan. Namun dalam konfigurasi berkerumun, arsitektur ini dapat menyebabkan lalu lintas jaringan yang padat dan kebuntuan.
Segera setelah record diblokir, instance tersebut memberi tahu semua instance lain bahwa halaman yang menyimpan record telah diperoleh dalam mode eksklusif. Jika contoh lain perlu mengubah catatan pada halaman yang sama, itu harus menunggu sampai perubahan pada halaman dilakukan, yaitu, informasi perubahan ditulis ke log di disk (dan transaksi dapat dilanjutkan). Mungkin juga terjadi bahwa halaman akan diubah secara berurutan oleh beberapa salinan, dan kemudian, saat menulis halaman ke disk, Anda harus mencari tahu siapa yang memiliki versi terkini dari halaman ini.
Refresh halaman yang sama secara tidak sengaja di node RAC yang berbeda secara dramatis menurunkan kinerja database - ke titik di mana kinerja cluster bisa lebih lambat daripada satu instance.
Penggunaan yang benar dari Oracle RAC adalah untuk mempartisi data secara fisik (misalnya, menggunakan mekanisme tabel yang dipartisi) dan mengakses setiap rangkaian partisi melalui node khusus. Tujuan utama dari RAC bukanlah penskalaan horizontal, tetapi toleransi kesalahan.
Jika sebuah node berhenti merespons detak jantung, maka node yang mendeteksi ini pertama kali memulai prosedur pemungutan suara disk. Jika node yang hilang tidak dicatat di sini, maka salah satu node bertanggung jawab untuk pemulihan data:
- "Membekukan" semua halaman yang berada di cache dari node yang hilang;
- Membaca log (ulangi) dari node yang hilang dan menerapkan kembali perubahan yang dicatat dalam log ini, sambil memeriksa apakah node lain memiliki versi yang lebih baru dari halaman yang diubah;
- memutar kembali transaksi yang belum terikat.
Untuk menyederhanakan perpindahan antar node, Oracle memiliki konsep layanan - contoh virtual. Sebuah instance dapat melayani banyak layanan, dan sebuah layanan dapat berpindah antar node. Contoh aplikasi yang melayani bagian tertentu dari basis (misalnya, sekelompok klien) bekerja dengan satu layanan, dan layanan yang bertanggung jawab untuk bagian basis ini, ketika sebuah node gagal, pindah ke node lain.
Sistem Data Murni IBM untuk Transaksi
Solusi cluster untuk DBMS muncul di portofolio Blue Giant pada tahun 2009. Secara ideologis, ini adalah pewaris cluster Parallel Sysplex yang dibangun di atas perangkat keras "konvensional". Pada tahun 2009, DB2 pureScale dirilis sebagai rangkaian perangkat lunak, dan pada tahun 2012 IBM menawarkan alat yang disebut Sistem Data Murni untuk Transaksi. Jangan bingung dengan Pure Data Systems for Analytics, yang tidak lebih dari Netezza yang diubah namanya.
Arsitektur pureScale terlihat seperti Oracle RAC pada pandangan pertama: dengan cara yang sama, beberapa node terhubung ke sistem penyimpanan bersama, dan setiap node menjalankan instance DBMS-nya sendiri dengan area memori dan log transaksinya sendiri. Tetapi tidak seperti Oracle, DB2 memiliki layanan penguncian khusus yang diwakili oleh set proses db2LLM *. Dalam konfigurasi cluster, layanan ini ditempatkan pada node terpisah, yang disebut fasilitas kopling (CF) di Sysplex Paralel, dan PowerHA di Data Murni.
PowerHA menyediakan layanan berikut:
- manajer kunci;
- cache buffer global;
- bidang komunikasi antar proses.
Akses memori jarak jauh digunakan untuk mentransfer data dari PowerHA ke node database dan sebaliknya, sehingga interkoneksi cluster harus mendukung protokol RDMA. PureScale dapat menggunakan Infiniband dan RDMA melalui Ethernet.
Jika node membutuhkan halaman, dan halaman ini tidak ada di cache, node meminta halaman di cache global, dan hanya jika tidak ada, halaman ini akan membacanya dari disk. Tidak seperti Oracle, kueri hanya masuk ke PowerHA dan bukan ke node tetangga.
Jika instance akan mengubah string, itu memblokirnya dalam mode eksklusif, dan halaman tempat string berada dalam mode bersama. Semua kunci terdaftar di manajer kunci global. Saat transaksi selesai, node mengirimkan pesan ke manajer kunci, yang menyalin halaman yang diubah ke cache global, melepaskan kunci, dan membatalkan halaman yang diubah di cache node lain.
Jika halaman yang berisi string yang dimodifikasi sudah dikunci, maka pengelola kunci akan membaca halaman yang dimodifikasi dari memori node yang membuat perubahan, melepaskan kunci, membatalkan halaman yang dimodifikasi di cache node lain, dan memberikan kunci halaman ke node yang memintanya.
"Dirty", yaitu, diubah, halaman dapat ditulis ke disk baik dari node biasa maupun dari PowerHA (castout).
Jika salah satu node pureScale gagal, pemulihan dibatasi hanya untuk transaksi yang belum selesai pada saat kegagalan: halaman yang diubah oleh node tersebut dalam transaksi yang diselesaikan berada di cache global di PowerHA. Node dimulai ulang dalam konfigurasi yang dipreteli di salah satu server cluster, memutar kembali transaksi yang tidak terikat dan melepaskan kunci.
PowerHA berjalan pada dua server dan node master mereplikasi statusnya secara sinkron. Jika node PowerHA utama gagal, cluster terus beroperasi dengan node siaga.
Tentu saja, jika Anda mengakses dataset melalui satu node, kinerja cluster secara keseluruhan akan lebih baik. PureScale bahkan mungkin memperhatikan bahwa beberapa area data sedang diproses oleh satu node, dan kemudian semua kunci yang terkait dengan area ini akan diproses secara lokal oleh node tanpa berkomunikasi dengan PowerHA. Tetapi segera setelah aplikasi mencoba mengakses data ini melalui node lain, pemrosesan kunci terpusat akan dilanjutkan.
Tolok ukur internal IBM pada beban kerja baca 90% dan tulis 10%, sangat mirip dengan beban produksi nyata, menunjukkan penskalaan hampir linier hingga 128 node. Kondisi pengujian, sayangnya, tidak diungkapkan.
HPE NonStop SQL
Portofolio Hewlett-Packard Enterprise juga memiliki platformnya sendiri yang sangat tersedia. Ini adalah platform NonStop yang diluncurkan pada tahun 1976 oleh Tandem Computers. Pada tahun 1997, perusahaan tersebut diambil alih oleh Compaq, yang kemudian bergabung dengan Hewlett-Packard pada tahun 2002.
NonStop digunakan untuk membangun aplikasi penting - misalnya, HLR atau pemrosesan kartu bank. Platform tersebut disampaikan dalam bentuk kompleks perangkat lunak dan perangkat keras (appliance), yang meliputi node komputasi, sistem penyimpanan data, dan peralatan komunikasi. ServerNet (dalam sistem modern - Infiniband) berfungsi baik untuk pertukaran antar node dan untuk akses ke sistem penyimpanan data.
Versi sebelumnya dari sistem menggunakan prosesor berpemilik yang disinkronkan satu sama lain: semua operasi dilakukan secara serempak oleh beberapa prosesor, dan segera setelah salah satu prosesor salah, prosesor dimatikan, dan yang lainnya terus bekerja. Kemudian, sistem beralih ke prosesor konvensional (MIPS pertama, lalu Itanium, dan terakhir x86), dan mekanisme lain mulai digunakan untuk sinkronisasi:
- pesan: setiap proses sistem memiliki kembaran "bayangan", di mana proses aktif secara berkala mengirimkan pesan tentang statusnya; jika proses utama gagal, proses bayangan mulai bekerja dari saat yang ditentukan oleh pesan terakhir;
- : , , ; , /.
Sejak 1987, DBMS relasional telah berjalan di platform NonStop - SQL / MP pertama, dan kemudian SQL / MX.
Seluruh database dibagi menjadi beberapa bagian, dan setiap bagian bertanggung jawab atas proses Data Access Manager (DAM) -nya sendiri. Ini menyediakan penulisan data, caching dan mekanisme penguncian. Pemrosesan data ditangani oleh Proses Server Pelaksana, yang berjalan pada node yang sama dengan manajer data masing-masing. Penjadwal SQL / MX membagi tugas antara pelaksana dan menggabungkan hasilnya. Jika perlu membuat perubahan yang konsisten, protokol komit dua fase yang disediakan oleh pustaka TMF (Transaction Management Facility) digunakan.
NonStop SQL tahu bagaimana memprioritaskan proses sehingga kueri analitik yang panjang tidak mengganggu pelaksanaan transaksi. Namun, tujuannya justru untuk memproses transaksi singkat, bukan analitik. Pengembang menjamin ketersediaan cluster NonStop pada level lima sembilan, yaitu downtime hanya 5 menit per tahun.
SAP HANA
Rilis stabil pertama dari HANA DBMS (1.0) berlangsung pada November 2010, dan paket SAP ERP dipindahkan ke HANA pada Mei 2013. Platform ini didasarkan pada teknologi yang dibeli: Mesin Pencari TREX (pencarian dalam penyimpanan kolom), P * TIME dan MAX DB.
Kata "HANA" sendiri merupakan singkatan dari High Performance ANalytical Appliance. DBMS ini dikirimkan dalam bentuk kode yang dapat dijalankan di server x86 mana pun, namun, instalasi industri hanya diperbolehkan pada peralatan bersertifikat. Ada solusi dari HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Beberapa konfigurasi Lenovo bahkan mengizinkan operasi tanpa SAN - kluster GPFS pada disk lokal memainkan peran sebagai penyimpanan bersama.
Tidak seperti platform yang tercantum di atas, HANA adalah DBMS dalam memori, yaitu gambar utama dari data disimpan di RAM, dan hanya log dan snapshot berkala yang ditulis ke disk untuk pemulihan jika terjadi bencana.
Setiap node cluster HANA bertanggung jawab atas bagian datanya sendiri, dan peta data disimpan dalam komponen khusus - Server Nama, yang terletak di node koordinator. Data antar node tidak diduplikasi. Informasi kunci juga disimpan di setiap node, tetapi sistem memiliki detektor kebuntuan global.
Klien HANA, saat terhubung ke sebuah cluster, memuat topologinya dan di masa mendatang dapat langsung mengakses node mana pun, tergantung pada data apa yang dibutuhkannya. Jika suatu transaksi mempengaruhi data dari satu node, maka itu dapat dilakukan oleh node ini secara lokal, tetapi jika data dari beberapa node berubah, maka node inisiator menghubungi node koordinator, yang membuka dan mengkoordinasikan transaksi terdistribusi, melakukan itu menggunakan protokol komit dua fase yang dioptimalkan.
Node koordinator diduplikasi, jadi jika koordinator gagal, node cadangan segera mengambil alih. Tetapi jika sebuah node dengan data gagal, maka satu-satunya cara untuk mendapatkan akses ke datanya adalah dengan merestart node. Sebagai aturan, dalam cluster HANA, server cadangan disimpan untuk memulai kembali node yang hilang di atasnya sesegera mungkin.