中科院云平台架构师，专注于数字化、智能化，技术方向：云、Linux内核、AI、MES/ERP/CRM/OA、物联网、传感器、大数据、ML、微服务。
分类： 云计算
2014-12-03 22:08:29
OpenStack旗下包含了一组由社区维护的开源项目，他们分别是OpenStackCompute(Nova)&OpenStackObjectStorage(Swift)& OpenStackImageService(Glance)。
OpenStackCompute[1]，为云组织的控制器，它提供一个工具来部署云，包括运行实例、管理网络以及控制用户和其他项目对云的访问(thecloudthroughusersandprojects)。它底层的开源项目名称是Nova，其提供的软件能控制IaaS云计算平台，类似于AmazonEC2和RackspaceCloudServers。实际上它定义的是，与运行在主机操作系统上潜在的虚拟化机制交互的驱动，暴露基于WebAPI的功能。
OpenStackObjectStorage[2]，是一个可扩展的对象存储系统。对象存储支持多种应用，比如复制和存档数据，图像或视频服务，存储次级静态数据，开发数据存储整合的新应用，存储容量难以估计的数据，为Web应用创建基于云的弹性存储。
OpenStackImageService[1]，是一个虚拟机镜像的存储、查询和检索系统，服务包括的RESTfulAPI允许用户通过HTTP请求查询VM镜像元数据，以及检索实际的镜像。VM镜像有四种配置方式：简单的文件系统，类似OpenStackObjectStorage的对象存储系统，直接用Amazon'sSimpleStorageSolution(S3)存储，用带有ObjectStore的S3间接访问S3。
三个组件之间的关系：
OpenStack Compute 提供给一个组织云的工具，其中的功能包括运行虚拟机实例, 管理网络以及通过用户和项目来控制对云的访问。OpenStack最基础的开源项目名字称为Nova，它提供的软件可以控制基础设施即服务(IaaS)云计算平台，和AmazonEC2和Rackspace云服务器有一定程度相似。OpenStack Compute 没有包含任何的虚拟化软件，相反它定义和运行在主机操作系统上的虚拟化机制交互的驱动程序，并通过基于Web的程序应用接口(API)来提供功能的使用。
功能分析Compute的组件和及其作用
OpenStack Compute是由几个主要的组件所组成的。
云控制器（cloud controller）包含了很多组件，API服务器(nova-api)，计算服务器(nova-Compute)，网络控制器(nova-network)，调度器(nova-schedule)，卷控制器(nova-volume)，消息队列(queue)，DashBoard。
API 服务器为云控制器扮演着web服务前端的角色。这个云框架的核心是API服务器。API服务器命令和控制hypervisor，存储还有网络，让用户可以实现云计算。API端点是一个基础的HTTP网页服务，通过使用多种API接口（Amazon，Rackspace和相关的模型)来提供认证，授权和基础命令和控制功能，增强了API和多种其他供应商已经存在的资源池的兼容性。
计算控制器（Compute controller）提供了计算服务器资源，其中包含计算服务。Compute控制器控制运行在宿主机上的计算实例。可以通过使用API的方式把命令分发到Compute控制器，进行以下的操作：
l运行实例
l结束实例
l重启实例
l接触卷
l断开卷
l获得控制台输出
l对象存储（Object Store）组件选择性提供存储服务。
l授权管理器（auth manager）提供认证和授权服务。
l卷控制器（volume controller)为Compute服务器提供了快速持久的块级别存储。卷工作处理器和iSCSI存储进行交互，管理基于LVM的实例卷，其中可以进行的操作包括：
l创建卷
l删除卷
l创建计算卷
卷可以在实例间传送，但是一次只能连接到一个实例。
网络控制器（network controller）提供了虚拟网络，使得Compute服务器和其他的Compute服务器以及外网进行交互。
网络控制器管理在宿主机上的网络资源。API服务器通过消息队列分发命令。这些命令之后会被网络控制器处理，特定的操作有：
l分配固定IP地址
l为项目配置VLAN
l为计算节点配置网络
目前为止，Nova只支持Linux网桥网络使得虚拟接口可以通过物理接口链接到外部网络。网络控制器提供了虚拟网络来使得计算服务器之间互相交互以及和公共网络交互。
Nova支持3种类型的网络，实现成3种相对应的“网络管理”类型：
lFlat网络管理模式
lFlat DHCP网络管理模式
lVLAN网络管理模式
这3种类型的网络管理模式可以在一个云系统里面共存。然而，如果没有为一个给定的项目选择它的网络管理类型，就不能在一个给定的Compute安装中配置多于一种类型的网络模式。
Nova有固定IP和浮动IP的概念。固定IP被分发到创建的实例，然后实例持有固定IP直到实例被显式地停机。浮动IP是一些可以和实例动态相连的IP地址。这些地址在任何时刻可以断开连接或者连接到另外的实例。用户可以为他们的项目保留一个浮动的IP地址。
uFlat模式
网络管理员指定一个子网。为虚拟机实例分配的IP地址都是从这个子网内面获取，然后在虚拟机启动时候注入虚拟机镜像。每个实例从有效地址池接收到一个固定的IP地址。网络管理员必须要配置好Linux网桥（名为br100），包括拥有网络的网络控制器还有拥有实例的云控制器。所有的系统实例都是和同一个网桥所相关的，网络管理员需要手动配置相连关系。注意：目前为止配置注入只能够Linux类型的操作系统正常工作，网络配置保存在/etc/network/interfaces路径。
uFlat DHCP模式
启动一个DHCP服务器，把从一个指定的子网中获得的IP地址传递到虚拟机实例，此外网络管理员还需手动配置网桥。为虚拟机实例所分配的IP地址都是从网络管理员指定的子网中所获得的。就像Flat模式一样，所有的实例都在计算节点中和一个网桥相关。除此以外需要一个DHCP服务器运行来配置实例。在这个模式里面，Compute做了更多一些的配置，尝试和以太网设备(默认为eth0)建立网桥。Compute也会运行dusmasq作为DHCP服务器监听这个网桥。之后实例做一次dhcpdiscover操作来接收他们的固定IP。
在两个Flat模式里面，网络节点没有扮演默认网关的角色。实例都被分配了公共的IP地址。Compute节点持有每个项目和实例都会创建的iptables/ebtalbes实体，来抵抗IP/MAC地址欺骗或者是ARP欺骗。
uVLAN网络模式
OpenStack Compute的默认模式。在这个模式里面，Compute为每个项目创建了VLAN和网桥。为了实现多台机器的安装，VLAN网络模式需要一个支持VLAN标签(IEEE 802.1Q)的路由器。每个项目获得一些只能从VLAN内部访问的私有IP地址。为了实现用户获得项目的实例，需要创建一个特殊的VPN实例（代码名为cloudpipe）。Compute为用户生成了证明书和key，使得用户可以访问VPN，同时Compute自动启动VPN。它为每个项目的所有实例提供一个私有网络段，这个私有网络段都是可以通过因特网的VPN访问的。在这个模式里面，每个项目获得它自己的VLAN，Linux网桥还有子网。被网络管理员所指定的子网都会在需要的时候动态地分配给一个项目。DHCP服务器为所有的VLAN所启动，从被分配到项目的子网中获取IP地址并传输到虚拟机实例。所有属于某个项目的实例都会连接到同一个VLAN。OpenStack Compute在必要的时候会创建Linux网桥和VLAN。
调度器（scheduler）选择最合适的Compute控制器来放置一个实例,实现负载均衡。
消息机制 OpenStack Compute 是建立在无共享(shared-nothing)的，基于消息（messaging-based）架构上的。在多服务器上运行所有的主要组件包括Compute 控制器，卷控制器，网络控制器以及对象存储。云控制器通过HTTP协议和内部对象存储通信。但是云控制器和调度器，网络控制器以及卷控制器是通过AMQP协议（AdvancedMessage Queue protocol)，即高级消息队列协议来通信。为了避免在等待响应的时候造成每个组件阻塞，OpenStack Compute使用了异步调用，当响应被接收时候会触发回调。为了取得同样组件的多份拷贝的无共享属性，OpenStack Compute 在分布式数据存储上保存了整个云系统的状态。对系统的更新会被写入到存储里面，必要时会使用原子性的事务来进行这个操作。对状态的请求会从存储里面读出。在有限的例子，读取的结果在很短的时间之内缓存到控制器里面。
一个典型的消息传递事件从API服务器接受来自用户的请求开始。这个API服务器授权这个用户，保证用户是被允许发起相关的命令。在请求中所涉及到的对象的有效性被评估，如果评估有效，为了相关的工作处理器，这请求会被路由到消息引擎。工作处理器在它们各自角色或者主机名的基础上监听这个队列。当监听产生了工作请求，工作处理器接收这个任务并开始执行。完成之后，响应会分发到队列里面。队列会被API服务器接收和转述到发起请求的用户。在整个过程中数据库实体会根据需求被查询，增加或者消除。
基于网页的控制台DashBoard
在OpenStack Compute安装时搭配OpenStack DashBoard andDjango-Nova 项目提供的基于网页的控制台，可以使用DashBoard接口。Django提供了和OpenStackCompute云控制器基于网页的交互。为了创建一个更有鲁棒性的和为产出准备的安装，需要用Apache网页服务器和MySQL/Postgres数据库进行配置。
支持虚拟机热迁移
支持集群安装（使用Puppet）
使用Puppet进行集群自动安装的方法在下面的配置下经过测试：
l多服务器上安装nova-Compute组件
l操作系统：ubuntu10.04或者ubuntu10.10
l多网络模式（Vlan模式，Flat模式）
支持EC2 API
EC2 API 提供了客户迁移，允许用户继续使用熟悉的EC2 API来管理他们的解决方案直到他们学会利用本地的具有高性能的OpenStack API。
OpenStack Object Storage（Swift）是OpenStack开源云计算项目的子项目之一。Swift使用普通的服务器来构建冗余的、可扩展的分布式对象存储集群，存储容量可达PB级。Swift的是用Python开发，前身是Rackspace Cloud Files项目，随着Rackspace加入到OpenStack社区，Racksapce也将Cloud Files的代码贡献给了社区，并逐渐形成现在Swift。Swift最新的发型版本为essex 1.4.6。
功能
Swift提供的服务与AWS S3基本相同，可以用以下用途：
l作为IaaS的存储服务
l与OpenStack Compute对接，为其存储镜像
l文档存储
l存储需要长期保存的数据，例如log
l存储网站的图片，缩略图等
Swift使用RESTful API对外提供服务，目前 1.4.6版本所提供的功能:
lAccount（存储账户）的GET、HEAD
lContainer（存储容器，与S3的bucket相同）的GET、PUT、HEAD、DELETE
lObject（存储对象）的GET、PUT、HEAD、DELETE、DELETE
lAccount、Container、Object的元数据支持
l大文件（无上限，单个无文件最大5G，大于5G的文件在客户端切分上传，并上传manifest文件）、
l访问控制、权限控制
l临时对象存储（过期对象自动删除）
l存储请求速率限制
l临时链接（让任何用户访问对象，不需要使用Token）
l表单提交（直接从HTML表单上传文件到Swift存储，依赖与临时链接）
l静态WEB站点（用Swift作为静态站点的WEB服务器）
架构
图为Swift的基本架构。
在介绍Swift的架构之前，先介绍一下OpenStack的设计原理：
1、Scalabilityand elasticity are our main goals
（可扩展性和伸缩性是我们的主要目标）
2、 Any featurethat limits our main goals must be optional
（任何影响到可扩展性和伸缩性的功能都必须是可选的）
3、Everythingshould be asynchronous，If you can’t do something asynchronously, see #2
（所有的环节必须是异步的，如果不能异步实现，参考第二条设计原理）
4、All requiredcomponents must be horizontally scalable
（所有的基础组件必须能横向扩展）
5、Always useshared nothing architecture (SN) or sharding，If you can’t Share nothing/shard, see #2
（始终使用无共享的架构，如果不能实现，参见第二条）
6、Distributeeverything，especiallylogic. Move logic to where state naturally exists.（所有的都是分布式的，尤其是逻辑。把逻辑放在状态应该存在的地方）
7、Accepteventual consistency and use it where it is appropriate.
（接受最终一致性，并在适合的条件下使用）
8、Testeverything（充足的测试）
依赖组件
Memcached，分布式缓存系统，在swift中主要被用于token和account信息，container信息的存储
Sqlite，轻量级数据库引擎，在swift中主要被用于管理account和container数据库
rsync，远程同步工具，用于storagenode之间的数据同步
XFS文件系统
WSGI，Python Web服务网关接口，通过paste.deploy工具包管理swift各服务进程、中间件的处理流程
Eventlet，Python搞并发网络编程库，swift所有的服务器进程均依赖于该库
主要组件
Ring文件
在基本架构图中，我并没有画出ring文件，但是它却是整个Swift中最重要的组件。ring文件是由一致性哈希算法生成，它的主要作用是存储名字到位置的映射。
ring文件分为三类，分别是：account.ring，container.ring，object.ring。
对于account的请求，就能通过account_name查询account.ring得到{‘/account_name’ : account_db_position}的映射，从而知道account数据库文件在集群的位置；
对于container的请求，通过account_name和container_name查询container.ring文件，得到{‘/account_name/container_name’ : container_db_position}的映射；
对于object的请求，通过account_name，container_name，object_name查询object.ring文件，得到{‘/account_name/container_name/object_name’ : object_position}的映射；
Ring文件作为一个静态文件存储在每个节点的/etc/swift目录下，被用于各节点之间的位置查询，使得swift的内部网络是一个P2P网络，不依赖某几个节点进行位置查询，避免了单点瓶颈。
生成ring文件的一致性哈希算法不但为数据的冗余性，分区容忍性提供了保证，也为整体架构上实现性能、容量的横向扩展奠定了基础。
Ring的详细构造过程将在下一节介绍。
proxy-server
proxy-server是proxy node中唯一运行的服务进程，也是swift集群的endpoint，向用户提供RESTful API。
对于用户的请求，proxy-server会根据配置文件的配置，将请求交给各个中间件进行处理，其中最重要的就是Auth中间件（认证），在处理完成后会根据请求路径将请求转发给相应的storagenode中的account-server。container-server或object-server进程处理。
swift集群的流入数据和流出数据都需要经过proxy-server，proxy-server不会对数据进行缓存。
auth-server
验证服务进程，为用户生成token和验证每个请求的token及token的权限。swift的验证服务是作为一个中间件被proxy-server使用，是可选的，可以自己开发，也可以使用OpenStackKeystone。Keystone是官方开发的验证服务，使用Keystone可以无缝的与其它OpenStack项目整合。
account-server
account-server是storage node中负责处理对account的GET、HEAD、PUT、DELETE、RELICATION请求的服务进程，account-server使用sqlite的数据库文件保存account的相关信息。
container-server
container-server是storage node中负责处理对container的GET、HEAD、PUT、DELETE、RELICATION请求的服务进程，container-server使用sqlite的数据库文件保存container的相关信息。
object-server
object-server是storage node中负责处理对object的GET、HEAD、PUT、PSOT、DELETE、RELICATION请求的服务进程，object-server直接操作object，并利用XFS文件系统的xattr包存object的元数据。
account-auditor、container-auditor、object-auditor
这三个进程运行在storage node中，分别检测account的db文件，container的db文件，object是否损坏，如果损坏，将会向存储有其它副本的storage node请求副本，替换损坏的。
account-replicator、container-replicator、object-replicator
这三个进程运行在storage node中，分别负责account的db文件，container的db文件，object在集群中副本的同步。
例如，一个object在swift集群中通常被存储在3个不同的storagenode中，对于一个PUT/account/container/object的请求，proxy-server会根据 /account/container/object查询ring文件，得到该object应该存储的节点列表（长度为3），proxy-server会将请求转发到这三个节点。如果只有两个节点写入成功，就认为这次PUT操作成功。写入失败的节点在一段时间后将会得到写入成功的节点object-replicator进程推送过来的数据。
container-updater、account-updater
这两个进程运行在storage node中，负责container数据库和account数据库的异步更新。使用异步更新的原因：在请求来量大时，container-server和account-server不能实时处理对数据库更新的请求，这些请求将被本地化到队列中，由updater进程进行异步更新。
总结
经过对Swift原理、代码的学习研究以及一系列地测试，我认为Swift简单、冗余、可扩展的架构保证了它能作为IaaS的一个基础服务。
OpenStack Compute (Nova)，为云组织的控制器，它提供一个工具来部署云，包括运行实例、管理网络以及控制用户等等。
OpenStack Object Storage (Swift)，是一个可扩展的对象存储系统。
OpenStack Image Service (Glance)，是一个虚拟机镜像的存储、查询和检索系统。
对于Nova，我们先来看一张图：
总的来说，nova的各个组件是以数据库和队列为中心进行通信的，下面对其中的几个组件做一个简单的介绍：
Queue，也就是消息队列，它就像是网络上的一个hub，nova各个组件之间的通信几乎都是靠它进行的，当前的Queue是用RabbitMQ实现的，它和database一起为各个守护进程之间传递消息。
database存储云基础架构中的绝大多数状态。这包括了可用的实例类型，在用的实例，可用的网络和项目。当前广泛使用的数据库是sqlite3(仅适合测试和开发工作)、MySQL和PostgreSQL。
nova-compute负责决定创造虚拟机和撤销虚拟机，通过运行一系列系统命令（例如发起一个KVM实例，）并把这些状态更新到nova-database中去，其过程相当复杂，但是基本原理很简单。
nova-schedule负责从queue里取得虚拟机请求并决定把虚拟机分配到哪个服务器上去。schedule的算法可以自己定义，目前有Simple （最少加载主机）,chancd(随机主机分配) ，zone(可用区域内的随机节点)等算法。
nova-volume负责记录每一个计算实例，相当于一个计算请求吧，并负责创建，分配或撤销持久层容器(Amazon的，iSCSI，AoE等等)给这些compute instances。
nova -netwok负责处理队列里的网络任务。
nova-api守护进程是OpenStack Compute的中心。它为所有API查询提供一个入口，并且同时支持OpenStack API 和 Amazon EC2 API。
为了看看nova是如何工作的，我们可以以启动一个实例为例来进行说明，因为启动一个新的instance涉及到很多openstack nova里面的组件共同协作。
其中：
API：处理客户端的请求，并且转发到 Queue和Database中。
Scheduler：选择一个host去执行命令
nova-compute：启动和停止实例，附加和删除卷等操作
nova-network：管理网络资源，分配固定IP。
接下来就是真正的过程了，先从API开始：
API
例如我们输入一个命令：euca-run-instances-k test -t m1.tiny ami-tiny 它会执行以下操作：
查看这种类型的instance是否达到最大值
给scheduler发送一个消息（实际上是发送到Queue中）去运行这个实例。
Schedule
调度器接收到了消息队列Queue中API发来的消息，然后根据事先设定好的调度规则，选择好一个host，之后，这个instance会在这个host上创建。
Compute
真正去创建一个instance的操作是由Compute完成的，而这个过程中compute组件与Glance密不可分，如图所示：
接下来，需要了解一下Glance在OpenStack里面所起的作用了。
我觉得看图是最直观的了，所以要弄明白Glance在整个OpenStack项目中的角色，就再来看一张图。
可以看出，通过Glance，Opentack的3个模块被链接成了一个整体，Glance为Nova提供镜像的查找操作，而Swift又为Glance提供实际的存储服务，Swift可以看作是Glacne存储接口的一个具体实现。
以我个人的理解来看，Glance的功能类似虚拟文件系统VFS，Glance提供给用户，或者说是Nova，一个统一的操作接口，而至于具体存储的是在Swift上还是在Amazon S3上，使用者不必关心。
知道了Glance所起到的作用之后，再来看compute调用Glance的那张图，详细会更好理解。
glance-api主要是用来接受各种api调用请求，并提供相应的操作。
glacne-registry用来和MySQL数据库进行交互，存储或者获取镜像的元数据，注意，刚才在Swift中提到，Swift在自己的Storage Server中是不保存元数据的，这儿的元数据是指保存在MySQL数据库中的关于镜像的一些信息，这个元数据是属于Glance的。
image store也就是图中的”Swift of S3″，是一个存储接口，通过接口，glance可以获取镜像，image不仅仅支持OpenStack自己的Swift格式的镜像，也同时支持Amazon S3等其他的镜像。
以上就是我对OpenStack三大组件的一些理解，这些内容有的直接来源于网络，有的是我看完资料后的总结，由于看了很多资料，而且没有保存链接，没法一一列举了。
部分内容转自：http://blog.nlogn.cn/openstack-nova-and-glance
平台搭建参照：http://my.oschina.net/xxbAndy/blog/297415
