openstack部署实践pdf

1. Openstack概述 、 部署安装环境 、 部署Openstack 、 Openstack操作基础

案例1：配置yum仓库

案例2：测试时间服务器

案例3：配置yum仓库

案例4：检查基础环境

案例5：部署Openstack

案例6：网络管理

案例7：登录openstack

1 案例1：配置yum仓库

1.1 问题

本案例要求配置基本环境：

配置三台虚拟机

2CPU，6G 内存，50G 硬盘

2CPU，4.5G 内存，100G 硬盘

配置静态IP ifcfg-eth0

openstack : 192.168.1.10

nova: 192.168.1.11, 192.168.1.12

配置主机名 /etc/hosts，能够相互 ping 通

配置 dns 服务器 /etc/resolv.conf

1.2 方案

此实验的整体方案需要三台机器，openstack作为主节点，nova01 和 nova02作为额外节点，真机做为DNS转发和NTP的服务器(这里不再在表-1中体现)，提供域名解析和时间同步服务，具体情况如表-1所示：

表-1

1.3 步骤

实现此案例需要按照如下步骤进行。

步骤一：准备三台虚拟机

[student@room9pc01 images]$base-vm openstack nova01 nova02

[student@room9pc01 images]$virsh start openstack

[student@room9pc01 images]$virsh start nova01

[student@room9pc01 images]$virsh start nova02

2）opensatck主机扩容为50G

[student@room9pc01 images]$ virsh blockresize--path /var/lib/libvirt/images/openstack.img--size 100G openstack

[student@room9pc01 images]$ virsh console openstack

[root@localhost~]#/usr/bin/growpart /dev/vda1

[root@localhost~]#/usr/sbin/xfs_growfs /

[root@localhost~]# df-h

Filesystem      Size  Used Avail Use%Mounted on

/dev/vda1        50G  914M  50G2%/

3）nova01 和 nova02 主机扩容为100G（以nova01为例）

[student@room9pc01 images]$ virsh blockresize--path /var/lib/libvirt/images/nova01.img--size 50G nova01

重新定义'/var/lib/libvirt/images/nova01.img'块设备大小

[root@localhost~]#/usr/bin/growpart /dev/vda1

[root@localhost~]#/usr/sbin/xfs_growfs  /

[root@localhost~]# df-h

Filesystem      Size  Used Avail Use%Mounted on

/dev/vda1      100G  917M  100G1%/

4）三台主机配置静态ip（以一台为例）

openstack：192.168.1.10

nova01： 192.168.1.11

nova02： 192.168.1.12

[root@localhost~]#cd /etc/sysconfig/network-scripts/

[root@localhost network-scripts]# vim ifcfg-eth0

# Generated by dracut initrd

DEVICE="eth0"

ONBOOT="yes"

NM_CONTROLLED="no"

TYPE="Ethernet"

BOOTPROTO="static"

PERSISTENT_DHCLIENT="yes"

IPADDR=192.168.1.10

NEMASK=255.255.255.0

GATEWAY=192.168.1.254

5）三台主机修改主机名，配置/etc/hosts，和/etc/resolv.conf文件（以一台为例）

[root@localhost~]# hostname openstack

[root@localhost~]# echo openstack>/etc/hostname

[root@localhost~]#vim /etc/hosts

192.168.1.10openstack

192.168.1.11nova01

192.168.1.12nova02

[root@localhost~]#vim /etc/resolv.conf//去掉search开头的行

;generatedby /usr/sbin/dhclient-script

nameserver192.168.1.254

6）修改三台主机的内存（openstack6G，nova01 和nova02 4G）

[student@room9pc01~]$ virsh edit openstack

...

<memory unit='KiB'>6588282</memory>

<currentMemory unit='KiB'>6588282</currentMemory>

...

[student@room9pc01~]$ virsh edit nova01

...

<memory unit='KiB'>4588282</memory>

<currentMemory unit='KiB'>4588282</currentMemory>

...

[student@room9pc01~]$ virsh start  openstack

域 openstack 已开始

[student@room9pc01~]$ virsh start  nova01

域 nova01 已开始

[student@room9pc01~]$ virsh start  nova02

域 nova02 已开始

2 案例2：测试时间服务器

2.1 问题

本案例要求掌握时间服务的配置：

修改 openstack，nova01，nova02 的时间服务器

重启服务后验证配置

2.2 步骤

实现此案例需要按照如下步骤进行。

步骤一：修改openstack，nova01 和 nova02 的时间服务器（以一台为例）

[root@openstack~]#vim /etc/chrony.conf

...

server192.168.1.254iburst

[root@openstack~]# systemctl restart chronyd

步骤二：验证

[root@openstack~]# chronyc sources-v

...

||||\

MSName/IP address        Stratum Poll Reach LastRx Last sample

===============================================================================

^*gateway36376-93ns[+903ns]+/-26ms

步骤三：两台虚拟机配置静态ip

注意：两台主机同样操作，改一下ip即可（以openstack.te.cn为例）

[root@localhost~]# echo openstack.te.cn>/etc/hostname

[root@localhost~]# hostname openstack.te.cn

//另外一台主机改名为nova.te.cn,配置ip为1.20

[root@openstack~]#vim /etc/sysconfig/network-scripts/ifcfg-eth0

# Generated by dracut initrd

DEVICE="eth0"

ONBOOT="yes"

IPV6INIT="no"

IPV4_FAILURE_FATAL="no"

NM_CONTROLLED="no"

TYPE="Ethernet"

BOOTPROTO="static"

IPADDR="192.168.1.10"

PREFIX=24

GATEWAY=192.168.1.254

[root@openstack~]# systemctl restart network

3 案例3：配置yum仓库

3.1 问题

本案例要求配置yum仓库：

配置 yum 源，软件仓库一共 4 个

3.2 步骤

实现此案例需要按照如下步骤进行。

步骤一：三台主机配置yum源（以一台主机为例，共10670个软件包）

[student@room9pc01~]$cd /linux-soft/04/openstack/

[student@room9pc01 openstack]$ ls

cirros.qcow2  RHEL7-extras.iso  RHEL7OSP-10.iso  small.qcow2

[student@room9pc01 openstack]$mkdir /var/ftp/RHEL7-extras

