All Products
Search
Document Center

Elasticsearch:Konfigurasi node untuk kluster Alibaba Cloud Elasticsearch

Last Updated:Aug 06, 2026

Saat membuat kluster Alibaba Cloud Elasticsearch, Anda harus mengonfigurasi spesifikasi dan penyimpanan untuk berbagai tipe node sesuai kebutuhan bisnis Anda. Kluster Elasticsearch terdiri dari node data, node Kibana, node master khusus, node hangat, node beku, dan node pengoordinasi, masing-masing dengan tanggung jawab yang berbeda.

Data node

Node data menyimpan data indeks serta menjalankan operasi pengindeksan, pencarian, dan agregasi. Node data memiliki kebutuhan CPU, memori, dan I/O yang tinggi. Jika sumber daya tidak mencukupi, kami menyarankan Anda menambahkan node data baru ke kluster.

Catatan
  • Jika sebuah kluster memiliki node master khusus, node data hanya berfungsi sebagai node data.

  • Jika sebuah kluster tidak memiliki node master khusus, node data berfungsi sebagai node data sekaligus node master.

  • Kluster Alibaba Cloud Elasticsearch menggunakan salah satu dari dua arsitektur lapisan kontrol: lapisan kontrol dasar (v2) atau lapisan kontrol cloud-native (v3). Pada arsitektur v2, memperbesar kapasitas kluster yang tidak memiliki node master khusus akan memicu restart kluster. Jika beban keseluruhan kluster rendah dan indeks Anda memiliki shard replika, kluster dapat tetap tersedia selama restart. Namun, dalam skenario tertentu—seperti beban tulis dan kueri yang tinggi—timeout akses dapat terjadi selama restart. Oleh karena itu, kami menyarankan melakukan operasi ini pada jam sepi.

Parameter

Deskripsi

Spesifikasi data node

Kami menyarankan Anda menggunakan node data dengan 2 vCPU dan memori 4 GiB di lingkungan pengujian, serta menggunakan node data dengan spesifikasi lebih tinggi di lingkungan produksi.

Tipe disk data node

  • ESSD (Default): Menyediakan latensi rendah, throughput tinggi, dan waktu respons cepat. Ideal untuk aplikasi yang sensitif terhadap latensi atau workload intensif I/O. Untuk informasi lebih lanjut tentang spesifikasi ESSD, lihat Spesifikasi node. Untuk informasi lebih lanjut tentang performa, lihat ESSD.

  • Ultra Disk: Menyediakan penyimpanan hemat biaya. Cocok untuk skenario logging dan analitik yang melibatkan volume data besar.

  • Standard SSD: Menawarkan IOPS tinggi dan responsivitas baik. Cocok untuk skenario analitik online dan pencarian.

Catatan
  • Anda dapat melihat tipe disk yang didukung di halaman pembelian.

  • Setelah kluster dibuat, Anda tidak dapat mengubah tipe disk node dalam kluster tersebut.

Tingkat performa ESSD

Jika Anda mengatur parameter Tipe Disk Data Node ke ESSD, Anda perlu mengonfigurasi parameter ini.

Enkripsi disk data node

  • Enkripsi disk memberikan keamanan data maksimal tanpa memerlukan perubahan tambahan pada bisnis dan aplikasi Anda. Namun, enkripsi disk mungkin sedikit memengaruhi performa kluster Anda.

  • Enkripsi disk tidak dikenai biaya tambahan. Tidak ada biaya tambahan saat Anda membaca atau menulis data ke disk terenkripsi.

Ruang penyimpanan per data node

Ruang penyimpanan setiap data node bergantung pada tipe disk. Satuan: GiB.

  • ESSD: Mendukung hingga 6 TiB ruang penyimpanan.

  • Ultra Disk: Mendukung hingga 20 TiB ruang penyimpanan untuk kluster Elasticsearch versi V6.7, V7.7, dan yang lebih baru. Untuk versi lain, ruang penyimpanan maksimum adalah 5 TiB.

  • Standard SSD: Mendukung hingga 6 TiB ruang penyimpanan untuk kluster Elasticsearch versi V6.7, V7.7, dan yang lebih baru. Untuk versi lain, ruang penyimpanan maksimum adalah 2 TiB.

