如果你以前曾在云平臺上工作過，你一定熟悉這些系統(tǒng)的分布式和解耦性質(zhì)。解耦的分布式系統(tǒng)依賴于微服務(wù)來執(zhí)行特定的任務(wù)，每個微服務(wù)都會暴露自己的REST(表示狀態(tài)轉(zhuǎn)移)API。這些微服務(wù)通常以諸如RabbitMQ或QPID等消息中間件的形式通過輕量級消息層相互通信。

　　這正是OpenStack的工作原理。每個主要的OpenStack組件(Keystone、Glance、Cinder、Neutron、Nova等)公開REST端點(diǎn)，組件和子組件通過消息中間件(如RabbitMQ)進(jìn)行通信。這種方法的優(yōu)點(diǎn)首先是允許將故障分配給特定組件，其次是云基礎(chǔ)設(shè)施運(yùn)營商可以以水平方式擴(kuò)展所有服務(wù)，并智能分配負(fù)載。

　　然而，這種分布式解耦系統(tǒng)雖然非常有利，但也帶來了固有的挑戰(zhàn)——如何正確監(jiān)控OpenStack服務(wù)，更具體地說，如何識別可能的單點(diǎn)故障。

　　下面的內(nèi)容針對OpenStack服務(wù)監(jiān)控的具體情況所面臨的真實(shí)挑戰(zhàn)，以及每個難題可能的解決方案。

　　挑戰(zhàn)一：系統(tǒng)不是一個整體

　　OpenStack的非整體性和解耦性通常被強(qiáng)調(diào)為其主要優(yōu)點(diǎn)。這當(dāng)然是一個重要的優(yōu)勢。然而，這顯然會使任何監(jiān)控整體服務(wù)狀態(tài)的嘗試變得復(fù)雜。在每個組件執(zhí)行一個特定任務(wù)的分布式系統(tǒng)中，每個組件進(jìn)一步分布到多個子組件中，因此，不難理解當(dāng)特定一部分軟件發(fā)生故障時，確定對服務(wù)的影響是多么困難。

　　克服這個困難的首要步是了解云。你需要確定所有主要組件之間的關(guān)系，然后確定每個獨(dú)立的特定服務(wù)之間的關(guān)系，它們的故障可能影響整體服務(wù)。簡單地說，你需要知道云中所有組件之間的關(guān)系。

　　考慮到這一點(diǎn)，你不僅需要監(jiān)視每個單獨(dú)組件的狀態(tài)(正在運(yùn)行或故障停止)，還要確定其他服務(wù)如何受到故障的影響。

　　例如，如果Keystone死機(jī)，沒有人能夠獲取服務(wù)目錄或登錄任何服務(wù)，但這通常不會影響虛擬機(jī)或其他已建立的云服務(wù)(對象存儲、塊存儲、負(fù)載均衡器等)，除非重新啟動服務(wù)且Keystone仍然宕機(jī)。然而，如果Apache失效，通過Apache工作的Keystone和其他類似的API服務(wù)可能會受到影響。

　　因此，監(jiān)控平臺或解決方案不僅需要能夠評估各個服務(wù)的狀態(tài)，而且還要能夠在服務(wù)故障之間進(jìn)行關(guān)聯(lián)，以便檢查對整個系統(tǒng)的真正影響，并相應(yīng)地發(fā)送警報(bào)或通知。

　　挑戰(zhàn)二：OpenStack不僅僅是OpenStack

　　基于OpenStack的云不僅是分布式和解耦式系統(tǒng)，也是一種可在操作系統(tǒng)和其他在云基礎(chǔ)設(shè)施中或與之相關(guān)的設(shè)備中創(chuàng)建資源的編排解決方案。這些資源包括虛擬機(jī)(Xen、KVM或其他管理程序軟件組件)、持久卷(NFS存儲服務(wù)器、Ceph群集、基于SAN的LVM卷或其他存儲后端)、網(wǎng)絡(luò)實(shí)體(端口，網(wǎng)橋，網(wǎng)絡(luò)，路由器，負(fù)載平衡器，防火墻，VPN等)和臨時磁盤(駐留在操作系統(tǒng)目錄中的Qcow2文件)以及許多其他小型系統(tǒng)。

　　因此，監(jiān)測解決方案需要考慮到這些基礎(chǔ)組件。雖然這些資源可能不太復(fù)雜，并且不太容易出現(xiàn)故障，但是當(dāng)它們停止運(yùn)行時，主要OpenStack服務(wù)中的日志可能會掩蓋真實(shí)的原因。它們僅在受到影響的OpenStack服務(wù)中顯示結(jié)果，而不顯示設(shè)備或失效的操作系統(tǒng)軟件的實(shí)際根本原因。

