View a markdown version of this page

Memahami strategi dan skenario alokasi node Amazon EMR - Amazon EMR
Strategi alokasi simpulPertimbangan alokasi simpulSkenario alokasi simpul

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Memahami strategi dan skenario alokasi node Amazon EMR

Bagian ini memberikan gambaran umum tentang strategi alokasi node dan skenario penskalaan umum yang dapat Anda gunakan dengan penskalaan terkelola Amazon EMR.

Strategi alokasi simpul

Penskalaan terkelola Amazon EMR mengalokasikan node inti dan tugas berdasarkan strategi peningkatan dan penurunan skala berikut:

Scale-up strategi

  • Untuk Amazon EMR rilis 7.2 dan yang lebih tinggi, penskalaan terkelola terlebih dahulu menambahkan node berdasarkan label node dan properti YARN pembatasan proses aplikasi.

  • Untuk Amazon EMR rilis 7.2 dan yang lebih tinggi, jika Anda mengaktifkan label node dan membatasi proses aplikasi ke CORE node, penskalaan terkelola Amazon EMR akan meningkatkan node inti dan node tugas jika permintaan proses aplikasi meningkat dan permintaan pelaksana meningkat. Demikian pula, jika Anda mengaktifkan label node dan membatasi proses aplikasi ke ON_DEMAND node, penskalaan terkelola meningkatkan node sesuai permintaan jika permintaan proses aplikasi meningkat dan meningkatkan node spot jika permintaan pelaksana meningkat.

  • Jika label node tidak diaktifkan, penempatan proses aplikasi tidak terbatas pada node atau tipe pasar apa pun.

  • Dengan menggunakan label node, penskalaan terkelola dapat meningkatkan dan menurunkan skala grup instans dan armada instans yang berbeda dalam operasi pengubahan ukuran yang sama. Misalnya, dalam skenario di mana instance_group1 memiliki ON_DEMAND node dan instance_group2 memiliki SPOT node, dan label node diaktifkan dan proses aplikasi dibatasi untuk node dengan ON_DEMAND label. Penskalaan terkelola akan mengurangi instance_group1 dan meningkatkan instance_group2 jika permintaan proses aplikasi menurun dan permintaan pelaksana meningkat.

  • Ketika Amazon EMR mengalami penundaan dalam peningkatan skala dengan grup instans saat ini, cluster yang menggunakan penskalaan terkelola secara otomatis beralih ke grup instance tugas yang berbeda.

  • Jika parameter MaximumCoreCapacityUnits diatur, maka Amazon EMR menskalakan simpul inti sampai unit inti mencapai batas maksimum yang diizinkan. Semua kapasitas yang tersisa ditambahkan ke simpul tugas.

  • Jika MaximumOnDemandCapacityUnits parameter disetel, Amazon EMR menskalakan cluster dengan menggunakan On-Demand Instans hingga On-Demand unit mencapai batas maksimum yang diizinkan. Semua kapasitas yang tersisa ditambahkan menggunakan Instans Spot.

  • Jika kedua parameter MaximumCoreCapacityUnits dan MaximumOnDemandCapacityUnits diatur, Amazon EMR mempertimbangkan kedua batas selama penskalaan.

    Misalnya, jika kurang dariMaximumOnDemandCapacityUnits, Amazon EMR pertama-tama menskalakan node inti hingga batas kapasitas inti tercapai. MaximumCoreCapacityUnits Untuk kapasitas yang tersisa, Amazon EMR pertama-tama menggunakan On-Demand Instans untuk menskalakan node tugas hingga On-Demand batas tercapai, dan kemudian menggunakan Instans Spot untuk node tugas.

