FAQ Amazon OpenSearch Service

Ya. Anda dapat membuat domain Amazon OpenSearch Service baru dengan Domain Creation Wizard di konsol hanya dengan beberapa klik. Saat membuat domain baru, Anda dapat menentukan jumlah instans, jenis instans, dan volume EBS yang ingin Anda alokasikan ke domain Anda. Anda juga dapat memodifikasi atau menghapus domain Amazon OpenSearch Service yang ada menggunakan konsol.

Ya, Amazon OpenSearch Service terintegrasi dengan Amazon VPC. Saat memilih akses VPC, alamat IP dari VPC Anda dilampirkan ke domain Amazon OpenSearch Service Anda dan semua lalu lintas jaringan tetap berada dalam jaringan AWS dan tidak dapat diakses ke Internet. Selain itu, Anda dapat menggunakan grup keamanan dan kebijakan IAM untuk membatasi akses ke domain Amazon OpenSearch Service Anda.

Ya. AWS CloudFormation mendukung Amazon OpenSearch Service. Untuk informasi selengkapnya, lihat dokumentasi Referensi Templat CloudFormation.

Ya. Anda dapat mengonfigurasi node master khusus untuk domain Anda. Saat memilih konfigurasi master khusus, Anda dapat menentukan jenis instans dan jumlah instans.

Ya. Anda dapat membuat beberapa indeks Elasticsearch atau OpenSearch dalam domain Amazon OpenSearch Service yang sama. Elasticsearch dan OpenSearch secara otomatis mendistribusikan indeks dan replika terkait antara instance yang dialokasikan ke domain.

Amazon OpenSearch Service mendukung tiga opsi untuk penyerapan data:

• Untuk volume data yang besar, kami merekomendasikan Amazon Kinesis Data Firehose, layanan terkelola sepenuhnya yang secara otomatis menskalakan agar sesuai dengan throughput data Anda dan tidak memerlukan administrasi berkelanjutan. Itu juga dapat mengubah, mengelompokkan, dan mengompresi data sebelum memuatnya.
• Amazon OpenSearch Service mendukung integrasi dengan Logstash. Anda dapat mengonfigurasi domain Amazon OpenSearch Service sebagai penyimpanan data untuk semua log yang datang dari implementasi Logstash Anda.
• Anda dapat menggunakan Elasticsearch asli (hingga versi 7.10) atau API OpenSearch, seperti API indeks dan massal, untuk memuat data ke domain Anda.

Ya. Amazon OpenSearch Service mendukung integrasi dengan Logstash. Anda dapat mengatur domain Amazon OpenSearch Service sebagai penyimpanan backend untuk semua log yang masuk melalui implementasi Logstash Anda. Anda dapat mengatur kontrol akses di domain Amazon OpenSearch Service untuk menggunakan penandatanganan permintaan untuk mengautentikasi panggilan dari implementasi Logstash Anda, atau menggunakan kebijakan IAM berbasis sumber daya untuk menyertakan alamat IP instans yang menjalankan implementasi Logstash Anda.

Ya. Amazon OpenSearch Service menawarkan kemampuan visualisasi yang didukung oleh OpenSearch Dashboards dan Kibana (versi 1.5 hingga 7.10).

Anda dapat memilih antara penyimpanan instans lokal atau volume EBS. Selama pembuatan domain, jika Anda memilih penyimpanan EBS, Anda dapat menambah dan mengurangi ukuran volume penyimpanan seperlunya.

Anda dapat memilih antara volume Magnetic, General Purpose, dan Provisioned IOPS EBS.

Ya. Amazon OpenSearch Service men-deploy penyimpanan berdasarkan pilihan instans dan/atau ukuran volume EBS terkait. Penyimpanan maksimum per simpul adalah 24 TB dengan instans R6g.12xlarge dengan penyimpanan EBS gp3. Dengan maksimum default 80 simpul data yang diizinkan per domain Amazon OpenSearch Service, Anda dapat mengalokasikan sekitar 1920 TB penyimpanan ke satu domain. Anda dapat meminta peningkatan batas layanan hingga 200 instans per domain dengan membuat kasus menggunakan Pusat Dukungan AWS. Dengan 200 instans, Anda dapat mengalokasikan sekitar 3 PB penyimpanan ke satu domain.

Jika Anda men-deploy instans data di satu AZ, instans utama khusus Anda juga di-deploy di AZ yang sama. Namun, jika Anda men-deploy instans data di dua atau tiga AZ, Amazon OpenSearch Service secara otomatis mendistribusikan instans utama khusus di tiga AZ. Pengecualian untuk aturan ini terjadi jika suatu wilayah hanya memiliki dua AZ atau jika Anda memilih jenis instans generasi lama untuk instans master yang tidak tersedia di semua AZ. Untuk detail selengkapnya, lihat dokumentasi kami.

Untuk beban kerja produksi, sebaiknya lakukan deploy instans data Anda di tiga AZ karena menghadirkan ketersediaan yang lebih baik. Selain itu, kami merekomendasikan penyediaan instans dalam kelipatan tiga untuk distribusi yang sama di seluruh AZ. Di wilayah di mana tiga AZ tidak tersedia, sebaiknya gunakan dua deployment AZ dengan jumlah instans data genap. Dalam semua kasus, kami menyarankan untuk menyediakan tiga instans master khusus.

Anda bisa mengaktifkan tiga deployment AZ untuk domain yang ada dan baru menggunakan konsol AWS, CLI, atau SDK. Untuk detail selengkapnya, lihat dokumentasi kami.

Tidak. Amazon OpenSearch Service tidak mengenakan biaya apa pun untuk mengaktifkan tiga penerapan AZ. Anda hanya membayar jumlah instans di domain Anda, bukan jumlah AZ tempat mereka diterapkan.

Semua domain yang dikonfigurasi untuk beberapa AZ akan mengaktifkan kesadaran zona untuk memastikan pecahan didistribusikan di seluruh Availability Zone. Di konsol, Anda sekarang dapat secara eksplisit memilih dua atau tiga penerapan AZ. Domain yang sebelumnya dikonfigurasi dengan "Zone Awareness" akan terus diterapkan di dua AZ kecuali jika dikonfigurasi ulang. Untuk detail selengkapnya, lihat dokumentasi kami.

