hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clay B. (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HBASE-12954) Ability impared using HBase on multihomed hosts
Date Mon, 02 Feb 2015 15:37:34 GMT
Clay B. created HBASE-12954:

             Summary: Ability impared using HBase on multihomed hosts
                 Key: HBASE-12954
                 URL: https://issues.apache.org/jira/browse/HBASE-12954
             Project: HBase
          Issue Type: Bug
    Affects Versions: 0.98.4
            Reporter: Clay B.
            Priority: Minor

For HBase clusters running on unusual networks (such as NAT'd cloud environments or physical
machines with multiple IP's per network interface) it would be ideal to have a way to both

# which IP interface to which HBase master or region-server will bind
# what hostname HBase will advertise in Zookeeper both for a master or region-server process

While efforts such as HBASE-8640 go a long way to normalize these two sources of information,
it is not possible in the current design of the properties available to an administrator for
these to be unambiguously specified.

One has been able to request `hbase.master.ipc.address` or `hbase.regionserver.ipc.address`
but one can not specify the desired HBase `hbase.master.hostname`. (It was removed in HBASE-1357,
further I am unaware of a region-server equivalent.)

I use a configuration management system to generate all of my configuration files on a per-machine
basis. As such, an option to generate a file specifying exactly which hostname to use would
be helpful.

Today, specifying the bind address for HBase works and one can use an HBase-only DNS for faking
what to put in Zookeeper but this is far from ideal. Network interfaces have no intrinsic
IP address, nor hostname. Specifing a DNS server is awkward as the DNS server may differ from
the system's resolver and is a single IP address. Similarly, on hosts which use a transient
VIP (e.g. through keepalived) for other services, it means there's a seemingly non-deterministic
hostname choice made by HBase depending on the state of the VIP at daemon start-up time.

I will attach two networking examples I use which become very difficult to manage under the
current properties.

This message was sent by Atlassian JIRA

View raw message