Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: fixing hdfs & yarn ha cluster templates

 

 

Info

Support for deploying HA Clusters with Blueprints has been added in As of Ambari 2.0, Ambari Blueprints supports deploying HA HDFS, YARN & HBase RegionServers.


Table of Contents
minLevel2

Summary

Ambari 2.0 adds support for deploying clusters with a Blueprint that utilize various Hadoop added support to the Blueprint functionality which allows for deploying High-Availability (HA) features.  This allows for HA clusters to be deployed and setup initially.  This is slightly different than the current HA model in Ambari, where a user will create a cluster and then use for certain components.

 

Prior to this functionality, configuring HA required manually using the Ambari Web HA Wizards

...

after deployment of the cluster.

 

The functionality supports these components:
  • HDFS NameNode HA
  • YARN ResourceManager HA
  • HBase RegionServers HA

Support may be added for other Hadoop technologies in later releases.  

Supported HA Cluster Types

Supported HA scenarios for Blueprints in Ambari 2.0:

  1. HDFS NameNode HA

  2. Yarn ResourceManager HA

  3. HBase RegionServer HA

Compatibility with Ambari UI

Compatibility with Ambari UI

While this While this feature does not require the Ambari UI to function, the Blueprints HA feature is completely compatible with the Ambari UI.  An HA cluster created via Blueprints can be monitored and configured via the Ambari UI, just as any other Blueprints cluster would function.  

Expert-Mode Configuration

In Ambari 2.0, the Blueprint support for HA requires the Blueprint to contain exact fine-grained configurations. See the examples below for more detail.

In future releases, we hope to provide a availability is meant to handle “expert mode” configuration.  In this mode, the creator of the Blueprint sets all the configuration required for a given technology to support HA.  For example: In HDFS NameNode HA, the user must specify the nameservice name, namenode logical names, and other configuration items as well.  This gives the Blueprint creator fine-grained control of the exact HA configuration desired for a given cluster.  In future releases, we hope to also provide a higher-level mode of operations, so that HA can be enabled in a more coarse-grained way.  

...

Getting Started with Blueprints HA

The simplest way to get started with setting up an HA cluster using Blueprints is to use the sample Blueprints in this documentation as a starting point.  This will likely be the most efficient way to obtain the full list of required properties for a given HA cluster, and can then be used as a starting point for customization.  While the samples provided describe smaller clusters (2-3 nodes) in order to provide simpler documentation, it should be straightforward to customize this initial Blueprint to suit larger clusters as well.  It is also possible to create an HA cluster with the Ambari UI, and export a Blueprint based on that cluster.  

Blueprint Example: HDFS NameNode HA Cluster

Summary

...

Start with the tested & working examples below and customize from there.

Blueprint Example: HDFS NameNode HA Cluster

Summary

HDFS NameNode HA allows a cluster to be configured such that a NameNode is not a single point of failure.
For more details on HDFS NameNode HA see the Apache Hadoop documentation.

In an Ambari-deployed HDFS NameNode HA cluster:

  • 2 NameNodes are deployed: an “active” and a “passive” namenode.
  • If the active NameNode should stop functioning properly, the passive node’s Zookeeper client will detect this case, and the passive node will become the new active node.

...

  • HDFS relies on Zookeeper to manage the details of failover in these cases.

...

  • The Blueprints HA feature will automatically invoke all required commands and setup steps for an HDFS NameNode HA cluster, provided that the correct configuration is provided in the Blueprint.  The shared edit logs of each NameNode are managed by the Quorum Journal Manager, rather than NFS shared storage.  The use of NFS shared storage in an HDFS HA setup is not supported by Ambari Blueprints, and is generally not encouraged.  

By setting a series of properties in the “hdfs-site” configuration file, a user can configure HDFS NameNode HA to use at most two NameNodes in a cluster.  These NameNodes are typically referenced via a logical name, the “nameservice”.

 

Note that 

How

By setting a series of properties in the “hdfs-site” configuration file, a user can configure HDFS NameNode HA to use at most two NameNodes in a cluster.  These NameNodes are typically referenced via a logical name, the “nameservice”.  These properties must be set in a Blueprint if NameNode HA is to be enabled.  

The following Apache Hadoop documentation link describes the steps required to setup HDFS NameNode HA manually:

http://hadoop.apache.org/docs/r2.3.0/hadoop-yarn/hadoop-yarn-site/HDFSHighAvailabilityWithQJM.html

 

Note

Ambari Blueprints will handle much of the details of server setup listed in this documentation, but the user of Ambari will need to define the various configuration properties listed in this article (dfs.nameservices, dfs.ha.namenodes.$NAME_OF_NAMENODE, etc).  The example Blueprints listed below will demonstrate the configuration properties that must be included in the Blueprint for this feature to startup the HA cluster properly.  

...

The Blueprints HA feature will automatically invoke all required commands and setup steps for an HDFS NameNode HA cluster, provided that the correct configuration is provided in the Blueprint.  The shared edit logs of each NameNode are managed by the Quorum Journal Manager, rather than NFS shared storage.  The use of NFS shared storage in an HDFS HA setup is not supported by Ambari Blueprints, and is generally not encouraged.  

