Openstack架构分析Word下载.docx
《Openstack架构分析Word下载.docx》由会员分享，可在线阅读，更多相关《Openstack架构分析Word下载.docx（18页珍藏版）》请在冰豆网上搜索。
a）
b）
c）
d）
允许应用拥有者注册云服务，查看运用和计费情况；
允许Developers/DevOpsfolks创建和存储他们应用的自定义镜像；
允许他们启动、监控和终止实例；
允许CloudOperator配置和操作基础架构
这四点都直击提供IaaS的核心，现在假设你同意了这四个特性，现在就可以将它们放
进如下所示的概念架构2-1中。
2-1OpenStack概念架构
在此模型中，作者假设了需要与云交互的四个用户集：
developers,devops,ownersand
operators，并为每类用户划分了他们所需要的功能。
该架构采用的是非常普通的分层方法（presentation,logicandresources），它带有两个正交区域。
展示层，组件与用户交互，接受和呈现信息。
Webportals为非开发者提供图形界面，
为开发者提供API端点。
如果是更复杂的结构，负载均衡，控制代理，安全和名称服务也都会在这层。
逻辑层为云提供逻辑（intelligence）和控制功能。
这层包括部署（复杂任务的工作流），
调度（作业到资源的映射），策略（配额等等），镜像注册imageregistry（实例镜像的元数据），日志（事件和计量）。
假设绝大多数服务提供者已经有客户身份和计费系统。
任何云架构都需要整合这些系统。
在任何复杂的环境下，我们都将需要一个management层来操作这个环境。
它应该包
括一个API访问云管理特性以及一些监控形式（forms）。
很可能，监控功能将以整合的形
式加入一个已存在的工具中。
当前的架构中已经为我们虚拟的服务提供商加入了monitoring和adminAPI，在更完全的架构中，你将见到一系列的支持功能，比如
provisioning和configurationmanagement。
最后，资源层。
既然这是一个compute云，我们就需要实际的compute、network
和
storage资源，以供应给我们的客户。
该层提供这些服务，无论他们是服务器，网络交换机，NAS（networkattachedstorage）还是其他的一些资源。
3.OpenStackCompute架构
3.1OpenStackCompute逻辑架构
OpenStackCompute逻辑架构中，组件中的绝大多数可分为两种自定义编写的Python守护进程（customwrittenpythondaemons）。
接收和协调API调用的WSGI应用（nova-api,glance-api,etc）
执行部署任务的Worker守护进程（nova-compute,nova-network,nova-schedule,etc.）
然而，逻辑架构中有两个重要的部分，既不是自定义编写，也不是基于Python，它们
是消息队列和数据库。
二者简化了复杂任务（通过消息传递和信息共享的任务）的异步部署。
逻辑架构图3-1如下所示：
3-1OpenStackCompute逻辑架构
从图中，我们可以总结出三点：
终端用户（DevOps,Developers和其他的OpenStack组件）通过和nova-api对话来与OpenStackCompute交互。
b）OpenStackCompute守护进程之间通过队列（行为）和数据库（信息）来交换信息，以执行API请求。
c）OpenStackGlance基本上是独立的基础架构，OpenStackCompute通过GlanceAPI来和它交互。
其各个组件的情况如下：
a）nova-api守护进程是OpenStackCompute的中心。
它为所有API查询（OpenStack
API或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消息队列。
f）SQLdatabase存储云基础架构中的绝大多数编译时和运行时状态。
这包括了可用
的实例类型，在用的实例，可用的网络和项目。
理论上，OpenStackCompute能
支持SQL-Alchemy支持的任何数据库，但是当前广泛使用的数据库是sqlite3（仅适合测试和开发工作），MySQL和PostgreSQL。
g）OpenStackGlance，是一个单独的项目，它是一个compute架构中可选的部分，分
为三个部分：
glance-api,glance-registryandtheimagestore.其中，glance-api接受
API调用，glance-registry负责存储和检索镜像的元数据，实际的ImageBlob存储
在ImageStore中。
ImageStore可以是多种不同的ObjectStore，包括OpenStackObjectStorage（Swift）
h）
最后，userdashboard是另一个可选的项目。
OpenStackDashboard提供了一个
OpenStackCompute界面来给应用开发者和devopsstaff类似API的功能。
当前它
是作为DjangowebApplication来实现的。
当然，也有其他可用的Web前端。
3.2概念映射
将逻辑架构映射到概念架构中（如3-2所示），可以看见我们还缺少什么。
3-2逻辑架构到概念架构的映射
这种覆盖方式并不是唯一的，这里的只是作者的理解。
通过覆盖OpenStack
Compute
逻辑组件，Glance和Dashboard，来表示功能范围。
对于每一个覆盖，都有
相应的提供该功能的逻辑组件的名称。
在这种覆盖范围中，最大的差距是logging和billing。
此刻，OpenStackCompute没
有能协调logging事件、记录日志以及创建/呈现bills的Billing组件。
真正的焦点
是logging和Billing的整合。
这能通过以下方式来补救。
比如代码扩充，商业产品或者服务或者自定义日志解析的整合。
b）Identity也是未来可能要补充的一点。
c）customerportal也是一个整合点。
userdashboard（见运行的实例，启动新的实例）
没有提供一个界面，来允许应用拥有者签署服务，跟踪它们的费用以及声明有问题的票据（lodgetroubletickets）。
而且，这很可能对我们设想的服务提供商来说是合适的。
e）
理想的情况是，AdminAPI会复制我们能通过命令行接口做的所有功能。
在带有AdminAPIwork的Diablo发布中会更好。
云监控和操作将是服务提供商关注的重点。
好操作方法的关键是好的工具。
当前，OpenStackCompute提供nova-instancemonitor，它跟踪计算结点使用情况。
未来我们还需要三方工具来监控。
f）Policy是极其重要的方面，但是会与供应商很相关。
从quotas到QoS，到隐私控
制都在其管辖内。
当前图上有部分覆盖，但是这取决于供应商的复杂需求。
为准确起见，OpenStackCompute为实例，浮点IP地址以及元数据提供配额。
g）
当前，OpenStackCompute内的Scheduling对于大的安装来说是相当初步的。
调度
器是以插件的方式设计的，目前支持chance（随机主机分配），simple（最少负载）和
zone（在一个可用区域里的随机结点。
）分布式的调度器和理解异构主机的调度器正在开发之中。
如你所见，OpenStackCompute为我们想象的服务提供商，提供了一个不错的基础，只要服务提供商愿意做一些整合。
3.3OpenStackCompute系统架构
OpenStackCompute由一些主要组件组成。
“Cloudcontroller”包含很多组件，它表示全局状态，以及与其他组件交互。
实际上，它提供的是Nova-api服务。
它的功能是：
为所
有API查询提供一个端点，初始化绝大多数的部署活动，以及实施一些策略。
API
服务器
起cloudcontrollerwebService前端的作用。
Computecontroller提供compute服务资源，典
型包含computeservice，ObjectStorecomponent可选地提供存储服务。
Authmanager提供
认证和授权服务，Volumecontroller为computeservers提供快速和持久的块级别存储。
Networkcontroller提供虚拟网络使computeservers彼此交互以及与公网进行交互。
Scheduler选择最合适的computecontroller来管理（host）一个实例。
OpenStackCompute建立在无共享、基于消息的架构上。
Cloudcontroller通过HTTP
与internalobjectstore交互，通过AMQP和scheduler、networkcontroller、
和volume
controller来进行通信。
为了避免在等待接收时阻塞每个组件，OpenStackCompute用异步调用的方式。
为了获得带有一个组件多个备份的无共享属性，OpenStackCompute将所有的云系统
状态保持在分布式的数据存储中。
对系统状态的更新会写到这个存储中，必要时用质子事务。
对系统状态的请求会从store中读出。
在少数情况下，控制器也会短时间缓存读取结果。
3.4OpenStackCompute物理架构
OpenStackCompute采用无共享、基于消息的架构，非常灵活，我们能安装每个nova-
service在单独的服务器上，这意味着安装OpenStackCompute有多种可能的方法。
可能多
结点部署唯一的联合依赖性，是Dashboard必须被安装在nova-api服务器。
几种部署架构如下：
单结点：
一台服务器运行所有的nova-services，同时也驱动虚拟实例。
这种配置只为尝试OpenStackCompute，或者为了开发目的；
双结点：
一个cloudcontroller
结点运行除nova-compute外的所有nova-
services，compute结点运行nova-compute。
一台客户计算机很可能需要打包镜像，以
及和服务器进行交互，但是并不是必要的。
这种配置主要用于概念和开发环境的证明。
多结点：
通过简单部署nova-compute在一台额外的服务器以及拷贝nova.conf文件到
这个新增的结点，你能在两结点的基础上，添加更多的compute结点，形成多结点部
署。
在较为复杂的多结点部署中，还能增加一个volumecontroller
和一个network
controller作为额外的结点。
对于运行多个需要大量处理能力的虚拟机实例，至少是4个结点是最好的。
一个可能的OpenstackCompute多服务器部署（集群中联网的虚拟服务器可能会改变）如下3-3所示：
3-3OpenStackCompute物理架构一
如果你注意到消息队列中大量的复制引发了性能问题，一种可选的架构是增加更多的Messaging服务器。
在这种情形下，除了可以扩展数据库服务器外，还可以增加一台额外
的RabbitMQ服务器。
部署中可以在任意服务器上运行任意nova-service，只要nova.conf中配置为指向RabbitMQ服务器，并且这些服务器能发送消息到它。
下图3-4是另外一种多结点的部署架构。
3-4多结点的部署架构二
3.5OpenStackCompute服务架构
因为Compute有多个服务，也可能有多种配置，下图3-5显示了总体的服务架构，以及服务之间的通信系统。
3-5OpenStackCompute服务架构
4.OpenStackImageService
OpenStackImageService包括两个主要的部分，分别是APIserver和Registryserver（s）。
OpenStackImageService的设计，尽可能适合各种后端仓储和注册数据库方案。
Server（运行“glanceapi”程序）起通信hub的作用。
比如各种各样的客户程序，镜像元
数据的注册，实际包含虚拟机镜像数据的存储系统，都是通过它来进行通信的。
APIserver
转发客户端的请求到镜像元数据注册处和它的后端仓储。
OpenStackImageService就是通过这些机制来实际保存进来的虚拟机镜像的。
OpenStackImageService支持的后端仓储有：
a）OpenStackObjectStorage。
它是OpenStack中高可用的对象存储项目。
b）FileSystem。
OpenStackImageService存储虚拟机镜像的默认后端是后端文件系统。
这个简单的后端会把镜像文件写到本地文件系统。
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提供了一个授权系统（swauth）。
运行Account服务的结点与个体账户是不同的概念。
Account服务器是存储系统的部分，必须和Container服务器和Object服务器配置在一起。
b）Authentication和AccessPermissions
你必须通过认证服务来认证，以接收OpenStackObjectStorage连接参数和认证令牌。
令牌必须为所有后面的container/object操作而传递。
典型的，特定语言的API处理认证，令牌传递和HTTPSrequest/response通信。
通过运用X-Container-Read:
accountname和
X-Container-Write:
accountname:
username，你能为用户或者账户对对象执行访问控制。
比如，这个设置就允许
来自accountname账户的的任意用户来读，但是只允许accountname账户里的用户
username来写。
你也能给OpenStackObjectStorage中存储的对象授予公共访问的权限，而
且可以通过Referer头部阻止像热链接这种基于站点的内容盗窃，来限制公共访问。
公共的
container设置被用作访问控制列表之上的默认授权。
比如，X-Container-Read:
referer:
any这个设置，允许任何人能从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来执行。
值得强调的是，所有操作必须包括一个来自你授权系统的有效的授权令牌。
特定语言的API绑定
一些流行语言支持的API绑定，在RackSpace云文件产品中是可用的。
这些绑定在基
础ReSTAPI上提供了一层抽象，允许变成人员直接与container和object模型打交道，而
不是HTTP请求和响应。
这些绑定可免费下载，使用和修改。
它们遵循MIT许可协议。
对
于OpenStackObjectStorage，当前支持的API绑定是：
PHP，Python，Java，C#/.NET和
Ruby。
5.2ObjectStorage如何工作
a）Ring
Ring代表磁盘上存储的实体的名称和它们的物理位置的映射。
accounts,containers,and
objects都有单独的Ring。
其他组件要在这三者之一进行任何操作，他们都需要合相应的Ring进行
升级会员 