Openstack架构分析.docx
- 文档编号:23361451
- 上传时间:2023-05-16
- 格式:DOCX
- 页数:40
- 大小:358.81KB
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来执行。
值得
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Openstack 架构 分析
![提示](https://static.bdocx.com/images/bang_tan.gif)