openstack基础架构

申明：本文主要观点引用自cloudman：http://blog.51cto.com/cloudman，感谢cloudman的分享。

OpenStack主要是通过Nova，Neutron，Glance，Cinder，Keystone，Horizon等模块对计算、网络和存储资源进行管理的.

Nova：管理VM的生命周期，是OpenStack中最核心的服务。

Neutron：为OpenStack提供网络连接服务，为VM提供虚拟网络和物理网络连接。

Glance：管理VM的启动镜像，Nova创建VM时将使用Glance提供的镜像。

Cinder：为VM提供块存储服务。

Glance可以将镜像存放在Swift中；Cinder也可以将Volume备份到Swift中。

Keystone：为OpenStack的各种服务提供认证和权限管理服务。

Horizon：为OpenStack用户提供一个Web的自服务Portal。

OpenStack本身是一个分布式系统，不但各个服务可以分布部署，服务中的组件也可以分布部署。这种分布式特性让OpenStack具备极大的灵活性、伸缩性和高可用性。控制节点（Controller Node）管理OpenStack，其上运行的服务有Keystone、Glance、Horizon以及Nova和Neutron中管理相关的组件。控制节点也运行支持OpenStack的服务，例如SQL数据库（通常是MySQL）、消息队列（通常是RabbitMQ）和网络时间服务NTP。网络节点（Network Node）其上运行的服务为Neutron。为OpenStack提供L2和L3网络。包括虚拟机网络、DHCP、路由、NAT等。 存储节点（Storage Node）提供块存储（Cinder）或对象存储（Swift）服务。计算节点（Compute Node）其上运行Hypervisor（默认使用KVM）。同时运行Neutron服务的agent，为虚拟机提供网络支持。

Keystone

Keystone主要负责：1）管理用户及其权限；2）维护 OpenStack Services 的 Endpoint；3）Authentication（认证）和 Authorization（鉴权）。

Keystone中有如下基本概念：

User指代任何使用OpenStack的实体，可以是真正的用户，其他系统或者服务；

Credentials是User用来证明自己身份的信息，可以是：1.用户名/密码；2.Token；3.API Key；4.其他高级方式；

Authentication是Keystone验证User身份的过程，User访问OpenStack时向Keystone提交用户名和密码形式的Credentials，Keystone验证通过后会给User签发一个Token作为后续访问的Credential；

Token是由数字和字母组成的字符串，User成功Authentication后由Keystone分配给User。Token用做访问Service的Credential，Service会通过Keystone验证Token的有效性，Token的有效期默认是24小时；

Project用于将OpenStack的资源（计算、存储和网络）进行分组和隔离，资源的所有权是属于Project的，每个User（包括admin）必须挂在Project里才能访问该Project的资源，一个User可以属于多个Project；

Endpoint是一个网络上可访问的地址，通常是一个URL。Service通过Endpoint暴露自己的API。Keystone负责管理和维护每个Service的Endpoint。

安全包含两部分：Authentication（认证）和Authorization（鉴权）Authentication解决的是“你是谁？”的问题Authorization解决的是“你能干什么？”的问题，Keystone是借助Role来实现Authorization的。

客户想查询某种数据，首先需要向Keystone认证，认证通过后，再获取该用户的权限，然后获取对应服务的Endpoint，通过该Endpoint访问服务，发向服务的请求，服务会先向Keystone进行身份验证，然后查看用户是否有使用这项服务的权限，校验完成，返回结果。

下面是创建一个虚机的流程：

可以看出来keystone在各个组件间扮演着一个中间人的作用，每个服务于服务间使用或者某个用户与服务间的使用，都要先到keystone这里来认证。

Glance

Glance是一种提供发现，注册，和下载的镜像服务，也是一个提供虚拟机镜像的集中式仓库。通过Glance的Restful API，可以查询镜像元数据下载镜像，虚拟机的镜像可以很方便的存储在各种地方。它通过提供一个虚拟磁盘映像目录和存储库，为Nova的虚拟机提供镜像服务。

Glance有以下几个组件:

glance-api：glance-api是系统后台运行的服务进程。对外提供RESTAPI，响应image查询、获取和存储的调用。glance-api不会真正处理请求。如果是与imagemetadata（元数据）相关的操作，glance-api会把请求转发给glance-registry；如果是与image自身存取相关的操作，glance-api会把请求转发给该image的store backend。

glance-registry：glance-registry是系统后台运行的服务进程。负责处理和存取image的metadata，例如image的大小和类型。

