Elasticsearch:Evaluasi spesifikasi dan kapasitas penyimpanan

Perhatian

Metode evaluasi dalam topik ini didasarkan pada hasil pengujian aktual dan pengalaman pengguna. Kebutuhan pengguna terhadap struktur data, kompleksitas kueri, volume data, performa, dan perubahan data dapat berbeda-beda. Topik ini hanya bersifat referensi. Kami menyarankan agar Anda mengevaluasi spesifikasi dan kapasitas penyimpanan kluster Elasticsearch berdasarkan data aktual dan skenario bisnis Anda.

Evaluasi storage space

Storage space kluster Elasticsearch ditentukan oleh faktor-faktor berikut:

• Volume data sumber.

• Jumlah replica shard: Setiap primary shard harus memiliki setidaknya satu replica shard.

• Overhead pengindeksan: Dalam kebanyakan kasus, overhead pengindeksan 10% lebih besar daripada data sumber.

  Sebagai contoh, indeks pemantauan yang digunakan oleh X-Pack untuk analisis anomali menghasilkan overhead pengindeksan. Indeks pemantauan tersebut mencakup jenis-jenis berikut:

  • .monitoring-es-6-*: Jenis indeks ini mengonsumsi storage space dalam jumlah besar. Secara default, Elasticsearch hanya menyimpan data indeks yang dibuat dalam tujuh hari terakhir.

  • .monitoring-kibana-6-*: Jumlah storage space yang dikonsumsi oleh jenis indeks ini meningkat seiring dengan jumlah indeks. Secara default, Elasticsearch hanya menyimpan data indeks yang dibuat dalam tujuh hari terakhir.

  • .watcher-history-3-*: Jenis indeks ini hanya mengonsumsi storage space dalam jumlah kecil. Jika indeks semacam ini tidak lagi diperlukan, Anda dapat menghapusnya secara manual.

• Overhead internal kluster Elasticsearch: Operasi internal seperti segment merging dan logging menghasilkan overhead pengindeksan. 20% storage space dicadangkan untuk overhead tersebut.

  Jumlah storage space yang dikonsumsi oleh log kluster meningkat seiring dengan jumlah kueri dan dorongan data yang diterima oleh kluster Elasticsearch. Log kluster mencakup run log, access log, dan slow log. Secara default, Elasticsearch hanya menyimpan log yang dihasilkan dalam tujuh hari terakhir. Durasi ini tidak dapat diubah.

• Storage space yang dicadangkan oleh sistem operasi: Secara default, sistem operasi mencadangkan 5% storage space untuk proses kritis, pemulihan sistem, dan fragmentasi disk.

• Overhead ambang batas keamanan: Elasticsearch mencadangkan setidaknya 15% storage space sebagai ambang batas keamanan.

Storage space yang direkomendasikan dihitung menggunakan rumus berikut:

Storage space kluster yang direkomendasikan = Volume data sumber × (1 + Jumlah replica shard) × Overhead pengindeksan/(1 - Storage space yang dicadangkan oleh sistem operasi)/(1 - Overhead internal kluster)/(1 - Overhead ambang batas keamanan)
             = Volume data sumber × (1 + Jumlah replica shard) × 1,7
             = Volume data sumber × 3,4

Dari pengaturan shard, hanya jumlah replica shard yang memengaruhi hasil rumus di atas. Menambahkan primary shard tidak meningkatkan penggunaan disk, karena data yang ada hanya didistribusikan ulang ke lebih banyak shard dan total volume data tetap tidak berubah. Menambahkan replica shard meningkatkan penggunaan disk secara proporsional terhadap jumlah replika, karena setiap replica shard menyimpan salinan lengkap data. Hal ini sesuai dengan faktor (1 + Jumlah replica shard) dalam rumus. Oleh karena itu, jika satu shard menjadi terlalu besar, kami menyarankan agar Anda menambah jumlah primary shard alih-alih menambah replica shard. Untuk menambah jumlah primary shard, Anda dapat menggunakan API _split untuk memisahkan indeks atau melakukan reindex data.

Evaluasi spesifikasi node dan jumlah node

Data node

• Jumlah maksimum node per kluster = Jumlah vCPU per node × 5.

