故障：一場由虛擬化存儲引發的分散式緩存性能悲劇

記得在網上曾經看到過這麼一句話：

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

假如把這句話與運維工作關聯起來，多數的意外，也許不是天災，而是人禍。

今天分享的就是在主備機房遷移後，由於在虛擬化上缺乏經驗，外加跨團隊間的溝通盲區，最終引爆了一場分散式緩存的性能悲劇。

- 01. 故障發生 -

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

在未能實現 「理論完美型」 監控體系之前，任何一個分散式系統的故障定位都是相當費力而複雜的，由於系統是分布化的，故障也是分布化的，尤其是基礎共享服務，一旦引爆，將一觸即潰。

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

圖1. 部分相關係統訪問流程示意圖

根據上面的示意圖，引發故障的罪魁禍首是「賬戶系統的緩存切片發生 『莫名』 的性能下降，導致產生了阻塞」。

賬戶系統，在整個系統鏈路中更為基礎，所以一旦性能、穩定性下降，將引發多米諾骨牌式效應。

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

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

為在最短時間內恢復，我們採取了如下2個臨時緩釋手段。

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

暴力限流：將一部分的網路接入進行攔截，從而減小對資料庫造成的壓力。

然而，在PaaS、容錯及動態伸縮等機制都不完善的情況下，當出現類似故障時，除採取 「舍卒保車」 的暴力手段之外，也沒有更立竿見影的方法。

- 02. 故障原因 -

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

網路問題：新機房帶寬擁塞……是不是網路有問題？

硬體問題：交換機壞了？ 虛擬機資源 「超賣」？

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

架構問題：Redis、Sentinel、Proxy哪裡又出BUG了？

隨著這四個問題被陸續排除之後，我們又通過 「訪問鏈路監控」 的分析功能進行排查，結果發現了蹊蹺。

可能導致性能下降的原因。下圖來自 ELK 的 日誌分析。

圖2. 賬戶系統 - 某Redis節點的iostat情況

圖3. 賬戶系統 - 某Proxy節點的iostat情況

圖5. 賬戶系統 - 緩存鏈路的某時間段監控數據

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

圖6. 賬戶系統 - 某Redis節點的iostat命令結果

圖7. 賬戶系統 - 某Redis節點I/O飆高時的異常進程

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

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

原機房：緩存服務使用的是本地磁碟管理模式。

現機房：VSAN-池化共享數據存儲，導致某些高I/O應用與緩存服務之間產生I/O交叉影響。

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

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

原機房：緩存服務的虛擬機被部署在獨立的硬體之上。

現機房：部分Redis與Proxy，與大數據服務的虛擬化節點部署在同一台物理機上，導致產生階段性資源爭搶。

圖9. 某虛擬化節點出現的CPU有規律的波動尖峰 - 分析圖

根據上面的結論，為了快速解決，我們將賬戶系統的緩存切片遷移至被臨時徵調的N台實體機上，並將磁碟切換為本地模式，系統隨之恢復正常。

- 03. 事後復盤 -

或許導致一個系統發生故障的因素有許多，除了軟體設計，還有硬體部署，當然還包括有效的跨團隊溝通。

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

答疑1：為什麼架構師在機房遷移前不知道虛擬機與磁碟的變動？

在好買，系統級設備，包括主機、操作系統、資料庫、網路、安全以及外圍設備，都歸屬於 「系統運維部」 管理。而中間件的架構設計、研發、運營以及運維部署，則屬於 「平台架構部」 的管轄範疇。

基於職責範疇，跨部門溝通會發生 「屁股決定腦袋」 的情況。

架構師：虛擬機與磁碟不歸我管，他們會保障的，應該了解我們的場景。

系統運維：這種變動提升了運維效率，也和你們說過了，你們沒提出質疑。

再從另一個視角來看，在缺乏虛擬化基礎架構（或超融合）實施經驗的前提下，架構師也未必能在遷移之初就預判到這種變動會與類似故障產生有必然的關聯性。

答疑2：為什麼要使用超融合虛擬化的設備（或技術）？本地磁碟不好嗎？

通過答疑1可以看出，為更高效的推動基礎架構從 「物理化」 至 「虛擬化」 的演變，甚至為 「雲化」 搭建通道，在不影響以Oracle為核心資料庫的大前提下，採用 「低成本、高效率、保穩定」 的技術選型是一家金融企業優先要考慮的。

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

圖10. 相比其他存儲的優勢

相比本次磁碟，基於 超融合虛擬化 - VSAN存儲自動化 方式最大的優點在於其極短的分配與回收時間，並基於磁碟的備份和恢復要比本地磁碟方便得多。

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

- 小 結 -

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

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！