Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Memilih tipe instans dan pengujian

Setelah menghitung kebutuhan penyimpanan dan memilih jumlah serpihan yang Anda butuhkan, Anda dapat mulai membuat keputusan perangkat keras. Persyaratan perangkat keras bervariasi secara dramatis oleh beban kerja, tetapi kami masih dapat menawarkan beberapa rekomendasi dasar.

Secara umum, batas penyimpanan untuk setiap tipe instans dipetakan dengan jumlah CPU dan memori yang mungkin Anda butuhkan untuk beban kerja ringan. Misalnya, instans m6g.large.search memiliki ukuran volume EBS maksimum 512 GiB, 2 core vCPU, dan 8 GiB memori. Jika klaster Anda memiliki banyak serpihan, melakukan pajak agregasi, sering memperbarui dokumen, atau memproses sejumlah besar kueri, sumber daya tersebut mungkin tidak cukup untuk kebutuhan Anda. Jika cluster Anda termasuk dalam salah satu kategori ini, coba mulai dengan konfigurasi yang mendekati 2 core vCPU dan 8 GiB memori untuk setiap 100 GiB dari kebutuhan penyimpanan Anda.

Namun, bahkan sumber daya tersebut mungkin tidak cukup. Beberapa OpenSearch pengguna melaporkan bahwa mereka membutuhkan sumber daya berkali-kali untuk memenuhi persyaratan mereka. Untuk menemukan perangkat keras yang tepat untuk beban kerja Anda, Anda harus membuat perkiraan awal yang terdidik, menguji dengan beban kerja yang representatif, menyesuaikan, dan menguji lagi.

Langkah 1: Buat anggaran awal

Untuk memulai, kami merekomendasikan minimal tiga node untuk menghindari OpenSearch masalah potensial, seperti keadaan otak terbelah (ketika selang komunikasi mengarah ke cluster yang memiliki dua node manajer). Jika Anda memiliki tiga node manajer khusus, kami masih merekomendasikan minimal dua node data untuk replikasi.

Langkah 2: Hitung persyaratan penyimpanan per simpul

Jika Anda memiliki persyaratan penyimpanan 184-GiB dan jumlah minimum tiga node yang disarankan, gunakan persamaan 184/3 = 61 GiB untuk menemukan jumlah penyimpanan yang dibutuhkan setiap node. Dalam contoh ini, Anda dapat memilih tiga m6g.large.search contoh, di mana masing-masing menggunakan volume penyimpanan EBS 90-GiB, sehingga Anda memiliki jaring pengaman dan beberapa ruang untuk pertumbuhan dari waktu ke waktu. Konfigurasi ini menyediakan 6 core vCPU dan memori 24 GiB, sehingga cocok untuk beban kerja yang lebih ringan.

Untuk contoh yang lebih penting, pertimbangkan persyaratan penyimpanan 14 TiB (14.336 GiB) dan beban kerja yang berat. Dalam hal ini, Anda dapat memilih untuk memulai pengujian dengan 2 * 144 = 288 core vCPU dan 8 * 144 = 1152 GiB memori. Angka-angka ini bekerja untuk sekitar 18 instans i3.4xlarge.search. Jika Anda tidak memerlukan penyimpanan lokal yang cepat, Anda juga dapat menguji 18 r6g.4xlarge.search instans, masing-masing menggunakan volume penyimpanan EBS 1-TiB.

Jika klaster Anda mencakup ratusan terabyte data, lihat Skala petabyte di Layanan Amazon OpenSearch .

Langkah 3: Lakukan pengujian perwakilan

Setelah mengonfigurasi klaster, Anda dapat menambahkan indeks menggunakan jumlah pecahan yang Anda hitung sebelumnya, melakukan beberapa pengujian klien representatif menggunakan kumpulan data realistis, dan memantau CloudWatch metrik untuk melihat bagaimana klaster menangani beban kerja.

Langkah 4: Berhasil atau ulangi

Jika kinerja memenuhi kebutuhan Anda, pengujian berhasil, dan CloudWatch metrik normal, cluster siap digunakan. Ingatlah untuk mengatur CloudWatch alarm untuk mendeteksi penggunaan sumber daya yang tidak sehat.

Jika performa tidak dapat diterima, percobaan gagal, atau CPUUtilization atau JVMMemoryPressure tinggi, Anda mungkin perlu memilih tipe instans yang berbeda (atau menambahkan instans) dan melanjutkan pengujian. Saat Anda menambahkan instance, OpenSearch secara otomatis menyeimbangkan kembali distribusi pecahan di seluruh cluster.

Karena lebih mudah untuk mengukur kelebihan kapasitas dalam cluster yang dikuasai daripada defisit pada cluster yang kurang bertenaga, kami sarankan memulai dengan cluster yang lebih besar dari yang Anda pikir Anda butuhkan. Selanjutnya, uji dan turunkan skala ke klaster efisien yang memiliki sumber daya ekstra untuk memastikan operasi yang stabil selama periode peningkatan aktivitas.

Cluster produksi atau cluster dengan status kompleks mendapat manfaat dari node manajer khusus, yang meningkatkan kinerja dan keandalan cluster.