SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

Date: Mei 11, 2024

What Causes Failovers to Happen

Apa Penyebab Terjadinya Kegagalan?

Saat bekerja di bagian dukungan, salah satu pertanyaan paling umum yang kami terima dari pelanggan adalah “Apa yang mendorong hal tersebutkegagalandari simpul utama saya ke simpul sekunder?”.

Ada beberapa alasan mengapa hal ini mungkin terjadi… dan kami akan mencoba menjelaskan penyebab paling umum dan bagaimana Anda dapat mengidentifikasinya.

Sebelum kita mulai, marimembedakan antara ‘failover’ dan ‘switchover’, karena banyak pelanggan menggunakan istilah ini secara bergantian.

‘Peralihan’ adalah tindakan memindahkan hierarki Anda secara manual dari simpul utama ke simpul sekunder. Hal ini dapat dilakukan melalui GUI, dengan melakukan ‘In Service’ pada node sekunder atau melalui baris perintah:

perform_action -a restore -t $LKTag (membawa hierarki ke dalam layanan)

Sebaliknya, ‘failover’ dilakukan tanpa interaksi manual apa pun… dan didefinisikan sebagai peralihan otomatis ke server cadangan setelah kegagalan server, aplikasi, atau perangkat keras/jaringan yang sebelumnya aktif..

Failover dan switchover pada dasarnya adalah operasi yang sama, hanya saja failover bersifat otomatis danbiasanya beroperasi tanpa peringatan, sedangkan peralihannya disengaja dan memerlukan campur tangan manusia.

Berikut ini adalah ‘kegagalan’ paling umum yang mengawali ‘kegagalan’:

  1. Penyebab Tingkat Server

Kegagalan Server

  • Server utama kehilangan daya atau dimatikan.
  • Penggunaan CPU disebabkan oleh beban berlebihan — Di bawah beban I/O yang sangat berat, penundaan dan kondisi memori rendah dapat menyebabkan sistem menjadi tidak responsif sehinggaPenjaga Kehidupandapat mendeteksi server sedang down dan memulai failover.
  • Kuorum/Saksi – Sebagai bagian dari mekanisme pagar I/O kuorum/saksi, ketika server utama kehilangan kuorum, “boot cepat”:, “pembunuhan cepat” atau “osu” dilakukan (berdasarkan pengaturan) dan failover dimulai. Saat menentukan kapan harus melakukan failover, server saksi mengizinkan sumber daya untuk digunakan di server cadangan hanya jika server tersebut memverifikasi bahwa server utama telah gagal dan tidak lagi menjadi bagian dari cluster. Hal ini akan mencegah terjadinya failover karena kegagalan komunikasi sederhana antar node ketika kegagalan tersebut tidak memengaruhi keseluruhan akses dan kinerja node dalam layanan.

Kegagalan Komunikasi (Detak Jantung).

LifeKeeper memiliki sinyal “detak jantung” bawaan yang secara berkala memberi tahu setiap server dalam konfigurasi bahwa server pasangannya sedang beroperasi. Secara default, LifeKeeper mengirimkan detak jantung antar server setiap lima detik (ini dapat disesuaikan untuk cluster yang sibuk). Jika masalah komunikasi menyebabkan detak jantung melewati dua detak namun kembali berlanjut pada detak jantung ketiga, LifeKeeper tidak mengambil tindakan. Namun, jika jalur komunikasi tetap mati selama tiga ketukan, LifeKeeper akan memberi label jalur komunikasi tersebut sebagai mati. Ini akan memulai failover jika jalur komunikasi redundan juga mati (kami merekomendasikan dua jalur).

Berikut ini dapat menyebabkan detak jantung tidak terdengar:

  • Koneksi jaringan ke server utama terputus.
  • Latensi jaringan.
  • Lalu lintas jaringan yang padat di jalur komunikasi TCP dapat mengakibatkan perilaku yang tidak terduga, termasuk failover palsu dan masalah inisialisasi LifeKeeper.
  • NIC gagal.
  • Peralihan jaringan gagal.
  • Menarik/menghapus konektivitas jaringan secara manual
  • Server utama kehilangan daya atau dimatikan.
  • Penggunaan CPU yang disebabkan oleh beban berlebihan — Di bawah beban I/O yang sangat berat, penundaan dan kondisi memori rendah dapat menyebabkan sistem menjadi tidak responsif sehingga LifeKeeper dapat mendeteksi server sedang down dan memulai failover.

Menyesuaikan parameter detak jantung:

LCMNUMHBEATS=Y (di mana Y adalah jumlah detak jantung sebelum mencatat kesalahan jalur komunikasi yang gagal di log). Standarnya adalah 3 dan dapat diubah jika sistem Anda sibuk atau melintasi WAN untuk menghindari kegagalan jalur komunikasi yang salah.

LCMHBEATTIME=5 (ini adalah interval dalam detik dan ini adalah default dan tidak boleh diubah).

Tunable ini TIDAK ada di file /etc/default/LifeKeeper secara default. Anda perlu menambahkannya untuk mengubah nilai detak jantung.

Setelah menambahkan merdu dan nilai-nilai ini di /etc/default/LifeKeeper Anda harus menghentikan LifeKeeper dan memulai ulang. Anda dapat menggunakan perintah lkstop -f, yang menghentikan LifeKeeper tetapi tidak mematikan aplikasi yang dilindungi.

Dan Anda perlu melakukan ini pada kedua sistem.

Ini akan memberikan waktu 5 kali Y detik sebelum LifeKeeper menandai jalur komunikasi sebagai gagal.

Apa itu Split-Brain dan apa penyebabnya?

Jika satu jalur komunikasi digunakan dan jalur komunikasi gagal, maka hierarki LifeKeeper mungkin mencoba untuk masuk ke layanan pada beberapa sistem secara bersamaan. Hal ini dikenal sebagai failover palsu atau skenario “otak terpecah”. Dalamskenario “otak terbelah”., setiap server yakin bahwa mereka mengendalikan aplikasi dan dengan demikian mungkin mencoba mengakses dan menulis data ke perangkat penyimpanan bersama. Untuk mengatasi skenario perpecahan otak, LifeKeeper dapat menyebabkan server dimatikan atau di-boot ulang atau meninggalkan hierarki di luar layanan untuk memastikan integritas data pada semua data bersama. Selain itu, lalu lintas jaringan yang padat di jalur komunikasi TCP dapat mengakibatkan perilaku yang tidak terduga, termasuk failover palsu dan kegagalan LifeKeeper untuk melakukan inisialisasi dengan benar.

Berikut ini adalah skenario yang dapat menyebabkan terjadinya split-brain:

  • Salah satu kegagalan komunikasi yang tercantum di atas
  • Shutdown LifeKeeper yang tidak tepat
  • Kelaparan sumber daya server
  • Kehilangan semua jalur jaringan
  • DNS atau kesalahan jaringan lainnya
  • Penguncian sistem

Memanfaatkan Kuorum/Saksi untuk mencegah terjadinya Split Brain

  • Paket Dukungan Server Kuorum/Saksi untuk LifeKeeper (steeleye-lkQWK, selanjutnya disebut “Paket Kuorum/Saksi”) dikombinasikan dengan proses failover yang ada pada inti LifeKeeper memungkinkan kegagalan sistem terjadi dengan tingkat kepercayaan yang lebih besar dalam situasi di mana kegagalan jaringan total dapat terjadi menjadi hal yang umum. Hal ini secara efektif berarti bahwa failover situs lokal dan failover ke node di seluruh WAN dapat dilakukan sekaligus sangat mengurangi risikootak terbelahsituasi.
  • Dalam sistem terdistribusi yang memperhitungkan partisi jaringan, terdapat konsep yang disebut kuorum untuk memperoleh konsensus di seluruh cluster. Node yang memiliki kuorum adalah node yang dapat memperoleh konsensus dari semua cluster dan diperbolehkan membawa sumber daya dalam pelayanan. Di sisi lain, node yang tidak memiliki kuorum adalah node yang tidak dapat memperoleh konsensus dari semua cluster dan tidak diperbolehkan membawa sumber daya untuk dilayani. Ini akan mencegah terjadinya perpecahan otak. Untuk memeriksa apakah suatu node memiliki kuorum disebut pemeriksaan kuorum. Dinyatakan “pemeriksaan kuorum berhasil” jika memenuhi kuorum, dan “pemeriksaan kuorum gagal” jika tidak memenuhi kuorum.
  • Jika terjadi kegagalan komunikasi, menggunakan satu node di mana kegagalan terjadi dan beberapa node lainnya (atau perangkat lain) akan memungkinkan sebuah node mendapatkan “pendapat kedua” tentang status node yang gagal. Simpul untuk mendapatkan “pendapat kedua” disebut simpul saksi (atau perangkat saksi), dan mendapatkan “pendapat kedua” disebut pemeriksaan saksi. Saat menentukan kapan harus melakukan failover, node saksi (perangkat saksi) mengizinkan sumber daya untuk digunakan di server cadangan hanya jika node tersebut memverifikasi bahwa server utama telah gagal dan tidak lagi menjadi bagian dari cluster. Hal ini akan mencegah terjadinya failover karena kegagalan komunikasi sederhana antar node ketika kegagalan tersebut tidak memengaruhi keseluruhan akses dan kinerja node dalam layanan. Selama pengoperasian sebenarnya, simpul saksi (perangkat saksi) akan dikonsultasikan ketika LifeKeeper dimulai atau jalur komunikasi yang gagal dipulihkan. Pengecekan saksi hanya dapat dilakukan pada node yang memenuhi kuorum.

  1. Penyebab Kegagalan Sumber Daya

