[
https://issues.apache.org/jira/browse/HBASE-6721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14720500#comment-14720500
]
Elliott Clark commented on HBASE-6721:
--------------------------------------
bq.I also find this a lot less impactful than MOB
This is touching the code that empirically has been the worst part of hbase,
and making it more complex. It's adding things that require user configuration.
Adding things that require user interaction on failure (failed open is an awful
thing to do to a table).
This adds another table that's required for the master to interact with for
assignment and region movement. Right now master is really struggling because
of the feedback loop of rit -> meta -> meta moves -> rit. Now we have double
the number of tables.
On top of that it adds in more things to Zk while we're trying to remove as
much data from there as possible.
This patch breaks ipv6.
This patch has Copy Paste code.
This patch doesn't have the correct headers.
This patch doesn't load meta's hri from disk on move.
bq. IMHO that's not an objective comparison. Favored Nodes and Region Server
groups are very different.
Not really they both are user configured places to put regions. Both features
interact with the balancer and AM. Both features affect the cluster in
disasters in basically the same way.
bq.Adding more states?
Failed open due to bogus servers. So an old state used in a new way. That means
something different than it did before.
bq.That there's an option to configure a different balancer?
There are tons more configurations than that. There's namespace goups, table
groups and groups for regionservers to be part of. Then there's all of the
different configurations for the servers that are in different groups.
This is the worst possible way to do multi-tenancy. We're layering a hack on
rather than do the real thing.
You're getting the same number of SPOF's and an added operational complexity.
If we want multi-tenancy, then lets do that right. We shouldn't accept hacks
that don't help most users and make getting to the correct solution harder.
> RegionServer Group based Assignment
> -----------------------------------
>
> Key: HBASE-6721
> URL: https://issues.apache.org/jira/browse/HBASE-6721
> Project: HBase
> Issue Type: New Feature
> Reporter: Francis Liu
> Assignee: Francis Liu
> Labels: hbase-6721
> Attachments: 6721-master-webUI.patch, HBASE-6721
> GroupBasedLoadBalancer Sequence Diagram.xml, HBASE-6721-DesigDoc.pdf,
> HBASE-6721-DesigDoc.pdf, HBASE-6721-DesigDoc.pdf, HBASE-6721-DesigDoc.pdf,
> HBASE-6721_0.98_2.patch, HBASE-6721_10.patch, HBASE-6721_11.patch,
> HBASE-6721_12.patch, HBASE-6721_8.patch, HBASE-6721_9.patch,
> HBASE-6721_9.patch, HBASE-6721_94.patch, HBASE-6721_94.patch,
> HBASE-6721_94_2.patch, HBASE-6721_94_3.patch, HBASE-6721_94_3.patch,
> HBASE-6721_94_4.patch, HBASE-6721_94_5.patch, HBASE-6721_94_6.patch,
> HBASE-6721_94_7.patch, HBASE-6721_98_1.patch, HBASE-6721_98_2.patch,
> HBASE-6721_hbase-6721_addendum.patch, HBASE-6721_trunk.patch,
> HBASE-6721_trunk.patch, HBASE-6721_trunk.patch, HBASE-6721_trunk1.patch,
> HBASE-6721_trunk2.patch, balanceCluster Sequence Diagram.svg,
> immediateAssignments Sequence Diagram.svg, randomAssignment Sequence
> Diagram.svg, retainAssignment Sequence Diagram.svg, roundRobinAssignment
> Sequence Diagram.svg
>
>
> In multi-tenant deployments of HBase, it is likely that a RegionServer will
> be serving out regions from a number of different tables owned by various
> client applications. Being able to group a subset of running RegionServers
> and assign specific tables to it, provides a client application a level of
> isolation and resource allocation.
> The proposal essentially is to have an AssignmentManager which is aware of
> RegionServer groups and assigns tables to region servers based on groupings.
> Load balancing will occur on a per group basis as well.
> This is essentially a simplification of the approach taken in HBASE-4120. See
> attached document.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
