You can increase or decrease the number of nodes in a running job flow. A job flow contains a single master node. The master node controls any slave nodes that are present. There are two types of slave nodes: core nodes, which hold data to process in the Hadoop Distributed File System (HDFS), and task nodes, which do not contain HDFS. After a job flow is running, you can increase, but not decrease, the number of core nodes. Task nodes also run your Hadoop jobs. After a job flow is running, you can both increase or decrease the number of task nodes.

You can modify the size of a running job flow using either the API or the CLI. The AWS Management Console allows you to monitor job flows that you resized, but it does not provide the option to resize job flows.

Nodes within a job flow are managed by instance groups. All job flows require a master instance group containing a single master node. Job flows using slave nodes require a core instance group that contains at least one core node. Additionally, if a job flow has a core instance group, it can also have a task instance group containing one or more task nodes.

When your job flow runs, Hadoop determines the number of mapper and reducer tasks needed to process the data. Larger job flows should have more tasks for better resource use and shorter processing time. Typically, an Amazon Elastic MapReduce (Amazon EMR) job flow remains the same size during the entire job flow; you set the number of tasks when you create the job flow. When you resize a running job flow, you can vary the processing during the job flow execution. Therefore, instead of using a fixed number of tasks, you can vary the number of tasks during the life of the job flow. There are two configuration options to help set the ideal number of tasks. They are:

You can set both options in the mapred-conf.xml file. When you submit a job flow to the cluster, the job client checks the current total number of map and reduce slots available cluster wide. The job client then uses the following equations to set the number of tasks:

The job client only reads the tasksperslot parameter if the number of tasks is not configured. You can override the number of tasks at any time, either for all job flows via a bootstrap action or individually per job by adding a step to change the configuration.

Amazon Elastic MapReduce (Amazon EMR) withstands slave node failures and continues job flow execution even if a slave node becomes unavailable. Amazon EMR automatically provisions additional slave nodes to replace those that fail.

You can have a different number of slave nodes for each job flow step. You can also add a step to a running job flow to modify the number of its slave nodes. Because all steps are guaranteed to run sequentially, you can specify the number of running slave nodes for any job flow step.

Parameters for Resizing Job Flows

The Amazon EMR CLI provides parameters so you can control how you resize a running job flow.

Parameters to Increase or Decrease Nodes

You can increase or decrease the number of nodes in a running job flow. The parameters are listed in the following table.

Parameter	Description
--modify-instance-group INSTANCE_GROUP_ID	Modify an existing instance group.
--instance-count INSTANCE_COUNT	Set the count of nodes for an instance group. Note You are only allowed to increase the number of nodes in a core instance group. You can increase or decrease the number of nodes in a task instance group. Master instance groups can not be modified.

Parameters to Add an Instance Group to a Running Job Flow

You can add an instance group to your running job flow. The parameters are listed in the following table.

Parameter	Description
--add-instance-group ROLE	Add an instance group to an existing job flow. The role may be TASK only. Currently, Amazon Elastic MapReduce (Amazon EMR) does not permit adding core or master instance groups to a running job flow.
--instance-count INSTANCE_COUNT	Set the count of nodes for an instance group.
--instance-type INSTANCE_TYPE	Set the type of Amazon EC2 instance to create nodes for an instance group.

Parameters to Specify an Instance Group when Creating a Job Flow

You can specify instance groups when you create a job flow. The parameters are listed in the following table.

Parameter	Description
--instance-group TYPE	Set the instance group type. A type is MASTER, CORE, or TASK
--instance-count INSTANCE_COUNT	Set the count of nodes for an instance group.
--instance-type INSTANCE_TYPE	Set the type of Amazon EC2 instance for nodes in an instance group.

The --describe command describes all instance groups and node types. If you run elastic-mapreduce --jobflow JobFlowID --describe, you see a section called InstanceGroups. You can see that your job flow contains a master instance group and, potentially, core and task instance groups.

Example

$ ./elastic-mapreduce --jobflow JobFlowID --describe

