Menggunakan penskalaan terkelola di Amazon EMR

Berikut ini Wilayah AWS, penskalaan terkelola Amazon EMR tersedia dengan Amazon EMR 6.14.0 dan yang lebih tinggi:

Berikut ini Wilayah AWS, penskalaan terkelola Amazon EMR tersedia dengan Amazon EMR 5.30.0 dan 6.1.0 dan yang lebih tinggi:

Penskalaan terkelola Amazon EMR hanya berfungsi dengan aplikasi YARN, seperti Spark, Hadoop, Hive, dan Flink. Itu tidak mendukung aplikasi yang tidak didasarkan pada YARN, seperti Presto dan HBase.

Minimum (MinimumCapacityUnits) — Batas bawah EC2 kapasitas yang diizinkan dalam sebuah cluster. Hal ini diukur melalui inti atau instans virtual central processing unit (vCPU) untuk grup instans. Hal ini diukur melalui unit untuk armada instans.

Maksimum (MaximumCapacityUnits) — Batas atas EC2 kapasitas yang diizinkan dalam sebuah cluster. Hal ini diukur melalui inti atau instans virtual central processing unit (vCPU) untuk grup instans. Hal ini diukur melalui unit untuk armada instans.

Batas atas Permintaan (MaximumOnDemandCapacityUnits) (Opsional) — Batas atas EC2 kapasitas yang diizinkan untuk jenis pasar On-Demand dalam sebuah cluster. Jika parameter ini tidak ditentukan, default ke nilai MaximumCapacityUnits.

Node inti maksimum (MaximumCoreCapacityUnits) (Opsional) - Batas atas EC2 kapasitas yang diizinkan untuk tipe node inti dalam sebuah cluster. Jika parameter ini tidak ditentukan, default ke nilai MaximumCapacityUnits.

Penskalaan terkelola didukung dalam rilis EMR Amazon terbatas Wilayah AWS dan. Untuk informasi selengkapnya, lihat Ketersediaan penskalaan terkelola.

Anda harus mengonfigurasi parameter yang diperlukan untuk penskalaan terkelola Amazon EMR. Untuk informasi selengkapnya, lihat Parameter penskalaan terkelola.

Untuk menggunakan penskalaan terkelola, proses kolektor metrik harus dapat terhubung ke titik akhir API publik untuk penskalaan terkelola di API Gateway. Jika Anda menggunakan nama DNS pribadi dengan Amazon Virtual Private Cloud, penskalaan terkelola tidak akan berfungsi dengan baik. Untuk memastikan bahwa penskalaan terkelola berfungsi, kami sarankan Anda melakukan salah satu tindakan berikut:

Jika pekerjaan YARN Anda sebentar-sebentar lambat selama penurunan skala, dan log Manajer Sumber Daya YARN menunjukkan bahwa sebagian besar node Anda dicantumkan penolakan selama waktu itu, Anda dapat menyesuaikan ambang batas waktu penonaktifan.

Kurangi spark.blacklist.decommissioning.timeout dari satu jam menjadi satu menit untuk membuat node tersedia untuk wadah tertunda lainnya untuk melanjutkan pemrosesan tugas.

Anda juga harus menyetel YARN.resourcemanager.nodemanager-graceful-decommission-timeout-secs ke nilai yang lebih besar untuk memastikan Amazon EMR tidak memaksa menghentikan node sementara “Spark Task” terpanjang masih berjalan di node. Default saat ini adalah 60 menit, yang berarti YARN menghentikan kontainer secara paksa setelah 60 menit setelah node memasuki status dekomisi.

Contoh berikut baris YARN Resource Manager Log menunjukkan node yang ditambahkan ke status dekomisi:

2021-10-20 15:55:26,994 INFO org.apache.hadoop.YARN.server.resourcemanager.DefaultAMSProcessor (IPC Server handler 37 on default port 8030): blacklist are updated in Scheduler.blacklistAdditions: [ip-10-10-27-207.us-west-2.compute.internal, ip-10-10-29-216.us-west-2.compute.internal, ip-10-10-31-13.us-west-2.compute.internal, ... , ip-10-10-30-77.us-west-2.compute.internal], blacklistRemovals: []

