Teorema CAP adalah landasan teori sistem terdistribusi. Tentu saja, kontroversi seputar hal ini tidak mereda: definisi di dalamnya tidak kanonik, dan tidak ada bukti yang kuat... Namun demikian, dengan teguh berpegang pada posisi akal sehat sehari-hari™, kami secara intuitif memahami bahwa teorema tersebut benar.
Satu-satunya hal yang tidak jelas adalah arti huruf "P". Ketika cluster terpecah, cluster memutuskan apakah akan merespons hingga kuorum tercapai, atau mengembalikan data yang tersedia. Tergantung pada hasil pilihan ini, sistem diklasifikasikan sebagai CP atau AP. Cassandra, misalnya, dapat berperilaku apa pun, bahkan tidak bergantung pada pengaturan cluster, tetapi pada parameter setiap permintaan spesifik. Tetapi jika sistemnya bukan "P" dan terpecah, lalu bagaimana?
Jawaban atas pertanyaan ini agak tidak terduga: cluster CA tidak dapat dipecah.
Cluster macam apa ini yang tidak bisa dipecah?
Atribut yang sangat diperlukan dari cluster tersebut adalah sistem penyimpanan data bersama. Dalam sebagian besar kasus, hal ini berarti menghubungkan melalui SAN, yang membatasi penggunaan solusi CA untuk perusahaan besar yang mampu memelihara infrastruktur SAN. Agar beberapa server dapat bekerja dengan data yang sama, diperlukan sistem file berkerumun. Sistem file tersebut tersedia dalam portofolio HPE (CFS), Veritas (VxCFS) dan IBM (GPFS).
Oracle RAC
Opsi Real Application Cluster pertama kali muncul pada tahun 2001 dengan dirilisnya Oracle 9i. Dalam cluster seperti itu, beberapa instance server bekerja dengan database yang sama.
Oracle dapat bekerja dengan sistem file cluster dan solusinya sendiri - ASM, Manajemen Penyimpanan Otomatis.
Setiap salinan menyimpan jurnalnya sendiri. Transaksi dieksekusi dan dilakukan oleh satu instance. Jika sebuah instance gagal, salah satu node cluster yang masih hidup (instances) membaca lognya dan memulihkan data yang hilang - sehingga memastikan ketersediaannya.
Semua instance memelihara cache-nya sendiri, dan halaman (blok) yang sama dapat berada di cache beberapa instance secara bersamaan. Terlebih lagi, jika suatu instance memerlukan sebuah halaman dan halaman tersebut berada dalam cache instance lain, instance tersebut dapat memperolehnya dari tetangganya menggunakan mekanisme fusi cache alih-alih membaca dari disk.
Namun apa yang terjadi jika salah satu instance perlu mengubah data?
Keunikan Oracle adalah tidak memiliki layanan penguncian khusus: jika server ingin mengunci suatu baris, maka catatan kunci ditempatkan langsung pada halaman memori tempat baris yang dikunci berada. Berkat pendekatan ini, Oracle menjadi juara kinerja di antara database monolitik: layanan penguncian tidak pernah menjadi hambatan. Namun dalam konfigurasi cluster, arsitektur seperti itu dapat menyebabkan lalu lintas jaringan yang intens dan kebuntuan.
Setelah rekaman dikunci, sebuah instance akan memberitahukan semua instance lainnya bahwa halaman yang menyimpan rekaman tersebut memiliki penangguhan eksklusif. Jika instance lain perlu mengubah catatan pada halaman yang sama, maka harus menunggu hingga perubahan pada halaman tersebut dilakukan, yaitu, informasi perubahan ditulis ke jurnal pada disk (dan transaksi dapat dilanjutkan). Mungkin juga suatu halaman akan diubah secara berurutan sebanyak beberapa salinan, dan kemudian ketika menulis halaman tersebut ke disk, Anda harus mencari tahu siapa yang menyimpan versi saat ini dari halaman ini.
Memperbarui halaman yang sama secara acak di seluruh node RAC yang berbeda menyebabkan performa database turun drastis, hingga ke titik di mana performa cluster bisa lebih rendah dibandingkan performa instance tunggal.
Penggunaan Oracle RAC yang benar adalah mempartisi data secara fisik (misalnya, menggunakan mekanisme tabel yang dipartisi) dan mengakses setiap kumpulan partisi melalui node khusus. Tujuan utama RAC bukanlah penskalaan horizontal, namun memastikan toleransi kesalahan.
Jika sebuah node berhenti merespons detak jantung, maka node yang mendeteksinya terlebih dahulu memulai prosedur pemungutan suara pada disk. Jika node yang hilang tidak dicatat di sini, maka salah satu node bertanggung jawab atas pemulihan data:
- "membekukan" semua halaman yang ada di cache dari node yang hilang;
- membaca log (mengulang) dari node yang hilang dan menerapkan kembali perubahan yang dicatat dalam log ini, sekaligus memeriksa apakah node lain memiliki versi halaman yang lebih baru yang diubah;
- mengembalikan transaksi yang tertunda.
Untuk menyederhanakan peralihan antar node, Oracle memiliki konsep layanan - mesin virtual. Sebuah instance dapat melayani beberapa layanan, dan sebuah layanan dapat berpindah antar node. Sebuah instance aplikasi yang melayani bagian tertentu dari database (misalnya, sekelompok klien) bekerja dengan satu layanan, dan layanan yang bertanggung jawab atas bagian database tersebut berpindah ke node lain ketika sebuah node gagal.
Sistem Data Murni IBM untuk Transaksi
Solusi cluster untuk DBMS muncul dalam portofolio Blue Giant pada tahun 2009. Secara ideologis, ini adalah penerus cluster Parallel Sysplex, yang dibangun dengan peralatan “biasa”. Pada tahun 2009, DB2 pureScale dirilis sebagai rangkaian perangkat lunak, dan pada tahun 2012, IBM menawarkan alat yang disebut Sistem Data Murni untuk Transaksi. Berbeda dengan Sistem Data Murni untuk Analisis, yang tidak lebih dari Netezza yang berganti nama.
Sekilas, arsitektur pureScale mirip dengan Oracle RAC: dengan cara yang sama, beberapa node terhubung ke sistem penyimpanan data umum, dan setiap node menjalankan instans DBMSnya sendiri dengan area memori dan log transaksinya sendiri. Namun, tidak seperti Oracle, DB2 memiliki layanan penguncian khusus yang diwakili oleh serangkaian proses db2LLM*. Dalam konfigurasi cluster, layanan ini ditempatkan pada node terpisah, yang disebut fasilitas kopling (CF) di Parallel Sysplex, dan PowerHA di Pure Data.
PowerHA menyediakan layanan berikut:
- manajer kunci;
- cache penyangga global;
- bidang komunikasi antarproses.
Untuk mentransfer data dari PowerHA ke node database dan sebaliknya, akses memori jarak jauh digunakan, sehingga interkoneksi cluster harus mendukung protokol RDMA. PureScale dapat menggunakan Infiniband dan RDMA melalui Ethernet.
Jika sebuah node membutuhkan sebuah halaman, dan halaman ini tidak ada dalam cache, maka node tersebut meminta halaman tersebut dalam cache global, dan hanya jika tidak ada, membacanya dari disk. Tidak seperti Oracle, permintaan hanya ditujukan ke PowerHA, dan bukan ke node tetangga.
Jika sebuah instance akan mengubah sebuah baris, ia menguncinya dalam mode eksklusif, dan halaman tempat baris tersebut berada dalam mode bersama. Semua kunci terdaftar di manajer kunci global. Ketika transaksi selesai, node mengirimkan pesan ke manajer kunci, yang menyalin halaman yang dimodifikasi ke cache global, melepaskan kunci, dan membatalkan halaman yang dimodifikasi di cache node lain.
Jika halaman di mana baris yang dimodifikasi berada sudah dikunci, maka pengelola kunci akan membaca halaman yang dimodifikasi dari memori node yang melakukan perubahan, melepaskan kunci, membatalkan halaman yang dimodifikasi di cache node lain, dan berikan kunci halaman ke node yang memintanya.
“Kotor”, yaitu halaman yang diubah dapat ditulis ke disk baik dari node biasa maupun dari PowerHA (castout).
Jika salah satu node pureScale gagal, pemulihan terbatas hanya pada transaksi yang belum selesai pada saat kegagalan: halaman yang diubah oleh node tersebut dalam transaksi yang telah selesai berada dalam cache global di PowerHA. Node dimulai ulang dalam konfigurasi yang lebih kecil di salah satu server di cluster, mengembalikan transaksi yang tertunda dan melepaskan kunci.
PowerHA berjalan di dua server dan node master mereplikasi statusnya secara sinkron. Jika node PowerHA utama gagal, klaster akan terus beroperasi dengan node cadangan.
Tentu saja, jika Anda mengakses kumpulan data melalui satu node, performa cluster secara keseluruhan akan lebih tinggi. PureScale bahkan dapat melihat bahwa area data tertentu sedang diproses oleh satu node, dan kemudian semua kunci yang terkait dengan area tersebut akan diproses secara lokal oleh node tersebut tanpa berkomunikasi dengan PowerHA. Namun segera setelah aplikasi mencoba mengakses data ini melalui node lain, pemrosesan kunci terpusat akan dilanjutkan.
Pengujian internal IBM pada beban kerja 90% baca dan 10% tulis, yang sangat mirip dengan beban kerja produksi di dunia nyata, menunjukkan penskalaan yang hampir linier hingga 128 node. Sayangnya, kondisi pengujian tidak diungkapkan.
HPE SQL Tanpa Henti
Portofolio Hewlett-Packard Enterprise juga memiliki platform yang sangat tersedia. Ini adalah platform NonStop, dirilis ke pasar pada tahun 1976 oleh Tandem Computers. Pada tahun 1997, perusahaan ini diakuisisi oleh Compaq, yang kemudian bergabung dengan Hewlett-Packard pada tahun 2002.
NonStop digunakan untuk membangun aplikasi penting - misalnya, HLR atau pemrosesan kartu bank. Platform ini disampaikan dalam bentuk kompleks perangkat lunak dan perangkat keras (peralatan), yang mencakup node komputasi, sistem penyimpanan data, dan peralatan komunikasi. Jaringan ServerNet (dalam sistem modern - Infiniband) berfungsi untuk pertukaran antar node dan untuk akses ke sistem penyimpanan data.
Versi awal sistem menggunakan prosesor berpemilik yang disinkronkan satu sama lain: semua operasi dilakukan secara serempak oleh beberapa prosesor, dan segera setelah salah satu prosesor membuat kesalahan, prosesor tersebut dimatikan, dan prosesor kedua terus bekerja. Kemudian, sistem beralih ke prosesor konvensional (pertama MIPS, kemudian Itanium dan akhirnya x86), dan mekanisme lain mulai digunakan untuk sinkronisasi:
- pesan: setiap proses sistem memiliki kembaran “bayangan”, yang mana proses aktif secara berkala mengirimkan pesan tentang statusnya; jika proses utama gagal, proses bayangan mulai bekerja sejak saat yang ditentukan oleh pesan terakhir;
- voting: sistem penyimpanan memiliki komponen perangkat keras khusus yang menerima beberapa akses identik dan mengeksekusinya hanya jika akses tersebut cocok; Alih-alih sinkronisasi fisik, prosesor beroperasi secara asinkron, dan hasil kerjanya hanya dibandingkan pada momen I/O.
Sejak tahun 1987, DBMS relasional telah berjalan pada platform NonStop - pertama SQL/MP, dan kemudian SQL/MX.
Seluruh database dibagi menjadi beberapa bagian, dan setiap bagian bertanggung jawab atas proses Data Access Manager (DAM) sendiri. Ini menyediakan mekanisme perekaman data, caching, dan penguncian. Pemrosesan data dilakukan oleh Proses Server Pelaksana yang berjalan pada node yang sama dengan pengelola data terkait. Penjadwal SQL/MX membagi tugas di antara pelaksana dan mengumpulkan hasilnya. Ketika perubahan yang disepakati perlu dilakukan, protokol komit dua fase yang disediakan oleh perpustakaan TMF (Fasilitas Manajemen Transaksi) digunakan.
NonStop SQL dapat memprioritaskan proses sehingga kueri analitis yang panjang tidak mengganggu eksekusi transaksi. Namun, tujuannya justru pada pemrosesan transaksi singkat, dan 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 bulan November 2010, dan paket SAP ERP dialihkan ke HANA pada bulan Mei 2013. Platform ini didasarkan pada teknologi yang dibeli: TREX Search Engine (pencarian dalam penyimpanan kolom), P*TIME DBMS, dan MAX DB.
Kata “HANA” sendiri merupakan akronim dari High performance ANalytical Appliance. DBMS ini disediakan dalam bentuk kode yang dapat dijalankan di server x86 mana pun, namun instalasi industri hanya diperbolehkan pada peralatan bersertifikat. Solusi tersedia dari HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Beberapa konfigurasi Lenovo bahkan mengizinkan pengoperasian tanpa SAN - peran sistem penyimpanan umum dimainkan oleh cluster GPFS pada disk lokal.
Berbeda dengan platform yang tercantum di atas, HANA adalah DBMS dalam memori, yaitu gambar data utama disimpan dalam 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 tidak diduplikasi antar node. Informasi penguncian juga disimpan di setiap node, namun sistem memiliki detektor kebuntuan global.
Ketika klien HANA terhubung ke sebuah cluster, ia mengunduh topologinya dan kemudian dapat mengakses node mana pun secara langsung, bergantung pada data apa yang dibutuhkannya. Jika suatu transaksi mempengaruhi data dari satu node, maka transaksi tersebut dapat dieksekusi secara lokal oleh node tersebut, namun jika data dari beberapa node berubah, node yang memulai menghubungi node koordinator, yang membuka dan mengoordinasikan transaksi terdistribusi, melakukan transaksi tersebut menggunakan sebuah 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 mengakses datanya adalah dengan me-restart node tersebut. Sebagai aturan, cluster HANA memelihara server cadangan untuk memulai kembali node yang hilang secepat mungkin.
Sumber: www.habr.com