I'll answer my own question here since I was able to work through it on a new install. With a fresh installation of HDP 2.3 with Ambari 2.1.1, you'll be prompted during the installation to select a server (or more) to install the NFS gateway on. This happens in the same configuration windows during cluster configuration where you designate Datanodes, Region Servers, Phoenix Servers, etc.. After the installation has finished, you'll see indications that the NFS Gateway is running on the choosen servers. Now what? If you go to one of the servers and do a df - h you won't see any new mount points. So how far down the path did Ambari get you. If you reference back to the HDP 2.2 docs on configuring NFS, you'll see that Ambari has started the nfs and rpcbind services for you. But now it's up to you to mount them. Follow the remaining HDP 2.2 docs to complete the process and mount the NFS gateway. The startup process for the NFS Gateway is run as the 'hdfs' user. So earlier documents covering proxy settings are NOT necessary. # Mount Example (to be run as root) mkdir / hdfs mount - t nfs - o vers = 3 ,proto = tcp,nolock localhost: / / hdfs User interaction details are found here. /etc/fstab Example for NFS Gateway Automount localhost:/ /hdfs nfs rw,vers=3,proto=tcp,nolock,timeo=600 0 0 If you're using NFS as a quick way to traverse HDFS while avoiding the startup times of the jvm when making the 'hdfs dfs ...' call, try out the hdfs-cli project. https://github.com/dstreev/hdfs-cli ... View more

Looking at my current HA implementation, the root zNode for HA is hadoop-ha, followed by the name of the HA instance. IE: /hadoop-ha/HOME , where HOME is to name of the HA NN instance. So this should support your "multiple" HA systems in theory. HA NN doesn't but much load on ZooKeeper, so you're not going to have a scaling issue in that regard. I think this is an operational issue though. Customers are starting to see that ZooKeeper is used for more and more things on clusters and could be considered a place that holds "too many eggs". Another point is around upgrades. While the rolling upgrade supports an easy transition for ZooKeeper, the clusters you would serve from a single ZooKeeper instance will have limitations, from an operational standpoint. Customers with larger clusters are trending to having multiple ZooKeepers per cluster, instead of one ZooKeeper the rule them all. Especially if Storm and Kafka are involved. They apply a different type (heavier) of load then NN HA. Note: Resource Manager HA can also put quite a load on ZooKeeper on really large clusters, as it uses ZooKeeper to maintain the state of jobs. ... View more

As a general rule we do NOT use the default Ambari Databases. Pick one, MySQL, Oracle or PostgreSQL and have a separate instance stood up for it. Then use it for all of your repositories. It should be this way for any environment beyond a sandbox. I wouldn’t even do a POC with the defaults. Simply because the defaults are all over the place and POC can turn into production systems :). Once you’ve committed to using a repository, changing “types” is not really possible. You need to start over basically. I know a lot have asked about this in the past, but it’s a mess. Take 2 minutes in the beginning, setup an “Independent” MySQL (or other) database and use it. If you need to move the MySQL around in the future, that’s possible and more obtainable than switching types. NOTE: Ambari won’t lay down MySQL until the Hive Metastore, so even if you figure out a way to use that Metastore for Oozie, Ranger, etc.. it’s will be controlled by the Hive Service Config. So it WILL restart MySQL when you’ve allow Ambari to install it. If you didn’t catch me saying it earlier, Install a separate and independent RDBMS for your Metastores. ... View more