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 cluster Amazon EMR dan cara kerjanya dengan aplikasi sumber terbuka
Topik ini memberikan informasi tentang fitur ketersediaan tinggi Hadoop HDFS NameNode dan YARN ResourceManager di cluster Amazon EMR, dan cara kerja fitur dengan ketersediaan tinggi dengan aplikasi sumber terbuka dan fitur Amazon EMR lainnya.
## High-availability HDFS
Cluster Amazon EMR 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 Amazon EMR, dua atau lebih node terpisah dikonfigurasi sebagai NameNodes. Yang satu NameNode berada dalam suatu `active` negara dan yang lainnya berada dalam suatu `standby` negara. 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. `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 yang 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 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 Amazon EMR dengan beberapa node utama memungkinkan fitur ketersediaan ResourceManager tinggi YARN di Hadoop. Untuk informasi selengkapnya, lihat [ ResourceManager Ketersediaan tinggi](https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/ResourceManagerHA.html).
Dalam cluster Amazon EMR dengan beberapa node primer, YARN ResourceManager berjalan pada ketiga node utama. Satu ResourceManager di `active` negara bagian, dan dua lainnya berada di `standby` negara bagian. Jika node utama `active` ResourceManager gagal, Amazon EMR memulai proses failover otomatis. Node utama dengan a `standby` ResourceManager mengambil alih semua operasi. Amazon EMR menggantikan node primer yang gagal dengan yang baru, yang kemudian bergabung kembali kuorum sebagai ResourceManager a. `standby`
Anda dapat terhubung ke “http://{{master-public-dns-name}}:8088/cluster" untuk setiap node utama, yang secara otomatis mengarahkan Anda ke pengelola `active` sumber daya. Untuk mengetahui pengelola 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 pada cluster Amazon EMR dengan beberapa node utama. Untuk setiap aplikasi, proses failover node utama bervariasi.
| Aplikasi | Ketersediaan selama failover node utama | Catatan |
| --- | --- | --- |
| Flink | Ketersediaan tidak terpengaruh oleh failover node utama | Tugas Flink di Amazon EMR dijalankan sebagai aplikasi YARN. Flink di JobManagers jalankan sebagai YARN ApplicationMasters di node inti. Tidak JobManager terpengaruh oleh proses failover node utama.
Jika Anda menggunakan Amazon EMR versi 5.27.0 atau yang lebih lama, ini JobManager adalah satu titik kegagalan. Ketika JobManager gagal, itu kehilangan semua status pekerjaan dan tidak akan melanjutkan pekerjaan yang sedang berjalan. Anda dapat mengaktifkan ketersediaan JobManager tinggi dengan mengonfigurasi jumlah percobaan aplikasi, checkpoint, dan mengaktifkan ZooKeeper sebagai penyimpanan status untuk Flink. Untuk informasi selengkapnya, lihat [ Mengonfigurasi Flink pada Cluster Amazon EMR dengan beberapa node utama. ](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/flink-configure.html#flink-multi-master)
Dimulai dengan Amazon EMR versi 5.28.0, tidak diperlukan konfigurasi manual untuk mengaktifkan JobManager ketersediaan tinggi. |
| Ganglia | Ketersediaan tidak terpengaruh oleh failover node utama | 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 masuk ke node siaga ketika node primer aktif gagal. |
| HBase | Ketersediaan tinggi | HBase secara otomatis gagal masuk ke node siaga ketika node primer aktif gagal.
Jika Anda menghubungkan ke HBase melalui server REST atau Thrift, Anda harus beralih ke node utama yang berbeda ketika node primer aktif gagal. |
| HKatalog | Ketersediaan tidak terpengaruh oleh failover node utama | 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 mengkonfigurasi persistensi notebook untuk mencegah kehilangan notebook pada kegagalan node utama. 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 utama | Karena Mahout tidak memiliki daemon, itu tidak terpengaruh oleh proses failover node utama. |
| MXnet | Ketersediaan tidak terpengaruh oleh failover node utama | Karena MXnet tidak memiliki daemon, itu tidak terpengaruh oleh proses failover node utama. |
| Phoenix | Ketersediaan Yang Tinggi | Phoenix hanya QueryServer berjalan 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 utama | Karena Pig tidak memiliki daemon, itu tidak terpengaruh oleh proses failover node utama. |
| Percikan | Ketersediaan tinggi | Semua aplikasi Spark berjalan dalam wadah YARN dan dapat bereaksi terhadap failover node utama dengan cara yang sama seperti fitur YARN dengan 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 container Tez berjalan di YARN, Tez berperilaku dengan cara yang sama seperti YARN selama proses failover node utama. |
| TensorFlow | Ketersediaan tidak terpengaruh oleh failover node utama | 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 contoh utama 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 cluster Amazon EMR dengan beberapa node utama, Anda harus mengonfigurasi database eksternal. Database eksternal ada di luar cluster dan membuat data persisten selama proses failover node utama. Untuk aplikasi berikut, komponen layanan akan pulih secara otomatis selama proses failover node utama, tetapi pekerjaan aktif mungkin gagal dan perlu dicoba lagi.
| Aplikasi | Ketersediaan selama failover node utama | Catatan |
| --- | --- | --- |
| Sarang | Ketersediaan tinggi hanya untuk komponen layanan | Metastore eksternal untuk Hive diperlukan. Ini harus menjadi 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 Katalog Data AWS Glue ](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-presto-glue.html) atau [ menggunakan database MySQL eksternal untuk Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-metastore-external.html).
Presto CLI 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 yang dikembalikan dari `MasterPublicDnsName` bidang dalam respons. |
**catatan**
Ketika node utama gagal, Java Database Connectivity (JDBC) atau Open Database Connectivity (ODBC) Anda menghentikan 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 primer. Atau Anda dapat menunggu node utama yang gagal diganti.
## Cara kerja fitur Amazon EMR dalam cluster dengan beberapa node utama
### Menghubungkan ke node utama menggunakan SSH
Anda dapat terhubung ke salah satu dari tiga node utama dalam cluster Amazon EMR menggunakan SSH dengan cara yang sama seperti Anda terhubung ke satu node utama. Untuk informasi selengkapnya, lihat [ Menghubungkan ke node utama menggunakan SSH](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-connect-master-node-ssh.html).
Jika node utama gagal, koneksi SSH Anda ke node utama itu berakhir. Untuk melanjutkan pekerjaan Anda, Anda dapat terhubung ke salah satu dari dua node utama lainnya. Atau, Anda dapat mengakses node utama baru setelah Amazon EMR mengganti 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 cluster Amazon EMR dengan beberapa node utama dengan cara yang sama seperti Anda bekerja dengan langkah-langkah dalam cluster dengan satu node 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 cluster Amazon EMR dengan beberapa node utama:
+ Jika node utama gagal, langkah-langkah yang berjalan pada node utama 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 dilanjutkan dan berhasil karena failover otomatis dari node utama.
+ 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 mengatur ActionOnFailure parameter ke CONTINUE, atau CANCEL\_AND\_WAIT, bukan TERMINATE\_JOB\_FLOW, atau TERMINATE\_CLUSTER.
### Perlindungan penghentian otomatis
Amazon EMR secara otomatis mengaktifkan perlindungan penghentian untuk semua cluster dengan beberapa node utama, dan mengganti setelan eksekusi langkah apa pun yang Anda berikan saat membuat cluster. Anda dapat menonaktifkan perlindungan penghentian setelah cluster diluncurkan. Lihat [Mengonfigurasi perlindungan pengakhiran untuk menjalankan klaster](UsingEMR_TerminationProtection.md#emr-termination-protection-running-cluster). Untuk mematikan cluster dengan beberapa node utama, Anda harus terlebih dahulu memodifikasi atribut cluster untuk menonaktifkan perlindungan terminasi. Untuk petunjuk, lihat [Menghentikan Cluster Amazon EMR 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 cluster Amazon EMR Anda dari penutupan yang tidak disengaja](UsingEMR_TerminationProtection.md).
### Fitur yang tidak didukung di Amazon EMR Cluster dengan beberapa node utama
Fitur Amazon EMR berikut saat ini tidak tersedia di cluster Amazon EMR 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 cluster Amazon EMR dengan beberapa node utama atau untuk cluster Amazon EMR yang terintegrasi dengan AWS Lake Formation.
+ 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 Amazon EMR](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 HDFS Transparan pada cluster Amazon EMR 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).