0%

环境

安装系统

最小化安装一个操作系统,这里选择 CentOS 7。

安装 git:

1
yum install -y git

网络

controller:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# vim /etc/sysconfig/network-scripts/ifcfg-enp4s0

TYPE="Ethernet"
PROXY_METHOD="none"
BROWSER_ONLY="no"
BOOTPROTO="none"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"
IPV6_ADDR_GEN_MODE="stable-privacy"
NAME="enp4s0"
UUID="ccf32c18-b4a6-40b8-ae09-06dc4148d42f"
DEVICE="enp4s0"
ONBOOT="yes"
IPADDR="192.168.0.201"
PREFIX="24"
GATEWAY="192.168.0.1"
DNS1="210.41.224.33"
DNS2="192.168.5.1"
IPV6_PRIVACY="no"

compute01:

1
IPADDR="192.168.0.202"

compute02:

1
IPADDR="192.168.0.202"

安装 shake 和 bake

添加 DevStack 用户

每个节点都要使用同样的名字。

1
useradd -s /bin/bash -d /opt/stack -m stack

stack 用户会对系统造成很大的改变,需要无密码的 sudo 权限:

1
echo "stack ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers

现在开始使用 stack 用户,退出并以 stack 登录:

1
su - stack

设置 SSH

在每个节点上设置 stack 用户具有 ssh 权限:

1
2
mkdir ~/.ssh; chmod 700 ~/.ssh
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCyYjfgyPazTvGpd8OaAvtU2utL8W6gWC4JdRS1J95GhNNfQd657yO6s1AH5KYQWktcE6FO/xNUC2reEXSGC7ezy+sGO1kj9Limv5vrvNHvF1+wts0Cmyx61D2nQw35/Qz8BvpdJANL7VwP/cFI/p3yhvx2lsnjFE3hN8xRB2LtLUopUSVdBwACOVUmH2G+2BWMJDjVINd2DPqRIA4Zhy09KJ3O1Joabr0XpQL0yt/I9x8BVHdAx6l9U0tMg9dj5+tAjZvMAFfye3PJcYwwsfJoFxC8w/SLtqlFX7Ehw++8RtvomvuipLdmWCy+T9hIkl+gHYE4cS3OIqXH7f49jdJf jesse@spacey.local" > ~/.ssh/authorized_keys

下载 devstack 脚本

下载最新版本的 devstack:

1
2
git clone https://git.openstack.org/openstack-dev/devstack
cd devstack

到目前为止,所有的步骤都适用于所有节点。从现在开始,控制节点和计算节点之间会有一些不同。

配置控制节点

控制节点运行 OpenStack 所有的服务,在 devstack 下创建 local.conf:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[stack@contorller devstack]$ vim local.conf

[[local|localrc]]
HOST_IP=192.168.0.211
FLAT_INTERFACE=ens33
FIXED_RANGE=10.4.128.0/20
FIXED_NETWORK_SIZE=4096
FLOATING_RANGE=192.168.0.220/29
MULTI_HOST=1
LOGFILE=/opt/stack/logs/stack.sh.log
ADMIN_PASSWORD=root
DATABASE_PASSWORD=root
RABBIT_PASSWORD=root
SERVICE_PASSWORD=root

在多节点配置中,私有子网的前十个 IP 通常保留,运行完 stack.sh 脚本之后运行:

1
for i in `seq 2 10`; do /opt/stack/nova/bin/nova-manage fixed reserve 10.4.128.$i; done

开始安装:

1
./stack.sh

配置计算节点

计算节点只运行工作服务,对其他的机器,创建 local.conf:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
[[local|localrc]]
HOST_IP=192.168.0.212 # change this per compute node
FLAT_INTERFACE=ens33
FIXED_RANGE=10.4.128.0/20
FIXED_NETWORK_SIZE=4096
FLOATING_RANGE=192.168.0.220/29
MULTI_HOST=1
LOGFILE=/opt/stack/logs/stack.sh.log
ADMIN_PASSWORD=root
DATABASE_PASSWORD=root
RABBIT_PASSWORD=root
SERVICE_PASSWORD=root
DATABASE_TYPE=mysql
SERVICE_HOST=192.168.0.211
MYSQL_HOST=$SERVICE_HOST
RABBIT_HOST=$SERVICE_HOST
GLANCE_HOSTPORT=$SERVICE_HOST:9292
ENABLED_SERVICES=n-cpu,q-agt,n-api-meta,c-vol,placement-client
NOVA_VNC_ENABLED=True
NOVNCPROXY_URL="http://$SERVICE_HOST:6080/vnc_auto.html"
VNCSERVER_LISTEN=$HOST_IP
VNCSERVER_PROXYCLIENT_ADDRESS=$VNCSERVER_LISTEN