Jika satu atau beberapa instans di AZ tidak dapat dijangkau atau tidak berfungsi, Amazon OpenSearch Service secara otomatis mencoba memunculkan instans baru di AZ yang sama untuk menggantikan instans yang terpengaruh. Dalam kejadian langka di mana instans baru tidak dapat ditampilkan di AZ, Amazon OpenSearch Service memunculkan instans baru di AZ lain yang tersedia jika domain telah dikonfigurasi untuk menerapkan instans di beberapa AZ. Setelah masalah AZ teratasi, Amazon OpenSearch Service menyeimbangkan ulang instans sedemikian rupa sehingga mereka didistribusikan secara merata di seluruh AZ yang dikonfigurasi untuk domain. Untuk detail selengkapnya lihat dokumentasi kami.

Bahkan saat Anda mengonfigurasi satu replika, kami merekomendasikan tiga AZ. Jika gangguan AZ terjadi di tiga domain AZ, Anda hanya kehilangan sepertiga dari kapasitas Anda tetapi jika gangguan terjadi di dua domain AZ, Anda kehilangan setengah kapasitas, yang bisa lebih mengganggu. Selain itu, dalam tiga domain AZ, saat AZ terganggu, Amazon OpenSearch Service dapat melakukan fallback ke dua AZ yang tersisa, dan masih mendukung replikasi lintas AZ. Dalam dua domain AZ, Anda kehilangan replikasi lintas-AZ jika satu AZ terganggu, yang selanjutnya dapat mengurangi ketersediaan. Untuk detail selengkapnya lihat dokumentasi kami.

Jumlah AZ yang diterapkan domain Anda sesuai dengan jumlah subnet yang telah Anda konfigurasikan untuk domain VPC Anda. Anda perlu mengonfigurasi setidaknya tiga subnet di domain VPC Anda untuk mengaktifkan tiga penerapan AZ. Untuk detail selengkapnya tentang mengonfigurasi VPC, lihat dokumentasi kami.

Ya. Program dengan akses Internet publik dapat mengakses domain Amazon OpenSearch Service melalui titik akhir publik. Jika pusat data Anda sudah terhubung ke Amazon VPC melalui Direct Connect atau tunneling SSH, Anda juga dapat menggunakan akses VPC. Dalam kedua kasus tersebut, Anda dapat mengonfigurasi kebijakan IAM dan grup keamanan untuk mengizinkan program yang berjalan di server di luar AWS untuk mengakses domain Amazon OpenSearch Service Anda. Klik di sini untuk informasi selengkapnya tentang permintaan yang ditandatangani.

Untuk memigrasikan data dari klaster Elasticsearch atau OpenSearch yang ada, Anda harus membuat snapshot dari klaster yang ada, dan menyimpan snapshot di bucket Amazon S3 Anda. Kemudian Anda dapat membuat domain Amazon OpenSearch Service baru dan memuat data dari snapshot ke domain Amazon OpenSearch Service yang baru dibuat menggunakan restore API.

Amazon OpenSearch Service memungkinkan Anda mengontrol penskalaan domain Amazon OpenSearch Service menggunakan konsol, API, dan CLI. Anda dapat menskalakan domain Amazon OpenSearch Service dengan menambahkan, menghapus, atau memodifikasi instans atau volume penyimpanan bergantung pada kebutuhan aplikasi Anda. Amazon OpenSearch Service terintegrasi dengan Amazon CloudWatch untuk menyediakan metrik tentang status domain Amazon OpenSearch Service agar Anda dapat membuat keputusan penskalaan yang sesuai untuk domain Anda.

Tidak. Menskalakan domain Amazon OpenSearch Service Anda dengan menambahkan atau memodifikasi instans, dan volume penyimpanan adalah operasi online yang tidak memerlukan downtime apa pun.

Ya. Jika Anda mengaktifkan replika untuk indeks OpenSearch/Elasticsearch dan menggunakan beberapa Availability Zone, Amazon OpenSearch Service secara otomatis mendistribusikan pecahan utama dan replika Anda di seluruh instans di AZ yang berbeda.

Ya. Amazon OpenSearch Service memaparkan beberapa metrik kinerja melalui Amazon CloudWatch termasuk jumlah node, kesehatan cluster, dokumen yang dapat dicari, metrik EBS (jika berlaku), CPU, memori, dan pemanfaatan disk untuk data dan node master. Silakan merujuk ke dokumentasi layanan untuk daftar lengkap metrik CloudWatch yang tersedia.

Ya. AWS CloudTrail adalah layanan web yang merekam panggilan API AWS untuk akun Anda dan mengirimkan file log kepada Anda. Riwayat panggilan API AWS yang dihasilkan oleh AWS CloudTrail memungkinkan analisis keamanan, pelacakan perubahan sumber daya, dan audit kepatuhan. Pelajari selengkapnya tentang AWS CloudTrail di halaman detail AWS CloudTrail, dan mengaktifkannya melalui halaman beranda Konsol Manajemen AWS CloudTrail.

Snapshot adalah salinan domain Amazon OpenSearch Service Anda pada suatu saat.

Membuat snapshot dapat berguna jika terjadi kehilangan data yang disebabkan oleh kegagalan node, serta kemungkinan kegagalan perangkat keras. Anda dapat menggunakan snapshot untuk memulihkan domain Amazon OpenSearch Service Anda dengan data yang dimuat sebelumnya atau untuk membuat domain Amazon OpenSearch Service baru dengan data yang dimuat sebelumnya. Alasan umum lainnya untuk menggunakan cadangan adalah untuk tujuan pengarsipan. Snapshot disimpan di Amazon S3.

Ya. Secara default, Amazon OpenSearch Service secara otomatis membuat snapshot per jam dari setiap domain Amazon OpenSearch Service dan menyimpannya selama 14 hari.

