Belajar Elasticsearch - Cluster Configuration & Node Management

#Pendahuluan

Sampai episode 13 kita bekerja di satu node. Tapi kekuatan Elasticsearch baru terasa saat beberapa node bersatu membentuk cluster — dan di situlah konfigurasi menjadi penting. Kesalahan konfigurasi cluster adalah sumber paling umum insiden produksi: split-brain, node yang tidak bisa bergabung, atau OOM karena heap yang salah.

Episode 14 membahas pengaturan cluster dan node: static vs dynamic settings, persistent vs transient, discovery dan cluster formation, konfigurasi node roles, JVM heap sizing, thread pools, dan circuit breakers. Ini fondasi yang membuat semua episode scaling berikutnya masuk akal.

#Static vs Dynamic Settings

Ada dua jenis setting di Elasticsearch:

• Static — dibaca dari elasticsearch.yml saat node start; tidak bisa diubah saat runtime tanpa restart. Contoh: node.name, node.roles, path.data, cluster.name.
• Dynamic — bisa diubah kapan saja lewat Cluster Update Settings API. Contoh: cluster.routing.allocation.enable, index.number_of_replicas.

cluster.name: my-cluster
node.name: data-1
node.roles: [master, data]
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
network.host: 0.0.0.0
discovery.seed_hosts: ["node1:9300", "node2:9300", "node3:9300"]

Aturan praktis: sebisa mungkin gunakan setting default; ubah hanya yang benar-benar dibutuhkan, dan tulis perubahan static ke file konfigurasi supaya terekam (infrastructure as code, episode 28).

#Persistent vs Transient

Dynamic settings punya dua lapisan:

• Persistent — tersimpan di cluster state, bertahan setelah restart. Ini cara yang benar untuk mengubah dynamic settings di production.
• Transient — berlaku sampai cluster restart atau dihapus. Hanya untuk eksperimen cepat.

PUT /_cluster/settings

{
  "persistent": {
    "cluster.routing.allocation.enable": "all"
  },
  "transient": {
    "cluster.routing.allocation.disk.threshold_enabled": false
  }
}

#Discovery dan Cluster Formation

Saat node start, ia harus menemukan node lain dan membentuk cluster. Mekanisme discovery menggunakan beberapa seed host sebagai daftar awal:

discovery.seed_hosts: ["node1:9300", "node2:9300", "node3:9300"]
cluster.initial_master_nodes: ["master-1", "master-2", "master-3"]

cluster.initial_master_nodes hanya dipakai saat cluster pertama kali dibentuk (bootstrap) untuk memilih master awal. Setelah itu, master dipilih lewat votings. Jumlah master-eligible node harus ganjil untuk menghindari tie voting — kita akan kembali ke topik quorum ini di episode 29.

#Node Roles

Peran node dikonfigurasi di node.roles (static):

Di cluster kecil, satu node menjalankan semua peran. Di production berskala besar, pisahkan: node khusus master (ringan), node khusus data (berat), node coordinating khusus untuk mengatur lalu lintas search tanpa menyimpan data. Peran menentukan beban dan profil hardware — episode 18 membahas ini lebih dalam.

#JVM Heap Sizing

Aturan emas pengaturan heap:

• Setengah dari RAM, maksimal 32 GB. Heap di atas 32 GB membuat JVM berhenti memakai compressed oops — pemborosan memori yang justru menurunkan performa.
• Sisa memori dipakai Lucene untuk cache file (page cache OS) — jangan beri heap terlalu banyak sehingga cache OS kelaparan.
• -Xms harus sama dengan -Xmx — menghindari resizing heap saat runtime.

-Xms8g
-Xmx8g
-XX:+UseG1GC
-XX:MaxGCPauseMillis=500

Monitor penggunaan heap: nilai aman di bawah 75–85%. Jika terus mendekati 100%, bukan berarti harus menaikkan heap — bisa jadi query aggregation yang berat atau field data yang membengkak. Episode 19 dan 21 akan membahas diagnosis performa.

#Thread Pools

Setiap node punya thread pools untuk jenis pekerjaan berbeda:

Thread pool punya ukuran yang dihitung otomatis dari jumlah CPU. Kalian tidak perlu mengubahnya di hampir semua kasus — yang perlu dipahami adalah cara membaca tanda overload: RejectedExecutionException di log menandakan thread pool penuh. Saat itu, jawabannya bukan menaikkan thread pool, melainkan menambah node atau memperbaiki query.

#Circuit Breakers

Circuit breaker adalah pengaman terakhir: ia memantau estimasi memori JVM yang dipakai operasi tertentu, dan menolak request jika mendekati batas — mencegah out-of-memory yang menjatuhkan node. Tiga breaker utama:

GET /_nodes/stats/breaker

Jika sering melihat error Data too large, data for [<breaker>]... di respons search, itu sinyal agregasi atau sorting yang terlalu boros memori — bukan alasan untuk menaikkan breaker. Breaker yang terlalu longgar hanya menunda kematian node.

#Kesalahan Umum

1. Heap -Xms berbeda dengan -Xmx. JVM melakukan resize yang tidak perlu — samakan keduanya.

2. Master-eligible node genap. Voting bisa buntu (tie) — jaga jumlahnya ganjil.

3. Mengubah dynamic settings lewat transient di production. Gunakan persistent dan rekam perubahannya.

4. Menaikkan thread pool saat overload. Itu menutup gejala, bukan penyebab — cari akar masalahnya (query berat, node kurang).

5. Menaikkan circuit breaker. Hampir selalu salah; benahi penggunaan memori, bukan batasnya.

#Penutup

Di episode 14 kalian menguasai konfigurasi cluster dan node: static vs dynamic settings, persistent vs transient, discovery dengan seed hosts dan bootstrap, node roles, JVM heap sizing dengan aturan setengah-RAM-maksimal-32GB, thread pools, dan circuit breakers.

Inti yang harus dibawa pulang:

• Static settings butuh restart; dynamic bisa diubah runtime (prefer persistent).
• Discovery memakai discovery.seed_hosts; bootstrap sekali dengan initial_master_nodes.
• Heap = setengah RAM, maks 32 GB, -Xms = -Xmx.
• RejectedExecutionException berarti overload, bukan alasan menaikkan thread pool.
• Circuit breaker menolak request demi mencegah OOM — hormati sinyalnya.

Cluster yang dikonfigurasi benar masih bisa ditembus — yang membedakan cluster production dari cluster belajar adalah keamanan. Di episode 15 kita bahas security fundamentals: mengaktifkan xpack.security, built-in users dan realm, user dan role management, metode autentikasi (native, LDAP/AD, SAML, API keys, service tokens), serta authorization dengan RBAC, DLS/FLS, dan role mapping. Sampai jumpa!