开始安装:

1
./stack.sh

当每个计算节点都安装完毕之后,验证它的输出:

1
nova service-list --binary nova-compute

当计算节点的服务出现之后,控制节点上运行:

1
./tools/discover_hosts.sh

来发现服务。

最终安装失败。

Ubuntu server 安装及配置

安装注意事项

使用 ubuntu-16.04.3-server-amd64 来进行安装,如果是虚拟化环境,需要启用嵌套虚拟化的选项。

安装语言最好选择英文,不然会报错,提示说“无法安装busybox-initramfs”。

因为在虚拟机中安装,组件安装要勾选上 Virtual Machine host、OpenSSH server 两个选项。

配置

系统中自带了 vim、screen 等,不必重新安装。

  1. 修改 IP 地址
1
2
3
4
5
6
7
$ sudo vim /etc/network/interfaces

auto ens33
iface ens33 inet static
address 192.168.0.141
netmask 255.255.255.0
gateway 192.168.0.1
  1. 修改 DNS 配置
1
2
3
4
$ sudo vim /etc/resolvconf/resolv.conf.d/base

nameserver 210.41.224.33
nameserver 192.168.5.1
  1. 修改安装源

此步骤是为了提高安装速度,非必要。

多次安装不成功,均网速的问题。安装的过程,需要考虑从三类位置下载软件:

  • OpenStack
  • Ubuntu
  • Python

OpenStack:一直没有找到合适稳定的镜像站点。

Ubuntu:

1
2
3
4
5
6
7
$ sudo vim /etc/apt/sources.list

在文件头部添加
deb mirror://mirrors.ubuntu.com/mirrors.txt xenial main restricted universe multiverse
deb mirror://mirrors.ubuntu.com/mirrors.txt xenial-updates main restricted universe multiverse
deb mirror://mirrors.ubuntu.com/mirrors.txt xenial-backports main restricted universe multiverse
deb mirror://mirrors.ubuntu.com/mirrors.txt xenial-security main restricted universe multiverse

Python:测试了一下豆瓣 pip 镜像站点速度比较快。

1
2
3
4
5
6
$ sudo mkdir /root/.pip/
$ sudo vim /root/.pip/pip.conf

添加如下内容
[global]
index-url = https://pypi.douban.com/simple
  1. 执行更新
1
2
$ sudo apt-get update
$ sudo apt-get upgrade

安装 OpenStack

添加 stack 用户

1
2
3
$ sudo useradd -s /bin/bash -d /opt/stack -m stack # -s:指定shell -d:指定家目录 -m:创建目录
$ echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/stack
$ sudo su - stack # 切换到 stack 用户

下载 devstack 脚本

1
2
3
4
5
6
$ sudo pwd
/opt/stack

$ time git clone https://git.openstack.org/openstack-dev/devstack -b stable/ocata
备份脚本
$ tar zcf devstack20170531.tar.gz devstack

创建配置文件 local.conf

1
2
3
4
5
6
7
8
9
10
$ id
$ cd devstack
$ vi local.conf

[[local|localrc]]
ADMIN_PASSWORD=root
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
secret 是初始密码,可以根据需要设置自已的密码。

开始安装

以 stack 的身份执行以下命令

1
$ time ./stack.sh 

结果如下:

日志位置

日志一般存放在 /var/log/...

日志格式

OpenStack 的日志格式都是统一的,如下:

<时间戳><日志等级><代码模块><日志内容><源代码位置>

  • 时间戳

    日志记录的时间,包括 年 月 日 时 分 秒 毫秒

  • 日志等级

    有INFO WARNING ERROR DEBUG等

  • 代码模块

    当前运行的模块

  • Request ID

    日志会记录连续不同的操作,为了便于区分和增加可读性,每个操作都被分配唯一的Request ID,便于查找日志内容 这是日志的主体,记录当前正在执行的操作和结果等重要信息

  • 源代码位置

    日志代码的位置,包括方法名称,源代码文件的目录位置和行号。这一项不是所有日志都有

