main  >   ni掌柜 / taokeeper

project:None

Creative:ni掌柜 create at2012年02月12日

ZooKeeper权限控制

原文链接:http://code.taobao.org/p/taokeeper/wiki/index

目前在公司内部使用ZooKeeper的地方越来越多,应用大多喜欢自己部署一套ZK集群来使用。考虑到ZK的高可用,并且一套ZK集群至少3台机器, 那么每个应用,尤其是一些非核心应用都自己去部署一套的话,对资源利用率很低。另外,随着ZK容灾的提出,单套ZK集群使用的机器量会更大,运维人员开始 对这个情况担忧,强烈希望能够合并ZK集群。

ZK集群合并使用本身并没有太大的难度,问题在于应用方是否愿意大家共用一套ZK集群,这其中一个显而易见的问题就是权限:如果我的数据被别人动了怎么办?

在公司不少牛人的帮助下,暂时得到两个权限方案,同时也希望大家提出自己的看法,共同进步。

方案一:采用ZooKeeper支持的digest方式,用户自己定义节点的权限

这种方案将zookeeper的acl和digest授权认证模式相结合。具体操作流程如下:

可以把这个访问授权过程看作是用户注册,系统给你一个密码,每次操作使用这个用户名(appName)和密码. 于是就可以对应有这样权限管理系统,专门是负责进行节点的创建申请:包含“申请私有节点”和“申请公有节点”。这样一来,节点的创建都是由这个权限管理系 统来负责了,每次申请完后,系统都会返回给你的一个key,格式通常是“{appName}:{password}”,以后你的任何操作都要在zk session 中携带上这个key,这样就能进行权限控制。当然,用户自己通过zk客户端进行path的创建也是可以的,只是要求他们要使用授权方式来进行zk节点的创建。 整个权限控制流程的代码测试,如下图所示: 源代码见附件。

注意:ZooKeeper原生的API是支持这种方式的,但是GitHub上的zkclient目前还不支持,我已经在它基础上添加了权限控制接口,测试通过。如果你正在使用这个客户端,那么不妨尝试一下。( https://github.com/nileader/zkclient

方案二、对zookeeper的AuthenticationProvider进行扩展,和内部其它系统A打通,从系统A中获取一些信息来判断权限

这个方案大致是这样: 1.A系统上有一份IP和appName对应的数据本地。 2.将这份数据在ZK服务器上缓存一份,并定时进行缓存更新。 3.每次客户端对服务器发起请求的时候,获取客户端ip进行查询,判断是否有对应appName的权限。限制指定ip只能操作指定 /appName znode。 4.其它容灾措施。

个人比较两个方案 1.方案一较方案二,用户的掌控性大,无论线上,日常,测试都可以由应用开发人员自己决定开启/关闭权限。 (方案一的优势) 2.方案二较方案一,易用性强,用户的使用和无权限基本一致。 (方案二的优势) 3.方案一较方案二更为纯洁。因为我觉得zk本来就应该是一个底层组件,让他来依赖其它上层的另一个系统?权限的控制精度取决于系统A上信息的准确性。 (方案一的优势)

另外附上 方案一 有权限和无权限对比压测TPS情况 测试条件:三台ZK服务器:8核 JDK 1.6.0-06 四台zk客户端机器:5核 JDK1.6.0-21 测试场景:800个发布者,对应800个path,每个path 3个订阅者,共2400个订阅者。发布者发布数据,通知订阅者。 结论:权限控制对zk的TPS有一定的影响,但是还是保持在较高的水准(1.3w+),如图(点击查看大图):

Attachments

ni掌柜 | 2012-02-12 13:14:41 | press_test.jpg | 58.0 KB
ni掌柜 | 2012-02-12 13:14:36 | java_programme_run_result.jpg | 186.3 KB
ni掌柜 | 2012-02-12 13:14:30 | auth_control_procedure.jpg | 23.4 KB
ni掌柜 | 2012-02-12 11:31:11 | DemoAuth.java | 7.9 KB
ni掌柜 | 2012-02-12 11:31:04 | ZooKeeper-Authentication.pdf | 356.4 KB