• Volume maksimum data yang dapat disimpan oleh setiap node dalam kluster Elasticsearch bervariasi tergantung pada skenario bisnis:

  • Skenario umum: Storage space maksimum per node = Ukuran memori per node (GiB) × 30.

  • Skenario kueri seperti akselerasi atau agregasi pada kueri data: Storage space maksimum per node = Ukuran memori per node (GiB) × 10.

  • Skenario logging seperti impor data log atau analitik offline: Storage space maksimum per node = Ukuran memori per node (GiB) × 50.

Tabel berikut mencantumkan jumlah maksimum node dan storage space maksimum per node untuk berbagai spesifikasi node.

Total storage space kluster Elasticsearch dihitung menggunakan rumus berikut: Total storage space kluster Elasticsearch = Storage space per node × Jumlah node. Anda dapat menentukan spesifikasi setiap node berdasarkan storage space maksimum per node dan jumlah maksimum node.

• Untuk volume data kecil yang menghasilkan I/O disk tinggi, evaluasi spesifikasi berdasarkan kemampuan I/O alih-alih hanya berdasarkan kapasitas penyimpanan. Kasus khas adalah indeks yang berisi sekitar 10 juta dokumen pendek, menempati sekitar 3 GB secara total, dan terutama dikueri berdasarkan pencocokan eksak, pencocokan awalan, atau agregasi. Kapasitas penyimpanan bukan hambatan dalam kasus ini, dan kebutuhan terhadap vCPU serta memori bersifat moderat. Namun, setiap kueri menyentuh banyak term dan segmen, yang menghasilkan pembacaan acak yang sering pada disk. Oleh karena itu, I/O disk menentukan latensi kueri yang dapat Anda capai. Kami menyarankan agar Anda mengevaluasi dua hal berikut secara bersamaan:

  • Spesifikasi node: pilih spesifikasi dengan rasio vCPU-memori 1:2, dan gunakan minimal 4 vCPU dan 16 GiB memori untuk setiap data node. Node dengan 4 vCPU dan 16 GiB memori mendukung hingga 160 GiB data dalam skenario kueri, yang memberikan ruang cukup untuk volume data sebesar ini. Spesifikasi di bawah nilai ini menyisakan sedikit page cache untuk indeks, sehingga kluster membaca lebih banyak data dari disk.

  • Penyimpanan: atur Storage Type ke Standard SSD saat Anda membeli kluster atau meningkatkan konfigurasi kluster. Standard SSD menyediakan IOPS tinggi dan waktu respons singkat, serta cocok untuk analitik dan pencarian online. IOPS dan throughput yang dapat dicapai oleh sebuah node ditentukan oleh tipe penyimpanan dan spesifikasi node, bukan oleh jumlah primary shard. Menambahkan primary shard ke indeks seukuran ini tidak meningkatkan kemampuan I/O yang tersedia.

Node master khusus

Jika kluster Elasticsearch Anda berisi banyak data node, kami menyarankan agar Anda mengaktifkan dedicated master node untuk memastikan stabilitas kluster.

Anda dapat merujuk pada petunjuk berikut untuk menentukan spesifikasi dedicated master node untuk kluster Elasticsearch Anda:

• Spesifikasi default: 2 vCPU dan 8 GiB memori

• Spesifikasi jika jumlah data node melebihi 10: 4 vCPU dan 16 GiB memori

• Spesifikasi jika jumlah data node melebihi 30: 8 vCPU dan 32 GiB memori

• Spesifikasi jika jumlah data node melebihi 50: 16 vCPU dan 64 GiB memori

Node klien

Jika Anda menggunakan client node independen, Anda dapat melakukan operasi reduce pada hasil evaluasi. Dalam kasus ini, jika terjadi garbage collection (GC) parah pada tahap reduce, data node tidak akan terpengaruh.

Jika Anda mengaktifkan client node, kami menyarankan agar Anda mengonfigurasi client node dan data node berdasarkan rasio 1:5 dan memilih spesifikasi dengan rasio vCPU-memori 1:4 atau 1:8 untuk client node. Anda harus membeli minimal dua client node. Misalnya, jika Anda mengonfigurasi 10 data node dengan spesifikasi 8 vCPU dan 32 GiB memori, kami menyarankan agar Anda mengonfigurasi 2 client node dengan spesifikasi 8 vCPU dan 32 GiB memori.

Evaluasi shard