1
2015-12-10 20:46:49.566 DEBUG nova.virt.libvirt.config [req-5c973fff-e9ba-4317-bfd9-76678cc96584 None None] Generated XML ('<cpu>\n  <arch>x86_64</arch>\n  <model>Westmere</model>\n  <vendor>Intel</vendor>\n  <topology sockets="2" cores="3" threads="1"/>\n  <feature name="avx"/>\n  <feature name="ds"/>\n  <feature name="ht"/>\n  <feature name="hypervisor"/>\n  <feature name="osxsave"/>\n  <feature name="pclmuldq"/>\n  <feature name="rdtscp"/>\n  <feature name="ss"/>\n  <feature name="vme"/>\n  <feature name="xsave"/>\n</cpu>\n',) to_xml /opt/stack/nova/nova/virt/libvirt/config.py:82

这条日志我们可以得知:

  1. 代码模块是 nova.virt.libvirt.config,由此可知应该是 Hypervisor Libvirt 相关的操作
  2. 日志内容是生成 XML
  3. 如果要跟踪源代码,可以到 /opt/stack/nova/nova/virt/libvirt/config.py 的 82 行,方法是 to_xml

Nova组件详解

nova-api

nova-api 是 nova 组件的门户,所有对 nova 的请求都首先由 nova-api 处理,nova 对外暴露几个接口,也就是 endpoint,查看 endpoint:

1
openstack endpoint show nova

nova-api 对接收到的请求会做如下操作:

  1. 检查传递的参数是否合法
  2. 调用 nova 的其他子服务来处理请求
  3. 格式化其他子服务返回的结果并返回给客户端

nova-api 可以接受哪些请求?
简单来说,只要是与虚拟机生命周期管理相关的操作,nova-api 都可以相应,大部分的操作在 dashboard 上面都可以找到,如图所示:

nova-4

nova-conductor

nova-compute 需要访问数据库获取 instance 的信息,但是 nova-compute 不会直接访问数据库,需要通过 nova-conductor 实现数据的访问。

nova-5

这样做有两个好处:

  1. 更好的系统安全性
  2. 更好的系统伸缩性
  • 更好的系统安全性

在 OpenStack 的早期版本中,nova-compute 可以直接访问数据库,但这样存在非常大的安全隐患。 因为 nova-compute 这个服务是部署在计算节点上的,为了能够访问控制节点上的数据库,就必须在计算节点的 /etc/nova/nova.conf 中配置访问数据库的连接信息,比如

1
2
[database]
connection = mysql+pymysql://root:secret@controller/nova?charset=utf8

试想任意一个计算节点被黑客入侵,都会导致部署在控制节点上的数据库面临极大风险。为了解决这个问题,从 G 版本开始,Nova 引入了一个新服务 nova-conductor,将 nova-compute 访问数据库的全部操作都放到 nova-conductor 中,而且 nova-conductor 是部署在控制节点上的。 这样就避免了 nova-compute 直接访问数据库,增加了系统的安全性。

  • 更好的伸缩性

nova-conductor 将 nova-compute 与数据库解耦之后还带来另一个好处:提高了 nova 的伸缩性。nova-compute 与 conductor 是通过消息中间件交互的。

这种松散的架构允许配置多个 nova-conductor 实例。 在一个大规模的 OpenStack 部署环境里,管理员可以通过增加 nova-conductor 的数量来应对日益增长的计算节点对数据库的访问。

nova-scheduler

在 /etc/nova/nova.conf 中,nova 通过 scheduler_driver、scheduler_available_filters、scheduler_default_filters 来配置 nova-scheduler。

filter_scheduler

filter_scheduler 是 nova-scheduler 默认的调度器,调度过程分为两步:

  1. 通过 filter 选择满足条件的计算节点(运行 nova-compute)
  2. 通过权重计算(weighting)选择在最优的计算节点上创建 instance

img

调度过程

Filter

当 filter-scheduler 需要执行调度操作时,会让 filter 对计算节点进行判断,filter 返回 True 或 False。Nova.conf 中的 scheduler_available_filters 选项用于配置 scheduler 可用的 filter,默认是所有 nova 自带的 filter 都可以用于滤操作。

1
scheduler_available_filters = nova.scheduler.filters.all_filters

另外还有一个选项 scheduler_default_filters,用于指定 scheduler 真正使用的 filter,默认值如下

1
scheduler_default_filters = RetryFilter, AvailabilityZoneFilter, RamFilter, DiskFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter

RetryFilter

RetryFilter 的作用是过滤掉已经调度过的节点,比如上次选择部署在计算节点 A 上面,但是由于某种原因失败了,那么这次就不会再部署。

AvailabilityZoneFilter

为提高容灾性和提供隔离服务,可以将计算节点划分到不同的Availability Zone中。例如把一个机架上的机器划分在一个 Availability Zone 中。 OpenStack 默认有一个命名为 “Nova” 的 Availability Zone,所有的计算节点初始都是放在 “Nova” 中。 用户可根据需要创建自己的 Availability Zone。nova-scheduler 会将不属于指定 AvailableZone 的计算节点过滤掉。

RamFilter

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

对于内存有一点需要注意: 为了提高系统的资源使用率,OpenStack 在计算节点可用内存时允许 overcommit,也就是可以超过实际内存大小。 超过的程度是通过 nova.conf 中 ram_allocation_ratio 这个参数来控制的,默认值为 1.5

1
ram_allocation_ratio = 1.5

其含义是:如果计算节点的内容为 10GB,OpenStack 则会认为它有 15GB(10*1.5)内存。

DiskFilter

DiskFilter 将不能满足 flavor 磁盘需求的计算节点过滤掉。Disk 同样允许 overcommit,通过 nova.conf 中 disk_allocation_ratio 控制,默认值为 1

1
disk_allocation_ratio = 1.0

CoreFilter

CoreFilter 将不能满足 flavor vCPU 需求的计算节点过滤掉。vCPU 同样允许 overcommit,通过 nova.conf 中 cpu_allocation_ratio 控制,默认值为 16

1
cpu_allocation_ratio = 16.0

ComputeFilter

ComputeFilter 保证只有 nova-compute 服务正常工作的计算节点才能够被 nova-scheduler调度。ComputeFilter 显然是必选的 filter。

ComputeCapabilitiesFilter

ComputeCapabilitiesFilter 根据计算节点的特性来筛选。这个比较高级,我们举例说明。
例如我们的节点有 x86_64 和 ARM 架构的,如果想将 Instance 指定部署到 x86_64 架构的节点上,就可以利用 ComputeCapabilitiesFilter。还记得 flavor 中有个 Metadata 吗,Compute 的 Capabilitie s就在 Metadata中 指定。

ImagePropertiesFilter

ImagePropertiesFilter 根据所选 image 的属性来筛选匹配的计算节点。 跟 flavor 类似,image 也有 metadata,用于指定其属性。

例如希望某个 image 只能运行在 kvm 的 hypervisor 上,可以通过 “Hypervisor Type” 属性来指定。

ServerGroupAntiAffinityFilter

ServerGroupAntiAffinityFilter 可以尽量将 Instance 分散部署到不同的节点上。

例如有 inst1,inst2 和 inst3 三个 instance,计算节点有 A,B 和 C。 为保证分散部署,进行如下操作:

  1. 创建一个 anti-affinity 策略的 server group “group-1”
1
nova server-group-create --policy anti-affinity group-1

请注意,这里的 server group 其实是 instance group,并不是计算节点的 group。

  1. 依次创建 Instance inst1, inst2和inst3并放到group-1中
1
2
3
nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst1
nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst2
nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst3

因为 group-1 的策略是 AntiAffinity,调度时 ServerGroupAntiAffinityFilter 会将 inst1, inst2 和 inst3 部署到不同计算节点 A, B 和 C。目前只能在 CLI 中指定 server group 来创建 instance。

创建 instance 时如果没有指定 server group,ServerGroupAntiAffinityFilter 会直接通过,不做任何过滤。

ServerGroupAffinityFilter

与 ServerGroupAntiAffinityFilter 的作用相反,ServerGroupAffinityFilter 会尽量将 instance 部署到同一个计算节点上。 方法类似

  1. 创建一个 affinity 策略的 server group “group-2”
1
nova server-group-create --policy affinity group-2
  1. 依次创建 instance inst1, inst2 和 inst3 并放到 group-2 中
