Aplikasi dan fitur yang didukung

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.

HDFS ketersediaan tinggi

Cluster EMR Amazon dengan beberapa node utama memungkinkan fitur ketersediaan HDFS NameNode tinggi di Hadoop. Untuk informasi lebih lanjut, lihat ketersediaan tinggi HDFS.

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 dan termasuk 5.30.1, hanya dua dari tiga node utama yang menjalankan HDFS. NameNode

Jika Anda perlu mencari tahu yang NameNode manaactive, 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

Benang ketersediaan tinggi ResourceManager

Cluster EMR Amazon dengan beberapa node utama memungkinkan fitur ketersediaan ResourceManager tinggi YARN di Hadoop. Untuk informasi selengkapnya, lihat ketersediaan ResourceManager tinggi.

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: //:8088/cluster master-public-dns-name” untuk node utama apa pun, yang secara otomatis mengarahkan Anda ke manajer sumber daya. active Untuk mengetahui manajer sumber daya manaactive, 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 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 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 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.
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.

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.
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.
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. 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 atau menggunakan database MySQL eksternal 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 ke node primer menggunakan SSH.

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 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.

Berikut ini adalah pertimbangan untuk bekerja dengan langkah-langkah dalam cluster 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 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 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. Untuk mematikan klaster dengan beberapa node primer, Anda harus terlebih dahulu memodifikasi atribut cluster untuk menonaktifkan perlindungan terminasi. Untuk instruksi, lihat Mengakhiri Cluster EMR Amazon dengan beberapa node utama.

Untuk informasi selengkapnya tentang perlindungan penghentian, lihat Menggunakan perlindungan pengakhiran.

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

• Akses sekali klik ke server riwayat Spark yang persisten

• Antarmuka pengguna aplikasi persisten

• Akses sekali klik 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

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.