openstack出错怎么办

106次阅读
没有评论

共计 2797 个字符,预计需要花费 7 分钟才能阅读完成。

这篇文章主要介绍了 openstack 出错怎么办,具有一定借鉴价值,感兴趣的朋友可以参考下,希望大家阅读完这篇文章之后大有收获,下面让丸趣 TV 小编带着大家一起了解一下。

控制节点:

查看云主机: nova list

详细查看单个云主机: nova show [name]

查看各个节点状态:nova-manage service list

 

计算节点:

查看节点状态: service openstack-nova-compute status

重启节点:  service openstack-nova-compute restart

1.

  虚拟机建立不起来的时候,有可能是,计算节点上的 openstack 服务 down 掉了,在控制节点上重启 openstack 服务即可。

[root@controlNode01 network-scripts]# nova service-list        

| 6  | nova-compute     | computeNode01 | nova     | enabled | down  | 2016-02-26T06:47:45.000000 | None            |

[root@controlNode01 network-scripts(keystone_ALUvRAN)]#openstack-service restart

2.

虚拟机删掉了,但是 volume 还显示 in-use 状态,需要从数据库里面重置 volume 的状态。

[root@controlNode01]# mysql cinder 

MariaDB [cinder]  SELECT id,status,attach_status,mountpoint,instance_uuid from volumes;

MariaDB [cinder]  UPDATE volumes SET status= available , attach_status= detached , mountpoint=NULL, instance_uuid=NULL WHERE id= 336d3e1c-298e-437d-a469-c2872cbe1a3a

  3.

有时候碰到硬盘太大,比如需要创建 80G 的虚拟机,则会创建失败,需要修改 nova 里面的 vif 超时参数。

vif_plugging_timeout=10

vif_plugging_is_fatal=False

4.

在运行“/etc/init.d/network restart”命令时,出现错误“Job for network.service failed. See  systemctl status network.service  and  journalctl -xn  for deta”,运行“cat /var/log/messages | grep network”命令查看日志中出现的与 network 相关的信息

我出现的错误,是由于外网的物理地址与 eth0 不一样。后来将 pub 网指向 eth0 即可

7.14.2016

问题 1:

控制节点与计算节点之间的时间不同步:

nova-manage service list 检测服务状态原理:

最近更新时间,或者第一次创建时间与当前时间间隔少于 CONF.service_down_time(60 秒),则认为服务 alive

从这里也可以得知为什么控制节点和计算节点的时间要一致。

http://blog.csdn.net/tantexian/article/details/39204993

问题 2:

  Nova scheduler :Host has more disk space than database expected

原理:

宿主机 RAM 和 DISK 的使用率往往要小于虚拟机理论使用的 RAM 和 DISK,在剩余资源充足的条件下,libvirt 将成功创建虚拟机。

随想:内存和磁盘超配虽然能提供更多数量的虚拟机,当该宿主机上大量虚拟机的负载都很高时,轻着影响虚拟机性能,重则引起 qemu-kvm 相关进程被杀,即虚拟机被关机。因此对于线上稳定性要求高的业务,建议不要超配 RAM 和 DISK,但可适当超配 CPU。建议这几个参数设置为:

CPU: CONF.cpu_allocation_ratio = 4

RAM: CONF.ram_allocation_ratio = 1.0

DISK: CONF.disk_allocation_ratio = 1.0

RAM-Reserve: CONF.reserved_host_memory_mb = 2048

DISK-Reserve: CONF.reserved_host_disk_mb = 20480

http://blog.csdn.net/wsfdl/article/details/45418727

问题 3:

在 nova-all.log 日志中发现 MessagingTimeout: Timed out waiting for a reply to message ID 问题

日志中时不时出现”MessagingTimeout: Timed out waiting for a reply to message“,来点绝的,直接修改 nova.conf 文件,添加:

[conductor]
use_local=true

如果计算节点宕机了,但没有在 nova 里将这个 host disable 掉,在  service_down_time and report_interval setting 时间内 nova-schedule 会误认为这个 host 仍然是 alive 的,从而出问题了。另外也可能是 olso 的 bug, https://bugs.launchpad.net/oslo.messaging/+bug/1338732

或者去掉 RetryFilter, 

scheduler_default_filters=AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,Image

在 neutron  openswitch-agent .log 中发现

MessagingTimeout: Timed out waiting for a reply to message ID

neutron 在同步路由信息时,会从 neutron-server 获取所有 router 的信息,这个过程会比较长(130s 左右,和网络资源的多少有关系),而 在 /etc/neutron/neutron.conf 中会有一个配置项“rpc_response_timeout”,它用来配置 RPC 的超时时间,默认为 60s, 所以导致超时异常. 解决方法为设置 rpc_response_timeout=180.

延时是解决各种问题的大招啊。。。

感谢你能够认真阅读完这篇文章,希望丸趣 TV 小编分享的“openstack 出错怎么办”这篇文章对大家有帮助,同时也希望大家多多支持丸趣 TV,关注丸趣 TV 行业资讯频道,更多相关知识等着你来学习!

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-08-16发表,共计2797字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)