Pacemaker untuk kelompok ketersediaan dan instans kluster failover di Linux

Aplikasi ke:SQL Server di Linux

Dimulai dengan SQL Server 2017 (14.x), SQL Server didukung di Linux dan Windows. Seperti penyebaran SQL Server berbasis Windows, database dan instans SQL Server harus sangat tersedia di bawah Linux. Artikel ini membahas informasi dasar untuk memahami Pacemaker dengan Corosync, dan cara merencanakan dan menyebarkannya untuk konfigurasi SQL Server.

Dasar-dasar ekstensi HA

Semua distribusi yang saat ini didukung mengirimkan add-on/ekstensi ketersediaan tinggi, yang didasarkan pada tumpukan pengklusteran Pacemaker. Tumpukan ini menggabungkan dua komponen utama: Pacemaker dan Corosync. Semua komponen stack adalah:

  • Alat pacu jantung. Komponen pengklusteran inti yang mengoordinasikan berbagai hal di seluruh komputer berkluster.
  • Corosync. Kerangka kerja dan set API yang menyediakan hal-hal seperti kuorum, kemampuan untuk memulai ulang proses yang gagal, dan sebagainya.
  • libQB. Menyediakan fitur seperti pencatatan log.
  • Agen sumber daya. Fungsionalitas khusus yang disediakan sehingga aplikasi dapat berintegrasi dengan Pacemaker.
  • Agen Fence Skrip/fungsionalitas yang membantu mengisolasi simpul dan menanganinya jika mengalami masalah.

Catatan

Tumpukan kluster biasanya disebut sebagai Pacemaker di dunia Linux.

Solusi ini dalam beberapa cara mirip dengan, tetapi dalam banyak hal berbeda dari menyebarkan konfigurasi berkluster menggunakan Windows. Dalam Windows, bentuk ketersediaan untuk pengklusteran, yang disebut kluster failover Windows Server (WSFC), terintegrasi ke dalam sistem operasi, dan fitur yang memungkinkan pembuatan WSFC, pengklusteran failover, dinonaktifkan dalam keadaan default. Dalam Windows, AG dan FCI dibangun di atas WSFC, dan berbagi integrasi yang ketat karena DLL sumber daya tertentu yang disediakan oleh SQL Server. Solusi yang digabungkan erat ini sebagian besar dimungkinkan karena semuanya berasal dari satu vendor.

Diagram membandingkan tumpukan ketersediaan tinggi Linux dan Windows. Tumpukan Linux menunjukkan SQL Server dengan Pacemaker dan Corosync pada distribusi Linux, sementara tumpukan Windows menunjukkan SQL Server dengan WSFC pada Windows Server. Keduanya berjalan pada komputer virtual melalui hypervisor dan hardware layers.

Di Linux, sementara setiap distribusi yang didukung memiliki Pacemaker yang tersedia, setiap distribusi dapat menyesuaikan dan memiliki implementasi dan versi yang sedikit berbeda. Beberapa perbedaan akan tercermin dalam instruksi dalam artikel ini. Lapisan pengklusteran ini bersifat open source, jadi meskipun disertakan dalam distribusi, lapisan pengklusteran ini tidak terintegrasi secara erat seperti WSFC terintegrasi di dalam Windows. Inilah sebabnya mengapa Microsoft menyediakan mssql-server-ha, sehingga SQL Server dan tumpukan Pacemaker dapat memberikan pengalaman yang hampir sama, tetapi tidak sepenuhnya identik, untuk AGs dan FCIs seperti di bawah Windows.

Untuk dokumentasi lengkap tentang Pacemaker, termasuk penjelasan lebih mendalam mengenai apa saja yang ada beserta informasi referensi lengkap, untuk RHEL dan SLES:

Catatan

Mulai SQL Server 2025 (17.x), SUSE Linux Enterprise Server (SLES) tidak didukung.

Untuk informasi selengkapnya tentang seluruh tumpukan, lihat juga halaman dokumentasi Pacemaker resmi di situs ClusterLabs.

Konsep dan terminologi Pacemaker

Bagian ini mendokumentasikan konsep dan terminologi umum untuk implementasi Pacemaker.

Simpul