Lihat detail selengkapnya tentang cara Amazon EMR terintegrasi dengan daftar penolakan YARN selama penonaktifan node, kasus ketika nodedi Amazon EMR dapat ditolak terdaftar, dan mengonfigurasi perilaku penonaktifan simpul Spark.

Pemanfaatan volume EBS yang berlebihan dapat menyebabkan masalah Penskalaan Terkelola. Kami menyarankan Anda mempertahankan volume EBS di bawah 90% pemanfaatan. Untuk informasi selengkapnya, lihat Opsi dan perilaku penyimpanan instans di Amazon EMR.

CloudWatch Metrik Amazon sangat penting agar penskalaan terkelola Amazon EMR dapat beroperasi. Kami menyarankan Anda memantau CloudWatch metrik Amazon dengan cermat untuk memastikan data tidak hilang. Untuk informasi selengkapnya tentang cara mengonfigurasi CloudWatch alarm untuk mendeteksi metrik yang hilang, lihat Menggunakan alarm Amazon CloudWatch .

Operasi penskalaan terkelola pada klaster 5.30.0 dan 5.30.1 tanpa Presto yang diinstal dapat menyebabkan gagal aplikasi atau menyebabkan grup instans seragam atau armada instans tetap berada di negara ARRESTED, terutama ketika operasi menurunkan skala diikuti dengan cepat oleh operasi menaikkan skala.

Sebagai solusinya, pilih Presto sebagai aplikasi untuk diinstal saat Anda membuat cluster dengan Amazon EMR rilis 5.30.0 dan 5.30.1, bahkan jika pekerjaan Anda tidak memerlukan Presto.

Saat Anda menetapkan node inti maksimum dan batas On-Demand untuk penskalaan terkelola Amazon EMR, pertimbangkan perbedaan antara grup instans dan armada instans. Setiap grup instans terdiri dari tipe instans yang sama dan opsi pembelian yang sama untuk instans: Sesuai Permintaan atau Spot. Untuk setiap armada instans, Anda dapat menentukan hingga lima tipe instans, yang dapat disediakan sebagai instans Sesuai Permintaan dan instans Spot. Untuk informasi selengkapnya, lihat Membuat sebuah klaster dengan armada instans atau grup instans seragam, Opsi armada instans, dan Skenario alokasi simpul.

Dengan Amazon EMR 5.30.0 dan yang lebih tinggi, jika Anda menghapus aturan default Izinkan Semua keluar ke 0.0.0.0/ untuk grup keamanan master, Anda harus menambahkan aturan yang memungkinkan konektivitas TCP keluar ke grup keamanan Anda untuk akses layanan pada port 9443. Grup keamanan Anda untuk akses layanan juga harus mengizinkan lalu lintas TCP masuk pada port 9443 dari grup keamanan utama. Untuk informasi selengkapnya tentang mengonfigurasi grup keamanan, lihat grup keamanan yang dikelola Amazon EMR untuk contoh utama (subnet pribadi).

Anda dapat menggunakan AWS CloudFormation untuk mengonfigurasi penskalaan terkelola Amazon EMR. Untuk informasi selengkapnya, lihat AWS::EMR::Cluster di AWS CloudFormation Panduan Pengguna.

Jika Anda menggunakan node Spot, pertimbangkan untuk menggunakan label node untuk mencegah Amazon EMR menghapus proses aplikasi saat Amazon EMR menghapus node Spot. Untuk informasi selengkapnya tentang label node, lihat Node tugas.

Pelabelan node tidak didukung secara default di Amazon EMR rilis 6.15 atau lebih rendah. Untuk informasi selengkapnya, lihat Memahami tipe simpul: node primer, inti, dan tugas.

Jika Anda menggunakan Amazon EMR rilis 6.15 atau lebih rendah, Anda hanya dapat menetapkan label node berdasarkan jenis node, seperti inti dan node tugas. Namun, jika Anda menggunakan Amazon EMR rilis 7.0 atau yang lebih tinggi, Anda dapat mengonfigurasi label node berdasarkan jenis node dan tipe pasar, seperti On-Demand dan Spot.

