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 kapasitas EC2 yang diizinkan dalam sebuah klaster. 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 kapasitas EC2 yang diizinkan dalam sebuah klaster. Hal ini diukur melalui inti atau instans virtual central processing unit (vCPU) untuk grup instans. Hal ini diukur melalui unit untuk armada instans.

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

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

Penskalaan terkelola didukung dalam rilis terbatas Wilayah AWS dan Amazon EMR. 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 metrik-kolektor 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 penskalaan terkelola berfungsi, sebaiknya lakukan salah satu tindakan berikut:

Jika pekerjaan YARN Anda lambat sebentar-sebentar selama penurunan skala, dan log Pengelola Sumber Daya YARN menunjukkan bahwa sebagian besar node Anda dicantumkan dalam daftar 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 meny YARN.resourcemanager.nodemanager-graceful-decommission-timeout-secs etel ke nilai yang lebih besar untuk memastikan Amazon EMR tidak memaksa menghentikan node saat “Spark Task” terpanjang masih berjalan di node. Default saat ini adalah 60 menit, yang berarti YARN memaksa mengakhiri wadah setelah 60 menit setelah node memasuki status dekomisi.

Contoh berikut baris Log Pengelola Sumber Daya YARN 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 node di Amazon EMR dapat dicantumkan ditolak, dan mengonfigurasi perilaku penonaktifan node Spark.

Untuk beban kerja Spark, menonaktifkan Spark Dynamic Resource Allocator (DRA) dengan mengubah properti Spark spark.dynamic menjadi FALSE dapat Allocation.enabled menyebabkan masalah Managed Scaling, di mana cluster dapat ditingkatkan lebih dari yang diperlukan untuk beban kerja Anda (hingga komputasi maksimum). Saat menggunakan Managed Scaling untuk beban kerja ini, sebaiknya Anda tetap mengaktifkan Spark DRA, yang merupakan status default properti ini.

Over-utilization volume EBS dapat menyebabkan masalah Managed Scaling. Kami menyarankan agar Anda menjaga volume EBS di bawah 90% pemanfaatan. Untuk informasi selengkapnya, lihat Opsi dan perilaku penyimpanan instans di Amazon EMR.

CloudWatch Metrik Amazon sangat penting untuk penskalaan yang dikelola Amazon EMR untuk 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 CloudWatch alarm Amazon.

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 On-Demand batas untuk penskalaan terkelola Amazon EMR, pertimbangkan perbedaan antara grup instans dan armada instans. Setiap grup instans terdiri dari jenis instans yang sama dan opsi pembelian yang sama untuk instance: On-Demand atau Spot. Untuk setiap armada instans, Anda dapat menentukan hingga lima jenis instans, yang dapat disediakan sebagai On-Demand 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 Iz inkan Semua keluar default 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 di port 9443. Grup keamanan Anda untuk akses layanan juga harus mengizinkan lalu lintas TCP masuk pada port 9443 dari grup keamanan master. Untuk informasi selengkapnya tentang mengonfigurasi grup keamanan, lihat grup EMR-managed keamanan Amazon untuk instance utama (subnet pribadi).

Anda dapat menggunakannya AWS CloudFormation untuk mengonfigurasi penskalaan terkelola Amazon EMR. Untuk informasi selengkapnya, lihat AWS::EMR::Klaster pada 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 simpul, lihat Node tugas.

Pelabelan node tidak didukung secara default di Amazon EMR rilis 6.15 atau lebih rendah. Untuk informasi selengkapnya, lihat Mem ahami jenis node: 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 node inti dan node tugas. Namun, jika Anda menggunakan Amazon EMR rilis 7.0 atau lebih tinggi, Anda dapat mengonfigurasi label node berdasarkan jenis node dan jenis pasar, seperti On-Demand dan Spot.

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

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

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

Penskalaan terkelola hanya mendukung label node ON_DEMAND dan SPOT atau CORE danTASK. Label simpul 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.

Penskalaan terkelola menskalakan node inti dan 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 Per timbangan dan praktik terbaik.

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

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

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

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

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 yang dikelola Amazon EMR perlu menjadwal ulang aplikasi Anda ke komisi ulang atau node. CORE ON_DEMAND

Untuk mengurangi risiko kegagalan aplikasi karena kehilangan data shuffle, Amazon EMR mengumpulkan metrik dari cluster untuk menentukan node yang memiliki data shuffle sementara 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. Hal ini dapat memengaruhi penurunan skala instans di cluster Anda secara tepat waktu. Untuk cluster yang memiliki data shuffle dalam jumlah besar, pertimbangkan untuk menggunakan EMR versi 6.13 dan yang lebih baru.