Tools & Checklist

Checklist Kesiapan Produksi

Sebelum cluster Elasticsearch atau OpenSearch Anda melayani trafik nyata, lewati daftar periksa ini. Tiap item bersifat actionable dan dikelompokkan per kategori: keamanan, ketersediaan, kapasitas, backup, monitoring, konfigurasi sistem, dan jaringan.

Ringkasan: Siap atau Belum?

Pakai tabel ini sebagai sapuan cepat. Jika ada satu pun kolom "Belum" pada baris kritis, tunda go-live.

Area	Pemeriksaan minimum	Tingkat
Keamanan	TLS aktif, autentikasi nyala, port 9200 tidak terbuka publik	Kritis
Ketersediaan	Minimal 3 master-eligible node, replica ≥ 1	Kritis
Backup	Snapshot terjadwal + restore teruji	Kritis
Konfigurasi sistem	vm.max_map_count, ulimit, swap off, heap ≤ 31 GB	Kritis
Kapasitas & shard	Ukuran shard 10-50 GB, ILM untuk time-series	Tinggi
Monitoring	Metrik cluster, alert disk & heap aktif	Tinggi
Jaringan	Firewall ketat, node saling terjangkau di port 9300	Tinggi

1. Keamanan

Autentikasi & otorisasi

Aktifkan security bawaan (xpack.security.enabled: true) atau OpenSearch Security.
Ganti semua kredensial default (mis. user elastic) dengan password kuat.
Terapkan role-based access control dengan prinsip hak minimum.

Enkripsi (TLS)

TLS aktif untuk transport (port 9300) antar node.
TLS/HTTPS aktif untuk lapisan REST (port 9200).
Panel admin diakses lewat reverse proxy HTTPS, bukan koneksi polos.

Pengerasan akses

Port 9200 tidak pernah terbuka langsung ke internet.
Tambahkan Basic Auth dan IP whitelist di reverse proxy.
Audit log aktif untuk melacak aksi administratif.

2. Ketersediaan & HA

Minimal 3 master-eligible node agar quorum aman dan terhindar dari split-brain.
Setel discovery.seed_hosts dan cluster.initial_master_nodes dengan benar.
Setiap indeks penting memiliki minimal 1 replica agar tahan kehilangan satu node.
Sebar shard antar availability zone dengan shard allocation awareness.
Hindari menempatkan semua master pada satu host fisik atau satu rak.
Uji skenario kegagalan: matikan satu node dan pastikan cluster kembali hijau.

3. Kapasitas & Shard

Ukuran tiap shard berada di rentang sehat 10-50 GB.
Jumlah shard per node di bawah ~20 shard untuk tiap 1 GB heap JVM.
Tidak ada indeks "raksasa" dengan satu primary shard berukuran ratusan GB.
ILM + rollover aktif untuk indeks time-series (log, metrik).
Disk terisi di bawah low watermark (default 85%) dengan ruang tumbuh.
Rencana kapasitas mempertimbangkan pertumbuhan data 6-12 bulan ke depan.

Belum yakin berapa shard? Gunakan Kalkulator & Panduan Ukuran Shard untuk menghitung jumlah primary dan replica yang ideal.

4. Backup & Pemulihan

Repository snapshot terdaftar (S3, GCS, Azure, atau filesystem bersama).
SLM (Snapshot Lifecycle Management) menjadwalkan snapshot otomatis.
Retensi snapshot ditetapkan (mis. simpan 30 harian + 12 bulanan).
Restore sudah diuji ke cluster terpisah, bukan sekadar dibuat.
RPO (toleransi kehilangan data) dan RTO (target waktu pulih) terdokumentasi.

Snapshot yang belum pernah berhasil dipulihkan bukan backup yang sah. Jadwalkan latihan restore minimal sekali per kuartal.

5. Monitoring & Alerting

Status cluster dipantau (hijau/kuning/merah) dengan alert saat berubah.
Alert disk mendekati watermark sebelum mencapai flood stage.
Pemantauan heap JVM dan tekanan GC per node.
Latensi kueri, antrean thread pool, dan penolakan (rejections) terpantau.
Log node terkumpul terpusat untuk diagnosis pasca-insiden.
Dasbor menampilkan throughput indexing dan search secara real-time.

6. Konfigurasi Sistem (OS & JVM)

Pengaturan tingkat sistem operasi sering terlewat, padahal menjadi penyebab umum node gagal start atau performa anjlok.

