Belajar LDAP - High Availability & Load Balancing

#Pendahuluan

Di episode 25 kalian menyetel satu server agar cepat. Episode 26 ini membahas bagaimana menyetel banyak server agar directory tetap tersedia — high availability dan load balancing. Konsep replikasi dari episode 13 menjadi fondasi di sini: replica consumer, mirror mode multi-master, load balancer di depan node-node, DNS sebagai lapisan distribusi, dan strategi failover. Tujuannya sederhana: ketika satu server mati karena perawatan atau gangguan, autentikasi dan pencarian tidak boleh berhenti.

#Arsitektur HA

Pilih topologi sesuai kebutuhan tulis dan baca kalian. Tidak ada satu bentuk yang benar untuk semua kasus:

Topologi	Karakteristik	Cocok untuk
Active-passive	Satu master tulis, replica read-only	Beban tulis rendah, prioritas keamanan data
Active-active (mirror mode)	Semua node bisa tulis, sinkron dua arah	Kebutuhan tulis tersebar, failover otomatis
Geographic distribution	Node di beberapa lokasi	Organisasi lintas region
DR site	Replica khusus pemulihan, kadang di-lag	Pemenuhan RPO/RTO antar lokasi

Arsitektur paling umum adalah active-passive: satu master menerima tulis, satu atau lebih consumer melayani pencarian dan autentikasi. Kalau kebutuhan tulis juga tersebar dan kalian menginginkan failover yang benar-benar mulus, gunakan mirror mode — dua node yang saling menerima tulis dan menyinkronkan perubahan dua arah melalui syncrepl.

#Replikasi untuk HA: Mirror Mode

Mirror mode dipasang di kedua node; masing-masing menjadi provider sekaligus consumer bagi node lainnya. Berikut konfigurasi olcSyncrepl yang digabung dengan overlay syncprov di tiap node:

dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModuleLoad: syncprov
 
dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 100 10
 
dn: olcDatabase={1}mdb,cn=config
olcSyncrepl:
  rid=001 provider=ldap://ldap-b.example.com
  type=refreshAndPersist schemachecking=on
  retry="30 5 300 3" mirror=TRUE
olcMirrorMode: TRUE

dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModuleLoad: syncprov
 
dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 100 10
 
dn: olcDatabase={1}mdb,cn=config
olcSyncrepl:
  rid=001 provider=ldap://ldap-a.example.com
  type=refreshAndPersist schemachecking=on
  retry="30 5 300 3" mirror=TRUE
olcMirrorMode: TRUE

mirror=TRUE pada olcSyncrepl membuat entry yang diterima dari provider diperlakukan seperti tulis lokal, sehingga tidak ter-echo kembali ke provider asal — mencegah loop replikasi. olcMirrorMode: TRUE menandai database sebagai multi-master. Dengan ini kedua node menerima tulis, dan contextCSN menjaga urutan perubahan. Konflik diselesaikan dengan membandingkan contextCSN — perubahan dengan timestamp terbaru yang menang.

#Load Balancer

Load balancer duduk di depan node-node dan membagi koneksi. Untuk protokol TCP seperti LDAP, HAProxy adalah pilihan yang umum dan ringan:

option ldap-check memanfaatkan kemampuan HAProxy melakukan pemeriksaan kesehatan berbasis protokol LDAP, bukan sekadar TCP connect. Kalau kalian lebih nyaman dengan Nginx, blok stream menyediakan fitur serupa:

/etc/nginx/nginx.conf - blok stream

stream {
    upstream ldap_backend {
        server 10.0.0.11:389;
        server 10.0.0.12:389;
    }
    server {
        listen 389;
        proxy_pass ldap_backend;
    }
}

Dengan balance roundrobin, setiap koneksi baru diputar ke node berikutnya — ideal untuk autentikasi yang banyak datang dan pergi. Yang perlu diingat: round-robin menganggap semua node setara. Kalau kalian menjalankan active-passive (bukan mirror mode), arahkan tulis hanya ke master dan semua baca ke replica, misalnya dengan dua backend terpisah.

#DNS Load Balancing

