故障現(xiàn)象
某運營商TECS資源池,在當前告警中顯示“虛機寫磁盤時延高告警”,如下圖所示。告警統(tǒng)計總體平均10分鐘左右自動恢復。
故障分析
結合現(xiàn)場環(huán)境和資源情況,分析問題產生的可能原因如下:
1. 虛擬機系統(tǒng)異常,操作系統(tǒng)只讀不可寫。
2. 計算節(jié)點訪問后端存儲異常。
3. 虛擬機讀寫性能不足,或者平臺QoS配置限定。
4. 虛擬機配置問題,或者虛機被攻擊,導致大量寫操作。
具體問題分析過程如下:
1. 登錄異常虛擬機操作系統(tǒng),檢查虛擬機內部業(yè)務是否正常讀寫,以及操作系統(tǒng)狀態(tài)。
2. 虛機寫磁盤延時告警上報后,底層平臺和業(yè)務網(wǎng)元雙向檢查。
平臺檢查虛機運行正常,無其它異常告警。
業(yè)務網(wǎng)元檢查虛機正常,網(wǎng)元無異常告警。
確認虛機寫磁盤時延高告警僅觸發(fā)告警,無業(yè)務影響,如下圖所示。
3. 在TECS上通過告警找到對應虛機的節(jié)點,確定該節(jié)點只有一個虛機是NFV-P-***。再檢查虛機讀寫速率和虛機所在節(jié)點讀寫速率。
4. 執(zhí)行iostat -x 3命令,檢查服務器節(jié)點。持續(xù)續(xù)觀察1小時,節(jié)點檢查正常,如下圖所示。
5. 在CloveStorage分布式存儲上使用告警信息中虛機名稱檢查,確認虛機對應卷。
a. 在TECS平臺檢查虛機對應的云盤,獲取云盤對應卷的ID,從告警確定虛機名,如下圖所示。
b. 測試TECS平臺使用sftp方式訪問第三方存儲正常,能夠正常訪問,也能正常發(fā)送問題。
c. 在CloveStorage分布式存儲上檢查每個對應卷和集群的性能,如下圖所示。
IOPS:I/O per second,即每秒鐘可以處理的I/O個數(shù),用來衡量存儲系統(tǒng)的I/O處理能力,如下圖所示。
讀寫速率:每秒鐘可以處理的數(shù)據(jù)量,常以MB/s或GB/s為單位,用于衡量存儲系統(tǒng)的吞吐量。
I/O:輸入(input)、輸出(output)。
IO時延:發(fā)起一次I/O請求到I/O處理完成的時間間隔。
容量:可用的存儲空間大小。
6. 根據(jù)上圖可以看出IOPS值在告警時間段超出200。
7. 在TECS平臺檢查存儲QoS設置值,為200,如下圖所示。
8. 檢查對應卷的IOPS值,超過 200;而卷的QoS設置IOPS最大上限為200,經(jīng)確認出現(xiàn)時延沖高的卷QoS均超過了設定的最大值,因此存在QoS設置不合理影響卷性能的問題。
9. 同時和業(yè)務網(wǎng)元確認,存在卷的QoS設置小于實際運行的預期值。
10. QoS(Quality of Service)即服務質量。在有限的資源下,QoS為各種業(yè)務分配固定的資源預留,為業(yè)務提供端到端的服務質量保證。
卷的QoS設置IOPS和帶寬上限,當卷的實際性能超過QoS設置的最大值時,會由于QoS的限制出現(xiàn)IO隊列排隊擁塞的情況,反映到上層,即對應的云盤IO時延增高并上報告警。
11. 通過以上檢查,發(fā)現(xiàn)存儲側在異常時間段沒有異常告警,確認底層存儲集群運行正常。
故障處理
1. 虛擬化平臺和業(yè)務網(wǎng)元聯(lián)合檢查確認是因為業(yè)務網(wǎng)元側針對QoS設置IOPS值小于卷實際運行的IOPS值,導致卷時延沖高,最終產生告警。
2. 修改存儲QoS值后,未再上報該告警。
-
運營商
+關注
關注
4文章
2425瀏覽量
46036 -
磁盤
+關注
關注
1文章
394瀏覽量
26174 -
命令
+關注
關注
5文章
745瀏覽量
23304 -
OpenStack
+關注
關注
1文章
72瀏覽量
19544
原文標題:TECS OpenStack-資源池虛機寫磁盤時延高告警的問題處理
文章出處:【微信號:ztedoc,微信公眾號:中興文檔】歡迎添加關注!文章轉載請注明出處。
發(fā)布評論請先 登錄
RCS融合通信系統(tǒng)設計方案解析

OpenStack資源調度和現(xiàn)狀分析

杉巖數(shù)據(jù)已實現(xiàn)了與OpenStack的全面緊耦合
OpenStack云平臺監(jiān)控數(shù)據(jù)采集及處理的實踐與優(yōu)化
TECS資源池SSH控制節(jié)點虛機提示connection refused的問題處理

資源池后端存儲服務狀態(tài)異常的問題處理

高并發(fā)內存池項目實現(xiàn)

TECS OpenStack資源池虛擬機網(wǎng)絡二層地址無法互通的問題處理

評論