Hi @dv_conan, Similar issue is addressed here - https://community.cloudera.com/t5/Support-Questions/failed-to-execute-command-install-yarn-mapreduce-framework/td-p/301804    Please refer and make the necessary changes to directory permissions and let us know if that helped you.  ... View more

Hello @nj20200 It seems there is an older/previous version of openssl-devel package (openssl-libs-1.0.2k-19.el7.x86_64) is installed, which is causing the installation failure of new version openssl-devel package (openssl-devel-1.0.1e-60.el7.x86_64).    So instead of installing the package, update the openssl-devel package by running  "#yum update openssl-devel with -force option"  or just remove the previous package and install the new version of openssl-devel package.  ... View more

Hello @uxadmin please note that block count threshold configuration is intended for DataNodes only.  This is a DataNode health test that checks for whether the DataNode has too many blocks. It's because having too many blocks on a DataNode may affect the DataNode's performance.    There's no hard limit on the # of blocks writable to a DN, as block size is merely a logical concept, not a physical layout. However, the block count alert serves to indicate an early warning to a growing number of small files issue. While your DN can handle a lot of blocks in general, going too high will cause performance issues. Your processing speeds may get lower if you keep a lot of tiny files on HDFS (depends on your use-case of course) so would be worth looking into.   You can find the block count threshold in HDFS config by navigating to CM > HDFS > Configuration > DataNode Block Count Thresholds  When the block counts on each DN goes above the threshold, CM triggers an alert. So you need to adjust the threshold value based on the block counts on each DN. You can determine the block counts on each DN, navigating to CM > HDFS > WebUI > Active NN > DataNodes tab > Block counts column under Datanode section.    Hope this helps.      ... View more

Hello @kolli_sandeep , it seems the failover controllers are down in the cluster. Please follow the steps here [1] and start the Failover Controller roles which will transition the NameNdoes to Active/Standby state.    You need to follow below steps;   Stop the FailoverController Roles under HDFS > Instances page  Remove the HA state from ZK. On a ZooKeeper server host, run zookeeper-client. Execute the following to remove the configured nameservice. This example assumes the name of the nameservice is nameservice1. You can identify the nameservice from the Federation and High Availability section on the HDFS Instances tab: rmr /hadoop-ha/nameservice1 (If you don't see any znode /hadoop-ha in ZK znode list, skip the step) After removing the HA znode in ZK, Go to CM and Click the HDFS > Instances >  Federation and High Availability > Actions   Under Actions menu, Select Actions > Initialize High Availability State in ZooKeeper. Then start the Failover Controllers role ( CM > Instances > Select FailoverControllers > Actions for selected > Start) Verify the NameNdoe State and if you don't see the active/standby state of NN, If any failure, just Restart the HDFS service [1] https://docs.cloudera.com/documentation/enterprise/latest/topics/cdh_hag_hdfs_ha_enabling.html ... View more

Hello @raghurok , Could you please check now and see if you still getting the timeout error. I believe the timeout is due to some network glitch or maintenance activity. I hope you will be able to access it now.  ... View more

Hi @pauljoshiva    Though it is expected to have uniform disk configiuration across datanodes in cluster, you can have two different sets of disk confgiration on DNs. You can have one parition of 2TB size on each disk (3 *2TB =6TB on each DN) even though existing has 1 TB size of partition on each disk across all 9 disks (9*1TB=9TB on each DN).    There will be no issue running DNs with such configiration, but you may see 6TB size DNs are filling faster than 9TB size DNs due to the fact that, NN doesn't consider availabel free space on DNs before writing blocks into it. NameNode picks the DN randomly after evaluating network distnace of the DN from client.   Hope this helps. Thank you    ... View more

Hello @vvk  Please note, while adding/removing the journal nodes from the running cluster, you need to ensure a quorum of journal nodes available for NameNodes. (As cited in the shared document--> NameNode high availability requires that you must maintain at least three, active JournalNodes in your cluster.) It means NameNode ensures at least a quorum of Journal Nodes (2 of 3 journal nodes) available for edits log write at any given point  Failing to write edits into a quorum of journal nodes, NameNode is expected to crash (shutdown itself). I believe this could be the scenario in your case.    So you need to add new journal nodes first to the cluster before removing the old Journal nodes one by one ensuring a quorum of journal nodes available in the cluster.    If you see NN crashed even after edits log write was successful on a quorum of JNs, then we need to check the NN log for any other issues.    Thank you     ... View more