Openstack架构分析.docx
《Openstack架构分析.docx》由会员分享，可在线阅读，更多相关《Openstack架构分析.docx（40页珍藏版）》请在冰豆网上搜索。
Openstack架构分析
OpenStack的架构
1.OpenStack是什么
OpenStack既是一个社区，也是一个项目和一个开源软件，它提供了一个部署云的操作
平台或工具集。
其宗旨在于，帮助组织运行为虚拟计算或存储服务的云，为公有云、私有云，
也为大云、小云提供可扩展的、灵活的云计算
OpenStack旗下包含了一组由社区维护的开源项目，他们分别是
OpenStackCompute
Nova），OpenStackObjectStorage（Swift），以及OpenStackImageService（Glance）。
OpenStackCompute[1]，为云组织的控制器，包括运行实例、
它提供一个工具来部署云，
管理网络以及控制用户和其他项目对云的访问
的开源项目名称Nova，其提供的软件能控
是制
thecloudthroughusersandprojects）。
它底层
IaaS云计算平台，类似AmazonEC2和于
RackspaceCloudServers。
实际上它定义的是，与运行在主机操作系统上潜在的虚拟化机制
交互的驱动，暴露基于WebAPI的功能
OpenStackObjectStorage[2]，是一个可扩展的对象存储系统。
对象存储支持多种应用，
比如复制和存档数据，图像或视频服务，存储次级静态数据，开发数据存储整合的新应用，存储容量难以估计的数据，为Web应用创建基于云的弹性存储。
OpenStackImageService[1]，是一个虚拟机镜像的存储、查询和检索系统，服务包括的
RESTful
API
允许用户通
过
HTTP请求查VM镜像元数据，以及检索实际的镜像。
询
VM镜
Storage的对象存储系统，直
Object的S3间接访S3。
Store问
像有四种配置方式：
简单的文件系统，类OpenStack
似Object接Amazon'sSimpleStorageSolution存储，用带
用（S3）有
三个项目的基本关系如下1-1所示：
图
a）
b）
c）
d）
的服
OpenStack能
实现这一点，我们需要提供几个高级特性：
2.云
IaaS，提供类似AmazonWeb
为
1-1OpenStack三个组件的关系
念架构
们建立自己的
允许应用拥有者注册云服务，查看运用和计费情况；
创建和存储他们应用的自定义镜像；
允许Developers/DevOpsfolks
允许他们启动、监控和终止实例；
这四点都直击提供
2-1中
允许CloudOperator配置和操作基
进如下所示的概念架构
IaaS的核心，
设你同意了这四个特性，现在就可以将它们放
2-1OpenStack概念架构
在此模型中，作者假设了需要与云交互的四个用户集：
developers,devops,ownersand
operators，并为每类用户划分了他们所需要的功能。
该架构采用的是非常普通的分层方法
），它带有两个正交区域。
presentation,logicandresources
展示层，组件与用户交互，接受和呈现信息。
Webportals为非开发者提供图形界面，为
开发者提供API端点。
如果是更复杂的结构，负载均衡，控制代理，安全和名称服务也都
会在这层。
逻辑层为云提供逻辑（intelligence）和控制功能。
这层包括部署（复杂任务的工作流），
调度（作业到资源的映射），策略（配额等等），镜像注册registry（实例镜像的元数据
image
），
日志（事件和计量）。
假设绝大多数服务提供者已经有客户身份和计费系统。
在任何复杂的环境下，我们都将需要一个
任何云架构都需要整合这些系统。
management层来操作这个环境。
它应该包括
一个API访问云管理特性以及一些监控形式形式加
forms）。
很可能，监控功能将以整合的
入一个已存在的工具中。
当前的架构中已经为我们虚拟的服务提供商加入了
monitorin
amnAI在更完
provisionin
和
和
的架构中，你将见到一系列的支持功能，比如g
configurationmanagement。
compute云，我们就需要实际的和storage
）还是其他的一些资源。
networkattachedstorage
架构
组件中的绝大多数可
护进程（
customwrittenpythondaemons
）
a）
etc
执行部署任务的Worke
b）
rk,nova-schedule,etc.
然而，逻辑架构中有两个重要
Python，它们
是消息队列和数据库。
二者简化
逻辑架构图3-1如下所示：
3-1
从图中，我们可以总结出三点：
逻辑架构逻辑架构中，
资源，以供应给我们的客户。
该层提供这些服务，无论他们是服务
3.1OpenStackComputeOpenStackCompute的
最后，资源层。
既然这是一个
compute、network
）。
3.OpenStackCompute
分为两
Python守
接收和协调API调用的WSGI应用（nova-api,
glance-api,
不是基于
递和信息共享的任务）
的异步部署。
a）终端用户（DevOps,D
话来与OpenStackCompute交互
OpenS
pi对
b）OpenStackCompute守护进程之间通过队列（行为）和数据库（信息）来交换信息，以执行API请求。
c）OpenStackGlance基本上是独立的基础架构，OpenStackCompute通过GlanceAPI来和它交互。
其各个组件的情况如下：
a）nova-api守护进程是OpenStackCompute的中心。
它为所有API查询（OpenStackAPI
或EC2API）提供端点，初始化绝大多数部署活动（比如运行实例），以及实施一些策略（绝大多数的配额检查）。
b）nova-compute进程主要是一个创建和终止虚拟机实例的Worker守护进程。
其过程
相当复杂，但是基本原理很简单：
从队列中接收行为，然后在更新数据库的状态时，执行一系列的系统命令执行他们。
c）nova-volume管理映射到计算机实例的卷的创建、附加和取消。
这些卷可以来自很多提供商，比如，ISCSI和AoE。
d）Nova-networkworker守护进程类似于nova-compute和nova-volume。
它从队列中
接收网络任务，然后执行任务以操控网络，比如创建bridginginterfaces或改变
iptablesrules。
e）Queue提供中心hub，为守护进程传递消息。
当前用RabbitMQ实现。
但是理论上
能是pythonampqlib支持的任何AMPQ消息队列。
SQLdatabase存储云基础架构中的绝大多数编译时和运行时状
f）态。
这包括了可用的实例类型，在用的实例，可用的网络和项目。
理论上，OpenStackCompute能支持SQL-Alchemy支持的任何数据库，但是当前广泛使用的数据库是sqlite3（仅适合
测试和开发工作），MySQL和PostgreSQL。
OpenStackGlance，是一个单独的项目，它是一
g）个compute架构中可选的部分，分为三个部分：
glance-api,glance-registryandtheimagestore.其中，
glance-api接受
API调用，glance-registry负责存储和检索镜像的元数据，
实际的ImageBlob存储在ImageStore中。
ImageStore可以是多种不ObjectStore，包括同的OpenStack
ObjectStorage（Swift）
OpenStackDashboard提供了一
h）最后，userdashboard是另一个可选的项目。
个
devopsstaff类似API的功能。
当前
OpenStackCompute界面来给应用开发者和它是
Web前端。
作为DjangowebApplication来实现的。
当然，也有其他可
用的
3.2
概念映射
将逻辑架构映射到概念架构中（如
3-2所示），可以看见我们还缺少什么
3-2
这种覆盖方式并不是唯一的，逻辑组件，Glance和Dashboard
b）
c）
逻辑架构到概念架构的映射
这里的只是作者的理解。
通过覆盖OpenStackCompute
，来表示功能范围。
对于每一个覆盖，都有相应的提供
该功能的逻辑组件的名称
在这种覆盖范围中，
最大的差距是logging和billing
。
此刻，
OpenStackCompute没
有能协
loggin
事件、记录日志以及创/呈
bil
的Billi
组件。
真正的焦点是
调
g
建现
ls
ng
loggin
和Billi
的整合。
这能通过以下方式来补
比如代码扩充，商业产品或者
g
ng
救。
a）
服务或者自定义日志解析的整合
Identity也是未来可能要补充的一点。
customerportal也是一个整合点。
userdashboard（见运行的实例，启动新的实例）没有提供一个界面，来允许应用拥有者签署服务，跟踪它们的费用以及声明有问题的
d）理想的情况是，AdminAPI
会复制我们能通过命令行接口做的所有功能。
在带有
AdminAPIwork
的Diablo
发布中会更好。
e）
云监控和操作将是服务提供商关注的重点。
好操作方法的关键是好的工具。
当前，
票据（lodgetroubletickets）。
而且，这很可能对我们设想的服务提供商来说是合适的
OpenStackCompute提供nova-instancemonitor，它跟踪计算结点使用情况。
未来我
们还需要三方工具来监控
f）Policy是极其重要的方面，但是会与供应商很相关。
从quotas到QoS，到隐私控制都在其管辖内。
当前图上有部分覆盖，但是这取决于供应商的复杂需求。
为准确起
见，OpenStack
Compute
为实例，浮IP地址以及元数据提供配额。
点
g）当前，OpenStack内
Compute的
Schedulin对于大的安装来说是相当初步的。
调度器
是以插件的方式设计的，目前支
持
g
chance（随机主机分），simple（最少）zone配负载和
在一个可用区域里的随机结点。
）分布式的调度器和理解异构主机的调度器正在开
发之中。
如你所见，OpenStackCompute为我们想象的服务提供商，提供了一个不错的基础，只要服务提供商愿意做一些整合。
3.3OpenStackCompute系统架构
OpenStackCompute由一些主要组件组成
Cloudcontroller
包含很多组件，它表示全
局状态，以及与其他组件交互。
实际上，它提供的是
Nova-api服务。
它的功能是：
为所有
API查询提供一个端点，初始化绝大多数的部署活动，
以及实施一些策略
API服务器起cloud
controller
compute服务资源，典型包含
webService
前端的作用
Computecontroller提供
computeservice，ObjectStorecomponent
可选地提供存储服务。
Authmanager提供认证和授
权服务，Volumecontroller
servers提供快速和持久的块级别存储。
为compute
Network
control提供虚拟网络
ler使
computeservers彼此交互以及与公网进行交互。
Scheduler选择最
合适
的
computecontroller
来管理host）一个实例（
OpenStackCompute
建立在无共享、基于消息的架构上
Cloudcontroller
通HTTP与
过
internalobjectstore
交互，通过AMQP和scheduler
networkcontroller
、和volumecontroller
来进行通信。
为了避免在等待接收时阻塞每个组件，
OpenStackCompute
用异步调用的方式
为了获得带有一个组件多个备份的无共享属OpenStackCompute将所有的云系统状性，
态保持在分布式的数据存储中。
对系统状态的更新会写到这个存储中，必要时用质子事务。
对系统状态的请求会从store中读出。
在少数情况下，控制器也会短时间缓存读取结果
3.4OpenStackCompute物理架构
nova-
OpenStackCompute采用无共享、基于消息的架构，非常灵活，我们能安装每个
service在单独的服务器上，
点部署唯一的联合依赖性，
这意味着安装OpenStackCompute有多种可能的方法。
可能多结是Dashboard必须被安装在nova-api服务器。
几种部署架构如下：
a）单结点：
为尝试OpenStackCompute，或者为了开发目的；
一台服务器运行所有的nova-services
，同时也驱动虚拟实例。
这种配置只
b）双结点：
一个cloudcontroller
结点运行
结点运行除nova-compute外的所有nova-services，compute
-compute。
一台客户计算机很可能需要打包镜像，
互，但是并不是必要的。
这种配置主要用于概念和开发环境的证明。
以及和服务器进行交
点，
通过简单部署nova-compute在一台额外的服务器以及拷贝nova.conf文件到这
你能在两结点的基础上，添加更多的
compute结点，形成多结点部署。
杂的多
在较为复
结点部署中，还能增加一个
为额外的
4个结点是最
少
变）
如
e物理架构
一种可选的架构
更多的
外的
Messaging服务器。
在这种情形下，除了可以扩展数据库服务器外，还可以增
RabbitMQ服务器。
部署中可以在任意服务器上
nova-service
volumecontroller和一个networkcontroller
，只要nova.conf中配
结
。
对于运行多个需要大量处理能力的虚拟机实例，
的OpenstackCompute多服务器部署（集群中联网的虚拟服务器可能会
3-3OpenStackComp
如果你注意到消息队列中大量的复制
了性能问题
这些服务器
置为指向RabbitMQ服务器，并且
下图3-4是另外一种多结点的部署架构。
能发送消息到它。
4
3.5OpenStackCompute服务架构
因为Compute有多个服务，了总体的服务架构，
多结点的部署架构二
置，
也可能有多种
以及
服务之间的通信系统。
下图
3-5
显示
3-5OpenStackCompute服务架构
OpenStackImageService
和Registryserver（s）
4.
OpenStackImageService
包括两个主要的部分，分别是
的设计，尽可能适合各
API
server
种后端仓储和注册数据库方案
OpenStackImage
Service
（运行“glanceapi”程序）起通信hub的作用。
比如各种各样的客户程序，镜像元数据的
APIServer
注册，实际包含虚拟机镜像数据的存储系统，都是通过它来进行通信的。
户端的请求到镜像元数据注册处和它的后端仓储。
制来实际保存进来的虚拟机镜像的
OpenStackImageService
a）OpenStackObjectStorage
APIserver
转发客
就是通过这些机
支持的后端仓储有：
b）FileSystem。
OpenStackImageService
它是OpenStack中高可用的对象存储项目。
ervice存储虚拟机镜像的默认后端是后端文件系统。
这
个简单的后端会把镜像文件写到本地文件系统。
c）S3。
该后端允许OpenStackImageService存储虚拟机镜像在AmazonS3服务中。
d）HTTP。
OpenStackImageService能通过HTTP在Internet上读取可用的虚拟机镜像。
这种存储方式是只读的。
OpenStackImageServiceregistryservers是遵守
OpenStackImageServiceRegistryAPI
的服务器。
根据安装手册，这两个服务安装在同一个服务器上。
镜像本身则可存储在OpenStack
ObjectStorage，Amazon'sS3infrastructure，fileSystem。
如果你只需要只读访问，可以存储
在一台Web服务器上。
5.OpenStackObjectStorage
5.1关键概念
a）Accounts和AccountServers
OpenStackObjectStorage系统被设计来供许多不同的存储消费者或客户使用。
每个用户必须通过认证系统来识别自己。
为此，OpenStackObjectStorage提供了一个授权系统
Account服务器是存储系统的部分，
（swauth）。
运Accoun服务的结点与个体账户是不同的概行t念。
必须Containe服务器Objec服务器配置在一起
和r和t
b）Authentication和AccessPermissions
你必须通过认证服务来认证，以接收OpenStackObjectStorage连接参数和认证令牌。
令牌必须为所有后面
的
API处理认证，
container/obj操作而传递。
典型的，特定语言ect的
令牌传递
和
HTTPSrequest/response
通信。
通过运X-Container-Read:
accountnameX-Container-
用和Write:
accountname:
username，
你能为用户或者账户对对象执行访问控制。
比如，
这个设置就允许来accountname账户的自
的任意用户来读，但是只允许
accountname账户里的用户username来写。
你也能给
OpenStack
Object中存储的对象授予公共访问的权限，Storage
这种基于站点的内容盗窃，来限制公共访问。
公共的
上的默认授权。
比如，X-Container-Read:
referer:
any
而且可以通Refere头部阻止像热链接过r
contain设置被用作访问控制列表之
er
这个设置，允许任何人能container从
中读，而不管其他的授权设置。
一旦
一般来说，每个用户能完全访问自己的存储账户。
用户必须用他们的证书来认证，
被认证，他们就能创建或删除container，以及账户之类的对象。
一个用户能访问另一个账户的内容的唯一方式是，他们享有一个API访问key或你的认证系统提供的会话令牌。
c）ContainersandObjects
一个Container是一个存储隔间，为你提供一种组织属于属于你的数据的方式。
它比较类似于文件夹或目录。
Container和其他文件系统概念的主要差异是containers不能嵌套。
然而，你可以在你的账户内创建无数的containers。
但是你必须在你的账户上有一个container，因为数据必须存在Container中。
Container取名上的限制是，它们不能包含“/”，而且长度上少于256字节。
长度的限制
也适用于经过URL编码后的名字。
比如，CourseDocs的Container名经过URL编码后是
“Course%20Docs”，因此此时的长度是13字节而非11字节。
一个对象是基本的存储实体，和表示你存储在OpenStackObjectStorage系统中文件的任何可选的元数据。
当你上传数据到OpenStackObjectStorage，它原样存储，由一个位置（container），对象名，以及key/value对组成的任何元数据。
比如，你可选择存储你数字照片的副本，把它们组织为一个影集。
在这种情况下，每个对象可以用元数据Album:
CaribbeanCruise或Album:
AspenSkiTrip来标记。
对象名上唯一的限制是，在经过URL编码后，它们的长度要少于1024个字节。
上传的存储对象的允许的最大大小5GB，最小是0字节。
你能用内嵌的大对象支持和
St工具来检索5GB以上的对象。
对于元数据，每个对象不应该超过90个key/value对，所
有key/value对的总字节长度不应该超过4KB。
d）Operations
Operations是你在OpenStackObjectStorage系统上执行的行为，比如创建或删除containers，上传或下载objects等等。
Operations的完全清单可以在开发文档上找到。
Operations能通过ReSTwebserviceAPI或特定语言的API来执行。
值得
升级会员 