Belajar Keepalived - Sejarah, Latar Belakang & Mengapa Memilih Keepalived

#Pendahuluan

Sebelum menulis konfigurasi apa pun, penting untuk tahu dari mana Keepalived lahir dan mengapa dia dipilih oleh begitu banyak tim infrastruktur. Episode 1 membuka babak sejarah: protokol VRRP yang menjadi fondasinya, perjalanan daemon Keepalived dari utilitas LVS menjadi solusi HA lengkap, dan perbandingan jujur dengan alternatif lain.

Kalian akan memahami kapan Keepalived adalah pilihan tepat dan kapan solusi lain seperti Corosync/Pacemaker lebih masuk akal. Mengetahui posisi sebuah tool di ekosistemnya membantu kalian mengambil keputusan arsitektur yang tidak hanya benar hari ini, tapi juga lima tahun ke depan.

Yang akan kita bahas: kelahiran Keepalived, evolusi standar VRRP, perbandingan dengan Heartbeat dan cluster manager, use cases utama, serta kriteria kapan Keepalived tidak cocok. Semua ini menjadi lensa untuk membaca episode-episode berikutnya.

#Sejarah Keepalived dan VRRP

#Kelahiran Keepalived

Keepalived ditulis oleh Alexandre Cassen sekitar awal tahun 2000-an sebagai daemon userspace di atas Linux Virtual Server (LVS). Ide awalnya sederhana: membungkus LVS dan VRRP dalam satu daemon dengan konfigurasi tunggal. Dengan begitu, sebuah node bisa menjadi load balancer sekaligus router redundant tanpa menulis ratusan baris script.

Dari situlah namanya berasal: keep dan alive, menjaga layanan tetap hidup. Sejak itu Keepalived berkembang menjadi proyek matang yang dikelola komunitas, rilis stabil versi 2.x, dan banyak dipakai sebagai frontend HA untuk HAProxy, Nginx, dan gateway jaringan.

#Perjalanan Standar VRRP

Keepalived mengimplementasikan Virtual Router Redundancy Protocol (VRRP). Protokol ini dirancang agar sekelompok router tampil sebagai satu virtual router. Evolusinya terpaut pada tiga RFC:

• RFC 2338 (1998): definisi VRRP pertama untuk IPv4, yang kemudian dikenal sebagai VRRPv2.
• RFC 3768 (2004): revisi VRRPv2 yang menghapus authentication header karena terbukti tidak aman.
• RFC 5798 (2010): VRRPv3, menambahkan dukungan IPv6 dan interval advertisement dalam centisecond.

Keepalived mendukung VRRPv2 dan VRRPv3 sekaligus. Pemahaman tentang RFC ini berguna saat kita menyentuh authentication di episode 9 dan IPv6 di episode 10. Karena standar ini publik, implementasi Keepalived bisa saling berkomunikasi dengan perangkat network lain yang juga berbicara VRRP.

#Perbandingan dengan Solusi HA Lain

Keepalived bukan satu-satunya tool HA di dunia Linux. Berikut perbandingan ringkas berdasarkan kebutuhan nyata di lapangan.

#Heartbeat

Heartbeat adalah pendahulu Keepalived yang populer di era proyek Linux-HA 2.0. Dia melakukan heartbeat antar node dan memindahkan resource melalui script. Kelemahan utama: konfigurasi kompleks dan tidak ada dukungan built-in untuk load balancing. Keepalived lebih ringan dan fokus pada VRRP plus LVS.

#Corosync/Pacemaker

Corosync menyediakan membership dan messaging antar node, sedangkan Pacemaker adalah cluster resource manager yang bisa memindahkan service, filesystem, dan IP secara stateful. Solusi ini jauh lebih kuat untuk workload kompleks seperti database cluster, tapi juga jauh lebih kompleks untuk dipelajari dan dioperasikan. Untuk sekadar floating IP failover, Pacemaker adalah overkill.

#LVS Native

LVS native lewat ipvsadm saja sudah menyediakan load balancing, tapi tidak punya mekanisme failover otomatis. Keepalived justru lahir untuk melengkapi LVS: dialah yang memonitor health backend dan memindahkan VIP saat load balancer mati. Posisi ini yang membuat Keepalived tetap relevan hingga sekarang.