Database：存储镜像元数据，Image的metadata会保持到database中，默认是MySQL。

Store backend：Glance自己并不存储image。真正的image是存放在backend中的。

Nova

Compute Service Nova 是OpenStack最核心的服务，负责维护和管理云环境的计算资源。OpenStack作为IaaS的云操作系统，虚拟机生命周期管理也就是通过Nova来实现的。Nova处于Openstak架构的中心，其他组件都为Nova提供支持：Glance为VM提供image；Cinder和Swift分别为VM提供块存储和对象存储；Neutron为VM提供网络连接。

1、组件

Nova的架构比较复杂，包含很多组件：

nova-api：接收和响应客户的API调用；

nova-scheduler：虚机调度服务，负责决定在哪个计算节点上运行虚机；

nova-compute：管理虚机的核心服务，通过调用Hypervisor API实现虚机生命周期管理；

nova-conductor：nova-compute经常需要更新数据库，比如更新虚机的状态，出于安全性和伸缩性的考虑，nova-compute并不会直接访问数据库，而是将这个任务委托给nova-conductor；

nova-console：用户可以通过多种方式访问虚机的控制台：nova-novncproxy，基于Web浏览器的VNC访问、nova-spicehtml5proxy，基于HTML5浏览器的SPICE访问、nova-xvpnvncproxy，基于Java客户端的VNC访问；

nova-consoleauth：负责对访问虚机控制台请求提供Token认证；

nova-cert：提供x509证书支持；

Database:Nova有一些数据要存放到数据库中，一般使用MySQL，数据库安装在控制节点上。

Message Queue：Nova包含众多的子服务，这些子服务之间需要相互协调和通信，为解耦各个子服务，Nova通过Message Queue作为子服务的信息中转站，OpenStack默认是用RabbitMQ作为Message Queue。

OpenStack是一个分布式系统，可以部署到若干节点上，对于Nova，这些服务会部署在两类节点上：计算节点和控制节点，计算节点上安装了Hypervisor，上面运行虚拟机，所以nova-compute需要放在计算节点上，其他子服务放在控制节点上的，控制节点上也可以运行了nova-compute，也就意味着控制节点也可以作为一个计算节点。

1、nova-scheduler

Filter scheduler是nova-scheduler默认的调度器，先通过过滤器（filter）选择满足条件的计算节点（运行nova-compute），然后通过权重计算（weighting）选择在最优（权重值最大）的计算节点上创建Instance，同时openstack允许使用第三方scheduler。

Filter：

Scheduler可以使用多个filter依次进行过滤，过滤之后的节点再通过计算权重选出最适合的节点，常用的filter有：

RetryFilter：刷掉之前已经调度过的节点；

AvailabilityZoneFilter：可用域过滤，过滤掉不属于指定AvailabilityZone的计算节点；

RamFilter：将不能满足 flavor 内存需求的计算节点过滤掉；

DiskFilter：将不能满足 flavor 磁盘需求的计算节点过滤掉；

CoreFilter：将不能满足 flavor vCPU 需求的计算节点过滤掉；

ComputeFilter：保证只有 nova-compute 服务正常工作的计算节点才能够被 nova-scheduler调度；

ServerGroupAntiAffinityFilter：尽量将 Instance 分散部署到不同的节点上；

ServerGroupAffinityFilter：尽量将 instance 部署到同一个计算节点上；

Filter可以在Nova.conf配置文件中配置。

Weight：

经过前面一堆filter的过滤，nova-scheduler选出了能够部署instance的计算节点，Scheduler会对每个计算节点打分，得分最高的获胜，目前nova-scheduler的默认实现是根据计算节点空闲的内存量计算权重值：空闲内存越多，权重越大。

2、nova-compute

nova-compute在计算节点上运行，负责管理节点上的instance；OpenStack对instance的操作，最后都是交给nova-compute来完成的；nova-compute与Hypervisor一起实现OpenStack对instance生命周期的管理。

nova-compute通过Driver架构支持多种Hypervisor，nova-compute为这些Hypervisor定义了统一的接口，Hypervisor只需要实现这些接口，就可以Driver的形式即插即用到OpenStack系统中，单个计算节点上只会运行一种 Hypervisor。

nova-compute的功能可以分为两类：定时向OpenStack报告计算节点的状态；实现instance生命周期的管理。每隔一段时间，nova-compute就会报告当前计算节点的资源使用情况和nova-compute服务状态，nova-compute可以通过Hypervisor的driver拿到计算节点的资源信息。