　　例如，如果libvirt失效，組件Nova將無法部署虛擬實(shí)例。 Nova-compute作為服務(wù)將被啟動并運(yùn)行，但在部署階段實(shí)例將失敗(實(shí)例狀態(tài)：錯誤)。為了檢測這一點(diǎn)，你需要在nova-compute日志之外還監(jiān)控libvirt(服務(wù)狀態(tài)、指標(biāo)及日志)。

　　因此，有必要檢查底層軟件和主要組件之間的關(guān)系，以及監(jiān)控最終的鏈接，并考慮所有最終服務(wù)的一致性測試。你需要監(jiān)控所有內(nèi)容：存儲、網(wǎng)絡(luò)、hypervision層、每個單獨(dú)的組件以及之間的關(guān)系。

　　挑戰(zhàn)三：跳出固有思維模式

　　Cacti、Nagios和Zabbix是OpenSource監(jiān)控解決方案的好例子。這些解決方案定義了一組非常具體的度量標(biāo)準(zhǔn)，用于識別操作系統(tǒng)上的可能問題，但是它們不提供確定更復(fù)雜的故障情況或甚至服務(wù)狀態(tài)所需的專門的指標(biāo)。

　　這是你需要有創(chuàng)造性的地方。你可以實(shí)施專門的指標(biāo)和測試，以定義服務(wù)是否正常、降級或完全失敗。

　　像OpenStack這樣的分布式系統(tǒng)，其中每個核心服務(wù)都暴露了一個REST API，并且連接到基于TCP的消息服務(wù)，容易受到網(wǎng)絡(luò)瓶頸、連接池耗盡和其他相關(guān)問題的影響。許多相關(guān)服務(wù)連接到基于SQL的數(shù)據(jù)庫，這可能會耗盡其大連接池，意味著需要在監(jiān)控解決方案中實(shí)施正確的連接狀態(tài)監(jiān)控指標(biāo)(建立、散布等待、關(guān)閉等)，以檢測可能的、影響API的連接相關(guān)問題。此外，可以構(gòu)建cli測試來檢查端點(diǎn)狀態(tài)并測量其響應(yīng)時間，這可以被轉(zhuǎn)換成實(shí)際顯示服務(wù)真實(shí)狀態(tài)的指標(biāo)。

　　上述每一個監(jiān)控解決方案和大多數(shù)其他商業(yè)或OpenSource解決方案可以通過自行設(shè)計(jì)專門指標(biāo)來進(jìn)行擴(kuò)展。

　　命令“time OpenStack catalogue list”可以測量Keystone API響應(yīng)時間，評估結(jié)果，并在結(jié)果不符合預(yù)期時產(chǎn)生人工故障狀態(tài)。此外，你可以使用簡單的操作系統(tǒng)工具，如“netstat”或“ss”，來監(jiān)控API端點(diǎn)的不同連接狀態(tài)，并了解服務(wù)中可能出現(xiàn)的問題。OpenStack云依賴關(guān)系的關(guān)鍵部分(例如消息代理和數(shù)據(jù)庫服務(wù))也可以這樣做。請注意，消息中間件失敗基本上將“殺死”OpenStack云。

　　關(guān)鍵是不要偷懶!不要只用默認(rèn)的指標(biāo)，而是應(yīng)該用與自己服務(wù)相關(guān)的指標(biāo)。

　　挑戰(zhàn)四：人為因素

　　人為因素關(guān)乎一切。俗話說，埋怨工具的工匠不是一個好工匠。

　　沒有經(jīng)過測試的情景響應(yīng)程序，單一故障不僅本身是一個問題，還將帶來造更多的問題。在你的監(jiān)控解決方案中，云基礎(chǔ)設(shè)施的任何事故及其相關(guān)警報(bào)中都應(yīng)該有明確的記錄，以清楚的步驟來解釋如何檢測、遏制和解決問題。

　　人為因素需要考慮，即使你有一個可以關(guān)聯(lián)事件和建議適當(dāng)?shù)慕鉀Q方案來檢測事故的、聰明的系統(tǒng)(一個有一定程度人工智能的系統(tǒng))。請務(wù)必記住，如果系統(tǒng)不正確或不完整，那么輸出也將不準(zhǔn)確或不完整。

　　總結(jié)一下，OpenStack監(jiān)控不一定很困難，最重要的是要徹底。每個單獨(dú)的服務(wù)以及與其他服務(wù)的互動都需要仔細(xì)監(jiān)控。特殊指標(biāo)甚至可以自己實(shí)現(xiàn)。通過一些TLC，你可以輕松地成功監(jiān)控你的OpenStack。

網(wǎng)站標(biāo)題：OpenStack監(jiān)控技巧
鏈接分享：http://www.rwnh.cn/news/265893.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供商城網(wǎng)站、外貿(mào)建站、軟件開發(fā)、網(wǎng)站策劃、品牌網(wǎng)站建設(shè)、自適應(yīng)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)