DNS adalah lapisan distribusi paling sederhana karena tidak ada komponen tambahan. Dua teknik utama:

Round-robin DNS — satu nama menunjuk ke beberapa alamat IP; klien memilih secara bergiliran. Efektif untuk beban baca yang ringan, tetapi kurang presisi karena tidak sadar kesehatan node.
SRV records — klien LDAP modern bisa mengambil daftar server beserta bobot dan prioritasnya:

SRV record untuk LDAP

_ldap._tcp.example.com.  300  IN  SRV  0 100 389 ldap-a.example.com.
_ldap._tcp.example.com.  300  IN  SRV  0 100 389 ldap-b.example.com.

Perhatikan TTL: semakin kecil TTL (misal 60 sampai 300 detik), semakin cepat klien melihat perubahan saat sebuah node dikeluarkan atau masuk kembali. TTL besar membuat pemulihan failover terasa lambat karena klien menyimpan jawaban DNS terlalu lama.

#Strategi Failover

Failover bisa ditangani di sisi server, sisi klien, atau keduanya:

Client-side failover — beri klien daftar server yang dicoba berurutan. Konfigurasi ldap.conf mendukung beberapa URI:

Bila node pertama tidak menjawab dalam NETWORK_TIMEOUT, libldap mencoba node berikutnya — tanpa menunggu intervensi manusia.

Penanganan kegagalan master — pada active-passive, ketika master mati dan tulis harus diteruskan, promosikan replica menjadi master (konfigurasi tulis diaktifkan di sana), lalu arahkan klien. Pada mirror mode, tidak ada promosi yang perlu dilakukan: node yang tersisa sudah menerima tulis sejak awal. Karena itu mirror mode sangat menarik untuk skenario di mana downtime tulis tidak bisa ditoleransi.

#Monitoring HA

High availability tanpa monitoring hanyalah harapan. Yang harus dipantau terus-menerus:

Health check — load balancer sudah menandai node sehat atau tidak; pantau juga hasil ldapsearch dasar dari sisi klien.
Replication lag — perbedaan contextCSN antara node adalah indikator paling langsung:

Bandingkan contextCSN antar node

ldapsearch -x -LLL -s base -b "" contextCSN

Jalankan perintah ini di setiap node dan bandingkan. Perbedaan yang mencolok berarti replikasi tertinggal — siasati sebelum node tertinggal permanen.

Alerting — kirim notifikasi saat node gagal health check atau saat lag replikasi melewati ambang (misal beberapa menit). Skrip cron sederhana yang mengecek contextCSN sudah jauh lebih baik daripada tidak ada.
Failover testing — matikan satu node secara berkala di staging (atau jadwal perawatan nyata) dan pastikan klien pindah tanpa gangguan. HA yang tidak pernah diuji akan gagal saat benar-benar dibutuhkan.

Tip

Untuk mirror mode, pastikan kedua node memakai credential replikasi yang sama dan schemachecking=on. Perubahan schema di satu node menyebar ke node lain lewat replikasi — kalau konfigurasi tidak seragam, cek contextCSN di cn=config juga, bukan hanya di database data.

#Penutup

Pada episode 26 ini, kalian memilih topologi HA yang sesuai, menyusun mirror mode dengan syncrepl dan olcMirrorMode, mengonfigurasi HAProxy dan Nginx untuk load balancing, memakai DNS round-robin dan SRV records, menerapkan failover di sisi klien, serta memantau kesehatan dan lag replikasi.

Inti yang harus dibawa pulang:

Pilih topologi dari kebutuhan — active-passive untuk kesederhanaan, mirror mode untuk failover tulis yang mulus.
Load balancer membagi koneksi; DNS round-robin menambah lapisan distribusi yang murah.
NETWORK_TIMEOUT dan daftar URI membuat klien pindah server sendiri.
Replication lag dipantau lewat contextCSN, bukan perasaan.

Di episode 27 berikutnya, kita memasuki sisi yang tidak menyenangkan tapi tak terhindarkan: troubleshooting — membaca log, men-debug dengan ldapsearch -d, dan menyelesaikan masalah autentikasi, pencarian lambat, dan replikasi yang macet.