OpenStack部署都有哪些方式

对于每一个刚接触到OpenStack的新人而言，安装无疑是最困难的，同时这也客观上提高了大家学习OpenStack云计算的技术门槛。想一想，自己3年前网上偶然接触到OpenStack时，一头茫然，手动搭建一个多节点环境时居然用了3个星期。

时至今日，真是感触颇多，从某种角度而言，也很庆幸当时自己并未因困难而放弃OpenStack，否则，应该是去做其他领域了吧！

言归正传，咱们就来数落数落部署OpenStack都有哪些方式吧。这里，我们根据使用者群体的不同类型来进行分类和归纳：

个人使用方面

DevStack

无疑，在可预见的未来时间内，DevStack仍将是众多开发者们的首选安装方式或工具。该方式主要是通过配置参数，执行shell脚本来安装一个OpenStack的开发环境。

Github: https://github.com/openstack-dev/devstack

Wiki: https://wiki.openstack.org/wiki/DevStack

Rdo

Rdo是由Red Hat开源的一款部署OpenStack的工具，同DevStack一样，支持单节点和多节点部署。但Rdo只支持CentOS系列的 *** 作系统。需要注意的是，该项目并不属于OpenStack官方社区项目。

Docs：https://www.rdoproject.org/install/quickstart

手动部署

手动部署all-in-one、multi-node、multi-HA-node环境。

其他

企业、团体方面

Puppet

Puppet由Ruby语言编写。应当说，Puppet是进入OpenStack自动化部署中的早期一批项目，历史还算悠久。目前，它的活跃开发群体们是Red hat、 Mirantis、UnitedStack等。

Red

hat自从收购Ansible之后，如今仍然保持强势劲头在Puppet

OpenStack项目中的Commit数量和质量，其技术实力不容小觑；Mirantis出品的Fuel部署工具中，大量的模块代码便使用的是

Puppet。就国内而言，UnitedStack是Puppet社区贡献和使用的最大用户。

Github：

https://github.com/openstack/puppet-keystone

Governance：

Wiki：

https://wiki.openstack.org/wiki/Puppet

Ansible

Ansible

是新近出现的自动化运维工具，已被Red

Hat收购。基于Python开发，集合了众多运维工具（puppet、cfengine、chef、saltstack等）的优点，实现了批量系统配

置、批量程序部署、批量运行命令等功能，它一方面总结了Puppet的设计上的得失，另一方面也改进了很多设计。比如是基于SSH方式工作，故而不需要在

被控端安装客户端。使得在和OpenStack结合上没有历史包袱，更加能够轻装上阵，未来发展潜力不容小觑号称是“你一直寻找的下一代Iaas”的

Zstack，使用到的部署工具也是基于Ansible。

Openstack-ansible项目，最早是由老牌Rackspace公司在Launchpad官网上注册。

在最新的Ansible OpenStack项目社区Commit贡献中，Rackspace也可谓是遥遥领先，而紧随其后的是Red Hat、国内九州云等公司。

Github：https://github.com/openstack/openstack-ansible

SaltStack

SaltStack

也是一款开源的自动化部署工具，基于Python开发，实现了批量系统配置、批量程序部署、批量运行命令等功能，和Ansible也是挺相近的。不同之一

是，由于SaltStack的master和minion认证机制和工作方式，需要在被控端安装minion客户端，在加之其他原因，自然和

Ansible相比，其优缺点便很明显了。

需要注意的是，使用Saltstack部署OpenStack，并不属于OpenStack社区项目。目前，主要还是处于用户自研自用的阶段。据笔者所知，目前国内的携程应该是使用Saltstack部署OpenStack规模最大的用户。

Saltstack部署OpenStack示例：https://github.com/luckpenguin/saltstack_openstack

Saltstack部署OpenStack模块：

TripleO

Tripleo

项目最早由HP于2013.4在launchpad上注册BP。用于完成OpenStack的安装与部署。TripleO全称“OpenStack On

OpenStack”，意思即为“云上云”，可以简单理解为利用OpenStack来部署OpenStack，即首先基于V2P(和P2V相反，也就是指

把虚拟机的镜像迁移到物理机上)的理念事先准备好一些OpenStack节点（计算、存储、控制节点）的镜像，然后利用已有openstack环境的裸机

服务Ironic项目去部署裸机，软件安装部分的diskimage-builder，最后通过Heat项目和镜像内的DevOps工具(Puppet

Or Chef)再在裸机上配置运行openstack。

和其他部署工具不同的是，TripleO利用OpenStack本来的基础设施来部署OpenStack，基于Nova、 Neutron、Ironic和Heat，来自动化部署和伸缩OpenStack集群。

应

当确切的说，TripleO项目属于当前OpenStack社区主推的“Big Tent”开发模式下的big tent

project（OpenStack下的项目分为三种，core project: nova/neutron等核心项目，big tent

project: 非核心项目，但也被OpenStack 基金会接受；第三种就是其它项目，只是放在OpenStack下，但是社区还没有接受）。

