您的位置:首页 > 运维架构

Openstack Keystone程序框架

2014-06-16 11:03 330 查看
前言:最近教研室在做一个关于Openstack开源云平台的项目,为避免狗熊掰棒子的悲剧再次发生,小牛决定以博客的形式总结记录每日所学,若有错误请大神们指出。

Openstack包括Nova、Swift、Glance、Keystone、Horizon等多个核心项目,今天不再展开讨论,主要关注Keystone。Keystone作为Openstack的核心项目之一,负责为Openstack其他模块提供身份认证服务,其程序自上而下分为如下四层结构:

Keystone API层

Router层

Service层

Backend Driver层

每层负责功能介绍如下:

1.Keystone API层:通过Restful HTTP方式和Openstack其他模块进行交互,对外提供Keystone各种服务。其中Keystone共有两类API:Public API和Admin API。其中Public API实现获取版本以及相应扩展信息的操作、获取Token以及Token租户信息的操作;而Admin API的功能更为强大,除了上述的获取版本及相应扩展信息的操作、获取Token及Token租户信息的操作外,还可以对User、Tenant、Role和Service
Endpoint进行管理操作。

2.Router层:主要实现上层API与下层具体服务之间的映射和转换功能,类似路由转发,所以称之为Router层。与API层对应,Router共分为两类(Public、Admin)共四个Router:

1)Admin Router:负责将Admin API请求映射成对应的行为操作、并转发至底层相应的服务执行。例如对于认证生成Token的Admin API请求,AdminRouter会将其映射为Token服务下的authenticate操作,并传至下层。

2)Public Router:与Admin Router类似,负责对Public API进行映射。

3)Admin Version Router:Keystone专门为获取版本的操作设立了两个Router,暂时还不清楚为何会这么设计,也许是因为底层实现和其他服务区别较大,路由方式不同,这个先不深究。Admin Version Router会将上层Admin API的版本请求映射为get_version操作,并交由底层Catalog服务来执行。

4)Public Version Router:与上类似,负责对系统版本的Public API进行映射操作。

3.Service及相应Backend Driver

Service和Backen Driver两层之间紧密耦合,接收上次Router发来的具体操作请求并执行请求,是认证等相关功能的具体执行者,提供Identity、Token、Catalog、Policy等服务。以Identity认证服务为例,通过后端获取User、Tenant、Metadata等相关数据并进行验证。Keystone对Identity服务提供4种后端驱动:sql、kvs、pam、ldap。

1)sql:后端Mysql数据库建立连接,除获取基本数据外,还支持对User、Tenant、Role的CRUD操作(Create/Read/Update/Delete)。

2)ldap:与sql类似,与后端LDAP建立连接,支持对User、Tenant、Role的CRUD操作。

3)pam:基于linux系统的PAM(Pluggable Authentication Modules)服务实现认证功能,但功能较单一,不支持CRUD操作。

4)kvs:通过Keystone自己实现的key-values store方式进行认证服务,支持对User、Tenant、Role的CRUD操作。

以上是最基本的Keystone的四层框架结构,自上而下的功能分配还是比较清晰的,后面随着项目研究的不断深入,会针对某个或某几个层次进行深入研究。

    
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息