Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Fitur yang mendukung ketersediaan tinggi di kluster EMR Amazon dan cara kerjanya dengan aplikasi sumber terbuka
Topik ini memberikan informasi tentang fitur ketersediaan tinggi Hadoop HDFS NameNode dan YARN di cluster EMR ResourceManager Amazon, dan bagaimana fitur ketersediaan tinggi bekerja dengan aplikasi open source dan fitur EMR Amazon lainnya.
## High-availability HDFS
Cluster EMR Amazon dengan beberapa node utama memungkinkan fitur ketersediaan HDFS NameNode tinggi di Hadoop. Untuk informasi lebih lanjut, lihat [ketersediaan tinggi HDFS](https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithNFS.html).
Dalam cluster EMR Amazon, dua atau lebih node terpisah dikonfigurasi sebagai. NameNodes Yang satu NameNode berada di `active` negara bagian dan yang lainnya dalam `standby` keadaan. Jika node `active` NameNode gagal, Amazon EMR memulai proses failover HDFS otomatis. Sebuah node dengan `standby` NameNode menjadi `active` dan mengambil alih semua operasi klien di cluster. Amazon EMR menggantikan node yang gagal dengan yang baru, yang kemudian bergabung kembali sebagai file. `standby`
**catatan**
Di Amazon EMR versi 5.23.0 hingga 5.36.2, hanya dua dari tiga node utama yang menjalankan HDFS. NameNode
Di Amazon EMR versi 6.x dan lebih tinggi, ketiga node utama menjalankan HDFS. NameNode
Jika Anda perlu mencari tahu yang NameNode mana`active`, Anda dapat menggunakan SSH untuk terhubung ke node utama apa pun di cluster dan menjalankan perintah berikut:
```
hdfs haadmin -getAllServiceState
```
Output mencantumkan node tempat NameNode diinstal dan statusnya. Misalnya,
```
ip-##-#-#-##1.ec2.internal:8020 active
ip-##-#-#-##2.ec2.internal:8020 standby
ip-##-#-#-##3.ec2.internal:8020 standby
```
## High-availability BENANG ResourceManager
Cluster EMR Amazon dengan beberapa node utama memungkinkan fitur ketersediaan ResourceManager tinggi YARN di Hadoop. Untuk informasi selengkapnya, lihat [ketersediaan ResourceManager tinggi](https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/ResourceManagerHA.html).
Dalam cluster EMR Amazon dengan beberapa node primer, YARN ResourceManager berjalan pada ketiga node utama. Satu ResourceManager dalam `active` keadaan, dan dua lainnya dalam `standby` keadaan. Jika node utama `active` ResourceManager gagal, Amazon EMR memulai proses failover otomatis. Sebuah node primer dengan `standby` ResourceManager mengambil alih semua operasi. Amazon EMR menggantikan simpul primer yang gagal dengan yang baru, yang kemudian bergabung kembali dengan kuorum sebagai. ResourceManager `standby`
Anda dapat terhubung ke “http://{{master-public-dns-name}}:8088/cluster" untuk node utama apa pun, yang secara otomatis mengarahkan Anda ke manajer `active` sumber daya. Untuk mengetahui manajer sumber daya mana`active`, gunakan SSH untuk terhubung ke node utama apa pun di cluster. Kemudian jalankan perintah berikut untuk mendapatkan daftar tiga node utama dan statusnya:
```
yarn rmadmin -getAllServiceState
```
## Aplikasi yang didukung di Amazon EMR Cluster dengan beberapa node utama
Anda dapat menginstal dan menjalankan aplikasi berikut di cluster EMR Amazon dengan beberapa node utama. Untuk setiap aplikasi, proses failover node primer bervariasi.
| Aplikasi | Ketersediaan selama failover node primer | Catatan |
| --- | --- | --- |
| Flink | Ketersediaan tidak terpengaruh oleh failover node primer | Tugas Flink di Amazon EMR dijalankan sebagai aplikasi YARN. Flink JobManagers dijalankan sebagai YARN ApplicationMasters pada node inti. JobManager Ini tidak terpengaruh oleh proses failover node primer.
Jika Anda menggunakan Amazon EMR versi 5.27.0 atau lebih lama, ini JobManager adalah satu titik kegagalan. Ketika JobManager gagal, ia kehilangan semua status pekerjaan dan tidak akan melanjutkan pekerjaan yang sedang berjalan. Anda dapat mengaktifkan ketersediaan JobManager tinggi dengan mengonfigurasi jumlah upaya aplikasi, pos pemeriksaan, dan mengaktifkan ZooKeeper sebagai penyimpanan status untuk Flink. Untuk informasi selengkapnya, lihat [Mengonfigurasi Flink di Cluster EMR Amazon dengan](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/flink-configure.html#flink-multi-master) beberapa node utama.
Dimulai dengan Amazon EMR versi 5.28.0, tidak diperlukan konfigurasi manual untuk mengaktifkan ketersediaan tinggi. JobManager |
| Ganglia | Ketersediaan tidak terpengaruh oleh failover node primer | Ganglia tersedia di semua node primer, sehingga Ganglia dapat terus berjalan selama proses failover node primer. |
| Hadoop | Ketersediaan yang tinggi | HDFS NameNode dan YARN ResourceManager secara otomatis gagal ke node siaga ketika node primer aktif gagal. |
| HBase | Ketersediaan tinggi | HBase secara otomatis gagal ke node siaga ketika node primer aktif gagal.
Jika Anda terhubung ke HBase melalui server REST atau Thrift, Anda harus beralih ke node primer yang berbeda ketika node primer aktif gagal. |
| HCatalog | Ketersediaan tidak terpengaruh oleh failover node primer | HCatalog dibangun di atas metastore Hive, yang ada di luar klaster. HCatalog tetap tersedia selama proses failover node utama. |
| JupyterHub | Ketersediaan tinggi | JupyterHub diinstal pada ketiga instance utama. Sangat disarankan untuk mengonfigurasi persistensi notebook untuk mencegah hilangnya notebook pada kegagalan node primer. Untuk informasi selengkapnya, lihat [Mengkonfigurasi persistensi notebook di Amazon S3](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-jupyterhub-s3.html). |
| Livy | Ketersediaan tinggi | Livy diinstal pada ketiga node utama. Ketika node primer aktif gagal, Anda kehilangan akses ke sesi Livy saat ini dan perlu membuat sesi Livy baru pada node primer yang berbeda atau pada node pengganti baru. |
| Mahout | Ketersediaan tidak terpengaruh oleh failover node primer | Karena Mahout tidak memiliki daemon, itu tidak terpengaruh oleh proses failover node utama. |
| MxNet | Ketersediaan tidak terpengaruh oleh failover node primer | Karena MXNet tidak memiliki daemon, itu tidak terpengaruh oleh proses failover node utama. |
| Phoenix | Ketersediaan Yang Tinggi | Phoenix' QueryServer berjalan hanya pada salah satu dari tiga node utama. Phoenix pada ketiga master dikonfigurasi untuk menghubungkan Phoenix QueryServer. Anda dapat menemukan IP pribadi server Phoenix Query dengan menggunakan file `/etc/phoenix/conf/phoenix-env.sh` |
| Babi | Ketersediaan tidak terpengaruh oleh failover node primer | Karena Babi tidak memiliki daemon, itu tidak terpengaruh oleh proses failover node primer. |
| Percikan | Ketersediaan tinggi | Semua aplikasi Spark berjalan dalam wadah YARN dan dapat bereaksi terhadap failover node primer dengan cara yang sama seperti fitur YARN ketersediaan tinggi. |
| Sqoop | Ketersediaan yang tinggi | Secara default, sqoop-job dan sqoop-metastore menyimpan data (deskripsi tugas) pada disk lokal utama yang menjalankan perintah, jika Anda ingin menyimpan data metastore di Basis Data eksternal, lihat dokumentasi Apache Sqoop |
| Tez | Ketersediaan tinggi | Karena kontainer Tez berjalan di YARN, Tez berperilaku dengan cara yang sama seperti YARN selama proses failover node utama. |
| TensorFlow | Ketersediaan tidak terpengaruh oleh failover node primer | Karena tidak TensorFlow memiliki daemon, itu tidak terpengaruh oleh proses failover node utama. |
| Zeppelin | Ketersediaan tinggi | Zeppelin diinstal pada ketiga node utama. Zeppelin menyimpan catatan dan konfigurasi interperter dalam HDFS secara default untuk mencegah kehilangan data. Sesi penerjemah benar-benar terisolasi di ketiga contoh utama. Data sesi akan hilang saat utama mengalami gagal. Disarankan untuk tidak memodifikasi catatan yang sama secara bersamaan pada instance primer yang berbeda. |
| ZooKeeper | Ketersediaan tinggi | ZooKeeper adalah dasar dari fitur failover otomatis HDFS. ZooKeeper menyediakan layanan yang sangat tersedia untuk memelihara data koordinasi, memberi tahu klien tentang perubahan dalam data itu, dan memantau klien untuk kegagalan. Untuk informasi selengkapnya, lihat [Failover otomatis HDFS](https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithNFS.html#Automatic_Failover). |
Untuk menjalankan aplikasi berikut di klaster EMR Amazon dengan beberapa node utama, Anda harus mengonfigurasi database eksternal. Database eksternal ada di luar cluster dan membuat data persisten selama proses failover node primer. Untuk aplikasi berikut, komponen layanan akan secara otomatis pulih selama proses failover node primer, tetapi pekerjaan aktif mungkin gagal dan perlu dicoba lagi.
| Aplikasi | Ketersediaan selama failover node primer | Catatan |
| --- | --- | --- |
| Sarang | Ketersediaan tinggi hanya untuk komponen layanan | Metastore eksternal untuk Hive diperlukan. Ini harus berupa metastore eksternal MySQL, karena PostgreSQL tidak didukung untuk cluster multi-master. Untuk informasi selengkapnya, lihat [Mengkonfigurasi metastore eksternal untuk Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-metastore-external-hive.html). |
| Rona | Ketersediaan tinggi hanya untuk komponen layanan | Diperlukan basis data eksternal untuk Hue. Untuk informasi selengkapnya, lihat [Menggunakan Hue dengan basis data jarak jauh di Amazon RDS](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/hue-rds.html). |
| Oozie | Ketersediaan tinggi hanya untuk komponen layanan | Basis data eksternal untuk Oozie diperlukan. Untuk informasi selengkapnya, lihat [Menggunakan Oozie dengan basis data jarak jauh di Amazon RDS](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/oozie-rds.html).
Oozie-server dan oozie-client diinstal pada ketiga node utama. Klien oozie dikonfigurasi untuk menyambungkan ke server oozie yang benar secara default. |
| PrestODB atau PrestoSQL/Trino | Ketersediaan tinggi hanya untuk komponen layanan | Metastore Hive eksternal untuk PrestoDB (PrestoSQL di Amazon EMR 6.1.0-6.3.0 atau Trino di Amazon EMR 6.4.0 dan yang lebih baru) diperlukan. Anda dapat menggunakan [Presto dengan AWS Glue Data Catalog](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-presto-glue.html) atau [menggunakan database MySQL eksternal](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-metastore-external.html) untuk Hive.
CLI Presto diinstal pada ketiga node utama sehingga Anda dapat menggunakannya untuk mengakses Koordinator Presto dari salah satu node utama. Koordinator Presto diinstal hanya pada satu node utama. Anda dapat menemukan nama DNS dari node utama tempat Koordinator Presto diinstal dengan memanggil Amazon EMR `describe-cluster` API dan membaca nilai bidang yang dikembalikan dalam respons. `MasterPublicDnsName` |
**catatan**
Ketika node utama gagal, Java Database Connectivity (JDBC) atau Open Database Connectivity (ODBC) mengakhiri koneksi ke node utama. Anda dapat terhubung ke salah satu node primer yang tersisa untuk melanjutkan pekerjaan Anda karena daemon metastore Hive berjalan di semua node utama. Atau Anda bisa menunggu node primer yang gagal diganti.
## Bagaimana fitur Amazon EMR bekerja di cluster dengan beberapa node utama
### Menghubungkan ke node primer menggunakan SSH
Anda dapat terhubung ke salah satu dari tiga node utama dalam cluster EMR Amazon menggunakan SSH dengan cara yang sama Anda terhubung ke satu node utama. Untuk informasi selengkapnya, lihat [Connect to the primary node menggunakan SSH](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-connect-master-node-ssh.html).
Jika node primer gagal, koneksi SSH Anda ke node utama berakhir. Untuk melanjutkan pekerjaan Anda, Anda dapat terhubung ke salah satu dari dua node utama lainnya. Atau, Anda dapat mengakses simpul utama baru setelah Amazon EMR menggantikan yang gagal dengan yang baru.
**catatan**
Alamat IP pribadi untuk node primer pengganti tetap sama dengan yang sebelumnya. Alamat IP publik untuk node primer pengganti dapat berubah. Anda dapat mengambil alamat IP baru di konsol atau dengan menggunakan perintah `describe-cluster` di CLI AWS .
NameNode hanya berjalan pada dua atau tiga node utama. Namun, Anda dapat menjalankan perintah `hdfs` CLI dan mengoperasikan pekerjaan untuk mengakses HDFS pada ketiga node utama.
### Bekerja dengan langkah-langkah di Amazon EMR Cluster dengan beberapa node utama
Anda dapat mengirimkan langkah-langkah ke klaster EMR Amazon dengan beberapa node primer dengan cara yang sama seperti Anda bekerja dengan langkah-langkah dalam klaster dengan satu simpul utama. Untuk informasi selengkapnya, lihat [Mengirim pekerjaan ke klaster](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-work-with-steps.html).
Berikut ini adalah pertimbangan untuk bekerja dengan langkah-langkah dalam klaster EMR Amazon dengan beberapa node utama:
+ Jika node primer gagal, langkah-langkah yang berjalan pada node primer ditandai sebagai GAGAL. Setiap data yang ditulis secara lokal akan hilang. Namun, status GAGAL mungkin tidak mencerminkan keadaan sebenarnya dari langkah-langkah tersebut.
+ Jika langkah yang sedang berjalan telah memulai aplikasi YARN ketika node utama gagal, langkah tersebut dapat berlanjut dan berhasil karena failover otomatis dari node primer.
+ Disarankan agar Anda memeriksa status langkah dengan mengacu pada output tugas. Misalnya, MapReduce pekerjaan menggunakan `_SUCCESS` file untuk menentukan apakah pekerjaan berhasil diselesaikan.
+ Disarankan agar Anda menyetel ActionOnFailure parameter ke CONTINUE, atau CANCEL\_AND\_WAIT, bukan TERMINATE\_JOB\_FLOW, atau TERMINATE\_CLUSTER.
### Perlindungan penghentian otomatis
Amazon EMR secara otomatis mengaktifkan perlindungan terminasi untuk semua cluster dengan beberapa node utama, dan mengganti pengaturan eksekusi langkah apa pun yang Anda berikan saat membuat klaster. Anda dapat menonaktifkan perlindungan terminasi setelah cluster diluncurkan. Lihat [Mengonfigurasi perlindungan pengakhiran untuk menjalankan klaster](UsingEMR_TerminationProtection.md#emr-termination-protection-running-cluster). Untuk mematikan klaster dengan beberapa node primer, Anda harus terlebih dahulu memodifikasi atribut cluster untuk menonaktifkan perlindungan terminasi. Untuk petunjuk, lihat [Mengakhiri Cluster EMR Amazon dengan beberapa node utama](emr-plan-ha-launch.md#emr-plan-ha-launch-terminate).
Untuk informasi selengkapnya tentang perlindungan penghentian, lihat [Menggunakan perlindungan penghentian untuk melindungi kluster EMR Amazon Anda dari penutupan yang tidak disengaja](UsingEMR_TerminationProtection.md).
### Fitur yang tidak didukung di Amazon EMR Cluster dengan beberapa node utama
Fitur EMR Amazon berikut saat ini tidak tersedia di kluster EMR Amazon dengan beberapa node utama:
+ EMR Notebooks
+ One-click akses ke server riwayat Spark persisten
+ Antarmuka pengguna aplikasi persisten
+ One-click akses ke antarmuka pengguna aplikasi persisten saat ini tidak tersedia untuk kluster EMR Amazon dengan beberapa node utama atau untuk cluster EMR Amazon yang terintegrasi dengan Lake Formation. AWS
+ Kontrol akses berbasis peran runtime. Untuk informasi selengkapnya, lihat [Pertimbangan tambahan](emr-steps-runtime-roles.md#emr-steps-runtime-roles-considerations) di [Peran runtime untuk langkah-langkah EMR Amazon](emr-steps-runtime-roles.md).
+ Integrasi Amazon EMR dengan AWS IAM Identity Center (propagasi identitas tepercaya). Untuk informasi selengkapnya, lihat [Integrasikan Amazon EMR dengan AWS IAM Identity Center](emr-idc.md).
**catatan**
Untuk menggunakan otentikasi Kerberos di klaster Anda, Anda harus mengonfigurasi KDC eksternal.
Dimulai dengan Amazon EMR versi 5.27.0, Anda dapat mengonfigurasi enkripsi Transparan HDFS pada kluster EMR Amazon dengan beberapa node utama. Untuk informasi selengkapnya, lihat [Enkripsi transparan dalam HDFS di Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-encryption-tdehdfs.html).