All Products
Search

This Product

    Elasticsearch:Upgrade konfigurasi kluster

    Document Center

    Elasticsearch:Upgrade konfigurasi kluster

    Last Updated:Apr 25, 2026

    Jika kluster Elasticsearch (ES) Anda mengalami pemanfaatan resource yang tinggi secara konsisten atau performanya tidak lagi memenuhi kebutuhan bisnis, lakukan upgrade konfigurasi untuk memulihkan stabilitas layanan. Upgrade dapat dilakukan dengan menambah jumlah node, meningkatkan spesifikasi node, memperluas kapasitas disk, atau menambahkan tipe node baru.

    Sebelum memulai

    Penting

    Upgrade konfigurasi kluster dapat menyebabkan latensi layanan, konflik konfigurasi, dan perubahan penagihan. Baca informasi berikut dengan cermat sebelum melanjutkan.

    • Stabilitas layanan

      • Aturan stabilitas layanan selama perubahan konfigurasi kluster:

        Kondisi kluster

        Dampak terhadap layanan

        Aksi yang direkomendasikan

        Beban normal dengan replika

        Beban normal: CPU ≤ 60%, heap memory ≤ 50%, beban < jumlah core.

        Layanan tetap tersedia, dengan potensi penurunan performa ringan.

        Tidak diperlukan aksi tambahan.

        Beban tinggi tanpa replika

        Beban tinggi: Penulisan atau kueri konkuren tinggi selama upgrade, dengan CPU > 60% atau heap memory > 50%.

        Kadang-kadang terjadi timeout akses.

        • Aktifkan mekanisme retry pada client.

        • Tingkatkan jumlah replika indeks sebelum upgrade.

        Beban tinggi dengan status tidak sehat

        Kadang-kadang terjadi timeout akses atau jitter layanan.

        Pulihkan kluster ke kondisi sehat sebelum melakukan perubahan.

      • Jendela pemeliharaan: Lakukan operasi ini selama jam sepi.

    • Perencanaan kapasitas

      Evaluasi kapasitas kluster yang dibutuhkan secara tepat.

    • Batasan konfigurasi

      • Anda tidak dapat melakukan upgrade versi Elasticsearch saat melakukan upgrade konfigurasi kluster.

      • Anda hanya dapat mengubah satu tipe node dalam satu operasi upgrade.

    • Dampak biaya

      Setelah Anda mengirimkan pesanan upgrade, sistem akan menagih Anda berdasarkan konfigurasi yang diperbarui. Untuk informasi lebih lanjut tentang aturan penagihan, lihat pay-as-you-go dan subscription.

    Pemeriksaan sebelum upgrade

    Penting

    Upgrade tanpa menyelesaikan pemeriksaan berikut dapat menyebabkan crash kluster, kehilangan data, atau ketidaktersediaan layanan. Verifikasi setiap item dengan cermat.

    • Kesehatan kluster

      Jalankan GET _cluster/health untuk memastikan status kluster adalah GREEN. Jika kluster tidak sehat, lihat Cluster Change Error - Unhealthy Cluster State untuk menyelesaikan masalah tersebut.

    • Keamanan beban

      Jalankan GET _cat/nodes?v. Kami merekomendasikan pemanfaatan CPU ≤ 60%. Jika lebih tinggi, aktifkan mekanisme retry pada client dan tingkatkan jumlah replika indeks.

    • Kesiapan indeks

      • Jalankan GET /_cat/indices?v untuk memeriksa apakah ada indeks dalam status CLOSE. Jika ada, jalankan POST /<index_name>/_open untuk membukanya sementara. Jika tidak, perubahan konfigurasi mungkin gagal karena alasan berikut:

        • Kluster dengan indeks tertutup tidak dapat mencapai status GREEN. Elasticsearch memerlukan status GREEN untuk operasi sensitif seperti memodifikasi aturan alokasi shard.

        • Selama perubahan konfigurasi, kluster melakukan realokasi shard:

          • Shard dari indeks tertutup tidak dapat berpartisipasi dalam realokasi.

          • Hal ini menyebabkan operasi yang bergantung pada status GREEN gagal.

          • Ini mencegah status kluster mencapai GREEN (maksimal hanya mencapai YELLOW).

      • Jalankan GET _cat/indices?v untuk memastikan jumlah replika setiap indeks minimal 1.

        Untuk instans yang dideploy di beberapa availability zone, pastikan jumlah replika setiap indeks kurang dari jumlah availability zone selama perubahan. Kami merekomendasikan mengatur jumlah replika menjadi 1. Setelah perubahan selesai, Anda dapat menambah jumlah replika secara manual.

    • Keseimbangan shard

      Jalankan GET _cat/shards?v untuk memeriksa apakah ada shard yang tidak seimbang.

      Penting

      Memverifikasi keseimbangan shard sebelum upgrade membantu mencegah degradasi performa atau crash kluster.

      • prirep: Periksa apakah ada shard replika (r) yang berstatus UNASSIGNED.

      • state: Periksa apakah migrasi shard terjebak dalam status RELOCATING dalam waktu lama.

      Masalah ini dapat mencegah node baru menerima shard dengan benar, sehingga status kluster tetap YELLOW atau RED setelah upgrade. Jika masalah ini ada, lihat Solutions for uneven cluster load untuk menyelesaikannya.

    Metode 1: Upgrade melalui Konsol

    1. Pada halaman Instances, klik Upgrade Configuration.

      Titik masuk alternatif: Pada halaman Basic Information instans Anda, klik Configuration Update > Upgrade.

    2. Pada halaman Upgrade/Downgrade, sesuaikan parameter konfigurasi berdasarkan kebutuhan bisnis Anda.

      Penting

      Parameter konfigurasi yang tersedia dapat bervariasi tergantung pada tipe dan versi kluster. Parameter yang ditampilkan pada halaman upgrade memiliki prioritas utama.

      • Aturan berikut berlaku untuk mengubah jumlah availability zone. Jika stok tidak mencukupi untuk spesifikasi tertentu di suatu availability zone, Anda harus melakukan migrasi node di availability zone tersebut sebelum upgrade.

        Ekspansi: Anda dapat menambah jumlah availability zone dari satu menjadi dua atau tiga.

      • Anda dapat meningkatkan spesifikasi node. Tipe penyimpanan berikut diurutkan dari performa terendah ke tertinggi:

        1. Disk cloud generasi sebelumnya: standard cloud disk -> ultra cloud disk -> SSD cloud disk.

          Catatan

          Tipe disk ini sedang dihentikan di beberapa wilayah dan availability zone. Kami merekomendasikan memilih ESSD.

        2. ESSD: ESSD (Enterprise SSD) menggabungkan jaringan 25 GbE dan teknologi RDMA untuk memberikan hingga 1 juta IOPS baca/tulis acak per disk dan latensi jalur tunggal yang rendah.

        3. Local disk.

          Catatan

          Local disk adalah storage device pada mesin fisik tempat Instance ECS berada. Local disk menyediakan akses penyimpanan lokal untuk Instance ECS dan cocok untuk skenario yang memerlukan performa I/O penyimpanan tinggi serta penyimpanan massal yang hemat biaya.

      • Intelligent Update (diaktifkan secara default): Sistem secara otomatis memilih metode update optimal berdasarkan perubahan konfigurasi. Anda juga dapat menonaktifkan fitur ini dan menentukan metode update secara manual:

        Metode Pembaruan

        Mekanisme

        Durasi

        Dampak terhadap layanan dan kasus penggunaan

        Blue-green Update

        Tambahkan node baru → Salin data → Alih bencana mulus

        Panjang

        • Alamat IP node berubah. Fluktuasi performa kluster sementara mungkin terjadi.

        • Cocok untuk skenario di mana durasi update tidak kritis, tetapi ketersediaan kluster tinggi sangat diperlukan.

        In-place Update

        Restart bergulir pada node (tidak perlu menyalin data).

        Singkat

        • Alamat IP node tidak berubah. Fluktuasi performa kluster sementara mungkin terjadi.

        • Cocok untuk skenario di mana kluster mengalami bottleneck performa dan update cepat diinginkan.

          Penting

          Berhati-hatilah memilih in-place update jika pemanfaatan resource tinggi (misalnya, CPU > 60%).

      • Forced Update: Melewati pemeriksaan kesehatan tetapi memicu restart kluster paksa. Hal ini dapat menyebabkan gangguan layanan berkepanjangan (waktu pemulihan tergantung pada volume data) dan hanya boleh digunakan untuk scaling darurat ketika kluster sudah tidak tersedia.

    3. Baca Terms of Service dan Service Level Agreement. Jika Anda setuju, klik Buy Now. Sistem akan menagih Anda berdasarkan metode penagihan yang dipilih.

      Selama perubahan, status kluster berubah menjadi Initializing. Performa kluster mungkin berfluktuasi sementara, dan kegagalan permintaan transien mungkin terjadi. Setelah perubahan selesai, status kluster diperbarui menjadi Normal.

    Metode 2: Upgrade melalui API

    Untuk informasi lebih lanjut, lihat dokumentasi API untuk UpdateInstance.

    Monitor dan verifikasi

    • Untuk melihat progres setelah upgrade dimulai, buka halaman Basic Information instans Anda di Konsol Elasticsearch Clusters:

      Klik Show Details:

    • Setelah upgrade selesai, verifikasi bahwa konfigurasi telah diterapkan pada halaman Basic Information kluster:

      • Status kluster kembali ke Active.

      • Availability zone

      • Jumlah node dan spesifikasi penyimpanan: Pastikan node baru telah bergabung ke kluster dan spesifikasi penyimpanan sudah sesuai.

      • Keseimbangan shard: Jalankan GET _cat/allocation?v untuk memeriksa distribusi shard. Jika shard tidak seimbang, lihat Solutions for uneven cluster load untuk menyelesaikan masalah tersebut.

    FAQ

    Upgrade dan metrik performa

    Q: Apakah upgrade selalu memperbaiki performa?

    A: Tidak selalu. Upgrade resource seperti CPU, memori, atau disk bukan solusi ajaib. Sebelum memutuskan untuk upgrade, analisis bottleneck spesifiknya:

    • Bottleneck CPU: Pemanfaatan CPU berkelanjutan di atas 80% dalam periode panjang (bukan lonjakan singkat).

    • Bottleneck memori: Waktu garbage collection (GC) panjang yang sering terjadi, swapping memori, atau error OutOfMemory (OOM).

    • Bottleneck disk: Fokus pada throughput I/O aktual, bukan hanya metrik %util (lihat detail di bawah).

    • Bottleneck jaringan: Bandwidth jaringan terus-menerus jenuh, dan latensi terasa tinggi.

    Konfirmasi bottleneck aktual sebelum upgrade untuk menghindari pemborosan resource yang tidak perlu. Terkadang, mengoptimalkan indeks, kueri, atau konfigurasi bisa lebih efektif daripada sekadar upgrade resource.

    Q: Mengapa sistem saya normal meskipun %util 100%?

    A: Metrik %util dalam iostat menunjukkan persentase waktu perangkat sibuk dengan I/O (tidak idle). Metrik ini tidak mengukur volume permintaan I/O, melainkan hanya keberadaannya. Karena perangkat disk modern dapat memproses beberapa permintaan I/O secara paralel, %util 100% tidak selalu berarti perangkat jenuh.

    • Contohnya, sebuah disk membutuhkan 0,1 detik untuk memproses satu permintaan I/O dan dapat menangani 10 permintaan sekaligus.

      • Jika 10 permintaan I/O dikirim secara berurutan, dibutuhkan 1 detik untuk menyelesaikannya, dan %util-nya 100%.

      • Jika 10 permintaan I/O dikirim sekaligus, mereka diproses secara paralel dan selesai dalam 0,1 detik. Diukur dalam interval satu detik, hasilnya adalah %util 10%.

    Penting: Metrik %util sebagian besar sudah tidak relevan dalam sistem penyimpanan modern dan tidak boleh menjadi satu-satunya faktor dalam memutuskan upgrade.

    Q: Metrik apa yang menunjukkan bottleneck disk?

    A: Fokus pada metrik berikut, bukan hanya mengandalkan %util:

    1. Throughput I/O: Laju baca/tulis data aktual (MB/s), dibandingkan dengan kebutuhan bisnis Anda.

    2. Waktu respons: Latensi permintaan I/O, yang secara langsung memengaruhi performa kueri.

    3. IOPS: Jumlah operasi I/O per detik, disesuaikan dengan model bisnis Anda.

    4. Kedalaman antrian: Jumlah permintaan I/O yang tertunda.

    Rekomendasi: Metrik %util 100% yang tidak berlangsung terus-menerus selama berjam-jam biasanya tidak perlu dikhawatirkan. Bottleneck performa sebenarnya harus diidentifikasi menggunakan alat profesional seperti fio untuk menentukan bandwidth maksimum dan IOPS aktual.

    Q: Bagaimana cara menilai bottleneck performa disk?

    A: Ikuti langkah-langkah berikut untuk mengevaluasi performa disk Anda:

    1. Analisis model bisnis Anda: Pahami rasio baca/tulis, ukuran I/O, dan karakteristik lainnya.

    2. Fokus pada throughput aktual, bandingkan dengan kebutuhan bisnis Anda, bukan metrik %util.

    3. Gunakan alat profesional untuk pengujian: Gunakan alat seperti fio untuk mensimulasikan workload bisnis aktual Anda dan menguji performa disk dalam skenario dunia nyata.

    4. Evaluasi latensi kueri: Periksa apakah waktu respons kueri ES memenuhi kebutuhan bisnis Anda.

    5. Monitor metrik utama: Lacak metrik internal ES seperti latensi pengindeksan dan latensi pencarian.

    Untuk menentukan apakah upgrade diperlukan, analisis rangkaian lengkap metrik performa, termasuk namun tidak terbatas pada pemanfaatan CPU, penggunaan memori, throughput I/O, dan latensi kueri. Jangan membuat keputusan berdasarkan satu metrik saja.

    Pertanyaan lainnya