Belajar Data Center Engineer - DC Interconnect & DCI

#Pendahuluan

Setelah di episode 23 kita menyelesaikan pilar SDDC, sekarang kita hubungkan gedung-gedungnya: Data Center Interconnect (DCI). Episode 13 (DR) dan 14 (hybrid) menyentuh kebutuhan ini; hari ini kita teknis penuh — bagaimana dua fasilitas berjarak puluhan kilometer bekerja sebagai satu kesatuan untuk replikasi, failover, bahkan kluster aktif-aktif.

DCI adalah disiplin di mana fisika kembali berkuasa: jarak = latensi, latensi = batas arsitektur. Kita mulai dari use case, lewati opsi transport, hitung budget latensi, lalu desain dan ukur interconnect sungguhan.

#Use Case DCI

Kenapa dua DC perlu bersambung? Empat alasan utama:

text

1. Replikasi data      : storage/DB sync-async antar site (DR, ep.13)
2. Failover layanan    : DNS/LB memindahkan user saat site mati
3. Kluster terdistribusi: database quorum, cache cluster lintas site
4. Migrasi & bursting  : pindah workload tanpa downtime panjang

Setiap use case punya toleransi latensi berbeda — dan itulah yang menentukan pilihan transport.

#Opsi Transport: Dari Fiber Sendiri sampai Internet

Opsi	Bandwidth	Latensi	Biaya	Cocok Untuk
Dark fiber	Tak terbatas (lambat cahaya saja)	Terendah	Capex tinggi	Jarak metro, volume besar
DWDM (wave)	Nx100G per wave	Rendah	Opex sewa	Metro/regional carrier-grade
EVPN/MPLS L2VPN/L3VPN	Per kontrak	Rendah-menengah	Opex	Multi-site enterprise
Internet + IPsec	Fleksibel	Tertinggi & variabel	Termurah	Fallback & non-kritikal

Praktik yang sehat: kombinasi. Link utama privat (dark fiber/DWDM/EVPN) + fallback IPsec via provider berbeda — persis pola episode 14, dinaikkan skala antar-fasilitas.

Aturan redundansi fisik yang sering dilanggar: diverse path. Dua link "berbeda" yang ternyata melewati terowongan fiber yang sama akan putus bersamaan saat backhoe lewat. Minta dokumentasi rute dari carrier dan pastikan jalurnya benar-benar terpisah.

#Budget Latensi: Fisika Tidak Bisa Ditawar

Rumus dasar yang wajib melekat:

text

Latensi fiber ≈ 5 µs/km satu arah (indeks refraksi ±1.5)
 
Jarak 10 km : RTT ±0.1 ms   -> metro dekat, sync replication OK
Jarak 30 km : RTT ±0.3 ms   -> masih layak sync DB tertentu
Jarak 100 km: RTT ±1.0 ms   -> sync mulai mahal bagi DB transaksional
Jarak 500 km: RTT ±5 ms     -> async territory

Tambahkan overhead perangkat (router, encryption, multiplexer) ±0.2-1 ms per hop. Aturan desainnya: ukur, jangan hitung teori saja — realitas rute fiber jarang lurus.

#Risiko Perpanjangan Layer 2

Pertanyaan klasik DCI: "bisa gak VLAN-nya diperpanjang ke site kedua?" Jawaban engineering-nya: bisa, tapi pahami harganya:

text

Perpanjangan L2 artinya:
- Satu domain broadcast      : ARP/flood lintas WAN memboros bandwidth
- Domain spanning-tree       : loop lintas site = outage dua site
- Failure domain gabungan    : masalah site A bisa merambat ke site B

Solusi modern adalah EVPN Multi-homing / VXLAN lintas site: hanya traffic yang dibutuhkan yang melewati WAN (ARP suppression, MAC routing), failure domain tetap terpisah per site. Prinsip emasnya:

Important

Stretch Layer 2 seminimal mungkin dan hanya jika aplikasi menuntut (klustering tertentu, live migration lintas site). Untuk mayoritas kasus, routing L3 antar site + replikasi aplikasi-level lebih tahan banting daripada L2 panjang.

#Desain Aktif-Aktif Antar Site

Arsitektur paling tangguh: kedua site melayani trafik bersamaan.

100%

Komponen kuncinya:

Traffic steering — anycast/GSLB mendistribusikan user; saat satu site mati, steering otomatis.
Data layer konsisten — DB primary-replica atau multi-primary; inilah bagian tersulit (latensi budget episode ini).
Stateless tier bebas — app/web identik di kedua site; konfigurasi via automation agar tidak drift (episode 22).
Kuorum hati-hati — sistem voting (DB cluster, etcd) butuh jumlah node ganjil lintas site agar split-brain terhindar.

#Praktik: Mengukur Interconnect Sungguhan

Sebelum percaya angka vendor, ukur sendiri. Dari host di DC1 ke host di DC2:

Ukur RTT dan jitter antar site

ping -c 20 -i 0.2 dc2-target.lab | tail -n 3
mtr -rwc 50 dc2-target.lab

text

rtt min/avg/max/mdev = 0.812/0.874/1.103/0.056 ms

RTT ±0.87 ms konsisten dengan jarak ±60 km + overhead perangkat. Yang sama pentingnya adalah jitter (mdev): replikasi sync sensitif terhadap lonjakan, bukan hanya rata-rata. Lanjutkan dengan throughput:

Ukur bandwidth DCI

iperf3 -s            # di sisi DC2
iperf3 -c dc2-target.lab -t 30 -P 4    # dari DC1, 4 stream

Catat ketiganya (RTT, jitter, throughput) sebagai baseline dc-docs/network/dci-baseline.md — monitoring bulanan akan memberi tahu kapan link mulai degradasi sebelum pengguna merasakannya.

#Common Pitfalls DCI

Satu rute fisik dua nama vendor — diverse path harus diverifikasi dokumen rute, bukan diasumsikan.
Replikasi sync melebihi budget — commit DB melambat drastis; hitung RTT maksimum yang ditoleransi aplikasi SEBELUM memilih lokasi site kedua.
Lupa bandwidth burst replikasi — resync penuh setelah maintenance bisa menghabiskan link berhari-hari; rencanakan QoS/throttling.
Monitoring per-link bukan per-layanan — link hijau belum tentu layanan hijau; monitor replikasi lag & health kluster lintas site secara langsung.

#Penutup

Inti yang harus dibawa pulang:

DCI melayani empat tujuan: replikasi, failover, kluster terdistribusi, migrasi/bursting — masing-masing dengan toleransi latensi berbeda.
Pilih transport sesuai kebutuhan: dark fiber/DWDM untuk metro serius, EVPN/MPLS untuk multi-site, IPsec internet selalu sebagai jalur cadangan diverse-path.
Latensi fiber ±5 µs/km satu arah adalah angka desain; ukur RTT+jitter+throughput nyata dan simpan baseline-nya.
Hindari stretch L2 berlebihan; aktif-aktif butuh steering trafik, konsistensi data layer, dan kuorum yang dirancang.

Di episode 25 selanjutnya kita naik ke kursi strategi: data center strategy & roadmap — siklus hidup fasilitas dari plan-build-operate-retire, kerangka keputusan build vs colo vs cloud, menyusun roadmap modernisasi bertahap dengan quick win dulu, dan cara memprioritaskan proyek dengan skor dampak-usaha. Sampai jumpa di episode 25!