Amazon OpenSearch Service akan mempertahankan snapshot otomatis per jam selama 14 hari terakhir.

Tidak ada biaya tambahan untuk snapshot otomatis per jam. Snapshot disimpan secara gratis di bucket Amazon OpenSearch Service S3 dan akan tersedia untuk tujuan pemulihan node.

Ya. Anda dapat menggunakan snapshot API untuk membuat snapshot manual tambahan selain snapshot otomatis harian yang dibuat oleh Amazon OpenSearch Service. Snapshot manual disimpan di bucket S3 Anda dan akan dikenakan biaya penggunaan Amazon S3 yang relevan.

Ya. Pelanggan dapat membuat domain Amazon OpenSearch Service baru dan memuat data dari snapshot ke domain Amazon OpenSearch Service yang baru dibuat menggunakan API pemulihan OpenSearch/Elasticsearch.

Snapshot harian yang disimpan oleh Amazon OpenSearch Service akan dihapus sebagai bagian dari penghapusan domain. Sebelum menghapus domain, Anda harus mempertimbangkan untuk membuat snapshot domain di bucket S3 Anda sendiri menggunakan proses snapshot manual. Snapshot yang disimpan di bucket S3 Anda tidak akan terpengaruh jika Anda menghapus domain Amazon OpenSearch Service Anda.

Amazon OpenSearch Service memaparkan tiga log Elasticsearch atau OpenSearch melalui Amazon CloudWatch Logs: log kesalahan, log lambat pencarian, dan log lambat indeks. Log ini berguna untuk pemecahan masalah kinerja dan masalah stabilitas dengan domain seseorang.

Log lambat adalah file log yang membantu melacak kinerja berbagai tahapan dalam suatu operasi. OpenSearch dan Elasticsearch memperlihatkan dua jenis log lambat:

• Indeks Lambat Log – Log ini memberikan wawasan tentang proses pengindeksan dan dapat digunakan untuk menyempurnakan pengaturan indeks.
• Cari Log Lambat – Log ini memberikan wawasan tentang seberapa cepat atau lambat kinerja kueri dan pengambilan. Log ini membantu menyempurnakan kinerja segala jenis operasi pencarian di OpenSearch atau Elasticsearch.

Untuk detail lengkap tentang log lambat, silakan merujuk ke dokumentasi OpenSearch.

Log lambat dapat diaktifkan melalui klik tombol dari Konsol atau melalui CLI dan API kami. Untuk detail selengkapnya silakan lihat dokumentasi kami.

Ya. Anda dapat memperbarui pengaturan untuk indeks tertentu untuk mengaktifkan atau menonaktifkan log lambat untuk itu. Untuk detail selengkapnya lihat dokumentasi kami.

Tidak. Mengaktifkan log lambat di Amazon OpenSearch Service memungkinkan opsi untuk memublikasikan log yang dihasilkan ke Amazon CloudWatch Logs untuk indeks di domain yang diberikan. Namun, untuk menghasilkan log Anda harus memperbarui pengaturan untuk satu atau lebih indeks untuk memulai proses logging. Untuk detail selengkapnya tentang pengaturan konfigurasi indeks untuk mengaktifkan log lambat, silakan lihat dokumentasi kami.

Tidak. Pembuatan file log bergantung pada pengaturan indeks. Untuk mematikan pembuatan file log, Anda harus memperbarui konfigurasi indeks. Untuk detail selengkapnya tentang pengaturan konfigurasi indeks untuk mengaktifkan log lambat, lihat dokumentasi kami.

Anda hanya dapat mengubah perincian logging untuk log yang lambat. OpenSearch dan Elasticsearch mengekspos beberapa level logging untuk log yang lambat. Anda perlu mengatur level yang sesuai dalam konfigurasi file index. Untuk detail selengkapnya tentang pengaturan konfigurasi indeks untuk mengaktifkan log lambat, silakan lihat dokumentasi OpenSearch.

Saat log lambat atau log kesalahan diaktifkan, Amazon OpenSearch Service mulai memublikasikan log yang dihasilkan ke CloudWatch Logs. Amazon OpenSearch Service tidak mengenakan biaya apa pun untuk mengaktifkan log. Namun, biaya CloudWatch standar akan berlaku.

OpenSearch menggunakan Apache Log4j 2 dan tingkat log bawaannya (dari yang paling kecil hingga yang paling besar) untuk TRACE, DEBUG, INFO, WARN, ERROR, dan FATAL. Jika Anda mengaktifkan log kesalahan, Amazon OpenSearch Service menerbitkan baris log WARN, ERROR, dan FATAL, dan memilih kesalahan dari tingkat DEBUG ke CloudWatch. Untuk detail selengkapnya, lihat dokumentasi kami.

Log kesalahan dapat diaktifkan melalui klik tombol dari AWS Console atau melalui CLI dan API kami. Untuk detail selengkapnya silakan lihat dokumentasi kami.

Tidak, log kesalahan diekspos untuk seluruh domain. Artinya, setelah diaktifkan, entri log dari semua indeks di domain akan tersedia.

Tidak, log kesalahan hanya tersedia untuk Elasticsearch versi 5.x ke atas.

Ya. Setiap entri log yang dibuat ke CloudWatch akan dibatasi hingga 255.000 karakter. Jika entri log Anda lebih besar dari itu, entri tersebut akan dipotong menjadi 255.000 karakter.

Log lambat hanya diperlukan saat Anda ingin memecahkan masalah indeks atau menyempurnakan kinerja. Pendekatan yang disarankan adalah hanya mengaktifkan logging untuk indeks yang memerlukan wawasan kinerja tambahan. Selain itu, setelah penyelidikan selesai, Anda harus mematikan pencatatan sehingga Anda tidak dikenakan biaya tambahan apa pun karenanya. Untuk detail selengkapnya, lihat dokumentasi.

CloudWatch menawarkan banyak cara untuk menggunakan log. Anda dapat melihat data log, mengekspornya ke S3, atau memprosesnya dalam waktu nyata. Untuk mempelajari lebih lanjut, lihat panduan pengembang CloudWatch Logs.

