oKeeper is restarted, HDFS will reconnect with no issues.
No. Currently, this is not supported. Whichever NameNode is started first will become active. You may choose to start the cluster in a specific order such that your preferred node starts first.
Even if automatic failover is configured, you may initiate a manual failover using the same hdfs haadmin command. It will perform a coordinated failover.
One option for shared storage for the NameNode is BookKeeper. BookKeeper achieves high availability and strong durability guarantees by replicating edit log entries across multiple storage nodes. The edit log can be striped across the storage nodes for high performance. Fencing is supported in the protocol, i.e, BookKeeper will not allow two writers to write the single edit log.
The meta data for BookKeeper is stored in ZooKeeper. In current HA architecture, a Zookeeper cluster is required for ZKFC. The same cluster can be for BookKeeper metadata.
For more details on building a BookKeeper cluster, please refer to the BookKeeper documentation
The BookKeeperJournalManager is an implementation of the HDFS JournalManager interface, which allows custom write ahead logging implementations to be plugged into the HDFS NameNode.
To use BookKeeperJournalManager, add the following to hdfs-site.xml.
<property> <name>dfs.namenode.shared.edits.dir</name> <value>bookkeeper://zk1:2181;zk2:2181;zk3:2181/hdfsjournal</value> </property> <property> <name>dfs.namenode.edits.journal-plugin.bookkeeper</name> <value>org.apache.hadoop.contrib.bkjournal.BookKeeperJournalManager</value> </property>
The URI format for bookkeeper is bookkeeper://[zkEnsemble]/[rootZnode] [zookkeeper ensemble] is a list of semi-colon separated, zookeeper host:port pairs. In the example above there are 3 servers, in the ensemble, zk1, zk2 & zk3, each one listening on port 2181.
[root znode] is the path of the zookeeper znode, under which the edit log information will be stored.
The class specified for the journal-plugin must be available in the NameNode's classpath. We explain how to generate a jar file with the journal manager and its dependencies, and how to put it into the classpath below.
<property> <name>dfs.namenode.bookkeeperjournal.output-buffer-size</name> <value>1024</value> </property>
<property> <name>dfs.namenode.bookkeeperjournal.ensemble-size</name> <value>3</value> </property>
<property> <name>dfs.namenode.bookkeeperjournal.quorum-size</name> <value>2</value> </property>
<property> <name>dfs.namenode.bookkeeperjournal.digestPw</name> <value>myPassword</value> </property>
<property> <name>dfs.namenode.bookkeeperjournal.zk.session.timeout</name> <value>3000</value> </property>
To generate the distribution packages for BK journal, do the following.
$ mvn clean package -Pdist
This will generate a jar with the BookKeeperJournalManager, all the dependencies needed by the journal manager, hadoop-hdfs/src/contrib/bkjournal/target/hadoop-hdfs-bkjournal-VERSION.jar
Note that the -Pdist part of the build command is important, as otherwise the dependencies would not be packaged in the jar. The dependencies included in the jar are shaded to avoid conflicts with other dependencies of the NameNode.
To run a HDFS namenode using BookKeeper as a backend, copy the bkjournal jar, generated above, into the lib directory of hdfs. In the standard distribution of HDFS, this is at $HADOOP_HDFS_HOME/share/hadoop/hdfs/lib/
cp hadoop-hdfs/src/contrib/bkjournal/target/hadoop-hdfs-bkjournal-VERSION.jar $HADOOP_HDFS_HOME/share/hadoop/hdfs/lib/
1) NameNode format command will not format the BookKeeper data automatically. We have to clean the data manually from BookKeeper cluster and create the /ledgers/available path in Zookeeper. ---- $ zkCli.sh create /ledgers 0 $ zkCli.sh create /ledgers/available 0 ---- Note: bookkeeper://zk1:2181;zk2:2181;zk3:2181/hdfsjournal The final part /hdfsjournal specifies the znode in zookeeper where ledger metadata will be stored. Administrators may set this to anything they wish.
2) Security in BookKeeper. BookKeeper does not support SASL nor SSL for conn