openstack出錯怎么辦

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

控制節(jié)點(diǎn)：

查看云主機(jī): nova list

詳細(xì)查看單個云主機(jī): nova show [name]

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

計(jì)算節(jié)點(diǎn):

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

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

1.

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

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

虛擬機(jī)刪掉了，但是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的虛擬機(jī)，則會創(chuàng)建失敗，需要修改nova里面的vif超時參數(shù)。

vif_plugging_timeout=10

vif_plugging_is_fatal=False

4.

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

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

7.14.2016

問題1：

控制節(jié)點(diǎn)與計(jì)算節(jié)點(diǎn)之間的時間不同步：

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

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

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

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

問題 2：

              Nova scheduler :Host has more disk space than database expected

原理：

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

隨想：內(nèi)存和磁盤超配雖然能提供更多數(shù)量的虛擬機(jī)，當(dāng)該宿主機(jī)上大量虛擬機(jī)的負(fù)載都很高時，輕著影響虛擬機(jī)性能，重則引起 qemu-kvm 相關(guān)進(jìn)程被殺，即虛擬機(jī)被關(guān)機(jī)。因此對于線上穩(wěn)定性要求高的業(yè)務(wù)，建議不要超配 RAM 和 DISK，但可適當(dāng)超配 CPU。建議這幾個參數(shù)設(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“， 來點(diǎn)絕的， 直接修改nova.conf文件，添加：

[conductor]
use_local=true

如果計(jì)算節(jié)點(diǎn)宕機(jī)了，但沒有在nova里將這個host disable掉，在 service_down_time and report_interval setting時間內(nèi)nova-schedule會誤認(rèn)為這個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)絡(luò)資源的多少有關(guān)系），而 在/etc/neutron/neutron.conf中會有一個配置項(xiàng)“rpc_response_timeout”，它用來配置RPC的超時時間，默認(rèn)為60s,所以導(dǎo)致超時異常.解決方法為設(shè)置rpc_response_timeout=180.

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

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