Jumlah shard dan ukuran setiap shard memengaruhi stabilitas dan performa kluster Elasticsearch. Anda harus merencanakan shard dengan tepat untuk semua indeks dalam kluster Elasticsearch. Hal ini membantu mencegah banyaknya shard memengaruhi performa kluster atau menyebabkan beban tidak merata dalam skenario bisnis kompleks. Misalnya, jika perencanaan shard untuk suatu indeks dalam kluster Elasticsearch tidak tepat, perbedaan signifikan dalam penggunaan disk node dan beban CPU yang tidak merata di antara node dapat terjadi.

Alibaba Cloud menyediakan panduan berikut untuk Anda merencanakan shard. Panduan ini hanya untuk referensi.

• Volume data yang disimpan pada setiap shard

  • Kami menyarankan agar Anda menyimpan tidak lebih dari 30 GiB data pada setiap shard. Dalam kasus khusus, Anda dapat menyimpan tidak lebih dari 50 GiB data pada setiap shard.

  • Dalam skenario analitik log atau skenario yang memerlukan indeks sangat besar, pastikan setiap shard menyimpan tidak lebih dari 100 GiB data.

• Jumlah shard

  • Sebelum mengalokasikan shard untuk kluster Elasticsearch Anda, kami menyarankan agar Anda mengevaluasi volume data yang ingin Anda simpan.

    • Jika total volume data besar, Anda harus mengurangi jumlah data yang ditulis untuk mengurangi beban kerja kluster Elasticsearch Anda. Dalam kasus ini, kami menyarankan agar Anda mengonfigurasi beberapa primary shard untuk setiap indeks dan satu replica shard untuk setiap primary shard.

    • Jika total volume data dan volume data yang ingin Anda tulis kecil, kami menyarankan agar Anda mengonfigurasi satu primary shard untuk setiap indeks dan satu atau lebih replica shard untuk setiap primary shard.

    Catatan

    • Secara default, kluster Elasticsearch versi V7.X atau lebih baru dikonfigurasi dengan satu primary shard untuk setiap indeks dan satu replica shard untuk setiap primary shard. Secara default, kluster Elasticsearch versi sebelum V7.X dikonfigurasi dengan lima primary shard untuk setiap indeks dan satu replica shard untuk setiap primary shard.

    • Jika volume data yang perlu Anda simpan kurang dari 30 GiB, Anda dapat mengonfigurasi satu primary shard untuk setiap indeks dan beberapa replica shard untuk primary shard tersebut. Hal ini mencapai load balancing. Misalnya, ukuran setiap indeks adalah 20 GiB, dan kluster Elasticsearch Anda berisi lima data node. Dalam kasus ini, Anda dapat mengonfigurasi satu primary shard untuk setiap indeks dan empat replica shard untuk setiap primary shard.

  • Kami menyarankan agar Anda menjaga jumlah shard sama dengan jumlah data node atau kelipatan bulat dari jumlah data node.

  • Kami menyarankan agar Anda mengonfigurasi maksimal lima shard untuk suatu indeks pada satu node.

  • Kami menyarankan agar Anda menghitung jumlah total shard untuk semua indeks pada satu node menggunakan salah satu rumus berikut:

    • Untuk kluster dengan spesifikasi kecil: Jumlah shard pada satu data node = Ukuran memori data node × 30

    • Untuk kluster dengan spesifikasi besar: Jumlah shard pada satu data node = Ukuran memori data node × 50

    Catatan

    • Saat menghitung jumlah shard, Anda juga harus mempertimbangkan volume data. Jika volume data kurang dari 1 TiB, kami menyarankan agar Anda menghitung jumlah shard menggunakan rumus untuk kluster dengan spesifikasi kecil.

    • Secara default, jumlah maksimum shard pada satu node dalam kluster Elasticsearch V7.X adalah 1.000. Kami menyarankan agar Anda tidak mengubah jumlah maksimum tersebut. Jika Anda ingin mengubah jumlah shard pada satu node, Anda dapat menambah jumlah node sebelum menggunakan kluster.

    • Kami menyarankan agar Anda mengonfigurasi shard berdasarkan kebutuhan bisnis Anda. Lebih banyak primary shard menghasilkan overhead performa yang lebih besar. Jika Anda mengonfigurasi jumlah shard yang terlalu besar untuk setiap indeks dalam kluster Elasticsearch Anda, file handle dapat habis. Akibatnya, faults dapat terjadi pada kluster Elasticsearch Anda.

Panduan di atas berlaku untuk satu indeks. Jika kluster Anda menyimpan beberapa indeks bisnis, indeks tersebut berbeda dalam volume data dan laju pertumbuhan, sehingga rencanakan jumlah primary shard untuk setiap indeks secara terpisah alih-alih menerapkan satu nilai untuk semua indeks. Lakukan langkah-langkah berikut untuk setiap indeks:

1. Kumpulkan input perencanaan indeks. Jalankan perintah GET _cat/indices?v&bytes=b untuk mendapatkan ukuran penyimpanan saat ini dari setiap indeks, lalu perkirakan peningkatan harian dan periode retensi indeks untuk mendapatkan volume data yang diharapkan pada akhir periode retensi. Catat jumlah data node dalam kluster, ukuran memori per data node, dan jumlah replica shard yang digunakan oleh indeks.

2. Hitung jumlah dasar primary shard berdasarkan ukuran penyimpanan per shard. Bagi volume data yang diharapkan dari indeks dengan 30 GiB dan bulatkan hasilnya ke atas. Dalam kasus khusus, Anda dapat menggunakan 50 GiB sebagai pembagi. Dalam skenario analitik log atau skenario yang memerlukan indeks sangat besar, Anda dapat menggunakan 100 GiB. Jika volume data yang diharapkan dari indeks tetap kurang dari 30 GiB, pertahankan satu primary shard untuk indeks tersebut dan tambahkan replica shard alih-alih, sehingga kueri pada indeks tersebar di berbagai node.

3. Selaraskan jumlah shard dengan jumlah data node. Sesuaikan nilai dasar sehingga jumlah total shard indeks, yang dihitung menggunakan rumus Jumlah primary shard × (1 + Jumlah replica shard), sama dengan jumlah data node atau kelipatan bulat dari jumlah data node. Pembulatan ke atas lebih disukai daripada pembulatan ke bawah, karena shard yang lebih kecil memberikan ruang untuk pertumbuhan di masa depan.

4. Verifikasi hasil terhadap batas per node. Setiap node harus menyimpan tidak lebih dari lima shard dari indeks yang sama. Jumlah total shard dari semua indeks pada satu data node tidak boleh melebihi nilai yang dihitung menggunakan rumus untuk spesifikasi kluster Anda: Ukuran memori data node × 30 untuk kluster dengan spesifikasi kecil, atau Ukuran memori data node × 50 untuk kluster dengan spesifikasi besar. Untuk kluster versi V7.X, pertahankan jumlah shard pada satu node di bawah 1.000. Jika jumlah shard yang direncanakan dari semua indeks melebihi batas ini, kurangi jumlah shard dari indeks yang memiliki volume data paling kecil, gabungkan indeks yang dipisahkan berdasarkan waktu tetapi jarang dikueri, atau tambahkan data node.

Sebagai contoh, suatu indeks diharapkan menyimpan 300 GiB data pada akhir periode retensinya, kluster berisi 6 data node, dan indeks menggunakan 1 replica shard. Jumlah dasar primary shard adalah 300 GiB/30 GiB = 10. Untuk membuat jumlah total shard menjadi kelipatan bulat dari 6, tingkatkan jumlah primary shard menjadi 12. Indeks tersebut kemudian memiliki 24 shard secara total, setiap shard menyimpan sekitar 25 GiB data, dan setiap data node menyimpan 4 shard dari indeks tersebut. Ketiga panduan tersebut terpenuhi.

Setelah Anda menyelesaikan perhitungan untuk setiap indeks, terapkan rencana tersebut. Anda hanya dapat menentukan jumlah primary shard saat membuat indeks. Untuk indeks yang sudah ada dan shard-nya terlalu besar, gunakan API _split untuk memisahkan indeks atau lakukan reindex data, dan gunakan templat indeks untuk menerapkan nilai yang direncanakan ke indeks yang dibuat selanjutnya.

Jika penggunaan disk atau utilisasi CPU masih berbeda signifikan di antara node setelah rencana diterapkan, shard dari satu atau beberapa indeks besar tetap terkonsentrasi pada beberapa node. Anda dapat mengidentifikasi indeks dan node yang menyebabkan ketidakseimbangan tersebut dan menyeimbangkan kembali shard berdasarkan Beban tidak seimbang pada kluster.

Untuk informasi selengkapnya tentang evaluasi shard, lihat How to size your shards.

Referensi

• Untuk mengetahui spesifikasi node yang didukung di berbagai wilayah dan versi, atau untuk membeli kluster Elasticsearch, lihat halaman pembelian.