Scale-down strategi

  • Mirip dengan strategi peningkatan skala, Amazon EMR menghapus node berdasarkan label node. Untuk informasi selengkapnya tentang label node, lihat Mem ahami jenis node: node primer, inti, dan tugas.

  • Jika Anda belum mengaktifkan label node, penskalaan terkelola akan menghapus node tugas dan kemudian menghapus node inti hingga mencapai kapasitas target penurunan skala yang diinginkan. Penskalaan terkelola tidak pernah menurunkan skala cluster di bawah batasan minimum yang ditentukan dalam kebijakan penskalaan terkelola.

  • Amazon EMR versi 5.34.0 dan yang lebih tinggi, dan Amazon EMR versi 6.4.0 dan yang lebih tinggi, mendukung kesadaran data Spark shuffle, yang mencegah penurunan skala instance sementara Managed Scaling mengetahui data shuffle yang ada. Untuk informasi selengkapnya tentang operasi shuffle, lihat Panduan Pemrograman Spark. Managed Scaling melakukan upaya terbaik untuk mencegah penskalaan node dengan data shuffle dari tahap saat ini dan sebelumnya dari aplikasi Spark aktif apa pun, hingga maksimum 30 menit. Ini membantu meminimalkan kehilangan data shuffle yang tidak diinginkan, menghindari kebutuhan untuk upaya ulang pekerjaan dan perhitungan ulang data perantara. Namun, pencegahan kehilangan data shuffle tidak dijamin. Untuk perlindungan Spark shuffle yang lebih baik, kami merekomendasikan kesadaran shuffle pada cluster dengan label rilis 7.4 atau lebih tinggi. Tambahkan flag berikut ke konfigurasi cluster untuk mengaktifkan perlindungan Spark shuffle yang ditingkatkan.

    • Jika yarn.nodemanager.shuffledata-monitor.interval-ms bendera (default 30000 ms) atau spark.dynamicAllocation.executorIdleTimeout (default 60 detik) telah diubah dari nilai default, pastikan kondisinya spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms tetap true dengan memperbarui flag yang diperlukan.

      [
	{
		"Classification": "yarn-site",
		"Properties": { 
		"yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data": "true"
		}
	},
	{
		"Classification": "spark-defaults",
		"Properties": {
		"spark.dynamicAllocation.enabled": "true",
		"spark.shuffle.service.removeShuffle": "true"
		}
	}
]

  • Penskalaan terkelola pertama-tama menghapus node tugas dan kemudian menghapus node inti hingga mencapai kapasitas target penurunan skala yang diinginkan. Cluster tidak pernah menskalakan di bawah batasan minimum yang ditentukan dalam kebijakan penskalaan terkelola.

  • Untuk cluster yang diluncurkan dengan Amazon EMR 5.x rilis 5.34.0 dan yang lebih tinggi, dan 6.x rilis 6.4.0 dan yang lebih tinggi, Amazon EMR Managed Scaling tidak mengurangi node yang ada ApplicationMaster untuk Apache Spark, jika ada tahapan aktif dalam aplikasi yang berjalan di dalamnya. Ini meminimalkan kegagalan pekerjaan dan percobaan ulang, yang membantu meningkatkan kinerja pekerjaan dan mengurangi biaya. Untuk mengonfirmasi node mana di cluster Anda yang sedang berjalanApplicationMaster, kunjungi Server Sejarah Spark dan filter driver di bawah tab Pel aksana ID aplikasi Spark Anda.

  • Meskipun penskalaan cerdas dengan EMR Managed Scaling meminimalkan kehilangan data shuffle untuk Spark, mungkin ada contoh ketika data shuffle sementara mungkin tidak dilindungi selama penurunan skala. Untuk memberikan ketahanan data shuffle yang ditingkatkan selama penurunan skala, sebaiknya aktifkan Graceful Decomisioning for Shuffle Data di YARN. Ketika Graceful Decomisioning for Shuffle Data diaktifkan di YARN, node yang dipilih untuk penskalaan yang memiliki data shuffle akan memasuki status Pen onaktifan dan terus melayani file shuffle. YARN ResourceManager menunggu sampai node melaporkan tidak ada file shuffle yang ada sebelum menghapus node dari cluster.

    • Amazon EMR versi 6.11.0 dan yang lebih tinggi mendukung penonaktifan yang Yarn-based anggun untuk data shuffle Hive untuk Tez dan Shuffle Handler. MapReduce

      • Aktifkan Penonaktifan Graceful untuk Data Shuffle dengan menyetel ke. yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data true

    • Amazon EMR versi 7.4.0 dan yang lebih tinggi mendukung penonakti Yarn-based fan anggun untuk data shuffle Spark saat layanan shuffle eksternal diaktifkan (diaktifkan secara default di EMR di EC2).

      • Perilaku default layanan shuffle eksternal Spark, saat menjalankan Spark on Yarn, adalah NodeManager agar Yarn menghapus file shuffle aplikasi pada saat aplikasi dihentikan. Ini mungkin berdampak pada kecepatan dekomisioning node dan pemanfaatan komputasi. Untuk aplikasi yang berjalan lama, pertimbangkan spark.shuffle.service.removeShuffle untuk mengatur true untuk menghapus file shuffle yang tidak lagi digunakan untuk mengaktifkan penonaktifan node yang lebih cepat tanpa data shuffle aktif.

    • Untuk meminimalkan kehilangan data Spark shuffle di Amazon EMR versi 7.4.0 dan yang lebih tinggi, pertimbangkan untuk mengatur flag berikut.

      • Jika yarn.nodemanager.shuffledata-monitor.interval-ms bendera (default 30000 ms) atau spark.dynamicAllocation.executorIdleTimeout (default 60 detik) telah diubah dari nilai default, pastikan bahwa kondisi spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms tetap true dengan memperbarui flag yang diperlukan.

        [
	{
		"Classification": "yarn-site",
		"Properties": { 
		"yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data": "true"
		}
	},
	{
		"Classification": "spark-defaults",
		"Properties": {
		"spark.dynamicAllocation.enabled": "true",
		"spark.shuffle.service.removeShuffle": "true"
		}
	}
]

