[
https://issues.apache.org/jira/browse/HBASE-11288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17112530#comment-17112530
]
Andrew Kyle Purtell edited comment on HBASE-11288 at 5/20/20, 7:17 PM:
-----------------------------------------------------------------------
bq. I agree publishing all the regionserver locations wouldn't make sense, but
I'm curious and probably missing something as to why can't we publish a subset
of regionserver locations?
Because we also want migrating service discovery and configuration
considerations to closely align, to avoid having to rethink how clients
discover cluster service. Right now operators have to pass around a string of
zookeeper endpoints. As you know zookeeper quorums are limited in size by how
they scale writes. And, in many deployments, ZK and masters might be colocated,
because they are both _meta_ services (metadata and coordination), and their
deployments have the same shape both in terms of number of instances and
placement with respect to failure domains. Sum these considerations, it is
highly advantageous if you have a string of ZK endpoints today, and tomorrow
you simply replace this string with a string of master endpoints. Probably its
the same list of hostnames served to clients the same way the zk quorum string
was previously served, with only the port numbers changing.
In contrast, what if we start exporting a subset of regionservers. How does
that work? It's guaranteed to be different from how zk quorum strings worked.
There are a lot more of them, they are randomly chosen (?), the connection info
has to dynamic instead of static (how is that collected? published to
clients?). I could go on. The alternative, described above, has been well
thought out, IMHO.
was (Author: apurtell):
bq. I agree publishing all the regionserver locations wouldn't make sense, but
I'm curious and probably missing something as to why can't we publish a subset
of regionserver locations?
Because we also want migrating service discovery and configuration
considerations to closely align, to avoid having to rethink how clients
discover cluster service. Right now operators have to pass around a string of
zookeeper endpoints. As you know zookeeper quorums are limited in size by how
they scale writes. And, in many deployments, ZK and masters might be colocated,
because they are both metadata services, and their deployments have the same
shape both in terms of number of instances and placement with respect to
failure domains. Sum these considerations, it is highly advantageous if you
have a string of ZK endpoints today, and tomorrow you simply replace this
string with a string of master endpoints. Probably its the same list of
hostnames served to clients the same way the zk quorum string was previously
served, with only the port numbers changing.
In contrast, what if we start exporting a subset of regionservers. How does
that work? It's guaranteed to be different from how zk quorum strings worked.
There are a lot more of them, they are randomly chosen (?), the connection info
has to dynamic instead of static (how is that collected? published to
clients?). I could go on. The alternative, described above, has been well
thought out, IMHO.
> Splittable Meta
> ---------------
>
> Key: HBASE-11288
> URL: https://issues.apache.org/jira/browse/HBASE-11288
> Project: HBase
> Issue Type: Umbrella
> Components: meta
> Reporter: Francis Christopher Liu
> Assignee: Francis Christopher Liu
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
