[
https://issues.apache.org/jira/browse/HBASE-6721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14224150#comment-14224150
]
Francis Liu commented on HBASE-6721:
------------------------------------
Enis, thanks for the review:
{quote}
Will it be better to have one-to-many relationship from servers to groups? All
servers will have the default group, as well as any more groups that it is
assigned. We can do the same thing for tables as well. By default, tables will
belong to group default, but can be added more.
{quote}
I skimmed through YARN-796 doc. To me it seems the notion of yarn labels and rs
groups are very different. Labels are intended to add attributes to certain
resources (ie gpu, high-memory, etc) so you can request for specific attributes
when requesting for resources. While groups mentioned in this jira is meant to
identify a logical grouping of resources, meant to guarantee an amount of
resources/capacity for a tenant. We have not seen a need for it to date. What
do we gain from doing the same for tables? It seems to me the purpose of groups
has no need for overlaps either way. Please correct me if I missed something.
{quote}
For all new features, I think it is fair to request one single source of truth
and also some more transactional guarantees for operations. If possible, we
should not use zk at all (for caching as done in patch). Instead we can just
open the region from master. This is different than the co-location discussion
for master and meta. This table is tiny, and not query'able from clients. The
data is just there for the master to access. If we do this, we do not even have
to have a cache.
{quote}
I have thought of this as well, we can do this but it would require handling
group table in a special way. ie make sure it is assigned after meta and before
any other table. have a groupWAL, have it's one sets of handlers similar to
meta, etc. As well as have a special case for making sure meta and root end up
in their designated groups even when group table hasn't been assigned yet. So
we're essentially trading one set of complexities for another. Having said
that, I'm ok with either approach. Should write up a patch with this approach?
On a related note, region servers consume group information from ZK similar to
security ACL. This is used in replication and other features we are working on.
As mentioned it is possible to remove caching usage of ZK but it would be good
to keep the information in there until the same facility security acl will
eventually be migrating to is available. Thoughts?
{quote}
I am ok with bringing this as a core functionality rather than CP + LB. The
reasoning is that as clusters grow bigger, more users might be interested in
this for better isolation.
{quote}
Great with this we can do the approach mentioned earlier if need be.
> 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: Vandana Ayyalasomayajula
> Attachments: 6721-master-webUI.patch, HBASE-6721-DesigDoc.pdf,
> HBASE-6721-DesigDoc.pdf, HBASE-6721-DesigDoc.pdf, HBASE-6721-DesigDoc.pdf,
> HBASE-6721_10.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_trunk.patch, HBASE-6721_trunk.patch,
> HBASE-6721_trunk.patch, HBASE-6721_trunk1.patch, HBASE-6721_trunk2.patch
>
>
> 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)