[student@room9pc01 openstack]$mkdir /var/ftp/RHEL7OSP-10

[student@room9pc01 openstack]$ mount RHEL7-extras.iso  /var/ftp/RHEL7-extras/

mount:/dev/loop1 写保护，将以只读方式挂载

[student@room9pc01 openstack]$ mount RHEL7OSP-10.iso /var/ftp/RHEL7OSP-10/

mount:/dev/loop2 写保护，将以只读方式挂载

[root@openstack~]#vim /etc/yum.repos.d/local.repo

[local_repo]

name=CentOS-$releasever-Base

baseurl="ftp://192.168.1.254/centos-1804"

enabled=1

gpgcheck=1

[RHEL7-extras]

name=RHEL7-extras

baseurl="ftp://192.168.1.254/RHEL7-extras"

enabled=1

gpgcheck=0

[RHEL7OSP-package]

name=RHEL7OSP-package

baseurl="ftp://192.168.1.254/RHEL7OSP-10/rhel-7-server-openstack-10-rpms"

enabled=1

gpgcheck=0

[RHEL7OSP-devtools]

name=RHEL7OSP-devtools

baseurl="ftp://192.168.1.254/RHEL7OSP-10/rhel-7-server-openstack-10-devtools-rpms"

enabled=1

gpgcheck=0

[root@openstack~]#scp /etc/yum.repos.d/local.repo192.168.1.11:/etc/yum.repos.d/

[email protected]'s password:

local.repo                                                                                          100%  490  484.4KB/s  00:00   

[root@openstack ~]# scp /etc/yum.repos.d/local.repo 192.168.1.12:/etc/yum.repos.d/

[email protected]'s password:

local.repo

4 案例4：检查基础环境

4.1 问题

本案例要求准备基础环境，为安装openstack做准备：

安装额外的软件包

是否卸载firewalld 和 NetworkManager

检查配置主机网络参数（静态IP）

主机名必须能够相互 ping 通

检查配置主机yum源（4个，10670）

依赖软件包是否安装

检查NTP服务器是否可用

检查 /etc/resolv.conf 不能有 search 开头的行

4.2 步骤

实现此案例需要按照如下步骤进行。

步骤一：检查基础环境

1）安装额外软件包（三台机器操作，这里以一台为例）

[root@openstack yum.repos.d]# yum install-y qemu-kvm libvirt-client libvirt-daemon libvirt-daemon-driver-qemu python-setuptools

2）是否卸载firewalld 和 NetworkManager

[root@openstack~]# rpm-qa|grep NetworkManager*

[root@openstack~]# rpm-qa|grep firewalld*

3）检查配置主机网络参数

[root@openstack~]#cat /etc/sysconfig/network-scripts/ifcfg-eth0

# Generated by dracut initrd

DEVICE="eth0"

ONBOOT="yes"

NM_CONTROLLED="no"

TYPE="Ethernet"

BOOTPROTO="static"

PERSISTENT_DHCLIENT="yes"

IPADDR=192.168.1.10

NEMASK=255.255.255.0

GATEWAY=192.168.1.254

4）验证主机名是否互通

[root@openstack~]# ping openstack

...

64bytes fromopenstack(192.168.1.10):icmp_seq=1ttl=255time=0.023ms

64bytes fromopenstack(192.168.1.10):icmp_seq=2ttl=255time=0.027ms

...

[root@openstack~]# ping nova01

PINGnova01(192.168.1.11)56(84)bytes of data.

64bytes fromnova01(192.168.1.11):icmp_seq=1ttl=255time=0.139ms

...

[root@openstack~]# ping nova02

PINGnova02(192.168.1.12)56(84)bytes of data.

64bytes fromnova02(192.168.1.12):icmp_seq=1ttl=255time=0.251ms

...

5）检查配置主机yum源

[root@openstack~]# yum repolist

已加载插件：fastestmirror

Loading mirror speeds from cached hostfile

源标识                                                          源名称                                                          状态

RHEL7-extras                                                    RHEL7-extras76

RHEL7OSP-devtools                                              RHEL7OSP-devtools3

RHEL7OSP-package                                                RHEL7OSP-package680

local_repo                                                      CentOS-7-Base9,911

repolist:10,670

6）检查时间同步是否可用

[root@openstack~]# chronyc  sources-v

210Numberof sources=1

....

||||\

MSName/IP address        Stratum Poll Reach LastRx Last sample

===============================================================================

^*gateway3737728+31us[+89us]+/-25ms

[root@openstack~]#

7）检查/etc/resolv.conf 不能有 search 开头的行

[root@openstack~]#cat /etc/resolv.conf

;generatedby /usr/sbin/dhclient-script

nameserver192.168.1.254

5 案例5：部署Openstack

5.1 问题

本案例要求通过packstack完成以下配置：

通过packstack部署Openstack

根据相关日志文件进行排错

5.2 步骤

实现此案例需要按照如下步骤进行。

步骤一：安装packstack

[root@openstack~]# yum install-y openstack-packstack

[root@openstack~]# packstack--gen-answer-file answer.ini

//answer.ini与answer.txt是一样的，只是用vim打开answer.ini文件有颜色

Packstack changed given value  to requiredvalue /root/.ssh/id_rsa.pub

[root@openstack~]# vim answer.ini

42CONFIG_SWIFT_INSTALL=n

45CONFIG_CEILOMETER_INSTALL=n//计费相关模块

49CONFIG_AODH_INSTALL=n//计费相关模块

53CONFIG_GNOCCHI_INSTALL=n//计费相关模块

75CONFIG_NTP_SERVERS=192.168.1.254//时间服务器的地址

98CONFIG_COMPUTE_HOSTS=192.168.1.11

102CONFIG_NETWORK_HOSTS=192.168.1.10,192.168.1.11

333CONFIG_KEYSTONE_ADMIN_PW=a//修改管理员的密码

840CONFIG_NEUTRON_ML2_TYPE_DRIVERS=flat,vxlan//驱动类型

876CONFIG_NEUTRON_ML2_VXLAN_GROUP=239.1.1.5

//设置组播地址,最后一个随意不能为0和255,其他固定

910CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS=physnet1:br-ex//物理网桥的名称

921CONFIG_NEUTRON_OVS_BRIDGE_IFACES=br-ex:eth0

