Mengapa Partisi Jaringan Asimetris Meremukkan Quorum Raft pada Migrasi Hybrid Datacenter

Banyak tim infrastruktur menganggap matematika konsensus Raft cukup sederhana: tiga node memberikan toleransi satu kegagalan, lima node memberikan toleransi dua. Seperti yang diulas secara gamblang dalam analisis 3-Node HA Kubernetes: Quorum and Split-Brain Explained, aturan quorum Q = ⌊N/2⌋ + 1 menjaga etcd agar tidak terjebak dalam skenario split-brain saat partisi jaringan membelah klaster secara biner. Namun, teori buku teks ini hampir selalu mengasumsikan model kegagalan simetris: jika Node A tidak bisa mengirim paket ke Node B, maka Node B diasumsikan tidak bisa mengirim paket balik ke Node A. Asumsi tersebut hancur berkeping-keping saat Anda mengeksekusi migrasi hybrid datacenter. Skenario tipikalnya terlihat masuk akal di atas kertas: dua control plane node berada di on-premise datacenter, lalu satu node control plane baru di-spin up di cloud provider melalui tautan AWS DirectConnect atau dedicated VPN tunnel untuk proses transisi bertahap. Di sinilah monster yang sesungguhnya bersembunyi: partisi jaringan asimetris (asymmetric network partition). Jaringan tidak putus total; alih-alih, paket data hanya mengalir lancar di satu arah, membingungkan algoritma Raft dan membekukan state Kubernetes secara hening.

Anatomi Kerusakan: Mengapa Heartbeat Bertepuk Sebelah Tangan

Dalam protokol Raft yang menjadi tulang punggung etcd, seorang leader mempertahankan otoritasnya dengan mengirimkan periodik heartbeat (MsgHeartbeat berupa entri log kosong) ke seluruh follower. Jika follower tidak menerima heartbeat sebelum interval electionTimeout terlampaui, node tersebut mengasumsikan leader telah mati, menaikkan angka term, berubah status menjadi candidate, lalu membroadcast RPC MsgVote ke anggota klaster lain. Bayangkan skenario tiga node (A, B, dan C) di mana Node B adalah leader. Karena adanya stateful firewall routing flap atau asymmetric BGP path pada koneksi transit hybrid, tautan antara Node A (on-prem) dan Node B (on-prem) menjadi asimetris: Node A dapat menerima paket dari Node B, tetapi paket balasan dari Node A ke Node B di-drop di layer switch atau conntrack table. Sementara itu, Node C di cloud dapat berkomunikasi normal dua arah dengan Node B, namun memiliki latensi tinggi ke Node A. Pada kondisi ini, Node B mengirim heartbeat ke Node A. Node A memprosesnya dan mengirim ACK (MsgHeartbeatResp). Namun, karena jalur A → B putus, ACK tersebut lenyap tanpa jejak. Node B menganggap Node A unreachable. Di saat bersamaan, jika arah sebaliknya yang terganggu di mana Node A tidak pernah menerima heartbeat dari Node B, Node A akan mengalami election timeout. Node A seketika menaikkan term-nya, mendeklarasikan pemilu, dan mengirim MsgVote ke Node B dan Node C. Ketika pesan vote ini berhasil mencapai Node B atau Node C lewat jalur yang masih terbuka, etcd leader (Node B) terpaksa turun tahta (step down) menjadi follower karena melihat adanya pesan dari term yang lebih tinggi. Pemilu dimulai, tetapi tidak ada candidate yang bisa mengumpulkan suara mayoritas yang stabil. Klaster terperangkap dalam siklus infinite election loop.

BASH

# Memeriksa fluktuasi kepemimpinan etcd via log journald
journalctl -u etcd -f | grep -E 'raft.node: raft|leader changed|elected leader'
# Indikasi khas partisi asimetris:
# "raft: 8a9b2c3d stepped down to follower because term 42 is higher than 41"
# "raft: 8a9b2c3d became leader at term 43"
# "raft: 8a9b2c3d stepped down to follower because term 44 is higher than 43"

Jebakan Metrik Sintetis dan Kegagalan Observabilitas Standar

