You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hadoop.apache.org by Patai Sangbutsarakum <si...@gmail.com> on 2013/06/21 21:44:10 UTC

Moving namenode and jobtracker to beefier machines

It's time to upgrade namenode and jobtracker machines to better beefier
boxes. Thus, we can have peaceful summer at least not worry from broken
machines!!

Current setup NN and JT are running in 2 separate boxes. NN and JT has its
own alias which CNAME to the destination boxes which looks like this:

hadoop-nn cname box1
hadoop-jt cname box2.


I am planning to

For jobtracker,

1. A day or two before the operation, decrease the TTL for hadoop-jt cname
to box2 down to like 1 min.

2. prepare a new JT box (newJTbox).

3. run stop-mapred on box2

4. change DNS to have hadoop-jt cname to newJTbox (still keep 1min TTL
there in case i need to revert the change)

5. run start-mapred.sh from newJTbox


For Namenode, pretty much same flow with Jobtracker,

1. A day or two before the operation, decrease the TTL for hadoop-NN cname
to box1 down to 1min

2. setup a new NN box.

3. mount NFS volume (used in dfs.name.dir) that being mounted in box1 to
newNNbox, and not format the local directory of dfs.name.dir in newNNbox.
So, the local dfs.name.dir will be empty, and dfs.name.dir for the remote
will have meta files from NFS.

4. run stop-dfs.sh on box1

5. change DNS to have hadoop-NN cname to newNNbox.

6. run start-dfs.sh from newNNbox.


I came across with this JIRA https://issues.apache.org/jira/browse/HDFS-34
I am wondering if these procedures both for jobtracker and namenode still
be valid from the fact in these Jira. if not, how you guys've done these
procedures.

please suggest
Patai