Ya, log lambat dapat diaktifkan untuk semua versi OpenSearch dan Elasticsearch yang didukung oleh Amazon OpenSearch Service. Namun, ada sedikit perbedaan dalam cara pengaturan log dapat ditentukan untuk setiap versi Elasticsearch. Silakan lihat dokumentasi kami untuk detail selengkapnya.

Tidak. Tidak akan ada waktu henti operasional. Setiap kali status log diperbarui, kami akan menerapkan cluster baru di latar belakang dan mengganti cluster yang ada dengan yang baru. Proses ini tidak akan menyebabkan waktu henti operasional. Namun, karena cluster baru disebarkan, pembaruan ke status log tidak akan instan.

Amazon OpenSearch Service saat ini mendukung peningkatan versi di tempat untuk domain dengan versi OpenSearch atau Elasticsearch versi 5.x dan yang lebih baru. Versi target yang kami dukung untuk pemutakhiran adalah 5.6, 6.3, 6.4, 6.5, 6.7, 6.8, 7.1, 7.4, 7.7, 7.8, 7.9, dan 7.10. Untuk detail selengkapnya, bacalah dokumentasi kami.

Silakan lihat dokumentasi kami untuk detail tentang migrasi dari berbagai versi Elasticsearch.

Tidak. Domain Anda tetap tersedia selama proses peningkatan versi. Namun, bagian dari proses peningkatan melibatkan relokasi pecahan, yang dapat memengaruhi kinerja domain. Sebaiknya tingkatkan versi saat beban di domain Anda rendah.

Peningkatan versi di tempat hanya tersedia untuk domain yang menjalankan Elasticsearch 5.x dan yang lebih baru. Jika domain Anda adalah versi 5.x atau lebih tinggi, Anda dapat menjalankan pemeriksaan kelayakan peningkatan untuk memvalidasi apakah domain Anda dapat ditingkatkan ke versi yang diinginkan. Silakan lihat dokumentasi kami untuk mempelajari selengkapnya.

Untuk daftar detail pengujian yang kami jalankan untuk memvalidasi kelayakan peningkatan, silakan lihat dokumentasi kami.

Tidak. Setelah pemutakhiran versi di tempat telah dipicu, Anda tidak dapat membuat perubahan pada konfigurasi domain sampai pemutakhiran selesai atau gagal. Anda dapat terus membaca dan menulis data saat peningkatan sedang berlangsung. Selain itu, Anda dapat menghapus domain, dalam hal ini pemutakhiran dihentikan dan domain dihapus.

Proses upgrade versi secara otomatis mengambil snapshot dari sistem dan hanya memulai upgrade yang sebenarnya jika snapshot berhasil. Jika peningkatan sedang berlangsung saat waktu mulai snapshot otomatis tercapai, snapshot otomatis dilewati untuk hari itu dan dilanjutkan pada hari berikutnya.

Amazon OpenSearch Service menjalankan serangkaian pengujian sebelum memicu pemutakhiran untuk memeriksa masalah umum yang dapat memblokir pemutakhiran. Jika tidak ada masalah yang ditemukan, layanan mengambil snapshot domain dan memulai proses upgrade jika snapshot berhasil. Upgrade tidak dipicu jika ada masalah yang dihadapi dengan salah satu langkah.

Jika masalah yang ditemui kecil dan dapat diperbaiki, Amazon OpenSearch Service secara otomatis mencoba mengatasinya dan membuka blokir pemutakhiran. Namun, jika masalah memblokir pemutakhiran, layanan akan kembali ke snapshot yang diambil sebelum pemutakhiran dan mencatat kesalahan. Untuk detail selengkapnya tentang melihat log dari kemajuan peningkatan versi, silakan lihat dokumentasi kami.

Ya. Anda dapat melihat log pemutakhiran dari konsol AWS atau memintanya menggunakan CLI atau SDK. Silakan lihat dokumentasi kami untuk detail selengkapnya.

Tidak. Setelah pemutakhiran dipicu, itu tidak dapat dijeda atau dibatalkan hingga selesai atau gagal.

Ya. Namun, jika Anda ingin mempertahankan semua domain Anda pada versi yang sama, sebaiknya jalankan pemeriksaan kelayakan peningkatan pada semua domain sebelum meningkatkannya. Langkah ekstra ini dapat membantu mengatasi masalah dengan satu domain yang mungkin tidak ada di domain lain.

Bergantung pada jumlah data dan ukuran kluster, pemutakhiran dapat memakan waktu mulai dari beberapa menit hingga beberapa jam untuk diselesaikan.

Tidak. Dengan pemutakhiran versi di tempat, semua data di klaster Anda juga dipulihkan sebagai bagian dari proses pemutakhiran. Jika Anda hanya ingin memutakhirkan domain saja, Anda dapat mengambil snapshot data Anda, menghapus semua indeks Anda dari domain, lalu memicu pemutakhiran versi di tempat. Atau, Anda dapat membuat domain terpisah dengan versi yang lebih baru, lalu memulihkan data Anda ke domain tersebut.

Tidak. Jika Anda perlu menurunkan versi ke versi yang lebih lama, hubungi AWS Support untuk memulihkan snapshot pra-peningkatan otomatis pada domain baru. Jika mengambil snapshot manual dari domain asli, Anda dapat melakukan langkah ini sendiri.

Multi-AZ dengan Siaga adalah opsi deployment baru untuk Amazon OpenSearch Service yang memungkinkan ketersediaan tinggi dan performa yang konsisten untuk beban kerja yang sangat penting bagi bisnis. Dengan Multi-AZ dengan Siaga, klaster terkelola OpenSearch Service tangguh terhadap kegagalan infrastruktur seperti penurunan simpul, atau kegagalan satu Zona Ketersediaan, memastikan tidak ada dampak terhadap performa atau ketersediaan, bahkan jika terjadi kegagalan satu Zona Ketersediaan. Multi-AZ dengan Siaga memberikan manfaat tambahan untuk menyederhanakan konfigurasi dan manajemen klaster dengan menerapkan praktik terbaik dan mengurangi kompleksitas.

