总结
经过前段时间艰苦卓绝的解决各种问题,总算是将整个openstack成功搭建。进入到创建云主机的步骤。这是个真正考验自己的地方了,特别是自己对网络这块就跟白痴一样,看openstack提供的官方文档里,各种GRE模式、VLAN模式、VXLAN模式、L2层转发、L3层转发、桥接、路由、Nova-Network,Fix-ip,Floating-ip。我能说我已经晕了么。进入正题
# 正题
在第一步安装成功后,下一步进入到云主机的安装过程中,主要是碰到了下列三类问题:
network分配不成功
看到这个问题,我首先怀疑的是自己的网络配置上有问题,首先来讲自己的采用的是All-in-one的方式进行安装,传说中的demo版本的单主机,单网卡。确实会造成整个机器都会卡到爆,将内存、cpu各种都吃的7788。检查自己的网卡配置。private-net-work已配置、public-net-work已配置。按理来讲network是应该分配成功的。
查看整个项目的网络拓扑,也是成功的。继续排查网络配置:
## Neutron options Q_USE_SECGROUP=True FLOATING_RANGE="10.3.10.0/24" FIXED_RANGE="10.0.3.0/24" NETWORK_GATEWAY="10.3.10.1" Q_FLOATING_ALLOCATION_POOL=start=10.3.10.230,end=10.3.10.240 PUBLIC_NETWORK_GATEWAY="10.3.10.1"
好像网络配置上也没有太多的问题,那么问题来了。查看n-cpu.log,q-meta.log看到错误日志为:not enough ip 进行分配的错误。通过检查发现,原来的原来是自己的配置的这个Q_FLOATING_ALLOCATION_POOL从10.230~10.240 竟然是另外一个项目组的服务器组的IP地址!已经被他们给占用光了。
block device mapping error:设备映射不成功
问题1修改完成后,紧接着问题2来了。出现设备映射不成功的问题。下面是自己创建整个项目、云主机的流程:
1. 创建Project -- meeting 2. 配置Project用户 --meeting-user 3. 切换到 meeting的工程 4. 进入到计算->访问与安全,创建安全组(meeting-sec),生成密钥 5. 进入到网络->网络拓扑, 新建网络、新建路由 6. 进入到计算->镜像, 新建镜像(镜像文件是ubuntu为openstack提供的镜像文件,14.04) 7. 通过镜像启动云主机!
经过几分钟后发现提示错误:block device mapping error. 在网上搜索了好久都没有找到问题的解决办法,各种尝试都无法摆脱出现错误的问题。很多大牛、官网上的bug库也提到了可能是因为该主机的资源不够造成的(cpu、内存、硬盘),在多次试验中发现,有的时候连接成功,有的时候连接失败(出错几率太高了),错误原因没有找到。
通过日志 n-cpu.log、c-api.log, 发现报告的是出现连接cinder volume出现了错误。
为了找到失败产生的原因,或者是找到方法应对这种失败。在多次的失败试验后,删除已有的项目,重新建立项目,再次通过镜像启动云主机,同样出现该问题,错误报告也是一样的。
首先:查看cinder volume的状态
stack@root:/opt/stack/source_openrc$ openstack volume list +--------------------------------------+--------------------+--------+------+-----------------------+ | ID | Display Name | Status | Size | Attached to +--------------------------------------+--------------------+--------+------+-----------------------+ | 46fe8d64-901a-41a1-8bd2-4145b85ea1d7 | test1 | succ | 10 | | +--------------------------------------+--------------------+--------+------+-----------------------+ (这个是成功的卷的状态)
发现实际上我们的列表中已经存在了一个卷,状态是成功可用。然而我们的openstack n-cpu中报告却是连接失败,一直不了解问题在哪儿?再次查看错误日志发现错误提示(n-cpu.log)中,发现提示的信息是在200s后还是没有连接到卷,所以报告了block device mapping error。大胆的猜测:是因为自己用了台很老的机器来搭建这个环境,整个机器由于cpu、内存、系统跑了过多的openstack的服务,造成了重新生成卷的时间过长,超过了nova调用中所设定的时间。
因此改动启动云主机的流程。我们通过镜像先生成卷,再通过卷去创建云主机。果然成功的完成了主机的创建。
再次多次试验,发现果然解决了上面的问题。
网络无法连接
成功生成了云主机后,进入到第三阶段,网络访问。实际上在创建云主机前(在创建网络的、新建路由),都应该完成这一步的操作的。
我的主机的物理环境是:10.3.10.x 。在云主机配置成功后,始终在主机上成功连接到云主机上。
需要配置规则:在规则中开放了ICMP协议、开放了22号TCP端口。然并卵,同样无法成功。
查看资料:《openstack_understand_neutron.pdf》、《ovm-linux-openstack-2202503.pdf》各种。的确是对openstack的网络架构上有了一点点了解,对自己理解openstack的网络还是非常的有帮助的,至少在ifconfig 后看到
br-ex、br-int 、br-int ,在配置网络时知道了GRE、VLAN、VxLan的简单区别。这里不能详细说了,因为自己也不懂,怕误导人。
检查配置,查看neutron服务是否正确启动.如果查看到有5个服务在active状态,那么表示网络服务状态是没问题,就看自己是如何配置这些服务了。
stack@root:/opt/stack/source_openrc$ neutron agent-list +--------------------------------------+--------+------+-------------------+-------+----------------+---------------------------+ | id | agent_type | host | availability_zone | alive | admin_state_up | binary | +--------------------------------------+--------------------+------+-------------------+-------+----------------+---------------------------+ | 051e7160-63fd-4d02-babf-085ab9b4c667 | Metering agent | root | | :-) | True | neutron-metering-agent | | 4ffac3f2-16da-48ec-ba2b-71d0aefbecc6 | Open vSwitch agent | root | | :-) | True | neutron-openvswitch-agent | | 64328472-ac83-4424-92ae-a0753e5648a0 | L3 agent | root | nova | :-) | True | neutron-l3-agent | | ba91f01f-a4a0-453b-bc3a-c4193c0f3802 | Metadata agent | root | | :-) | True | neutron-metadata-agent | | fe9927b4-6d61-402b-8c34-e874aeb5d252 | DHCP agent | root | nova | :-) | True | neutron-dhcp-agent | +--------------------------------------+--------------------+------+-------------------+-------+----------------+---------------------------+
最终配置如下:
# Enabling Neutron (network) Service disable_service n-net enable_service q-svc enable_service q-agt enable_service q-dhcp enable_service q-l3 enable_service q-meta enable_service q-metering enable_service neutron ## Neutron options Q_USE_SECGROUP=True FLOATING_RANGE="10.3.10.0/24" FIXED_RANGE="10.0.1.0/24" NETWORK_GATEWAY="10.0.1.1" Q_FLOATING_ALLOCATION_POOL=start=10.3.10.130,end=10.3.10.240 PUBLIC_NETWORK_GATEWAY="10.3.10.1" Q_L3_ENABLED=True #mark PUBLIC_INTERFACE=eth0 Q_USE_PROVIDERNET_FOR_PUBLIC=True #mark OVS_PHYSICAL_BRIDGE=br-ex #mark PUBLIC_BRIDGE=br-ex #mark OVS_BRIDGE_MAPPINGS=public:br-ex # VLAN configuration. #在前面的配置中是使用的tunnels Q_PLUGIN=ml2 ##mark ##ENABLE_TENANT_TUNNELS=True ENABLE_TENANT_VLANS=True ##mark
重新运行./stack.sh 至此。网络连通性的问题搞定。等自己在以后的学习中更加深入的了解后再对这块进行补充。
web中vnc无法直接登录
在web上进入计算->云主机数量->点击云主机实例->控制台:发现会出现错误,错误代码:
atkbd serio0: Use ‘setkeycodes 00 ’ to make it known.
atkbd serio0: Unknown key pressed (translated set 2, code 0x0 on isa0060/serio0).
ssh无法直接登录
这个问题纯属于乌龙事件:是规则里面没有配置ICMP造成。
试验方案:
1.通过中间路由登录系统
suo ip netns #用户查看当前的路由
suo ip netns excc qroute-xxxxx-xxxxx ssh -i xxxx.pem ubuntu@10.0.1.5
强烈补充:ubuntu的云主机的启动脚本,通过下面的脚本启动云主机后,我才能通过ssh登录到云主机上:
#!/bin/sh
passwd ubuntu<<EOF
ubuntu
ubuntu
EOF
sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/g' /etc/ssh/sshd_config
service ssh restart
2. 为云主机分派浮动IP(假设地址为10.3.10.132)
ssh -i xxxx.pem ubuntu@10.3.10.132
系统重启
系统重启后就意味着需要重启devstack了,但是如果执行./stack.sh,等于是重装了一次devstack,所有部署都清空了,
这种情况肯定是大家不想看到的,幸好有大神提供了重启脚本,在最后面也共享下。cinder-volume的错误
1. Cinder-Volume错误 解决c-vol中ERROR cinder.service [-] Manager for service cinder-volume localhost.localdomain@lvmdriver-1 is reporting problems, not sending heartbeat. Service will appear "down". 的问题 在执行重启脚本(rejion.sh)前: [stack@localhost ~]$ sudo losetup -f /opt/stack/data/stack-volumes-default-backing-file [stack@localhost ~]$ sudo losetup -f /opt/stack/data/stack-volumes-lvmdriver-1-backing-file 2. 服务器重启后发现openstack的主机IP无法连接,最终发现是因为br-ex这个网桥中没有设置IP地址 sudo ifconfig eth0 0.0.0.0 sudo ifconfig eth0 up sudo ifconfig br-ex 10.3.10.83 netmask 255.255.255.0 sudo ifconfig br-ex down sudo ifconfig br-ex up
下面是重启脚本(rejion.sh):(感谢网上的某位大神,出处已经忘记了,盗用下你的成果)
# script rejoins an existing screen, or re-creates a
# screen session from a previous run of stack.sh.
TOP_DIR=`dirname $0`
# Import common functions in case the localrc (loaded via stackrc)
# uses them.
source $TOP_DIR/functions
source $TOP_DIR/stackrc
# if screenrc exists, run screen
if [[ -e $TOP_DIR/stack-screenrc ]]; then
if screen -ls | egrep -q "[0-9].stack"; then
echo "Attaching to already started screen session.."
exec screen -r stack
fi
exec screen -c $TOP_DIR/stack-screenrc
fi
echo "Couldn't find $TOP_DIR/stack-screenrc file; have you run stack.sh yet?"
exit 1