openstack的放弃之路

一 openstack由来

openstack最早由美国国家航空航天局NASA研发的Nova和Rackspace研发的swift组成。后来以apache许可证授权,旨在为公共及私有云平台建设。openstack主要用来为企业内部实现类似于Amazon EC2和S3的云基础架构服务（Iaas）.每6个月更新一次，基本与ubuntu同步，命名是以A-Z作为首字母来的。

二 openstack项目与组件（服务名是项目名的别名）

核心项目3个

1.控制台

服务名：Dashboard

项目名：Horizon

功能：web方式管理云平台，建云主机，分配网络，配安全组，加云盘

2.计算

服务名：计算

项目名：Nova

功能：负责响应虚拟机创建请求、调度、销毁云主机

3.网络

服务名：网络

项目名：Neutron

功能：实现SDN（软件定义网络），提供一整套API,用户可以基于该API实现自己定义专属网络，不同厂商可以基于此API提供自己的产品实现

存储项目2个

1.对象存储

服务名：对象存储

项目名：Swift

功能：REST风格的接口和扁平的数据组织结构。RESTFUL HTTP API来保存和访问任意非结构化数据，ring环的方式实现数据自动复制和高度可以扩展架构，保证数据的高度容错和可靠性

2.块存储

服务名：块存储

项目名：Cinder

功能：提供持久化块存储，即为云主机提供附加云盘。

共享服务项目3个

1.认证服务

服务名：认证服务

项目名：Keystone

功能：为访问openstack各组件提供认证和授权功能，认证通过后，提供一个服务列表（存放你有权访问的服务），可以通过该列表访问各个组件。

2.镜像服务

服务名：镜像服务

项目名：Glance

功能：为云主机安装操作系统提供不同的镜像选择

3.计费服务

服务名：计费服务

项目名：Ceilometer

功能：收集云平台资源使用数据，用来计费或者性能监控

高层服务项目1个

1.编排服务

服务名：编排服务

项目名：Heat

功能：自动化部署应用，自动化管理应用的整个生命周期.主要用于Paas

三 openstack各组件详解及运行流程

各组件逻辑关系图：

openstack新建云主机流程图:

虚拟机启动过程如下：

界面或命令行通过RESTful API向keystone获取认证信息。

keystone通过用户请求认证信息，并生成auth-token返回给对应的认证请求。

界面或命令行通过RESTful API向nova-api发送一个boot instance的请求（携带auth-token）。

nova-api接受请求后向keystone发送认证请求，查看token是否为有效用户和token。

keystone验证token是否有效，如有效则返回有效的认证和对应的角色（注：有些操作需要有角色权限才能操作）。

通过认证后nova-api和数据库通讯。

初始化新建虚拟机的数据库记录。

nova-api通过rpc.call向nova-scheduler请求是否有创建虚拟机的资源(Host ID)。

nova-scheduler进程侦听消息队列，获取nova-api的请求。

nova-scheduler通过查询nova数据库中计算资源的情况，并通过调度算法计算符合虚拟机创建需要的主机。

对于有符合虚拟机创建的主机，nova-scheduler更新数据库中虚拟机对应的物理主机信息。

nova-scheduler通过rpc.cast向nova-compute发送对应的创建虚拟机请求的消息。

nova-compute会从对应的消息队列中获取创建虚拟机请求的消息。

nova-compute通过rpc.call向nova-conductor请求获取虚拟机消息。（Flavor）

nova-conductor从消息队队列中拿到nova-compute请求消息。

nova-conductor根据消息查询虚拟机对应的信息。

nova-conductor从数据库中获得虚拟机对应信息。

nova-conductor把虚拟机信息通过消息的方式发送到消息队列中。

nova-compute从对应的消息队列中获取虚拟机信息消息。

nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求glance-api获取创建虚拟机所需要镜像。

glance-api向keystone认证token是否有效，并返回验证结果。

token验证通过，nova-compute获得虚拟机镜像信息(URL)。

nova-compute通过keystone的RESTfull API拿到认证k的token，并通过HTTP请求neutron-server获取创建虚拟机所需要的网络信息。

neutron-server向keystone认证token是否有效，并返回验证结果。

token验证通过，nova-compute获得虚拟机网络信息。

nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求cinder-api获取创建虚拟机所需要的持久化存储信息。

cinder-api向keystone认证token是否有效，并返回验证结果。

token验证通过，nova-compute获得虚拟机持久化存储信息。

nova-compute根据instance的信息调用配置的虚拟化驱动来创建虚拟机。

下面我们就围绕上图流程展开。

1.keystone

User：指使用Openstack service的用户，可以是人、服务、系统，但凡使用了Openstack service的对象都可以称为User。

Project(Tenant)：可以理解为一个人、或服务所拥有的 资源集合 。在一个Project(Tenant)中可以包含多个User，每一个User都会根据权限的划分来使用Project(Tenant)中的资源。比如通过Nova创建虚拟机时要指定到某个Project中，在Cinder创建卷也要指定到某个Project中。User访问Project的资源前，必须要与该Project关联，并且指定User在Project下的Role。

Role：用于划分权限。可以通过给User指定Role，使User获得Role对应的操作权限。Keystone返回给User的Token包含了Role列表，被访问的Services会判断访问它的User和User提供的Token中所包含的Role。系统默认使用管理Role admin和成员Role _member_ 。

Policy：OpenStack对User的验证除了OpenStack的身份验证以外，还需要鉴别User对某个Service是否有访问权限。Policy机制就是用来控制User对Tenant中资源(包括Services)的操作权限。对于Keystone service来说，Policy就是一个JSON文件，默认是/etc/keystone/policy.json。通过配置这个文件，Keystone Service实现了对User基于Role的权限管理。

Token：是一个字符串表示，作为访问资源的令牌。Token包含了在 指定范围和有效时间内 可以被访问的资源。EG. 在Nova中一个tenant可以是一些虚拟机，在Swift和Glance中一个tenant可以是一些镜像存储，在Network中一个tenant可以是一些网络资源。Token一般被User持有。

Credentials：用于确认用户身份的凭证

Authentication：确定用户身份的过程

Service：Openstack service，即Openstack中运行的组件服务。

Endpoint：一个可以通过网络来访问和定位某个Openstack service的地址，通常是一个URL。比如，当Nova需要访问Glance服务去获取image 时，Nova通过访问Keystone拿到Glance的endpoint，然后通过访问该endpoint去获取Glance服务。我们可以通过Endpoint的region属性去定义多个region。Endpoint 该使用对象分为三类：

admin url –> 给admin用户使用，Post：35357

internal url –> OpenStack内部服务使用来跟别的服务通信，Port：5000

public url –> 其它用户可以访问的地址，Post：5000

创建完service后创建API EndPoint. 在openstack中，每一个service都有三种end points. Admin, public, internal。 Admin是用作管理用途的，如它能够修改user/tenant(project)。 public 是让客户调用的，比如可以部署在外网上让客户可以管理自己的云。internal是openstack内部调用的。三种endpoints 在网络上开放的权限一般也不同。Admin通常只能对内网开放，public通常可以对外网开放internal通常只能对安装有openstack对服务的机器开放。

V3新增

Tenant 重命名为 Project

添加了 Domain 的概念

添加了 Group 的概念

详细流程：

用户alice登录keystone系统（password或者token的方式），获取一个临时的token和catalog服务目录（v3版本登录时，如果没有指定scope，project或者domain，获取的临时token没有任何权限，不能查询project或者catalog）。

alice通过临时token获取自己的所有的project列表。

alice选定一个project，然后指定project重新登录，获取一个正式的token，同时获得服务列表的endpoint，用户选定一个endpoint，在HTTP消息头中携带token，然后发送请求（如果用户知道project name或者project id可以直接第3步登录）。

消息到达endpoint之后，由服务端（nova）的keystone中间件（pipeline中的filter：authtoken）向keystone发送一个验证token的请求。（token类型：uuid需要在keystone验证token，pki类型的token本身是包含用户详细信息的加密串，可以在服务端完成验证）

keystone验证token成功之后，将token对应用户的详细信息，例如：role，username，userid等，返回给服务端（nova）。

服务端（nova）完成请求，例如：创建虚拟机。

服务端返回请求结果给alice。

2.glance

v1

v2

3.nova与cinder

nova主要组成:

nova-api

nova-scheduler

nova-compute

nova-conductor

cinder主要组成:

cinder-api

cinder-scheduler

cinder-volume

cinder各组件功能：

Cinder-api 是 cinder 服务的 endpoint，提供 rest 接口，负责处理 client 请求，并将 RPC 请求发送至 cinder-scheduler 组件。

Cinder-scheduler 负责 cinder 请求调度，其核心部分就是 scheduler_driver, 作为 scheduler manager 的 driver，负责 cinder-volume 具体的调度处理，发送 cinder RPC 请求到选择的 cinder-volume。

Cinder-volume 负责具体的 volume 请求处理，由不同后端存储提供 volume 存储空间。目前各大存储厂商已经积极地将存储产品的 driver 贡献到 cinder 社区

cinder架构图：

openstack组件间通信:调用各组件api提供的rest接口，组件内通信:基于rpc(远程过程调用)机制，而rpc机制是基于AMQP模型实现的

