hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-6721) RegionServer Group based Assignment
Date Tue, 25 Nov 2014 00:33:12 GMT

    [ https://issues.apache.org/jira/browse/HBASE-6721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14223835#comment-14223835

Enis Soztutar commented on HBASE-6721:

I left some comments in RB, but I wanted to comment on high level things here. 

I think this is generally a useful feature, since we are seeing more and more multi-tenant
use cases, and without really good isolation rs groups allow the cluster to be shared more
 - I was reading up on the recent YARN label feature (YARN-796), since the ideas are very
similar. However, in YARN labels, a node can have multiple labels, versus here, a server can
only have one group. 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. For assignment, we just look at all the cumulative list of servers
that this region will be assignable to. Will this complicate assignment? 
 - Alternatively we can also name this labels (just a suggestion). 
 - 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. 
 - 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.

> 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

This message was sent by Atlassian JIRA

View raw message