Jika permintaan proses aplikasi meningkat dan permintaan pelaksana berkurang ketika Anda membatasi proses aplikasi ke node inti, Anda dapat menambahkan kembali node inti dan menghapus node tugas dalam operasi pengubahan ukuran yang sama. Untuk informasi selengkapnya, lihat Memahami strategi dan skenario alokasi node.

Amazon EMR tidak memberi label pada node tugas, jadi Anda tidak dapat menyetel properti YARN untuk membatasi proses aplikasi hanya untuk node tugas. Namun, jika Anda ingin menggunakan tipe pasar sebagai label node, Anda dapat menggunakan SPOT label ON_DEMAND atau untuk penempatan proses aplikasi. Kami tidak menyarankan menggunakan node Spot untuk proses utama aplikasi.

Saat menggunakan label node, total unit yang berjalan di klaster sementara dapat melebihi set komputasi maksimal dalam kebijakan penskalaan terkelola sementara Amazon EMR menonaktifkan beberapa instans Anda. Total unit yang diminta akan selalu berada di atau di bawah perhitungan maksimal polis Anda.

Penskalaan terkelola hanya mendukung label node ON_DEMAND dan SPOT atau CORE danTASK. Label node kustom tidak didukung.

Amazon EMR membuat label node saat membuat cluster dan sumber daya penyediaan. Amazon EMR tidak mendukung penambahan label node saat Anda mengkonfigurasi ulang cluster. Anda juga tidak dapat memodifikasi label node saat mengonfigurasi penskalaan terkelola setelah meluncurkan cluster.

Skala skala terkelola inti dan node tugas secara independen berdasarkan proses aplikasi dan permintaan pelaksana. Untuk mencegah masalah kehilangan data HDFS selama penurunan skala inti, ikuti praktik standar untuk node inti. Untuk mempelajari lebih lanjut tentang praktik terbaik tentang node inti dan replikasi HDFS, lihat Pertimbangan dan praktik terbaik.

Anda tidak dapat menempatkan proses aplikasi dan pelaksana hanya pada core atau node. ON_DEMAND Jika Anda ingin menambahkan proses aplikasi dan pelaksana pada salah satu node, jangan gunakan konfigurasi. yarn.node-labels.am.default-node-label-expression

Misalnya, untuk menempatkan proses aplikasi dan pelaksana di ON_DEMAND node, atur komputasi maks sama dengan maksimum di node. ON_DEMAND Hapus juga yarn.node-labels.am.default-node-label-expression konfigurasi.

Untuk menambahkan proses aplikasi dan pelaksana pada core node, hapus konfigurasi. yarn.node-labels.am.default-node-label-expression

Saat Anda menggunakan penskalaan terkelola dengan label node, atur properti yarn.scheduler.capacity.maximum-am-resource-percent: 1 jika Anda berencana untuk menjalankan beberapa aplikasi secara paralel. Melakukannya memastikan bahwa proses aplikasi Anda sepenuhnya memanfaatkan yang tersedia CORE atau ON_DEMAND node.

Jika Anda menggunakan penskalaan terkelola dengan label node, setel properti yarn.resourcemanager.decommissioning.timeout ke nilai yang lebih panjang dari aplikasi yang berjalan paling lama di cluster Anda. Melakukannya mengurangi kemungkinan penskalaan terkelola Amazon EMR perlu menjadwal ulang aplikasi Anda ke remisi atau node. CORE ON_DEMAND

Untuk mengurangi risiko kegagalan aplikasi karena kehilangan data acak, Amazon EMR mengumpulkan metrik dari cluster untuk menentukan node yang memiliki data shuffle transien yang ada dari tahap saat ini dan sebelumnya. Dalam kasus yang jarang terjadi, metrik dapat terus melaporkan data basi untuk aplikasi yang sudah selesai atau dihentikan. Ini dapat memengaruhi penurunan skala instans tepat waktu di klaster Anda. Untuk cluster yang memiliki sejumlah besar data shuffle, pertimbangkan untuk menggunakan EMR versi 6.13 dan yang lebih baru.