初识Opensatck_2

(Updated: )
,

前一篇文章过了一遍权限服务和虚拟机映像服务, 而且都是在控制节点上进行的. 现在终于要开始部署计算服务了, 想想都激动.

Nova

为了了解Nova是如何工作的, 我们先看下这个逻辑架构图的Nova部分:

Nova-arch

可以看到, 其中最重要, 和大部分的组件都产生关系的组件就是这个Queue了. 官方文档称呼这个东西叫做central hub, 都已经central了能不重要吗哈哈. 这个队列主要是在各种daemon中传递消息的, 通常使用的是RabbitMQ.

然后我们从最外面开始看, 这里唯一和外界打交道的就是nova-api了, 它是用来接受和响应终端用户的计算API调用的. 与之配合的, 上图中没有列出的一个组件是nova-api-metadata service, 听名字就知道了, 这个东西是用来接受来自实例的源数据请求的.

接着是调度器组件–Nova-scheduler.

值得一提的是, 在Nova中原本有一个Placement API, 参与到scheduler的调度流程当中, 原本是一个可选的功能, 到了P版本的时候要求强制开启. 渐渐地, 在18年的年末, Placement API开始从nova项目中剥离, 渐渐地成为Openstack Placement, 期待最终替代nova-scheduler. 计划在S版本中成为一个独立的项目. 但是目前(这里用的是Q版本), 我们在配置的时候已经有点要单独看待的意思了.

这个东西从队列中取出外部对虚拟机实例的请求然后来决定交给哪一个host来运行. 那么如何运行呢, 这就要交给Nova的另一个核心组件也就是计算服务了. Nova compute是一个用来创建和终止虚拟机实例的工作进程, 例如:

  • 使用Xen的XenAPI
  • 使用KVM或者是QEMU的libvirt API
  • 使用VMware的VMwareAPI

根据虚拟机平台不同, 所使用到的HyperVisor API也不同. 然后再虚拟机启动之后把他在数据库中存储的状态进行update.

那就奇怪了, 上面的架构图中, 计算服务似乎并没和数据库进行直接的交互. 没错, 负责协调引领计算节点和数据库交互的模块就是conductor module.

Nova的配置 - 控制节点和计算节点

我们按照官方文档的说明, 对控制节点和计算节点的Nova服务进行配置, 然后进行安装验证. 下面说下我遇到的问题:

安装和配置完成之后, 惊奇的发现不停的报503和401错误, 原因大概率可能是因为配置文件里面的密码写错了, 另外, 如果密码参数是空白的话, 也会报错.

我之前在说glance的时候说这个配置项在官方文档已经找不到了, 但是如果不在里面写上的话, 一些服务注册发现会遇到授权错误导致失败, 也即是401 Unauthorized错误的原因. 所以还是要写上的.

如果配置完成我们会运行一个 nova-status upgrade check来检查问题.

这里再记录一个奇妙的事情, 我在执行这个check的时候发现一个Warning提示:

1
2
3
4
5
6
7
8
| Check: Resource Providers                                           |
| Result: Warning                                                     |
| Details: There are 1 compute resource providers and 2 compute nodes |
|   in the deployment. Ideally the number of compute resource         |
|   providers should equal the number of enabled compute nodes        |
|   otherwise the cloud may be underutilized. See                     |
|   https://docs.openstack.org/nova/latest/user/placement.html        |
|   for more details.                                                 |