Bencana ini sering kali lambat diidentifikasi karena sistem monitoring standar memberikan sinyal aman (false positive). Probe HTTP liveness kubernetes dari luar cluster (/healthz API server) kerap kali masih merespons 200 OK selama beberapa detik awal karena kube-apiserver masih melayani pembacaan dari cache in-memory. Pemeriksaan ICMP ping antar-server juga sering kali sukses karena rute paket ICMP mungkin melewati antarmuka routing yang berbeda dibanding segmen overlay VXLAN atau port etcd peer (2380). Secara eksternal, dashboard observabilitas memperlihatkan semua node berstatus 'Ready'. Namun di balik layar, setiap operasi mutasi—seperti pembuatan pod baru, rotasi Secret, atau update endpoints oleh CNI—tertahan tanpa batas waktu (freeze). Kubelet di worker node gagal memperbarui heartbeat statusnya ke API server, yang pada akhirnya memicu node eviction massal secara keliru setelah node-monitor-grace-period habis, memperluas blast radius dari control plane ke data plane workloads.

Menjinakkan Partisi: Pre-Vote Phase dan Batasan Geografis Raft

Solusi rekayasa pertama di level algoritma untuk memitigasi disruptive term bumping adalah mekanisme Raft Pre-Vote, yang dirancang untuk mencegah node yang terisolasi merusak stabilitas klaster. Dalam fase Pre-Vote, candidate tidak langsung menaikkan term resminya. Ia mengirimkan MsgPreVote dua arah untuk menanyakan: "Apakah mayoritas node klaster setuju bahwa leader saat ini sudah mati dan saya layak mencalonkan diri?" Jika candidate tidak menerima respon mayoritas spekulatif, ia tidak akan pernah menaikkan term klaster. Fitur ini diaktifkan secara default pada versi etcd modern via parameter engine Raft, sebagaimana didokumentasikan dalam panduan Frequently Asked Questions (FAQ) etcd. Namun, Pre-Vote bukanlah peluru perak untuk arsitektur hybrid yang keliru sejak awal. Menjalankan stretched etcd cluster yang melintasi dua availability zone on-premise dan satu region cloud di seberang WAN adalah anti-pattern yang berbahaya. Fluktuasi RTT (round-trip time) di atas 15-30ms pada jalur WAN hybrid akan membuat batas election-timeout default (1000ms) dan heartbeat-interval (100ms) menjadi sangat rapuh terhadap jitter sekecil apa pun.

YAML

# Parameter etcd untuk meredam jitter jaringan WAN (jika terpaksa dilakukan)
ETCD_HEARTBEAT_INTERVAL: 250
ETCD_ELECTION_TIMEOUT: 1250
ETCD_PRE_VOTE: "true"

Langkah Taktis dan Mitigasi di Lapangan

Jika klaster Anda sudah terlanjur mengalami freeze akibat kegagalan quorum yang tidak bisa pulih sendiri, restart daemon etcd tidak akan menyelesaikan masalah selama asimetri rute masih ada. Langkah penanganan operasional berjenjang yang harus diambil mencakup:

Deteksi Asimetri di Level Socket: Gunakan eBPF tracing atau utilitas tcpdump untuk memastikan alur ACK dua arah pada port 2380, bukan sekadar memverifikasi handshake SYN/ACK awal. Periksa status antrean soket dengan perintah ss -t -i 'sport = :2380 or dport = :2380' untuk melihat apakah terjadi penumpukan unacknowledged packets (unacked) yang mengindikasikan silent drop.
Isolasi Node yang Mengalami Partisi: Segera cabut node hybrid yang bermasalah dari konfigurasi keanggotaan etcd (etcdctl member remove <member-id>) alih-alih membiarkannya terus-menerus memicu kontestasi pemilu di latar belakang.
Prosedur Quorum Recovery Darurat: Jika mayoritas node kehilangan sinkronisasi log secara permanen, ikuti runbook operasional seperti yang dijabarkan dalam Canonical Kubernetes Quorum Restoration Guide untuk merekonstruksi klaster dari satu node survivor yang paling mutakhir menggunakan flag --force-new-cluster.

Fondasi konsensus terdistribusi tidak memaafkan ilusi jaringan yang mulus. Dalam setiap perencanaan migrasi infrastruktur menuju hybrid cloud, jangan pernah memperlakukan tautan antar-datacenter setara dengan backplane top-of-rack switch lokal. Pendekatan yang jauh lebih aman adalah menjaga control plane etcd tetap utuh di satu sisi jaringan hingga proses migrasi data selesai, lalu melakukan cutover switch DNS kube-apiserver secara atomik, alih-alih meregangkan satu klaster Raft melintasi jurang WAN yang tidak stabil.