Untuk mengaktifkan Multi-AZ dengan Siaga, klaster terkelola harus memenuhi ketentuan berikut:

• Menjalankan OpenSearch 1.3 atau versi yang lebih baru.
• Melakukan deployment di Wilayah AWS dengan 3-AZ. Saat ini, wilayah California Utara AWS tidak mendukung 3-AZ dan oleh karena itu tidak cocok untuk Multi-AZ dengan Siaga.
• Jumlah simpul data harus dalam kelipatan tiga.
• Jumlah salinan data (primer + replika) harus dalam kelipatan tiga.
• Ikuti panduan ukuran untuk pemimpin (ukuran yang disarankan berdasarkan jumlah simpul, jumlah serpihan, dan jumlah pemetaan di klaster Anda).

Dengan Multi-AZ dengan Siaga, Amazon OpenSearch Service mendeteksi dan secara otomatis memulihkan dari beberapa kegagalan infrastruktur. Amazon OpenSearch Service secara otomatis mengalihkan simpul aktif ke siaga dalam waktu kurang dari satu menit ketika salah satu peristiwa berikut terjadi:

• Hilangnya satu AZ aktif atau semua simpul dalam AZ aktif
• Hilangnya konektivitas ke satu AZ aktif
• Kegagalan perangkat keras instans di AZ aktif
• Kegagalan penyimpanan pada simpul di AZ aktif

Saat ini Multi-AZ dengan Siaga tidak mencakup peristiwa berikut:

• Hilangnya Quorum master, karena pemulihan dari peristiwa ini bisa berlangsung selama beberapa menit
• Hilangnya beberapa Zona Ketersediaan
• Hilangnya konektivitas ke suatu Wilayah
• Hilangnya lebih dari 50% simpul di lebih dari satu AZ
• Downtime yang disebabkan karena komputasi atau penyimpanan yang tidak mencukupi sebagai akibat dari perubahan karakteristik beban kerja
• Downtime yang disebabkan kueri yang membingungkan
• Hilangnya satu atau beberapa layanan yang bergantung pada Amazon OpenSearch Service seperti ARPS dan ALB
• Downtime OpenSearch Dashboard selama peningkatan versi

Tidak. Pada prinsipnya, panduan ukuran tetap sama. Multi-AZ dengan Siaga memiliki prasyarat yang menyederhanakan model mental yang diperlukan untuk mengukur klaster. Cara mengira-ngira ukuran untuk klaster terkelola adalah bahwa Anda harus melihat kapasitas yang diperlukan untuk layanan beban kerja Anda, lalu menambahkan 50% untuk redundansi. Perbedaan utama antara opsi ‘Zone Awareness’ saat ini dan opsi Multi-AZ dengan Siaga adalah bagaimana kapasitas redundan atau tambahan ditangani untuk mempertahankan ketersediaan. Multi-AZ dengan Siaga mengharuskan Anda memiliki setidaknya satu salinan data di setiap AZ, sehingga Multi-AZ dengan Siaga dapat secara eksplisit menyimpan kapasitas dalam satu AZ sebagai siaga. Kapasitas siaga ini bertindak sebagai target failover selama gangguan AZ atau kegagalan instans. Model yang ada mengharuskan Anda mempertahankan tingkat sumber daya yang optimal untuk menyediakan beban kerja Anda. Anda akan terus memantau klaster Anda untuk masalah ukuran dan mengambil tindakan korektif saat karakteristik beban kerja berubah.

Tidak. Amazon OpenSearch Service bekerja pada model tanggung jawab bersama. Anda bertanggung jawab untuk memastikan bahwa klaster Anda berukuran sesuai dengan beban kerja Anda. Multi-AZ dengan Siaga menjadikan model mental penyiapan klaster Anda sederhana. Anda harus terus memantau metrik kesalahan dan latensi beserta penggunaan penyimpanan, CPU, dan RAM untuk sinyal bahwa klaster kelebihan beban dan mungkin perlu diskalakan.

Tidak. Fitur Multi-AZ dengan Siaga tersedia tanpa biaya tambahan. Anda terus membayar sumber daya yang digunakan di klaster untuk menyediakan beban kerja Anda. Jika klaster Anda sudah mengikuti praktik terbaik dan memiliki setidaknya tiga salinan data untuk klaster 3-AZ, Anda tidak mungkin dikenakan biaya tambahan untuk pindah ke Multi-AZ dengan Siaga. Namun, jika klaster Anda berukuran kecil atau tidak memiliki kapasitas redundan yang cukup untuk menyediakan beban kerja Anda, Anda perlu menambahkan kapasitas untuk pindah ke Multi-AZ dengan Siaga untuk meningkatkan ketersediaan dan performa. Kapasitas siaga dicadangkan dari total kapasitas yang dikonfigurasi.

SLA Amazon OpenSearch Service kami menjamin Persentase Uptime Bulanan setidaknya 99,9% untuk Amazon OpenSearch Service.

Anda memenuhi syarat untuk kredit SLA untuk Amazon OpenSearch Service di bawah SLA Amazon OpenSearch Service jika domain multi-AZ di Amazon OpenSearch Service memiliki Persentase Waktu Aktif Bulanan kurang dari 99,9% selama siklus penagihan bulanan.

Untuk detail selengkapnya tentang syarat dan ketentuan SLA, serta detail tentang cara mengajukan klaim, silakan lihat halaman detail SLA Amazon OpenSearch Service.

Pencarian lintas klaster adalah fitur Elasticsearch dan OpenSearch yang memungkinkan melakukan kueri dan agregasi di dua klaster terhubung. Pencarian lintas klaster bekerja dengan menyiapkan koneksi satu arah yang ringan antara klaster yang berpartisipasi.

Domain yang berpartisipasi dalam pencarian lintas cluster harus memenuhi kriteria berikut:

• Domain yang berpartisipasi harus ada di OpenSearch atau Elasticsearch versi 6.8 ke atas
• Domain yang berpartisipasi harus mengaktifkan enkripsi saat transit
• Domain yang berpartisipasi harus mengaktifkan Kontrol Akses Berbutir Halus (FGAC)
• Versi domain yang berpartisipasi harus mematuhi aturan yang sama seperti peningkatan versi bergulir

Pencarian lintas-cluster saat ini didukung pada jenis contoh berikut:

• Keluarga i2, i3
• Keluarga r3, r4, r5
• Keluarga m4, m5
• Keluarga c4, c5
• Keluarga Graviton

Pencarian lintas-cluster tidak didukung pada instans keluarga t2 dan m3 karena keterbatasan teknis.

Ya. Domain yang berpartisipasi dapat dimiliki oleh dua akun AWS yang berbeda.

Ya.

Untuk mulai menggunakan pencarian lintas klaster, ikuti dokumentasi di sini.

Replikasi lintas klaster, kemampuan baru yang mengizinkan pelanggan Amazon OpenSearch Service untuk mengotomatisasi penyalinan dan sinkronisasi indeks dari satu klaster ke klaster lain dengan latensi rendah di Wilayah AWS yang sama atau berbeda.

Domain yang berpartisipasi dalam replikasi lintas klaster harus memenuhi kriteria berikut:

• Domain yang berpartisipasi harus ada di Elasticsearch versi 7.10
• Domain yang berpartisipasi harus mengaktifkan enkripsi saat transit
• Domain yang berpartisipasi harus mengaktifkan Kontrol Akses Berbutir Halus (FGAC)
• Versi domain yang berpartisipasi harus mematuhi aturan yang sama seperti peningkatan versi bergulir

Ya, domain di dua Wilayah AWS yang berbeda dapat berpartisipasi dalam replikasi lintas klaster.

Tidak. Implementasi replikasi lintas klaster saat ini tidak mendukung Ultrawarm atau Cold Storage.

Ya. Anda harus membayar biaya transfer data AWS standar untuk data yang ditransfer ke dalam dan ke luar dari Amazon OpenSearch Service.

Kami mengumumkan proyek OpenSearch, fork open source berbasis komunitas dari Elasticsearch dan Kibana, pada 12 April 2021. Kami berkomitmen untuk melakukan investasi jangka panjang di OpenSearch untuk memastikan pengguna terus memiliki rangkaian analitik dan pencarian sumber terbuka yang aman, berkualitas tinggi, dengan peta jalan yang kaya akan fungsionalitas baru dan inovatif. Proyek ini mencakup OpenSearch (berasal dari Elasticsearch 7.10.2) dan OpenSearch Dashboards (berasal dari Kibana 7.10.2). Kami meluncurkan OpenSearch versi 1.0 pada 12 Juli 2021. Sebagai bagian dari komitmen jangka panjang kami terhadap OpenSearch, kami menambahkan dukungan untuk OpenSearch 1.0 pada layanan terkelola pada 7 September 2021 dan mengubah nama dari Amazon Elasticsearch Service menjadi Amazon OpenSearch Service. Bersama dengan OpenSearch 1.0, kami terus mendukung versi Elasticsearch lama hingga 7.10 pada layanan. Selain perubahan nama, Anda dapat yakin bahwa kami akan terus memberikan pengalaman hebat yang sama tanpa berdampak pada operasi yang sedang berlangsung, metodologi pengembangan, atau penggunaan bisnis. Pelajari selengkapnya tentang OpenSearch di sini: https://opensearch.org

Kami telah berusaha untuk membuat perubahan nama ini semulus mungkin untuk Anda. Ada beberapa aspek, seperti SDK/API konfigurasi baru, yang memerlukan tindakan Anda untuk memastikan Anda mendapatkan manfaat terbaik dari layanan. Meskipun SDK yang ada akan terus berfungsi dari perspektif kompatibilitas, fungsionalitas baru apa pun yang memerlukan API konfigurasi baru hanya akan diterapkan di SDK baru. Oleh karena itu, sebaiknya Anda pindah ke SDK baru. Selain itu, terlepas dari SDK barunya, kami sangat menyarankan agar Anda memindahkan kebijakan IAM yang ada untuk menggunakan API konfigurasi yang telah diganti namanya. Mulai sekarang, kebijakan IAM Anda yang ada akan terus berfungsi dengan definisi API lama. Namun, kami akan beralih ke validasi izin berbasis API yang baru dan pada akhirnya kami akan meminta Anda untuk menggunakan API baru dalam kebijakan Anda (khusus untuk API di mana ada perubahan nama; misalnya CreateElasticsearchDomain ke CreateDomain). Bacalah dokumentasi untuk detail selengkapnya.

Tidak. Dari perspektif kompatibilitas mundur, kami akan memastikan bahwa penyiapan Anda yang ada terus berfungsi dengan OpenSearch 1.0. Namun, kami menyarankan Anda akhirnya pindah ke SDK terbaru untuk pengalaman yang lebih bersih dan terbaru, seperti yang disebutkan di atas.

Tidak. Tidak ada perubahan harga.

OpenSearch mencakup kode Elasticsearch tertentu yang berlisensi Apache dari Elasticsearch B.V. dan kode sumber lainnya. Elasticsearch B.V. bukan merupakan sumber dari kode sumber lain tersebut. ELASTICSEARCH adalah merek dagang terdaftar dari Elasticsearch B.V.

Meningkatkan ke OpenSearch 1.x memastikan infrastruktur pencarian Anda dibangun di atas proyek sumber terbuka Berlisensi Apache yang berkembang dan dinamis serta memberi Anda akses ke banyak peningkatan dan fitur inovatif yang tersedia di OpenSearch 1.2 (saat tulisan ini dibuat).  Fitur seperti keamanan tingkat perusahaan, pemberitahuan, manajemen siklus hidup data, observabilitas, deteksi anomali berbasis ML, dan lainnya adalah bagian dari OpenSearch Service, tanpa biaya lisensi tambahan.

Kami menggunakan proses deployment blue/green (BG) selama peningkatan. Selama BG, layanan menambahkan simpul ke klaster OpenSearch Service dalam konfigurasi dan versi baru, memigrasikan data dari simpul lama, dan menghapus simpul lama saat migrasi data selesai. Selama BG, API pencarian dan pengindeksan tersedia dan berfungsi secara normal. Meskipun BG dirancang untuk tidak mengganggu permintaan kueri dan pengindeksan, beberapa perubahan (terutama yang melibatkan perubahan pada pengaturan terkait keamanan) dapat menyebabkan dasbor tidak tersedia selama periode perubahan.

AWS memelihara 19 versi Elasticsearch berlisensi Apache-2.0. Tidak ada satu pun dari versi ini yang dihentikan atau direncanakan untuk dihentikan saat ini.

Ya, peningkatan akan memicu proses deployment BG. Harap tinjau persiapan dan langkah-langkah peningkatan di sini.

Harap bekerja sama dengan tim akun AWS untuk mendapatkan informasi berdasarkan situasi spesifik Anda dengan RI.

Proyek OpenSearch 1.0 adalah fork dari sumber terbuka Elasticsearch 7.10.2. ini kompatibel dengan Elasticsearch 7.10--Anda tidak perlu mengubah penggunaan. Untuk bermigrasi, Anda dapat meningkatkan domain ke versi Elasticsearch 7.10 dari versi sebelumnya dalam seri 6.x dan 7.x, mengambil snapshot, dan memulihkan snapshot tersebut ke domain yang menjalankan OpenSearch Service 1.x. Beberapa klien atau alat menyertakan pemeriksaan versi yang dapat menyebabkan klien atau alat tidak dapat digunakan dengan OpenSearch Service. Saat Anda meningkatkan, aktifkan mode kompatibilitas untuk mengatasi pemeriksaan versi ini.

Dalam kebanyakan kasus, Anda dapat terus menggunakan klien yang ada. API dan fungsionalitas pencarian inti kompatibel dengan Elasticsearch versi 7.10.2. Jika Anda memiliki klien yang lebih lama, klien yang melakukan pemeriksaan versi, atau klien yang memanfaatkan fungsionalitas yang ditargetkan ke versi Elasticsearch yang lebih lama seperti versi utama 5 atau 6, kami sarankan Anda mencoba membawa klien ke standar minimum dukungan pada versi 7.10.2 untuk memastikan transisi berjalan lancar.

Proyek OpenSearch mendukung berbagai klien yang secara khusus dibangun untuk menangani versi mesin OpenSearch di Amazon OpenSearch Service. Periksa klien Anda terhadap daftar klien OpenSearch terbaru dan bahasa pemrograman yang didukung untuk klien tersebut.

Anda dapat mengaktifkan fitur mode kompatibilitas untuk bekerja sama dengan klien dari vendor lain, tetapi ingat untuk memeriksa versi yang dilaporkan OpenSearch. Aktifkan pengaturan ini guna memastikan layanan merespons dengan versi 7.10.2 untuk klien yang dikembangkan sebelum pengenalan mesin OpenSearch Service.

Indeks Elasticsearch 5.x tidak kompatibel dengan Elasticsearch 7.10 atau OpenSearch 1.x. Anda harus membuat indeks baru dan memuat data dari sumber. Jika Anda menjalankan beban kerja analitik log, Anda dapat mengevaluasi apakah strategi retensi data mendukung untuk berjalan secara paralel saat membangun set data lengkap di domain baru.

Ya, silakan hubungi opensearchmigration-si-support@amazon.com untuk meminta daftar partner untuk wilayah, industri, dan kompleksitas proyek Anda. Partner Jaringan Partner AWS (APN) dilatih dan memiliki pengalaman untuk membantu Anda dengan peningkatan. 

OpenSearch 1.0 adalah fork dari Elasticsearch 7.10.2. OpenSearch dan Elasticsearch bersifat kompatibel. Jika Anda mengaktifkan mode kompatibilitas, klien Elasticsearch juga kompatibel dengan OpenSearch 1.0.

Amazon OpenSearch Service tidak dan tidak akan menawarkan versi mesin Elasticsearch setelah versi 7.10.2.

Seperti yang diumumkan AWS saat kami melakukan fork pada Elasticsearch, kami bermaksud untuk membangun, dan telah membangun komunitas yang berkembang seputar OpenSearch. Kami telah menerbitkan panduan untuk OpenSearch, lengkap dengan masukan dari komunitas dan konsensus tentang prioritas fitur. Kami akan melakukan segala upaya yang layak untuk menjaga kompatibilitas dengan Elasticsearch. Tujuan kami adalah berkembang bersama komunitas dan pelanggan Amazon OpenSearch Service.

Anda dapat langsung meningkatkan ke OpenSearch Service 1.0 dari Elasticsearch dan Kibana versi 6.8.0 ke 7.10.2, serta membuka distro untuk Elasticsearch (ODFE) 1.x. Untuk meningkatkan versi dari ODFE ke OpenSearch, kami merekomendasikan untuk terlebih dahulu meningkatkan ke ODFE 1.13, kemudian meningkatkan ke OpenSearch 1.0.

Sumber daya migrasi ada di sini:

Migrasi Analitik

Bermigrasi ke Amazon OpenSearch Service

Integrasi nol-ETL dengan Amazon DynamoDB menghilangkan kerumitan operasional dalam mengatur replikasi data dari penyimpanan data transaksional ke penyimpanan data pencarian. Pembuatan dan pengelolaan jalur data yang digunakan untuk menjaga sinkronisasi penyimpanan data yang berbeda bisa jadi menyulitkan dan mahal, serta sering mengalami kesalahan yang sulit dilacak. Integrasi ini dapat membantu pelanggan Amazon DynamoDB memperoleh hasil pencarian yang mendekati waktu nyata dari data transaksional mereka dengan menawarkan solusi terkelola penuh untuk membuat data operasional dari Amazon DynamoDB tersedia di Amazon OpenSearch Service dalam hitungan detik setelah ditulis.