#Ringkasan Perbandingan

Tidak ada solusi yang unggul di semua dimensi. Yang membedakan Keepalived adalah kesederhanaannya untuk kebutuhan lapisan jaringan:

• Keepalived: failover L4 plus load balancing dalam satu daemon ringan.
• Heartbeat: heartbeat sederhana berbasis script, sekarang jarang dipakai.
• Corosync/Pacemaker: cluster resource manager untuk layanan stateful.
• LVS native: load balancing murni, tanpa failover otomatis.

Pilih Keepalived saat kebutuhan kalian adalah VIP dan ketersediaan layanan; pilih cluster manager saat resource yang dikelola lebih dari sekadar IP.

#Use Cases Utama Keepalived

#Floating IP Failover

Kombinasi paling umum: dua node dan satu virtual IP. Saat node aktif mati, VIP pindah ke node cadangan dalam hitungan detik. Pola ini dipakai untuk API gateway, VIP database, dan NAT gateway. Tidak ada klien yang perlu mengubah konfigurasi karena alamatnya tetap sama.

#HA Load Balancer Frontend

Keepalived ditempatkan di depan HAProxy atau Nginx. Virtual IP milik load balancer, sedangkan real server adalah backend aplikasi. Saat satu load balancer mati, yang lain mengambil alih VIP tanpa klien menyadarinya. Arsitektur ini kita bedah penuh di episode 6 dan 14.

#Redundant Gateway

Keepalived bisa membuat default gateway yang redundan: dua router berbagi satu VIP sebagai gateway, dan server di bawahnya selalu punya satu pintu keluar yang andal. Detail routing dan policy routing untuk skenario ini kita bahas di episode 12.

#Mengapa Memilih Keepalived

Tiga alasan utama tim produksi memilih Keepalived:

• Ringan dan fokus: satu daemon, satu file konfigurasi, tanpa dependency cluster yang besar.
• Menggabungkan VRRP dan LVS: failover dan load balancing dalam satu tool yang saling melengkapi.
• Matang dan didukung luas: dipakai di ekosistem HAProxy, Nginx, dan berbagai stack infrastruktur.

Verifikasi versi daemon yang kalian miliki sebagai bekal diskusi selanjutnya:

keepalived --version

Output keepalived --version menunjukkan versi VRRP dan build options. Informasi ini penting karena fitur seperti auth_type dan centisecond hanya tersedia di versi tertentu.

#Kapan Keepalived Tidak Cocok

Keepalived bukan jawaban untuk semua masalah HA. Jika layanan kalian butuh konsensus mayoritas, quorum, atau manajemen resource yang kompleks, pertimbangkan alternatif lain. Skenario seperti cluster database dengan replikasi stateful atau fencing disk sebaiknya ditangani oleh Corosync/Pacemaker atau solusi database-native.

#Penutup

Episode 1 menempatkan Keepalived di peta sejarah dan ekosistem: lahir dari LVS, dibangun di atas standar VRRP, dan bersaing dengan Heartbeat serta Corosync/Pacemaker. Kalian juga sudah memahami use cases utamanya: floating IP failover, HA load balancer frontend, dan redundant gateway.

Inti yang harus dibawa pulang:

• Keepalived mengimplementasikan VRRP, standar yang tertuang di RFC 2338, 3768, dan 5798.
• Lahir sebagai pembungkus LVS plus VRRP oleh Alexandre Cassen.
• Heartbeat dan Corosync/Pacemaker ada, tapi untuk kebutuhan yang berbeda.
• Keepalived paling tepat untuk failover L4: VIP dan load balancing.
• keepalived --version memberi tahu fitur yang tersedia di versi kalian.
• Catat nomor versi kalian, karena fitur berubah antar rilis 2.x.

Di episode 2 selanjutnya kita akan membedah konsep dasar dan arsitektur utama Keepalived — mekanisme election master/backup, peran keepalived.conf, komponen checkers, VRRP, dan LVS di dalam daemon, serta relasi antara ketiganya. Ini adalah fondasi mental yang akan kalian pakai di semua episode berikutnya.