Jika klaster tidak memiliki beban apapun, maka Amazon EMR membatalkan penambahan instans baru dari evaluasi sebelumnya dan melakukan operasi menurunkan skala. Jika klaster memiliki beban berat, Amazon EMR membatalkan penghapusan instans dan melakukan operasi menaikkan skala.

Pertimbangan alokasi simpul

Sebaiknya gunakan opsi On-Demand pembelian untuk node inti untuk menghindari hilangnya data HDFS jika terjadi reklamasi Spot. Anda dapat menggunakan opsi pembelian Spot untuk simpul tugas untuk mengurangi biaya dan mendapatkan eksekusi pekerjaan yang lebih cepat ketika lebih banyak Instans Spot ditambahkan ke simpul tugas.

Skenario alokasi simpul

Anda dapat membuat berbagai skenario penskalaan berdasarkan kebutuhan Anda dengan mengatur parameter node inti Maksimum, Minimum, On-Demand batas, dan Maksimum dalam kombinasi yang berbeda.

Skenario 1: Hanya Skala Node Inti

Untuk menskalakan simpul inti saja, parameter penskalaan terkelola harus memenuhi persyaratan berikut:

  • Bat On-Demand asnya sama dengan batas maksimum.

  • Simpul inti maksimum sama dengan batas maksimum.

Ketika On-Demand batas dan parameter node inti maksimum tidak ditentukan, kedua parameter default ke batas maksimum.

Skenario ini tidak berlaku jika Anda menggunakan penskalaan terkelola dengan label node dan membatasi proses aplikasi Anda untuk hanya berjalan pada CORE node, karena penskalaan terkelola menskalakan node tugas untuk mengakomodasi permintaan pelaksana.

Contoh berikut menunjukkan skenario penskalaan simpul inti saja.

Status awal klaster Parameter penskalaan Perilaku penskalaan

Grup instans

Inti: 1 On-Demand

Tugas: 1 On-Demand dan 1 Spot

UnitType: Instans

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 20

Skala antara 1 hingga 20 Instans atau unit armada instans pada node inti menggunakan On-Demand tipe. Tidak ada penskalaan pada simpul tugas.

