Belajar LDAP - Replikasi
Mendistribusikan direktori ke banyak server dengan syncrepl: konsep provider dan consumer, mode refreshOnly dan refreshAndPersist, delta syncrepl, mirror mode dan multi-master, serta monitoring lag replikasi.
#Pendahuluan
Di episode 12 kalian menerapkan kebijakan password pada satu server. Sekarang bayangkan organisasi mulai tumbuh: aplikasi tersebar di beberapa lokasi, dan satu server menjadi titik kegagalan serta kemacetan. Episode 13 ini menjawabnya dengan replikasi — bagaimana data direktori disalin secara otomatis dari satu server ke server lain memakai protokol syncrepl yang sudah kalian kenal sekilas sebagai salah satu overlay di episode 11.
#Konsep Replikasi
Replikasi di OpenLDAP berputar pada dua peran dasar:
- Provider (sebelumnya disebut master) — server sumber yang menerima penulisan dan menyebarkan perubahan.
- Consumer (sebelumnya replica atau slave) — server yang menerima salinan data dan melayani pencarian.
Istilah master dan slave kini digantikan provider dan consumer karena lebih akurat menggambarkan hubungan — sebuah consumer di satu replikasi bisa saja menjadi provider bagi consumer lain. Perubahan disebarkan dengan protokol syncrepl, yang pada dasarnya sebuah persistent search: consumer membuka koneksi dan provider mengirimkan setiap modifikasi yang terjadi.
Mode replikasi di OpenLDAP adalah: single-master (satu provider), mirror mode (dua server saling menerima tulis), dan N-way multi-master (semua server bisa menerima tulis).
#Mode Replikasi
Tiga mode sinkronisasi syncrepl yang harus kalian pahami:
| Mode | Cara Kerja | Karakteristik |
|---|---|---|
refreshOnly | Consumer mempolling provider secara berkala | Polling, ada interval interval, cocok untuk bandwidth kecil |
refreshAndPersist | Provider mendorong perubahan seketika dan menjaga koneksi | Push real-time, perubahan tiba tanpa menunggu interval |
| delta-syncrepl | Consumer meminta hanya perubahan sejak titik tertentu | Efisien, butuh accesslog di provider |
Dalam refreshOnly, consumer bertanya ke provider tiap interval dan menerima snapshot penuh dari data yang berubah. refreshAndPersist memulai dengan snapshot awal lalu membiarkan koneksi terbuka — perubahan berikutnya dikirim langsung. Delta-syncrepl memakai log perubahan (accesslog overlay) sehingga yang dikirim hanya delta, bukan seluruh context.
#Replikasi Single-Master
Setup paling umum: satu provider menulis, satu atau banyak consumer membaca. Consumer perlu akun bind khusus, dibuat sebagai entry biasa — misalnya cn=replicator,dc=example,dc=com — dengan hak ACL read dan search terhadap seluruh suffix.
dn: cn=replicator,dc=example,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: replicator
description: Replication bind account
userPassword: rahasia-kuat-123Di sisi provider, aktifkan overlay syncprov:
dn: cn=module{0},cn=config
objectClass: olcModuleList
olcModulePath: /usr/lib/ldap
olcModuleLoad: syncprov.la
dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 100 10
olcSpSessionlog: 100olcSpCheckpoint: 100 10 menyimpan log sinkronisasi setiap 100 operasi atau 10 menit, dan olcSpSessionlog membatasi jumlah perubahan yang dipertahankan untuk client offline.
Di sisi consumer, tambahkan atribut olcSyncrepl ke database:
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl: {0}rid=001 \
provider=ldap://ldap01.example.com:389 \
bindmethod=simple \
binddn="cn=replicator,dc=example,dc=com" \
credentials=rahasia-kuat-123 \
searchbase="dc=example,dc=com" \
type=refreshAndPersist \
retry="5 5 300 +" \
interval=00:00:00:30rid adalah identitas replikasi unik per server. Untuk menguji, lakukan modifikasi di provider lalu cari di consumer dan bandingkan contextCSN:
ldapmodify -x -D cn=admin,dc=example,dc=com -W
ldapsearch -x -H ldap://ldap02.example.com -b dc=example,dc=com contextCSN#Delta-syncrepl
Agar hanya perubahan yang dikirim (bukan seluruh data), pasang accesslog overlay di provider. Ini sangat membantu saat banyak consumer dan bandwidth terbatas:
dn: olcDatabase={2}mdb,cn=config
objectClass: olcDatabaseConfig
olcDatabase: mdb
olcDbDirectory: /var/lib/ldap/accesslog
olcSuffix: cn=accesslog
olcDbIndex: entryCSN eq
olcDbIndex: objectClass eqConsumer lalu menambahkan syncdata=accesslog pada olcSyncrepl-nya, dan provider menjalankan overlay syncprov di atas database accesslog. Perubahan diteruskan sebagai log entry alih-alih data mentah, sehingga trafik replikasi jauh lebih ringan.
#Mirror Mode dan Multi-Master
Ketika single-master tidak cukup, kalian bisa membuat lebih dari satu server yang menerima tulis. Mirror mode adalah bentuk dua-node: kedua server sama-sama menerima penulisan dan saling mereplikasi, dengan olcMirrorMode: TRUE di kedua sisi. N-way multi-master membuka ini ke banyak node sekaligus.
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcMirrorMode
olcMirrorMode: TRUE
dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1 ldap://ldap01.example.comDi server kedua, olcServerID berubah menjadi 2 ldap://ldap02.example.com. Setiap node tetap menjalankan syncprov dan saling memasang olcSyncrepl satu sama lain.
Konsekuensi terpenting multi-master adalah konflik penulisan. OpenLDAP menyelesaikannya dengan membandingkan contextCSN — perubahan dengan CSN terbesar (paling baru) yang menang. Artinya, jika dua admin mengubah entry yang sama di server berbeda, hasilnya ditentukan oleh waktu, bukan urutan manusia. Karena itu, hindari multi-master kecuali benar-benar butuh; mirror mode biasanya sudah cukup dan jauh lebih mudah diprediksi.
#Monitoring Replikasi
Replikasi perlu diawasi, bukan dipasang lalu dilupakan:
contextCSN— nilai ini mengidentifikasi titik sinkronisasi. Consumer yang lag memilikicontextCSNlebih lama dari provider.- Replication lag — bandingkan timestamp di
contextCSNkedua server; selisihnya adalah lag. - Sync state — hasil bind
olcSyncrepldan log slapd menampilkan pesan sinkronisasi seperti syncrepl_entry saat entry disinkronkan. - Troubleshooting — periksa kredensial
cn=replicator, pastikan ACL memberi akses baca, dan cek apakah port 389 terbuka dari consumer ke provider.
ldapsearch -x -H ldap://ldap01.example.com -b dc=example,dc=com contextCSN
ldapsearch -x -H ldap://ldap02.example.com -b dc=example,dc=com contextCSNTip
Buat skrip sederhana yang mengambil contextCSN dari provider dan semua consumer, lalu hitung selisihnya. Replikasi yang sehat punya selisih dalam hitungan detik pada refreshAndPersist; selisih yang membesar menandakan masalah jaringan, kredensial, atau beban berlebih.
#Best Practices
- Master di jaringan terlindungi — simpan provider di segmen yang hanya bisa diakses server internal.
- Replica untuk read scaling — arahkan pencarian dan bind aplikasi ke consumer, tulis ke provider.
- Monitor replication lag — lag yang membesar adalah gejala awal kegagalan.
- Uji skenario failover — matikan provider, promosikan consumer (ubah read-write), lalu kembalikan; lakukan berkala.
- Strategi backup — backup data dari provider atau consumer tanpa mengganggu layanan;
slapcatdi masing-masing node tetap valid karena data identik.
#Penutup
Pada episode 13 ini kalian memahami replikasi OpenLDAP: peran provider dan consumer, protokol syncrepl, perbedaan refreshOnly, refreshAndPersist, dan delta-syncrepl, konfigurasi single-master dengan overlay syncprov, mirror mode dan multi-master dengan olcServerID, penyelesaian konflik lewat contextCSN, monitoring lag, serta praktik terbaik untuk failover dan backup.
Inti yang harus dibawa pulang:
- Provider menulis, consumer membaca — pola single-master adalah default yang paling aman.
refreshAndPersistadalah mode umum — perubahan tiba real-time tanpa polling.- Delta-syncrepl hemat bandwidth — tapi butuh accesslog di provider.
contextCSNadalah tolok ukur kesehatan — lag adalah gejala, bukan hal yang dianggap normal.
Di episode 14 berikutnya, kita membahas LDAP indexing — bagaimana olcDbIndex membuat pencarian cepat dan mencegah slapd memindai seluruh database. Replikasi yang kalian bangun akan sangat bergantung pada index yang benar di sisi consumer.