//br-ex桥的名称与eth0连接，管理eth0,网桥与哪个物理网卡连接

1179CONFIG_PROVISION_DEMO=n//DEMO是否测试

[root@openstack~]# packstack--answer-file=answer.ini

Welcome to the Packstack setup utility

The installation log file is available at:/var/tmp/packstack/20190423-170603-b43g_i/openstack-setup.log

Installing:

Clean Up[DONE]

Discovering ip protocol version[DONE]

[email protected]'s password:

[email protected]'s password:

Setting up ssh keys

****Installation completed successfully******//出现这个为成功

6 案例6：网络管理

6.1 问题

本案例要求运用OVS完成以下配置：

查看外部OVS网桥及其端口

验证OVS配置

6.2 步骤

实现此案例需要按照如下步骤进行。

步骤一：查看外部OVS网桥

1）查看br-ex网桥配置（br-ex为OVS网桥设备）

[root@openstack~]#cat /etc/sysconfig/network-scripts/ifcfg-br-ex

ONBOOT="yes"

NM_CONTROLLED="no"

IPADDR="192.168.1.10"

PREFIX=24

GATEWAY=192.168.1.254

DEVICE=br-ex

NAME=br-ex

DEVICETYPE=ovs

OVSBOOTPROTO="static"

TYPE=OVSBridge

2）查看eth0网卡配置（该网卡为OVS网桥的接口）

[root@openstack~]#cat /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0

NAME=eth0

DEVICETYPE=ovs

TYPE=OVSPort

OVS_BRIDGE=br-ex

ONBOOT=yes

BOOTPROTO=none

3）验证OVS配置

[root@openstack~]# ovs-vsctl show

Bridge br-ex

Controller"tcp:127.0.0.1:6633"

is_connected:true

fail_mode:secure

Port br-ex

Interface br-ex

type:internal

Port phy-br-ex

Interface phy-br-ex

type:patch

options:{peer=int-br-ex}

Port"eth0"

Interface"eth0"

ovs_version:"2.5.0"

7 案例7：登录openstack

7.1 问题

本案例要求通过Horizon完成以下操作：

修改/etc/httpd/conf.d/15-horizon_vhost.conf 配置文件，使其可以成功登录openstack

7.2 步骤

实现此案例需要按照如下步骤进行。

步骤一：浏览器访问openstack

1）浏览器访问

[root@openstack~]# firefox192.168.1.10//访问失败

2）需要改配置文件并重新加载

[root@openstack~]#

[root@openstack conf.d]# vi15-horizon_vhost.conf

35WSGIProcessGroup apache

36WSGIApplicationGroup%{GLOBAL}//添加这一行

[root@openstack conf.d]# apachectl  graceful//重新载入配置文件

3）浏览器访问，出现页面，如图-6所示：

图-6

3）查看用户名和密码

[root@openstack conf.d]# cd

[root@openstack~]# ls

answer.ini  keystonerc_admin//keystonerc_admin生成的文件，里面有用户名和密码

[root@openstack~]# cat keystonerc_admin

unset OS_SERVICE_TOKEN

exportOS_USERNAME=admin//用户名

exportOS_PASSWORD=a//密码

exportOS_AUTH_URL=http://192.168.1.10:5000/v2.0

exportPS1='[\u@\h \W(keystone_admin)]\$ '

exportOS_TENANT_NAME=admin

exportOS_REGION_NAME=RegionOne

4）在火狐浏览器中输入用户名和密码，登录后页面如图-7所示：

图-7

安装openstack可能会出现的错误以及排错方法

1）ntp时间不同步，如图-2所示：

图-2

解决办法：查看ntp时间服务器，是否出现*号，若没有，查看配置文件，配置ntp服务器步骤在案例3，可以参考

[root@room9pc01~]# chronyc sources-v//出现*号代表NTP时间可用

^*120.25.115.20261762-753us[-7003us]+/-24ms

[root@openstack~]# chronyc sources-v

^*192.168.1.25439377504+50us[-20us]+/-24ms

[root@nova~]# chronyc sources-v

^*192.168.1.25439377159-202us[-226us]+/-24ms

2）网桥名称写错，如图-3所示：

图-3

解决办法：检查配置文件

[root@openstack~]# vim answer.ini

...

921CONFIG_NEUTRON_OVS_BRIDGE_IFACES=br-ex:eth0

//br-ex桥的名称与eth0连接，管理eth0,网桥与哪个物理网卡连接

...

3）若/root/.ssh/id_rsa.pub，提示password，同样是配置文件没有写对，如图-4所示：

图-4

4）yum源没有配置正确，如图-5所示：

图-5

解决办法：检查yum是否为10853个软件包，查看是否是yum源没有配置正确，之后安装oprnstack-dashboard

5）出现Cannot allocate memory,如图-6所示：

图-6

解决办法：

内存不足，重新启动主机

6）出现/usr/bin/systemctl start openvswith ... falied，说明是ssse3指令集的错误，如图-7所示：

图-7

解决办法：编辑openstack的xml文件，在里面添加

<cpu mode='host-passthrough'>

</cpu>

7）若出现 Could not prefetch... ‘openstack’。 如图-8所示：

图-8

配置文件里面有中文符号

9）访问openstack出错

图-9

没有修改Apache配置文件

4）创建名为myproject的项目

[root@openstack~]# source~/keystonerc_admin  //初始化环境变量

[root@openstack~(keystone_admin)]# openstack project create myproject

+-------------+----------------------------------+

|Field|Value|

+-------------+----------------------------------+

|description|None|

|enabled|True|

|id||

|name|myproject|

+-------------+----------------------------------+

5）查看项目信息

[root@openstack~(keystone_admin)]# openstack project list

+----------------------------------+-----------+

|ID|Name|

+----------------------------------+-----------+

||services|

||admin|

||myproject|

+----------------------------------+-----------+

6）更新vcpu配额为30

[root@openstack~(keystone_admin)]# nova quota-update--cores30myproject

7）删除myproject

[root@openstack~(keystone_admin)]# openstack projectdeletemyproject

2. 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去修改的。

3. 如何使用OpenStack，Docker和Spark打造一个云服务

蘑菇街基于 OpenStack 和 Docker 的私有云实践

