記得在網(wǎng)上曾經(jīng)看到過這么一句話：

明天和意外不知道哪一個先來，在天災(zāi)面前我們都很渺小。

假如把這句話與運維工作關(guān)聯(lián)起來，多數(shù)的意外，也許不是天災(zāi)，而是人禍。

今天分享的就是在主備機房遷移后，由于在虛擬化上缺乏經(jīng)驗，外加跨團隊間的溝通盲區(qū)，最終引爆了一場分布式緩存的性能悲劇。

[[224572]]

- 01. 故障發(fā)生 -

在機房切換后的第一個工作日，無論是APP端，還是PC端，所有用戶均出現(xiàn)登錄、開戶、交易緩慢的現(xiàn)象，甚至有部分用戶直接收到錯誤碼返回。

在未能實現(xiàn) “理論完美型” 監(jiān)控體系之前，任何一個分布式系統(tǒng)的故障定位都是相當(dāng)費力而復(fù)雜的，由于系統(tǒng)是分布化的，故障也是分布化的，尤其是基礎(chǔ)共享服務(wù)，一旦引爆，將一觸即潰。

言歸正傳，在人肉運維與半自動工具的努力之下，最終確定了瓶頸點，下面通過簡單的示意圖進行展示。

圖1. 部分相關(guān)系統(tǒng)訪問流程示意圖

根據(jù)上面的示意圖，引發(fā)故障的罪魁禍?zhǔn)资恰纲~戶系統(tǒng)的緩存切片發(fā)生 ‘莫名’ 的性能下降，導(dǎo)致產(chǎn)生了阻塞」。

賬戶系統(tǒng)，在整個系統(tǒng)鏈路中更為基礎(chǔ)，所以一旦性能、穩(wěn)定性下降，將引發(fā)多米諾骨牌式效應(yīng)。

圖中上鏈路：1、2、3點，直接影響開戶、登錄等業(yè)務(wù)場景。

圖中下鏈路：1、2、3、4點，間接影響交易、支付等業(yè)務(wù)場景。

為在最短時間內(nèi)恢復(fù)，我們采取了如下2個臨時緩釋手段。

暴力降級：將一部分的應(yīng)用請求從Redis切到Oracle集群。

暴力限流：將一部分的網(wǎng)絡(luò)接入進行攔截，從而減小對數(shù)據(jù)庫造成的壓力。

然而，在PaaS、容錯及動態(tài)伸縮等機制都不完善的情況下，當(dāng)出現(xiàn)類似故障時，除采取 “舍卒保車” 的暴力手段之外，也沒有更立竿見影的方法。

- 02. 故障原因 -

簡而言之，在故障發(fā)生之時，在懵逼的同時，我們的腦海中閃過一些猜測

網(wǎng)絡(luò)問題：新機房帶寬擁塞……是不是網(wǎng)絡(luò)有問題？

硬件問題：交換機壞了？ 虛擬機資源 “超賣”？

安全問題：被黑客攻擊？DDoS？

架構(gòu)問題：Redis、Sentinel、Proxy哪里又出BUG了？

隨著這四個問題被陸續(xù)排除之后，我們又通過 “訪問鏈路監(jiān)控” 的分析功能進行排查，結(jié)果發(fā)現(xiàn)了蹊蹺。

可能導(dǎo)致性能下降的原因。下圖來自 ELK 的 日志分析。

圖2. 賬戶系統(tǒng) - 某Redis節(jié)點的iostat情況

圖3. 賬戶系統(tǒng) - 某Proxy節(jié)點的iostat情況

圖5. 賬戶系統(tǒng) - 緩存鏈路的某時間段監(jiān)控數(shù)據(jù)

跟著這條線索，再進入服務(wù)器進行查看。下圖來自 Linux 的 命令行。

圖6. 賬戶系統(tǒng) - 某Redis節(jié)點的iostat命令結(jié)果

圖7. 賬戶系統(tǒng) - 某Redis節(jié)點I/O飆高時的異常進程

可以基本斷定，導(dǎo)致緩存性能下降的“元兇”正是I/O，但在Redis未開啟持久化功能項的前提下，原因主要可以歸因為以下這些。