Simpul adalah server yang berpartisipasi dalam kluster. Kluster Pacemaker secara asli mendukung hingga 16 simpul. Jumlah ini dapat terlampaui jika Corosync tidak berjalan pada simpul tambahan, tetapi Corosync diperlukan untuk SQL Server. Oleh karena itu, jumlah maksimum simpul yang dapat dimiliki kluster untuk konfigurasi berbasis SQL Server adalah 16; ini adalah batas Pacemaker, dan tidak ada hubungannya dengan batasan maksimum untuk AG atau FCI yang diberlakukan oleh SQL Server.

Sumber daya

Baik WSFC maupun kluster Pacemaker memiliki konsep sumber daya. Sumber daya adalah fungsionalitas khusus yang berjalan dalam konteks kluster, seperti disk atau alamat IP. Misalnya, di bawah Pacemaker, sumber daya FCI dan AG dapat dibuat. Ini tidak jauh berbeda dengan apa yang dilakukan di WSFC, di mana Anda menemukan sumber daya SQL Server untuk FCI atau AG ketika mengonfigurasi AG, tetapi tidak sama persis karena perbedaan dasar dalam cara SQL Server terintegrasi dengan Pacemaker.

Pacemaker memiliki sumber daya standar dan kloning. Sumber daya kloning adalah yang berjalan secara bersamaan pada semua simpul. Contohnya adalah alamat IP yang berjalan pada beberapa simpul untuk tujuan penyeimbangan beban. Sumber daya apa pun yang dibuat untuk FCI menggunakan sumber daya standar, karena hanya satu simpul yang dapat menghosting FCI pada waktu tertentu.

Catatan

Artikel ini berisi referensi ke istilah budak, istilah yang tidak lagi digunakan Microsoft. Ketika istilah tersebut dihapus dari perangkat lunak, kami menghapusnya dari artikel ini.

Ketika AG dibuat, AG memerlukan bentuk khusus dari sumber daya kloning yang disebut sumber daya multi-status. Meskipun AG hanya memiliki satu replika utama, AG itu sendiri berjalan di semua simpul yang dikonfigurasi untuk dikerjakan, dan berpotensi memungkinkan hal-hal seperti akses baca-saja. Karena ini adalah penggunaan simpul "langsung", sumber daya memiliki konsep dua status: Dipromosikan (sebelumnya Master) dan Tidak Dipromosikan (sebelumnya Budak). Untuk informasi selengkapnya, lihat Sumber daya multi-status: Sumber daya yang memiliki beberapa mode.

Grup/set sumber daya

Mirip dengan peran dalam WSFC, kluster Pacemaker memiliki konsep grup sumber daya. Grup sumber daya (disebut set di SLES) adalah kumpulan sumber daya yang berfungsi bersama-sama dan dapat melakukan failover dari satu simpul ke simpul lainnya sebagai satu unit. Grup sumber daya tidak dapat berisi sumber daya yang dikonfigurasi sebagai Dipromosikan atau Tidak Dipromosikan; dengan demikian, grup sumber daya tidak dapat digunakan untuk AG. Meskipun grup sumber daya dapat digunakan untuk FCI, grup sumber daya umumnya bukan konfigurasi yang direkomendasikan.

Kendala

WSFC memiliki berbagai parameter untuk sumber daya dan hal-hal seperti dependensi, yang memberi tahu WSFC tentang hubungan induk/anak antara dua sumber daya yang berbeda. Dependensi hanyalah aturan yang memberi tahu WSFC sumber daya mana yang harus online terlebih dahulu.

Kluster Pacemaker tidak memiliki konsep dependensi, tetapi ada batasan. Ada tiga jenis batasan: kolokasi, lokasi, dan pemesanan.

  • Batasan kolokasi memberlakukan apakah dua sumber daya harus berjalan pada node yang sama atau tidak.
  • Batasan lokasi memberi tahu kluster Pacemaker tempat sumber daya dapat (atau tidak dapat) berjalan.
  • Batasan urutan memberi tahu kluster Pacemaker mengenai urutan di mana sumber daya harus dimulai.

Catatan

Batasan kolokasi tidak diperlukan untuk sumber daya dalam grup sumber daya, karena semua batasan tersebut dipandang sebagai satu unit.

Quorum, fence agents, dan STONITH

