這篇文章主要介紹了openstack出錯(cuò)怎么辦，具有一定借鑒價(jià)值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。
樅陽(yáng)ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場(chǎng)景，ssl證書(shū)未來(lái)市場(chǎng)廣闊！成為創(chuàng)新互聯(lián)的ssl證書(shū)銷售渠道，可以享受市場(chǎng)價(jià)格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18980820575（備注：SSL證書(shū)合作）期待與您的合作！
控制節(jié)點(diǎn)：
查看云主機(jī): nova list
詳細(xì)查看單個(gè)云主機(jī): nova show [name]
查看各個(gè)節(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ī)建立不起來(lái)的時(shí)候，有可能是，計(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ù)庫(kù)里面重置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.
有時(shí)候碰到硬盤(pán)太大，比如需要?jiǎng)?chuàng)建80G的虛擬機(jī)，則會(huì)創(chuàng)建失敗，需要修改nova里面的vif超時(shí)參數(shù)。
vif_plugging_timeout=10
vif_plugging_is_fatal=False
4.
在運(yùn)行“/etc/init.d/network restart”命令時(shí)，出現(xiàn)錯(cuò)誤“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)的錯(cuò)誤，是由于外網(wǎng)的物理地址與eth0不一樣。后來(lái)將pub網(wǎng)指向eth0即可
7.14.2016
問(wèn)題1：
控制節(jié)點(diǎn)與計(jì)算節(jié)點(diǎn)之間的時(shí)間不同步：
nova-manage service list檢測(cè)服務(wù)狀態(tài)原理：
最近更新時(shí)間，或者第一次創(chuàng)建時(shí)間與當(dāng)前時(shí)間間隔少于CONF.service_down_time（60秒），則認(rèn)為服務(wù)alive
從這里也可以得知為什么控制節(jié)點(diǎn)和計(jì)算節(jié)點(diǎn)的時(shí)間要一致。
http://blog.csdn.net/tantexian/article/details/39204993
問(wèn)題 2：
Nova scheduler :Host has more disk space than database expected
原理：
宿主機(jī) RAM 和 DISK 的使用率
往往要小于虛擬機(jī)理論使用的 RAM 和 DISK，在剩余資源充足的條件下，libvirt 將成功創(chuàng)建虛擬機(jī)。
隨想：內(nèi)存和磁盤(pán)超配雖然能提供更多數(shù)量的虛擬機(jī)，當(dāng)該宿主機(jī)上大量虛擬機(jī)的負(fù)載都很高時(shí)，輕著影響虛擬機(jī)性能，重則引起 qemu-kvm 相關(guān)進(jìn)程被殺，即虛擬機(jī)被關(guān)機(jī)。因此對(duì)于線上穩(wěn)定性要求高的業(yè)務(wù)，建議不要超配 RAM 和 DISK，但可適當(dāng)超配 CPU。建議這幾個(gè)參數(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
問(wèn)題 3：
在nova-all.log日志中發(fā)現(xiàn)MessagingTimeout: Timed out waiting for a reply to message ID問(wèn)題
日志中時(shí)不時(shí)出現(xiàn)”MessagingTimeout: Timed out waiting for a reply to message“， 來(lái)點(diǎn)絕的， 直接修改nova.conf文件，添加：
[conductor]
use_local=true
如果計(jì)算節(jié)點(diǎn)宕機(jī)了，但沒(méi)有在nova里將這個(gè)host disable掉，在 service_down_time and report_interval setting時(shí)間內(nèi)nova-schedule會(huì)誤認(rèn)為這個(gè)host仍然是alive的，從而出問(wèn)題了。 另外也可能是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在同步路由信息時(shí)，會(huì)從neutron-server獲取所有router的信息，這個(gè)過(guò)程會(huì)比較長(zhǎng)（130s左右，和網(wǎng)絡(luò)資源的多少有關(guān)系），而 在/etc/neutron/neutron.conf中會(huì)有一個(gè)配置項(xiàng)“rpc_response_timeout”，它用來(lái)配置RPC的超時(shí)時(shí)間，默認(rèn)為60s,所以導(dǎo)致超時(shí)異常.解決方法為設(shè)置rpc_response_timeout=180.
延時(shí)是解決各種問(wèn)題的大招啊。。。
感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享的“openstack出錯(cuò)怎么辦”這篇文章對(duì)大家有幫助，同時(shí)也希望大家多多支持創(chuàng)新互聯(lián)，關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，更多相關(guān)知識(shí)等著你來(lái)學(xué)習(xí)!
重慶分公司
重慶分公司
