Cara mengonfigurasi parameter saat membuat kluster Alibaba Cloud Elasticsearch - Elasticsearch

Saat membuat kluster Alibaba Cloud Elasticsearch, Anda perlu mengonfigurasi spesifikasi dan penyimpanan berbagai tipe node sesuai kebutuhan bisnis. Kluster Elasticsearch terdiri atas data node, Kibana node, dedicated master node, warm node, frozen node, dan coordinating node, masing-masing dengan tanggung jawab yang berbeda.

Data node

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

Catatan

Jika sebuah kluster memiliki dedicated master node, data node hanya berfungsi sebagai data node.
Jika sebuah kluster tidak memiliki dedicated master node, data node berperan ganda sebagai data node sekaligus dedicated master node.
Kluster Alibaba Cloud Elasticsearch menggunakan salah satu dari dua arsitektur control plane: control plane dasar (v2) atau control plane cloud-native (v3). Pada arsitektur v2, peningkatan kapasitas kluster yang tidak memiliki dedicated master node akan memicu restart kluster. Jika beban keseluruhan kluster rendah dan indeks Anda memiliki shard replika, kluster tetap tersedia selama restart. Namun, dalam skenario tertentu—seperti beban write dan query 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 menggunakan data node dengan 2 vCPU dan memori 4 GiB di lingkungan pengujian, serta menggunakan data node 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 sensitif terhadap latensi atau workload intensif I/O. Untuk informasi lebih lanjut tentang spesifikasi ESSD, lihat Spesifikasi node. Untuk informasi 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 membaca atau menulis data ke disk terenkripsi.
Ruang penyimpanan per data node	Ruang penyimpanan setiap data node bergantung pada tipe disknya. 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 lainnya, 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 lainnya, 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 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 memiliki dua data node memiliki risiko split-brain yang tinggi dan stabilitas rendah. Jika kluster versi lama seperti V6.X atau V5.X hanya memiliki dua data node, node master khusus mungkin tidak terpilih saat diperlukan restart node, sehingga kluster mungkin tidak dapat menyediakan layanan. Oleh karena itu, Anda harus mengonfigurasi parameter ini sesuai kebutuhan bisnis Anda.

Kibana node

Nilai parameter Kibana Node hanya bisa Yes.
Kibana node dengan 1 vCPU dan memori 2 GiB tidak dikenai biaya. Namun, kami menyarankan hanya menggunakannya untuk tujuan pengujian.
Mengingat dampaknya terhadap performa dan stabilitas kluster, kami menyarankan membeli Kibana node dengan minimal 2 vCPU dan memori 4 GiB atau spesifikasi lebih tinggi.

Dedicated master node

Anda dapat menggunakan dedicated master node untuk menjalankan operasi pada kluster, seperti membuat indeks, menghapus indeks, melacak node, dan mengalokasikan shard. Stabilitas dedicated master node sangat penting bagi kesehatan kluster. Secara default, setiap node dalam kluster dapat berfungsi sebagai dedicated master node. Operasi seperti indexing data, pencarian, dan kueri memerlukan banyak sumber daya CPU, memori, dan I/O. Untuk memastikan stabilitas kluster, kami menyarankan membeli dedicated master node guna memisahkan fungsi tersebut dari data node.

Penting

Jika dedicated master node dalam kluster Anda gratis, Anda akan dikenai biaya setelah melakukan upgrade konfigurasi kluster.
Jika Anda melakukan perubahan blue-green pada kluster yang tidak memiliki dedicated master node dan menggunakan arsitektur lama (V2), data node akan direstart saat Anda melakukan perubahan berikutnya pada kluster. Oleh karena itu, kami menyarankan membeli dedicated master node.

Parameter	Deskripsi
Dedicated master node	Untuk meningkatkan stabilitas layanan Anda, kami menyarankan membeli dedicated master node. Untuk kluster Elasticsearch multi-zona, nilai default parameter ini adalah Yes dan tidak dapat diubah. Catatan Anda tidak dapat melepas dedicated master node yang telah dibeli. Setelah kluster dibuat, Anda dapat membeli dedicated master node saat melakukan upgrade 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 sensitif terhadap latensi atau workload intensif I/O. Untuk informasi lebih lanjut tentang spesifikasi ESSD, lihat Spesifikasi node. Untuk informasi 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 write tinggi, dan sensitif terhadap latensi.
Data hangat: Indeks yang jarang dikueri dan umumnya read-only atau memiliki aktivitas write minimal. Biasanya berupa data historis.

Dengan menempatkan data panas dan hangat pada tipe node yang berbeda, Anda dapat mencegah konflik sumber daya akibat data hangat yang 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 dedicated master node telah dibeli, warm node hanya berfungsi sebagai warm node.

