Sesi 13: Semua Server Hidup, Sistem Tetap Mati: SPOF, High Availability, & Split Brain
Bagaimana jika kita punya 10 server aplikasi berkecepatan tinggi, tapi semuanya tersambung lewat satu perangkat tunggal yang tidak punya kembaran?
1. Masalah Utama: Ilusi Redundansi Parsial (SPOF)
Banyak tim membanggakan arsitektur mereka: "Kami punya 10 web server, 5 worker, dan auto-scaling!"
Namun jika ditelusuri diagram jaringannya: - 10 web server itu semua berada di belakang 1 unit Load Balancer tunggal. - Atau semua server ditenagai oleh 1 Power Distribution Unit (PDU) rak server. - Atau semua traffic melewati 1 Core Switch jaringan.
INTERNET
│
▼
┌───────────────────┐
│ SINGLE LB / SWITCH│ ◄── SINGLE POINT OF FAILURE (SPOF)!
└─────────┬─────────┘ (Jika ini mati, SEMUA MATI)
┌─────────────┼─────────────┐
▼ ▼ ▼
┌───────────┐ ┌───────────┐ ┌───────────┐
│ Server 1 │ │ Server 2 │ │ Server 10 │
│ (100% UP) │ │ (100% UP) │ │ (100% UP) │
└───────────┘ └───────────┘ └───────────┘
Hasilnya: Kesepuluh server aplikasi berstatus 100% sehat dan menyala, tetapi sistem tetap mati total bagi seluruh user di dunia. Inilah yang disebut Single Point of Failure (SPOF).
2. High Availability (HA): Menghilangkan Titik Tunggal Kegagalan
Prinsip dasar High Availability (HA) adalah: Tidak boleh ada komponen apa pun dalam jalur kritis transaksi yang berdiri sendiri tanpa pasangan redundansi.
Dua Pola Redundansi HA:
A. Active-Passive (Master-Standby)
- Cara Kerja: Node Primer (
Active) melayani 100% traffic. Node Sekunder (Passive / Standby) siaga memonitor heartbeat. - Failover: Jika Node Primer mati, Node Sekunder mengambil alih alamat Virtual IP (VIP) via protokol VRRP / Keepalived.
- Kelebihan: Sangat mudah diprediksi, tidak ada komplikasi sinkronisasi data dua arah.
- Kekurangan: 50% kapasitas hardware menganggur (idle capacity waste).
B. Active-Active
- Cara Kerja: Kedua node (
Node 1danNode 2) sama-sama aktif menerima dan memproses traffic secara bersamaan. - Failover: Jika salah satu mati, node yang tersisa menanggung 100% beban.
- Kelebihan: Efisiensi hardware maksimal, tidak ada mesin yang terbuang percuma.
- Kekurangan: Kapasitas cluster harus dirancang dengan headroom 50% agar saat 1 node tumbang, node yang tersisa tidak ikut meledak karena overloaded.
3. Bahaya Mematikan: Split Brain & Quorum
Apa yang terjadi jika koneksi jaringan (link kabel heartbeat) antara dua node redundan terputus, padahal kedua node itu sendiri masih hidup?
┌──────────────┐ ┌──────────────┐
│ NODE A │ X [HEARTBEAT] X │ NODE B │
│ "B Mati!" │ TERPUTUS │ "A Mati!" │
│ JADI MASTER! │ │ JADI MASTER! │
└──────┬───────┘ └──────┬───────┘
│ │
▼ ▼
[Tulis ke Disk] [Tulis ke Disk]
└───► KORUPSI DATA TOTAL! ◄──┘
Fenomena Split Brain:
- Node A mengira Node B mati ──► Node A menyatakan diri sebagai
MASTER. - Node B mengira Node A mati ──► Node B juga menyatakan diri sebagai
MASTER. - Keduanya menerima traffic dan menulis data yang bertentangan ke storage/database ──► Data Corruption permanen (Kehancuran database).
Solusi Split Brain: Quorum & Odd Number Nodes (Aturan Ganjil)
Sistem terdistribusi modern (seperti etcd, Zookeeper, Raft, Paxos) melarang cluster berjumlah genap (2 node). Mereka mewajibkan minimal 3 node (atau angka ganjil: 3, 5, 7).
- Pada cluster 3 node: \text{Quorum} = \lfloor 3/2 \rfloor + 1 = 2.
- Jika terjadi network partition (1 node terisolasi dari 2 node lainnya):
- Kubu mayoritas (2 node) memiliki Quorum (2/2) ──► Lanjut Melayani Traffic.
- Kubu minoritas (1 node) tidak punya Quorum (1/2) ──► Otomatis Mundur (Self-Isolate / Read-Only).
- Split brain mustahil terjadi!
4. Metrik Kesiapan Bencana: RTO dan RPO
Dalam mendesain sistem HA dan Disaster Recovery, dua angka ini wajib disepakati di awal dengan bisnis:
KEJADIAN BENCANA
│
▼
◄────────────┼────────────────────────► WAKTU
RPO │ RTO
(Data Hilang)│ (Waktu Mati Sistem)
| Metrik | Nama Panjang | Pertanyaan Bisnis | Target Ideal |
|---|---|---|---|
| RTO | Recovery Time Objective | "Berapa lama sistem boleh padam sebelum menyala kembali?" | < 5 detik (Auto failover) |
| RPO | Recovery Point Objective | "Berapa banyak data transaksi terakhir yang boleh hilang?" | 0 byte (Zero Data Loss) |
5. Jebakan Terbesar: Redundansi Tanpa Uji Failover adalah Asumsi
Banyak perusahaan merasa aman karena memiliki server cadangan, namun saat bencana asli terjadi: 1. Script failover otomatis ternyata error karena permission file. 2. Sertifikat SSL di server cadangan ternyata sudah kedaluwarsa 6 bulan lalu. 3. Kapasitas server cadangan tidak pernah diuji untuk menampung 100% beban puncak.
Hukum Keras SRE: "Sistem failover yang tidak pernah diuji sengaja (GameDay / Chaos Engineering) dijamin akan gagal saat bencana sebenarnya tiba."
6. Ringkasan Desain HA
| Komponen | Masalah SPOF | Solusi HA |
|---|---|---|
| Pintu Masuk (VIP) | 1 Load Balancer mati | Dual LB dengan VRRP / Keepalived (Active-Passive / Active-Active) |
| Server Aplikasi | Server crash / memory leak | Stateless Pool + Health Check Drain |
| Shared State (Redis) | 1 Redis mati | Redis Sentinel / Redis Cluster (Quorum 3 node) |
| Database | 1 DB mati | Primary-Replica + Auto Failover (Patroni / Orchestrator) |
| Koordinasi Cluster | Split Brain | Raft Consensus + Quorum Ganjil (3 atau 5 node) |
7. Istilah Kunci
SPOF (Single Point of Failure): Titik tunggal yang jika rusak membuat seluruh sistem tumbang.HA (High Availability): Desain sistem tanpa SPOF yang menjamin uptime tinggi.Active-Passive: Satu melayani, satu siaga.Active-Active: Semua melayani bersamaan dengan batas headroom.Failover: Pengalihan otomatis beban kerja ke node cadangan.Split Brain: Kondisi di mana dua node saling mengklaim sebagai Master akibat putusnya link komunikasi.Quorum: Jumlah suara mayoritas (\lfloor N/2 \rfloor + 1) yang sah untuk mengambil keputusan.RTO / RPO: Batas toleransi waktu pemulihan dan batas toleransi kehilangan data.