Bila Anda menggunakan penskalaan terkelola dengan label node dan membatasi proses aplikasi Anda ke ON_DEMAND node, cluster akan menskalakan 1 hingga 20 instans atau unit armada instans pada CORE node menggunakan Spot jenis On-Demand atau, tergantung pada jenis permintaan.

Armada instans

Inti: 1 On-Demand

Tugas: 1 On-Demand dan 1 Spot

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 20

Skenario 2: Hanya menskalakan node tugas

Untuk menskalakan simpul tugas saja, parameter penskalaan terkelola harus memenuhi persyaratan berikut:

  • Simpul inti maksimum harus sama dengan batas minimum.

Contoh berikut menunjukkan skenario penskalaan simpul tugas saja.

Status awal klaster Parameter penskalaan Perilaku penskalaan

Grup instans

Inti: 2 On-Demand

Tugas: 1 Spot

UnitType: Instans

MinimumCapacityUnits: 2

MaximumCapacityUnits: 20

MaximumCoreCapacityUnits: 2

Jaga agar simpul inti tetap stabil pada 2 dan hanya menskalakan simpul tugas antara 0 hingga 18 instans atau unit armada instans. Kapasitas antara batas minimum dan maksimum ditambahkan ke simpul tugas saja.

Bila Anda menggunakan penskalaan terkelola dengan label node dan membatasi proses aplikasi Anda ke node ON_DEMAND, cluster akan menjaga node inti tetap stabil di 2 dan hanya menskalakan node tugas antara 0 hingga 18 instans atau unit armada instans yang menggunakan Spot jenis On-demand atau, tergantung pada jenis permintaan.

Armada instans

Inti: 2 On-Demand

Tugas: 1 Spot

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 2

MaximumCapacityUnits: 20

MaximumCoreCapacityUnits: 2

Skenario 3: Hanya On-Demand Instans di cluster

Untuk memiliki On-Demand Instans saja, cluster Anda dan parameter penskalaan terkelola harus memenuhi persyaratan berikut:

  • Bat On-Demand asnya sama dengan batas maksimum.

    Ketika On-Demand batas tidak ditentukan, nilai parameter default ke batas maksimum. Nilai default menunjukkan bahwa Amazon EMR hanya menskalakan On-Demand Instans.

Jika simpul inti maksimum kurang dari batas maksimum, parameter simpul inti maksimum dapat digunakan untuk membagi alokasi kapasitas antara simpul inti dan tugas.

Untuk mengaktifkan skenario ini dalam cluster yang terdiri dari grup instance, semua grup node dalam cluster harus menggunakan tipe On-Demand pasar selama konfigurasi awal.

Skenario ini tidak berlaku jika Anda menggunakan penskalaan terkelola dengan label node dan membatasi proses aplikasi Anda untuk hanya berjalan pada ON_DEMAND node, karena penskalaan terkelola menskalakan Spot node untuk mengakomodasi permintaan pelaksana.

Contoh berikut menunjukkan skenario memiliki On-Demand Instans di seluruh cluster.

Status awal klaster Parameter penskalaan Perilaku penskalaan

Grup instans

Inti: 1 On-Demand

Tugas: 1 On-Demand

UnitType: Instans

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 12

Skala antara 1 hingga 12 instans atau unit armada instans pada node inti menggunakan On-Demand tipe. Skala kapasitas yang tersisa menggunakan On-Demand pada node tugas. Tidak ada penskalaan menggunakan Instans Spot.

Bila Anda menggunakan penskalaan terkelola dengan label node dan membatasi proses aplikasi Anda ke CORE node, cluster akan menskalakan antara 1 hingga 20 instans atau unit armada instans pada CORE task node atau node menggunakan ON_DEMAND tipe, tergantung pada jenis permintaan. Penskalaan pada node inti tidak akan melebihi 12 instans atau unit armada instans.

Armada instans

Inti: 1 On-Demand

Tugas: 1 On-Demand

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 12

Skenario 4: Hanya Instans Spot di cluster