Kuorum dalam Pacemaker secara konsep mirip dengan WSFC. Seluruh tujuan mekanisme kuorum kluster adalah untuk memastikan bahwa kluster tetap aktif dan berjalan. Baik add-on WSFC dan HA untuk distribusi Linux memiliki konsep pemungutan suara, di mana setiap simpul dihitung terhadap kuorum. Anda ingin sebagian besar suara naik, jika tidak, dalam skenario terburuk, kluster akan dimatikan.

Berbeda dengan WSFC, tidak ada sumber daya saksi yang dapat digunakan untuk bekerja dengan kuorum. Seperti WSFC, tujuannya adalah untuk menjaga jumlah pemilih tetap ganjil. Konfigurasi kuorum memiliki pertimbangan yang berbeda untuk AG daripada FCI.

WSFC memantau status simpul yang berpartisipasi dan menanganinya ketika masalah terjadi. Versi WSFC yang lebih baru menawarkan fitur seperti mengkarantina simpul yang salah tingkah laku atau tidak tersedia (simpul tidak aktif, komunikasi jaringan tidak berfungsi, dll.). Di sisi Linux, fungsionalitas seperti ini disediakan oleh fence agent. Konsepnya kadang-kadang disebut sebagai anggar. Namun, agen pagar ini khusus untuk penyebaran, dan sering disediakan oleh vendor perangkat keras dan beberapa vendor perangkat lunak, seperti mereka yang menyediakan hypervisor. Misalnya, VMware menyediakan agen pagar yang dapat digunakan untuk VM Linux yang divirtualisasi menggunakan vSphere.

Kuorum dan fencing berkaitan dengan konsep lain yang disebut STONITH, atau Shoot the Other Node in the Head. STONITH diperlukan untuk memiliki kluster Pacemaker yang didukung pada semua distribusi Linux. Untuk informasi selengkapnya, lihat Fencing di Kluster Ketersediaan Tinggi Red Hat (RHEL).

corosync.conf

File corosync.conf berisi konfigurasi kluster. Ini terletak di /etc/corosync. Dalam operasi normal sehari-hari, file ini seharusnya tidak perlu diedit jika kluster disiapkan dengan benar.

Lokasi log kluster

Lokasi log untuk kluster Pacemaker berbeda tergantung pada distribusinya.

  • RHEL dan SLES: /var/log/cluster/corosync.log
  • Ubuntu: /var/log/corosync/corosync.log

Untuk mengubah lokasi pengelogan default, ubah corosync.conf.

Merencanakan kluster Pacemaker untuk SQL Server

Bagian ini membahas titik perencanaan penting untuk kluster Pacemaker.

Virtualisasikan kluster Pacemaker berbasis Linux untuk SQL Server

Menggunakan komputer virtual untuk menyebarkan penyebaran SQL Server berbasis Linux untuk AG dan FCI dicakup oleh aturan yang sama seperti untuk mitra berbasis Windows mereka. Ada serangkaian aturan dasar untuk dukungan penyebaran SQL Server virtual yang disediakan oleh Microsoft dalam kebijakan Dukungan untuk produk Microsoft SQL Server yang berjalan di lingkungan virtualisasi perangkat keras. Hypervisor yang berbeda seperti Hyper-V Microsoft dan ESXi VMware mungkin memiliki variansi yang berbeda selain itu, karena perbedaan dalam platform itu sendiri.

Ketika datang ke AG dan FCI di bawah virtualisasi, pastikan bahwa anti-afinitas diatur untuk simpul kluster Pacemaker tertentu. Ketika dikonfigurasi untuk ketersediaan tinggi dalam konfigurasi AG atau FCI, VM yang menghosting SQL Server tidak boleh berjalan pada host hypervisor yang sama. Misalnya, jika FCI dua node disebarkan, harus ada setidaknya tiga host hypervisor sehingga salah satu VM yang menghosting simpul dapat dipindahkan jika terjadi kegagalan host, terutama jika menggunakan fitur seperti Live Migration atau vMotion.

Untuk dokumentasi Hyper-V, lihat Gunakan Pengklusteran Tamu untuk Ketersediaan Tinggi

Jaringan

