Sesi 13 — Semua Server Hidup, Sistem Tetap Mati: SPOF, High Availability, & Split Brain

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 1 dan Node 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).

\text{Quorum} = \left\lfloor \frac{N}{2} \right\rfloor + 1

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.

Sesi 13: Semua Server Hidup, Sistem Tetap Mati: SPOF, High Availability, & Split Brain

Versi video sesi ini