Cara Mengoptimalkan Kinerja ClusterControl dan Komponennya

Pemantauan dan manajemen sangat penting untuk lingkungan produksi apa pun karena kinerja itu penting. Antarmuka pengguna yang lambat yang tertinggal atau tidak merespons, peringatan yang tertunda, dan batas waktu tugas cluster ketika server kekurangan sumber daya adalah semua hal yang dapat menyebabkan masalah. Ada beberapa cara untuk meningkatkan kinerja ClusterControl, terutama jika Anda mengelola beberapa cluster dan setiap cluster berisi beberapa node. Blog ini memberikan beberapa tips tuning. Poin yang diuraikan di sini dikurasi berdasarkan pengalaman kami menangani masalah kinerja yang dilaporkan oleh pengguna dan pelanggan kami.

Sebagai pengantar, ClusterControl terdiri dari beberapa komponen utama - aplikasi web (frontend) berbasis PHP dan sejumlah proses daemon (backend). Ini memanfaatkan database MySQL/MariaDB untuk penyimpanan persisten. Anda secara efektif mengontrol cluster Anda dari aplikasi web, yang akan diterjemahkan ke serangkaian panggilan proses yang dijalankan oleh proses backend untuk mengelola dan memantau cluster database Anda.

Database MySQL

Komponen ClusterControl mengandalkan database MySQL atau MariaDB sebagai penyimpanan persisten untuk memantau data yang dikumpulkan dari node yang dikelola dan semua metadata ClusterControl (misalnya, pekerjaan apa yang ada dalam antrian, jadwal pencadangan, status pencadangan, dll.). Secara default, skrip penginstal akan menginstal versi apa pun yang disediakan oleh repositori standar OS. Berikut ini adalah versi MySQL/MariaDB yang diinstal oleh penginstal:

• CentOS/Redhat 6 - MySQL 5.1

• CentOS/Redhat 7 - MariaDB 5.5

• Ubuntu 18.04 (Bionic) - MySQL 5.7

• Ubuntu 16.04 (Xenial) - MySQL 5.7

• Ubuntu 14.04 (Terpercaya) - MySQL 5.5

• Debian 9 (Peregangan) - MySQL 5.5

• Debian 8 (Jessie) - MySQL 5.5

• Debian 7 (Wheezy) - MySQL 5.5

Skrip penginstal akan melakukan beberapa penyesuaian dasar seperti mengonfigurasi lokasi datadir, port MySQL, pengguna, dan ukuran kumpulan buffer InnoDB di awal tahap penginstalan. Namun, penyetelan mungkin tidak cocok setelah Anda mengimpor atau membuat lebih banyak kluster/node. Dengan peningkatan jumlah node yang akan dipantau dan dikelola, ClusterControl akan menggunakan lebih banyak sumber daya, dan lapisan database biasanya merupakan hambatan pertama yang dihadapi pengguna. Beberapa penyetelan lebih lanjut mungkin diperlukan untuk menahan beban yang masuk.

ClusterControl cukup pintar untuk mendeteksi anomali kinerja apa pun dengan menulis baris berikut di dalam cmon_X.log (di mana X adalah ID cluster):

2018-11-28 01:30:00 : (INFO) CmonSheetManager at 0x3839af0 loaded 70 values for key 'diskstat' between 2018-11-23 01:30:00 - 2018-11-28 01:30:0
0.
2018-11-28 01:30:00 : (INFO) SQL processing: 220.0000ms
2018-11-28 01:30:00 : (INFO) Parsing       : 0.0000ms
2018-11-28 01:30:00 : (INFO) Sum           : 220.0000ms

Hal di atas hanya berarti butuh 220 md (Nilai penjumlahan) untuk memuat 70 nilai untuk komponen "diskstat", di mana sebagian besar waktu pemrosesan terjadi pada tahap pemrosesan SQL dan 0 md untuk mengurai kumpulan hasil SQL Ini menyimpulkan bahwa lapisan SQL mengambil sebagian besar waktu pemrosesan ketika ClusterControl mencoba untuk mengkueri kumpulan data.

Kami yakin sebagian besar kueri SQL yang dijalankan oleh ClusterControl dioptimalkan dengan benar untuk satu instance MySQL dan menggunakan pengindeksan yang tepat. Sederhananya, jika Anda melihat sesuatu seperti di atas muncul secara teratur di file log, beberapa perbaikan pada lapisan database akan dilakukan, seperti yang ditunjukkan pada bagian berikut.

Menyetel Ukuran Pool Buffer InnoDB