LifeKeeper dirancang untuk memantau aplikasi individu dan kelompok aplikasi terkait, secara berkala melakukan pemulihan lokal atau pemberitahuan ketika aplikasi yang dilindungi gagal. Aplikasi terkait, misalnya, adalah hierarki di mana aplikasi utama bergantung pada penyimpanan tingkat rendah atau sumber daya jaringan. LifeKeeper memantau status dan kesehatan sumber daya yang dilindungi ini. Jika sumber daya ditentukan berada dalam keadaan gagal, maka akan dilakukan upaya untuk memulihkan sumber daya atau aplikasi pada sistem saat ini (node ​​dalam layanan) tanpa intervensi eksternal. Jika pemulihan lokal ini gagal, failover sumber daya akan dimulai.

Kegagalan Aplikasi

  • Kegagalan aplikasi terdeteksi, namun proses pemulihan lokal gagal.
  • Hapus Kegagalan – Selama proses failover sumber daya, sumber daya tertentu perlu dihapus dari layanan di server utama dan kemudian dimasukkan ke dalam layanan di server cadangan yang dipilih untuk menyediakan fungsionalitas penuh dari aplikasi penting. Jika proses penghapusan ini gagal, reboot server utama akan dilakukan sehingga mengakibatkan kegagalan server total.

Contoh kegagalan penghapusan:

  • Tidak dapat melepas sistem file
  • Tidak dapat mematikan aplikasi yang dilindungi (Oracle, mysql, postgres, dll)

Masalah Sistem File

  • Disk Penuh — Pemantauan Kesehatan Sistem File LifeKeeper dapat mendeteksi kondisi sistem file penuh disk yang dapat mengakibatkan kegagalan sumber daya sistem file.
  • Sistem File Tidak Dipasang atau Dipasang dengan Benar — Pengguna secara manual melepas atau mengubah opsi pada sistem file dalam layanan dan dilindungi LK.
  • Kegagalan Remount — Berikut ini adalah daftar penyebab umum kegagalan remount yang dapat menyebabkan failover:
  • sistem file rusak (kegagalan fsck)
  • kegagalan membuat direktori mount point
  • titik pemasangan sedang sibuk
  • kegagalan pemasangan
  • Kesalahan internal Penjaga Kehidupan

Kegagalan Alamat IP

Ketika kegagalan alamat IP terdeteksi oleh IP Recovery Kit, kegagalan yang diakibatkannya memicu eksekusi skrip pemulihan lokal IP. LifeKeeper pertama-tama mencoba mengembalikan alamat IP ke layanan pada antarmuka jaringan saat ini. Jika upaya pemulihan lokal gagal, LifeKeeper akan melakukan failover alamat IP dan semua sumber daya yang bergantung ke server cadangan. Selama failover, proses penghapusan akan membatalkan konfigurasi alamat IP pada server saat ini sehingga dapat dikonfigurasi pada server cadangan. Kegagalan proses penghapusan ini akan menyebabkan sistem melakukan boot ulang.

  • konflik kekayaan intelektual
  • tabrakan IP
  • Kegagalan resolusi DNS
  • Kegagalan NIC atau Switch