在该项目的社区Commit贡献上，Red hat可谓是遥遥领先，而紧随其后的是IBM等公司。

Wiki：https://wiki.openstack.org/wiki/TripleO

Kolla

在

国内一些互联网资料上，常看到关于kolla是TripleO项目的一部分这样的描述，其实是不准确的。真实的是，Kolla项目起源于Tripleo项

目，时至今日，与它没有任何关系（虽然它们的目标都是做自动化部署，但走的道路却不同）。比之于Tripleo和其他部署工具，Kolla走的是

docker容器部署路线。

kolla项目起源于TripleO项目，聚焦于使用docker容器部署OpenStack服务。该项目由

Cisco于2014年9月提出，是OpenStack的孵化项目。当前Kolla项目在Kollaglue

repo提供了以下服务的docker镜像。 # docker search kollaglue

Kolla的优势和使用场景，体现在如下几个方面：

原子性的升级或者回退OpenStack部署；

基于组件升级OpenStack；

基于组件回退OpenStack；

这里，我们予以拆分来理解：

Kolla

的最终目标是为OpenStack的每一个服务都创建一个对应的Docker Image，通过Docker

Image将升级的粒度减小到Service级别，从而使升级时，对OpenStack影响能达到最小，并且一旦升级失败，也很容易回滚。升级只需要三

步：Pull新版本的容器镜像，停止老版本的容器服务，然后启动新版本容器。回滚也不需要重新安装包了，直接启动老版本容器服务就行，非常方便。

Kolla是通过Docker Compose来部署OpenStack集群的，现在主要是针对裸机部署的，所以在部署Docker Container时，默认的网络配置都是Host模式。

首

先，只需要通过一个命令就可以把管理节点部署完成，这个命令是调用Docker

Compose来部署OpenStack的所有服务，然后我们可以在每一个计算节点上通过Docker

Compose安装计算节点需要的服务，就能部署一个OpenStack集群。因为Kolla的Docker

Image粒度很小，它针对每个OpenStack服务都有特定的Image，所以我们也可以通过Docker

Run来 *** 作某个具体的OpenStack服务。

目前，我所在的公司九州云的一位同事近日获得提名成为Kolla项目Core。为OpenStack社区中增添了一份来自于中国的力量。

Fuel

Fuel

是针对OpenStack生产环境目标

（非开源）设计的一个端到端”一键部署“的工具，大量采用了Python、Ruby和JavaScript等语言。其功能含盖自动的PXE方式的 *** 作系统

安装，DHCP服务，Orchestration服务 和puppet 配置管理相关服务等，此外还有OpenStack关键业务健康检查和log

实时查看等非常好用的服务。

Fuel，这款让很多人即爱且痛的工具，在国内外都很盛名。爱的原因是，它确实很棒；痛的原因是，要想彻底掌握

它，可不是一件容易事（各个模块集成度高、使用技术复杂）。既然提到Fuel，自然不能不提它的父母——Mirantis。Mirantis是一家技术实

力非常雄厚的OpenStack服务集成商，他是社区贡献排名前5名中唯一一个靠OpenStack软件和服务盈利的公司。同时，Fuel的版本节奏也很

快，平均每半年就能提供一个相对稳定的社区版。

从和笔者接触到的一些情况来看，国内研究、使用Fuel的个人、群体还是为数不少的。不少国内OpenStack初创公司的安装包就是基于Fuel去修改的。

kolla-ansible 安装openstack时，要求被安装的节点上，对应网络平面的网卡名称要相同。但有时候会遇到不同节点对应网卡名不相同的问题，同时，有些节点修改网卡名又不能成功。这时候，可以使用网卡bond技术，将网卡名称统一。

bonding技术提供了七种工作模式，在使用的时候需要指定一种，每种有各自的优缺点.

具体的网上有很多资料，了解每种模式的特点根据自己的选择就行, 一般会用到0、1、4、6这几种模式。

下面介绍CentOS7.5/Ubuntu16.04(Kylin)系统的网卡bond方法，这里使用mode 1

linux下网卡bonding配置

Ubuntu双网卡绑定

重启过程中可能出现 option mode: ubable to set because the bond device is up 错误，这时候删除已经存在的网卡bond上的ip，并重试

由于网络部分出现了许多得新名词。将从整体到分部细致讲解。

来源于网络得一张图

如图所示，连成了一条线。重要得如何实现互联，接下来以表象论证这张图。

最好将图放在一边，边看边对照图。

这里先介绍从虚拟机访问外网。端口A开始：

表现出来就是虚拟机有张网卡A。

查询此虚拟机得子网ip为 10.1.1.5，以及所在节点，记住这个节点。

通过子网ip查询到端口id为 b65c1085-a971-4333-82dc-57012e9be490

记住这个id

图中A与B互联，意味着A与B一定具有某种映射关系。

若没有此命令则安装： yum install -y bridge-utils

可以看到这个id对应的tap设备！

veth pair是什么？后面再介绍。

由图可知，端口B(qvbXXX)和端口C(tapXXX)在同一个linux网桥上。它们俩互通了。