{
  "JobFlows": [
    {
      "Name": "Development Job Flow (requires manual termination)",
      "LogUri": "s3n:\/\/myawsbucket\/FileName\/",
      "ExecutionStatusDetail": {
        "StartDateTime": null,
        "EndDateTime": null,
        "LastStateChangeReason": "Starting instances",
        "CreationDateTime": DateTimeStamp,
        "State": "STARTING",
        "ReadyDateTime": null
      },
      "Steps": [],
      "Instances": {
        "MasterInstanceId": null,
        "Ec2KeyName": "KeyName",
        "NormalizedInstanceHours": 0,
        "InstanceCount": 5,
        "Placement": {
          "AvailabilityZone": "us-east-1a"
        },
        "SlaveInstanceType": "m1.small",
        "HadoopVersion": "0.20",
        "MasterPublicDnsName": null,
        "KeepJobFlowAliveWhenNoSteps": true,
        "InstanceGroups": [
          {
            "StartDateTime": null,
            "SpotPrice": null,
            "Name": "Master Instance Group",
            "InstanceRole": "MASTER",
            "EndDateTime": null,
            "LastStateChangeReason": "",
            "CreationDateTime": DateTimeStamp,
            "LaunchGroup": null,
            "InstanceGroupId": "InstanceGroupID",
            "State": "PROVISIONING",
            "Market": "ON_DEMAND",
            "ReadyDateTime": null,
            "InstanceType": "m1.small",
            "InstanceRunningCount": 0,
            "InstanceRequestCount": 1
          },
          {
            "StartDateTime": null,
            "SpotPrice": null,
            "Name": "Task Instance Group",
            "InstanceRole": "TASK",
            "EndDateTime": null,
            "LastStateChangeReason": "",
            "CreationDateTime": DateTimeStamp,
            "LaunchGroup": null,
            "InstanceGroupId": "InstanceGroupID",
            "State": "PROVISIONING",
            "Market": "ON_DEMAND",
            "ReadyDateTime": null,
            "InstanceType": "m1.small",
            "InstanceRunningCount": 0,
            "InstanceRequestCount": 2
          },
          {
            "StartDateTime": null,
            "SpotPrice": null,
            "Name": "Core Instance Group",
            "InstanceRole": "CORE",
            "EndDateTime": null,
            "LastStateChangeReason": "",
            "CreationDateTime": DateTimeStamp,
            "LaunchGroup": null,
            "InstanceGroupId": "InstanceGroupID",
            "State": "PROVISIONING",
            "Market": "ON_DEMAND",
            "ReadyDateTime": null,
            "InstanceType": "m1.small",
            "InstanceRunningCount": 0,
            "InstanceRequestCount": 2
          }
        ],
        "MasterInstanceType": "m1.small"
      },
      "BootstrapActions": [],
      "JobFlowId": "JobFlowID"
    }
  ]
}

Arrested State

An instance group goes into arrested state if it encounters too many errors while trying to start the new cluster nodes. For example, if new nodes fail while performing bootstrap actions, the instance group goes into an arrested state, rather than continuously provision new nodes. After you resolve the underlying issue, reset the desired number of nodes on the job flow's instance group, and then the instance group resumes allocating nodes.

The command --describe returns all instance groups and node types, and so you can see the state of the instance groups for the job flow. If Amazon Elastic MapReduce (Amazon EMR) detects any kind of fault with an instance group, it changes the group's state to ARRESTED.

Use the --modify-instance-group command to reset a job flow in the ARRESTED state.

Modifying the instance group instructs Amazon EMR to attempt to provision nodes again. No running nodes are restarted or terminated.

To reset a job flow in an arrested state

• Enter the --modify-instance-group command as follows:

  If you are using...	From the command-line prompt, enter...
  Linux or UNIX	$ ./elastic-mapreduce \ --modify-instance-group InstanceGroupID \ -–instance-count COUNT
  Microsoft Windows	c:/ruby/ruby elastic-mapreduce \ --modify-instance-group InstanceGroupID \ -–instance-count COUNT

  The <InstanceGroupID>/<InstanceGroupID> is the ID of the arrested instance group and <COUNT> is the number of nodes you want in the instance group.

	Tip
	You do not need to change the number of nodes from the original configuration to free a running job flow. Set -–instance-count to the same count as the original setting.

Legacy Job Flows

Before October 2010, Amazon EMR did not have the concept of instance groups. Job flows developed for Amazon EMR that were built before the option to resize running job flows was available are considered legacy job flows. Previously, the Amazon EMR architecture did not use instance groups to manage nodes and only one type of slave node existed. Legacy job flows reference slaveInstanceType and other now deprecated fields. Amazon EMR continues to support the legacy job flows; you do not need to modify them to run them correctly.

Job Flow Behavior

If you run a legacy job flow and only configure master and slave nodes, you observe a slaveInstanceType and other deprecated fields associated with your job flows.

Mapping Legacy Job Flows to Instance Groups

Before October 2010, all cluster nodes were either master nodes or slave nodes. An Amazon Elastic MapReduce (Amazon EMR) configuration could typically be represented like the following diagram.

Old Amazon EMR Model

1	A legacy job flow launches and a request is sent to Amazon EMR to start the job flow.
2	Amazon EMR creates a Hadoop cluster.
3	The legacy job flow runs on a cluster consisting of a single master node and the specified number of slave nodes.

Job flows created using the older model are fully supported and function as originally designed. The Amazon EMR API and commands map directly to the new model. Master nodes remain master nodes and become part of the master instance group. Slave nodes still run HDFS and become core nodes and join the core instance group.

	Note
	No task instance group or task nodes are created as part of a legacy job flow, however you can add them to a running job flow at any time.

The following diagram illustrates how a legacy job flow now maps to master and core instance groups.

Old Amazon EMR Model Remapped to Current Architecture

1	A request is sent to Amazon EMR to start a job flow.
2	Amazon EMR creates an Hadoop cluster with a master instance group and core instance group.
3	The master node is added to the master instance group.
4	The slave nodes are added to the core instance group.

s3://elasticmapreduce/libs/resize-job-flow/0.1/resize-job-flow.jar \
--add-instance-group task --instance-type InstanceType --instance-count 10