Konflik Reservasi

  • Reservasi ke perangkat yang dilindungi hilang atau dicuri
  • Tidak dapat memperoleh kembali reservasi atau kendali perangkat sumber daya yang dilindungi (disebabkan oleh intervensi pengguna manual, HBA, atau kegagalan sakelar)

Perangkat SCSI

  • Perangkat SCSI yang dilindungi tidak dapat dibuka. Perangkat mungkin gagal atau mungkin telah dihapus dari sistem.

Sumber daya untuk mengidentifikasi penyebab failover

/var/log/lifekeeper.log

File log ini, yang ditulis oleh LifeKeeper, harus menjadi tempat pertama yang Anda lihat dalam menentukan apa yang mungkin menyebabkan failover.

Misalnya, salah satu alasan paling umum adalah kegagalan jalur komunikasi. Di bawah ini adalah contoh entri yang akan Anda temukan di lifekeeper.log ketika hal ini terjadi:

21 Sep 11:06:57 es1ecc08tev lcm[46893]: INFO:lcm.tli_hand:::005257: detak jantung tidak terjawab 1 dari 48 pada dev 10.236.17.226/10.238.17.226 (nomor driver lcm = 129).

21 Sep 11:06:57 es1ecc08tev lcm[46893]: INFO:lcm.tli_hand:::005257: detak jantung tidak terjawab 1 dari 48 pada dev 10.236.17.226/10.237.17.226 (nomor driver lcm = 1360929).

21 Sep 11:07:02 es1ecc08tev lcm[46893]: INFO:lcm.tli_hand:::005257: detak jantung tidak terjawab 2 dari 48 pada dev 10.236.17.226/10.238.17.226 (nomor driver lcm = 129).

Setelah mencapai jumlah detak jantung maksimum, failover dimulai:

21 Sep 11:10:49 es6ecc08tev lcm[9416]: INFO:lcm.tli_hand:::005257: detak jantung tidak terjawab 47 dari 48 pada dev 10.237.17.226/10.236.17.226 (nomor driver lcm = 71).

21 Sep 11:10:49 es6ecc08tev eventslcm[47082]: PERINGATAN:lcd.net:::004258:Komunikasi ke es1ecc08tev paling lambat 10.237.17.226/10.236.17.226 GAGAL

21 Sep 11:10:49 es6ecc08tev eventslcm[47082]: PERINGATAN:lcd.net:::004261:COMMUNICATIONS failover dari sistem “es1ecc08tev” akan dimulai.

21 Sep 11:10:49 es6ecc08tev penjaga pantai[47121]: PEMBERITAHUAN:event.comm_down:::010466:KOMUNIKASI es1ecc08tev GAGAL

/var/log/messages

File yang dihasilkan linux ini biasanya berisi pesan sistem yang dihasilkan oleh berbagai proses dan layanan yang berjalan pada sistem. Pesan-pesan ini dapat mencakup:

Pesan boot sistem: Informasi tentang proses boot sistem, termasuk pesan kernel dan pesan dari systemd atau sistem init lainnya.

Pesan permulaan dan penghentian layanan: Pesan yang menunjukkan kapan layanan dimulai atau dihentikan, termasuk kesalahan atau peringatan apa pun yang ditemui selama proses.

Pesan kernel: Informasi tentang pengoperasian kernel Linux, termasuk deteksi perangkat keras, inisialisasi perangkat, dan kesalahan atau peringatan kernel.

Pesan terkait jaringan: Informasi tentang koneksi jaringan, aktivitas firewall, dan perubahan konfigurasi jaringan.

Informasi kinerja sistem: Pesan terkait pemantauan kinerja sistem, seperti penggunaan CPU, penggunaan memori, dan statistik I/O disk.

Ketersediaan Tinggi SIOS dan Pemulihan Bencana

SIOS Technology Corporation menyediakanKetersediaan TinggiDanPemulihan bencanaproduk yang melindungi & mengoptimalkan infrastruktur TI dengan manajemen cluster untuk aplikasi terpenting Anda.Hubungi kami hari iniuntuk informasi lebih lanjut.

Direproduksi dengan izin dariSIOS