本次主要想分享一下过去一年时间里，我们在建设基于Docker的私有云实践过程中，曾经遇到过的问题，如何解决的经验，还有我们的体会和思考，与大家共勉。
在生产环境中使用Docker有一些经历和经验。私有云项目是2014年圣诞节期间上线的，从无到有，经过了半年多的发展，经历了3次大促，已经逐渐形成了一定的规模。

架构
集群管理
大家知道，Docker自身的集群管理能力在当时条件下还很不成熟，因此我们没有选择刚出现的 Swarm，而是用了业界最成熟的OpenStack，这样能同时管理Docker和KVM。我们把Docker当成虚拟机来跑，是为了能满足业务上对虚拟化的需求。今后的思路是微服务化，把应用进行拆分，变成一个个微服务，实现PaaS基于应用的部署和发布。
通过OpenStack如何管理Docker?我们采用的是OpenStack+nova-docker+Docker的架构模式。nova- docker是StackForge上一个开源项目，它做为nova的一个插件，通过调用Docker的RESTful接口来控制容器的启停等动作。
我们在IaaS基础上自研了编排调度等组件，支持应用的弹性伸缩、灰度升级等功能，并支持一定的调度策略，从而实现了PaaS层的主要功能。
同时，基于Docker和Jenkins实现了持续集成(CI)。Git中的项目如果发生了git push等动作，便会触发Jenkins Job进行自动构建，如果构建成功便会生成Docker Image并push到镜像仓库。基于CI生成的Docker Image，可以通过PaaS的API或界面，进行开发测试环境的实例更新，并最终进行生产环境的实例更新，从而实现持续集成和持续交付。
网络和存储
网络方面，我们没有采用Docker默认提供的NAT网络模式，NAT会造成一定的性能损失。通过OpenStack，我们支持Linux bridge和Open vSwitch，不需要启动iptables，Docker的性能接近物理机的95%。
容器的监控
监控方面，我们自研了container tools，实现了容器load值的计算，替换了原有的top、free、iostat、uptime等命令。这样业务方在容器内使用常用命令时看到的是容器的值，而不是整个物理机的。目前我们正在移植Lxcfs到我们的平台上。
我们还在宿主机上增加了多个阈值监控和报警，比如关键进程监控、日志监控、实时pid数量、网络连接跟踪数、容器oom报警等等。
冗灾和隔离性
冗灾和隔离性方面，我们做了大量的冗灾预案和技术准备。我们能够在不启动docker daemon的情况下，离线恢复Docker中的数据。同时，我们支持Docker的跨物理机冷迁移，支持动态的CPU扩容/缩容，网络IO磁盘IO的限速。
遇到的问题及解决方法
接近一年不到的产品化和实际使用中我们遇到过各种的问题，使用Docker的过程也是不断优化Docker、不断定位问题、解决问题的过程。
我们现在的生产环境用的是CentOS 6.5。曾经有个业务方误以为他用的Docker容器是物理机，在Docker容器里面又装了一个Docker，瞬间导致内核crash，影响了同一台物理机的其他Docker容器。
经过事后分析是2.6.32-431版本的内核对network namespace支持不好引起的，在Docker内创建bridge会导致内核crash。upstream修复了这个bug，从2.6.32-431升级到2.6.32-504后问题解决。
还有一个用户写的程序有bug，创建的线程没有及时回收，容器中产生了大量的线程，最后在宿主机上都无法执行命令或者ssh登陆，报的错是"bash: fork: Cannot allocate memory"，但通过free看空闲的内存却是足够的。
经过分析，发现是内核对pid的隔离性支持不完善，pid_max(/proc/sys/kernel/pid_max)是全局共享的。当一个容器中的pid数目达到上限32768，会导致宿主机和其他容器无法创建新的进程。最新的4.3-rc1才支持对每个容器进行pid_max限制。
我们还观察到docker的宿主机内核日志中会产生乱序的问题。经过分析后发现是由于内核中只有一个log_buf缓冲区，所有printk打印的日志先放到这个缓冲区中，docker host以及container上的rsyslogd都会通过syslog从kernel的log_buf缓冲区中取日志，导致日志混乱。通过修改 container里的rsyslog配置，只让宿主机去读kernel日志，就能解决这个问题。
除此之外，我们还解决了device mapper的dm-thin discard导致内核crash等问题。
体会和思考
最后分享一下我们的体会和思考，相比KVM比较成熟的虚拟化技术，容器目前还有很多不完善的地方，除了集群管理、网络和存储，最重要的还是稳定性。影响稳定性的主要还是隔离性的不完善造成的，一个容器内引起的问题可能会影响整个系统。
容器的memcg无法回收slab cache，也不对dirty cache量进行限制，更容易发生OOM问题。还有，procfs上的一些文件接口还无法做到per-container，比如pid_max。
另外一点是对容器下的运维手段和运维经验的冲击。有些系统维护工具，比如ss，free，df等在容器中无法使用了，或者使用的结果跟物理机不一致，因为系统维护工具一般都会访问procfs下的文件，而这些工具或是需要改造，或是需要进行适配。
虽然容器还不完善，但是我们还是十分坚定的看好容器未来的发展。Kubernetes、Mesos、Hyper、CRIU、runC等容器相关的开源软件，都是我们关注的重点。
Q&A
Q：请问容器间的负载均衡是如何做的?
A： 容器间的负载均衡，更多是PaaS和SaaS层面的。我们的P层支持4层和7层的动态路由，通过域名的方式，或者名字服务来暴露出对外的接口。我们能够做到基于容器的灰度升级，和弹性伸缩。
Q：请问你们的OpenStack是运行在CentOS 6.5上的吗?
A: 是的，但是我们针对OpenStack和Docker依赖的包进行了升级。我们维护了内部的yum源。
Q：请问容器IP是静态编排还是动态获取的?
A: 这个跟运维所管理的网络模式有关，我们内部的网络没有DHCP服务，因此对于IaaS层，容器的IP是静态分配的。对于PaaS层来说，如果有DHCP服务，容器的App所暴露出来IP和端口就可以做到动态的。
Q：请问你们当时部署的时候有没有尝试过用Ubuntu，有没有研究过两个系统间的区别，另外请问你们在OpenStack上是怎样对这些虚拟机监控的?
A: 我们没有尝试过Ubuntu，因为公司生产环境上用的是CentOS。我们的中间件团队负责公司机器的监控，我们和监控团队配合，将监控的agent程序部署到宿主机和每个容器里，这样就可以当成虚拟机来进行监控。
当然，容器的数据是需要从cgroups里来取，这部分提取数据的工作，是我们来实现的。
Q：容器间的网络选型有什么建议，据说采用虚拟网卡比物理网卡有不小的性能损失，Docker自带的weaves和ovs能胜任吗?
A: 容器的网络不建议用默认的NAT方式，因为NAT会造成一定的性能损失。之前我的分享中提到过，不需要启动iptables，Docker的性能接近物理机的95%。Docker的weaves底层应该还是采用了网桥或者Open vSwitch。建议可以看一下nova-docker的源码，这样会比较容易理解。
Q：静态IP通过LXC实现的吗?
A: 静态IP的实现是在nova-docker的novadocker/virt/docker/vifs.py中实现的。实现的原理就是通过ip命令添加 veth pair，然后用ip link set/ip netns exec等一系列命令来实现的，设置的原理和weaves类似。
Q：容器内的进程gdb你们怎么弄的，把gdb打包到容器内吗?
A: 容器内的gdb不会有问题的，可以直接yum install gdb。
Q：共享存储能直接mount到容器里吗?
A: 虽然没试过，但这个通过docker -v的方式应该没什么问题。
Q：不启动Docker Daemon的情况下，离线恢复Docker中的数据是咋做到的?
A: 离线恢复的原理是用dmsetup create命令创建一个临时的dm设备，映射到Docker实例所用的dm设备号，通过mount这个临时设备，就可以恢复出原来的数据。
Q：Docker的跨物理机冷迁移，支持动态的CPU扩容/缩容，网络IO磁盘IO的限速，是怎么实现的，能具体说说吗?
A：Docker的冷迁移是通过修改nova-docker，来实现OpenStack迁移的接口，具体来说，就是在两台物理机间通过docker commit，docker push到内部的registry，然后docker pull snapshot来完成的。
动态的CPU扩容/缩容，网络IO磁盘IO的限速主要是通过novadocker来修改cgroups中的cpuset、iops、bps还有TC的参数来实现的。
Q：请问你们未来会不会考虑使用Magnum项目，还是会选择Swarm?
A：这些都是我们备选的方案，可能会考虑Swarm。因为Magnum底层还是调用了Kubernetes这样的集群管理方案，与其用Magnum，不如直接选择Swarm或者是Kubernetes。当然，这只是我个人的看法。
Q：你们的业务是基于同一个镜像么，如果是不同的镜像，那么计算节点如何保证容器能够快速启动?
A：运维会维护一套统一的基础镜像。其他业务的镜像会基于这个镜像来制作。我们在初始化计算节点的时候就会通过docker pull把基础镜像拉到本地，这也是很多公司通用的做法，据我了解，腾讯、360都是类似的做法。
Q：做热迁移，有没有考虑继续使用传统共享存储的来做?
A： 分布式存储和共享存储都在考虑范围内，我们下一步，就计划做容器的热迁移。
Q：请问你们是直接将公网IP绑定到容器吗，还是通过其他方式映射到容器的私有IP，如果是映射如何解决原本二层的VLAN隔离?
A：因为我们是私有云，不涉及floating ip的问题，所以你可以认为是公网IP。VLAN的二层隔离完全可以在交换机上作。我们用Open vSwitch划分不同的VLAN，就实现了Docker容器和物理机的网络隔离。
Q：Device mapper dm-thin discard问题能说的详细些吗?
A：4月份的时候，有两台宿主机经常无故重启。首先想到的是查看/var/log/messages日志，但是在重启时间点附近没有找到与重启相关的信息。而后在/var/crash目录下，找到了内核crash的日志vmcore-dmesg.txt。日志的生成时间与宿主机重启时间一致，可以说明宿主机是发生了kernel crash然后导致的自动重启。“kernel BUG at drivers/md/persistent-data/dm-btree-remove.c:181!”。 从堆栈可以看出在做dm-thin的discard操作(process prepared discard)，虽然不知道引起bug的根本原因，但是直接原因是discard操作引发的，可以关闭discard support来规避。
我们将所有的宿主机配置都禁用discard功能后，再没有出现过同样的问题。
在今年CNUTCon的大会上，腾讯和大众点评在分享他们使用Docker的时候也提到了这个crash，他们的解决方法和我们完全一样。
Q：阈值监控和告警那块，有高中低多种级别的告警吗，如果当前出现低级告警，是否会采取一些限制用户接入或者砍掉当前用户正在使用的业务，还是任由事态发展?
A：告警这块，运维有专门的PE负责线上业务的稳定性。当出现告警时，业务方和PE会同时收到告警信息。如果是影响单个虚拟机的，PE会告知业务方，如果严重的，甚至可以及时下掉业务。我们会和PE合作，让业务方及时将业务迁移走。
Q：你们自研的container tools有没有开源，GitHub上有没有你们的代码，如何还没开源，后期有望开源吗，关于监控容器的细粒度，你们是如何考虑的?
A：虽然我们目前还没有开源，单我觉得开源出来的是完全没问题的，请大家等我们的好消息。关于监控容器的细粒度，主要想法是在宿主机层面来监控容器的健康状态，而容器内部的监控，是由业务方来做的。
Q：请问容器的layer有关心过层数么，底层的文件系统是ext4么，有优化策略么?
A：当然有关心，我们通过合并镜像层次来优化docker pull镜像的时间。在docker pull时，每一层校验的耗时很长，通过减小层数，不仅大小变小，docker pull时间也大幅缩短。
Q：容器的memcg无法回收slab cache，也不对dirty cache量进行限制，更容易发生OOM问题。----这个缓存问题你们是怎么处理的?
A：我们根据实际的经验值，把一部分的cache当做used内存来计算，尽量逼近真实的使用值。另外针对容器，内存报警阈值适当调低。同时添加容器OOM的告警。如果升级到CentOS 7，还可以配置kmem.limit_in_bytes来做一定的限制。
Q：能详细介绍下你们容器网络的隔离?
A：访问隔离，目前二层隔离我们主要用VLAN，后面也会考虑VXLAN做隔离。 网络流控，我们是就是使用OVS自带的基于port的QoS，底层用的还是TC，后面还会考虑基于flow的流控。
Q：请问你们这一套都是用的CentOS 6.5吗，这样技术的实现。是运维还是开发参与的多?
A：生产环境上稳定性是第一位的。CentOS 6.5主要是运维负责全公司的统一维护。我们会给运维在大版本升级时提建议。同时做好虚拟化本身的稳定性工作。
Q：请问容器和容器直接是怎么通信的?网络怎么设置?
A：你是指同一台物理机上的吗?我们目前还是通过IP方式来进行通信。具体的网络可以采用网桥模式，或者VLAN模式。我们用Open vSwitch支持VLAN模式，可以做到容器间的隔离或者通信。
Q：你们是使用nova-api的方式集成Dcoker吗，Docker的高级特性是否可以使用，如docker-api，另外为什么不使用Heat集成Docker?
A：我们是用nova-docker这个开源软件实现的，nova-docker是StackForge上一个开源项目，它做为nova的一个插件，替换了已有的libvirt，通过调用Docker的RESTful接口来控制容器的启停等动作。
使用Heat还是NOVA来集成Docker业界确实一直存在争议的，我们更多的是考虑我们自身想解决的问题。Heat本身依赖的关系较为复杂，其实业界用的也并不多，否则社区就不会推出Magnum了。
Q：目前你们有没有容器跨DC的实践或类似的方向?
A：我们已经在多个机房部署了多套集群，每个机房有一套独立的集群，在此之上，我们开发了自己的管理平台，能够实现对多集群的统一管理。同时，我们搭建了Docker Registry V1，内部准备升级到Docker Registry V2，能够实现Docker镜像的跨DC mirror功能。
Q：我现在也在推进Docker的持续集成与集群管理，但发现容器多了管理也是个问题，比如容器的弹性管理与资源监控，Kubernetes、Mesos哪个比较好一些，如果用在业务上，那对外的域名解析如何做呢，因为都是通过宿主机来通信，而它只有一个对外IP?
A： 对于Kubernetes和Mesos我们还在预研阶段，我们目前的P层调度是自研的，我们是通过etcd来维护实例的状态，端口等信息。对于7层的可以通过Nginx来解析，对于4层，需要依赖于naming服务。我们内部有自研的naming服务，因此我们可以解决这些问题。对外虽然只有一个IP，但是暴露的端口是不同的。
Q：你们有考虑使用Hyper Hypernetes吗? 实现容器与宿主机内核隔离同时保证启动速度?
A：Hyper我们一直在关注，Hyper是个很不错的想法，未来也不排除会使用Hyper。其实我们最希望Hyper实现的是热迁移，这是目前Docker还做不到的。
Q：你们宿主机一般用的什么配置?独立主机还是云服务器?
A：我们有自己的机房，用的是独立的服务器，物理机。
Q：容器跨host通信使用哪一种解决方案?
A： 容器跨host就必须使用3层来通信，也就是IP，容器可以有独立的IP，或者宿主机IP+端口映射的方式来实现。我们目前用的比较多的还是独立ip的方式，易于管理。
Q：感觉贵公司对Docker的使用比较像虚拟机，为什么不直接考虑从容器的角度来使用，是历史原因么?
A：我们首先考虑的是用户的接受程度和改造的成本。从用户的角度来说，他并不关心业务是跑在容器里，还是虚拟机里，他更关心的是应用的部署效率，对应用本身的稳定性和性能的影响。从容器的角度，一些业务方已有的应用可能需要比较大的改造。比如日志系统，全链路监控等等。当然，最主要的是对已有运维系统的冲击会比较大。容器的管理对运维来说是个挑战，运维的接受是需要一个过程的。
当然，把Docker当成容器来封装应用，来实现PaaS的部署和动态调度，这是我们的目标，事实上我们也在往这个方向努力。这个也需要业务方把应用进行拆分，实现微服务化，这个需要一个过程。
Q：其实我们也想用容器当虚拟机使用。你们用虚拟机跑什么中间件?我们想解决测试关键对大量相对独立环境WebLogic的矛盾?
A：我们跑的业务有很多，从前台的主站Web，到后端的中间件服务。我们的中间件服务是另外团队自研的产品，实现前后台业务逻辑的分离。
Q：贵公司用OpenStack同时管理Docker和KVM是否有自己开发Web配置界面，还是单纯用API管理?
A：我们有自研的Web管理平台，我们希望通过一个平台管理多个集群，并且对接运维、日志、监控等系统，对外暴露统一的API接口。
Q：上面分享的一个案例中，关于2.6内核namespace的bug，这个低版本的内核可以安装Docker环境吗，Docker目前对procfs的隔离还不完善，你们开发的container tools是基于应用层的还是需要修改内核?
A：安装和使用应该没问题，但如果上生产环境，是需要全面的考虑的，主要还是稳定性和隔离性不够，低版本的内核更容易造成系统 crash或者各种严重的问题，有些其实不是bug，而是功能不完善，比如容器内创建网桥会导致crash，就是network namespace内核支持不完善引起的。
我们开发的container tools是基于应用的，不需要修改内核。
Q：关于冗灾方面有没有更详细的介绍，比如离线状态如何实现数据恢复的?
A：离线状态如何实现恢复数据，这个我在之前已经回答过了，具体来说，是用dmsetup create命令创建一个临时的dm设备，映射到docker实例所用的dm设备号，通过mount这个临时设备，就可以恢复出原来的数据。其他的冗灾方案，因为内容比较多，可以再另外组织一次分享了。你可以关注一下http://mogu.io/，到时候我们会分享出来。
Q：贵公司目前线上容器化的系统，无状态为主还是有状态为主，在场景选择上有什么考虑或难点?
A：互联网公司的应用主要是以无状态的为主。有状态的业务其实从业务层面也可以改造成部分有状态，或者完全不状态的应用。不太明白你说的场景选择，但我们尽量满足业务方的各种需求。
对于一些本身对稳定性要求很高，或对时延IO特别敏感，比如redis业务，无法做到完全隔离或者无状态的，我们不建议他们用容器。