Catatan

Saat Anda mengubah ukuran ultra disk dengan ruang penyimpanan lebih dari 2.560 GiB, hanya pembaruan blue-green yang dapat dilakukan untuk ultra disk tersebut karena disk dirancang untuk berjalan dalam array disk atau RAID 0.

Jumlah data node

Jumlah node yang Anda beli harus merupakan kelipatan jumlah zona.

Penting

Kluster yang hanya berisi dua data node memiliki risiko split-brain yang tinggi dan stabilitas rendah. Jika kluster versi lama seperti V6.X atau V5.X hanya berisi dua data node, node master khusus mungkin tidak dipilih jika diperlukan restart node, sehingga kluster mungkin tidak dapat menyediakan layanan. Oleh karena itu, Anda harus mengonfigurasi parameter ini berdasarkan kebutuhan bisnis Anda.

Kibana node

  • Nilai parameter Kibana Node hanya bisa Yes.

  • Node Kibana dengan 1 vCPU dan memori 2 GiB tidak dikenai biaya. Namun, kami menyarankan Anda hanya menggunakan node Kibana dengan spesifikasi tersebut untuk tujuan pengujian.

  • Mengingat dampaknya terhadap performa dan stabilitas kluster, kami menyarankan Anda membeli node Kibana dengan 2 vCPU dan memori 4 GiB atau spesifikasi lebih tinggi.

Dedicated master node

Anda dapat menggunakan node master khusus untuk menjalankan operasi pada kluster, seperti membuat atau menghapus indeks, melacak node, dan mengalokasikan shard. Stabilitas node master khusus sangat penting bagi kesehatan kluster. Secara default, setiap node dalam kluster dapat berfungsi sebagai node master. Namun, operasi seperti pengindeksan data, pencarian, dan kueri memerlukan banyak sumber daya CPU, memori, dan I/O. Untuk memastikan stabilitas kluster, kami menyarankan Anda membeli node master khusus yang terpisah dari node data.

Penting
  • Jika node master khusus dalam kluster Anda awalnya gratis, Anda akan dikenai biaya untuk node tersebut setelah meningkatkan konfigurasi kluster.

  • Jika Anda melakukan perubahan blue-green pada kluster yang tidak memiliki node master khusus dan diterapkan di arsitektur lama (V2), node data akan direstart saat Anda melakukan perubahan berikutnya pada kluster. Oleh karena itu, kami menyarankan Anda membeli node master khusus.

Parameter

Deskripsi

Dedicated master node

  • Untuk meningkatkan stabilitas layanan Anda, kami menyarankan Anda membeli node master khusus.

  • Untuk kluster Elasticsearch multi-zona, nilai default parameter ini adalah Yes, dan Anda tidak dapat mengubah nilainya.

Catatan
  • Anda tidak dapat melepas node master khusus yang telah Anda beli.

  • Untuk kluster yang tidak memiliki node master khusus, Anda tidak dapat memodifikasi pengaturan node master khusus. Parameter terkait tidak dapat dikonfigurasi di halaman pembelian.

  • Setelah kluster dibuat, Anda dapat membeli node master khusus saat meningkatkan konfigurasi kluster.

Spesifikasi dedicated master node

Anda dapat melihat spesifikasi yang didukung di halaman pembelian.

Tipe disk dedicated master node

  • ESSD (Default): Menyediakan latensi rendah, throughput tinggi, dan waktu respons cepat. Ideal untuk aplikasi yang sensitif terhadap latensi atau workload intensif I/O. Untuk informasi lebih lanjut tentang spesifikasi ESSD, lihat Spesifikasi node. Untuk informasi lebih lanjut tentang performa, lihat ESSD.

  • Ultra Disk: Menyediakan penyimpanan hemat biaya. Cocok untuk skenario logging dan analitik yang melibatkan volume data besar.

  • Standard SSD: Menawarkan IOPS tinggi dan responsivitas baik. Cocok untuk skenario analitik online dan pencarian.

Anda dapat melihat tipe disk yang didukung di halaman pembelian.

Ruang penyimpanan dedicated master node

Nilai parameter ini hanya bisa 20G.

Jumlah dedicated master node

Nilai parameter ini hanya bisa 3.

Warm node

Jika workload Anda melibatkan kedua jenis data berikut, kami menyarankan menggunakan arsitektur hot-warm, yang menggabungkan node panas berkinerja tinggi dengan node hangat berkapasitas besar:

  • Data panas: Indeks yang sering dikueri, memiliki beban tulis tinggi, dan sensitif terhadap latensi.

  • Data hangat: Indeks yang jarang dikueri dan sebagian besar read-only atau memiliki aktivitas tulis minimal. Biasanya merupakan data historis.

Dengan menempatkan data panas dan hangat pada tipe node yang berbeda, Anda dapat mencegah konflik sumber daya akibat data hangat memengaruhi performa data panas, secara signifikan mengurangi biaya penyimpanan, serta meningkatkan efisiensi dan stabilitas kluster secara keseluruhan.

Untuk informasi lebih lanjut, lihat Arsitektur "Hot-Warm" di Elasticsearch 5.x.

Catatan

Jika node master khusus dibeli, node hangat hanya digunakan sebagai node hangat.

Jika node master khusus tidak dibeli, node hangat juga berfungsi sebagai node master.

Parameter

Deskripsi

Warm node

Anda dapat menonaktifkan node hangat yang telah dibeli. Jika kluster macet saat Anda menonaktifkan node hangat, lihat Apa yang harus dilakukan jika kluster macet setelah node hangat dinonaktifkan?

Spesifikasi warm node

Untuk informasi tentang spesifikasi yang didukung, lihat halaman pembelian.

Untuk skenario dengan kebutuhan I/O tinggi dan penyimpanan besar, Anda juga dapat menggunakan tipe instans disk lokal hemat biaya, seperti tipe instans 20 vCPU, memori 88 GiB (SATA: 8 × 7300 GiB). Batasan berikut berlaku untuk tipe instans disk lokal:

  • Hanya instans kernel-enhanced V7.17 yang diterapkan di arsitektur lapisan kontrol cloud-native (v3) di dua atau tiga zona ketersediaan yang mendukung tipe instans disk lokal.

  • Untuk instans yang menggunakan arsitektur v3, perubahan blue-green tingkat node, seperti scale-out node, tidak didukung untuk tipe instans disk lokal.

Catatan
  • Konfigurasikan minimal satu replika saat menggunakan tipe instans disk lokal untuk mencegah kehilangan data di disk lokal.

  • Anda tidak dapat mengubah tipe instans disk lokal menjadi tipe instans cloud disk.

  • Jika arsitektur aplikasi Anda tidak dapat menjamin keandalan data, kami menyarankan Anda membuat kluster menggunakan tipe instans cloud disk. Snapshot tingkat mesin tidak didukung untuk tipe instans cloud disk.

Tipe disk warm node

Ultra Disk dan ESSD didukung.

Enkripsi disk warm node

  • Enkripsi disk memberikan keamanan data maksimal tanpa memerlukan perubahan tambahan pada bisnis dan aplikasi Anda. Namun, enkripsi disk mungkin sedikit memengaruhi performa kluster Anda.

  • Enkripsi disk tidak dikenai biaya tambahan. Tidak ada biaya tambahan saat Anda membaca atau menulis data ke disk terenkripsi.

