Devstack搭建基础开发环境

经验借鉴

一、环境准备

---

1. 准备：

      两台虚拟机，第一台（hostname:devstack）充当控制、网络、计算节点（allinone），第二台（hostname:devstack-com）充当计算节点。内存为8G、磁盘100G全部挂在/下，便于开发。安装Centos Linux release 7.2.1511，选择最简安装。OpenStack版本将对齐社区Master分支，目前即为开发中Queen版。

---

2. 网卡配置：

eth0  -  模拟业务网  -  (192.168.0.0/24)  ;   eth1  -  模拟管理网  -  (10.134.1.0/24)  ;  eth2  -  模拟外网  -  (10.254.4.0/24)

devstack         -  eth0：192.168.0.156 、eth1：10.134.1.156 、eth2：10.254.4.156

devstack-com -  eth0：192.168.0.157 、eth1：10.134.1.157 

---

3. 整体规划如下：

---

二、自动化安装（step by step）

---

1. 配置国内base源：

[root@devstack ~]# cd /etc/yum.repos.d/ ; wget http://mirrors.163.com/.help/CentOS7-Base-163.repo

---

2. 安装git工具：

[root@devstack ~]# yum install git -y

---

3. clone源代码：

[root@devstack ~]# cd /home ; git clone https://github.com/openstack-dev/devstack.git

---

4. 创建stack用户：

[root@devstack /home]# /home/devstack/tools/create-stack-user.sh

---

5. 修改配置文件：

控制、网络、计算复用节点配置：

说明：HOST_IP为该节点的管理IP、密码均使用123456最简密码。

注： 此配置规划了将使用的外网网段，即FLOATING_RANGE、Q_FLOATING_ALLOCATION_POOL、PUBLIC_NETWORK_GATEWAY三个字段配置。若未规划，可将NEUTRON_CREATE_INITIAL_NETWORKS置为False，可以搭建完成后手动配置。

---

计算节点配置：

注：此配置中的PLACEMENT_SERVICE_HOST经测试为生效，由于目前Nova代码master版本缺少Placement配置会报异常，导致Nova-compute不能正常启动，即在安装出错后，得手动配置，在后面 （7.启动安装） 处会详细说明。

---

6. 更改文件用户：

[root@devstack ~]# chown -R stack:stack /home/devstack/

---

7. 启动安装：

控制、网络、计算复用节点（devstack节点）：

[root@devstack ~]# su stack

[stack@devstack devstack]$ cd /home/devstack/ ; ./stack.sh

到这里，devstack节点安装就完成了。区别于rdo的rpm包安装，devstack是源码安装。因为要install大量的python依赖，控制节点安装在2小时左右。

---

计算节点（devstack-com节点）：

[stack@devstack-com devstack]$ cd /home/devstack/ ; ./stack.sh

报错，发现n-cpu服务并未启动，可在/etc/nova/nova-cpu.conf中添加如下配置：

执行： [root@devstack-com ~]# systemctl restart [email protected] ， 即可完成安装。

---

8. 其余问题：

1）调整业务网：安装完发现，业务网走的还是管理网络，

options: {df_default="true", in_key=flow, local_ip="10.134.1.156", out_key=flow, remote_ip="10.134.1.157"}

但实际规划的是192.168.0.0/24网络做业务网，这里需要调整/etc/neutron/plugins/ml2/ml2_conf.ini文件：

重启服务：systemctl restart [email protected] ，即可。

现在利用ovs-vsctl show命令可观察到：

options: {df_default="true", in_key=flow, local_ip="192.168.0.156", out_key=flow, remote_ip="192.168.0.157"}

2）手动创建网络：如果之前devstack节点的配置文件中， NEUTRON_CREATE_INITIAL_NETWORKS设为False，默认不会创建网络，要手动创建：

使用admin租户、admin用户： # source /home/devstack/openrc admin admin

创建外部网络： # neutron net-create ext-net --provider:network_type flat --provider:physical_network public --shared --router:external

创建外部子网：# neutron subnet-create ext-net 10.254.4.0/24 --name ext-subnet --allocation-pool start=10.254.4.205,end=10.254.4.215 --gateway 10.254.4.254

使用demo租户、demo用户： # source /home/devstack/openrc demo demo

创建租户网络：# neutron net-create demo-net

创建租户子网：# neutron subnet-create demo-net 192.168.1.0/24 --name demo-subnet --gateway 192.168.1.1

创建租户路由：# neutron router-create demo-router

子网接入路由：# neutron router-interface-add demo-router demo-subnet

子网设置网关：# neutron router-gateway-set demo-router ext-net

3） cell映射：

社区在O版后，nova引入了cellv2并强制使用，当新增计算节点后，要映射至所属cell中，执行

# nova-manage cell_v2 discover_hosts --verbose

---

9. 升级与重装：

1. 升级devstack代码：

# cd /home/devstack/ ; git pull

2. 升级组件代码（以nova为例）：

# cd /opt/stack/nova/ ; git pull

注意需要重启nova相关服务，db或者api_db有修改的话，需要把数据库拉至最新：

# nova-manage db sync

# nova-manage api_db sync

# systemctl restart devstack@n-api-meta devstack@n-api devstack@n-cauth devstack@n-cond-cell1 devstack@n-cpu devstack@n-novnc devstack@n-sch devstack@n-super-cond

3. 重装：

# cd /home/devstack/ ; ./unstack.sh     停止服务

# cd /home/devstack/ ; ./clean.sh         删除已有数据

# cd /home/devstack/ ; ./stack.sh         重新安装

4. 所有组件升级：

最好的方式就是重装，并建议删除/opt/stack下所有组件源码，重新clone安装依赖

---

三、环境确认、测试

1. 服务状态确认

Keystone: 服务内部没有mq通信，执行# openstack project list ， 有显示即正常。

Nova： 执行# nova service-list ， 查看各服务state是否为up。

Neutron： 执行# neutron agent-list ， 查看alive是否为:-)

Cinder：执行# openstack volume service list ，查看各服务state是否为up

Glance：服务内部没有mq通信，执行#glance image-list ， 有镜像显示即正常。

Horizon：本地登陆http://10.134.1.156/dashboard，若本地不通管理网，使用elinks  http://10.134.1.156/dashboard 检查

---

2. 创建虚机测试

1. 使用demo租户、demo用户

# source /home/devstack/openrc demo demo

2. 创建本地虚机：

# nova boot test --flavor 1 --image cirros-0.3.4-x86_64-disk --nic net-id=89070a3f-1c28-480a-8db6-c59376b0ed07

3. 创建卷虚机：

# nova boot test-vol --flavor 1 --block-device source=image,id=58aa7836-eabb-431c-9247-5787680e6f46,dest=volume,size=1,bootindex=0,shutdown=remove --nic net-id=89070a3f-1c28-480a-8db6-c59376b0ed07

4. 查看虚机状态，直至active：

# nova list

5074d02d-8c4c-4d79-8997-5982f0517192 | test | ACTIVE | - | Running | demo-net=192.168.1.11

573961c6-354a-439a-a665-7058e3bc98bb | test-vol | ACTIVE | - | Running | demo-net=192.168.1.4

5. 登陆vnc进行进一步查看：

# nova get-vnc-console test novnc

novnc | http://10.134.1.156:6080/vnc_auto.html?token=23df2caf-095a-4c00-9933-5cefd0fb47d8

---

3. 网络状态确认

1. 外网连通信检测，最简单的方法就是，从本地去ping，netns中qrouter的qg口：

# ip netns exec qrouter-f8d0e07a-bc9f-4642-9892-9711b94c3410 ip a | grep 10.254

inet 10.254.4.210/24 brd 10.254.4.255 scope global qg-63090b03-08

# ping 10.254.4.210

2. 外网snat确认:

通过ns登陆虚拟机 # ip netns exec qdhcp-89070a3f-1c28-480a-8db6-c59376b0ed07 ssh [email protected]，若无法登陆，请放通安全组。

# ping 10.254.4.156

3. floatingip dnat确认：

创建floatingip：# neutron floatingip-create ext-net

绑定floatingip：# neutron floatingip-associate 3f9ecd27-e8c1-429e-a77a-d00af3c3bcaf 28e76da8-9fd6-4d55-b2c9-4b9c1b419c87

5074d02d-8c4c-4d79-8997-5982f0517192 | test | ACTIVE | - | Running | demo-net=192.168.1.11, 10.254.4.208

# ping 10.254.4.208

---

4. 迁移/热迁移确认：

1. hosts解析，stack用户需要互信，这些是devstack不会做的，自己手动配置下，具体方法就不说了

2. 登陆dashboard进行测试，观察resize后flavor的变化，live-migrate后host的变化，一般都是OK的

---

四、开发调试技巧

1. 查看安装服务

新版本的devstack用systemd取代了screen来启动服务

