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.
-
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 |
Catatan
|
|
Tingkat performa ESSD |
Jika Anda mengatur parameter Tipe Disk Data Node ke ESSD, Anda perlu mengonfigurasi parameter ini. |
|
Enkripsi disk data node |
|
|
Ruang penyimpanan per data node |
Ruang penyimpanan setiap data node bergantung pada tipe disk. Satuan: GiB.
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.
-
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 |
Catatan
|
|
Spesifikasi dedicated master node |
Anda dapat melihat spesifikasi yang didukung di halaman pembelian. |
|
Tipe disk dedicated master node |
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.
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
Catatan
|
|
Tipe disk warm node |
Ultra Disk dan ESSD didukung. |
|
Enkripsi disk warm node |
Catatan
|
|
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
-
Untuk informasi lebih lanjut tentang cara membeli kluster Elasticsearch, lihat Buat kluster Alibaba Cloud Elasticsearch.
-
Untuk informasi lebih lanjut tentang node, lihat Node | Panduan Elasticsearch.
-
Untuk informasi lebih lanjut tentang harga spesifikasi node, lihat Harga.
FAQ
Kluster macet setelah menonaktifkan node hangat
1. Periksa aturan alokasi node box_type
-
Kueri pengaturan
index.routing.allocation.require.box_typeuntuk semua indeks yang ada.GET */_settings/index.routing.allocation.require.box_typeJika output-nya
{"index.routing.allocation.require.box_type": "warm"}, indeks tersebut harus dialokasikan ke node denganbox_type=warm. -
Periksa apakah aturan alokasi
box_typedikonfigurasi di templat indeks apa pun.Kueri semua templat indeks untuk memeriksa apakah aturan alokasi
box_typedikonfigurasi. 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_typeMenanyakan 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_typedari 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_typedari 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_typedari 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 }