Ukuran kumpulan buffer adalah komponen penting dan harus dikonfigurasi di awal untuk meningkatkan kinerja MySQL. Ini memungkinkan pemrosesan MySQL terjadi di dalam memori alih-alih mengenai disk. Aturan praktis yang sederhana adalah memeriksa rasio hit InnoDB dan mencari baris berikut di bawah bagian BUFFER POOL DAN MEMORY:

Buffer pool hit rate 986 / 1000

Tingkat hit 986/1000 menunjukkan bahwa dari 1000 baris yang dibaca, ia mampu membaca baris dalam RAM sebanyak 986 kali. Sisanya 14 kali, ia harus membaca deretan data dari disk. Sederhananya, 1000 / 1000 adalah nilai terbaik yang kami coba capai di sini, yang berarti data yang sering diakses cocok sepenuhnya di RAM.

Meningkatkan nilai innodb_buffer_pool_size akan banyak membantu untuk mengakomodasi lebih banyak ruang bagi MySQL untuk bekerja. Namun, pastikan Anda memiliki sumber daya RAM yang cukup sebelumnya. Secara default, ClusterControl mengalokasikan 50% RAM ke kumpulan buffer. Jika host didedikasikan untuk ClusterControl, Anda bahkan dapat mendorongnya ke nilai yang lebih tinggi seperti 70%, asalkan Anda menyisihkan setidaknya 2GB RAM untuk proses dan cache OS. Jika Anda tidak dapat mengalokasikan sebanyak itu, menambah RAM adalah satu-satunya solusi.

Mengubah nilai ini memerlukan restart MySQL (lebih lama dari MySQL 5.7.5), sehingga urutan restart layanan yang benar adalah:

1. Ubah nilai innodb_buffer_pool_size di dalam my.cnf.
2. Hentikan layanan CMON.
3. Mulai ulang layanan MySQL/MariaDB.
4. Mulai layanan CMON.

Atau cukup reboot host jika Anda bisa mendapatkan waktu henti yang lebih lama.

Menyetel max_connections

Secara default, skrip penginstal akan mengonfigurasi nilai max_connections hingga 512. Ini agak tinggi, meskipun waras, karena ClusterControl hampir tidak mencapai total 200 koneksi, kecuali server MySQL dibagikan dengan aplikasi lain atau Anda memiliki puluhan node MySQL yang dipantau oleh ClusterControl (kita berbicara tentang 30 node dan lebih banyak lagi).

Nilai max_connections yang tinggi memboroskan sumber daya dan menyesuaikan nilainya akan memengaruhi memori maksimum yang dikonfigurasi untuk MySQL. Jika lebih besar dari System RAM maka ada kemungkinan proses MySQL Server akan berhenti dengan pengecualian OOM, jika semua koneksi digunakan.

Untuk memeriksa ini, cukup cari status MySQL max_used_connections. Berikut ini adalah koneksi maksimum yang pernah dicapai MySQL pada node ClusterControl yang memonitor 2 cluster dengan total 6 node MySQL:

mysql> SHOW STATUS like 'max_used_connections';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 43    |
+----------------------+-------+

Nilai yang baik untuk memulai adalah Max_used_connections x 2, dan secara bertahap tingkatkan jika nilainya terus meningkat. Memodifikasi variabel max_connections dapat dilakukan secara dinamis melalui pernyataan SET GLOBAL.

Menggunakan file soket MySQL

Secara default, skrip penginstal akan secara otomatis mengonfigurasi nilai host berikut di dalam setiap file konfigurasi basis data ClusterControl:

Hal di atas akan memaksa klien MySQL untuk terhubung melalui jaringan TCP, seperti menghubungkan ke host MySQL jarak jauh meskipun ClusterControl berjalan di server yang sama dengan server MySQL. Kami sengaja mengonfigurasinya dengan cara ini untuk menyederhanakan proses penginstalan karena hampir setiap platform OS melakukan pra-konfigurasi file soket MySQL secara berbeda, yang sangat mengurangi tingkat kegagalan penginstalan.

Mengubah nilai menjadi "localhost" akan memaksa klien untuk menggunakan file soket MySQL Unix sebagai gantinya:

Pada sistem berbasis Unix, program MySQL memperlakukan nama host localhost secara khusus, dengan cara yang mungkin berbeda dari yang Anda harapkan dibandingkan dengan program berbasis jaringan lainnya. Untuk koneksi ke localhost, program MySQL mencoba terhubung ke server lokal dengan menggunakan file soket Unix. Ini terjadi bahkan jika opsi --port atau -P diberikan untuk menentukan nomor port.

Menggunakan file soket MySQL UNIX jauh lebih aman dan akan memotong overhead jaringan. Itu selalu direkomendasikan melalui TCP. Namun, Anda perlu memastikan file soket dikonfigurasi dengan benar. Itu harus ada pada arahan berikut di dalam my.cnf dan setiap file opsi MySQL pada node ClusterControl, misalnya:

[mysqld]
socket=/var/lib/mysql/mysql.sock

[client]
socket=/var/lib/mysql/mysql.sock

[mysql]
socket=/var/lib/mysql/mysql.sock

[mysqldump]
socket=/var/lib/mysql/mysql.sock

Mengubah file soket juga akan memerlukan restart MySQL dan CMON. Jika Anda menggunakan "localhost", Anda dapat menambahkan beberapa opsi konfigurasi tambahan seperti skip-networking=1, untuk mencegah penerimaan koneksi jarak jauh. Gambar ClusterControl Docker kami menggunakan pendekatan ini untuk mengatasi batasan dalam proxy-docker saat mengikat port.

OpenSSH dengan SSSD

ClusterControl menggunakan protokol SSH sebagai saluran komunikasi utamanya untuk mengelola dan memantau node jarak jauh. Konfigurasi OpenSSH default cukup baik dan akan berfungsi dalam banyak kasus. Namun, di beberapa lingkungan di mana SSH terintegrasi dengan alat peningkatan keamanan lainnya seperti SElinux atau System Security Services Daemon (SSSD), hal itu dapat membawa dampak signifikan pada kinerja SSH.

Kami telah melihat banyak kasus di mana jumlah koneksi SSH yang semakin meningkat dibuat untuk masing-masing node yang dikelola dan akhirnya, server ClusterControl dan semua node yang dikelola memaksimalkan memori sistem mereka dengan koneksi SSH. Dalam beberapa kasus, hanya sistem penuh normal yang melakukan boot ulang setiap malam di server ClusterControl yang dapat menyelesaikan masalah.

Jika Anda menjalankan infrastruktur Anda dengan System Security Services Daemon (SSSD), Anda disarankan untuk mengomentari baris berikut di dalam konfigurasi klien OpenSSH di /etc/ssh/ssh_config pada node ClusterControl:

#ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h

Di atas akan melewati penggunaan SSSD untuk mengelola kunci host, yang akan ditangani oleh klien OpenSSH.

Mulai dari ClusterControl 1.7.0, Anda memiliki opsi untuk menggunakan alat pemantauan berbasis agen dengan Prometheus. Dengan pemantauan berbasis agen, ClusterControl tidak menggunakan SSH untuk mengambil sampel metrik host yang dapat berlebihan di beberapa lingkungan.

Sistem File dan Partisi

Kontroler ClusterControl menulis entri baru di file lognya hampir setiap detik untuk setiap cluster. Bagi mereka yang ingin memanfaatkan penulisan sekuensial ini pada disk dan ingin menghemat biaya, Anda dapat menggunakan disk spindel untuk tujuan ini. Ubah baris berikut di dalam semua cmon_X.cnf:

logfile=/new/partition/log/cmon_X.log

Ganti X dengan ID cluster dan mulai ulang layanan CMON untuk menerapkan perubahan.

Jika Anda menggunakan ClusterControl sebagai repositori cadangan, Anda disarankan untuk mengalokasikan ruang disk yang cukup pada partisi terpisah selain partisi root. Akan lebih baik jika partisi berada pada sistem file berjaringan atau berkerumun agar mudah dipasang dengan node yang ditargetkan saat melakukan operasi pemulihan. Kami telah melihat kasus di mana cadangan yang dibuat menghabiskan semua ruang disk di partisi utama, yang pada akhirnya memengaruhi ClusterControl dan komponennya.

Terus up to Date

ClusterControl memiliki siklus rilis pendek - setidaknya satu rilis besar baru setiap kuartal tahun ditambah patch pemeliharaan mingguan (kebanyakan perbaikan bug - jika ada). Alasannya adalah ClusterControl mendukung banyak vendor dan versi database, sistem operasi, dan platform perangkat keras. Seringkali ada hal-hal baru yang diperkenalkan dan hal-hal lama yang ditinggalkan dari apa yang disediakan. ClusterControl harus mengikuti semua perubahan yang diperkenalkan oleh vendor aplikasi dan mengikuti praktik terbaik setiap saat.

Kami menyarankan pengguna untuk selalu menggunakan versi terbaru ClusterControl (mengupgrade dengan mudah) bersama dengan browser web terbaru (dibuat dan diuji di Google Chrome dan Mozilla Firefox), karena kemungkinan besar kami memanfaatkan fitur baru yang tersedia dalam versi terbaru.

Pemikiran Terakhir

Jika Anda memiliki pertanyaan atau mengalami masalah atau masalah kelambatan saat menggunakan ClusterControl, silakan hubungi kami melalui saluran dukungan kami. Saran dan masukan sangat kami harapkan.

Selamat menyetel!