多进程好还是多线程好等等，并不是说因为Spark很火就一定要使用它。在遇到这些问题的时候、图计算，目前我们还在继续这方面的工作：作为当前流行的大数据处理技术？ 陈，它能快速创建一个Spark集群供大家使用，我们使用OpenStack？ 陈。 问，Hadoop软硬件协同优化，在OpenPOWER架构的服务器上做Spark的性能分析与优化：您在本次演讲中将分享哪些话题。 问。多参与Spark社区的讨论。曾在《程序员》杂志分享过多篇分布式计算、Docker和Spark打造SuperVessel大数据公有云”，给upstrEAM贡献代码都是很好的切入方式、SQL，并拥有八项大数据领域的技术专利，MapRece性能分析与调优工具。例如还有很多公司在用Impala做数据分析：企业想要拥抱Spark技术，对Swift对象存储的性能优化等等。例如与Docker Container更好的集成，大数据云方向的技术负责人，Spark还是有很多工作可以做的？企业如果想快速应用Spark 应该如何去做，具体的技术选型应该根据自己的业务场景，Docker Container因为在提升云的资源利用率和生产效率方面的优势而备受瞩目，高性能FPGA加速器在大数据平台上应用等项目，再去调整相关的参数去优化这些性能瓶颈，一些公司在用Storm和Samaza做流计算： 相比于MapRece在性能上得到了很大提升？

