|
|
|
OpenStack的架构
1.
OpenStack是什么
OpenStack既是一个社区，也是一个项目和一个开源软件，它提供了一个部署云的操作平台或工具集。其宗旨在于，帮助组织运行为虚拟计算或存储服务的云，为公有云、私有云，也为大云、小云提供可扩展的、灵活的云计算。
OpenStack旗下包含了一组由社区维护的开源项目，他们分别是OpenStackCompute（Nova），OpenStackObject Storage（Swift），以及OpenStackImage Service（Glance）。
OpenStack Compute[1]，为云组织的控制器，它提供一个工具来部署云，包括运行实例、管理网络以及控制用户和其他项目对云的访问（thecloud through users and projects）。它底层的开源项目名称是Nova，其提供的软件能控制IaaS云计算平台，类似于AmazonEC2和Rackspace Cloud Servers。实际上它定义的是，与运行在主机操作系统上潜在的虚拟化机制交互的驱动，暴露基于WebAPI的功能。
OpenStack Object Storage[2]，是一个可扩展的对象存储系统。对象存储支持多种应用，比如复制和存档数据，图像或视频服务，存储次级静态数据，开发数据存储整合的新应用，存储容量难以估计的数据，为Web应用创建基于云的弹性存储。
OpenStack Image Service[1]，是一个虚拟机镜像的存储、查询和检索系统，服务包括的RESTfulAPI允许用户通过HTTP请求查询VM镜像元数据，以及检索实际的镜像。VM镜像有四种配置方式：简单的文件系统，类似OpenStackObject Storage的对象存储系统，直接用Amazon's Simple Storage Solution(S3) 存储，用带有Object Store的S3间接访问S3。
三个项目的基本关系如下图1-1所示：
1-1 OpenStack三个组件的关系
2.
云服务提供商的概念架构
OpenStack能帮我们建立自己的IaaS，提供类似AmazonWeb Service的服务给客户。为实现这一点，我们需要提供几个高级特性：
a)
允许应用拥有者注册云服务，查看运用和计费情况；
b)
允许Developers/DevOps folks创建和存储他们应用的自定义镜像；
c)
允许他们启动、监控和终止实例；
d)
允许Cloud Operator配置和操作基础架构
这四点都直击提供IaaS的核心，现在假设你同意了这四个特性，现在就可以将它们放进如下所示的概念架构2-1中。
2-1 OpenStack 概念架构
在此模型中，作者假设了需要与云交互的四个用户集：developers,devops, owners and operators，并为每类用户划分了他们所需要的功能。该架构采用的是非常普通的分层方法（presentation,logic and resources），它带有两个正交区域。
展示层，组件与用户交互，接受和呈现信息。Webportals为非开发者提供图形界面，为开发者提供API端点。如果是更复杂的结构，负载均衡，控制代理，安全和名称服务也都会在这层。
逻辑层为云提供逻辑（intelligence）和控制功能。这层包括部署（复杂任务的工作流），调度（作业到资源的映射），策略（配额等等），镜像注册imageregistry (实例镜像的元数据)，日志 (事件和计量) 。
假设绝大多数服务提供者已经有客户身份和计费系统。任何云架构都需要整合这些系统。
在任何复杂的环境下，我们都将需要一个management层来操作这个环境。它应该包括一个API访问云管理特性以及一些监控形式（forms）。很可能，监控功能将以整合的形式加入一个已存在的工具中。当前的架构中已经为我们虚拟的服务提供商加入了monitoring和adminAPI，在更完全的架构中，你将见到一系列的支持功能，比如provisioning和 configurationmanagement。
最后，资源层。既然这是一个compute云，我们就需要实际的compute、network 和 storage资源，以供应给我们的客户。该层提供这些服务，无论他们是服务器，网络交换机，NAS（networkattached storage）还是其他的一些资源。
3.
OpenStack Compute架构
3.1
OpenStack Compute逻辑架构
OpenStack Compute逻辑架构中，组件中的绝大多数可分为两种自定义编写的Python守护进程（customwritten python daemons）。
a)
接收和协调API调用的WSGI应用（nova-api,glance-api, etc）
b)
执行部署任务的Worker守护进程（nova-compute,nova-network, nova-schedule, etc.）
然而，逻辑架构中有两个重要的部分，既不是自定义编写，也不是基于Python，它们是消息队列和数据库。二者简化了复杂任务（通过消息传递和信息共享的任务）的异步部署。
逻辑架构图3-1如下所示：
3-1 OpenStack Compute逻辑架构
从图中，我们可以总结出三点：
a)
终端用户（DevOps, Developers 和其他的 OpenStack 组件）通过和nova-api对话来与OpenStackCompute交互。
b)
OpenStack Compute守护进程之间通过队列（行为）和数据库（信息）来交换信息，以执行API请求。
c)
OpenStack Glance基本上是独立的基础架构，OpenStack Compute通过GlanceAPI来和它交互。
其各个组件的情况如下：
a)
nova-api守护进程是OpenStack Compute的中心。它为所有API查询（OpenStackAPI 或 EC2 API）提供端点，初始化绝大多数部署活动（比如运行实例），以及实施一些策略（绝大多数的配额检查）。
b)
nova-compute进程主要是一个创建和终止虚拟机实例的Worker守护进程。其过程相当复杂，但是基本原理很简单：从队列中接收行为，然后在更新数据库的状态时，执行一系列的系统命令执行他们。
c)
nova-volume管理映射到计算机实例的卷的创建、附加和取消。这些卷可以来自很多提供商，比如，ISCSI和AoE。
d)
Nova-network worker守护进程类似于nova-compute和nova-volume。它从队列中接收网络任务，然后执行任务以操控网络，比如创建bridginginterfaces或改变iptables rules。
e)
Queue提供中心hub，为守护进程传递消息。当前用RabbitMQ实现。但是理论上能是pythonampqlib支持的任何AMPQ消息队列。
f)
SQL database存储云基础架构中的绝大多数编译时和运行时状态。这包括了可用的实例类型，在用的实例，可用的网络和项目。理论上，OpenStackCompute能支持SQL-Alchemy支持的任何数据库，但是当前广泛使用的数据库是sqlite3（仅适合测试和开发工作），MySQL和PostgreSQL。
g)
OpenStack Glance，是一个单独的项目，它是一个compute架构中可选的部分，分为三个部分：glance-api,glance-registry and the image store. 其中，glance-api接受API调用，glance-registry负责存储和检索镜像的元数据，实际的ImageBlob存储在Image Store中。ImageStore可以是多种不同的Object Store，包括OpenStackObject Storage (Swift)
h)
最后，user dashboard是另一个可选的项目。OpenStackDashboard提供了一个OpenStack Compute界面来给应用开发者和devopsstaff类似API的功能。当前它是作为Djangoweb Application来实现的。当然，也有其他可用的Web前端。
3.2
概念映射
将逻辑架构映射到概念架构中（如3-2所示），可以看见我们还缺少什么。
3-2 逻辑架构到概念架构的映射
这种覆盖方式并不是唯一的，这里的只是作者的理解。通过覆盖OpenStackCompute 逻辑组件，Glance和Dashboard，来表示功能范围。对于每一个覆盖，都有相应的提供该功能的逻辑组件的名称。
a)
在这种覆盖范围中，最大的差距是logging和billing。此刻，OpenStackCompute没有能协调logging事件、记录日志以及创建/呈现bills的Billing组件。真正的焦点是logging和Billing的整合。这能通过以下方式来补救。比如代码扩充，商业产品或者服务或者自定义日志解析的整合。
b)
Identity也是未来可能要补充的一点。
c)
customer portal也是一个整合点。user dashboard（见运行的实例，启动新的实例）没有提供一个界面，来允许应用拥有者签署服务，跟踪它们的费用以及声明有问题的票据（lodgetrouble tickets）。而且，这很可能对我们设想的服务提供商来说是合适的。
d)
理想的情况是，Admin API会复制我们能通过命令行接口做的所有功能。在带有AdminAPI work的Diablo 发布中会更好。
e)
云监控和操作将是服务提供商关注的重点。好操作方法的关键是好的工具。当前，OpenStack Compute 提供 nova-instancemonitor，它跟踪计算结点使用情况。未来我们还需要三方工具来监控。
f)
Policy是极其重要的方面，但是会与供应商很相关。从quotas到QoS，到隐私控制都在其管辖内。当前图上有部分覆盖，但是这取决于供应商的复杂需求。为准确起见，OpenStackCompute 为实例，浮点IP地址以及元数据提供配额。
g)
当前，OpenStack Compute内的Scheduling对于大的安装来说是相当初步的。调度器是以插件的方式设计的，目前支持chance(随机主机分配)，simple(最少负载)和zone（在一个可用区域里的随机结点。）分布式的调度器和理解异构主机的调度器正在开发之中。
如你所见，OpenStack Compute为我们想象的服务提供商，提供了一个不错的基础，只要服务提供商愿意做一些整合。
3.3
OpenStack Compute系统架构
OpenStack Compute由一些主要组件组成。“Cloudcontroller”包含很多组件，它表示全局状态，以及与其他组件交互。实际上，它提供的是Nova-api服务。它的功能是：为所有API查询提供一个端点，初始化绝大多数的部署活动，以及实施一些策略。API 服务器起cloudcontroller web Service前端的作用。Compute controller 提供compute服务资源，典型包含computeservice，Object Store component可选地提供存储服务。Authmanager提供认证和授权服务，Volume controller为computeservers提供快速和持久的块级别存储。Network controller提供虚拟网络使computeservers彼此交互以及与公网进行交互。Scheduler选择最合适的computecontroller来管理（host）一个实例。
OpenStack Compute建立在无共享、基于消息的架构上。Cloudcontroller通过HTTP与internalobject store交互，通过AMQP和scheduler、networkcontroller、
和volume controller 来进行通信。为了避免在等待接收时阻塞每个组件，OpenStackCompute用异步调用的方式。
为了获得带有一个组件多个备份的无共享属性，OpenStackCompute将所有的云系统状态保持在分布式的数据存储中。对系统状态的更新会写到这个存储中，必要时用质子事务。
对系统状态的请求会从store中读出。在少数情况下，控制器也会短时间缓存读取结果。
3.4
OpenStack Compute物理架构
OpenStack Compute采用无共享、基于消息的架构，非常灵活，我们能安装每个nova-service在单独的服务器上，这意味着安装OpenStack Compute有多种可能的方法。可能多结点部署唯一的联合依赖性，是Dashboard必须被安装在nova-api服务器。几种部署架构如下：
a)
单结点：一台服务器运行所有的nova- services，同时也驱动虚拟实例。这种配置只为尝试OpenStackCompute，或者为了开发目的；
b)
双结点：一个cloud controller 结点运行除nova-compute外的所有nova-services，compute结点运行nova-compute。一台客户计算机很可能需要打包镜像，以及和服务器进行交互，但是并不是必要的。这种配置主要用于概念和开发环境的证明。
c)
多结点：通过简单部署nova-compute在一台额外的服务器以及拷贝nova.conf文件到这个新增的结点，你能在两结点的基础上，添加更多的compute结点，形成多结点部署。在较为复杂的多结点部署中，还能增加一个volumecontroller 和一个network controller作为额外的结点。对于运行多个需要大量处理能力的虚拟机实例，至少是4个结点是最好的。
一个可能的OpenstackCompute多服务器部署（集群中联网的虚拟服务器可能会改变）如下3-3所示：
3-3
OpenStack Compute物理架构一
如果你注意到消息队列中大量的复制引发了性能问题，一种可选的架构是增加更多的Messaging服务器。在这种情形下，除了可以扩展数据库服务器外，还可以增加一台额外的RabbitMQ服务器。部署中可以在任意服务器上运行任意nova-service，只要nova.conf中配置为指向RabbitMQ服务器，并且这些服务器能发送消息到它。
下图3-4是另外一种多结点的部署架构。
3-4 多结点的部署架构二
|
|
窥视卡
雷达卡
发表于 2015-10-11 07:36:06