另外我也发现在使用compute列举服务的时候, 出现了重复的ID:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
[root@controller ~]# openstack compute service list
+----+------------------+-------------------------------+----------+---------+-------+----------------------------+
| ID | Binary           | Host                          | Zone     | Status  | State | Updated At                 |
+----+------------------+-------------------------------+----------+---------+-------+----------------------------+
|  1 | nova-scheduler   | control_node                  | internal | enabled | down  | 2019-03-19T05:49:25.000000 |
|  2 | nova-consoleauth | control_node                  | internal | enabled | down  | 2019-03-19T05:49:31.000000 |
|  3 | nova-conductor   | control_node                  | internal | enabled | down  | 2019-03-19T05:49:32.000000 |
|  8 | nova-compute     | compute_node1                 | nova     | enabled | up    | 2019-03-21T01:23:00.000000 |
|  9 | nova-consoleauth | controller.rjjc.comcontroller | internal | enabled | up    | 2019-03-21T01:23:01.000000 |
| 10 | nova-scheduler   | controller.rjjc.comcontroller | internal | enabled | up    | 2019-03-21T01:22:56.000000 |
| 11 | nova-conductor   | controller.rjjc.comcontroller | internal | enabled | up    | 2019-03-21T01:22:57.000000 |
|  1 | nova-scheduler   | control_node                  | internal | enabled | down  | 2019-03-19T05:49:25.000000 |
|  2 | nova-consoleauth | control_node                  | internal | enabled | down  | 2019-03-19T05:49:31.000000 |
|  3 | nova-conductor   | control_node                  | internal | enabled | down  | 2019-03-19T05:49:32.000000 |
|  8 | nova-compute     | compute_node1                 | nova     | enabled | up    | 2019-03-21T01:23:00.000000 |
|  9 | nova-consoleauth | controller.rjjc.comcontroller | internal | enabled | up    | 2019-03-21T01:23:01.000000 |
| 10 | nova-scheduler   | controller.rjjc.comcontroller | internal | enabled | up    | 2019-03-21T01:22:56.000000 |
| 11 | nova-conductor   | controller.rjjc.comcontroller | internal | enabled | up    | 2019-03-21T01:22:57.000000 |
+----+------------------+-------------------------------+----------+---------+-------+----------------------------+

然后google了很久都说是把数据库改一下就好了, 但是神奇的是进去之后发现并没有重复的compute节点, 于是我就把数据库洗掉了重新生成了一次, 这一次就好了, 想要尝试复现这个情况的时候也没成功. 所以就先当做是一个奇怪的现象记录在这里.

配置好了Nova之后我们就可以开始着手搭建最小化openstack的最后一步了, 来构建网络服务. 代码名为**neutron**.

Neutron

先来了解一下Openstack的两种网络选项, 分别叫做Provider Networks和Self-Service Networks.

其中前者主要就只有2层, 他把虚拟的网络通过桥接的方式连接到物理网络上, 然后依赖物理网络上的第三层服务(路由). 至于后者, 使用到的技术就是NAT, 所以显然, 这个网络选项是含有第三层服务的.

接下来就来看看Openstack的网络组件Neutron的相关, 这个服务主要包含三个组件:

  • neutron-server 用于接受和路由访问请求到合适的Openstack网络插件
  • Openstack Networking plug-ins and agents 这个就是上面提到的网络插件了, 比如思科, vSwitch, Linux bridging, VMware NSX等等; 这里常见的agent例如第三层代理, DHCP等等
  • Messaging Queue 最后一个就不用过多介绍了, 主要负责agent和server之间的消息传递.

现在我们来说说关于neutron和Openstack网络一些概念, 作为一个网络服务就是需要提供对于网络, 子网, 路由器等等的对象抽象. 对于一个给定的网络, 需要设立至少一个外部网络, 这个外部网络不仅仅是一个虚拟定义网络, 而是一个在Openstack范围之外可以访问到的物理的外部网络, 只要是在这么一个外部的网络中, 任何人都可以物理的访问到. 除了外部网络 , 每一个Neutron定义的网络还需要有一至多个内部网络, 这些软件定义网络直接连接到虚拟机, 在这么一个网络中, 只有给定这些网络和子网的虚拟机之间可以通过这些网络直接访问.

另外, 在Openstack的网络概念中, 还有一个叫做安全组的东西. 熟悉吧, 我们在腾讯云阿里云操作云主机的时候就遇到这个概念了, 所谓安全组其实就是防火墙规则, 一个虚拟机可以被关联到一至多个安全组.

对于Neutron网络中的另一个重要组成部分 – 插件, 每一个网络插件都有他自己的概念, 因此这种就只能遇到在说了.

Neutron的配置

巨大的坑: 主机名不能带下划线!

这种事情给你就应该在一开始说一下嘛! 如果主机名携带下划线, 就会导致linuxbridge服务启动失败, 并且systemctl不会给你错误返回值! 需要你自己去看日志.

其他的照着官方那个文档做就没问题.

配置完了Nova和Neutron之后, 一个最小化的Openstack就完成了

接下来为了更方便的使用, 我们可以构建horizon.

Horizon

Horizon就是Openstack的前端dashboard了. 使用的Django进行的开发, 配置使用起来十分容易:

dashboard1

但是现在还不能直接通过镜像启动实例, 因为我们还有一些必要的配置项没有搞. 但是现在这么一个基础的服务框架已经建立, 接下来因为时间和进度的关系, 我会暂时放下Openstack转而学习Docker的基础, 最后再来学习将两者统一起来的项目Zun或者Magnum.