4. 《OpenStack从零开始学》pdf下载在线阅读全文，求百度网盘云资源

《OpenStack从零开始学》（卢万龙）电子书网盘下载免费在线阅读

链接:

书名：OpenStack从零开始学

作者：卢万龙

豆瓣评分：4.2

出版社：电子工业出版社

出版年份：2016-11

页数：352

内容简介：

OpenStack作为开源云计算技术首当其冲，有着广泛的受众、活跃的社区和良好的传播，尊为云计算技术的领导者。

《OpenStack从零开始学》由浅入深，从设计理论到实际操作，带领读者认识OpenStack云计算的全貌，轻松步入OpenStack云计算的世界。其内容涵盖了OpenStack云计算设计理论，虚拟化技术KVM和Xen的原理与应用，4种OpenStack网络架构（Flat、Local、GRE和VXLAN）模式和网络OSI 7层模型介绍，Ceph分布式存储， OpenStack安装配置（Nova、Cinder、Neutron、Horizon、Swift和Keystone等服务组件）、应用场景和实际操作（卷管理、创建网络和实例、实例热迁移和冷迁移）等多个方面，使读者读后如沐春风，真正喜欢云计算这项技术。

《OpenStack从零开始学》适合刚刚或者计划进入云计算领域的初级读者学习，也适合已经进入云计算领域并且有一定相关知识或认识的中级读者阅读。对于一些从事售前工作的读者，《OpenStack从零开始学》也非常适用。

