openstack出錯怎么辦

262次閱讀

沒有評論

共計 2797 個字符，預計需要花費 7 分鐘才能閱讀完成。

這篇文章主要介紹了 openstack 出錯怎么辦，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓丸趣 TV 小編帶著大家一起了解一下。

控制節(jié)點：

查看云主機: nova list

詳細查看單個云主機: nova show [name]

查看各個節(jié)點狀態(tài)：nova-manage service list

計算節(jié)點:

查看節(jié)點狀態(tài): service openstack-nova-compute status

重啟節(jié)點: service openstack-nova-compute restart

1.

虛擬機建立不起來的時候，有可能是，計算節(jié)點上的 openstack 服務 down 掉了，在控制節(jié)點上重啟 openstack 服務即可。

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

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

2.

虛擬機刪掉了，但是 volume 還顯示 in-use 狀態(tài)，需要從數(shù)據(jù)庫里面重置 volume 的狀態(tài)。

[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.

有時候碰到硬盤太大，比如需要創(chuàng)建 80G 的虛擬機，則會創(chuàng)建失敗，需要修改 nova 里面的 vif 超時參數(shù)。

vif_plugging_timeout=10

vif_plugging_is_fatal=False

4.

在運行“/etc/init.d/network restart”命令時，出現(xiàn)錯誤“Job for network.service failed. See systemctl status network.service and journalctl -xn for deta”，運行“cat /var/log/messages | grep network”命令查看日志中出現(xiàn)的與 network 相關的信息

我出現(xiàn)的錯誤，是由于外網(wǎng)的物理地址與 eth0 不一樣。后來將 pub 網(wǎng)指向 eth0 即可

7.14.2016

問題 1：

控制節(jié)點與計算節(jié)點之間的時間不同步：

nova-manage service list 檢測服務狀態(tài)原理：

最近更新時間，或者第一次創(chuàng)建時間與當前時間間隔少于 CONF.service_down_time（60 秒），則認為服務 alive

從這里也可以得知為什么控制節(jié)點和計算節(jié)點的時間要一致。

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

問題 2：

Nova scheduler :Host has more disk space than database expected

原理：

宿主機 RAM 和 DISK 的使用率往往要小于虛擬機理論使用的 RAM 和 DISK，在剩余資源充足的條件下，libvirt 將成功創(chuàng)建虛擬機。

隨想：內(nèi)存和磁盤超配雖然能提供更多數(shù)量的虛擬機，當該宿主機上大量虛擬機的負載都很高時，輕著影響虛擬機性能，重則引起 qemu-kvm 相關進程被殺，即虛擬機被關機。因此對于線上穩(wěn)定性要求高的業(yè)務，建議不要超配 RAM 和 DISK，但可適當超配 CPU。建議這幾個參數(shù)設置為：

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 日志中發(fā)現(xiàn) MessagingTimeout: Timed out waiting for a reply to message ID 問題

日志中時不時出現(xiàn)”MessagingTimeout: Timed out waiting for a reply to message“，來點絕的，直接修改 nova.conf 文件，添加：

[conductor]
use_local=true

如果計算節(jié)點宕機了，但沒有在 nova 里將這個 host disable 掉，在 service_down_time and report_interval setting 時間內(nèi) 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 中發(fā)現(xiàn)

MessagingTimeout: Timed out waiting for a reply to message ID

neutron 在同步路由信息時，會從 neutron-server 獲取所有 router 的信息，這個過程會比較長（130s 左右，和網(wǎng)絡資源的多少有關系），而在 /etc/neutron/neutron.conf 中會有一個配置項“rpc_response_timeout”，它用來配置 RPC 的超時時間，默認為 60s, 所以導致超時異常. 解決方法為設置 rpc_response_timeout=180.

延時是解決各種問題的大招啊。。。

感謝你能夠認真閱讀完這篇文章，希望丸趣 TV 小編分享的“openstack 出錯怎么辦”這篇文章對大家有幫助，同時也希望大家多多支持丸趣 TV，關注丸趣 TV 行業(yè)資訊頻道，更多相關知識等著你來學習!

正文完