Item	Nilai disarankan	Cara setel
`vm.max_map_count`	≥ 262144	`sysctl -w vm.max_map_count=262144` + persist di `/etc/sysctl.conf`
File descriptor (ulimit -n)	≥ 65535	Atur `nofile` di `/etc/security/limits.conf` atau unit systemd
Maks. proses/thread	≥ 4096	Atur `nproc` untuk user elasticsearch
Swap	Dimatikan / terkunci	`swapoff -a` atau `bootstrap.memory_lock: true`
Heap JVM	~50% RAM, maks 31 GB	`-Xms` = `-Xms` sama besar di `jvm.options`

# cek nilai aktif
sysctl vm.max_map_count
ulimit -n
cat /proc/sys/vm/swappiness

# verifikasi dari Elasticsearch sendiri
GET /_nodes/stats/jvm
GET /_nodes?filter_path=**.mlockall

Setel -Xms dan -Xmx ke nilai sama agar JVM tidak menyesuaikan ukuran heap saat berjalan. Jangan lewati 31 GB agar compressed oops tetap aktif.

7. Jaringan

Firewall hanya membuka port yang perlu: 9200 (REST, dibatasi) dan 9300 (transport antar node).
Node saling terjangkau di port 9300 dengan latensi rendah dan stabil.
network.host diikat ke alamat internal, bukan 0.0.0.0 tanpa proteksi.
Komunikasi klien melewati load balancer atau coordinating node, bukan langsung ke data node.
DNS/hostname antar node stabil agar discovery tidak putus saat IP berubah.

FAQ Kesiapan Produksi

Apa hal paling kritis sebelum Elasticsearch masuk produksi?

Tiga hal utama: keamanan (TLS dan autentikasi aktif, jangan pernah ekspos port 9200 tanpa proteksi), ketersediaan (minimal 3 master-eligible node agar quorum aman), dan backup snapshot yang teruji bisa dipulihkan. Tanpa ketiganya, cluster Anda berisiko bocor, split-brain, atau kehilangan data permanen.

Mengapa vm.max_map_count harus dinaikkan?

Elasticsearch menggunakan mmap untuk mengakses indeks, dan nilai default kernel Linux (65530) terlalu rendah. Setel vm.max_map_count minimal 262144 di /etc/sysctl.conf, jika tidak node bisa gagal start atau crash saat indeks membesar.

Apakah swap harus dimatikan?

Ya, sangat disarankan. Swapping membuat latensi JVM tidak terduga dan dapat memicu garbage collection yang lama. Matikan swap (swapoff -a dan hapus entri di /etc/fstab) atau setel bootstrap.memory_lock: true agar heap terkunci di RAM.

Berapa ukuran heap JVM yang disarankan?

Setel heap sekitar 50% dari RAM fisik dan jangan melebihi sekitar 30-31 GB agar JVM tetap memakai compressed ordinary object pointers (compressed oops). Misal server 64 GB RAM cukup pakai heap 30 GB, sisanya untuk filesystem cache yang penting bagi performa Lucene.

Bagaimana memastikan backup benar-benar berfungsi?

Jangan hanya membuat snapshot, tetapi uji restore secara berkala ke cluster terpisah. Snapshot ke repository S3-compatible, jadwalkan via SLM (Snapshot Lifecycle Management), dan dokumentasikan RPO/RTO. Backup yang belum pernah dipulihkan belum bisa disebut backup.

Perkuat Keamanan Cluster

Lengkapi checklist ini dengan praktik keamanan production menyeluruh untuk panel dan cluster Anda.

Best Practices Keamanan

Checklist Kesiapan Produksi

Ringkasan: Siap atau Belum?

1. Keamanan

Autentikasi & otorisasi

Enkripsi (TLS)

Pengerasan akses

2. Ketersediaan & HA

3. Kapasitas & Shard

4. Backup & Pemulihan

5. Monitoring & Alerting

6. Konfigurasi Sistem (OS & JVM)

7. Jaringan

FAQ Kesiapan Produksi

Apa hal paling kritis sebelum Elasticsearch masuk produksi?

Mengapa vm.max_map_count harus dinaikkan?

Apakah swap harus dimatikan?

Berapa ukuran heap JVM yang disarankan?

Bagaimana memastikan backup benar-benar berfungsi?

Perkuat Keamanan Cluster

Halaman Terkait

Kalkulator Shard

Best Practices Keamanan

Snapshot ke S3 / R2

Tuning JVM Heap