E-MapReduce:FAQ

Apa yang dimaksud dengan restart stateful kluster?

Restart stateful kluster mencakup restart ResourceManager dan NodeManager. ResourceManager menyimpan informasi dasar dan status aplikasi. NodeManager menyimpan informasi dan status container yang sedang berjalan. ResourceManager dan NodeManager terus-menerus menyinkronkan statusnya ke sistem penyimpanan eksternal seperti ZooKeeper, LevelDB, dan Hadoop Distributed File System (HDFS). Status ResourceManager dan NodeManager dapat secara otomatis dimuat ulang dan dipulihkan setelah direstart. Hal ini memastikan bahwa status aplikasi dan container dapat secara otomatis dipulihkan setelah kluster ditingkatkan atau direstart. Dalam kebanyakan kasus, peningkatan atau restart kluster tidak terasa oleh aplikasi dan container.

Bagaimana cara mengaktifkan high availability (HA) ResourceManager?

Bagaimana cara mengonfigurasi hot update?

1. Konfigurasikan parameter utama.

   Anda dapat memeriksa atau mengonfigurasi parameter yang terkait dengan hot update pada tab Configure di halaman layanan YARN kluster di Konsol EMR. Tabel berikut menjelaskan parameter tersebut.

   Parameter	Deskripsi	Nilai yang direkomendasikan
   yarn.scheduler.configuration.store.class	Jenis backing store. Jika Anda mengatur parameter ini ke fs, sistem file digunakan sebagai backing store.	fs
   yarn.scheduler.configuration.max.version	Jumlah maksimum file konfigurasi yang dapat disimpan dalam sistem file. File konfigurasi berlebih akan secara otomatis dihapus jika jumlah file konfigurasi melebihi nilai parameter ini.	100
   yarn.scheduler.configuration.fs.path	Jalur tempat file capacity-scheduler.xml disimpan. Jika Anda tidak mengonfigurasi parameter ini, jalur penyimpanan akan dibuat secara otomatis. Jika tidak ada awalan yang ditentukan, jalur relatif sistem file default digunakan sebagai jalur penyimpanan.	/yarn/<Nama Kluster>/scheduler/conf Penting Ganti <Nama Kluster> dengan nama kluster tertentu. Beberapa kluster yang menggunakan layanan YARN mungkin menggunakan penyimpanan terdistribusi yang sama.

2. Lihat konfigurasi file capacity-scheduler.xml.

   • Metode 1 (RESTful API): Akses URL dengan format berikut: http://<rm-address>/ws/v1/cluster/scheduler-conf.

   • Metode 2 (HDFS): Akses jalur konfigurasi ${yarn.scheduler.configuration.fs.path}/capacity-scheduler.xml.<timestamp> untuk melihat konfigurasi file capacity-scheduler.xml. <timestamp> menunjukkan waktu pembuatan file capacity-scheduler.xml. File capacity-scheduler.xml dengan nilai timestamp terbesar adalah file konfigurasi terbaru.

3. Perbarui konfigurasi.

   Sebagai contoh, Anda dapat mengubah parameter yarn.scheduler.capacity.maximum-am-resource-percent dan menghapus parameter yarn.scheduler.capacity.xxx. Untuk menghapus parameter, cukup hapus field nilai parameter tersebut.

   curl -X PUT -H "Content-type: application/json" 'http://<rm-address>/ws/v1/cluster/scheduler-conf' -d '
   {
     "global-updates": [
       {
         "entry": [{
           "key":"yarn.scheduler.capacity.maximum-am-resource-percent",
           "value":"0.2"
         },{
           "key":"yarn.scheduler.capacity.xxx"
         }]
       }
     ]
   }'

Bagaimana cara menangani distribusi sumber daya yang tidak merata di antara aplikasi dalam suatu queue?

Lihat penggunaan sumber daya queue

Untuk melihat penggunaan sumber daya queue, periksa Used Capacity pada UI YARN. Nilai ini menunjukkan persentase sumber daya queue yang sedang digunakan, dihitung berdasarkan nilai penggunaan memori atau vCore yang lebih tinggi.

1. Akses UI YARN. Untuk detailnya, lihat Akses UI web komponen open source.

2. Pada halaman All Applications, klik ID job target.

3. Klik queue pada baris Queue.

   Bagian Application Queues menampilkan penggunaan sumber daya queue.

   Detail queue mencakup parameter seperti Queue State, Used Capacity, Configured Capacity, Configured Max Capacity, Effective Capacity, Absolute Used Capacity, dan Used Resources. Parameter Used Capacity menunjukkan penggunaan sumber daya saat ini, misalnya, <memory:896, vCores:1> (10,9%).

Akumulasi file log .out YARN