生命周期的管理包括instance的launch、shutdown、reboot、suspend、resume、terminate、resize、migration、snapshot等，以launch为例，nova-compute首先会根据指定的flavor依次为instance分配内存、磁盘空间、vCPU和网络资源，资源准备好之后，nova-compute会为instance创建镜像文件，首先将image从glance下载到计算节点，通过qemu-img转换成raw格式，然后将其作为backing file通过qemu-img命令创建instance的镜像文件，镜像文件指的是instance启动盘所对应的文件，image不会变，而镜像文件会发生变化，然后创建instance的XML定义文件，虚拟网络设备，最后启动实例。

从组件协作方面，用户向API（nova-api）发送请求：“帮我创建一个Instance”；API对请求做一些必要处理后，向Messaging（RabbitMQ）发送了一条消息：“让Scheduler创建一个Instance”；Scheduler（nova-scheduler）从Messaging获取到API发给它的消息，然后执行调度算法，从若干计算节点中选出节点A；Scheduler向Messaging发送了一条消息：“在计算节点A上创建这个Instance”；计算节点A的Compute（nova-compute）从Messaging中获取到Scheduler发给它的消息，然后通过本节点的Hypervisor Driver创建Instance；在Instance创建的过程中，Compute如果需要查询或更新数据库信息，会通过Messaging向Conductor（nova-conductor）发送消息，Conductor负责数据库访问。

其他几种生命周期操作需要申请资源的就会走scheduler，否则不需要经过scheduler，直接交由nova-compute处理。

其他几种生命周期操作：soft reboot只是重启操作系统，不需要调度；hard reboot是重启instance，相当于关机之后再开机，不需要调度；终止实例是删除指定的实例，镜像文件，网络资源等，不需要调度；Pause是将实例状态保存到内存，短时间停止实例，不需要调度；Resume是从内存中读回instance的状态，然后继续运行instance，不需要调度；Suspend操作将instance的状态保存到宿主机的磁盘上，不需要调度；Snapshot，是对instance的镜像文件（系统盘）进行全量备份，生成一个类型为snapshot的image，然后将其保存到Glance上，不需要调度；Rebuild会用snapshot替换instance当前的镜像文件，同时保持instance的其他诸如网络，资源分配属性不变，不需要调度；Shelve会将instance作为image保存到Glance中，然后在宿主机上删除该instance，不需要调度；unshelve的过程其实就是通过该image launch一个新的instance，nova-scheduler也会选择合适的计算节点来创建该instance，需要调度；migrate会将原节点的实例停止，镜像文件上传到目的节点，然后在新节点启动instance，需要调度；Resize和migrate类似，只是在启动新instance时采用不同的flavor，需要调度；Live Migrate先将instance的数据迁移过来，主要包括镜像文件、虚拟网络等资源，源节点暂定instance，目标节点Resume instance，再将原节instance删除，Instance在Live Migrate的整个过程中不会停机，需要调度。

Cinder

操作系统获得存储空间的两种方式，一为通过某种协议（SAC,SCCI,SAN,ISCSI等）挂接裸硬盘，然后分区、格式化，创建文件系统，这叫做块存储；二是通过NFS、CIFS等协议mount远程文件系统。

Openstack的Cinder提供Block Storage Service来管理volume的生命周期，主要包括：1）提供RESTAPI来管理volume。2）提供scheduler调用volume。3）通过driver架构支持多种backend，如LVM,NFS,Ceph等。

Cinder包含几个组件：1）cinder-api，接受用户的api请求，调用cinder volume。2）cinder-volume，管理volume的生命周期。3）cinder-scheduler，通过调度算法选择最合适的存储节点创建volume。4）volume provider，存储设备，为volume提供物理存储空间。5）RabbitMQ，Cinder各个子服务通过消息队列实现进程间通信和相互协作。

下面通过一次创建volume操作来说明cinder工作流程：

1、向cinder-api发送创建volume请求。

2、cinder-api向RabbitMQ发送了一条消息。

3、cinder-scheduler从RabbitMQ获取到消息，然后执行调度算法，从若干计存储点中选出节点。

4、cinder-scheduler向RabbitMQ发送让存储节点创建volume消息。

5、存储节点的cinder-volume从RabbitMQ中获取到消息，通过driver在volume provider上创建volume。

Neutron

Neutron管理的网络资源包括Network，subnet和port；network包含local, flat, VLAN, VxLAN和GRE；subnet是属于某个network的ip段；port可以看做虚拟交换机上的一个端口。

Neutron 构成：

Neutron Server：对外提供网络API，接收请求，并调用Plugin处理请求。

Plugin：处理Neutron Server发来的请求，维护OpenStack逻辑网络的状态，并调用Agent处理请求。

Agent：处理Plugin的请求，负责在network provider上真正实现各种网络功能。

network provider：提供网络服务的虚拟或物理网络设备，例如Linux Bridge，Open vSwitch或者其他支持Neutron的物理交换机。

Queue：Neutron Server，Plugin和agent之间通过Messaging Queue通信和调用。

Neutron Server：

Neutron Server主要做两件事：提供 API 服务和运行 Plugin（Core Plugin，Service Plugin）下面是其基本分层结构：

ML2 Core Plugin：

ML2作为新一代的core plugin，提供了一个框架，允许在OpenStack网络中同时使用多种Layer 2网络技术，不同的节点可以使用不同的网络实现机制，解决了传统的core plugin与core plugin agent一一对应的问题以及编写传统的core plugin需要编写大量重复和类似的数据库访问的代码的问题。

ML2对二层网络进行抽象和建模，引入了type driver和mechansim driver。每一种网络类型都有一个对应的ML2 type driver，type driver负责维护网络类型的状态，执行验证，创建网络等；每一种网络机制也都有一个对应的ML2 mechansim driver。 mechanism driver负责获取由type driver维护的网络状态，并确保在相应的网络设备（物理或虚拟）上正确实现。

Service Plugin：

Service Plugin 及其 Agent 提供更丰富的扩展功能，包括路由，load balance，firewall等

openstack网络类型：

local network：

不会与宿主机的任何物理网卡相连，也不关联任何的VLAN ID，用于内部测试，local网络的流量只能局限在本节点之内。

flat network：

是不带tag的网络，要求宿主机的物理网卡直接与linux bridge连接，所以每个flat network都会独占一个物理网卡。

vlan network：

带tag的网络，在物理网卡上创建了带vlanid的vlan interface，连接到lingux bridge，instance通过该vlan interface发送到的数据包就会打上该接口的tag，每个vlan network有自己的bridge，从而也就实现了基于vlan的隔离。

Vxlan network：

VXLAN全称Virtual eXtensible Local Area Network，由于VXLAN的数据包在整个转发过程中保持了内部数据的完整，因此VXLAN的数据平面是一个基于隧道的数据平面。它是一种将二层建立在三层上的网络，通过将二层数据封装到 UDP 的方式来扩展数据中心的二层网段数量。VXLAN的ID（VNI或者VNID）用24-bit标记，支持16777216个二层网段。

VXLAN 定义了一个MAC-in-UDP的封装格式。 在原始的Layer 2网络包前加上VXLAN header，然后放到UDP和IP包中。 通过MAC-in-UDP封装，VXLAN 能够在Layer 3网络上建立起了一条Layer 2的隧道。

VXLAN使用VXLAN tunnel endpoint(VTEP)设备处理VXLAN的封装和解封。 每个VTEP有一个IP interface，配置了一个IP地址。VTEP使用该IP封装Layer 2 frame，并通过该IP interface传输和接收封装后的VXLAN数据包。

VXLAN在VTEP间建立隧道，通过Layer 3网络传输封装后的Layer 2数据。

这里发现数据时以UDP的形式发送的，那么TCP怎么办？这里其实是UDP封装的TCP连接，UDP和TCP将做为两个独立的协议栈各自工作，相互之间没有交互。虚机始终认为自己是在用TCP交互。

为了实现VLAN和VXLAN之间互通，VXLAN定义了VXLAN网关。VXLAN网关上同时存在两种类型的端口：VXLAN端口和普通端口。当收到从VXLAN网络到普通网络的数据时，VXLAN网关去掉外层包头，根据内层的原始帧头转发到普通端口上；当有数据从普通网络进入到VXLAN网络时，VXLAN网关负责打上外层包头，并根据原始VLAN ID对应到一个VNI，同时去掉内层包头的VLAN ID信息。

在openstack上基本结构与vlan类似：

router：

物理router或者虚拟router为我们提供跨subnet互联互通功能，在router上分别配子网的网关，就可以完成数据的路由。opestack的l3 agent为每个router创建了一个namespace，通过veth pair与TAP相连，然后将Gateway IP配置在位于namespace里面的veth interface上，每个namespace拥有自己的路由表，这样既可以隔离不同租户的网络，从而支持网络重叠，又可以完成路由。