1
2
3
nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst1
nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst2
nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst3

因为 group-2 的策略是 Affinity,调度时 ServerGroupAffinityFilter 会将 inst1, inst2 和 inst3 部署到同一个计算节点。创建 instance 时如果没有指定 server group,ServerGroupAffinityFilter 会直接通过,不做任何过滤。

weight

通过过滤之后会计算权重值,根据计算节点空闲内存来计算权重值,内存越多,权重值越大。

日志

1
/var/log/nova/scheduler.log

注:要显示 DEBUG 日志,需要在 /etc/nova/nova.conf 中打开 debug 选项

1
2
[DEFAULT]
debug = True

nova-compute

nova-compute 通过 Driver架构支持多种 Hypervisor。

我们可以在 /opt/stack/nova/nova/virt/ 目录下查看到 OpenStack 源代码中已经自带了上面这几个 Hypervisor 的 Driver:

某个特定的计算节点上只会运行一种 Hypervisor,只需在该节点 nova-compute 的配置文件 /etc/nova/nova.conf 中配置所对应的 compute_driver 就可以了。

nova-compute 的功能可以分为两类:

  1. 定时向 OpenStack 报告计算节点的状态
  2. 实现 instance 生命周期的管理

定时向 OpenStack 报告计算节点的状态

前面我们看到 nova-scheduler 的很多 Filter 是根据算节点的资源使用情况进行过滤的。比如 RamFilter 要检查计算节点当前可以的内存量;CoreFilter 检查可用的 vCPU 数量;DiskFilter 则会检查可用的磁盘空间。

那这里有个问题:OpenStack 是如何得知每个计算节点的这些信息呢?答案是 nova-compute 会定期向 OpenStack 报告。

nova-compute 是如何获得当前计算节点的资源使用信息的?nova-compute 可以通过 Hypervisor 的 driver 拿到这些信息。

实现 instance 生命周期的管理

OpenStack 对 instance 最主要的操作都是通过 nova-compute 实现的,包括 instance 的 launch、shutdown、reboot、suspend、resume、terminate、resize、migration、snapshot 等。

本节讨论实例的创建操作。

nova-compute 创建 instance 的过程可以分为 4 步:

  1. 为 instance 准备资源
  2. 创建 instance 的镜像文件
  3. 创建 instance 的 XML 定义文件
  4. 创建虚拟网络并启动虚拟机

为 instance 准备资源

nova-compute 首先会根据指定的 flavor 依次为 instance 分配内存、磁盘空间和 vCPU。可以在日志中看到这些细节。

网络资源也会提前分配。

创建 instance 的镜像文件

OpenStack 启动一个 instance 时,会选择一个 image,这个 image 由 Glance 管理。 nova-compute会:

  1. 首先将该 image 下载到计算节点
  2. 然后将其作为 backing file 创建 instance 的镜像文件

从 Glance 下载 image

nova-compute 首先会检查 image 是否已经下载(比如之前已经创建过基于相同 image 的 instance)。如果没有,就从 Glance 下载 image 到本地。由此可知,如果计算节点上要运行多个相同 image 的 instance,只会在启动第一个 instance 的时候从 Glance 下载 image,后面的 instance 启动速度就大大加快了。

可以看到:

  1. image(ID为 917d60ef-f663-4e2d-b85b-e4511bb56bc2)是 qcow2 格式,nova-compute 将其下载。Nova 默认会通过 qemu-img 转换成 raw 格式,以提高 IO 性能。
  2. image 的存放目录是 /opt/stack/data/nova/instances/_base,这是由 /etc/nova/nova.conf 的下面两个配置选项决定的。
1
2
instances_path = /opt/stack/data/nova/instances
base_dir_name = _base
  1. 下载的 image 文件被命名为 60bba5916c6c90ed2ef7d3263de8f653111dd35f,这是 image id 的 SHA1 哈希值。

为 instance 创建镜像文件

有了 image 之后,instance 的镜像文件直接通过 qemu-img 命令创建,backing file 就是下载的 image。

http://7xo6kd.com1.z0.glb.clouddn.com/upload-ueditor-image-20160501-1462109263590069817.png

可以通过 qume-info 查看 disk 文件的属性:

http://7xo6kd.com1.z0.glb.clouddn.com/upload-ueditor-image-20160501-1462109267370087342.png

