[
https://issues.apache.org/jira/browse/HBASE-12721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15314637#comment-15314637
]
Dima Spivak commented on HBASE-12721:
-------------------------------------
Looks like the framework can handle what you want it to do, [~apurtell]. Here's
how:
# Log into your AWS host and create a file that looks like this:
{noformat}
root@trying-apache-docker:~# cat andy-setup.cfg
[hadoop/slaves]
+++ '\n'.join(["{{0}}.{network}".format(node) for node in {secondary_nodes}])
[hadoop/core-site.xml]
fs.default.name = hdfs://{primary_node[0]}.{network}:8020
[hadoop/mapred-site.xml]
mapreduce.framework.name = yarn
[hadoop/yarn-site.xml]
yarn.resourcemanager.hostname = {primary_node[0]}.{network}
yarn.nodemanager.aux-services = mapreduce_shuffle
yarn.nodemanager.aux-services.mapreduce_shuffle.class =
org.apache.hadoop.mapred.ShuffleHandler
yarn.nodemanager.vmem-check-enabled = false
[hbase/regionservers]
+++ '\n'.join(["{{0}}.{network}".format(node) for node in {secondary_nodes}])
[hbase/backup-masters]
{secondary_nodes[0]}.{network}
[hbase/hbase-site.xml]
hbase.cluster.distributed = true
hbase.rootdir = hdfs://{primary_node[0]}.{network}/hbase
hbase.zookeeper.quorum = {primary_node[0]}.{network}
hbase.zookeeper.property.dataDir = /usr/local/zookeeper
hbase.it.clustermanager.hadoop.hdfs.user = root
hbase.it.clustermanager.zookeeper.user = root
hbase.it.clustermanager.hbase.user = root
[hadoop/hadoop-env.sh]
body:
COMMON_HDFS_OPTS="$COMMON_HDFS_OPTS -XX:+UseG1GC"
COMMON_HDFS_OPTS="$COMMON_HDFS_OPTS -XX:MaxGCPauseMillis=100"
COMMON_HDFS_OPTS="$COMMON_HDFS_OPTS -XX:+PrintGCDetails"
COMMON_HDFS_OPTS="$COMMON_HDFS_OPTS -XX:+PrintGCDateStamps"
COMMON_HDFS_OPTS="$COMMON_HDFS_OPTS -XX:+PrintGCTimeStamps"
COMMON_HDFS_OPTS="$COMMON_HDFS_OPTS -XX:+PrintAdaptiveSizePolicy"
COMMON_HDFS_OPTS="$COMMON_HDFS_OPTS -XX:+PrintReferenceGC"
COMMON_HDFS_OPTS="$COMMON_HDFS_OPTS -XX:+ParallelRefProcEnabled"
COMMON_HDFS_OPTS="$COMMON_HDFS_OPTS -XX:+TieredCompilation"
COMMON_HDFS_OPTS="$COMMON_HDFS_OPTS -XX:-ResizePLAB"
export HADOOP_NAMENODE_OPTS="$HADOOP_NAMENODE_OPTS -Xms1g -Xmx1g"
export HADOOP_NAMENODE_OPTS="$HADOOP_NAMENODE_OPTS $COMMON_HDFS_OPTS"
export HADOOP_NAMENODE_OPTS="$HADOOP_NAMENODE_OPTS -XX:+AlwaysPreTouch"
export HADOOP_NAMENODE_OPTS="$HADOOP_NAMENODE_OPTS -verbose:gc
-Xloggc:/var/log/hadoop/hdfs-namenode-gc.log"
export HADOOP_SECONDARYNAMENODE_OPTS="$HADOOP_SECONDARYNAMENODE_OPTS -Xms1g
-Xmx1g"
export HADOOP_SECONDARYNAMENODE_OPTS="$HADOOP_SECONDARYNAMENODE_OPTS
$COMMON_HDFS_OPTS"
export HADOOP_SECONDARYNAMENODE_OPTS="$HADOOP_SECONDARYNAMENODE_OPTS
-verbose:gc -Xloggc:/var/log/hadoop/hdfs-secondarynamenode-gc.log"
export HADOOP_DATANODE_OPTS="$HADOOP_DATANODE_OPTS -Xms1g -Xmx1g"
export HADOOP_DATANODE_OPTS="$HADOOP_DATANODE_OPTS $COMMON_HDFS_OPTS"
export HADOOP_DATANODE_OPTS="$HADOOP_DATANODE_OPTS -XX:+AlwaysPreTouch"
export HADOOP_DATANODE_OPTS="$HADOOP_DATANODE_OPTS -verbose:gc
-Xloggc:/var/log/hadoop/hdfs-datanode-gc.log"
[hbase/hbase-env.sh]
body:
COMMON_HBASE_OPTS="$COMMON_HBASE_OPTS -XX:+UseG1GC"
COMMON_HBASE_OPTS="$COMMON_HBASE_OPTS -XX:+PrintGCDetails"
COMMON_HBASE_OPTS="$COMMON_HBASE_OPTS -XX:+PrintGCDateStamps"
COMMON_HBASE_OPTS="$COMMON_HBASE_OPTS -XX:+PrintGCTimeStamps"
COMMON_HBASE_OPTS="$COMMON_HBASE_OPTS -XX:+PrintAdaptiveSizePolicy"
COMMON_HBASE_OPTS="$COMMON_HBASE_OPTS -XX:+PrintReferenceGC"
COMMON_HBASE_OPTS="$COMMON_HBASE_OPTS -XX:+ParallelRefProcEnabled"
COMMON_HBASE_OPTS="$COMMON_HBASE_OPTS -XX:+TieredCompilation"
COMMON_HBASE_OPTS="$COMMON_HBASE_OPTS -XX:-ResizePLAB"
export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS -Xms1g -Xmx1g"
export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS $COMMON_HBASE_OPTS"
export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS -verbose:gc
-Xloggc:/var/log/hbase/hbase-master-gc.log"
export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS -Xms32g -Xmx32g"
export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS $COMMON_HBASE_OPTS"
export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS
-XX:MaxGCPauseMillis=50"
export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS
-XX:+UseCondCardMark"
export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS
-XX:+AlwaysPreTouch"
export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS -verbose:gc
-Xloggc:/var/log/hbase/hbase-regionserver-gc.log"
export HBASE_ZOOKEEPER_OPTS="$HBASE_ZOOKEEPER_OPTS -Xms1g -Xmx1g"
export HBASE_ZOOKEEPER_OPTS="$HBASE_ZOOKEEPER_OPTS $COMMON_HBASE_OPTS"
export HBASE_ZOOKEEPER_OPTS="$HBASE_ZOOKEEPER_OPTS -XX:+AlwaysPreTouch"
export HBASE_ZOOKEEPER_OPTS="$HBASE_ZOOKEEPER_OPTS -verbose:gc
-Xloggc:/var/log/hbase/hbase-zookeeper-gc.log"
{noformat}
# Assuming the file is in your current working directory, run the following to
use it when starting up a {{master}} cluster:
{noformat}
CLUSTERDOCK_TARGET_DIR=$(pwd) clusterdock_run ./bin/start_cluster apache_hbase
--hbase-version=master --configurations=/root/target/andy-setup.cfg
--start-services
{noformat}
What's going on under the hood is that, since we run clusterdock out of a
Docker container, we need to have a way of volume mounting a directory into
that container. One easy way to do this is for the framework to always volume
mount the path pointed to by {{CLUSTERDOCK_TARGET_DIR}} into the clusterdock
container's {{/root/target}} folder. Once you have that, the
{{\--configurations}} argument selects which script to use. Give it a shot and
let me know if it works as expected.
> Create Docker container cluster infrastructure to enable better testing
> -----------------------------------------------------------------------
>
> Key: HBASE-12721
> URL: https://issues.apache.org/jira/browse/HBASE-12721
> Project: HBase
> Issue Type: New Feature
> Reporter: Dima Spivak
> Assignee: Dima Spivak
>
> Some simple work on using HBase with Docker was committed into /dev-support
> as "hbase_docker;" all this did was stand up a standalone cluster from source
> and start a shell. Now seems like a good time to extend this to be useful for
> applications that could actual benefit the community, especially around
> testing. Some ideas:
> - Integration testing would be much more accessible if people could stand up
> distributed HBase clusters on a single host machine in a couple minutes and
> run our awesome hbase-it suite against it.
> - Binary compatibility testing of an HBase client is easiest when standing up
> an HBase cluster can be done once and then different client source/binary
> permutations run against it.
> - Upgrade testing, and especially rolling upgrade testing, doesn't have any
> upstream automation on build.apache.org, in part because it's a pain to set
> up x-node clusters on Apache infrastructure.
> This proposal, whether it stays under /dev-support or moves out into it's own
> top-level module ("hbase-docker" would conveniently fit the existing schema
> :-)), strives to create a simple framework for deploying "distributed,"
> multi-container Apache HBase clusters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
