You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Andrew Purtell (JIRA)" <ji...@apache.org> on 2012/11/05 18:28:15 UTC

[jira] [Comment Edited] (HBASE-6721) RegionServer Group based Assignment

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

Andrew Purtell edited comment on HBASE-6721 at 11/5/12 5:27 PM:
----------------------------------------------------------------

Regarding storing the group assignment information in ZooKeeper, I think this is a good strategy. You can optimize for the case where HBase (re)starts with valid group assignment data available in ZK. Therefore you can avoid some bootstrapping challenges. However, you must persist the group assignment information into a table, like how security does with {{_acl_}}. After starting up, if in the uncommon case there is group assignment information in the {{_group_}} (or similar) table that is not in sync with that in ZK (perhaps because ZK state was cleared), you should update ZK data accordingly. From there, there are a couple of options:
- WARN the administrator that the table assignments should be updated via disable and enable.
- Automatically trigger reassignment via disable and enable. 
- Region moves (if the assignment information is available - trunk only)

Edit: Fix incorrect use of markup.
                
      was (Author: apurtell):
    Regarding storing the group assignment information in ZooKeeper, I think this is a good strategy. You can optimize for the case where HBase (re)starts with valid group assignment data available in ZK. Therefore you can avoid some bootstrapping challenges. However, you must persist the group assignment information into a table, like how security does with "__acl__". After starting up, if in the uncommon case there is group assignment information in the "__group__" (or similar) table that is not in sync with that in ZK (perhaps because ZK state was cleared), you should update ZK data accordingly. From there, there are a couple of options:
- WARN the administrator that the table assignments should be updated via disable and enable.
- Automatically trigger reassignment via disable and enable. 
- Region moves (if the assignment information is available - trunk only)
                  
> 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
>             Fix For: 0.96.0
>
>         Attachments: HBASE-6721_94_2.patch, HBASE-6721_94.patch, HBASE-6721_94.patch, HBASE-6721-DesigDoc.pdf
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira