Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Node master khusus di OpenSearch Layanan Amazon
Amazon OpenSearch Service menggunakan node master * khusus * untuk meningkatkan stabilitas cluster. Sebuah simpul utama khusus melakukan tugas manajemen klaster, tetapi tidak menyimpan data atau menanggapi permintaan pengunggahan data. Pembongkaran tugas manajemen klaster ini meningkatkan stabilitas domain Anda. Sama seperti semua jenis simpul lainnya, Anda membayar tarif per jam untuk setiap simpul utama khusus.
Simpul utama khusus melakukan tugas manajemen klaster berikut:
+ Lacak semua node di cluster.
+ Lacak jumlah indeks di cluster.
+ Lacak jumlah pecahan milik setiap indeks.
+ Mempertahankan informasi routing untuk node di cluster.
+ Memperbarui status cluster setelah status berubah, seperti membuat indeks dan menambahkan atau menghapus node di cluster.
+ Mereplikasi perubahan ke status cluster di semua node dalam cluster.
+ Pantau kesehatan semua node cluster dengan mengirimkan sinyal * detak jantung*, sinyal periodik yang memantau ketersediaan node data di cluster.
Ilustrasi berikut menunjukkan domain OpenSearch Layanan dengan 10 instance. Tujuh dari instans adalah simpul data dan tiga adalah simpul utama khusus. Hanya satu dari node master khusus yang aktif. Dua node master khusus abu-abu menunggu sebagai cadangan jika node master khusus aktif gagal. Semua permintaan unggah data dilayani oleh tujuh simpul data, dan semua tugas manajemen klaster diturunkan ke simpul utama khusus yang aktif.
## Memilih jumlah node master khusus
Sebaiknya gunakan Multi-AZ dengan Standby, yang menambahkan ** tiga node master ** khusus ke setiap domain OpenSearch Layanan produksi. Jika Anda menerapkan Multi-AZ tanpa Standby atau Single-AZ, kami masih merekomendasikan tiga node master khusus. Jangan pernah memilih jumlah simpul utama khusus yang genap. Pertimbangkan hal berikut saat memilih jumlah simpul utama khusus:
+ Satu node master khusus secara eksplisit dilarang oleh OpenSearch Layanan karena Anda tidak memiliki cadangan jika terjadi kegagalan. Anda menerima pengecualian validasi jika Anda mencoba untuk membuat domain dengan hanya satu simpul utama khusus.
+ Jika Anda memiliki dua node master khusus, cluster Anda tidak memiliki kuorum node yang diperlukan untuk memilih node master baru jika terjadi kegagalan.
Kuorum adalah jumlah node master khusus/2 \+ 1 (dibulatkan ke bawah ke bilangan bulat terdekat). Dalam hal ini, 2 / 2 \+ 1 = 2. Karena satu simpul utama khusus telah gagal dan hanya satu cadangan ada, klaster tidak memiliki kuorum dan tidak dapat memilih utama baru.
+ Tiga simpul utama khusus, nomor yang disarankan, menyediakan dua simpul cadangan dalam hal kegagalan simpul master dan kuorum yang diperlukan (2) untuk memilih utama baru.
+ Empat node master khusus tidak lebih baik dari tiga dan dapat menyebabkan masalah jika Anda menggunakan [ beberapa Zona Ketersediaan](managedomains-multiaz.md).
+ Jika salah satu simpul utama gagal, Anda memiliki kuorum (3) untuk memilih utama baru. Jika dua simpul gagal, Anda kehilangan kuorum tersebut, seperti yang Anda lakukan dengan tiga simpul utama khusus.
+ Dalam konfigurasi Availability Zone tiga, dua AZ memiliki satu simpul utama khusus, dan satu AZ memiliki dua. Jika AZ mengalami gangguan, dua AZ yang tersisa tidak memiliki kuorum yang diperlukan (3) untuk memilih master baru.
+ Memiliki lima simpul utama khusus berfungsi serta tiga dan memungkinkan Anda kehilangan dua simpul sambil mempertahankan kuorum. Tetapi karena hanya satu node master khusus yang aktif pada waktu tertentu, konfigurasi ini berarti Anda membayar untuk empat node idle. Banyak pengguna menganggap tingkat perlindungan failover ini berlebihan.
Jika cluster memiliki jumlah node yang memenuhi syarat master yang genap, OpenSearch dan versi Elasticsearch 7. *x * dan kemudian mengabaikan satu node sehingga konfigurasi pemungutan suara selalu berupa angka ganjil. Dalam kasus ini, empat simpul utama khusus pada dasarnya setara dengan tiga (dan dua banding satu).
**catatan**
Jika klaster Anda tidak memiliki kuorum yang diperlukan untuk memilih simpul utama baru, menulis *dan* membaca permintaan untuk klaster keduanya gagal. Perilaku ini berbeda dari OpenSearch default.
## Memilih jenis instance untuk node master khusus
### OpenSearch Domain layanan dan kuota instans
Meskipun node master khusus tidak memproses permintaan pencarian dan kueri, ukurannya sangat berkorelasi dengan ukuran instance dan jumlah instance, indeks, dan pecahan yang dapat mereka kelola. Untuk cluster produksi, kami merekomendasikan, minimal, rekomendasi ukuran berikut untuk node master khusus.
Rekomendasi ini didasarkan pada beban kerja yang khas dan dapat bervariasi berdasarkan kebutuhan Anda. Klaster dengan banyak serpihan atau pemetaan bidang bisa mendapatkan keuntungan dari tipe instans yang lebih besar. Untuk informasi selengkapnya, lihat CloudWatch Alarm yang [ disarankan ](cloudwatch-alarms.md) untuk OpenSearch Layanan Amazon untuk menentukan apakah Anda perlu menggunakan jenis instans yang lebih besar.
| RAM | Dukungan Max Node untuk Elasticsearch dan OpenSearch Layanan 1.x hingga 2.15 | Dukungan Max Shard untuk Elasticsearch dan OpenSearch Layanan 1.x hingga 2.15 | Dukungan Max Node untuk OpenSearch Layanan 2.17 dan di atasnya | Dukungan Max Shard untuk OpenSearch Layanan 2.17 dan di atasnya |
| --- | --- | --- | --- | --- |
| 2 GB | Tidak berlaku | Tidak berlaku | 10 | 1K |
| 4 GB | Tidak berlaku | Tidak berlaku | 10 | 5K |
| 8GB | 10 | 10K | 30 | 15K |
| 16GB | 30 | 30K | 60 | 30K |
| 32 GB | 75 | 40K | 120 | 60K |
| 64GB | 125 | 75K | 240 | 120K |
| 128GB | 200 | 75K | 480 | 240K |
| 256GB | Tidak berlaku | Tidak berlaku | 1002 | 500K |
**Multi-AZ dengan ukuran node master Standby: ** Saat menggunakan Multi-AZ dengan Standby, tiga node master khusus secara otomatis disediakan di tiga Zona Ketersediaan. Untuk penerapan siaga, gunakan rekomendasi ukuran yang sama seperti di atas tetapi pastikan bahwa jenis instance node master memiliki RAM yang cukup untuk mengelola jumlah pecahan yang diharapkan di semua AZ. Misalnya, cluster dengan 60 node data dan 40.000 pecahan dalam konfigurasi siaga harus menggunakan node master khusus dengan setidaknya 32 GB RAM (seperti `r6g.xlarge.search` atau`m6g.2xlarge.search`).