Belajar Zabbix - High Availability (HA) & Disaster Recovery

#Pendahuluan

Sampai episode 15, semua deployment kita memakai satu server Zabbix. Itu bekerja dengan baik sampai server mati — dan semua monitoring ikut mati, tepat saat dibutuhkan paling banyak. Episode 16 ini membahas dua jawaban untuk masalah itu: HA cluster untuk ketersediaan berkelanjutan, dan disaster recovery untuk memastikan data dan konfigurasi bisa dipulihkan.

HA dan DR adalah pasangan yang saling melengkapi. HA menjaga sistem tetap hidup saat satu node bermasalah. DR menjaga kemampuan untuk kembali berjalan dari nol — di lokasi lain, dari backup. Keduanya adalah syarat agar Zabbix layak dipakai untuk infrastruktur kritis.

#HA Cluster Zabbix Server

#Konsep Active dan Standby Node

HA cluster Zabbix terdiri dari dua node server atau lebih yang berbagi satu database. Satu node aktif memproses semua collection, sementara node standby memantau kondisi node aktif. Jika node aktif gagal, salah satu standby mengambil alih.

Keunggulan pendekatan ini: tidak butuh shared storage atau load balancer khusus. Yang dibutuhkan hanyalah node ekstra dan database yang bisa diakses kedua node.

#Konfigurasi HAClusterNodes

HA dikonfigurasi di zabbix_server.conf pada setiap node:

HANodeName=zabbix-server-01
HAClusterNodes=zabbix-server-01,zabbix-server-02

• HANodeName: nama unik node ini, harus berbeda di tiap server.
• HAClusterNodes: daftar nama semua node dalam cluster, dipisahkan koma.

Parameter HANodeName dan HAClusterNodes memberitahu server siapa dirinya dan siapa rekan clusternya. Setelah kedua node berjalan, cluster terbentuk secara otomatis.

#Failover Behavior

Node standby memantau kondisi node aktif dan database. Saat node aktif gagal, node standby menunggu sejenak untuk memastikan kegagalan nyata, lalu mengambil peran aktif dan mulai memproses collection. Proses ini otomatis tanpa intervensi manual.

zabbix_server -R ha_status

Perintah zabbix_server -R ha_status menampilkan status masing-masing node dalam cluster. Pantau output ini secara berkala — status HA juga tersedia sebagai item internal untuk dimonitor Zabbix sendiri.

#Disaster Recovery

#Backup Database

Database adalah jantung Zabbix — semua konfigurasi, history, dan trends ada di sana. Backup berkala menjadi prioritas pertama. Untuk MySQL:

mysqldump -uzabbix -p --single-transaction --routines --triggers zabbix | gzip > zabbix-backup.sql.gz

Opsi --single-transaction menghasilkan backup yang konsisten tanpa mengunci tabel. Untuk PostgreSQL, pakai pg_dump; jika memakai TimescaleDB dari episode 12, sertakan dump dengan format yang mendukung restore hypertable.

Simpan backup di lokasi berbeda dari server — idealnya di luar lokasi yang sama — dan uji restore secara berkala.

#Backup Konfigurasi

Selain database, cadangkan konfigurasi yang tidak tersimpan di database:

• File zabbix_server.conf dan zabbix_proxy.conf.
• File zabbix_agent2.conf dan kunci PSK di setiap host.
• Konfigurasi reverse proxy dan sertifikat TLS.

Template juga bisa di-export sebagai file YAML dan disimpan di version control — cara efektif menjaga template tetap terdokumentasi dan bisa dikembalikan kapan saja.

#Prosedur Restore

Restore berarti membalikkan backup menjadi sistem yang berjalan:

1. Install Zabbix dengan versi yang sama seperti saat backup dibuat.
2. Buat database baru dan import backup.
3. Sesuaikan zabbix_server.conf agar menunjuk ke database yang dipulihkan.
4. Jalankan server dan verifikasi frontend menampilkan data yang sama.

gunzip -c zabbix-backup.sql.gz | mysql -uzabbix -p zabbix

Perintah gunzip -c zabbix-backup.sql.gz | mysql -uzabbix -p zabbix mengembalikan isi backup ke database. Selalu dokumentasikan langkah ini dan latih di lingkungan uji sebelum benar-benar dibutuhkan.

#Mendesain Strategi Ketersediaan

Keputusan arsitektur bisa disusun berjenjang:

• Standalone + backup terjadwal: cukup untuk lingkungan dev atau non-kritis.
• HA cluster: untuk lingkungan yang butuh kontinuitas tanpa downtime.
• HA + DR lintas lokasi: untuk infrastruktur kritis dengan RPO dan RTO yang ketat.

Node A (active) ─┐
                 ├── Database ── backup harian → lokasi off-site
Node B (standby)─┘

Tentukan target RPO (seberapa banyak data yang boleh hilang) dan RTO (seberapa cepat harus pulih) sejak awal. Kedua angka ini menentukan frekuensi backup dan kompleksitas arsitektur yang diperlukan.

#Penutup

Episode 16 menyiapkan Zabbix untuk skenario terburuk: HA cluster dengan node active dan standby memastikan collection berlanjut saat satu node gagal, dan backup database serta konfigurasi dengan prosedur restore memastikan sistem bisa dibangun kembali dari nol.

Inti yang harus dibawa pulang:

• HA cluster berbagi satu database; node standby mengambil alih saat node aktif gagal.
• HANodeName dan HAClusterNodes adalah dua parameter inti konfigurasi HA.
• Backup database mencakup konfigurasi, history, dan trends.
• Simpan konfigurasi server dan kunci PSK di luar database.
• Restore harus diuji berkala, bukan hanya didokumentasikan.

Di episode 17 selanjutnya kita akan membahas performance tuning dan capacity planning — menyesuaikan cache dan jumlah worker, tuning database, menghitung NVP untuk sizing, serta memonitor kesehatan Zabbix dengan internal checks.