Untuk memiliki Instans Spot saja, klaster Anda dan parameter penskalaan terkelola harus memenuhi persyaratan berikut:

  • On-Demand batas ditetapkan ke 0.

Jika simpul inti maksimum kurang dari batas maksimum, parameter simpul inti maksimum dapat digunakan untuk membagi alokasi kapasitas antara simpul inti dan tugas.

Untuk mengaktifkan skenario ini dalam sebuah klaster yang terdiri dari grup instans, grup instans inti harus menggunakan opsi pembelian Spot selama konfigurasi awal. Jika tidak ada Instans Spot di grup instance tugas, penskalaan terkelola Amazon EMR akan membuat grup tugas menggunakan Instans Spot bila diperlukan.

Skenario ini tidak berlaku jika Anda menggunakan penskalaan terkelola dengan label node dan membatasi proses aplikasi Anda untuk hanya berjalan di ON_DEMAND node, karena penskalaan terkelola menskal ON_DEMAND akan node untuk mengakomodasi permintaan proses aplikasi.

Contoh berikut menunjukkan skenario dari memiliki Instans Spot di seluruh klaster.

Status awal klaster Parameter penskalaan Perilaku penskalaan

Grup instans

Inti: 1 Spot

Tugas: 1 Spot

UnitType: Instans

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 0

Menskalakan antara 1 hingga 20 Instans atau unit armada instans pada simpul inti menggunakan Spot. Tidak ada penskalaan menggunakan On-Demand tipe.

Bila Anda menggunakan penskalaan terkelola dengan label node dan membatasi proses aplikasi Anda ke CORE node, cluster akan menskalakan antara 1 hingga 20 instans atau unit armada instans pada CORE atau TASK node menggunakan Spot, tergantung pada jenis permintaan. Amazon EMR tidak menskalakan menggunakan ON_DEMAND tipe.

Armada instans

Inti: 1 Spot

Tugas: 1 Spot

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 0

Skenario 5: Menskal On-Demand akan Instans pada node inti dan Instans Spot pada node tugas

Untuk menskal On-Demand akan Instans pada node inti dan Instans Spot pada node tugas, parameter penskalaan terkelola harus memenuhi persyaratan berikut:

  • B On-Demand atas harus sama dengan node inti maksimum.

  • Baik On-Demand batas dan node inti maksimum harus kurang dari batas maksimum.

Untuk mengaktifkan skenario ini dalam cluster yang terdiri dari grup instance, grup node inti harus menggunakan opsi On-Demand pembelian.

Skenario ini tidak berlaku jika Anda menggunakan penskalaan terkelola dengan label node dan membatasi proses aplikasi Anda untuk hanya berjalan pada ON_DEMAND node atau CORE node.

Contoh berikut menunjukkan skenario penskalaan On-Demand Instans pada node inti dan Instans Spot pada node tugas.

Status awal klaster Parameter penskalaan Perilaku penskalaan

Grup instans

Inti: 1 On-Demand

Tugas: 1 On-Demand dan 1 Spot

UnitType: Instans

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 7

MaximumCoreCapacityUnits: 7

Skala hingga 6 On-Demand unit pada node inti karena sudah ada 1 On-Demand unit pada node tugas dan batas maksimum untuk On-Demand adalah 7. Kemudian naikkan skala hingga 13 unit Spot pada simpul tugas.

Armada instans

Inti: 1 On-Demand

Tugas: 1 On-Demand dan 1 Spot

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 7

MaximumCoreCapacityUnits: 7

Skenario 6: CORE Instans skala untuk permintaan proses aplikasi dan TASK instans untuk permintaan pelaksana.

Skenario ini hanya berlaku jika Anda menggunakan penskalaan terkelola dengan label node dan membatasi proses aplikasi untuk hanya berjalan pada CORE node.

Untuk menskalakan CORE node berdasarkan permintaan proses aplikasi dan TASK node berdasarkan permintaan eksekutor, Anda harus mengatur konfigurasi berikut saat peluncuran cluster:

  • yarn.node-labels.enabled:true

  • yarn.node-labels.am.default-node-label-expression: 'CORE'