• Penyebab: Beberapa library dependensi Hadoop menggunakan Java Logging APIs untuk menghasilkan log, melewati pengaturan rotasi log4j. Standard error (stderr) dari daemon ini dialihkan ke file .out. Tanpa pembersihan otomatis, file-file ini menumpuk dan dapat memenuhi disk data.

• Solusi: Gunakan perintah head dan tail dengan timestamp log untuk memeriksa apakah log API Java ini mengonsumsi ruang disk berlebihan. Log ini biasanya berada pada level INFO dan tidak memengaruhi fungsionalitas komponen. Untuk mencegah kehabisan disk, Anda dapat menonaktifkan logging ini.

  Sebagai contoh, untuk mengoptimalkan Timeline Server dengan menonaktifkan logging dari library dependensi Jersey, ikuti langkah-langkah berikut:

  1. Jalankan perintah berikut untuk memantau file log .out yang terkait dengan hadoop-timelineserver- di jalur log YARN. Jalur log adalah /var/log/emr/yarn/ untuk kluster DataLake dan /mnt/disk1/log/hadoop-yarn untuk kluster Hadoop.

     tail /var/log/emr/yarn/*-hadoop-timelineserver-*.out

     Output log menunjukkan catatan dari komponen com.sun.jersey.

     xxx                     com.sun.jersey.server.wadl.generators.AbstractWadlGeneratorGrammarGenerator attachTypes
     INFO: Couldn't find grammar element for class javax.ws.rs.core.Response
     xxx                     com.sun.jersey.server.wadl.generators.AbstractWadlGeneratorGrammarGenerator attachTypes
     INFO: Couldn't find grammar element for class javax.ws.rs.core.Response
     xxx                     com.sun.jersey.server.wadl.generators.AbstractWadlGeneratorGrammarGenerator attachTypes
     INFO: Couldn't find grammar element for class javax.ws.rs.core.Response
                             com.sun.jersey.server.wadl.generators.AbstractWadlGeneratorGrammarGenerator attachTypes
     INFO: Couldn't find grammar element for class javax.ws.rs.core.Response
     xxx                     com.sun.jersey.server.wadl.generators.AbstractWadlGeneratorGrammarGenerator attachTypes
     INFO: Couldn't find grammar element for class javax.ws.rs.core.Response
     xxx                     com.sun.jersey.server.wadl.generators.AbstractWadlGeneratorGrammarGenerator attachTypes
     INFO: Couldn't find grammar element for class javax.ws.rs.core.Response

  2. Untuk menonaktifkan log level INFO dari library Jersey, buat file konfigurasi. Pada node EMR yang menjalankan Timeline Server, jalankan perintah berikut sebagai pengguna root untuk membuat file tersebut.

     sudo su root -c "echo 'com.sun.jersey.level = OFF' > $HADOOP_CONF_DIR/off-logging.properties"

  3. Di Konsol EMR, buka tab Configure untuk layanan YARN. Temukan parameter YARN_TIMELINESERVER_OPTS (atau yarn_timelineserver_opts untuk kluster Hadoop) dan tambahkan -Djava.util.logging.config.file=off-logging.properties ke nilai parameternya.

  4. Simpan konfigurasi dan restart Timeline Server agar perubahan berlaku. Pantau layanan tersebut. Jika Timeline Server berhasil dimulai dan log .out-nya tidak lagi menampilkan pesan dari com.sun.jersey, Anda telah berhasil menonaktifkan logging tersebut.

Bagaimana cara memeriksa apakah layanan ResourceManager normal?

Bagaimana cara mendapatkan status aplikasi?

Troubleshooting aplikasi

1. Periksa status aplikasi di halaman detail aplikasi atau dengan menggunakan REST API aplikasi.

   • Status aplikasi tidak ditemukan. Kemungkinan penyebabnya meliputi:

     • Proses client berhenti sebelum mengirimkan aplikasi ke YARN. Hal ini mungkin menunjukkan adanya masalah pada komponen sisi client, seperti BRS atau flowagent. Periksa log pengiriman client.

     • Client tidak dapat terhubung ke ResourceManager YARN. Verifikasi bahwa alamat ResourceManager benar dan tidak ada masalah jaringan. Masalah jaringan dapat mengakibatkan error berikut pada client: com.aliyun.emr.flow.agent.common.exceptions.EmrFlowException: ###[E40001,RESOURCE_MANAGER]: Failed to access to resource manager, cause: The stream is closed.

   • NEW_SAVING: Dalam keadaan ini, informasi aplikasi sedang ditulis ke penyimpanan status ZooKeeper. Jika aplikasi tetap dalam keadaan ini, kemungkinan penyebabnya meliputi:

     • Ada masalah dengan ZooKeeper. Periksa apakah layanan ZooKeeper berjalan dengan baik.

     • Ada masalah dalam membaca atau menulis data ke ZooKeeper. Untuk solusinya, lihat Apa yang harus saya lakukan jika ResourceManager berada dalam keadaan Standby dan tidak dapat secara otomatis beralih ke keadaan Active?

   • SUBMITTED: Keadaan ini jarang terjadi. Kemungkinan penyebabnya adalah scheduler Capacity terblokir karena kontensi lock dari terlalu banyak permintaan pembaruan node. Hal ini biasanya terjadi pada kluster berskala besar dan memerlukan optimasi proses. Untuk kasus terkait, lihat YARN-9618.

   • ACCEPTED: Periksa Diagnostics. Lakukan tindakan yang sesuai berdasarkan pesan yang diberikan.

     • Pesan error: "Queue's AM resource limit exceeded."

       • Kemungkinan penyebab: Jumlah sumber daya ApplicationMaster (AM) yang digunakan dan sumber daya AM yang diminta melebihi batas sumber daya AM untuk queue tersebut. Kondisi yang diperiksa di UI adalah: ${Used Application Master Resources} + ${AM Resource Request} < ${Max Application Master Resources}.

       • Solusi: Tingkatkan batas sumber daya AM untuk queue tersebut. Sebagai contoh, atur parameter yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent menjadi 0,5.

     • Pesan error: "User's AM resource limit exceeded."

       • Kemungkinan penyebab: Jumlah sumber daya AM yang digunakan oleh pengguna dan sumber daya AM yang diminta melebihi batas sumber daya AM per pengguna untuk queue tersebut.

       • Solusi: Tingkatkan rasio batas pengguna. Anda dapat mengubah nilai parameter yarn.scheduler.capacity.<queue-path>.user-limit-factor dan yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent.

     • Pesan error: "AM container is launched, waiting for AM container to Register with RM."

       • Kemungkinan penyebab: ApplicationMaster telah dimulai, tetapi inisialisasi internalnya belum selesai, misalnya karena timeout koneksi ZooKeeper.

       • Solusi: Periksa log ApplicationMaster.

     • Pesan error: "Application is Activated, waiting for resources to be assigned for AM."

       Lanjutkan ke Langkah 3 untuk menyelidiki mengapa permintaan sumber daya ApplicationMaster tidak terpenuhi.

   • RUNNING: Lanjutkan ke Langkah 2 untuk memeriksa apakah permintaan sumber daya container telah terpenuhi.

   • FAILED: Periksa diagnostics. Lakukan tindakan yang sesuai berdasarkan pesan yang diberikan.

     • Pesan kesalahan: "Batas maksimum aplikasi sistem telah tercapai; pengajuan aplikasi tidak dapat diterima."

       • Kemungkinan penyebab: Jumlah total aplikasi yang sedang berjalan di kluster telah melebihi batas yang dikonfigurasi (parameter: yarn.scheduler.capacity.maximum-applications, nilai default: 10000).

       • Solusi: Periksa metrik JMX untuk memverifikasi bahwa setiap queue memiliki jumlah aplikasi yang berjalan sesuai harapan. Identifikasi dan atasi aplikasi yang menyebabkan pengiriman berulang berlebihan. Jika semua aplikasi sah, pertimbangkan untuk meningkatkan nilai konfigurasi ini berdasarkan workload kluster.

     • Pesan error: "Application XXX submitted by user YYY to unknown queue: ZZZ"

       • Kemungkinan penyebab: Aplikasi dikirimkan ke queue yang tidak ada.

       • Solusi: Kirimkan aplikasi ke leaf queue yang ada.

     • Pesan error: "Application XXX submitted by user YYY to non-leaf queue: ZZZ"

       • Kemungkinan penyebab: Aplikasi dikirimkan ke parent queue.

       • Solusi: Kirimkan aplikasi ke leaf queue yang ada.

     • Pesan error: "Queue XXX is STOPPED. Cannot accept submission of application: YYY"

       • Kemungkinan penyebab: Aplikasi dikirimkan ke queue yang berstatus STOPPED atau DRAINING. Queue dalam keadaan ini sedang offline atau sedang di-decommission.

       • Solusi: Kirimkan aplikasi ke queue yang berstatus RUNNING.

     • Pesan kesalahan: "Antrean XXX sudah memiliki YYY aplikasi dan tidak dapat menerima pengajuan aplikasi: ZZZ"

       • Kemungkinan penyebab: Jumlah aplikasi dalam queue telah mencapai batasnya.

       • Solusi:

         1. Periksa apakah ada aplikasi bermasalah yang dikirimkan berulang kali ke queue tersebut.

         2. Sesuaikan konfigurasi: yarn.scheduler.capacity.<queue-path>.maximum-applications.

     • Pesan kesalahan: "Antrean XXX sudah memiliki YYY aplikasi dari pengguna ZZZ dan tidak dapat menerima pengiriman aplikasi: AAA"

       • Kemungkinan penyebab: Jumlah aplikasi dari pengguna tersebut telah mencapai batasnya.

       • Solusi:

         1. Periksa apakah pengguna tersebut mengirimkan aplikasi bermasalah secara berulang.

         2. Sesuaikan parameter konfigurasi berikut: yarn.scheduler.capacity.<queue-path>.maximum-applications, yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent, dan yarn.scheduler.capacity.<queue-path>.user-limit-factor.

2. Periksa apakah alokasi sumber daya YARN tidak lengkap.

   1. Di halaman daftar aplikasi, klik ID aplikasi untuk membuka halaman detailnya.

   2. Di daftar di bagian bawah halaman, klik AM-ID untuk membuka halaman App Attempt.

   3. Periksa daftar Total Outstanding Resource Requests untuk sumber daya yang tertunda. Atau, kueri dengan REST API PendingRequests.

      • Tidak ada sumber daya yang tertunda: Ini menunjukkan bahwa YARN telah menyelesaikan alokasi. Keluar dari pemeriksaan ini dan selidiki ApplicationMaster. Saat tidak ada sumber daya yang tertunda, bagian Total Outstanding Resource Requests menunjukkan 0 untuk semua metrik (misalnya, memory:0, vCores:0), dan tabel permintaan sumber daya di bawahnya kosong. Tabel ini mencakup kolom seperti Priority, ResourceName, Capability, dan NumContainers.

      • Ada sumber daya yang tertunda: Ini menunjukkan bahwa alokasi sumber daya YARN belum selesai. Lanjutkan ke langkah berikutnya.

3. Periksa batas sumber daya.

   Periksa sumber daya kluster atau queue. Lihat informasi sumber daya seperti Effective Max Resource dan Used Resources.

   1. Periksa apakah sumber daya kluster, queue, atau parent queue-nya telah habis.

   2. Periksa apakah dimensi sumber daya apa pun dalam leaf queue mendekati atau telah mencapai batasnya.

   3. Ketika utilisasi sumber daya kluster tinggi (misalnya, di atas 85%), kecepatan alokasi aplikasi dapat menurun. Hal ini dapat terjadi karena sebagian besar node tidak memiliki sumber daya yang tersedia. Ketika node tidak dapat memenuhi permintaan sumber daya, scheduler mungkin memesan permintaan tersebut. Sejumlah besar reservasi dapat memperlambat proses alokasi. Masalah ini juga dapat disebabkan oleh ketidakseimbangan antara sumber daya memori dan CPU. Misalnya, beberapa node mungkin memiliki memori yang tersedia tetapi tidak memiliki CPU yang tersedia, sedangkan yang lain memiliki CPU yang tersedia tetapi tidak memiliki memori yang tersedia.

4. Periksa apakah container gagal memulai meskipun sumber dayanya telah dialokasikan. Halaman App Attempt di UI web YARN menunjukkan jumlah container yang dialokasikan. Amati angka ini untuk periode singkat untuk melihat apakah angka tersebut berubah. Jika container gagal memulai, periksa log NodeManager atau container yang sesuai untuk menyelidiki kegagalannya.

5. Ubah tingkat log secara dinamis. Buka halaman Log Level di UI web YARN (http://RM_IP:8088/logLevel). Di field Class Name, masukkan nama kelas target (misalnya, kelas dalam paket org.apache.hadoop.yarn.server.resourcemanager.scheduler, seperti org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity). Di daftar drop-down Level, pilih DEBUG, lalu klik Set Log Level. Ini secara dinamis mengatur tingkat log untuk kelas yang ditentukan menjadi DEBUG.

   Penting

   Aktifkan logging DEBUG hanya saat Anda mereproduksi masalah tersebut. Durasi kurang dari satu menit biasanya sudah cukup, karena log dihasilkan sangat cepat. Setelah Anda mengambil log yang diperlukan, atur kembali tingkat log menjadi INFO.

Parameter untuk sumber daya maksimum yang tersedia

Perubahan konfigurasi YARN tidak berlaku

• Kemungkinan penyebab

  • Untuk konfigurasi yang tidak mendukung hot update, komponen terkait tidak direstart.

  • Untuk konfigurasi yang mendukung hot update, tindakan yang diperlukan tidak dilakukan.

• Solusi: Setelah memodifikasi konfigurasi, lakukan tindakan lanjutan yang tepat.

  File konfigurasi	Jenis	Tindakan
  capacity-scheduler.xml fair-scheduler.xml	Konfigurasi scheduler	Jalankan operasi refresh_queues pada ResourceManager.
  yarn-env.sh yarn-site.xml mapred-env.sh mapred-site.xml	Konfigurasi runtime komponen YARN	Restart komponen terkait. Sebagai contoh: Jika Anda memodifikasi parameter seperti YARN_RESOURCEMANAGER_HEAPSIZE di file yarn-env.sh atau yarn.resourcemanager.nodes.exclude-path di file yarn-site.xml, Anda harus merestart ResourceManager. Jika Anda memodifikasi parameter seperti YARN_NODEMANAGER_HEAPSIZE di file yarn-env.sh atau yarn.nodemanager.log-dirs di file yarn-site.xml, Anda harus merestart NodeManager. Jika Anda memodifikasi parameter seperti MAPRED_HISTORYSERVER_OPTS di file mapred-env.sh atau mapreduce.jobhistory.http.policys di file mapred-site.xml, Anda harus merestart MRHistoryServer.

Apa yang harus saya lakukan jika pesan error berikut dilaporkan untuk pengecualian yang terjadi pada client aplikasi: Exception while invoking getClusterNodes of class ApplicationClientProtocolPBClientImpl over rm2 after 1 fail over attempts. Trying to fail over immediately?

• Deskripsi masalah: ResourceManager aktif tidak dapat diakses. Log ResourceManager berisi informasi pengecualian berikut: WARN org.apache.hadoop.ipc.Server: Incorrect header or version mismatch from 10.33.**.**:53144 got version 6 expected version 9.

• Penyebab: Versi Hadoop yang lama digunakan. Versi remote procedure call (RPC) yang digunakan oleh client aplikasi tidak kompatibel dengan versi Hadoop.

• Solusi: Gunakan Hadoop versi yang kompatibel dengan versi RPC client aplikasi tersebut.

Apa yang harus saya lakukan jika ResourceManager tidak dapat secara otomatis beralih dari keadaan Standby ke keadaan Active?

Menyelesaikan error OOM ResourceManager

Mengapa lokalisasi gagal saat node mulai menjalankan job, dan mengapa log job tidak dapat dikumpulkan atau dihapus?

• Deskripsi masalah: Log NodeManager berisi informasi pengecualian berikut: java.io.IOException: Couldn't create proxy provider class org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider.

• Penyebab: Konfigurasi HDFS salah.

• Solusi:

  1. Informasi pengecualian tersebut dikemas dan bukan penyebab utama masalah. Untuk mengidentifikasi penyebab utamanya, Anda harus memeriksa log tingkat debug.

     • Di CLI untuk client Hadoop, Anda dapat menjalankan perintah seperti hadoop fs -ls / untuk mengakses Hadoop. Kemudian, jalankan perintah berikut untuk mengaktifkan debugging:

       export HADOOP_LOGLEVEL=DEBUG

     • Di lingkungan runtime dengan konfigurasi Log4j, tambahkan log4j.logger.org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider=DEBUG di akhir konfigurasi Log4j.

  2. Contoh pada gambar berikut menunjukkan bahwa penyebab utama masalah adalah pengguna memodifikasi konfigurasi NameServices. Pengguna mengubah emr-cluster menjadi hadoop-emr-cluster. Namun, node baru menggunakan konfigurasi NameServices asli setelah penskalaan keluar.

  3. Di tab Configure di halaman layanan HDFS kluster di Konsol EMR, periksa apakah parameter dikonfigurasi dengan benar.

Bagaimana cara menangani pengecualian lokalisasi sumber daya?

• Deskripsi masalah:

  • Container AM yang digunakan untuk memproses job gagal memulai, dan pesan error berikut dilaporkan:

    Application application_1412960082388_788293 failed 2 times due to AM Container for appattempt_1412960082388_788293_000002 exited with exitCode: -1000 due to: EPERM: Operation not permitted. The exception information is the diagnostic information about the failed job.

  • Terjadi error saat paket sumber daya aplikasi didekompresi setelah diunduh untuk lokalisasi sumber daya. Anda dapat memeriksa log NodeManager berikut:

    INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.ResourceLocalizationService: Failed to download rsrc { { hdfs://hadoopnnvip.cm6:9000/user/heyuan.lhy/apv/small_apv_20141128.tar.gz, 1417144849604, ARCHIVE, null },pending,[(container_1412960082388_788293_01_000001)],14170282104675332,DOWNLOADING}
    EPERM: Operation not permitted
            at org.apache.hadoop.io.nativeio.NativeIO$POSIX.chmodImpl(Native Method)
            at org.apache.hadoop.io.nativeio.NativeIO$POSIX.chmod(NativeIO.java:226)
            at org.apache.hadoop.fs.RawLocalFileSystem.setPermission(RawLocalFileSystem.java:629)
            at org.apache.hadoop.fs.DelegateToFileSystem.setPermission(DelegateToFileSystem.java:186)
            at org.apache.hadoop.fs.FilterFs.setPermission(FilterFs.java:235)
            at org.apache.hadoop.fs.FileContext$10.next(FileContext.java:949)
            at org.apache.hadoop.fs.FileContext$10.next(FileContext.java:945)
            at org.apache.hadoop.fs.FSLinkResolver.resolve(FSLinkResolver.java:90)
            at org.apache.hadoop.fs.FileContext.setPermission(FileContext.java:945)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:398)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:412)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:412)
            at org.apache.hadoop.yarn.util.FSDownload.call(FSDownload.java:352)
            at org.apache.hadoop.yarn.util.FSDownload.call(FSDownload.java:57)
            at java.util.concurrent.FutureTask.run(FutureTask.java:262)
            at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
            at java.util.concurrent.FutureTask.run(FutureTask.java:262)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
            at java.lang.Thread.run(Thread.java:744)

• Penyebab: Paket sumber daya aplikasi berisi soft link, yang mengakibatkan pengecualian lokalisasi sumber daya.

• Solusi: Hapus soft link yang terdapat dalam paket sumber daya aplikasi.

Apa yang harus saya lakukan jika pesan error "No space left on device" ditampilkan dan container gagal memulai atau berjalan?

Nama domain gagal diselesaikan di NodeManager atau selama menjalankan job. Apa yang harus saya lakukan?

• Deskripsi masalah: Pesan error berikut ditampilkan: java.net.UnknownHostException: Invalid host name: local host is: (unknown).

• Kemungkinan penyebab dan solusi:

  • Periksa apakah Domain Name System (DNS) server dikonfigurasi dengan benar.

    Jalankan perintah berikut untuk memeriksa konfigurasi server DNS:

    cat /etc/resolv.conf

  • Periksa apakah aturan yang diperlukan dikonfigurasi untuk Port 53 firewall.

    Jika aturan yang diperlukan dikonfigurasi, nonaktifkan firewall.

  • Periksa apakah layanan Name Service Cache Daemon (NSCD) diaktifkan untuk server DNS.

    Jalankan perintah berikut untuk memeriksa status layanan NSCD:

    systemctl status nscd

    Jika layanan NSCD diaktifkan untuk server DNS, jalankan perintah berikut untuk menonaktifkan layanan NSCD:

    systemctl stop nscd

Menangani error OOM NodeManager

Kegagalan startup NodeManager: Direktori cgroup hilang

• Pesan error: ResourceHandlerException: Unexpected: Cannot create yarn cgroup Subsystem:cpu Mount point:/proc/mounts User:hadoop Path:/sys/fs/cgroup/cpu/hadoop-yarn

• Penyebab: Restart instance ECS yang tidak terduga, sering disebabkan oleh cacat kernel (masalah yang diketahui pada versi 4.19.91-21.2.al7.x86_64), menghancurkan data in-memory cgroup CPU dan membuat cgroup tidak valid.

• Solusi: Modifikasi skrip bootstrap untuk grup node yang ada dan penskalaan keluar untuk membuat direktori cgroup dan konfigurasikan file rc.local agar secara otomatis membuat ulang direktori ini setiap kali instance dimulai.

  # enable cgroups
  mkdir -p /sys/fs/cgroup/cpu/hadoop-yarn
  chown -R hadoop:hadoop /sys/fs/cgroup/cpu/hadoop-yarn
  # enable cgroups after reboot
  echo "mkdir -p /sys/fs/cgroup/cpu/hadoop-yarn" >> /etc/rc.d/rc.local
  echo "chown -R hadoop:hadoop /sys/fs/cgroup/cpu/hadoop-yarn" >> /etc/rc.d/rc.local
  chmod +x /etc/rc.d/rc.local

Konfigurasi sumber daya NodeManager tidak berlaku

• Deskripsi: Setelah memodifikasi parameter yarn.nodemanager.resource.cpu-vcores dan yarn.nodemanager.resource.memory-mb, menyimpan konfigurasi, dan merestart NodeManager, jumlah sumber daya tidak diperbarui.

• Penyebab: Parameter ini harus diterapkan di tingkat grup node karena instance dalam grup node dapat memiliki spesifikasi CPU dan memori yang berbeda.

• Solusi: Di Konsol E-MapReduce (EMR), terapkan pengaturan sumber daya ke grup node NodeManager. Untuk informasi lebih lanjut, lihat Mengelola item konfigurasi. Di tab Configure layanan YARN, alihkan filter ke Node Group Configuration. Pilih grup node target, seperti emr-core (CORE), dan modifikasi parameter pada sub-tab yarn-site.xml.

Menangani node yang tidak sehat

• Penyebab

  • Pemeriksa kesehatan disk menandai node sebagai tidak sehat jika rasio direktori sehat terhadap total direktori berada di bawah ambang batas yang ditentukan oleh parameter yarn.nodemanager.disk-health-checker.min-healthy-disks di yarn-site.xml (default: 0,25). Misalnya, pada node NodeManager dengan empat disk, node menjadi tidak sehat hanya jika direktori pada keempat disk tersebut tidak sehat. Jika tidak, laporan status NodeManager hanya melaporkan bahwa local-dirs are bad atau log-dirs are bad. Untuk informasi lebih lanjut, lihat Apa yang harus dilakukan jika pesan "local-dirs are bad" atau "log-dirs are bad" dilaporkan?.

  • Masalah yang dilaporkan oleh skrip pemeriksaan kesehatan NodeManager: Pemeriksaan ini dinonaktifkan secara default. Anda dapat mengaktifkan pemeriksaan ini dengan mengatur parameter yarn.nodemanager.health-checker.script.path di yarn-site.xml ke jalur skrip pemeriksaan kesehatan.

• Solusi

  • Untuk masalah disk, lihat Apa yang harus dilakukan jika pesan "local-dirs are bad" atau "log-dirs are bad" dilaporkan?.

  • Untuk masalah yang dilaporkan oleh skrip pemeriksaan kesehatan, lakukan troubleshooting berdasarkan skrip kustom Anda.

Masalah disk node: 'local-dirs are bad' atau 'log-dirs are bad'

• Penyebab: Pemeriksa kesehatan disk secara berkala memverifikasi bahwa local-dirs (direktori cache untuk dependensi task, data antara, dan file lainnya) dan log-dirs (direktori untuk log eksekusi task) memenuhi beberapa kondisi. Jika direktori gagal memenuhi kondisi apa pun, sistem menandainya sebagai buruk.

  • Dapat dibaca

  • Dapat ditulis

  • Dapat dieksekusi

  • Penggunaan disk berada di bawah ambang batas yang dikonfigurasi. Ini dikontrol oleh parameter yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage di file yarn-site.xml, yang default-nya 90%.

    Ruang disk yang tersedia lebih besar daripada persyaratan ruang bebas minimum. Ini dikontrol oleh parameter yarn.nodemanager.disk-health-checker.min-free-space-per-disk-mb di file yarn-site.xml, yang default-nya 0.

• Solusi

  • Ruang disk yang tidak mencukupi biasanya menyebabkan masalah ini. Jika salah satu skenario berikut berlaku, pertimbangkan untuk memperluas kapasitas disk:

    • Node NodeManager ber-spesifikasi tinggi dan menjalankan banyak task.

    • Kapasitas disk relatif kecil.

    • Task bergantung pada data atau file besar.

    • Task menghasilkan banyak data antara.

    • Log task besar dan mengonsumsi ruang disk yang signifikan.

  • Periksa parameter yarn.nodemanager.localizer.cache.target-size-mb di file yarn-site.xml. Jika nilai ini terlalu tinggi relatif terhadap kapasitas disk, cache untuk task historis dapat mengonsumsi ruang disk berlebihan. Sistem secara otomatis membersihkan cache ini hanya setelah melebihi ukuran yang dikonfigurasi.

  • Jika disk yang rusak menyebabkan masalah ini, lihat Mengganti disk lokal yang rusak di kluster.

Apa yang harus saya lakukan jika pesan error "User [dr.who] is not authorized to view the logs for application ***" ditampilkan?

• Deskripsi masalah: Informasi pada gambar berikut ditampilkan saat halaman log dibuka.

• Penyebab: Aturan daftar kontrol akses (ACL) diperiksa saat Anda mengakses halaman Log NodeManager. Jika aturan ACL diaktifkan dan pengguna jarak jauh ingin melihat log aplikasi, pengguna jarak jauh tersebut harus memenuhi salah satu kondisi berikut:

  • Pengguna jarak jauh adalah pengguna admin.

  • Pengguna jarak jauh adalah pemilik aplikasi.

  • Pengguna jarak jauh memenuhi aturan ACL yang dikustomisasi untuk aplikasi tersebut.

• Solusi: Periksa apakah pengguna jarak jauh memenuhi salah satu kondisi di atas.

Apa yang harus saya lakukan jika pesan error "HTTP ERROR 401 Authentication required" atau "HTTP ERROR 403 Unauthenticated users are not authorized to access this page" ditampilkan?

• Deskripsi masalah: Error HTTP ERROR 401 atau HTTP ERROR 403 dilaporkan saat Anda mengakses UI web atau memanggil RESTful API. Detail HTTP ERROR 401 ditunjukkan pada gambar berikut.

  

• Penyebab: YARN menggunakan metode autentikasi simple dan tidak mengizinkan akses anonim. Untuk informasi lebih lanjut, lihat Autentikasi untuk konsol web HTTP Hadoop dalam dokumentasi resmi Apache Hadoop.

• Solusi:

  • Metode 1: Konfigurasikan parameter URL untuk menentukan pengguna jarak jauh, seperti user.name=***.

  • Metode 2: Di bagian Configuration Filter pada tab Configure di halaman layanan HDFS kluster di Konsol EMR, cari parameter hadoop.http.authentication.simple.anonymous.allowed dan ubah nilainya menjadi true untuk mengizinkan akses anonim. Untuk informasi lebih lanjut tentang parameter ini, lihat Autentikasi untuk konsol web HTTP Hadoop dalam dokumentasi resmi Apache Hadoop. Kemudian, restart layanan HDFS. Untuk informasi lebih lanjut, lihat Merestart layanan.

Mengapa nilai TotalVcore yang ditampilkan tidak benar?

Di bagian kluster atau RESTful API metrik di pojok kanan atas UI web YARN, nilai TotalVcore yang ditampilkan tidak benar. Ini adalah masalah logika komputasi untuk TotalVcore dalam versi Apache Hadoop sebelum 2.9.2. Untuk informasi lebih lanjut, lihat Total #VCores in cluster metrics is wrong when CapacityScheduler reserved some containers dalam dokumentasi resmi Apache Hadoop.

Masalah ini telah diperbaiki di EMR V3.37.x, EMR V5.3.x, dan versi minor berikutnya.

Apa yang harus saya lakukan jika informasi aplikasi yang ditampilkan di UI web TEZ tidak lengkap?

Task Spark Thrift Server di UI web YARN

Jika Anda memilih Spark saat membuat kluster, kluster tersebut secara otomatis memulai layanan Spark Thrift Server default. Layanan ini menggunakan sumber daya satu driver YARN. Secara default, task Spark Thrift Server meminta sumber daya dari YARN melalui driver ini.

Dukungan URL OSS untuk yarn.timeline-service.leveldb-timeline-store.path

Parameter yarn.timeline-service.leveldb-timeline-store.path tidak mendukung URL bucket OSS.

Saat Anda membuat kluster Hadoop, parameter yarn.timeline-service.leveldb-timeline-store.path default-nya adalah nilai parameter hadoop.tmp.dir. Jangan memodifikasi parameter hadoop.tmp.dir untuk HDFS, karena ini memengaruhi parameter yarn.timeline-service.leveldb-timeline-store.path.

Timeout koneksi Timeline Server atau penggunaan sumber daya tinggi

Saat menjalankan banyak job Tez, Anda mungkin mengalami timeout koneksi saat menulis event ke YARN Timeline Server. Hal ini terjadi karena proses Timeline Server mengonsumsi sumber daya CPU berlebihan, menyebabkan utilisasi CPU node mencapai batasnya. Hal ini memengaruhi eksekusi job dan layanan non-inti seperti pembuatan laporan. Untuk menyelesaikan masalah ini, modifikasi item konfigurasi berikut.

Di Konsol EMR, modifikasi konfigurasi untuk layanan Tez dan YARN. Untuk instruksinya, lihat Mengelola item konfigurasi.

1. Di tab tez-site.xml pada halaman Configure untuk layanan Tez, tambahkan parameter tez.yarn.ats.event.flush.timeout.millis dan atur nilainya menjadi 60000. Parameter ini mengatur timeout untuk task Tez yang menulis event ke YARN Timeline Server.

2. Di tab yarn-site.xml pada halaman Configure untuk layanan YARN, tambahkan atau modifikasi item konfigurasi berikut. Kemudian, di halaman Status layanan YARN, restart TimelineServer.

   Parameter	Nilai	Deskripsi
   yarn.timeline-service.store-class	org.apache.hadoop.yarn.server.timeline.RollingLevelDBTimelineStore	Kelas penyimpanan event untuk YARN Timeline Server.
   yarn.timeline-service.rolling-period	daily	Periode rolling event untuk YARN Timeline Server.
   yarn.timeline-service.leveldb-timeline-store.read-cache-size	4194304	Ukuran cache baca untuk penyimpanan LevelDB YARN Timeline Server.
   yarn.timeline-service.leveldb-timeline-store.write-buffer-size	4194304	Ukuran buffer tulis untuk penyimpanan LevelDB YARN Timeline Server.
   yarn.timeline-service.leveldb-timeline-store.max-open-files	500	Jumlah maksimum file terbuka untuk penyimpanan LevelDB YARN Timeline Server.