- 數(shù)據(jù)庫(kù)維護(hù)
-
記得在網(wǎng)上曾經(jīng)看到過(guò)這么一句話:
明天和意外不知道哪一個(gè)先來(lái),在天災(zāi)面前我們都很渺小。
假如把這句話與運(yùn)維工作關(guān)聯(lián)起來(lái),多數(shù)的意外,也許不是天災(zāi),而是人禍。
今天分享的就是在主備機(jī)房遷移后,由于在虛擬化上缺乏經(jīng)驗(yàn),外加跨團(tuán)隊(duì)間的溝通盲區(qū),最終引爆了一場(chǎng)分布式緩存的性能悲劇。
- 01. 故障發(fā)生 -
在機(jī)房切換后的第一個(gè)工作日,無(wú)論是APP端,還是PC端,所有用戶均出現(xiàn)登錄、開(kāi)戶、交易緩慢的現(xiàn)象,甚至有部分用戶直接收到錯(cuò)誤碼返回。
在未能實(shí)現(xiàn) “理論完美型” 監(jiān)控體系之前,任何一個(gè)分布式系統(tǒng)的故障定位都是相當(dāng)費(fèi)力而復(fù)雜的,由于系統(tǒng)是分布化的,故障也是分布化的,尤其是基礎(chǔ)共享服務(wù),一旦引爆,將一觸即潰。
言歸正傳,在人肉運(yùn)維與半自動(dòng)工具的努力之下,最終確定了瓶頸點(diǎn),下面通過(guò)簡(jiǎn)單的示意圖進(jìn)行展示。
圖1. 部分相關(guān)系統(tǒng)訪問(wèn)流程示意圖
根據(jù)上面的示意圖,引發(fā)故障的罪魁禍?zhǔn)资恰纲~戶系統(tǒng)的緩存切片發(fā)生 ‘莫名’ 的性能下降,導(dǎo)致產(chǎn)生了阻塞」。
賬戶系統(tǒng),在整個(gè)系統(tǒng)鏈路中更為基礎(chǔ),所以一旦性能、穩(wěn)定性下降,將引發(fā)多米諾骨牌式效應(yīng)。
圖中上鏈路:1、2、3點(diǎn),直接影響開(kāi)戶、登錄等業(yè)務(wù)場(chǎng)景。
圖中下鏈路:1、2、3、4點(diǎn),間接影響交易、支付等業(yè)務(wù)場(chǎng)景。
為在最短時(shí)間內(nèi)恢復(fù),我們采取了如下2個(gè)臨時(shí)緩釋手段。
暴力降級(jí):將一部分的應(yīng)用請(qǐng)求從Redis切到Oracle集群。
暴力限流:將一部分的網(wǎng)絡(luò)接入進(jìn)行攔截,從而減小對(duì)數(shù)據(jù)庫(kù)造成的壓力。
然而,在PaaS、容錯(cuò)及動(dòng)態(tài)伸縮等機(jī)制都不完善的情況下,當(dāng)出現(xiàn)類似故障時(shí),除采取 “舍卒保車” 的暴力手段之外,也沒(méi)有更立竿見(jiàn)影的方法。
- 02. 故障原因 -
簡(jiǎn)而言之,在故障發(fā)生之時(shí),在懵逼的同時(shí),我們的腦海中閃過(guò)一些猜測(cè)
網(wǎng)絡(luò)問(wèn)題:新機(jī)房帶寬擁塞……是不是網(wǎng)絡(luò)有問(wèn)題?
硬件問(wèn)題:交換機(jī)壞了? 虛擬機(jī)資源 “超賣”?
安全問(wèn)題:被黑客攻擊?DDoS?
架構(gòu)問(wèn)題:Redis、Sentinel、Proxy哪里又出BUG了?
隨著這四個(gè)問(wèn)題被陸續(xù)排除之后,我們又通過(guò) “訪問(wèn)鏈路監(jiān)控” 的分析功能進(jìn)行排查,結(jié)果發(fā)現(xiàn)了蹊蹺。
可能導(dǎo)致性能下降的原因。下圖來(lái)自 ELK 的 日志分析。
圖2. 賬戶系統(tǒng) - 某Redis節(jié)點(diǎn)的iostat情況
圖3. 賬戶系統(tǒng) - 某Proxy節(jié)點(diǎn)的iostat情況
圖5. 賬戶系統(tǒng) - 緩存鏈路的某時(shí)間段監(jiān)控?cái)?shù)據(jù)
跟著這條線索,再進(jìn)入服務(wù)器進(jìn)行查看。下圖來(lái)自 Linux 的 命令行。
圖6. 賬戶系統(tǒng) - 某Redis節(jié)點(diǎn)的iostat命令結(jié)果
圖7. 賬戶系統(tǒng) - 某Redis節(jié)點(diǎn)I/O飆高時(shí)的異常進(jìn)程
可以基本斷定,導(dǎo)致緩存性能下降的“元兇”正是I/O,但在Redis未開(kāi)啟持久化功能項(xiàng)的前提下,原因主要可以歸因?yàn)橐韵逻@些。
1、遷移機(jī)房時(shí),磁盤管理模式有變動(dòng)
原機(jī)房:緩存服務(wù)使用的是本地磁盤管理模式。
現(xiàn)機(jī)房:VSAN-池化共享數(shù)據(jù)存儲(chǔ),導(dǎo)致某些高I/O應(yīng)用與緩存服務(wù)之間產(chǎn)生I/O交叉影響。
圖8. 新機(jī)房采用VMWare vSphere 超融合虛擬化磁盤管理模式
2、遷移機(jī)房時(shí),虛擬機(jī)部署方式有變動(dòng)
原機(jī)房:緩存服務(wù)的虛擬機(jī)被部署在獨(dú)立的硬件之上。
現(xiàn)機(jī)房:部分Redis與Proxy,與大數(shù)據(jù)服務(wù)的虛擬化節(jié)點(diǎn)部署在同一臺(tái)物理機(jī)上,導(dǎo)致產(chǎn)生階段性資源爭(zhēng)搶。
圖9. 某虛擬化節(jié)點(diǎn)出現(xiàn)的CPU有規(guī)律的波動(dòng)尖峰 - 分析圖
根據(jù)上面的結(jié)論,為了快速解決,我們將賬戶系統(tǒng)的緩存切片遷移至被臨時(shí)征調(diào)的N臺(tái)實(shí)體機(jī)上,并將磁盤切換為本地模式,系統(tǒng)隨之恢復(fù)正常。
- 03. 事后復(fù)盤 -
或許導(dǎo)致一個(gè)系統(tǒng)發(fā)生故障的因素有許多,除了軟件設(shè)計(jì),還有硬件部署,當(dāng)然還包括有效的跨團(tuán)隊(duì)溝通。
所以,除了歸因分析之外,利用復(fù)盤答疑的方式,對(duì)整個(gè)事件的過(guò)程進(jìn)行了梳理,希望這種梳理能夠幫助我們理清思路。
答疑1:為什么架構(gòu)師在機(jī)房遷移前不知道虛擬機(jī)與磁盤的變動(dòng)?
在好買,系統(tǒng)級(jí)設(shè)備,包括主機(jī)、操作系統(tǒng)、數(shù)據(jù)庫(kù)、網(wǎng)絡(luò)、安全以及外圍設(shè)備,都?xì)w屬于 “系統(tǒng)運(yùn)維部” 管理。而中間件的架構(gòu)設(shè)計(jì)、研發(fā)、運(yùn)營(yíng)以及運(yùn)維部署,則屬于 “平臺(tái)架構(gòu)部” 的管轄范疇。
基于職責(zé)范疇,跨部門溝通會(huì)發(fā)生 “屁股決定腦袋” 的情況。
架構(gòu)師:虛擬機(jī)與磁盤不歸我管,他們會(huì)保障的,應(yīng)該了解我們的場(chǎng)景。
系統(tǒng)運(yùn)維:這種變動(dòng)提升了運(yùn)維效率,也和你們說(shuō)過(guò)了,你們沒(méi)提出質(zhì)疑。
再?gòu)牧硪粋€(gè)視角來(lái)看,在缺乏虛擬化基礎(chǔ)架構(gòu)(或超融合)實(shí)施經(jīng)驗(yàn)的前提下,架構(gòu)師也未必能在遷移之初就預(yù)判到這種變動(dòng)會(huì)與類似故障產(chǎn)生有必然的關(guān)聯(lián)性。
答疑2:為什么要使用超融合虛擬化的設(shè)備(或技術(shù))?本地磁盤不好嗎?
通過(guò)答疑1可以看出,為更高效的推動(dòng)基礎(chǔ)架構(gòu)從 “物理化” 至 “虛擬化” 的演變,甚至為 “云化” 搭建通道,在不影響以O(shè)racle為核心數(shù)據(jù)庫(kù)的大前提下,采用 “低成本、高效率、保穩(wěn)定” 的技術(shù)選型是一家金融企業(yè)優(yōu)先要考慮的。
我們來(lái)看下 超融合虛擬化 - VSAN存儲(chǔ)自動(dòng)化 能帶來(lái)哪些運(yùn)維優(yōu)勢(shì)。
圖10. 相比其他存儲(chǔ)的優(yōu)勢(shì)
相比本次磁盤,基于 超融合虛擬化 - VSAN存儲(chǔ)自動(dòng)化 方式最大的優(yōu)點(diǎn)在于其極短的分配與回收時(shí)間,并基于磁盤的備份和恢復(fù)要比本地磁盤方便得多。
對(duì)于分布式緩存這種場(chǎng)景而言,只能算是一種特殊要求。
- 小 結(jié) -
好了,又到了講大道理的時(shí)間了。相信通過(guò)這篇案例的分享,您應(yīng)該已經(jīng)明白了整個(gè)事件的始末原由,此時(shí)此刻,或許吐槽聲、贊嘆聲、嘲笑聲會(huì)游蕩在不同人的心中,無(wú)論出于哪種目的,希望這篇分享能夠給您帶來(lái)一些幫助。