Mysql
 sql >> Teknologi Basis Data >  >> RDS >> Mysql

Bagaimana ClusterControl Mengonfigurasi IP Virtual dan Apa yang Diharapkan Selama Failover

Alamat IP virtual adalah alamat IP yang tidak sesuai dengan antarmuka jaringan fisik yang sebenarnya. Itu mengapung di antara beberapa antarmuka jaringan dan hanya satu antarmuka aktif yang akan menyimpan alamat IP untuk toleransi kesalahan dan mobilitas. ClusterControl menggunakan Keepalive untuk menyediakan integrasi alamat IP virtual dengan penyeimbang beban basis data untuk menghilangkan titik kegagalan tunggal (SPOF) di tingkat penyeimbang beban.

Dalam posting blog ini, kami akan menunjukkan kepada Anda bagaimana ClusterControl mengonfigurasi alamat IP virtual dan apa yang dapat Anda harapkan ketika failover atau failback terjadi. Memahami perilaku ini sangat penting untuk meminimalkan gangguan layanan, dan memperlancar operasi pemeliharaan yang perlu dilakukan sesekali.

Persyaratan

Ada beberapa persyaratan untuk menjalankan Keepalive di jaringan Anda:

  • Protokol IP 112 (Protokol Redundansi Router Virtual - VRRP) harus didukung dalam jaringan. Beberapa jaringan menonaktifkan dukungan untuk VRRP, terutama komunikasi antar-VLAN. Harap verifikasi ini dengan administrator jaringan.
  • Jika Anda menggunakan multicast, jaringan harus mendukung permintaan multicast (gunakan ip a | grep -i multicast). Jika tidak, Anda dapat menggunakan unicast melalui unicast_src_ip dan unicast_peer pilihan. Menggunakan multicast berguna saat Anda memiliki lingkungan dinamis seperti lingkungan cloud, atau saat penetapan IP dilakukan melalui DHCP.
  • Satu set instans VRRP harus menggunakan virtual_router_id yang unik nilai, yang tidak dapat dibagikan di antara instance lain. Jika tidak, Anda akan melihat paket palsu dan kemungkinan besar akan memutus sakelar cadangan master.
  • Jika Anda menjalankan di lingkungan cloud seperti AWS, Anda mungkin perlu menggunakan skrip eksternal (petunjuk:gunakan opsi "beri tahu") untuk memisahkan dan mengaitkan alamat IP virtual (IP Elastis) sehingga dikenali dan dapat dirutekan oleh routernya.

Menerapkan Keepalive

Untuk menginstal Keepalive melalui ClusterControl, Anda memerlukan dua atau lebih load balancer yang diinstal oleh atau diimpor ke ClusterControl. Untuk penggunaan produksi, kami sangat menyarankan agar perangkat lunak penyeimbang beban berjalan pada host yang berdiri sendiri dan tidak ditempatkan bersama dengan node database Anda.

Setelah Anda memiliki setidaknya dua penyeimbang beban yang dikelola oleh ClusterControl, untuk menginstal Keepalive dan mengaktifkan alamat IP virtual, cukup buka ClusterControl -> pilih cluster -> Kelola -> Load Balancer -> Keepalive:

Sebagian besar bidang cukup jelas. Anda dapat menerapkan set Keepalive baru atau mengimpor instance Keepalive yang ada. Bidang penting termasuk alamat IP virtual aktual dan antarmuka jaringan di mana alamat IP virtual akan ada. Jika host menggunakan dua nama antarmuka yang berbeda, tentukan nama antarmuka dari host Keepalive 1, lalu ubah file konfigurasi di Keepalive 2 secara manual dengan nama antarmuka yang benar nanti.

Instans VRRP

Pada saat penulisan ini, ClusterControl v1.5.1 menginstal Keepalive v1.3.5 (bergantung pada sistem operasi host) dan berikut ini yang dikonfigurasi untuk instans VRRP:

vrrp_instance VI_PROXYSQL {
   interface eth0                # interface to monitor
   state MASTER
   virtual_router_id 51          # Assign one ID for this route
   priority 100
   unicast_src_ip 10.0.0.246
   unicast_peer {
      10.0.0.204
   }
   virtual_ipaddress {
       10.0.0.100                        # the virtual IP
   }
   track_script {
       chk_proxysql
   }
#    notify /usr/local/bin/notify_keepalived.sh
}

ClusterControl mengonfigurasi instans VRRP untuk berkomunikasi melalui unicast. Dengan unicast, kita harus mendefinisikan semua rekan unicast dari node Keepalive lainnya. Ini kurang dinamis tetapi berfungsi sebagian besar waktu. Dengan multicast, Anda dapat menghapus baris tersebut (unicast_*) dan mengandalkan alamat IP multicast untuk penemuan dan peering host. Ini lebih sederhana tetapi biasanya diblokir oleh administrator jaringan.