Catatan
  • Anda tidak dapat menonaktifkan enkripsi disk untuk disk yang telah dienkripsi.

  • Anda tidak dapat mengaktifkan enkripsi disk untuk disk yang telah dibeli. Saat Anda meningkatkan konfigurasi kluster, Anda tidak dapat mengaktifkan enkripsi disk untuk disk yang telah dibeli. Jika Anda membeli cloud disk saat meningkatkan konfigurasi kluster, Anda dapat mengaktifkan enkripsi disk.

Ruang penyimpanan warm node

Nilai minimum parameter ini adalah 500. Satuan: GiB.

Jumlah warm node

Jumlah node yang Anda beli harus merupakan kelipatan jumlah zona.

Setelah Anda membeli node hangat, sistem akan menambahkan parameter -Enode.attr.box_type ke parameter startup node, seperti ditunjukkan pada tabel berikut.

Tipe node

Parameter startup

Data node

-Enode.attr.box_type=hot

Warm node

-Enode.attr.box_type=warm

Frozen nodes

Node beku merupakan lapisan komputasi untuk fitur Searchable Snapshot. Node ini mempertahankan metadata indeks, mengelola cache bersama lokal, dan menarik blok data yang diperlukan dari Object Storage Service (OSS) sesuai permintaan untuk kueri. Dengan menyimpan data historis sebagai snapshot di Alibaba Cloud OSS, node beku dapat mengurangi biaya penyimpanan hingga 90% sekaligus mempertahankan kemampuan pencarian.

  • Node beku hanya didukung untuk instans V8.17.0 dan yang lebih baru. Setelah mengaktifkan node beku, Anda tidak dapat menonaktifkannya. Untuk menonaktifkannya, hubungi dukungan teknis.

  • Node beku tidak memerlukan disk lokal berkapasitas besar karena data disimpan di OSS. Kami menyarankan mengonfigurasi memori yang cukup untuk meningkatkan rasio hit cache.

  • Untuk contoh detail, lihat Searchable Snapshot.

Parameter

Deskripsi

Frozen node

Saat membeli instans baru V8.17.0, Anda dapat memilih kotak centang di bagian spesifikasi instans untuk mengaktifkan fitur ini.

Spesifikasi frozen node

Kami menyarankan tipe instans dengan 4 vCPU dan memori 16 GiB atau lebih tinggi. Memori node beku mempertahankan metadata indeks dan mengelola cache bersama. Memori yang cukup dapat meningkatkan rasio hit cache. Untuk informasi tentang spesifikasi yang didukung, lihat halaman pembelian.

Tipe disk frozen node

Ultra Disk dan ESSD didukung. Disk lokal hanya berfungsi sebagai cache bersama, dan data dipersistenkan di OSS.

Ruang penyimpanan frozen node

Kami menyarankan 500 GiB atau lebih. Ruang disk lokal berfungsi sebagai cache bersama. Cache menggunakan 90% dari total ruang disk node atau total ruang dikurangi 100 GiB, mana yang lebih kecil. Kebijakan Least Recently Used (LRU) mengeluarkan blok data dingin. Semakin besar ruang disk, semakin tinggi rasio hit cache.

Jumlah frozen node

Jumlah node yang Anda beli harus merupakan kelipatan jumlah zona ketersediaan.

Setelah Anda membeli node beku, sistem akan menambahkan parameter -Enode.attr.box_type ke parameter startup node, seperti ditunjukkan pada tabel berikut.

Tipe node

Parameter startup

data node

-Enode.attr.box_type=hot

warm node

-Enode.attr.box_type=warm

frozen node

-Enode.attr.box_type=frozen

Client node

Anda dapat membeli node klien untuk berbagi beban overhead CPU dari node data. Hal ini meningkatkan performa pemrosesan dan stabilitas layanan kluster. Untuk layanan yang intensif CPU, seperti layanan yang memerlukan banyak kueri agregasi, kami menyarankan Anda membeli node klien.