...

Example Cluster Creation Template

 

Code Block
{
  "blueprint" : "blueprint-hdfs-ha",
  "default_password" : "default",
  "host_groups" :[
    {
      "name" :": "changethis",
  "host_group_1groups",: [
     { "hosts" : [         
        {
          "fqdn" : "c6401.ambari.apache.org"
        }
      ], "name": "gateway"
    },
    {
      "namehosts" : "host_group_2",  [
        { "hostsfqdn" : [ "c6402.ambari.apache.org" }
      ], "name": "master_1"
    },
    { "hosts": [
         { "fqdn" : "c6402c6403.ambari.apache.org" }
      ],  }"name": "master_2"
    },
  ]
  {  },"hosts": [
   {
     { "namefqdn" : "host_group_3", 
c6404.ambari.apache.org" }
      ], "hostsname" : ["master_3"
         },
    {    {"hosts": [
        {  "fqdn" : "c6403c6405.ambari.apache.org" }
      ],
  }
     "name": "slave_1"     ]
    } 
  ]
}

 

 

Create Cluster Instance

...

Note

The Blueprints HA feature does not support configuring the initial “active” or “standby” status of the ResourceManagers deployed in a Yarn HA cluster.  The first instance to obtain the Zookeeper lock will become the “active” node.  This allows the user to specify the host groups that contain the 2 ResourceManager instances, but also shields the user from the need to select the first “active” node.  


After the cluster has started up initially, the state of the “active” and “standby” ResourceManagers may change over time.  The initial “active” server is not guaranteed to remain the “active” node over the lifetime of the cluster.  During a failover event, the “standby” node may be required to fulfill the role of the “active” server. 

The active or standby status of a ResourceManager is not recorded or expressed when a Yarn cluster is being exported to a Blueprint, using the Blueprint REST API endpoint.  Since clusters change over time, this state is only accurate in the initial startup of the cluster. 

 

Example Blueprint

The following link includes an example Blueprint for a 3-node Yarn ResourceManager HA Cluster:

yarn_ha_blueprint.json

Register Blueprint with Ambari Server

Post the blueprint to the "blueprint-yarn-ha" resource to the Ambari Server.

Code Block
POST /api/v1/blueprints/blueprint-yarn-ha
 
...
[ Request Body is the example blueprint defined above ]
...
 
201 - Created

 

Example Cluster Creation Template

of the “active” and “standby” ResourceManagers may change over time.  The initial “active” server is not guaranteed to remain the “active” node over the lifetime of the cluster.  During a failover event, the “standby” node may be required to fulfill the role of the “active” server. 


The active or standby status of a ResourceManager is not recorded or expressed when a Yarn cluster is being exported to a Blueprint, using the Blueprint REST API endpoint.  Since clusters change over time, this state is only accurate in the initial startup of the cluster. 

 

Example Blueprint

The following link includes an example Blueprint for a 3-node Yarn ResourceManager HA Cluster:

yarn_ha_blueprint.json


Register Blueprint with Ambari Server

Post the blueprint to the "blueprint-yarn-ha" resource to the Ambari Server.


Code Block
POST /api/v1/blueprints/blueprint-yarn-ha
 
...
[ Request Body is the example blueprint defined above ]
...
 
201 - Created

 

Example Cluster Creation Template


Code Block
{
  "blueprint": "blueprint-yarn-ha",
  "default_password": "changethis",
  "configurations": [
    { "yarn-site" : {
        "yarn.resourcemanager.zk-address" : "c6402.ambari.apache.org:2181,c6403.ambari.apache.org:2181,c6404.ambari.apache.org:2181”,
        ”yarn.resourcemanager.hostname.rm1" : "c6403.ambari.apache.org",
        "yarn.resourcemanager.hostname.rm2" : "c6404.ambari.apache.org"
     }}
  ],
  "host_groups": [
    { "hosts": [
Code Block
{
  "blueprint" : "blueprint-yarn-ha",
  "default_password" : "default",
  "host_groups" :[
    {
      "name" : "host_group_1", 
      "hosts" : [         
        {
          "fqdn" : "c6401.ambari.apache.org" }
      ], "name": "gateway"
    },
    { "hosts": ][
        { "fqdn": "c6402.ambari.apache.org" },
    {
   ],   "name" : "hostmaster_group_2", 1"
    },
     { "hosts" : [         
        {
          "fqdn" : "c6402c6403.ambari.apache.org" }
      ],  }"name": "master_2"
    },
  ]
  {  },"hosts": [
   {
     { "namefqdn" : "host_group_3", c6404.ambari.apache.org" }
      ], "hostsname" : ["master_3"
         },
    {    {"hosts": [
        {  "fqdn" : "c6403c6405.ambari.apache.org" }
      ],
  }
     "name": "slave_1"     ]
    } 
  ]
}


 

Create Cluster Instance

...