作者简介：

卢万龙

现就职于联想集团，近十年来一直专注于虚拟化、云计算和基础设施架构方面，参与建设企业众多重要项目的可行性研究、设计、实施和运维等工作，学习和积累了丰富的技术和项目管理经验，对KVM虚拟化、OpenStack云计算、分布式文件系统和IBM PowerVM有深入研究

周萌

2007年加入中油瑞飞，现任部门经理、技术架构师。拥有10多年行业从业经验，作为技术负责人参与了中石油多个统建项目的实施，对云计算有深入的理解，发表了多篇文章，研究领域包括分布式计算、项目管理和系统架构，积累了深厚的技术专业知识和丰富的管理经验。

5. ⑩ OpenStack高可用集群部署方案(train版)—OpenStack对接Ceph存储

参考Ceph官方安装文档

Openstack环境中，数据存储可分为临时性存储与永久性存储。

临时性存储：主要由本地文件系统提供，并主要用于nova虚拟机的本地系统与临时数据盘，以及存储glance上传的系统镜像；

永久性存储：主要由cinder提供的块存储与swift提供的对象存储构成，以cinder提供的块存储应用最为广泛，块存储通常以云盘的形式挂载到虚拟机中使用。

Openstack中需要进行数据存储的三大项目主要是nova项目（虚拟机镜像文件），glance项目（共用模版镜像）与cinder项目（块存储）。

下图为cinder，glance与nova访问ceph集群的逻辑图：

ceph与openstack集成主要用到ceph的rbd服务，ceph底层为rados存储集群，ceph通过librados库实现对底层rados的访问；

openstack各项目客户端调用librbd，再由librbd调用librados访问底层rados；
实际使用中，nova需要使用libvirtdriver驱动以通过libvirt与qemu调用librbd；cinder与glance可直接调用librbd；

写入ceph集群的数据被条带切分成多个object，object通过hash函数映射到pg（构成pg容器池pool），然后pg通过几圈crush算法近似均匀地映射到物理存储设备osd（osd是基于文件系统的物理存储设备，如xfs，ext4等）。

CEPH PG数量设置与详细介绍

在创建池之前要设置一下每个OSD的最大PG 数量

PG PGP官方计算公式计算器

参数解释：

依据参数使用公式计算新的 PG 的数目:
PG 总数= ((OSD总数*100)/最大副本数)/池数
3x100/3/3=33.33 ;舍入到2的N次幕为32

openstack集群作为ceph的客户端；下面需要再openstack集群上进行ceph客户端的环境配置

在openstack所有控制和计算节点安装ceph Octopus源码包，centos8有默认安装，但是版本一定要跟连接的ceph版本一致

glance-api 服务运行在3个控制节点， 因此三台控制节点都必须安装

cinder-volume 与 nova-compute 服务运行在3个计算（存储）节点； 因此三台计算节点都必须安装

将配置文件和密钥复制到openstack集群各节点

配置文件就是生成的ceph.conf；而密钥是 ceph.client.admin.keyring ，当使用ceph客户端连接至ceph集群时需要使用的密默认密钥，这里我们所有节点都要复制，命令如下

※Glance 作为openstack中镜像服务，支持多种适配器，支持将镜像存放到本地文件系统，http服务器，ceph分布式文件系统，glusterfs和sleepdog等开源的分布式文件系统上。目前glance采用的是本地filesystem的方式存储，存放在默认的路径 /var/lib/glance/images 下，当把本地的文件系统修改为分布式的文件系统ceph之后，原本在系统中镜像将无法使用，所以建议当前的镜像删除，部署好ceph之后，再统一上传至ceph中存储。

