Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 68F1C17B32 for ; Mon, 2 Feb 2015 21:37:34 +0000 (UTC) Received: (qmail 91703 invoked by uid 500); 2 Feb 2015 21:37:35 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 91663 invoked by uid 500); 2 Feb 2015 21:37:35 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 91652 invoked by uid 99); 2 Feb 2015 21:37:35 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Feb 2015 21:37:35 +0000 Date: Mon, 2 Feb 2015 21:37:35 +0000 (UTC) From: "Andrew Purtell (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (HBASE-12954) Ability impaired using HBase on multihomed hosts MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14301975#comment-14301975 ] Andrew Purtell edited comment on HBASE-12954 at 2/2/15 9:36 PM: ---------------------------------------------------------------- This is similar of course to issues operators face on EC2 clouds, where the reverse resolved internal DNS names are of no use unless all clients are also using the internal resolvers. So like Stack suggested, we need to disconnect the hostnames HBase uses internally from those posted to ZK for external consumption. One option could be to do it like HDFS rack mapping: a configuration property specifies a script that the master will execute to map IP addresses to internal and external names. It takes as input the IP address and a flag that specifies "internal" or "external". The results from executing the script with "internal" would be handed to regionservers as their identity, the results from executing with "external" would be advertised in ZooKeeper. Edit: Or invoke the script once and have it hand back all necessary information, structured as YAML or JSON or similar. was (Author: apurtell): This is similar of course to issues operators face on EC2 clouds, where the reverse resolved internal DNS names are of no use unless all clients are also using the internal resolvers. So like Stack suggested, we need to disconnect the hostnames HBase uses internally from those posted to ZK for external consumption. One option could be to do it like HDFS rack mapping: a configuration property specifies a script that the master will execute to map IP addresses to internal and external names. It takes as input the IP address and a flag that specifies "internal" or "external". The results from executing the script with "internal" would be handed to regionservers as their identity, the results from executing with "external" would be advertised in ZooKeeper. > Ability impaired 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. > Assignee: Ted Yu > Priority: Minor > Attachments: 12954-v1.txt, Hadoop Three Interfaces.png > > > 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 specify: > # 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 (v6.3.4#6332)