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. 整体规划如下:

Devstack搭建基础开发环境_第1张图片


二、自动化安装(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. 修改配置文件:

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

Devstack搭建基础开发环境_第2张图片

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

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


计算节点配置:

Devstack搭建基础开发环境_第3张图片

注:此配置中的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搭建基础开发环境_第4张图片

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


计算节点(devstack-com节点):

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

Devstack搭建基础开发环境_第5张图片

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

Devstack搭建基础开发环境_第6张图片

执行: [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文件:

Devstack搭建基础开发环境_第7张图片

重启服务: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

Devstack搭建基础开发环境_第8张图片


4. 迁移/热迁移确认:

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

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


四、开发调试技巧

1. 查看安装服务

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

# systemctl | grep devstack

Devstack搭建基础开发环境_第9张图片

这里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 进入断点,进行简单调试:

Devstack搭建基础开发环境_第10张图片

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

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

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

Devstack搭建基础开发环境_第11张图片

# git log

Devstack搭建基础开发环境_第12张图片



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

你可能感兴趣的:(OpenStack,Problems)