Bagian selanjutnya adalah alamat IP virtual. Anda dapat menentukan beberapa alamat IP virtual per instans VRRP, dipisahkan oleh baris baru. Load balancing di HAProxy/ProxySQL dan Keepalive secara bersamaan juga membutuhkan kemampuan untuk mengikat ke alamat IP yang nonlocal, artinya tidak ditetapkan ke perangkat di sistem lokal. Ini memungkinkan instance penyeimbang beban yang berjalan untuk mengikat ke IP yang tidak lokal untuk failover. Jadi ClusterControl juga mengonfigurasi net.ipv4.ip_nonlocal_bind=1 di dalam /etc/sysctl.conf.

Arahan berikutnya adalah track_script , di mana Anda dapat menentukan skrip untuk proses health check yang dijelaskan di bagian selanjutnya.

Pemeriksaan Kesehatan

ClusterControl mengonfigurasi Keepalive untuk melakukan pemeriksaan kesehatan dengan memeriksa kode kesalahan yang dikembalikan oleh track_script. Dalam file konfigurasi Keepalived, yang secara default terletak di /etc/keepalived/keepalived.conf, Anda akan melihat sesuatu seperti ini:

   track_script {
       chk_proxysql
   }

Di mana ia memanggil chk_proxysql yang berisi:

vrrp_script chk_proxysql {
   script "killall -0 proxysql"   # verify the pid existence
   interval 2                    # check every 2 seconds
   weight 2                      # add 2 points of prio if OK
}

Perintah "killall -0" mengembalikan kode keluar 0 jika ada proses yang disebut "proxysql" yang berjalan di host. Jika tidak, instance harus menurunkan dirinya sendiri dan mulai memulai failover seperti yang dijelaskan di bagian berikutnya. Perhatikan bahwa Keepalived juga mendukung komponen Linux Virtual Server (LVS) untuk melakukan pemeriksaan kesehatan, yang juga mampu memuat keseimbangan koneksi TCP/IP, mirip dengan HAProxy, tetapi itu di luar cakupan entri blog ini.

Mensimulasikan Kegagalan

Untuk komponen VRRP, Keepalive menggunakan protokol VRRP (protokol IP 112) untuk berkomunikasi antara instans VRRP. Nilai prioritas MASTER yang lebih tinggi berarti master akan selalu memiliki hak istimewa yang lebih tinggi untuk menyimpan alamat IP virtual, kecuali jika Anda mengonfigurasi instans dengan "nopreempt". Mari kita gunakan contoh untuk menjelaskan aliran failover dan failback dengan lebih baik. Perhatikan diagram berikut:

Ada tiga instance ProxySQL di depan tiga node MySQL Galera. Setiap host ProxySQL dikonfigurasi dengan Keepalive sebagai MASTER dengan nomor prioritas berikut:

  • ProxySQL1 - prioritas 101
  • ProxySQL2 - prioritas 100
  • ProxySQL3 - prioritas 99

Ketika Keepalive dimulai sebagai MASTER, pertama-tama akan mengiklankan nomor prioritas kepada anggota dan kemudian mengasosiasikan dirinya dengan alamat IP virtual. Berbeda dengan instance CADANGAN, itu hanya akan mengamati iklan dan hanya menetapkan alamat IP virtual setelah dikonfirmasi dapat meningkatkan dirinya menjadi MASTER.

Perhatikan bahwa jika Anda mematikan proses "proxysql" atau "haproxy" secara manual melalui perintah kill, manajer proses systemd akan secara default mencoba memulihkan proses yang dihentikan secara tidak wajar. Juga, jika Anda mengaktifkan pemulihan otomatis ClusterControl, ClusterControl akan selalu mencoba untuk memulai proses bahkan jika Anda melakukan shutdown bersih melalui systemd (systemctl stop proxysql). Untuk mensimulasikan kegagalan dengan sebaik-baiknya, kami menyarankan pengguna untuk menonaktifkan fitur pemulihan otomatis ClusterControl atau cukup matikan server ProxySQL untuk memutus komunikasi.

Jika kita mematikan ProxySQL1, alamat IP virtual akan dialihkan ke host berikutnya yang memiliki prioritas lebih tinggi pada waktu tertentu (yaitu ProxySQL2) :

Anda akan melihat yang berikut di syslog dari node yang gagal:

Feb 27 05:21:59 proxysql1 systemd: Unit proxysql.service entered failed state.
Feb 27 05:21:59 proxysql1 Keepalived_vrrp[12589]: /usr/bin/killall -0 proxysql exited with status 1
Feb 27 05:21:59 proxysql1 Keepalived_vrrp[12589]: VRRP_Script(chk_proxysql) failed
Feb 27 05:21:59 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Changing effective priority from 103 to 101
Feb 27 05:22:00 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Received advert with higher priority 102, ours 101
Feb 27 05:22:00 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Entering BACKUP STATE
Feb 27 05:22:00 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) removing protocol VIPs.

Sedangkan pada node sekunder, hal berikut terjadi:

Feb 27 05:22:00 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) forcing a new MASTER election
Feb 27 05:22:01 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Transition to MASTER STATE
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Entering MASTER STATE
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) setting protocol VIPs.
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: Sending gratuitous ARP on eth0 for 10.0.0.100
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Sending/queueing gratuitous ARPs on eth0 for 10.0.0.100
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: Sending gratuitous ARP on eth0 for 10.0.0.100
Feb 27 05:22:02 proxysql2 avahi-daemon[346]: Registering new address record for 10.0.0.100 on eth0.IPv4.

Dalam hal ini, failover memakan waktu sekitar 3 detik, dengan waktu failover maksimum adalah interval + iklan_int . Di balik layar, titik akhir basis data telah berubah dan lalu lintas basis data dialihkan melalui ProxySQL2 tanpa diketahui oleh aplikasi.

Ketika ProxySQL1 kembali online, itu akan memaksa pemilihan MASTER baru dan mengambil alih alamat IP karena prioritas yang lebih tinggi:

Feb 27 05:38:34 proxysql1 Keepalived_vrrp[12589]: VRRP_Script(chk_proxysql) succeeded
Feb 27 05:38:35 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Changing effective priority from 101 to 103
Feb 27 05:38:36 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) forcing a new MASTER election
Feb 27 05:38:37 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Transition to MASTER STATE
Feb 27 05:38:38 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Entering MASTER STATE
Feb 27 05:38:38 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) setting protocol VIPs.
Feb 27 05:38:38 proxysql1 Keepalived_vrrp[12589]: Sending gratuitous ARP on eth0 for 10.0.0.100
Feb 27 05:38:38 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Sending/queueing gratuitous ARPs on eth0 for 10.0.0.100
Feb 27 05:38:38 proxysql1 avahi-daemon[343]: Registering new address record for 10.0.0.100 on eth0.IPv4.

Pada saat yang sama, ProxySQL2 menurunkan dirinya ke status CADANGAN dan menghapus alamat IP virtual dari antarmuka jaringan:

Feb 27 05:38:36 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Received advert with higher priority 103, ours 102
Feb 27 05:38:36 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Entering BACKUP STATE
Feb 27 05:38:36 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) removing protocol VIPs.
Feb 27 05:38:36 proxysql2 avahi-daemon[346]: Withdrawing address record for 10.0.0.100 on eth0.

Pada titik ini, ProxySQL1 kembali online dan menjadi penyeimbang beban aktif yang melayani koneksi dari aplikasi dan klien. VRRP biasanya akan mendahului server dengan prioritas lebih rendah ketika server dengan prioritas lebih tinggi online. Jika Anda ingin membuat alamat IP tetap di ProxySQL2 setelah ProxySQL1 kembali online, gunakan opsi "nopreempt". Hal ini memungkinkan mesin berprioritas lebih rendah untuk mempertahankan peran utama, bahkan ketika mesin berprioritas lebih tinggi kembali online. Namun, agar ini berfungsi, status awal entri ini harus CADANGAN. Jika tidak, Anda akan melihat baris berikut:

Feb 27 05:50:33 proxysql2 Keepalived_vrrp[6298]: (VI_PROXYSQL): Warning - nopreempt will not work with initial state MASTER

Karena secara default ClusterControl mengonfigurasi semua node sebagai MASTER, Anda harus mengonfigurasi opsi konfigurasi berikut untuk masing-masing instance VRRP:

vrrp_instance VI_PROXYSQL {
...
   state BACKUP
   nopreempt
...
}

Mulai ulang proses Keepalive untuk memuat perubahan ini. Alamat IP virtual hanya akan gagal ke ProxySQL1 atau ProxySQL3 (tergantung pada prioritas dan node mana yang tersedia pada saat itu) jika pemeriksaan kesehatan gagal pada ProxySQL2. Dalam banyak kasus, menjalankan Keepalive di dua host sudah cukup.


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. Pemantauan &Manajemen Operasi MySQL 8.0 dengan ClusterControl

  2. Stempel waktu dengan presisi milidetik:Bagaimana cara menyimpannya di MySQL

  3. MySQL Mengubah Prosedur Tersimpan

  4. Cara Mengatur Set Karakter dan Susunan Tabel di MySQL

  5. Periksa apakah tabel MySQL ada tanpa menggunakan pilih dari sintaks?