@Anil Bagga hortonworks has documentation on pre checks you should perform prior to upgrading to 2.4.0 here. Prechecks http://docs.hortonworks.com/HDPDocuments/Ambari-2.2.2.0/bk_upgrading_Ambari/content/_preparing_to_upgrade_ambari_and_hdp.html http://docs.hortonworks.com/HDPDocuments/Ambari-2.2.2.0/bk_upgrading_Ambari/content/_upgrading_HDP_prerequisites.html Prepare upgrade http://docs.hortonworks.com/HDPDocuments/Ambari-2.2.2.0/bk_upgrading_Ambari/content/_preparing_to_upgrade_ambari.html http://docs.hortonworks.com/HDPDocuments/Ambari-2.2.2.0/bk_upgrading_Ambari/content/_upgrading_HDP_prepare_to_upgrade.html post upgrade http://docs.hortonworks.com/HDPDocuments/Ambari-2.2.2.0/bk_upgrading_Ambari/content/_post_ambari_upgrade_tasks.html ... View more

@Anil Bagga, you can follow the documentation for the upgrade that @ssathish specified, however, I would like to emphasize a few important tasks that need to make your checklist. They may look like a no brainer but quite often unhealthy installations are upgraded and when issues occur, it is much more difficult to debug what happened. As such, I always recommend to check your current installation, identify and address issues before upgrade. The purpose is to confirm that the cluster is healthy and will experience minimal service disruption before attempting an upgrade. Use the Ambari Web UI to ensure that all services in the cluster are running. For each service in the cluster, run the Service Check on the service’s Service Actions menu to confirm that the service is operational. Service checks are used extensively during rolling upgrade so if they fail when run manually, they will likely fail during upgrade too. For each service use the Stop and Start buttons in the Ambari Web UI to verify that the service can be stopped and started. Services are repeatedly stopped and started during upgrade. If they fail when initiated manually, they will likely fail during upgrade too. Understand and, as necessary, remediate any Ambari alerts. Ensure that you have an up-to-date backup of any supporting databases, including Hive, Ranger, Oozie, and any others. Enable HDFS, YARN, HBase, and Hive HA to minimize service disruption. Ensure that each cluster node has at least 2.5 GB of disk space available for each HDP version. The target installation directory is /usr/hdp/<version>. Operationally, be aware that new service user accounts might be created to support new software projects that were not installed as part of the earlier HDP release. For example, these new user accounts might need to be added to an LDAP server or created as Kerberos principals. Another thing that is extremely important is to understand what are the issues with your existent version and workarounds in place, as well known issues of the new release and if existent issues are not fixed, how would your port the fixes. Not last, test, test, test and finalize your upgrade when you are convinced that you did everything that was necessary to reduce risk. Until FINALIZE you can always rollback, after that is more difficult. As you know, with the recent versions of Ambari you can do either Rolling or Express Upgrade. It depends on your business requirements, but an Express Upgrade can be done during a maintenance window, while Rolling Upgrade for a large cluster can take significant time. Current release of Ambari does the upgrade sequentially, one node at the time. There is no parallelism. Good luck! ... View more

@Anil Bagga @jk answered, Configuration Groups is the way to go. I will not repeat the references and the paragraph he pasted from the reference, but I would like to elaborate more on the practical aspects of using configuration groups not only for heterogenous infrastructure, but also for cases when the existent homogeneous infrastructure becomes heterogeneous due to hardware failures, e.g. failed drives which can make your current infrastructure to behave like heterogeneous. That is another scenario for using Configuration Groups. From the configuration point of view, your best approach is to use Configuration Groups to manage various data nodes infrastructure, however, there is more to it. With the new servers you may have more and faster storage on those new nodes.Your YARN containers sizing is defined globally (RAM and cores) as such if some nodes can store more data you need to have more cores and RAM on those nodes to be able to process the data in all nodes with a similar performance to avoid long running tasks on some of the nodes which in case of MapReduce can lead to lose of overall performance. Also, don't forget to balance the data across all nodes after you add the new data nodes. Third and not last, test your applications and monitor resources use across your infrastructure. There are always ways to improve performance by improving the design of the SQL or application to leverage the infrastructure evenly for best parallelism. ... View more

@Anil Bagga As jk also mentioned, the most recent Ambari version was just launched: 2.4.1. Documentation is on Ambari's website: https://ambari.apache.org and the roadmap on the wiki: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=30755705. However, I'd like to you to look at the great presentation that Jeff Sposetti delivered at our New York meetup on 9/13/2016: http://www.slideshare.net/dbist/past-present-and-future-of-apache-ambari . As you can see in the presentation, a few features included in 2.4.1 are very exciting, e.g. Log Search (centralized view of logs), Automated Cluster Upgrade and many more are included or to come. Jeff's almost 100-pages presentation includes also the roadmap. ... View more