Integrasi nol-ETL dari Amazon OpenSearch Service dengan Amazon DynamoDB menggunakan Amazon OpenSearch Ingestion untuk memindahkan data operasional dari Amazon DynamoDB ke Amazon OpenSearch Service dengan lancar. Untuk mengaktifkan integrasi, pelanggan terlebih dahulu memilih tabel Amazon DynamoDB yang datanya perlu direplikasi. Fitur integrasi nol-ETL ini mengatur jalur Amazon OpenSearch Ingestion di akun pelanggan yang menangani replikasi data ke klaster yang dikelola Amazon OpenSearch Service atau kumpulan nirserver. Amazon OpenSearch Ingestion memahami struktur tabel Amazon DynamoDB, lalu melakukan bootstrap pada klaster yang dikelola Amazon OpenSearch Service atau kumpulan nirserver dengan data yang ada pada tabel DynamoDB. Secara opsional, pelanggan dapat menentukan skema untuk indeks yang akan dibuat di Amazon OpenSearch Service. Pembaruan apa pun pada tabel DynamoDB juga direplikasi ke Amazon OpenSearch Service tanpa intervensi manual oleh pelanggan.

Fitur nol-ETL ini menggunakan Amazon OpenSearch Ingestion untuk memindahkan data dari Amazon DynamoDB ke Amazon OpenSearch Service dan memanfaatkan kemampuan transformasi data native dari jalur Amazon OpenSearch Ingestion untuk mengumpulkan dan memfilter data saat sedang bergerak. Saat memindahkan data dari tabel Amazon DynamoDB, pelanggan mungkin ingin menghapus beberapa kolom atau membuat kolom baru berdasarkan gabungan kolom yang sudah ada. Secara opsional, pelanggan juga dapat menulis logika kustom untuk Amazon OpenSearch Ingestion guna mencapai kemampuan transformasi yang dapat disesuaikan terlebih dahulu. Bagi pengguna lain, yang hanya ingin memindahkan seluruh data mereka dari sumber ke sink, Amazon OpenSearch Ingestion menyediakan cetak biru khusus sehingga mereka dapat melakukan integrasi hanya dengan beberapa klik tombol.

Untuk memastikan bahwa Amazon OpenSearch Ingestion memiliki izin yang diperlukan untuk mereplikasi data di kedua sistem ini, fitur integrasi nol-ETL membuat peran IAM dengan izin yang diperlukan untuk membaca data dari tabel Amazon DynamoDB dan menulis ke domain atau kumpulan Amazon OpenSearch. Peran ini kemudian diambil oleh jalur Amazon OpenSearch Ingestion untuk memastikan bahwa postur keamanan yang tepat selalu terjaga saat memindahkan data dari sumber ke tujuan.

Anda dapat melihat semua metrik yang terkait dengan integrasi nol-ETL Anda dengan Amazon DynamoDB di dasbor yang disediakan oleh Penyerapan Amazon OpenSearch bersama dengan log waktu nyata di Amazon CloudWatch. Hal ini memungkinkan pelanggan untuk mengatur peringatan khusus yang dipicu saat ambang batas yang ditentukan pengguna dilanggar.

Mesin kueri OpenSearch Service telah dirancang ulang untuk mendukung analisis data operasional yang disimpan di penyimpanan objek cloud, seperti Amazon S3 dan danau data berbasis S3. Hal ini dilakukan tanpa menduplikasi data. Saat detik membuat perbedaan, pelanggan dapat meningkatkan performa kueri mereka serta membuat dasbor pemuatan cepat menggunakan kemampuan akselerasi kueri bawaan integrasi yang baru.

Untuk memulai dari Konsol Manajemen AWS, pelanggan mengatur sumber data baru dari domain OpenSearch Service yang ada yang menjalankan OpenSearch Service versi 2.11 atau lebih tinggi. Saat mengatur sumber data Kueri Langsung yang baru, pelanggan perlu menyediakan akses baca/tulis ke Amazon S3 dan Katalog Data AWS Glue untuk memfasilitasi kueri data di Amazon S3 dari OpenSearch Service. Pelanggan dapat menyesuaikan kebijakan IAM untuk membatasi akses ke bucket tertentu di Amazon S3 atau sumber daya di Katalog Data AWS Glue. Setelah mengonfigurasi sumber data baru di konsol, pelanggan akan masuk ke OpenSearch Service untuk mengonfigurasi kontrol akses berbasis peran, akselerasi untuk mempercepat performa kueri, dan secara opsional dasbor khusus untuk templat tipe log yang populer, seperti Log Aliran VPC, Log Penyeimbang Beban Elastis, dan Log NGINX. Pelanggan ditagih untuk sumber daya komputasi yang digunakan dalam bentuk Unit Komputasi OpenSearch Kueri Langsung (OCU; tarif penggunaan akan berlaku). Setelah mengonfigurasi sumber data baru, pelanggan dapat mulai mengueri data mereka langsung dari API OpenSearch atau Dasbor OpenSearch.

Pelanggan hanya membayar sumber daya yang digunakan oleh beban kerja mereka. OpenSearch Service hanya mengenakan biaya untuk komputasi yang diperlukan untuk mengueri data eksternal secara langsung serta memelihara indeks opsional di OpenSearch Service. Kapasitas komputasi diukur dalam Unit Komputasi OpenSearch (OCU) yang merupakan unit yang sama yang digunakan oleh Amazon OpenSearch Nirserver dan Amazon OpenSearch Ingestion. Jumlah OCU berhubungan langsung dengan vCPU dan memori yang diperlukan untuk mengueri atau memelihara indeks berdasarkan data. Pelanggan akan melihat satu entri untuk komputasi dalam unit OCU-jam dengan label untuk kueri langsung. OCU ditagih setiap jam dengan granularitas per menit. Jika tidak ada kueri atau aktivitas pengindeksan yang aktif, tidak ada OCU yang digunakan. Biaya untuk Amazon S3 atau Katalog Data AWS Glue akan ditagih secara terpisah di akun pelanggan. Untuk detail harga selengkapnya kunjungi halaman harga Amazon OpenSearch Service.