这里有两个容易搞混淆的术语,在此特别说明一下:

  1. image,指的是 Glance 上保存的镜像,作为 instance 运行的模板。 计算节点将下载的 image 存放在 /opt/stack/data/nova/instances/_base 目录下。
  2. 镜像文件,指的是 instance 启动盘所对应的文件
  3. 二者的关系是:image 是镜像文件 的 backing file。image 不会变,而镜像文件会发生变化。比如安装新的软件后,镜像文件会变大。

创建 instance 的 XML 定义文件

创建的 XML 文件会保存到该 instance 目录 /opt/stack/data/nova/instances/f1e22596-6844-4d7a-84a3-e41e6d7618ef,命名为 libvirt.xml

创建虚拟网络并启动 instance

http://7xo6kd.com1.z0.glb.clouddn.com/upload-ueditor-image-20160501-1462109268755029101.png

本环境用的是 linux-bridge 实现的虚拟网络。

CLI 查看实例:

1
virsh list

nova架构

nova-f9ad05cc-94a8-408b-90dd-4863227bd681

nova组件

可分为以下几类

api

nova-api

接收和响应客户的 API 调用。 除了提供 OpenStack 自己的API,nova-api 还支持 Amazon EC2 API。

compute core

nova-scheduler

虚机调度服务,负责决定在哪个计算节点上运行虚机

nova-compute

管理虚机的核心服务,通过调用 Hypervisor API 实现虚机生命周期管理

Hypervisor

计算节点上跑的虚拟化管理程序,虚机管理最底层的程序。 不同虚拟化技术提供自己的 Hypervisor。 常用的 Hypervisor 有 KVM,Xen, VMWare 等

nova-conductor

nova-compute 经常需要更新数据库,比如更新虚机的状态。 出于安全性和伸缩性的考虑,nova-compute 并不会直接访问数据库,而是将这个任务委托给 nova-conductor,这个我们后面详细讨论。

Console Interface

nova-console

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

nova-consoleauth

负责对访问虚机控制台请亲提供 Token 认证

nova-cert

提供 x509 证书支持

Database

Nova 会有一些数据需要存放到数据库中,一般使用 MySQL。

数据库安装在控制节点上。 Nova 使用命名为 “nova” 的数据库。

Message Queue

在前面我们了解到 Nova 包含众多的子服务,这些子服务之间需要相互协调和通信。

为解耦各个子服务,Nova 通过 Message Queue 作为子服务的信息中转站。所以在架构图上我们看到了子服务之间没有直接的连线,是通过 Message Queue 联系的。

Nova组件如何协同工作

1、只有nova-compute组件需要安装在计算节点上

2、可以使用命令查看nova组件分别安装在哪些节点上

1
nova service-list

3、虚拟机创建流程:

客户向 api 发送请求,api 传递给消息队列,消息队列通知 scheduler,scheduler 通过调度算法确定在哪一台虚拟机上面创建,发消息给消息队列,消息队列通知该计算节点的 compute 组件,compute 创建虚拟机,发送消息给消息队列,消息队列传递给 conductor 组件,conductor 组件写入更新数据库。

nova-2

OpenStack通用设计思路

  1. 每一个 OpenStack 组件都通过 api 对外提供服务,还可以运行多个 api 实现高可用。

  2. 对于某项操作,如果有多个实体能够完成任务,那么一般都会有 scheduler 调度服务,如 nova、cinder。

  3. worker 工作服务:如 nova 的nova-compute服务,如果调度不过来那么可以增加scheduler服务,如果计算资源不够可以增加计算节点。

  4. 采用基于 driver 的框架。 以 nova 为例,OpenStack 的计算节点支持多种 Hypervisor。 包括 KVM, Hyper-V, VMWare, Xen, Docker, LXC 等。 nova-compute 为这些 Hypervisor 定义了统一的接口,Hypervisor 只需要实现这些接口,就可以 driver 的形式即插即用到 OpenStack 中。

    nova-3

    配置文件 /etc/nova/nova.conf 中由 compute_driver 配置项指定该计算节点使用哪种 Hypervisor 的 driver。glance 支持多种存储后端,也是一种 driver 架构,cinder、neutron 都是。

  5. 消息队列服务。将每一个服务解耦,实现异步调用。

  6. database。每一个服务的状态信息都在数据库中维护。