• Anda dapat merujuk pada hasil uji stres pada kluster Elasticsearch dengan spesifikasi dan versi berbeda untuk mengetahui performa berbagai spesifikasi node. Untuk informasi selengkapnya, lihat topik dalam direktori Performance.

• Untuk informasi tentang perbedaan antara tipe kluster Edisi Standar dan Edisi Kernel-enhanced, serta perubahan fitur di setiap versi kluster, lihat Fitur versi.

• Anda dapat menyesuaikan item seperti spesifikasi node, storage space node, dan jumlah node untuk kluster Elasticsearch yang sudah ada berdasarkan hasil evaluasi. Untuk informasi tentang cara melakukan operasi tersebut dan tindakan pencegahan terkait, lihat Upgrade cluster configuration dan Downgrade a cluster.

• Anda hanya dapat menentukan jumlah primary shard untuk suatu indeks saat membuat indeks tersebut. Setelah indeks dibuat, Anda tidak dapat mengubah jumlah tersebut untuk indeks tersebut. Untuk informasi tentang cara membuat indeks, lihat Create an index.

• Jika volume data yang disimpan pada setiap shard untuk indeks yang sudah ada melebihi volume yang direkomendasikan, kami menyarankan agar Anda melakukan reindex data untuk indeks tersebut. Untuk informasi selengkapnya, lihat Use the reindex API to migrate data between Alibaba Cloud Elasticsearch clusters.

  Catatan

  Reindex data dapat memastikan kontinuitas layanan tetapi memakan waktu.

• Untuk informasi tentang cara menyelesaikan beban tidak seimbang pada kluster Elasticsearch, lihat Unbalanced loads on a cluster.

• Untuk informasi tentang cara menyelesaikan distribusi tidak merata data panas pada node, lihat Uneven distribution of hot data on nodes.

• Jika Anda mengaktifkan fitur Auto Indexing, kami menyarankan agar Anda menggunakan fitur manajemen siklus hidup indeks (ILM) atau skrip API Elasticsearch untuk menghapus indeks lama. Untuk informasi selengkapnya tentang fitur ILM, lihat Manage Heartbeat data with ILM.

• Kami menyarankan agar Anda menghapus indeks kecil secara tepat waktu untuk membebaskan heap memory.

Alasan perbedaan penyimpanan indeks

Ukuran penyimpanan dapat sangat bervariasi antar indeks. Bagian berikut menjelaskan alasan umum perbedaan tersebut dan metode troubleshooting-nya.

• Pengaturan alat analisis berbeda: Alat analisis ngram memecah teks menjadi banyak kombinasi karakter kecil, yang menghasilkan token jauh lebih banyak daripada alat analisis standard. Hal ini menghasilkan inverted index yang lebih besar. Sebagai contoh, untuk dokumen yang sama, indeks yang menggunakan alat analisis ngram dengan min_gram=1 dan max_gram=4 dapat sekitar 3,4 kali lebih besar daripada indeks yang sama yang menggunakan alat analisis standard.

• Tipe bidang dan pengaturan pemetaan berbeda: Tipe bidang text membangun inverted index dengan melakukan tokenisasi nilai bidang menjadi beberapa token. Tipe bidang keyword tidak melakukan tokenisasi; alih-alih, indeks tersebut mengindeks seluruh nilai bidang sebagai satu term dalam inverted index, mendukung pencocokan eksak (term kueri), pengurutan, dan agregasi. Konfigurasi pemetaan yang berbeda secara langsung memengaruhi konsumsi penyimpanan.

• Jumlah replika berbeda: Nilai yang lebih tinggi untuk parameter number_of_replicas meningkatkan konsumsi penyimpanan total.

• Pengaturan kompresi berbeda: Pengaturan best_compression menggunakan algoritma DEFLATE. Algoritma ini menawarkan rasio kompresi lebih tinggi daripada algoritma LZ4 default, tetapi dengan sedikit penurunan performa baca/tulis.

Untuk menyelidiki perbedaan penyimpanan, lakukan langkah-langkah berikut:

• Jalankan perintah GET _cat/indices?v&bytes=b untuk melihat ukuran penyimpanan setiap indeks.

• Jalankan perintah POST <index>/_disk_usage?run_expensive_tasks=true untuk menganalisis distribusi penyimpanan tingkat bidang dan mengidentifikasi bidang yang mengonsumsi ruang paling banyak.

FAQ

Bagaimana cara menentukan apakah kluster saya memerlukan peningkatan konfigurasi, dan apakah I/O disk merupakan risiko?

