Belajar Network Engineer - High Availability Network

#Pendahuluan

Setelah di episode 22 fabric data center kalian berdiri megah, satu pertanyaan manajemen akan datang tanpa ampun: kalau ini mati, apa yang terjadi? High availability bukan fitur premium — ia cara berpikir yang harus menyertai setiap keputusan desain sejak hari pertama. Dan ironinya terkenal: mayoritas outage besar terjadi saat redundansi beralih, bukan saat komponen mati diam-diam.

Episode ini membahas matematika availability, metodologi menemukan titik lemah, teknik redundansi tiap lapisan, dan budaya pengujian failover.

#Matematika Availability

Availability diukur dalam persen — dan angka desimalnya punya harga:

Dua konsep yang sering salah dipahami:

1. Availability adalah perkalian rantai: jalur user → switch access → core → WAN → server. Empat komponen 99.9% masing-masing hanya menghasilkan sekitar 99.6% total. Memperbaiki yang terlemah selalu paling murah.
2. MTBF vs MTTR: uptime tinggi bisa dicapai dua arah — perangkat yang jarang rusak (mahal) atau pemulihan super cepat (proses + otomasi). Organisasi matang menginvestasikan MTTR: deteksi cepat, runbook siap, failover otomatis.

#Menemukan Single Point of Failure

SPOF adalah komponen yang matinya melumpuhkan layanan tanpa alternatif. Metode auditnya sistematis — telusuri jalur kritikal dari satu aplikasi bisnis sampai ke sumber listrik:

User laptop -> AP wireless [SPOF jika area cuma 1 AP]
-> Switch access LT2 [PSU tunggal?]
-> Uplink tunggal ke distribusi? [SPOF]
-> Core switch stack [stack cable = titik gabung]
-> Edge router [satu unit? satu ISP?] <- SPOF klasik
-> Firewall [state sync antar unit?]
-> Server ERP [satu VM? satu host? satu storage?] <- tersembunyi favorit

Pengalaman lapangan konsisten: audit pertama hampir selalu menemukan SPOF di tempat tak terduga — listrik (satu UPS untuk semua), cooling (satu AC ruang server), atau kabel uplink kedua yang ternyata masuk switch yang sama. Redundansi fisik yang tidak independen adalah ilusi.

#Teknik Redundansi Per Lapisan

#Link & Path

• Dual uplink dengan ECMP/LACP (episode 4) — semua link aktif, bukan standby tidur.
• Dua ISP dengan BGP multihoming (episode 21) — keluar-masuk otomatis berganti jalur.
• Path fisik berbeda: kabel A lewat riser timur, kabel B barat; dua telco beda last-mile.

#Gateway & Device

• HSRP/VRRP (episode 8) untuk gateway virtual.
• Stacking/virtual chassis: beberapa switch fisik dikelola sebagai satu logis — ring topologi internal.
• MLAG/vPC/multi-chassis LAG: dua switch independen tampil sebagai satu LAG partner bagi server/leaf bawahnya — standar fabric modern.

Perbedaan filosofinya penting: stacking = kontrol plane bersatu (sederhana tapi upgrade berisiko bersama); MLAG = kontrol terpisah dengan sinkronisasi state (lebih tangguh, lebih rumit). Pahami perilaku upgrade masing-masing sebelum memilih.

#Security Appliance

Firewall redundan butuh lebih dari dua kotak: stateful failover — tabel sesi disinkronkan agar koneksi TCP user tidak mati saat aktif berganti (tanpa ini, semua download dan video call putus). Konfigurasikan heartbeat di jalur terpisah dari trafik data, dan pastikan versi OS kedua unit identik.

#Load Balancer & Health Check

LB (L4/L7) menjadi pintu wajib trafik — redundansinya pasangan aktif-standby VRRP, plus health check yang benar:

• Cek yang bermakna: HTTP request nyata ke endpoint health, bukan sekadar ping/TCP connect.
• Interval & threshold proporsional (3x gagal berturut berarti keluar pool).
• Waspadai flapping: health check terlalu sensitif membuat backend masuk-keluar pool dan menggandakan error di atas kondisi aslinya.

#Praktik: Menghapus SPOF dari Desain Kantor

Kembali ke studi kasus kita (120 user) dan naikkan standarnya menjadi tanpa titik mati tunggal:

Wireless      : 2 AP per lantai, controller HA pair
Access        : dual uplink ke DUA distribusi switch berbeda (MLAG)
Distribution  : 2 x L3 switch MLAG, gateway anycast/VRRP
Internet edge : 2 router HSRP + 2 ISP (BGP atau failover NAT)
Firewall      : HA pair stateful, heartbeat terpisah
Power         : 2 feed listrik, UPS terpisah per rack row
Server        : hypervisor cluster >= 3 host, storage replikasi
Monitoring    : probe dari luar + dalam (episode 10)
Runbook       : prosedur failover tiap komponen + kontak vendor

Perhatikan pola meta-nya: setiap lapisan punya dua unit independen — dan independensi mencakup daya, path fisik, dan kontrol plane. Biaya tambahan biasanya 30-60% dari baseline single-unit; bandingkan dengan biaya downtime satu hari operasional, keputusannya sering tidak sulit.

#Common Pitfalls

• Redundansi tidak independen — dua ISP yang lewat satu kanal fiber gedung sama, dua PSU yang colok satu UPS: mati bersamaan persis saat dibutuhkan.
• Failover tanpa capacity planning — node backup sanggup menampung beban penuh? Jika tiap unit dirancang 50% load, satu mati membuat sisanya overload bergantian.
• Split brain — heartbeat putus membuat dua unit sama-sama menganggap diri aktif (dua VIP, dua owner LAG); mitigasinya heartbeat ganda + quorum/witness.
• Asimetri pasca-failover — trafik pulang lewat jalur lain daripada pergi (firewall state ada di unit salah satu sisi); uji dua arah, bukan cuma ping satu arah.

#Penutup

Inti yang harus dibawa pulang:

• Availability dihitung: perkalian rantai + MTBF/MTTR; empat sembilan berarti 52 menit downtime/tahun — mahal dan harus didesain sadar.
• Temukan SPOF dengan menelusuri jalur kritikal end-to-end, termasuk listrik, cooling, dan kabel — bukan cuma diagram logis.
• Tiap lapisan punya tekniknya: ECMP/LACP, HSRP, stacking vs MLAG, firewall stateful pair, LB health check bermakna.
• Independensi redundansi mencakup fisik & kontrol plane; uji failover berkala mengubah klaim menjadi fakta.

Di episode 24 kita optimalkan apa yang sudah tahan banting: network performance — membangun baseline, analisa latency dengan mtr, throughput iperf3, bandwidth-delay product, dan playbook audit performa end-to-end. Sampai jumpa!