Member since
09-18-2015
3274
Posts
1159
Kudos Received
426
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 2565 | 11-01-2016 05:43 PM | |
| 8496 | 11-01-2016 05:36 PM | |
| 4858 | 07-01-2016 03:20 PM | |
| 8178 | 05-25-2016 11:36 AM | |
| 4326 | 05-24-2016 05:27 PM |
12-04-2015
08:28 PM
Accepting this as best answer. Thanks @Ali Bajwa
... View more
12-04-2015
04:21 PM
Since my question pertains to containers, prewarm is the correct answer but it is not the correct question so I will ask again.
... View more
12-10-2015
09:46 PM
1 Kudo
While storage space is absolutely critical as @Neeraj Sabharwal and @Ali Bajwa wrote in their post we just "discovered" that also CPU is a key point. When HWX released AMS we began to deploy Ambari and AMS on the same machine, but soon the understood that for a production environment it could be a good practice to use one VM for Ambari and another VM for AMS, so the really high impact on computation resources of AMS didn't impact Ambari (sometimes, during the aggregation phase we got 16 CPU at 90% for 10/15 minutes).
... View more
09-21-2017
06:00 PM
1 Kudo
@Neeraj Sabharwal I am still facing the same issue, can you please help. Ambari version been used here is 2.2.2.0 with postgresql 9.2.18 on rhel 7. This happens to us most of the time. I have made sure that agents on all hosts are running and are pointing toward the ambari server, iptables, selinux are disabled. /etc/hosts are updated correctly. I am registering Ambari blueprint via API through Ansible and then cluster creation template also via API through Ansible in automated way. What could be the reason behind this?
... View more
06-01-2016
12:20 PM
Thx @bsani We have sat HA on our name nodes while we don't want the cluster to be unawailable. So is there a best practice for doing patching on a cluster that is supposed to be available 24/7. How to avoid rebalancing during patching When upgrading datanodes in chuncks, is there a way to make sure that replica of a data block is available on one of the servers alive /Claus
... View more
11-26-2015
04:21 PM
1 Kudo
The Hadoop Ecosystem Table https://hadoopecosystemtable.github.io/
... View more
Labels:
06-09-2016
04:41 AM
In addition don't forget to re-start Amabri-server after making above mentioned changes.
... View more
11-27-2015
05:03 PM
Also, If we are using MR then we might need to revisit the mapper/reducer container's heap size accordingly.
... View more
11-26-2015
10:59 AM
1 Kudo
Use case There are 2 groups Analytics and DW. We want to split the cluster resources between these 2 groups. User - neeraj belongs to Analytics group. User - dwuser belongs to DW group User neeraj is not allowed to use Default and dwuser queue. Be default, all the jobs submitted by user neeraj must go to it's assigned queue. User dwuser is not allowed to use Default and Analytics queue. By default, all the jobs submitted by user dwuser must go to it's assigned queue. Environment HDP 2.3 (Hortonworks Data Platform) and Ambari 2.1 This tutorial completely independent of Hadoop distribution. Yarn is must i,e Hadoop 2.x I will be using Capacity Scheduler view to configure queues. yarn.scheduler.capacity.maximum-am-resource-percent=0.2
yarn.scheduler.capacity.maximum-applications=10000
yarn.scheduler.capacity.node-locality-delay=40
yarn.scheduler.capacity.queue-mappings=u:neeraj:Analytics,u:dwuser:DW
yarn.scheduler.capacity.queue-mappings-override.enable=true
yarn.scheduler.capacity.root.accessible-node-labels=*
yarn.scheduler.capacity.root.acl_administer_queue=yarn
yarn.scheduler.capacity.root.acl_submit_applications=yarn
yarn.scheduler.capacity.root.Analytics.acl_administer_queue=yarn
yarn.scheduler.capacity.root.Analytics.acl_submit_applications=neeraj
yarn.scheduler.capacity.root.Analytics.capacity=60
yarn.scheduler.capacity.root.Analytics.maximum-capacity=60
yarn.scheduler.capacity.root.Analytics.minimum-user-limit-percent=100
yarn.scheduler.capacity.root.Analytics.ordering-policy=fifo
yarn.scheduler.capacity.root.Analytics.state=RUNNING
yarn.scheduler.capacity.root.Analytics.user-limit-factor=1
yarn.scheduler.capacity.root.capacity=100
yarn.scheduler.capacity.root.default.acl_administer_queue=yarn
yarn.scheduler.capacity.root.default.acl_submit_applications=yarn
yarn.scheduler.capacity.root.default.capacity=10
yarn.scheduler.capacity.root.default.maximum-capacity=100
yarn.scheduler.capacity.root.default.state=RUNNING
yarn.scheduler.capacity.root.default.user-limit-factor=1
yarn.scheduler.capacity.root.DW.acl_administer_queue=yarn
yarn.scheduler.capacity.root.DW.acl_submit_applications=dwuser
yarn.scheduler.capacity.root.DW.capacity=30
yarn.scheduler.capacity.root.DW.maximum-capacity=30
yarn.scheduler.capacity.root.DW.minimum-user-limit-percent=100
yarn.scheduler.capacity.root.DW.ordering-policy=fifo
yarn.scheduler.capacity.root.DW.state=RUNNING
yarn.scheduler.capacity.root.DW.user-limit-factor=1
yarn.scheduler.capacity.root.maximum-capacity=100
yarn.scheduler.capacity.root.queues=Analytics,DW,default [root@nsfed01 ~]# su - neeraj [neeraj@nsfed01 ~]$ mapred queue -showacls 15/08/18 14:45:03 INFO impl.TimelineClientImpl: Timeline service address: http://nsfed03.cloud.hortonworks.com:8188/ws/v1/timeline/ 15/08/18 14:45:03 INFO client.RMProxy: Connecting to ResourceManager at nsfed03.cloud.hortonworks.com/172.24.64.22:8050 Queue acls for user : neeraj Queue Operations ===================== root Analytics SUBMIT_APPLICATIONS DW default [neeraj@nsfed01 ~]$ [root@nsfed01 ~]# su - neeraj [neeraj@nsfed01 ~]$ yarn jar /usr/hdp/2.3.0.0-2557/hadoop-mapreduce/hadoop-mapreduce-examples.jar pi 20 1000000009 Number of Maps = 20 Samples [root@nsfed03 yarn]# su - dwuser [dwuser@nsfed03 ~]$ yarn jar /usr/hdp/2.3.0.0-2557/hadoop-mapreduce/hadoop-mapreduce-examples.jar pi 20 1000000009 Number of Maps = 20 CS view
... View more
Labels: