Pacemaker untuk grup ketersediaan dan instans kluster failover di Linux
Berlaku untuk:
SQL Server - 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 add-on/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 tumpukan adalah:
- Pacemaker. 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 hal-hal seperti pengelogan.
- Agen sumber daya. Fungsionalitas khusus yang disediakan sehingga aplikasi dapat berintegrasi dengan Pacemaker.
- Agen pagar. 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. Di Windows, bentuk ketersediaan pengklusteran, yang disebut kluster failover Windows Server (WSFC), dibangun ke dalam sistem operasi, dan fitur yang memungkinkan pembuatan WSFC, pengklusteran failover, dinonaktifkan secara default. Di 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 dimungkinkan oleh dan besar karena semuanya dari satu vendor.
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 sumber terbuka, jadi meskipun dikirim dengan distribusi, lapisan pengklusteran tidak terintegrasi erat dengan cara yang sama seperti WSFC berada di bawah Windows. Inilah sebabnya mengapa Microsoft menyediakan mssql-server-ha, sehingga SQL Server dan tumpukan Pacemaker dapat menyediakan hampir, tetapi tidak persis sama, pengalaman untuk AG dan FCI seperti di bawah Windows.
Untuk dokumentasi lengkap tentang Pacemaker, termasuk penjelasan yang lebih mendalam tentang apa semuanya dengan informasi referensi lengkap, untuk RHEL dan SLES:
Ubuntu tidak memiliki panduan untuk ketersediaan.
Untuk informasi selengkapnya tentang seluruh tumpukan, lihat juga halaman dokumentasi Pacemaker resmi di situs ClusterLabs.
Konsep dan terminologi Pacemaker
Bagian ini mencocokkan 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 berbeda dengan apa yang dilakukan di WSFC, di mana Anda melihat sumber daya SQL Server untuk sumber daya FCI atau AG saat mengonfigurasi AG, tetapi tidak persis sama karena perbedaan yang mendasari bagaimana SQL Server terintegrasi dengan Pacemaker.
Pacemaker memiliki sumber daya standar dan kloning. Mengkloning sumber daya adalah sumber daya 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
Komunikasi bebas bias
Artikel ini berisi referensi ke istilah budak, istilah yang dianggap menyinggung Microsoft saat digunakan dalam konteks ini. Istilah muncul dalam artikel ini karena saat ini muncul di perangkat lunak. Ketika istilah dihapus dari perangkat lunak, kami akan menghapusnya dari artikel.
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 pemesanan memberi tahu kluster Pacemaker urutan sumber daya harus dimulai.
Catatan
Batasan kolokasi tidak diperlukan untuk sumber daya dalam grup sumber daya, karena semua batasan tersebut dipandang sebagai satu unit.
Kuorum, agen pagar, dan STONITH
Kuorum di bawah Pacemaker mirip dengan WSFC dalam konsep. 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.
Tidak seperti WSFC, tidak ada sumber daya saksi untuk bekerja dengan kuorum. Seperti WSFC, tujuannya adalah untuk menjaga jumlah pemilih tetap aneh. 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, jenis fungsionalitas ini disediakan oleh agen pagar. 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 ikatan pagar ke konsep lain yang disebut STONITH, atau Tembak Simpul Lain di Kepala. STONITH diperlukan untuk memiliki kluster Pacemaker yang didukung pada semua distribusi Linux. Untuk informasi selengkapnya, lihat Anggar 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 rekan-rekan berbasis Windows mereka. Ada seperangkat aturan dasar untuk dukungan penyebaran SQL Server virtual yang disediakan oleh Kebijakan dukungan Microsoft untuk produk Microsoft SQL Server yang berjalan di lingkungan virtualisasi perangkat keras. Hypervisor yang berbeda seperti ESXi Hyper-V dan VMware Microsoft mungkin memiliki variansi yang berbeda di atasnya, 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 ada di suatu tempat bagi salah satu VM yang menghosting simpul untuk pergi jika terjadi kegagalan host, terutama jika menggunakan fitur seperti Migrasi Langsung atau vMotion.
Untuk dokumentasi Hyper-V, lihat Menggunakan 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, tidak ada redundansi sejati di lapisan jaringan, jadi mengonfigurasi beberapa NIC adalah sedikit ilusi ke komputer 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 AlwaysOn beberapa subnet dan instans kluster failover.
Kuorum dan STONITH
Konfigurasi dan persyaratan kuorum terkait dengan penyebaran khusus AG atau FCI dari SQL Server.
STONITH diperlukan untuk kluster Pacemaker yang didukung. Gunakan dokumentasi dari distribusi untuk mengonfigurasi STONITH. Contohnya adalah di Anggar 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 ketersediaan Windows.
- 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. Distribusi pencampuran memiliki cerita yang sama dengan mencampur WSFC dan Linux: gunakan Tidak Ada atau AG terdistribusi.