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