1、遷移機房時，磁盤管理模式有變動

原機房：緩存服務(wù)使用的是本地磁盤管理模式。

現(xiàn)機房：VSAN-池化共享數(shù)據(jù)存儲，導(dǎo)致某些高I/O應(yīng)用與緩存服務(wù)之間產(chǎn)生I/O交叉影響。

圖8. 新機房采用VMWare vSphere 超融合虛擬化磁盤管理模式

2、遷移機房時，虛擬機部署方式有變動

原機房：緩存服務(wù)的虛擬機被部署在獨立的硬件之上。

現(xiàn)機房：部分Redis與Proxy，與大數(shù)據(jù)服務(wù)的虛擬化節(jié)點部署在同一臺物理機上，導(dǎo)致產(chǎn)生階段性資源爭搶。

圖9. 某虛擬化節(jié)點出現(xiàn)的CPU有規(guī)律的波動尖峰 - 分析圖

根據(jù)上面的結(jié)論，為了快速解決，我們將賬戶系統(tǒng)的緩存切片遷移至被臨時征調(diào)的N臺實體機上，并將磁盤切換為本地模式，系統(tǒng)隨之恢復(fù)正常。

- 03. 事后復(fù)盤 -

或許導(dǎo)致一個系統(tǒng)發(fā)生故障的因素有許多，除了軟件設(shè)計，還有硬件部署，當(dāng)然還包括有效的跨團隊溝通。

所以，除了歸因分析之外，利用復(fù)盤答疑的方式，對整個事件的過程進行了梳理，希望這種梳理能夠幫助我們理清思路。

答疑1：為什么架構(gòu)師在機房遷移前不知道虛擬機與磁盤的變動？

在好買，系統(tǒng)級設(shè)備，包括主機、操作系統(tǒng)、數(shù)據(jù)庫、網(wǎng)絡(luò)、安全以及外圍設(shè)備，都歸屬于 “系統(tǒng)運維部” 管理。而中間件的架構(gòu)設(shè)計、研發(fā)、運營以及運維部署，則屬于 “平臺架構(gòu)部” 的管轄范疇。

基于職責(zé)范疇，跨部門溝通會發(fā)生 “屁股決定腦袋” 的情況。

架構(gòu)師：虛擬機與磁盤不歸我管，他們會保障的，應(yīng)該了解我們的場景。

系統(tǒng)運維：這種變動提升了運維效率，也和你們說過了，你們沒提出質(zhì)疑。

再從另一個視角來看，在缺乏虛擬化基礎(chǔ)架構(gòu)（或超融合）實施經(jīng)驗的前提下，架構(gòu)師也未必能在遷移之初就預(yù)判到這種變動會與類似故障產(chǎn)生有必然的關(guān)聯(lián)性。

答疑2：為什么要使用超融合虛擬化的設(shè)備（或技術(shù)）？本地磁盤不好嗎？

通過答疑1可以看出，為更高效的推動基礎(chǔ)架構(gòu)從 “物理化” 至 “虛擬化” 的演變，甚至為 “云化” 搭建通道，在不影響以O(shè)racle為核心數(shù)據(jù)庫的大前提下，采用 “低成本、高效率、保穩(wěn)定” 的技術(shù)選型是一家金融企業(yè)優(yōu)先要考慮的。

我們來看下 超融合虛擬化 - VSAN存儲自動化 能帶來哪些運維優(yōu)勢。

圖10. 相比其他存儲的優(yōu)勢

相比本次磁盤，基于 超融合虛擬化 - VSAN存儲自動化 方式最大的優(yōu)點在于其極短的分配與回收時間，并基于磁盤的備份和恢復(fù)要比本地磁盤方便得多。

對于分布式緩存這種場景而言，只能算是一種特殊要求。

- 小   結(jié) -

好了，又到了講大道理的時間了。相信通過這篇案例的分享，您應(yīng)該已經(jīng)明白了整個事件的始末原由，此時此刻，或許吐槽聲、贊嘆聲、嘲笑聲會游蕩在不同人的心中，無論出于哪種目的，希望這篇分享能夠給您帶來一些幫助。