Jika dedicated master node belum dibeli, warm node juga berfungsi sebagai dedicated master node.

Parameter	Deskripsi
Warm node	Anda dapat menonaktifkan warm node yang telah dibeli. Jika kluster mengalami hang saat Anda menonaktifkan warm node, lihat Apa yang harus dilakukan jika kluster hang setelah warm node dinonaktifkan?
Spesifikasi warm node	Informasi tentang spesifikasi yang didukung tersedia di halaman pembelian. Untuk skenario dengan kebutuhan I/O tinggi dan penyimpanan besar, Anda juga dapat menggunakan tipe instans local disk hemat biaya, seperti tipe instans `20 vCPU, memori 88 GiB (SATA: 8 × 7300 GiB)`. Batasan berikut berlaku untuk tipe instans local disk: Hanya instans kernel-enhanced versi V7.17 yang diterapkan dalam arsitektur control plane cloud-native (v3) di dua atau tiga availability zone yang mendukung tipe instans local disk. Untuk instans yang menggunakan arsitektur v3, perubahan blue-green tingkat node, seperti skala keluar node, tidak didukung untuk tipe instans disk lokal. Catatan Konfigurasikan minimal satu replika saat menggunakan tipe instans local disk untuk mencegah kehilangan data pada local disk. Anda tidak dapat mengubah tipe instans local disk menjadi tipe instans cloud disk. Jika arsitektur aplikasi Anda tidak dapat menjamin keandalan data, kami menyarankan 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 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 melakukan upgrade konfigurasi kluster, Anda tidak dapat mengaktifkan enkripsi disk untuk disk yang telah dibeli. Namun, jika Anda membeli cloud disk saat upgrade 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 membeli warm node, 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

Frozen node merupakan lapisan komputasi untuk fitur Searchable Snapshot. Frozen node memelihara 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, frozen node dapat mengurangi biaya penyimpanan hingga 90% sambil tetap mempertahankan kemampuan pencarian.

Frozen node hanya didukung untuk instans versi V8.17.0 dan yang lebih baru. Setelah diaktifkan, Anda tidak dapat menonaktifkan frozen node. Untuk menonaktifkannya, hubungi dukungan teknis.
Frozen node tidak memerlukan local disk 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 versi V8.17.0, Anda dapat memilih kotak centang di bagian spesifikasi instans untuk mengaktifkan fitur ini.
Spesifikasi frozen node	Kami menyarankan tipe instans dengan minimal 4 vCPU dan memori 16 GiB. Memori frozen node memelihara metadata indeks dan mengelola cache bersama. Memori yang cukup dapat meningkatkan rasio hit cache. Informasi tentang spesifikasi yang didukung tersedia di halaman pembelian.
Tipe disk frozen node	Ultra Disk dan ESSD didukung. Local disk hanya berfungsi sebagai cache bersama, sedangkan data dipertahankan di OSS.
Ruang penyimpanan frozen node	Kami menyarankan minimal 500 GiB. 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 availability zone.

Setelah membeli frozen node, 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 client node untuk berbagi beban overhead CPU data node. Hal ini meningkatkan performa pemrosesan dan stabilitas layanan kluster. Untuk layanan yang intensif CPU—seperti layanan yang memerlukan banyak kueri agregasi—kami menyarankan membeli client node.

Parameter	Deskripsi
Coordinating node	Anda tidak dapat melepas client node yang telah dibeli untuk kluster yang diterapkan dalam arsitektur control plane cloud-native (kluster versi V7.16 atau yang lebih baru). Anda dapat memeriksa apakah client node dalam kluster Anda dapat dilepas 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

Untuk informasi lebih lanjut tentang cara membeli kluster Elasticsearch, lihat Buat kluster Alibaba Cloud Elasticsearch.
Untuk informasi lebih lanjut tentang node, lihat Node | Elasticsearch Guide.
Untuk informasi lebih lanjut tentang harga spesifikasi node, lihat Pricing.

FAQ

Kluster hang setelah menonaktifkan warm node

1. Periksa apakah aturan alokasi node berdasarkan `box_type` dikonfigurasi secara manual di kluster (yaitu, apakah indeks dialokasikan secara paksa ke node yang diberi tag `warm` )

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 dalam templat indeks apa pun.
Kueri semua templat indeks untuk memeriksa apakah aturan alokasi box_type dikonfigurasi. Jika suatu templat mengembalikan "index.routing.allocation.require.box_type": "warm", semua indeks baru secara default dialokasikan ke warm node.
Saat indeks baru dibuat, konfigurasi tersebut diwariskan dari templat. Jika nilai ini diatur dalam 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 warm dari semua kebijakan Index Lifecycle Management (ILM).

Jika suatu indeks dialokasikan ke warm node, mematikan node data dingin melalui 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 warm.
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 field 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 field 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
}