Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Kesalahan sumber daya selama operasi klaster EMR Amazon
Kesalahan berikut ini biasanya disebabkan oleh sumber daya terbatas pada klaster. Panduan menjelaskan setiap kesalahan dan memberikan bantuan pemecahan masalah.
**Topics**
+ [Cluster EMR Amazon berakhir dengan NO\$1SLAVE\$1LEFT dan node inti FAILED\$1BY\$1MASTER](emr-cluster-NO_SLAVE_LEFT-FAILED_BY_MASTER.md)
+ [Kesalahan kluster Amazon EMR: Tidak dapat mereplikasi blok, hanya berhasil mereplikasi ke nol node.](enough-hdfs-space.md)
+ [Kesalahan klaster EMR Amazon: KUOTA EC2 TERLAMPAUI](emr-EC2.md)
+ [Kesalahan klaster Amazon EMR: Terlalu banyak kegagalan pengambilan](emr-troubleshoot-error-resource-1.md)
+ [Kesalahan kluster Amazon EMR: File hanya dapat direplikasi ke 0 node, bukan 1](emr-troubleshoot-error-resource-2.md)
+ [Kesalahan kluster Amazon EMR: Node yang terdaftar penolakan](emr-troubleshoot-error-resource-3.md)
+ [Kesalahan pelambatan dengan kluster EMR Amazon](emr-throttling-error.md)
+ [Kesalahan klaster EMR Amazon: Jenis instans tidak didukung](emr-INSTANCE_TYPE_NOT_SUPPORTED-error.md)
+ [Kesalahan cluster Amazon EMR: EC2 kehabisan kapasitas](emr-EC2_INSUFFICIENT_CAPACITY-error.md)
+ [Kesalahan kluster Amazon EMR: Kesalahan faktor replikasi HDFS](emr-hdfs-insufficient-replication.md)
+ [Kesalahan kluster Amazon EMR: Kesalahan ruang HDFS tidak mencukupi](emr-hdfs-insufficient-space.md)
# Cluster EMR Amazon berakhir dengan NO\$1SLAVE\$1LEFT dan node inti FAILED\$1BY\$1MASTER
Biasanya, hal ini terjadi karena proteksi pengakhiran dinonaktifkan, dan semua simpul inti melebihi kapasitas penyimpanan disk yang ditentukan oleh ambang pemanfaatan maksimum di klasifikasi konfigurasi `yarn-site`, yang sesuai dengan file `yarn-site.xml`. Nilainya adalah 90% secara default. Ketika pemanfaatan disk untuk node inti melebihi ambang batas pemanfaatan, layanan NodeManager kesehatan YARN melaporkan node sebagai. `UNHEALTHY` Sementara dalam keadaan ini, Amazon EMR menolak daftar node dan tidak mengalokasikan kontainer YARN untuk itu. Jika simpul tetap tidak sehat selama 45 menit, Amazon EMR menandai instans Amazon EC2 terkait untuk diakhiri sebagai `FAILED_BY_MASTER`. Ketika semua instans Amazon EC2 yang terkait dengan simpul inti ditandai untuk pengakhiran, klaster berakhir dengan status `NO_SLAVE_LEFT` karena tidak ada sumber daya untuk melaksanakan pekerjaan.
Melebihi pemanfaatan disk pada satu simpul inti mungkin menyebabkan reaksi berantai. Jika satu simpul melebihi ambang pemanfaatan disk akibat HDFS, simpul lain kemungkinan besar juga berada dekat ambang. Node pertama melebihi ambang batas pemanfaatan disk, jadi Amazon EMR menolak mencantumkannya. Hal ini meningkatkan beban pemanfaatan disk untuk node yang tersisa karena mereka mulai mereplikasi data HDFS di antara mereka sendiri yang hilang pada node deny-listed. Setiap simpul kemudian menjadi `UNHEALTHY` dengan cara yang sama, dan klaster akhirnya berakhir.
## Praktik terbaik dan rekomendasi
### Mengkonfigurasi perangkat keras klaster dengan penyimpanan yang memadai
Ketika Anda membuat sebuah klaster, pastikan bahwa ada cukup simpul inti dan masing-masing memiliki penyimpanan instans serta volume penyimpanan EBS yang memadai untuk HDFS. Untuk informasi selengkapnya, lihat [Menghitung kapasitas HDFS yang dibutuhkan dari sebuah klaster](emr-plan-instances-guidelines.md#emr-plan-instances-hdfs). Anda juga dapat menambahkan instans inti ke grup instans yang ada secara manual atau dengan menggunakan penskalaan otomatis. Instans yang baru memiliki konfigurasi penyimpanan yang sama seperti instans lain dalam grup instans. Untuk informasi selengkapnya, lihat [Gunakan penskalaan klaster EMR Amazon untuk menyesuaikan perubahan beban kerja](emr-scale-on-demand.md).
### Aktifkan perlindungan penghentian
Aktifkan perlindungan penghentian Dengan cara ini, jika node inti ditolak terdaftar, Anda dapat terhubung ke instans Amazon EC2 terkait menggunakan SSH untuk memecahkan masalah dan memulihkan data. Jika Anda mengaktifkan proteksi pengakhiran, harap diingat bahwa Amazon EMR tidak menggantikan instans Amazon EC2 dengan instans baru. Untuk informasi selengkapnya, lihat [Menggunakan perlindungan penghentian untuk melindungi kluster EMR Amazon Anda dari penutupan yang tidak disengaja](UsingEMR_TerminationProtection.md).
### Buat alarm untuk CloudWatch metrik MRUnhealthy Node
Metrik ini melaporkan jumlah simpul yang melaporkan Status `UNHEALTHY`. Ini setara dengan metrik YARN `mapred.resourcemanager.NoOfUnhealthyNodes`. Anda dapat mengatur notifikasi untuk alarm ini agar memperingatkan Anda tentang simpul yang tidak sehat sebelum batas waktu 45 menit tercapai. Untuk informasi selengkapnya, lihat [Memantau metrik Amazon EMR dengan CloudWatch](UsingEMR_ViewingMetrics.md).
### Ubah pengaturan menggunakan situs yarn
Pengaturan di bawah ini dapat disesuaikan sesuai dengan kebutuhan aplikasi Anda. Sebagai contoh, Anda mungkin ingin meningkatkan ambang pemanfaatan disk tempat simpul melaporkan `UNHEALTHY` dengan meningkatkan nilai `yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage`.
Anda dapat mengatur nilai-nilai ini ketika Anda membuat sebuah klaster menggunakan klasifikasi konfigurasi `yarn-site`. Untuk informasi selengkapnya, lihat [Mengkonfigurasi Aplikasi](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) dalam *Panduan Rilis Amazon EMR*. Anda juga dapat menyambung ke instans Amazon EC2 yang terkait dengan simpul inti menggunakan SSH, dan kemudian menambahkan nilai-nilai dalam `/etc/hadoop/conf.empty/yarn-site.xml` menggunakan editor teks. Setelah melakukan perubahan, Anda harus memulai ulang hadoop-yarn-nodemanager seperti yang ditunjukkan di bawah ini.
**penting**
Saat Anda memulai ulang NodeManager layanan, kontainer YARN aktif dimatikan kecuali `yarn.nodemanager.recovery.enabled` diatur untuk `true` menggunakan klasifikasi `yarn-site` konfigurasi saat Anda membuat cluster. Anda juga harus menentukan direktori tempat menyimpan status kontainer menggunakan properti `yarn.nodemanager.recovery.dir`.
```
sudo /sbin/stop hadoop-yarn-nodemanager
sudo /sbin/start hadoop-yarn-nodemanager
```
Untuk informasi selengkapnya tentang properti dan nilai default `yarn-site` saat ini, lihat [Pengaturan default YARN](http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-common/yarn-default.xml) dalam dokumentasi Apache Hadoop.
| Properti | Nilai default | Deskripsi |
| --- | --- | --- |
| benang.nodemanager. disk-health-checker.interval-ms | 120000 | Frekuensi (dalam detik) yang dijalankan oleh pemeriksa kesehatan disk. |
| benang.nodemanager. disk-health-checker. min-healthy-disks | 0,25 | Fraksi minimum dari jumlah disk yang harus sehat NodeManager untuk meluncurkan wadah baru. Hal ini sesuai dengan kedua yarn.nodemanager.local-dirs (secara default, `/mnt/yarn` di Amazon EMR) dan yarn.nodemanager.log-dirs (secara default `/var/log/hadoop-yarn/containers`, yang symlinked ke `mnt/var/log/hadoop-yarn/containers` di Amazon EMR). |
| `yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage` | 90.0 | Persentase maksimum pemanfaatan ruang disk yang diizinkan setelah disk ditandai sebagai buruk. Nilai dapat berkisar dari 0,0 hingga 100,0. Jika nilainya lebih besar dari atau sama dengan 100, NodeManager cek untuk disk penuh. Ini berlaku baik untuk `yarn-nodemanager.local-dirs` dan `yarn.nodemanager.log-dirs`. |
| `yarn.nodemanager.disk-health-checker.min-free-space-per-disk-mb` | 0 | Ruang minimum yang mesti tersedia pada disk agar dapat digunakan. Ini berlaku baik untuk `yarn-nodemanager.local-dirs` dan `yarn.nodemanager.log-dirs`. |
# Kesalahan kluster Amazon EMR: Tidak dapat mereplikasi blok, hanya berhasil mereplikasi ke nol node.
Kesalahan, “Tidak dapat mereplikasi blok, hanya berhasil mereplikasi ke nol simpul.” biasanya terjadi ketika sebuah klaster tidak memiliki penyimpanan HDFS yang cukup. Kesalahan ini terjadi ketika Anda menghasilkan lebih banyak data di klaster Anda daripada yang dapat disimpan dalam HDFS. Anda melihat kesalahan ini hanya saat klaster berjalan, karena ketika pekerjaan berakhir klaster akan merilis ruang HDFS yang digunakan.
Jumlah ruang HDFS yang tersedia untuk klaster bergantung pada jumlah dan tipe instans Amazon EC2 yang digunakan sebagai simpul inti. Simpul tugas tidak digunakan untuk penyimpanan HDFS. Semua ruang disk pada setiap instans Amazon EC2, termasuk volume penyimpanan EBS terpasang, tersedia untuk HDFS. Untuk informasi selengkapnya tentang jumlah penyimpanan lokal untuk setiap jenis instans EC2, lihat [Jenis dan keluarga instans](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) di Panduan Pengguna *Amazon EC2*.
Faktor lain yang dapat mempengaruhi jumlah ruang HDFS yang tersedia adalah faktor replikasi, yang merupakan jumlah salinan dari setiap blok data yang disimpan dalam HDFS untuk redundansi. Faktor replikasi meningkat dengan jumlah simpul dalam klaster: ada 3 salinan dari setiap blok data untuk klaster dengan 10 simpul atau lebih, 2 salinan dari setiap blok untuk klaster dengan 4 sampai 9 simpul, dan 1 salinan (tidak ada redundansi) untuk klaster dengan 3 simpul atau kurang. Total ruang HDFS yang tersedia dibagi dengan faktor replikasi. Dalam beberapa kasus, seperti meningkatkan jumlah simpul dari 9 ke 10, peningkatan faktor replikasi dapat benar-benar menyebabkan jumlah ruang HDFS yang tersedia berkurang.
Sebagai contoh, sebuah klaster dengan sepuluh simpul inti tipe m1.large akan memiliki 2833 GB ruang yang tersedia untuk HDFS ((10 simpul X 850 GB per simpul)/faktor replikasi 3).
Jika klaster melebihi jumlah ruang yang tersedia untuk HDFS, Anda dapat menambahkan simpul inti tambahan untuk klaster Anda atau menggunakan kompresi data untuk membuat lebih banyak ruang HDFS. Jika klaster Anda dapat dihentikan dan dimulai ulang, Anda dapat mempertimbangkan menggunakan simpul inti tipe instans Amazon EC2 yang lebih besar. Anda juga dapat mempertimbangkan menyesuaikan faktor replikasi. Namun, harap diingat bahwa penurunan faktor replikasi akan mengurangi redundansi data HDFS dan kemampuan pemulihan klaster Anda dari kehilangan atau kerusakan blok HDFS.
# Kesalahan klaster EMR Amazon: KUOTA EC2 TERLAMPAUI
Jika Anda mendapatkan pesan `EC2 QUOTA EXCEEDED`, mungkin ada beberapa penyebab. Tergantung pada perbedaan konfigurasi, mungkin diperlukan waktu hingga 5-20 menit bagi klaster sebelumnya untuk berakhir dan melepaskan sumber daya yang dialokasikan. Jika Anda mendapatkan kesalahan `EC2 QUOTA EXCEEDED` ketika Anda mencoba untuk meluncurkan sebuah klaster, mungkin itu karena sumber daya dari klaster yang baru berakhir belum dirilis. Pesan ini juga dapat disebabkan oleh perubahan ukuran grup instans atau armada instans ke ukuran target yang lebih besar daripada kuota instans saat ini untuk akun tersebut. Hal ini dapat terjadi secara manual atau otomatis melalui penskalaan otomatis.
Pertimbangkan opsi berikut untuk menyelesaikan masalah:
+ Ikuti petunjuk dalam [kuota AWS layanan](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) di *Referensi Umum Amazon Web*untuk meminta peningkatan batas layanan. Bagi sebagian orang APIs, menyiapkan CloudWatch acara mungkin merupakan pilihan yang lebih baik daripada meningkatkan batas. Untuk detail selengkapnya, lihat [Kapan mengatur acara EMR di CloudWatch](emr-service-limits-cloudwatch-events.md).
+ Jika satu klaster atau lebih yang sedang berjalan tidak pada kapasitas yang ditentukan, ubah ukuran grup instans atau kurangi kapasitas target pada armada instans untuk klaster yang sedang berjalan.
+ Membuat klaster dengan lebih sedikit instans EC2 atau kapasitas target yang lebih rendah.
# Kesalahan klaster Amazon EMR: Terlalu banyak kegagalan pengambilan
Adanya pesan kesalahan ”**Terlalu banyak kegagalan mengambil**“ atau ”**Kesalahan saat membaca output tugas**“ dalam log langkah atau upaya tugas menunjukkan bahwa tugas tersebut bergantung pada output tugas lain. Hal ini sering terjadi ketika tugas peredaman berada dalam antrean untuk dieksekusi dan membutuhkan output dari satu atau lebih tugas pemetaan dan outputnya belum tersedia.
Ada beberapa alasan output mungkin tidak tersedia:
+ Tugas prasyarat masih memproses. Hal ini seringkali berupa tugas pemetaan.
+ Data mungkin tidak tersedia karena konektivitas jaringan yang buruk jika data terletak pada instans yang berbeda.
+ Jika HDFS digunakan untuk mengambil output, mungkin ada masalah dengan HDFS.
Penyebab paling umum dari kesalahan ini adalah bahwa tugas sebelumnya masih diproses. Hal ini mungkin terjadi jika kesalahan muncul saat tugas peredaman mencoba berjalan untuk pertama kalinya. Anda dapat memeriksa apakah hal ini yang terjadi dengan meninjau log syslog untuk langkah klaster yang mengembalikan kesalahan. Jika syslog menunjukkan adanya kemajuan tugas pemetaan dan peredaman, ini menunjukkan bahwa fase peredaman telah dimulai saat ada tugas pemetaan yang belum selesai.
Satu hal yang harus dicari dalam log adalah persentase kemajuan pemetaan yang mencapai 100% dan kemudian turun kembali ke nilai yang lebih rendah. Ketika persentase pemetaan mencapai 100%, ini tidak berarti bahwa semua tugas pemetaan selesai. Ini hanya berarti bahwa Hadoop mengeksekusi semua tugas pemetaan. Jika nilai ini turun kembali di bawah 100%, itu berarti bahwa tugas pemetaan telah gagal dan, tergantung pada konfigurasi, Hadoop dapat mencoba untuk menjadwalkan ulang tugas tersebut. Jika persentase peta tetap 100% di log, lihat CloudWatch metrik, khususnya`RunningMapTasks`, untuk memeriksa apakah tugas peta masih diproses. Anda juga dapat menemukan informasi ini menggunakan antarmuka web Hadoop pada simpul utama.
Jika Anda melihat masalah ini, ada beberapa hal yang dapat Anda coba:
+ Instruksikan fase peredaman untuk menunggu lebih lama sebelum mulai. Anda dapat melakukan ini dengan mengubah pengaturan konfigurasi Hadoop mapred.reduce.slowstart.completed.maps ke waktu yang lebih lama. Untuk informasi selengkapnya, lihat [Buat tindakan bootstrap untuk menginstal perangkat lunak tambahan dengan cluster EMR Amazon](emr-plan-bootstrap.md).
+ Cocokkan jumlah peredam dengan kemampuan peredam total di klaster tersebut. Anda melakukan ini dengan menyesuaikan pengaturan konfigurasi Hadoop mapred.reduce.tasks untuk pekerjaan tersebut.
+ Gunakan kode kelas combiner untuk meminimalisir jumlah output yang perlu diambil.
+ Periksa bahwa tidak ada masalah dengan layanan Amazon EC2 yang mempengaruhi performa jaringan klaster. Anda dapat melakukannya menggunakan [Service Health Dashboard](https://status.aws.amazon.com/).
+ Meninjau sumber daya CPU dan memori instans di klaster Anda untuk memastikan bahwa pemrosesan data Anda tidak membuat sumber daya simpul Anda kewalahan. Untuk informasi selengkapnya, lihat [Konfigurasikan perangkat keras dan jaringan cluster Amazon EMR](emr-plan-instances.md).
+ Periksa versi Amazon Machine Image (AMI) yang digunakan dalam klaster Amazon EMR Anda. Jika versinya adalah versi 2.3.0 hingga 2.4.4 inklusif, perbarui ke versi yang lebih baru. Versi AMI dalam kisaran tertentu menggunakan versi Jetty yang mungkin gagal memberikan output dari fase pemetaan. Kesalahan pengambilan terjadi ketika peredam tidak dapat memperoleh output dari fase pemetaan.
Jetty adalah server HTTP sumber terbuka yang digunakan untuk komunikasi antar mesin dalam klaster Hadoop.
# Kesalahan kluster Amazon EMR: File hanya dapat direplikasi ke 0 node, bukan 1
Ketika file ditulis ke HDFS, file tersebut direplikasi ke beberapa simpul inti. Ketika Anda melihat kesalahan ini, itu berarti bahwa NameNode daemon tidak memiliki DataNode instance yang tersedia untuk menulis data dalam HDFS. Dengan kata lain, tidak terjadi replikasi blok. Kesalahan ini dapat disebabkan oleh sejumlah masalah:
+ Sistem berkas HDFS mungkin telah kehabisan ruang. Ini adalah penyebab yang paling mungkin.
+ DataNode Contoh mungkin tidak tersedia saat pekerjaan dijalankan.
+ DataNode instance mungkin telah diblokir dari komunikasi dengan node master.
+ Instans dalam grup instans inti mungkin tidak tersedia.
+ Izin mungkin hilang. Misalnya, JobTracker daemon mungkin tidak memiliki izin untuk membuat informasi pelacak pekerjaan.
+ Pengaturan ruang cadangan untuk sebuah DataNode instans mungkin tidak cukup. Periksa apakah hal ini yang terjadi dengan memeriksa pengaturan konfigurasi dfs.datanode.du.reserved.
Untuk memeriksa apakah masalah ini disebabkan oleh HDFS kehabisan ruang disk, lihat `HDFSUtilization` metrik di CloudWatch. Jika nilai ini terlalu tinggi, Anda dapat menambahkan simpul inti tambahan untuk klaster tersebut. Jika Anda memiliki cluster yang menurut Anda mungkin kehabisan ruang disk HDFS, Anda dapat mengatur alarm CloudWatch untuk mengingatkan Anda ketika nilai `HDFSUtilization` naik di atas tingkat tertentu. Untuk informasi selengkapnya, lihat [Mengubah ukuran cluster EMR Amazon yang sedang berjalan secara manual](emr-manage-resize.md) dan [Memantau metrik Amazon EMR dengan CloudWatch](UsingEMR_ViewingMetrics.md).
Jika HDFS kehabisan ruang bukan masalahnya, periksa log, DataNode log, dan konektivitas jaringan untuk masalah lain yang dapat mencegah HDFS mereplikasi data. NameNode Untuk informasi selengkapnya, lihat [Lihat file log EMR Amazon](emr-manage-view-web-log-files.md).
# Kesalahan kluster Amazon EMR: Node yang terdaftar penolakan
NodeManager Daemon bertanggung jawab untuk meluncurkan dan mengelola kontainer pada node inti dan tugas. Kontainer dialokasikan ke NodeManager daemon oleh ResourceManager daemon yang berjalan pada node master. ResourceManager Memonitor NodeManager simpul melalui detak jantung.
Ada beberapa situasi di mana ResourceManager daemon menolak mencantumkan a NodeManager, menghapusnya dari kumpulan node yang tersedia untuk memproses tugas:
+ Jika NodeManager belum mengirim detak jantung ke ResourceManager daemon dalam 10 menit terakhir (600.000 milidetik). Periode waktu ini dapat dikonfigurasi menggunakan pengaturan konfigurasi `yarn.nm.liveness-monitor.expiry-interval-ms`. Untuk informasi selengkapnya tentang mengubah klasifikasi konfigurasi Yarn, lihat [Mengkonfigurasi aplikasi](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) dalam *Panduan Rilis Amazon EMR*.
+ NodeManager memeriksa kesehatan disk yang ditentukan oleh `yarn.nodemanager.local-dirs` dan`yarn.nodemanager.log-dirs`. Pemeriksaan ini termasuk izin dan ruang disk kosong (< 90%). Jika disk gagal memeriksa, NodeManager berhenti menggunakan disk tertentu tetapi masih melaporkan status node sebagai sehat. Jika sejumlah disk gagal dalam pemeriksaan, node dilaporkan tidak sehat ke wadah baru ResourceManager dan wadah baru tidak ditetapkan ke node.
Master aplikasi juga dapat menolak daftar NodeManager node jika memiliki lebih dari tiga tugas yang gagal. Anda dapat mengubah ini ke nilai yang lebih tinggi menggunakan parameter konfigurasi `mapreduce.job.maxtaskfailures.per.tracker`. Pengaturan konfigurasi lain yang mungkin Anda ubah akan mengendalikan berapa kali percobaan tugas dilakukan sebelum menandainya sebagai gagal: `mapreduce.map.max.attempts` untuk tugas pemetaan dan `mapreduce.reduce.maxattempts` untuk tugas peredaman. Untuk informasi selengkapnya tentang mengubah klasifikasi konfigurasi, lihat [Mengkonfigurasi aplikasi](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) dalam *Panduan Rilis Amazon EMR*.
# Kesalahan pelambatan dengan kluster EMR Amazon
Kesalahan “Dibatasi dari *Amazon EC2* saat meluncurkan cluster” dan “Gagal menyediakan instance karena pembatasan dari" terjadi *Amazon EC2* ketika Amazon EMR tidak dapat menyelesaikan permintaan karena layanan lain telah membatasi aktivitas. Amazon EC2 adalah sumber yang paling umum dari kesalahan throttling, tetapi layanan lain mungkin menjadi penyebab kesalahan throttling. [AWS service limits](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) berlaku berdasarkan wilayah untuk meningkatkan performa, dan kesalahan throttling menunjukkan bahwa Anda telah melampaui batas layanan untuk akun Anda di Wilayah tersebut.
## Kemungkinan penyebab
Sumber yang paling umum dari kesalahan throttling Amazon EC2 adalah sejumlah besar instans klaster yang diluncurkan sehingga batas layanan Anda untuk instans EC2 terlampaui. Instans klaster dapat diluncurkan karena alasan berikut:
+ Klaster baru dibuat.
+ Klaster diubah ukurannya secara manual. Untuk informasi selengkapnya, lihat [Mengubah ukuran cluster EMR Amazon yang sedang berjalan secara manual](emr-manage-resize.md).
+ Grup instans dalam sebuah klaster menambahkan instans (menskalakan keluar) sebagai hasil dari aturan penskalaan otomatis. Untuk informasi selengkapnya, lihat [Memahami aturan penskalaan otomatis](emr-automatic-scaling.md#emr-scaling-rules).
+ Armada instans dalam sebuah klaster menambahkan instans untuk memenuhi kapasitas target yang meningkat. Untuk informasi selengkapnya, lihat [Merencanakan dan mengonfigurasi armada instans untuk klaster EMR Amazon](emr-instance-fleet.md).
Kemungkinan lain adalah bahwa frekuensi atau jenis permintaan API yang dibuat untuk Amazon EC2 mengakibatkan kesalahan throttling. Untuk informasi lebih lanjut tentang cara Amazon EC2 melakukan throttling permintaan API, lihat [Tingkat permintaan API kueri](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/query-api-troubleshooting.html#api-request-rate) di *Referensi API Amazon EC2*.
## Solusi
Pertimbangkan solusi berikut:
+ Ikuti petunjuk dalam [kuota AWS layanan](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) di *Referensi Umum Amazon Web*untuk meminta peningkatan batas layanan. Bagi sebagian orang APIs, menyiapkan CloudWatch acara mungkin merupakan pilihan yang lebih baik daripada meningkatkan batas. Untuk detail selengkapnya, lihat [Kapan mengatur acara EMR di CloudWatch](emr-service-limits-cloudwatch-events.md).
+ Jika Anda memiliki klaster yang diluncurkan pada jadwal yang sama—misalnya, di awal jam—pertimbangkan waktu mulai yang mengejutkan.
+ Jika Anda memiliki klaster yang diberi ukuran untuk permintaan puncak, dan Anda secara berkala memiliki kapasitas instans, pertimbangkan untuk menentukan penskalaan otomatis untuk menambahkan dan menghapus instans sesuai permintaan. Dengan cara ini, instans digunakan secara lebih efisien, dan tergantung pada profil permintaan, kemungkinan lebih sedikit instans yang diminta pada waktu tertentu di akun. Untuk informasi selengkapnya, lihat [Menggunakan penskalaan otomatis dengan kebijakan khusus untuk grup instans di Amazon EMR](emr-automatic-scaling.md).
# Kesalahan klaster EMR Amazon: Jenis instans tidak didukung
Jika Anda membuat klaster, dan gagal dengan pesan kesalahan “Jenis instans yang diminta tidak *InstanceType* didukung di Zona Ketersediaan yang diminta,” artinya Anda membuat klaster dan menetapkan jenis instans untuk satu atau beberapa grup instans yang tidak didukung oleh EMR Amazon di Wilayah dan Zona Ketersediaan tempat klaster dibuat. Amazon EMR dapat mendukung sebuah tipe instans di satu Availability Zone dalam suatu Wilayah dan tidak di wilayah lain. Subnet yang Anda pilih untuk sebuah klaster menentukan Availability Zone di dalam Wilayah tersebut.
## Solusi
**Menentukan jenis instans yang tersedia di Availability Zone menggunakan AWS CLI**
+ Gunakan perintah `ec2 run-instances` dengan opsi `--dry-run`. Pada contoh di bawah ini, ganti *m5.xlarge* dengan tipe instance yang ingin Anda gunakan, *ami-035be7bafff33b6b6* dengan AMI yang terkait dengan jenis instance tersebut, dan *subnet-12ab3c45* dengan subnet di Availability Zone yang ingin Anda kueri.
```
aws ec2 run-instances --instance-type m5.xlarge --dry-run --image-id ami-035be7bafff33b6b6 --subnet-id subnet-12ab3c45
```
Untuk petunjuk tentang menemukan ID AMI, lihat [Temukan AMI Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/finding-an-ami.html). Untuk menemukan ID subnet, Anda dapat menggunakan perintah [describe-subnets](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-subnets.html).
Untuk mempelajari lebih lanjut tentang cara menemukan jenis instans yang tersedia, lihat [Menemukan jenis instans Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-discovery.html).
Setelah Anda menentukan tipe instans yang tersedia, Anda dapat melakukan hal-hal berikut:
+ Buat klaster di Wilayah dan Subnet EC2 yang sama, dan pilih tipe instans yang berbeda dengan kemampuan yang sama dengan pilihan awal Anda. Untuk daftar tipe instans yang didukung, lihat [Jenis instans yang didukung dengan Amazon EMR](emr-supported-instance-types.md). Untuk membandingkan kemampuan tipe instans EC2, lihat [Tipe instans Amazon EC2](https://aws.amazon.com/ec2/instance-types/).
+ Pilih subnet untuk klaster di Availability Zone tempat tipe instans tersebut tersedia dan didukung oleh Amazon EMR.
**Mengurangi kegagalan peluncuran cluster armada instance karena jenis instans utama yang tidak didukung di Amazon EMR**
Node primer sangat penting dalam kluster EMR Amazon. Peluncuran kluster EMR mungkin gagal dengan `instance type not supported` kesalahan saat Amazon EMR mencoba meluncurkan klaster di Availability Zone jika jenis instans utama tidak didukung. Pemilihan Availability Zone yang disempurnakan untuk cluster armada instance di Amazon EMR secara otomatis menyaring AZs tidak didukung untuk jenis instans utama yang Anda tentukan dalam konfigurasi cluster. Ini berarti Amazon EMR tidak akan memilih Availability Zone di mana jenis instans utama yang dikonfigurasi tidak didukung, yang mencegah kegagalan peluncuran klaster karena jenis instans yang tidak didukung.
Untuk mengaktifkan peningkatan ini, tambahkan izin yang diperlukan ke peran atau kebijakan layanan untuk klaster Anda. Versi terbaru `AmazonEMRServicePolicy_v2` menyertakan izin ini, jadi jika Anda menggunakan kebijakan itu, peningkatan sudah tersedia. Jika Anda menggunakan peran atau kebijakan layanan kustom, tambahkan izin `ec2:DescribeInstanceTypeOfferings` saat meluncurkan klaster Anda.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:DescribeInstanceTypeOfferings"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Sid": "AllowEC2Describeinstancetypeofferings"
}
]
}
```
------
# Kesalahan cluster Amazon EMR: EC2 kehabisan kapasitas
*EC2 berada di luar kapasitas untuk *InstanceType** kesalahan terjadi saat Anda mencoba membuat klaster, atau menambahkan instance ke klaster, di Availability Zone yang tidak memiliki jenis instans EC2 yang ditentukan lagi. Subnet yang Anda pilih untuk sebuah klaster menentukan Availability Zone.
Untuk membuat klaster baru, lakukan salah satu dari hal berikut:
+ Tentukan tipe instans yang berbeda dengan kemampuan serupa
+ Buat klaster di Wilayah yang berbeda
+ Pilih subnet di Availability Zone tempat tipe instans yang Anda inginkan mungkin tersedia.
Untuk menambahkan instans ke klaster yang sedang berjalan, lakukan salah satu hal berikut:
+ Ubah konfigurasi grup instans atau konfigurasi armada instans untuk menambahkan tipe instans yang tersedia dengan kemampuan serupa. Untuk daftar tipe instans yang didukung, lihat [Jenis instans yang didukung dengan Amazon EMR](emr-supported-instance-types.md). Untuk membandingkan kemampuan tipe instans EC2, lihat [Tipe instans Amazon EC2](https://aws.amazon.com/ec2/instance-types/).
+ Akhiri klaster dan buat kembali klaster tersebut di Availability Zone tempat tipe instans tersebut tersedia.
# Kesalahan kluster Amazon EMR: Kesalahan faktor replikasi HDFS
Saat Anda menghapus node inti dari [grup instans](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-uniform-instance-group.html) inti atau [armada instans](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-fleet.html), Amazon EMR mungkin mengalami kesalahan replikasi HDFS. Kesalahan ini terjadi ketika Anda menghapus node inti dan jumlah node inti berada di bawah [faktor dfs.replication](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hdfs-config.html) yang dikonfigurasi untuk Hadoop Distributed File System (HDFS). Dengan demikian, Amazon EMR tidak dapat melakukan operasi dengan aman. Untuk menentukan nilai default `dfs.replication` konfigurasi, konfigurasi [HDFS](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hdfs-config.html).
## Kemungkinan penyebab
Lihat berikut ini untuk kemungkinan penyebab kesalahan faktor replikasi HDFS:
+ Jika Anda [mengubah ukuran grup instans inti atau armada instance secara manual](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-resize.html) di bawah `dfs.replication` faktor yang dikonfigurasi.
+ Kebijakan Anda untuk [penskalaan terkelola](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-scaling.html) atau [penskalaan otomatis](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-automatic-scaling.html) memungkinkan penskalaan untuk mengurangi jumlah node inti di bawah ambang batas. `dfs.replication`
+ Kesalahan ini juga dapat terjadi jika Amazon EMR mencoba [mengganti](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-node-replacement.html) node inti yang tidak sehat ketika cluster memiliki jumlah node inti minimal yang ditentukan oleh. []()
## Solusi dan praktik terbaik
Lihat berikut ini untuk solusi dan praktik terbaik:
+ Saat Anda mengubah ukuran cluster EMR Amazon secara manual, jangan turunkan di bawah `dfs.replication` karena Amazon EMR tidak dapat menyelesaikan pengubahan ukuran dengan aman.
+ Saat Anda menggunakan penskalaan terkelola atau penskalaan otomatis, pastikan kapasitas minimum klaster Anda tidak lebih rendah dari faktornya. `dfs.replication`
+ Jumlah instance inti harus setidaknya `dfs.replication` ditambah satu. Ini memastikan bahwa Amazon EMR dapat berhasil mengganti node inti yang tidak sehat jika Anda mengaktifkan penggantian inti yang tidak sehat.
**penting**
Kegagalan node inti tunggal dapat menyebabkan hilangnya data HDFS jika Anda mengatur `dfs.replication` ke 1. Jika klaster Anda memiliki penyimpanan HDFS, sebaiknya Anda mengonfigurasi klaster dengan setidaknya empat node inti untuk beban kerja produksi guna menghindari kehilangan data dan juga menyetel `dfs.replication` faktornya menjadi minimal 2.
# Kesalahan kluster Amazon EMR: Kesalahan ruang HDFS tidak mencukupi
Kesalahan ruang yang tidak mencukupi Hadoop Distributed File System (HDFS) dapat terjadi jika Anda mencoba menghapus node inti, tetapi Amazon EMR tidak dapat menyelesaikan operasi dengan aman karena ruang yang tidak memadai yang tersisa di HDFS. Sebelum Amazon EMR menghapus node inti, semua data HDFS pada node harus ditransfer ke node inti lainnya untuk memastikan redundansi data. Namun, jika tidak ada cukup ruang pada node inti lainnya untuk replikasi, Amazon EMR tidak dapat menonaktifkan node dengan anggun.
## Kemungkinan penyebab
Lihat berikut ini untuk daftar kemungkinan penyebab kesalahan ruang HDFS tidak mencukupi:
+ Jika Anda secara manual menurunkan grup instans inti atau armada instans ketika tidak ada cukup ruang HDFS pada node yang tersisa untuk replikasi data sebelum skala turun.
+ Penskalaan terkelola atau penskalaan otomatis menurunkan grup instans inti atau armada instans ketika tidak ada cukup ruang HDFS untuk replikasi data.
+ Amazon EMR mencoba mengganti node inti yang tidak sehat tetapi tidak dapat mengganti node dengan aman karena ruang HDFS yang tidak mencukupi.
## Solusi dan praktik terbaik
Lihat berikut ini untuk solusi dan praktik terbaik:
+ Tingkatkan jumlah node inti di cluster EMR Amazon Anda. Jika Anda menggunakan penskalaan terkelola atau penskalaan otomatis, tingkatkan kapasitas minimum node inti Anda.
+ Gunakan volume EBS yang lebih besar untuk node inti Anda saat Anda membuat cluster EMR Anda.
+ Hapus data HDFS yang tidak dibutuhkan di kluster EMR Anda. Kami menyarankan Anda mengatur CloudWatch alarm untuk memantau `HDFSUtilization` metrik di klaster Anda untuk mengetahui apakah kluster EMR Anda kekurangan ruang.