从rpc使用的角度出发，nova，neutron，和cinder的流程是相似的，我们以cinder为例阐述rpc机制

(参考链接：https://www.ibm.com/developerworks/cn/cloud/library/1403_renmm_opestackrpc/)

Openstack 组件内部的 RPC（Remote Producer Call）机制的实现是基于 AMQP(Advanced Message Queuing Protocol)作为通讯模型，从而满足组件内部的松耦合性。AMQP 是用于异步消息通讯的消息中间件协议，AMQP 模型有四个重要的角色:

Exchange：根据 Routing key 转发消息到对应的 Message Queue 中

Routing key：用于 Exchange 判断哪些消息需要发送对应的 Message Queue

Publisher：消息发送者，将消息发送的 Exchange 并指明 Routing Key，以便 Message Queue           可以正确的收到消息

Consumer：消息接受者，从 Message Queue 获取消息

消息发布者 Publisher 将 Message 发送给 Exchange 并且说明 Routing Key。Exchange 负责根据 Message 的 Routing Key 进行路由，将 Message 正确地转发给相应的 Message Queue。监听在 Message Queue 上的 Consumer 将会从 Queue 中读取消息。

Routing Key 是 Exchange 转发信息的依据，因此每个消息都有一个 Routing Key 表明可以接受消息的目的地址，而每个 Message Queue 都可以通过将自己想要接收的 Routing Key 告诉 Exchange 进行 binding，这样 Exchange 就可以将消息正确地转发给相应的 Message Queue。

Publisher可以分为4类：

Direct Publisher发送点对点的消息；

Topic Publisher采用“发布——订阅”模式发送消息；

Fanout Publisher发送广播消息的发送；

Notify Publisher同Topic Publisher，发送 Notification 相关的消息。

Exchange可以分为3类：

Direct Exchange根据Routing Key进行精确匹配，只有对应的 Message Queue 会接受到消息；

Topic Exchange根据Routing Key进行模式匹配，只要符合模式匹配的Message Queue都会收到消息；

Fanout Exchange将消息转发给所有绑定的Message Queue。

AMQP消息模型

RPC 发送请求

Client 端发送 RPC 请求由 publisher 发送消息并声明消息地址，consumer 接收消息并进行消息处理，如果需要消息应答则返回处理请求的结果消息。

OpenStack RPC 模块提供了 rpc.call，rpc.cast, rpc.fanout_cast 三种 RPC 调用方法，发送和接收 RPC 请求。

rpc.call 发送 RPC 请求并返回请求处理结果，请求处理流程如图 5 所示，由 Topic Publisher 发送消息，Topic Exchange 根据消息地址进行消息转发至对应的 Message Queue 中，Topic Consumer 监听 Message Queue，发现需要处理的消息则进行消息处理，并由 Direct Publisher 将请求处理结果消息，请求发送方创建 Direct Consumer 监听消息的返回结果

rpc.cast 发送 RPC 请求无返回，请求处理流程如图 6 所示，与 rpc.call 不同之处在于，不需要请求处理结果的返回，因此没有 Direct Publisher 和 Direct Consumer 处理。

rpc.fanout_cast 用于发送 RPC 广播信息无返回结果

neutron

neutron包含组件：

neutron-server

neutron-plugin

neutron-agent

neutron各组件功能介绍：

Neutron-server可以理解为一个专门用来接收Neutron REST API调用的服务器，然后负责将不同的rest api分发到不同的neutron-plugin上。

Neutron-plugin可以理解为不同网络功能实现的入口，各个厂商可以开发自己的plugin。Neutron-plugin接收neutron-server分发过来的REST API，向neutron database完成一些信息的注册，然后将具体要执行的业务操作和参数通知给自身对应的neutron agent。

Neutron-agent可以直观地理解为neutron-plugin在设备上的代理，接收相应的neutron-plugin通知的业务操作和参数，并转换为具体的设备级操作，以指导设备的动作。当设备本地发生问题时，neutron-agent会将情况通知给neutron-plugin。

Neutron database，顾名思义就是Neutron的数据库，一些业务相关的参数都存在这里。

Network provider，即为实际执行功能的网络设备，一般为虚拟交换机（OVS或者Linux Bridge）。

neutron-plugin分为core-plugin和service-plugin两类。

Core-plugin，Neutron中即为ML2（Modular Layer 2），负责管理L2的网络连接。ML2中主要包括network、subnet、port三类核心资源，对三类资源进行操作的REST API被neutron-server看作Core API，由Neutron原生支持。其中：

Service-plugin，即为除core-plugin以外其它的plugin，包括l3 router、firewall、loadbalancer、VPN、metering等等，主要实现L3-L7的网络服务。这些plugin要操作的资源比较丰富，对这些资源进行操作的REST API被neutron-server看作Extension API，需要厂家自行进行扩展。

“Neutron对Quantum的插件机制进行了优化，将各个厂商L2插件中独立的数据库实现提取出来，作为公共的ML2插件存储租户的业务需求，使得厂商可以专注于L2设备驱动的实现，而ML2作为总控可以协调多厂商L2设备共同运行”。在Quantum中，厂家都是开发各自的Service-plugin，不能兼容而且开发重复度很高，于是在Neutron中就为设计了ML2机制，使得各厂家的L2插件完全变成了可插拔的，方便了L2中network资源扩展与使用。

（注意，以前厂商开发的L2 plugin跟ML2都存在于neutron/plugins目录下，而可插拔的ML2设备驱动则存在于neutron/plugins/ml2/drivers目录下）

ML2作为L2的总控，其实现包括Type和Mechanism两部分，每部分又分为Manager和Driver。Type指的是L2网络的类型（如Flat、VLAN、VxLAN等），与厂家实现无关。Mechanism则是各个厂家自己设备机制的实现，如下图所示。当然有ML2，对应的就可以有ML3，不过在Neutron中L3的实现只负责路由的功能，传统路由器中的其他功能（如Firewalls、LB、VPN）都被独立出来实现了，因此暂时还没有看到对ML3的实际需求。

一般而言，neutron-server和各neutron-plugin部署在控制节点或者网络节点上，而neutron agent则部署在网络节点上和计算节点上。我们先来分析控制端neutron-server和neutron-plugin的工作，然后再分析设备端neutron-agent的工作。

neutron新进展(dragon  flow):

https://www.ustack.com/blog/neutron-dragonflow/

网络模式介绍：

根据创建网络的用户的权限，Neutron network 可以分为：

Provider network：管理员创建的和物理网络有直接映射关系的虚拟网络。

Tenant network：租户普通用户创建的网络，物理网络对创建者透明，其配置由 Neutorn 根据管理员在系统中的配置决定。

根据网络的类型，Neutron network 可以分为：

VLAN network（虚拟局域网） ：基于物理 VLAN 网络实现的虚拟网络。共享同一个物理网络的多个 VLAN 网络是相互隔离的，甚至可以使用重叠的 IP 地址空间。每个支持 VLAN network 的物理网络可以被视为一个分离的 VLAN trunk，它使用一组独占的 VLAN ID。有效的 VLAN ID 范围是 1 到 4094。

Flat network：基于不使用 VLAN 的物理网络实现的虚拟网络。每个物理网络最多只能实现一个虚拟网络。

local network（本地网络）：一个只允许在本服务器内通信的虚拟网络，不知道跨服务器的通信。主要用于单节点上测试。

GRE network （通用路由封装网络）：一个使用 GRE 封装网络包的虚拟网络。GRE 封装的数据包基于 IP 路由表来进行路由，因此 GRE network 不和具体的物理网络绑定。

VXLAN network（虚拟可扩展网络）：基于 VXLAN 实现的虚拟网络。同 GRE network 一样， VXLAN network 中 IP 包的路由也基于 IP 路由表，也不和具体的物理网络绑定。

注：在AWS中，该概念对应 VPC 概念。AWS 对 VPC 的数目有一定的限制，比如每个账户在每个 region 上默认最多只能创建 5 个VPC，通过特别的要求最多可以创建 100 个。

1.vlan

2.gre与vxlan请参考

http://www.cnblogs.com/sammyliu/p/4622563.html

http://www.cnblogs.com/xingyun/p/4620727.html

gre网络

gre与vxlan区别

关于gre和vxlan二次封装数据包的MTU问题

VXLAN 模式下虚拟机中的 mtu 最大值为1450，也就是只能小于1450，大于这个值会导致 openvswitch 传输分片，进而导致虚拟机中数据包数据重传，从而导致网络性能下降。GRE 模式下虚拟机 mtu 最大为1462。

计算方法如下：

vxlan mtu = 1450 = 1500 – 20(ip头) – 8(udp头) – 8(vxlan头) – 14(以太网头)

gre mtu = 1462 = 1500 – 20(ip头) – 4(gre头) – 14(以太网头)

可以配置 Neutron DHCP 组件，让虚拟机自动配置 mtu，

#/etc/neutron/dhcp_agent.ini[DEFAULT]dnsmasq_config_file = /etc/neutron/dnsmasq-neutron.conf#/etc/neutron/dnsmasq-neutron.confdhcp-option-force=26,1450或1462

重启 DHCP Agent，让虚拟机重新获取 IP，然后使用 ifconfig 查看是否正确配置 mtu。