Tidak seperti WSFC, Pacemaker tidak memerlukan nama khusus atau setidaknya satu alamat IP khusus untuk kluster Pacemaker itu sendiri. AG dan FCI akan memerlukan alamat IP (lihat dokumentasi untuk masing-masing informasi lebih lanjut), tetapi bukan nama, karena tidak ada sumber daya nama jaringan. SLES memang memungkinkan konfigurasi alamat IP untuk tujuan administrasi, tetapi tidak diperlukan, seperti yang dapat dilihat di Membuat kluster Pacemaker.

Seperti WSFC, Pacemaker akan lebih memilih jaringan redundan, yang berarti kartu jaringan yang berbeda (NIC atau pNIC untuk fisik) memiliki alamat IP individual. Dalam hal konfigurasi kluster, setiap alamat IP akan memiliki apa yang dikenal sebagai cincinnya sendiri. Namun, seperti halnya WSFC saat ini, banyak implementasi divirtualisasi atau di cloud publik di mana hanya ada satu NIC virtual (vNIC) yang disajikan ke server. Jika semua pNIC dan vNIC terhubung ke sakelar fisik atau virtual yang sama, maka tidak ada redundansi yang sebenarnya pada lapisan jaringan, sehingga mengonfigurasi beberapa NIC hanya sebuah ilusi bagi mesin virtual. Redundansi jaringan biasanya dibangun ke dalam hypervisor untuk penyebaran virtual, dan pasti dibangun ke dalam cloud publik.

Salah satu perbedaan dengan beberapa NIC dan Pacemaker versus WSFC adalah bahwa Pacemaker memungkinkan beberapa alamat IP pada subnet yang sama, sedangkan WSFC tidak. Untuk informasi selengkapnya tentang beberapa subnet dan kluster Linux, lihat artikel Mengonfigurasi grup ketersediaan Always On beberapa subnet dan instans kluster failover.

Quorum dan STONITH

Konfigurasi dan persyaratan kuorum terkait dengan penerapan yang spesifik untuk AG atau FCI di SQL Server.

STONITH diperlukan untuk kluster Pacemaker yang didukung. Gunakan dokumentasi dari distribusi untuk mengonfigurasi STONITH. Contohnya adalah di Pemagaran Berbasis Penyimpanan untuk SLES. Ada juga agen STONITH untuk VMware vCenter Server untuk solusi berbasis ESXI. Untuk informasi selengkapnya, lihat Stonith Plugin Agent untuk VMware VM VM VCenter SOAP Fencing (Tidak Resmi).

Interoperabilitas

Bagian ini mendistribusikan bagaimana kluster berbasis Linux dapat berinteraksi dengan WSFC atau dengan distribusi Linux lainnya.

WSFC

Saat ini, tidak ada cara langsung bagi WSFC dan kluster Pacemaker untuk bekerja sama. Ini berarti bahwa tidak ada cara untuk membuat AG atau FCI yang berfungsi di WSFC dan Pacemaker. Namun, ada dua solusi interoperabilitas, yang keduanya dirancang untuk AG. Satu-satunya cara FCI dapat berpartisipasi dalam konfigurasi lintas platform adalah jika berpartisipasi sebagai instans dalam salah satu dari dua skenario ini:

  • AG dengan jenis kluster Tidak Ada. Untuk informasi selengkapnya, lihat dokumentasi grup Windows availability.
  • AG terdistribusi, yang merupakan jenis grup ketersediaan khusus yang memungkinkan dua AG berbeda untuk dikonfigurasi sebagai grup ketersediaan mereka sendiri. Untuk informasi selengkapnya tentang AG terdistribusi, lihat dokumentasi Grup ketersediaan terdistribusi.

Distribusi Linux lainnya

Di Linux, semua simpul kluster Pacemaker harus berada pada distribusi yang sama. Misalnya, ini berarti bahwa simpul RHEL tidak dapat menjadi bagian dari kluster Pacemaker yang memiliki simpul SLES. Alasan utama untuk ini sebelumnya dinyatakan: distribusi mungkin memiliki versi dan fungsionalitas yang berbeda, sehingga semuanya tidak dapat berfungsi dengan baik. Pencampuran distribusi sama halnya dengan mencampur WSFC dan Linux: gunakan None atau AG terdistribusi.

Konten terkait

  • Last updated on