進階丨經過性能測試發現存儲高可用切換問題及分析優化

本文轉自@TWT社區，【做者】楊建旭。

【摘要】本文介紹在有業務壓力下的存儲高可用切換測試，從中發現的影響切換時間的問題，以及對問題的分析。

通常狀況下，咱們壓力測試關注的都是交易系統吞吐量、業務的響應時間，批處理系統的處理時間，可是咱們不多關注某一個計算機部件的故障而致使的高可用切換過程的業務中斷時間，以及切換過程當中的性能表現。這其實也是咱們性能測試所關注的，由於在有壓力和沒有壓力的狀況下，這個業務中斷的時間是不同的；切換過程和正常處理過程當中系統性能的表現也是不同的。

本文介紹在有業務壓力下的存儲高可用切換測試，從中發現的影響切換時間的問題，以及對問題的分析。

1、 存儲服務器高可用的類型

存儲的高可用類型不少，先來介紹一種存儲的高可用類型 GAD

鏈接備存儲也相似，但不論應用指向主存儲仍是備存儲，先落盤的都是主存儲。然而這些不是本文的關鍵。

2、 單臺故障後會發生什麼？

當主存儲故障，備存儲會自動切換爲主存儲（改變了身份），而且應用會經過多路徑軟件識別出主存儲故障（當到達超時時間），切換到備存儲。

當備存儲故障，應用也會經過多路徑軟件識別出備存儲故障，把 IO 路徑切換到主存儲。

3、 測試結果

在這個測試當中，咱們除了關注咱們一般所關注的必定吞吐量狀況下業務響應時間、數據庫 IO 響應時間、磁盤 IO 響應時間，咱們還會關注單臺存儲故障後的切換時長和切換過程的性能表現。

下面是帶着壓力，存儲高可用切換過程當中的 CPU 利用率的圖。

在主存儲故障後大約 40 多秒後，彷佛應用發現了主存儲故障，以後切到備存儲作業務，但彷佛直到 3 分鐘以後，業務量才徹底起來，中間 40 秒 ~3 分鐘的過程當中，有毛刺狀 CPU 。但即便是吞吐量恢復以後，仍然偶爾有吞吐量忽然降低的狀況。

4、 問題分析

通常來講，存儲高可用的過程 40 秒就足夠了，咱們作了 LVM 模式高可用的測試，的確在 40 秒完成存儲切換，那麼：

一、爲何 GAD 切換時間比 LVM 長？
首先從原理上講， LVM 模式是這樣的

都是主存儲，一個存儲壞了，只要應用本身發現了，多路徑軟件直接切到另外一個存儲就大功告成了。

而 GAD 的主存儲出了故障，不但應用要把路徑切換到備存儲，而且，存儲自己要作調整。即備存儲要把本身的身份變成主存儲。爲何要變身份呢？由於，在一個存儲故障的狀況下，寫 IO 的邏輯也和平時不同。仲裁要告訴備存儲，你如今變成主了，並且是沒有備機的主機。

這麼一來，就會多一些時間上的耽擱。固然，這個耽擱也本不應這麼長（ 2 分鐘）

二、 爲何有 CPU 的毛刺， 3 分鐘以後才徹底恢復
這是這個 CPU 圖中的疑點。明明故障發生 40 秒以後，已經在備存儲上看到了有 IO 讀寫，而且，業務系統也開始作業務了，爲何 CPU 忽高忽低呢？業務的吞吐量也沒有徹底起來，直到 3 分鐘之後。

那麼，咱們作個推理：

1） CPU 高的時候，是有業務作成功，便可以作寫 IO ，而 CPU 低的時候，沒有業務作成功，即不能作寫 IO 。

2） 那麼爲何有時候能寫 IO ，有時不能寫呢？

是否是由於業務系統中用到了多個 LUN ，這些 LUN 並非同一時間在備存儲啓動的，而是一個一個慢慢啓動的？

這個推理其實很好理解，由於，咱們在 Windows 開機的時候，很早就能夠看到 Windows 的桌面了，但這時候開啓應用可能失敗。由於 Windows 爲了讓用戶體驗更高，採用了先展現桌面，後面慢慢啓動那些服務的策略。那麼存儲系統是否是也是這樣的呢？

咱們作一個小實驗，把業務系統寫日誌的那個盤（ LV ），在建盤的時候，把它條帶化（打散）到 3 個 LUN 上面。寫日誌時候，在 LUN1 寫 4M 數據（舉例），以後就切到 LUN2 上寫數據，寫滿 4M 以後，又去 LUN3 上面寫。

注：應用的邏輯是，業務完成的標誌是寫日誌完成，若是寫不了日誌，這個業務就 Hang 住。

這個圖就完美的驗證了上面的猜測。

CPU 明顯的忽高忽低就是業務量時而有，時而沒有，對應的就是日誌一下子能夠寫，一下子不能寫。
爲何時而不能寫呢？由於寫完 LUN1 ，要切換到 LUN2 上面寫，而 LUN2 這時候尚未在存儲層面完成主備切換，應用在下 IO 的時候，存儲才意識到本身這個 LUN 應該作切換了，並且應該儘快切換（有點像催單的意思），以後 LUN2 優先完成啓動，繼續作業務。以此類推， LUN3 也是同樣。

5、 調優

基於上述猜測，如何作調優呢？

1） 多路徑軟件（ HDLM ）探測存儲是否活着，有一個超時時間的設置。把這個超時時間縮短，能夠儘早發現存儲的故障。

2） 讓存儲本身儘早發現本身的故障。多路徑軟件中有一個 HealthCheck 的選項，大概的意思是每隔多久去看一看本身的 LUN 是否是還活着。若是不活着就在另外一臺存儲上把對應的備份激活。把這個 HealthCheck 的時間縮短，從默認的 60 分鐘改成 1 分鐘。那麼存儲在發生故障最多一分鐘以後，將得到消息，並把故障的 LUN 在另外一臺存儲上拉起。

6、 調優後的結果

完美的驗證。

中斷時間只有不到一分鐘，恢復以後也沒有出現吞吐量忽然降低的狀況。

7、 後續

事實上，這實際上是 GAD 在某個 AIX 版本上的 bug ，但經過這樣的性能測試，咱們不但發現了 bug ，還經過外部的參數優化了切換的效果。