分布式緩存組件故障分析及監(jiān)控優(yōu)化

IT那活兒發(fā)布于2023-01-11 13:20 / 3670人閱讀

背景

PaaS平臺緩存組件采用電信集體自研分布式緩存ctg-cache產(chǎn)品，部署在“天翼云”資源池，為多個能力中心提供服務(wù)，如外部客戶統(tǒng)一認(rèn)證平臺（UAM）、CPCP增量（CPC1）、CPCP工作臺（CPC1WEB）、綜合資源（RM）、銷售門戶，計費等，目前支撐大約為每分鐘10萬的業(yè)務(wù)訪問緩存請求。CRM集群部署了10組Redis實例節(jié)點，以及4個“接入機(jī)”節(jié)點，如表一、圖一所示。

表格 1 CRM集群節(jié)點信息

圖表 1 分布式緩存部署拓?fù)鋱D

IT運維與安全體系的落地關(guān)鍵在于解決問題的快慢，歸根結(jié)底是客戶感知,巡檢是必要手段之一。通過巡檢，一方面可檢查服務(wù)可用性，保障服務(wù)的平穩(wěn)運行，另一方面可發(fā)現(xiàn)潛在的隱患，及時做出對應(yīng)的整改措施。我們對于巡檢的不斷優(yōu)化和改善，就是為了更快地修復(fù)、杜絕和預(yù)防故障，達(dá)成客戶能夠獲得良好的感知的最終目的。

目前PaaS平臺組主要通過監(jiān)控告警和定期巡檢來保障分布式緩存的服務(wù)健康性。分布式緩存實行每日巡檢制，巡檢主要分為3個時間段，第一個時間段是早上7點到7點半，進(jìn)行PaaS平臺所有組件的統(tǒng)一晨檢，保障營業(yè)廳營業(yè)前服務(wù)的健康性；第二個時間段是上班時間由平臺組每隔2小時巡檢一次，在保障組件正常運行的同時，還要關(guān)注監(jiān)控曲線的波動幅度是否正常、CPU/內(nèi)存使用率是否偏高、應(yīng)用執(zhí)行緩存操作的報錯率等，便于及時發(fā)現(xiàn)隱患；第三個時間段是晚上9點到9點半，進(jìn)行PaaS平臺所有組件的統(tǒng)一巡檢。

案例分享

此前PaaS平臺組對于分布式緩存的巡檢主要是檢查管理頁面組件的運行狀態(tài)，但在分布式緩存一次故障處理過程中，運維人員在收到告警后立刻著手進(jìn)行處理，當(dāng)時管理頁面組件運行狀態(tài)正常，運維人員在問題定位上耗費了較長時間，因此沒有快速解決故障。

故障現(xiàn)象

（1）運維人員收到緩存的各類告警郵件，包括宕機(jī)告警、服務(wù)告警等告警郵件。

（2）平臺測試程序和應(yīng)用調(diào)用緩存報錯：READONLYyou can’t write against a read only salve，大量寫入操作失敗。

圖表 2 分布式緩存“READONLY”報錯

故障分析

（1）在10.145.***.7、10.145.***.11接入機(jī)上出現(xiàn)網(wǎng)絡(luò)狀態(tài)波動，使得監(jiān)控端口探測失效、應(yīng)用連接失敗、應(yīng)用報錯。

（2）10.145.***.7、10.145.***.11 機(jī)器網(wǎng)絡(luò)恢復(fù)后，期間發(fā)生的Redis主從切換沒有寫入zookeeper，zookeeper判斷主從錯誤，同時，10.145.***.11的“接入機(jī)”出現(xiàn)故障，表象為正在運行但實際卻不可用，導(dǎo)致應(yīng)用繼續(xù)報錯，延長了故障發(fā)生時間。

圖表 3 分布式緩存故障過程示意圖

故障處理

（1）在機(jī)器網(wǎng)絡(luò)恢復(fù)后，運維人員檢查管理頁面，發(fā)現(xiàn)Redis節(jié)點和“接入機(jī)”的運行狀態(tài)全部正常，但執(zhí)行平臺測試程序，報“READONLY”錯，原因是網(wǎng)絡(luò)波動期間發(fā)生的Redis主從切換沒有寫入zookeeper，于是進(jìn)行了Redis主從切換。

（2）整個CRM集群的所有Redis節(jié)點主從切換完畢后，驗證測試程序依然在報錯，而此時zookeeper中Redis主從信息與實際信息已經(jīng)全部一致。運維人員查看客戶端監(jiān)控發(fā)現(xiàn)有一臺“接入機(jī)”的報錯顯著地高于其他接入機(jī)，于是重啟了該接入機(jī)，之后測試程序不再報錯。

圖表 4 服務(wù)恢復(fù)后的可用性測試

優(yōu)化與總結(jié)

為了更快定位問題并解決，我們優(yōu)化了巡檢方案。巡檢的優(yōu)化方案主要為增加緩存組件的巡檢項目，包括Redis主從切換狀態(tài)檢測和服務(wù)可用性探測，從而能夠快速判斷問題產(chǎn)生的環(huán)節(jié)，加快故障修復(fù)的操作流程。

方案實現(xiàn)通過Ansible腳本完成，腳本分為兩個部分，第一部分通過對比zookeeper節(jié)點信息與Redis實際主從信息是否一致來檢查主從切換是否正常；第二部分為執(zhí)行探測程序，使用4份不同的環(huán)境配置信息，每份配置信息對應(yīng)一臺接入機(jī)，保持其它不變，只改變“接入機(jī)”的地址，既可以檢查服務(wù)可用性，又可以確保通過每臺“接入機(jī)”連接Redis進(jìn)行讀寫都不會報錯。

主從切換狀態(tài)檢測

Redis主從切換狀態(tài)是否正常的判別標(biāo)準(zhǔn)是，登入zookeeper，進(jìn)入到/apps/cache/redisSets/CRM_REDIS_001目錄，檢查每一個master節(jié)點前的IP地址是否與實際的主節(jié)點一致。

舉例：

實際為10.145.***.5:**00為主，10.145.***.4:**00為從

/app/ctgcache/cache_apps/redisEntites/redis/src/redis-cli-h 10.145.***.5 -p **00 -a VI9IAMzX info replication

圖表 5 Redis主從信息