Evaluasi kluster dalam urutan berikut. Metrik resource memberi tahu Anda apakah kluster mendekati batas kapasitasnya, dan event kluster memberi tahu Anda apakah I/O disk telah menjadi hambatan.

Langkah 1: Periksa apakah metrik resource tetap pada level tinggi

Pada halaman detail instans, klik Cluster Monitoring dan lihat tab Basic Monitoring. Atur rentang waktu menjadi 1 hari lalu menjadi 7 hari, lalu periksa Node CPU Utilization(%), Node Disk Utilization(%), Node HeapMemory Utilization(%), dan Node load_1m. Jika metrik tetap lebih tinggi dari 80% selama jam kerja, atau jika load_1m tetap mendekati atau lebih tinggi dari jumlah vCPU per node, kluster berjalan mendekati batas kapasitasnya. Dalam kasus ini, performa tulis dan kueri serta stabilitas kluster dapat terpengaruh meskipun tidak ada alert kritis yang dipicu, dan Anda harus mempertimbangkan untuk meningkatkan konfigurasi kluster. Status kluster dan metrik QPS tulis dan kueri pada tab yang sama membantu Anda mengonfirmasi apakah beban berasal dari peningkatan traffic atau perubahan pola kueri.

Basic Monitoring menyediakan tujuh metrik: status kluster, QPS indeks kluster, QPS kueri kluster, utilisasi CPU node, penggunaan disk node, utilisasi heap memory node, dan load_1m node. Tidak tersedia grafik IOPS terpisah atau grafik throughput disk, jadi jangan gunakan grafik pemantauan untuk menentukan apakah disk mencapai batas I/O-nya.

Langkah 2: Identifikasi risiko I/O disk berdasarkan event kluster

Klik Event Center di panel navigasi kiri, lalu filter event berdasarkan rentang waktu, ID instans, dan tingkat keparahan event. Event berikut menunjukkan bahwa kemampuan I/O konfigurasi penyimpanan saat ini telah menjadi hambatan: disk I/O performance bottleneck, high disk I/O utilization, dan disk throughput throttling. Jika event semacam ini terjadi berulang kali, atau jika disertai dengan peningkatan latensi kueri atau permintaan yang ditolak, kluster memiliki risiko hambatan I/O, meskipun utilisasi CPU dan heap memory normal. Jika event menunjukkan bahwa kluster telah memasuki status read-only, segera tangani, karena tulisan sudah diblokir. Batas atas IOPS dan throughput yang memicu event ini ditentukan oleh tipe penyimpanan dan spesifikasi node kluster.

Langkah 3: Kurangi tekanan dalam jangka pendek

• Optimalkan kueri: persempit rentang waktu kueri, hindari kueri wildcard dan agregasi high-cardinality pada indeks besar, serta hapus atau gabungkan indeks yang kecil atau tidak lagi dikueri untuk membebaskan heap memory.

• Kurangi jumlah replica shard untuk indeks yang tidak memerlukan throughput baca tinggi. Setiap replica shard menyimpan salinan lengkap data, sehingga menghapus satu replica shard mengurangi penggunaan disk dan overhead tulis.

• Tingkatkan distribusi shard berdasarkan panduan dalam bagian "Evaluasi shard" topik ini. Anda hanya dapat menentukan jumlah primary shard saat membuat indeks. Untuk indeks yang sudah ada, gunakan API _split untuk memisahkan indeks atau lakukan reindex data, alih-alih berharap dapat mengubah jumlah primary shard indeks yang sedang berjalan.

Langkah 4: Skalakan kluster untuk pertumbuhan jangka panjang

Jika metrik tetap pada level tinggi setelah optimasi di atas, atau jika volume data terus meningkat, tingkatkan konfigurasi kluster. Anda dapat meningkatkan spesifikasi node, menambah data node, atau memperluas storage space per node berdasarkan Upgrade cluster configuration, dan evaluasi ulang spesifikasi target berdasarkan bagian "Evaluasi spesifikasi node dan jumlah node" topik ini. Jika I/O disk—bukan vCPU atau memori—merupakan hambatan, evaluasi tipe penyimpanan yang menyediakan IOPS lebih tinggi saat merencanakan peningkatan. Jika kluster Anda menggunakan spesifikasi developer, perhatikan bahwa layanan terganggu selama peningkatan dan kluster tidak dapat diturunkan kembali ke spesifikasi developer setelahnya.