端口D在ovs网桥上。C和D的互联是veth pair的特性。

由图可以看出，qvoXXX在ovs网桥上，qvb在linux网桥上。它们之间的互联是veth pair的特性，它们就像一根导线的两端。

ovs查询命令：

这里可以看到3种网桥: br-int、br-tun、br-ex。这里有个印象就好。

仔细的查看一下，可以看到qvoXXX在br-int网桥上。

至此D端口也找到了

E、F端口通过ovs网桥自身连接。

ovs-vsctl show 可以看到两个patch类型的端口，用于连接br-int和br-tun。类似于veth pair。

ovs-vsctl show 可以在br-tun网桥上看到vxlan类型的端口，并注明本地ip和remote ip，通过此类型端口，将不同的物理环境互联，对于上层好似就一个网桥。再者br-tun网桥还与br-int互联，这意味，对于再上一层的应用，似乎只有一个br-int。

和【E】【F】相同。

此时携带源ip为子网的流量到达M端口，而L端口得网段为外网网段，因此M网段的流量此时无法直接进入L端口。借助router（网络命名空间），使用iptables，将M端口流量的源ip转换为外网网段。此时流量可进入L端口从而访问外网。（M与N之间连通性非网络对实现，而是ovs tap设备实现。网络对的一个明显特征为 ip a 可以看到@符号连接两个端口）

找到虚拟机所在租户的路由id

本机为 894699dc-bc60-4b5e-b471-e95afa20f1d7

根据路由id找到网络命名空间

在所有节点上执行如下命令，找到对应id的qrouter

ip netns

本环境为：qrouter-894699dc-bc60-4b5e-b471-e95afa20f1d7

在此网络命名空间的节点上执行（如下命令意义为进入网络命名空间）：

此时已进入网络命名空间。

查看ip

可以看到qg和qr开头的网卡名称。qg为d性ip地址组，qr为子网网关。此时在虚拟机所在节点上查询ovs网桥，可以在br-int看到与此同名的qg和qr端口。

由于是源地址转换，因此先路由再转换源ip(iptables规则)。

查看路由规则：

route -n

第一条可以看到外网的网关，通过qg网卡发送，规则正好匹配。

选好路由规则之后，进行更改源ip。

可以看到 neutron-l3-agent-float-snat(配置了d性ip才会出现)、neutron-l3-agent-snat。因为neutron-l3-agent-float-snat优先级高于neutron-l3-agent-snat，如果没有配置d性ip，则会将源ip改为该路由的外网ip；如果配置了d性ip则会将源ip改为d性ip。

总的来说，流量从qr出去绕了一圈（网络命名空间）改变了源ip又从qg进入，然后通过ovs patch进入br-ex。

br-ex如何与外网连接的呢？进入网络节点查看ovs网桥：

可以看到 br-ex与em3网卡互联。因此流量直接走em3出去。还记得你这张网卡是干嘛的吗？是那张不配置ip的物理网卡！

通过iptables的prerouting可以看出，在进入之前修改了目的d性ip为子网ip，后经路由转发。另，网络命名空间可以通过arp发现子网ip与mac地址的对应关系。

lbaas，负载均衡

dhcp，dhcp服务。

通过前面说的br-tun 实现。如果没有单独划分网络，则使用管理网网段。若单独配置了tunnel网络，则br-tun里的网络使用tunnel网络。

br-tun 里定义了vxlan，并且指定了 local_ip、remote_ip。根据这两个ip以及路由信息，可以确定 br-tun 通过哪张网卡与外部通信。也是因此可以为tunnel配置专用网卡。

都是通过iptables实现。

防火墙：qrouter网络命名空间中得iptables实现。

安全组：虚拟机所在得宿主机得iptables实现。

可以看到防火墙规则。

可以看到对应端口id得安全组规则。

已经知道了qrouter 利用nat表实现d性ip与子网ip之间的映射，但是如何从外部访问到qg网卡的？

这里做了一个简单的模拟 *** 作:

https://www.jianshu.com/p/44e73910c241

dnsmasq 实现。

kolla-ansible 的dnsmasq日志相对路径参考：neutron/dnsmasq.log(可通过dnsmasq.conf 找到日志路径)

日志中可以看到dhcp的详细过程。过程参考如下：

文档参考：

https://docs.openstack.org/neutron/stein/admin/intro-basic-networking.html#dhcp

dhcp也通过网络命名空间实现，名称由网络id决定。dhcp可以拥有多个，通过neutron.conf 中 dhcp_agents_per_network 决定。

另：centos7虚拟机中的 /var/log/messages 也记录了dhcp相关 *** 作。

network qos 可以理解为网络流量限制，官方名称：网络质量即服务

本环境通过openvswitch实现的qos。

如上图为设置的 带宽限制规则。

根据端口号查看流表，命令参考：

上图标记的104就为dscp mark 乘 4 的结果，乘4是一种规范。

https://docs.openstack.org/neutron/queens/admin/deploy-ovs.html

---