当租户网络连接到router，通常将router作为默认网关。

当router接收到instance的数据包，并将其转发到外网时:

1. router会修改包的源地址为自己的外网地址，这样确保数据包转发到外网，并能够从外网返回。

2. router修改返回的数据包，并转发给真正的instance。

这个行为被称作Source NAT。

如果需要从外网直接访问instance，则可以利用floating IP。

1. floating IP提供静态NAT功能，建立外网IP与instance租户网络IP的一对一映射。

2. floating IP是配置在router提供网关的外网interface上的，而非instance中。

3. router会根据通信的方向修改数据包的源或者目的地址。

Open vSwitch：

Open vSwitch的网络设备有：br-ex，连接外部（external）网络的网桥；br-int，集成（integration）网桥，所有instance的虚拟网卡和其他虚拟网络设备都将连接到该网桥；br-tun，隧道（tunnel）网桥，基于隧道技术的VxLAN和GRE网络将使用该网桥进行通信。

当我们创建一个子网，Neutron会为该子网启用一个dhcp接口，而每创建一个实例，都会创建一个linux bridge，一端连接实例的tap设备，另一端通过一个veth pair连接到br-int，而每一个子网都有一个tag，因为所有网络都是连接到br-int的，所以该tag是隔离不同网络的标识，local的网络，在ovs里表现如下：

br-int是一个ovs网桥，但是我们可以连接网卡a，b，c。。。，上面讲的所有instance的虚拟网卡和其他虚拟网络设备都将连接到br-int，那该如何区分呢，这就需要我们创建另一个ovs网桥，该网桥通过patch port连接在一起，flat的网络在ovs里表现如下：

那ovs如何设置vlan的网络呢，上面提到一个tag，这个tag就是linux的vlan id，但是在ovs这里，这个只是内部id，vlan的网络不采用这种方式隔离。OVS通过flow rule（流规则）来指定如何对进出br-int的数据进行转发，进而实现vlan之间的隔离。当数据进出br-int时，flow rule可以修改、添加或者剥掉数据包的VLAN tag，Neutron负责创建这些flow rule并将它们配置到 br-int，br-eth1等ovs网桥上。比如：

priority=4,in_port=2,dl_vlan=1 actions=mod_vlan_vid:100,NORMAL

priority=4,in_port=2,dl_vlan=5 actions=mod_vlan_vid:101,NORMAL

一般设置在创建的网桥上，就是把内部tag 1转换为vlan 100，内部tag 5转换为vlan 101，而：

priority=3,inport=1,dl_vlan=100 actions=mod_vlan_vid:1,NORMAL

priority=3,inport=1,dl_vlan=101 actions=mod_vlan_vid:5,NORMAL

一般设置在br-int上，就是将vlan 100转为内部tag 1，将vlan 101转为内部tag 5。

如果需要访问外网，则需要将br-ex通过patch port连接到br-int，如果为虚机分配外网ip，则配置方式和之前一样，指定或dhcp一个ip地址，然后通过br-ex发出去；如果不为虚机分配外网ip，则需要通过router转发到br-ex：

上面提到vxlan通过br-tun进行通信，需要把br-tun连接到br-int上，创建一个vxlan的网络，会在br-tun上创建一个特殊的port用来通信，指定了vxlan隧道本端VTEP和远端VTEP的地址，所以每两个VTEP就会生成一个port，vxlan的数据通信都是从这两个port发出。

ovs的vxlan通信也是采用流规则实现的，br-tun上定义的规则的大致转发如下：

table 0将br-int进来的包转发给table 2处理，将其他VTEP发来的数据转发给table 4处理。

table 2将br-int进来的单播包转发给table 20处理，多播包转发给table 22处理。

table 4定义多条vxlan id和内部tag的映射关系，将其他VTEP发来的数据里的vxlan id转换为内部的tag，然后转发给table 10。

table 10将包转发给br-int，并往table 20添加一些返程信息。

table 20依赖table 10的学习，学习内容包括vxlan id和内部tag的映射关系，目标的mac地址等，收到发往该mac的消息；或对应tag的消息，则会根据这个学习结果完成id转换和转发，不再发往table 22。如果没有对应规则，则转发到table 22。

table 22将内部tag转换为vxlanid并发出。