Belajar Samba - Cluster & Scale-out (CTDB)

#Pendahuluan

Sampai episode 17, kalian punya satu server Samba yang hebat. Episode 18 menjawab pertanyaan yang muncul saat satu server tidak cukup — atau tidak boleh mati: bagaimana membuat beberapa server Samba bekerja sebagai satu entitas? Jawabannya adalah CTDB (Clustered Trivial Database), komponen yang mengubah kumpulan node Linux menjadi NAS enterprise dengan high availability dan scale-out. Ini topik yang membedakan administrator file server biasa dari arsitek storage.

#Konsep: Mengapa SMB Sulit Di-Cluster

#Masalah Locking

File sharing itu mudah di-cluster selama klien hanya membaca. Masalah muncul saat locking: SMB mengizinkan klien mengunci file (oplock, byte-range lock). Kalau dua node Samba mengelola lock sendiri-sendiri, node A tidak tahu node B sedang mengunci file yang sama — dan dua klien bisa "percaya" mereka memegang hak eksklusif. Hasilnya: korupsi data.

#Solusi CTDB

CTDB menyatukan database lock dari semua node ke satu database terdistribusi (memakai teknologi record-based locking). Setiap node bertanya ke CTDB sebelum mengunci; keputusan lock bersifat cluster-wide. Ini persis analog dari cluster file system di level SMB — inilah mengapa CTDB disebut Clustered Samba.

#Arsitektur CTDB

#Komponen Cluster

Topologi CTDB

        Public IP 192.168.10.50
                 |
   +-------------+-------------+
   |             |             |
 node1          node2         node3
 smbd+ctdb      smbd+ctdb     smbd+ctdb
   |             |             |
   +---- shared storage (CephFS/GPFS) ----+

Setiap node menjalankan smbd + ctdbd dan me-mount storage bersama (cluster filesystem: CephFS, GPFS, GFS2, atau GlusterFS).
Public IP (disebut IP takeover) dimiliki satu node secara aktif; saat node mati, IP dipindah otomatis ke node lain — klien tidak perlu mengganti alamat.
ctdbd menjaga heartbeats antar node dan mengelola failover.

#Mengapa Storage Harus Bersama

Kunci scale-out CTDB: semua node melihat filesystem yang sama. Tidak ada "file di node 1" vs "file di node 2" — ada satu namespace, diakses semua node. CTDB tidak menyalin data; ia hanya menyeragamkan lock dan failover. Tanpa storage bersama, kalian bukan cluster, melainkan beberapa server terpisah dengan IP berbeda.

#Konfigurasi Dasar

#smb.conf di Semua Node

/etc/samba/smb.conf [global] — cluster mode

[global]
   workgroup = LAB
   security = user
   clustering = yes
   idmap config * : backend = tdb
   idmap config * : range = 3000-7999

clustering = yes memberi tahu Samba bahwa ia berjalan di bawah CTDB — locking dan state dipindahkan ke cluster. Semua node harus memakai konfigurasi yang identik agar perilaku konsisten.

#ctbd.conf

/etc/ctdb/ctdb.conf (contoh)

public_addresses = /etc/ctdb/public_addresses

Daftar public IP per node:

/etc/ctdb/public_addresses

192.168.10.50/24 node1
192.168.10.51/24 node2

#Menjalankan dan Memeriksa Cluster

Aktifkan CTDB di semua node

sudo systemctl enable --now ctdb

Verifikasi status cluster:

Status cluster CTDB

sudo ctdb status
sudo ctdb ip
sudo ctdb nodes

ctdb status: daftar node, peran (leader), dan status OK/DISCONNECTED.
ctdb ip: public IP dan node yang aktif memegangnya.
ctdb nodes: daftar anggota cluster.

Warning

CTDB tidak didukung untuk peran AD DC. Replikasi AD adalah mekanisme yang berbeda — menambahkan DC kedua adalah caranya, bukan clustering (episode 9). CTDB adalah solusi untuk file server yang melayani banyak klien; jangan mencampur kedua dunia ini. Untuk file server saja, CTDB sudah cukup tangguh.

#Failover dan Scale-out

#Uji Failover

Matikan satu node (atau sudo ctdb disable node1) dan perhatikan IP berpindah:

Lihat IP berpindah saat node down

sudo ctdb ip

Saat node1 down, public IP-nya diambil node lain dalam hitungan detik — koneksi klien yang memakai IP tersebut tetap berjalan (koneksi TCP aktif bisa terputus dan harus disambung ulang, tapi layanan tidak mati). Ini esensi high availability: downtime dihitung detik, bukan jam.

#Scale-out

CTDB meng-skala dengan menambah node (sampai batas scalability storage) — setiap node menambah kapasitas koneksi dan CPU untuk melayani klien, sementara data tetap satu namespace di storage bersama. Untuk NAS enterprise multi-node:

Gunakan CephFS atau GPFS sebagai storage bersama — keduanya mendukung scale-out sendiri, memberi kapasitas yang nyaris tak terbatas.
Tambah node CTDB untuk menambah throughput SMB tanpa memindahkan data.
Pantau ctdb status dan beban tiap node (episode 20).

Tip

Jangan berpikir CTDB = "replikasi data". Data tinggal di storage bersama; yang direplikasi adalah lock dan state. Artinya storage bersama adalah titik kritis — pastikan storage itu sendiri highly available (Ceph dengan replikasi, GPFS dengan quorum). Cluster Samba di atas storage tunggal yang rapuh hanyalah memindahkan titik kegagalan, bukan menghilangkannya.

#Pitfall Umum

Node tidak bisa bergabung: firewall memblokir port CTDB (4379) antar node — buka di semua arah.
Lock tidak konsisten antar node: clustering = yes tidak aktif di semua node, atau versi Samba berbeda.
Public IP tidak failover: public_addresses salah format atau heartbeats terganggu — cek ctdb status.
Data korup setelah failover: storage bersama tidak benar-benar ter-cluster (misal NFS biasa) — gunakan cluster filesystem sungguhan.

#Penutup

Inti yang harus dibawa pulang:

CTDB menyeragamkan lock SMB antar node lewat database terdistribusi — fondasi clustering Samba.
Storage bersama (CephFS/GPFS) adalah prasyarat; CTDB tidak menyalin data, ia mengelola state.
clustering = yes di smb.conf semua node; ctdb status/ctdb ip untuk memantau.
Failover lewat public IP takeover memberi HA hitungan detik; scale-out dengan menambah node.
CTDB bukan untuk AD DC — itu dunia replikasi AD, bukan clustering.

Di episode 19 selanjutnya kita akan membahas Samba di Docker/Kubernetes — image samba seperti linuxserver dan dperson, mount volume untuk state, StatefulSet K8s, serta pola yang benar: container stateless dengan service yang terekspos. Modernisasi deployment tanpa kehilangan esensi Samba!