[
https://issues.apache.org/jira/browse/HBASE-6721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14720647#comment-14720647
]
Francis Liu commented on HBASE-6721:
------------------------------------
{quote}
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).
{quote}
This is a key feature, it's better to penalize a misbehaving table than have it
affect and potentially take down the entire cluster. This will only happen if
all the servers are down analogous to a cluster being down. It's pretty
intuitive. We can add a better message if need be.
{quote}
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.
{quote}
It actually doesn't. The table is only read at startup and never again.
{quote}
On top of that it adds in more things to Zk while we're trying to remove as
much data from there as possible.
{quote}
Yes, this will be addressed just like the other modules that currently use zk.
{quote}
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.
{quote}
Thanks for the review. I'll make sure to address them. Can you point out which
code is copy paste. Also please elaborate on meta hri? Prolly post it on RB so
we don't pollute this discussion?
{quote}
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.
{quote}
IMHO this is a huge oversimplification. I agree with [~apurtell] let's evaluate
regionserver group on it's own merits. ie User configures regionservers to put
tables on not regions. Region servers can be any number while in FN it can be
at most (or only?) 3. FN was designed to guarantee performance, RS was meant to
guarantee isolation.
{quote}
There are tons more configurations than that. There's namespace goups, table
groups and groups for regionservers to be part of.
{quote}
Right now there's only group and it can have regionservers and tables as
members.
{quote}
Then there's all of the different configurations for the servers that are in
different groups.
{quote}
This is no different from configuring different clusters and is optional. A
really good feature IMHO.
{quote}
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.
{quote}
IMHO the operational complexity is better than managing the same number of
clusters. I honestly would not like to increase my number of SPOFs that
increases the probability of one going down. Also isn't there NN HA already?
{quote}
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.
{quote}
IMHO this will help a lot of users. This is not only a multi-tenancy solution
but an isolation solution. It will help them isolate different workloads (ie
CD/PROD, batch/realtime). It will also help them isolate system tables becoming
unavailable because a user access pattern/data surfaced a bug which caused the
RS to die. It also allows you to configure each group differently (ie GC
settings). It also provides coprocessor isolation.
> 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)