# systemctl | grep devstack

这里c-开头的就是cinder服务，g-开头的就是glance服务，keystone即keystone服务，n-即nova服务，q-即neutron服务，placement-api即nova-placement服务，dstat是以dstat命令为基础的监控，etcd是分布式存储服务、作为cinder的分布式锁。

所有守护进程服务都可以在/etc/systemd/system/下找到对应文件，即可找到入口及对应参数。

---

2. 查看日志

新版本devstack不再记录日志在/var/log 或 /opt/stack/log下，转而使用journalctl来代替：

# journalctl -a --unit [email protected] | grep XXX 这个相当于之前的 # cat /var/log/nova/nova-compute.log | grep XXX

# journalctl -f --unit [email protected]   这个相当于之前的 # tail -f /var/log/nova/nova-compute.log

---

3. 断点调试

由于目前devstack中很多服务都是依赖httpd启动的，传统的关闭守护服务，利用命令启动加pdb断点调试已不再试用，这里使用社区官方推荐的remote-pdb，即：

from remote_pdb import RemotePdb;RemotePdb('127.0.0.1', 4444).set_trace()   取代之前的   import pdb ; pdb.set_trace()

之后重启服务即可，调用对应api后进入断点，利用telnet或nc -t命令即可进行调试。

---

4. 综合分析、善用git

这里以nova为例，比如在Pike版本调度中，提出了基于Placement的Allocation candidates策略，即CPU、MEM、DISK过滤不再经过nova中的对应filter，而是发送rest请求给Placement服务，利用sql语句（不加以orm封装的）来直接过滤，得出候选主机。当然，Placement服务还在开发中，我们选择配置driver=caching_scheduler来屏蔽它，不过在目前（2017/12/20）的nova代码中，貌似行不通.......

1、问题复现：

修改nova.conf中的driver = filter_scheduler，改为driver = caching_scheduler，重启devstack@n-sch服务，再启动一个虚机，发现ERROR。

2、问题定位：

查看日志：# journalctl -a --unit [email protected] | grep ERROR

发现：ERROR oslo_messaging.rpc.server File "/opt/stack/nova/nova/scheduler/manager.py", line 152, in select_destinations

           ERROR oslo_messaging.rpc.server allocation_request_version, return_alternates)

           ERROR oslo_messaging.rpc.server UnboundLocalError: local variable 'allocation_request_version' referenced before assignment

根据Traceback，定位问题发生在scheduler服务中，出错代码为/opt/stack/nova/nova/scheduler/manager.py第152行

3、阅读代码，进一步定位：

85 def select_destinations(self, ctxt, request_spec=None,

...................................

119        alloc_reqs_by_rp_uuid, provider_summaries = None, None

120        if self.driver.USES_ALLOCATION_CANDIDATES:

121            res = self.placement_client.get_allocation_candidates(resources)

122            if res is None:

123                # We have to handle the case that we failed to connect to the

124                # Placement service and the safe_connect decorator on

125                # get_allocation_candidates returns None.

126                alloc_reqs, provider_summaries, allocation_request_version = (

127                        None, None, None)

128            else:

129                (alloc_reqs, provider_summaries,

130                            allocation_request_version) = res

...................................

150        selections = self.driver.select_destinations(ctxt, spec_obj,

151        instance_uuids, alloc_reqs_by_rp_uuid, provider_summaries,

152        allocation_request_version, return_alternates)

发现只有当self.driver.USES_ALLOCATION_CANDIDATES为true时，才能得到allocation_request_version，否则该变量就不存在！！！

3、断点调试，确认问题：

在/opt/stack/nova/nova/scheduler/manager.py中插入断点：

119        alloc_reqs_by_rp_uuid, provider_summaries = None, None

120        from remote_pdb import RemotePdb;RemotePdb('127.0.0.1', 4444).set_trace()

121        if self.driver.USES_ALLOCATION_CANDIDATES:

安装remote-pdb ： # pip install remote-pdb ； 重启devstack@n-sch服务：systemctl restart devstack@n-sch；再次创建虚机

执行 # nc -t 127.0.0.1 4444 进入断点，进行简单调试：

发现caching_scheduler确实是不使用Allocation candidates策略的，引入allocation_request_version是引发这一问题的元凶。

4、利用git查找代码历史：

# git annotate /opt/stack/nova/nova/scheduler/manager.py

# git log

作者：Remy_XL
链接：https://www.jianshu.com/p/8d2b2637f3d4
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。