Parameter

Deskripsi

Coordinating node

Anda tidak dapat melepas node klien yang telah Anda beli untuk kluster yang diterapkan di arsitektur kontrol cloud-native (kluster V7.16 atau yang lebih baru). Anda dapat memeriksa apakah Anda dapat melepas node klien di kluster Anda di halaman pembelian.

Spesifikasi coordinating node

Anda dapat melihat spesifikasi yang didukung di halaman pembelian.

Tipe disk coordinating node

Nilai parameter ini hanya bisa Ultra Disk.

Ruang penyimpanan coordinating node

Nilai parameter ini hanya bisa 20G.

Jumlah coordinating node

Jumlah node yang Anda beli harus merupakan kelipatan jumlah zona.

Referensi

FAQ

Kluster macet setelah menonaktifkan node hangat

1. Periksa aturan alokasi node box_type

  • Kueri pengaturan index.routing.allocation.require.box_type untuk semua indeks yang ada.

    GET */_settings/index.routing.allocation.require.box_type

    Jika output-nya {"index.routing.allocation.require.box_type": "warm"}, indeks tersebut harus dialokasikan ke node dengan box_type=warm.

  • Periksa apakah aturan alokasi box_type dikonfigurasi di templat indeks apa pun.

    Kueri semua templat indeks untuk memeriksa apakah aturan alokasi box_type dikonfigurasi. Jika templat mengembalikan "index.routing.allocation.require.box_type": "warm", semua indeks baru dialokasikan ke node hangat secara default.

    Saat indeks baru dibuat, indeks tersebut mewarisi konfigurasi dari templat. Jika nilai ini diatur di templat, semua indeks berikutnya secara otomatis menerapkan aturan ini.

  • GET _ilm/policy?filter_path=*.policy.phases.warm.actions.allocate.require.box_type

    Menanyakan konfigurasi alokasi node untuk fase hangat dari semua kebijakan Index Lifecycle Management (ILM).

Jika indeks dialokasikan ke node hangat, mematikan node data dingin dengan melakukan operasi scale-down akan menyebabkan perubahan kluster menjadi Change is blocked:

2. Solusi

  • Hapus konfigurasi box_type dari kebijakan

    # Pertama, hentikan ILM.
    POST _ilm/stop
    
    # Lihat kebijakan ILM spesifik.
    GET _ilm/policy/your_policy_name
    
    # Perbarui kebijakan ILM dan hapus konfigurasi box_type dari fase hangat.
    PUT _ilm/policy/your_policy_name
    {
      "policy": {
        "phases": {
          "warm": {
            "actions": {
              "allocate": {
                "require": {
                  "box_type": null  # Hapus konfigurasi ini.
                }
              }
            }
          },
          "hot": {
            "actions": {
              "allocate": {
                "require": {
                  "box_type": null  # Jika ada, hapus juga ini.
                }
              }
            }
          }
        }
      }
    }
    
    # Jika bidang require di bawah allocate kosong, hapus seluruh aksi allocate.
    # Atau, pertahankan hanya aturan alokasi lain yang diperlukan, seperti jumlah replika.
  • Hapus konfigurasi box_type dari templat indeks

    # Lihat nama templat spesifik.
    GET _template/?filter_path=*.settings.index.routing.allocation.require.box_type
    # Perbarui templat dan hapus konfigurasi box_type.
    PUT _template/your_template_name
    {
      "settings": {
        "index.routing.allocation.require.box_type": null
      }
    }
    # Atau, kirim ulang definisi templat lengkap tanpa bidang box_type.
  • Hapus konfigurasi box_type dari indeks

    # Hapus konfigurasi box_type untuk indeks tertentu.
    PUT /your_index_name/_settings
    {
      "index.routing.allocation.require.box_type": null
    }
    # Hapus konfigurasi untuk semua indeks secara batch.
    {
      "index.routing.allocation.require.box_type": null
    }