Belajar System Administrator - High Availability & Failover

#Pendahuluan

Di episode 16 kalian mengenal load balancer; episode 21 membuat server cepat. Episode 22 menggabungkan keduanya menuju tujuan terakhir operasional: layanan yang terus tersedia — High Availability (HA).

Kenyataan yang harus diterima setiap sysadmin: semua server akan mati. Yang membedakan organisasi profesional adalah seberapa cepat layanan kembali. HA bukan soal mencegah kegagalan — itu mustahil — melainkan soal merancang sistem agar kegagalan satu komponen tidak menghentikan layanan.

#Mengukur Ketersediaan

Ketersediaan diukur dengan uptime percentage:

Semakin banyak "sembilan", semakin mahal biayanya — HA adalah keputusan bisnis, bukan sekadar teknis. Kalian tidak butuh 99.999% untuk blog; kalian butuh untuk sistem pembayaran.

#Komponen HA

HA dibangun dari tiga komponen yang saling bekerja:

1. Redundancy — lebih dari satu server (tidak ada titik gagal tunggal).
2. Health check — pendeteksi kegagalan (probe yang memberitahu "server ini mati").
3. Failover — pengalihan otomatis saat satu server gagal.

Poin penting yang sering dilupakan: redundancy tanpa failover otomatis hanyalah "dua server mati bergantian". Sistem harus mendeteksi dan beralih sendiri.

#Health Check: Mata Load Balancer

Health check adalah denyut nadi backend. Ada beberapa level:

Implementasi dengan Nginx:

upstream backend_app {
    server 192.168.56.11:3000 max_fails=3 fail_timeout=30s;
    server 192.168.56.12:3000 max_fails=3 fail_timeout=30s;
}
 
server {
    listen 80;
    server_name app.example.com;
 
    location / {
        proxy_pass http://backend_app;
    }
}

max_fails=3 fail_timeout=30s berarti: jika 3 probe gagal dalam 30 detik, backend dikeluarkan dari pool sementara — dan Nginx mengarahkan semua trafik ke server yang sehat. Inilah failover otomatis level dasar.

#Clustering dan Virtual IP (VIP)

Load balancer sendiri bisa menjadi titik gagal. Solusinya clustering: dua node aktif-standby dengan Virtual IP (VIP) — satu IP yang melayani, berpindah otomatis saat node aktif mati.

Tool klasiknya: Keepalived (VRRP) atau Pacemaker/Corosync untuk level cluster penuh.

sudo apt install -y keepalived

vrrp_instance VI_1 {
    state MASTER
    interface enp0s3
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass ha-secret
    }
    virtual_ipaddress {
        192.168.56.100
    }
}

sudo systemctl enable --now keepalived
ip addr | grep 192.168.56.100

Saat master mati, node backup (priority 90) mengambil alih VIP 192.168.56.100 — client tidak perlu tahu apa-apa, karena yang mereka tuju adalah VIP, bukan server spesifik.

#Failover Database dan Shared State

Bagian tersulit HA adalah state — data yang hidup. Dua pendekatan umum:

Untuk lab, coba PostgreSQL replication sederhana (primary-standby) agar paham konsepnya:

# Di primary: tambahkan ke postgresql.conf
wal_level = replica
max_wal_senders = 5
# Di standby: bangun dari base backup, jalankan
pg_basebackup -h primary-ip -D /var/lib/postgresql/16/main -U replicator -P -R

Ketika primary mati, standby bisa dipromosikan (failover) — kehilangan data seminimal mungkin, sesuai RPO yang ditetapkan.

#Praktik: Setup HA Sederhana

Latihan terpadu di lab:

# 1. Dua instance aplikasi (port 3000 di dua VM / dua container)
docker run -d -p 127.0.0.1:3000 --name app1 my-app:1.0.0   # server A
docker run -d -p 127.0.0.1:3000 --name app2 my-app:1.0.0   # server B
# 2. Load balancer Nginx dengan health check (di atas)
# 3. Uji failover: matikan app1
docker stop app1
curl -sS http://app.example.com   # masih merespons (dilayani app2)
# 4. Hidupkan kembali & amati health check
docker start app1

Jika curl masih merespons saat app1 mati — HA kalian bekerja. Anda baru saja menyaksikan perbedaan antara "satu server" dan "layanan".

#Penutup

Inti yang harus dibawa pulang dari episode 22:

• HA mengukur uptime; jumlah "sembilan" adalah keputusan bisnis.
• Tiga komponen: redundancy, health check, failover otomatis — redundancy saja tidak cukup.
• Health check yang baik memeriksa kesehatan aplikasi, bukan sekadar port.
• Keepalived/VIP menghilangkan titik gagal pada load balancer.
• HA bukan pengganti backup — keduanya wajib berdampingan.

Di episode 23 selanjutnya kita akan membahas Disaster Recovery Planning — RPO/RTO, DR site, dan runbook, dengan praktik simulasi DR di lab. HA menjaga layanan tetap hidup; DR memastikan kalian bisa bangkit kembali setelah yang terburuk!