Jika Anda tidak menentukan ON_DEMAND batas dan parameter CORE node maksimum, kedua parameter default ke batas maksimum.

Jika ON_DEMAND node maksimum kurang dari batas maksimum, penskalaan terkelola menggunakan parameter ON_DEMAND node maksimum untuk membagi alokasi kapasitas antara ON_DEMAND dan SPOT node. Jika Anda mengatur parameter CORE node maksimum ke kurang dari atau sama dengan parameter kapasitas minimum, CORE node tetap statis pada kapasitas inti maksimum.

Contoh berikut menunjukkan skenario penskalaan instans CORE berdasarkan permintaan proses aplikasi dan instance TASK berdasarkan permintaan eksekutor.

Status awal klaster Parameter penskalaan Perilaku penskalaan

Grup instans

Inti: 1 On-Demand

Tugas: 1 On-Demand

UnitType: Instans

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 10

MaximumCoreCapacityUnits: 20

Menskalakan CORE node antara 1 dan 20 node berdasarkan permintaan proses aplikasi cluster menggunakan jenis pasar On-Demand atau Spot. Menskal TASK akan node berdasarkan permintaan eksekutor dan sisa kapasitas yang tersedia setelah Amazon EMR mengal CORE okasikan node.

Jumlah TASK node CORE dan yang diminta tidak akan melebihi maximumCapacity 20. Jumlah node inti sesuai permintaan dan node tugas sesuai permintaan tidak akan melebihi 10. maximumOnDemandCapacity Node inti atau tugas tambahan menggunakan tipe pasar Spot.

Armada instans

Inti: 1 On-Demand

Tugas: 1 On-Demand

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 10

MaximumCoreCapacityUnits: 20

Skenario 7: ON_DEMAND Instans skala untuk permintaan proses aplikasi dan SPOT instans untuk permintaan pelaksana.

Skenario ini hanya berlaku jika Anda menggunakan penskalaan terkelola dengan label node dan membatasi proses aplikasi untuk hanya berjalan pada ON_DEMAND node.

Untuk menskalakan ON_DEMAND node berdasarkan permintaan proses aplikasi dan SPOT node berdasarkan permintaan eksekutor, Anda harus mengatur konfigurasi berikut saat peluncuran cluster:

  • yarn.node-labels.enabled:true

  • yarn.node-labels.am.default-node-label-expression: 'ON_DEMAND'

Jika Anda tidak menentukan ON_DEMAND batas dan parameter CORE node maksimum, kedua parameter default ke batas maksimum.

Jika CORE node maksimum kurang dari batas maksimum, penskalaan terkelola menggunakan parameter CORE node maksimum untuk membagi alokasi kapasitas antara CORE dan TASK node. Jika Anda mengatur parameter CORE node maksimum ke kurang dari atau sama dengan parameter kapasitas minimum, CORE node tetap statis pada kapasitas inti maksimum.

Contoh berikut menunjukkan skenario penskalaan On-Demand Instans berdasarkan permintaan proses aplikasi dan instans Spot berdasarkan permintaan eksekutor.

Status awal klaster Parameter penskalaan Perilaku penskalaan

Grup instans

Inti: 1 On-Demand

Tugas: 1 On-Demand

UnitType: Instans

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 10

Menskalakan ON_DEMAND node antara 1 dan 20 node berdasarkan permintaan proses aplikasi cluster menggunakan jenis TASK node CORE atau. Menskal SPOT akan node berdasarkan permintaan eksekutor dan sisa kapasitas yang tersedia setelah Amazon EMR mengal ON_DEMAND okasikan node.

Jumlah SPOT node ON_DEMAND dan yang diminta tidak akan melebihi maximumCapacity 20. Jumlah node inti on-demand dan node inti spot yang diminta tidak akan melebihi 10. maximumCoreCapacity Node on-demand atau spot tambahan menggunakan tipe TASK node.

Armada instans

Inti: 1 On-Demand

Tugas: 1 On-Demand

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 10