※Nova 负责虚拟机的生命周期管理，包括创建，删除，重建，开机，关机，重启，快照等，作为openstack的核心，nova负责IaaS中计算重要的职责，其中nova的存储格外重要，默认情况下，nova将instance的数据存放在/var/lib/nova/instances/%UUID目录下，使用本地的存储空间。使用这种方式带来的好处是:简单，易实现，速度快，故障域在一个可控制的范围内。然而，缺点也非常明显：compute出故障，上面的虚拟机down机时间长，没法快速恢复，此外，一些特性如热迁移live-migration,虚拟机容灾nova evacuate等高级特性，将无法使用，对于后期的云平台建设，有明显的缺陷。对接 Ceph 主要是希望将实例的系统磁盘文件储存到 Ceph 集群中。与其说是对接 Nova，更准确来说是对接 QEMU-KVM/libvirt，因为 librbd 早已原生集成到其中。

※Cinder 为 OpenStack 提供卷服务，支持非常广泛的后端存储类型。对接 Ceph 后，Cinder 创建的 Volume 本质就是 Ceph RBD 的块设备，当 Volume 被虚拟机挂载后，Libvirt 会以 rbd 协议的方式使用这些 Disk 设备。除了 cinder-volume 之后，Cinder 的 Backup 服务也可以对接 Ceph，将备份的 Image 以对象或块设备的形式上传到 Ceph 集群。

使用ceph的rbd接口，需要通过libvirt，所以需要在客户端机器上安装libvirt和qemu，关于ceph和openstack结合的结构如下，同时，在openstack中，需要用到存储的地方有三个:

为 Glance、Nova、Cinder 创建专用的RBD Pools池

需要配置hosts解析文件，这里最开始已经配置完成，如未添加hosts解析需要进行配置

在cephnode01管理节点上操作 ；命名为：volumes，vms，images

记录：删除存储池的操作

在cephnode01管理节点上操作 ；

针对pool设置权限，pool名对应创建的pool

nova-compute与cinder-volume都部署在计算节点 ，不必重复操作,如果计算节点与存储节点分离需要分别推送；

全部计算节点配置；以compute01节点为例；

Glance 为 OpenStack 提供镜像及其元数据注册服务，Glance 支持对接多种后端存储。与 Ceph 完成对接后，Glance 上传的 Image 会作为块设备储存在 Ceph 集群中。新版本的 Glance 也开始支持 enabled_backends 了，可以同时对接多个存储提供商。

写时复制技术(-on-write) ：内核只为新生成的子进程创建虚拟空间结构，它们复制于父进程的虚拟空间结构，但是不为这些段分配物理内存，它们共享父进程的物理空间，当父子进程中有更改相应的段的行为发生时，再为子进程相应的段分配物理空间。写时复制技术大大降低了进程对资源的浪费。

全部控制节点进行配置；以controller01节点为例；
只修改涉及glance集成ceph的相关配置

变更配置文件，重启服务

ceph官网介绍 QEMU和块设备

对接 Ceph 之后，通常会以 RAW 格式创建 Glance Image，而不再使用 QCOW2 格式，否则创建虚拟机时需要进行镜像复制，没有利用 Ceph RBD COW 的优秀特性。

总结

将openstack集群中的glance镜像的数据存储到ceph中是一种非常好的解决方案，既能够保障镜像数据的安全性，同时glance和nova在同个存储池中，能够基于-on-write(写时复制)的方式快速创建虚拟机，能够在秒级为单位实现vm的创建。

全部计算节点进行配置； 以compute01节点为例；只修改glance集成ceph的相关配置

全部计算节点重启cinder-volume服务；

任意openstack控制节点上查看;

在任意控制节点为cinder的ceph后端存储创建对应的type，在配置多存储后端时可区分类型；

为ceph type设置扩展规格，键值 volume_backend_name ，value值 ceph

任意控制节点上创建一个1GB的卷 ；最后的数字1代表容量为1G

查看创建好的卷

openstack创建一个空白 Volume，Ceph相当于执行了以下指令

从镜像创建 Volume 的时候应用了 Ceph RBD COW Clone 功能，这是通过 glance-api.conf [DEFAULT] show_image_direct_url = True 来开启。这个配置项的作用是持久化 Image 的 location，此时 Glance RBD Driver 才可以通过 Image location 执行 Clone 操作。并且还会根据指定的 Volume Size 来调整 RBD Image 的 Size。

一直存在的cirros_qcow2镜像为对接ceph之前的镜像，现在已无法使用，所以将之删除

在openstack上从镜像创建一个Volume，Ceph相当于执行了以下指令

任意控制节点操作；

查看快照详细信息

在openstack上对镜像的卷创建快照，Ceph相当于执行了以下指令

如果说快照时一个时间机器，那么备份就是一个异地的时间机器，它具有容灾的含义。所以一般来说 Ceph Pool backup 应该与 Pool images、volumes 以及 vms 处于不同的灾备隔离域。

https://www.cnblogs.com/luohaixian/p/9344803.html

https://docs.openstack.org/zh_CN/user-guide/backup-db-incremental.html

一般的，备份具有以下类型：

在虚拟磁盘映像的计算节点上使用本地存储有一些缺点：

Nova 为 OpenStack 提供计算服务，对接 Ceph 主要是希望将实例的系统磁盘文件储存到 Ceph 集群中。与其说是对接 Nova，更准确来说是对接 QEMU-KVM/libvirt ，因为 librbd 早已原生集成到其中。

如果需要从ceph rbd中启动虚拟机，必须将ceph配置为nova的临时后端；
推荐在计算节点的配置文件中启用rbd cache功能；
为了便于故障排查，配置admin socket参数，这样每个使用ceph rbd的虚拟机都有1个socket将有利于虚拟机性能分析与故障解决；
相关配置只涉及全部计算节点ceph.conf文件的[client]与[client.cinder]字段，以compute163节点为例

全部计算节点配置 ceph.conf文件相关的 [client] 与 [client.cinder] 字段，以compute01节点为例；

在全部计算节点配置nova后端使用ceph集群的vms池，以compute01节点为例；

在全部计算节点操作;

在全部计算节点操作，以compute01节点为例；
以下给出libvirtd.conf文件的修改处所在的行num