一個磁碟報警後的改進思路

• 2019 年 10 月 4 日
• 筆記

這是學習筆記的第 2101 篇文章

最近和同事在梳理一個系統的改進方案，裡面也涉及到一些彙報思路和技巧，最終的方案是需要申請一些伺服器，但是整個分析的過程，是一套嚴謹的推理過程，總之是讓領導認為這是在解決問題，而不是在逃避問題，同時申請伺服器是在優化資源配置，而不是無腦一味的要資源。

問題的背景是有兩套數據倉庫集群，存儲都是以T為單位來計算的，最近碰到了一些硬體問題也發現了原本設計中的潛在問題；同時對於目前的業務增長，領導也提出了新的期望，比如計算任務要到下午才能計算完成，預期想優化到早晨，前後討論過幾次，總體感覺解決方案和思路比較牽強，雖然是解決了部分問題，但是一上來就是申請伺服器感覺還缺少一些信服力。

首先，我們應該明確這是一套高可用服務的改進方案，而不是單純的資源申請方案。整個方案的目標有兩個：

1）改進現有服務集群的問題

2）在現有基礎上優化服務的計算能力

服務集群的問題

對於現有集群的潛在問題關注，也是由最近發生的一個硬碟問題發現的，整個集群的節點有上百個，整個服務的部署是單機多實例，一台伺服器上部署有20個實例，硬碟是按照8T*10的規格去配置的，使用了RAID5,結果最近系統部同事收到了一個磁碟報警，本來這是一件很正常的事情，結果在工程師維修的時候發現另外一塊磁碟也存在潛在瓶頸，雖然沒有報警，但是通過一些方法發現已經處於損壞的邊緣，這個時候問題的優先順序就上來了，如果第2塊磁碟再發生損壞，那麼整個文件的存儲在RAID5的模式下就存在問題了。當然集群本身是有高可用機制的，但是目前的集群節點部署是按照組對稱部署的，類似如下的方式。

實際每個伺服器上面的實例數有20個，即10個primary,10個mirror,如果發生了伺服器存儲損壞，導致服務不可用，那麼原本的10個Primary節點會漂移到另外的伺服器上面，那麼從高可用層面來說是可行的。但是存在四個嚴重問題：

1）如果節點漂移到從庫，開始大量的計算任務，很可能會把整個集群跑崩，可能產生一種連鎖反應，整個節點不可用，後續導致集群不可用。

2）如果後續要修復節點，耗時過長，因為整個集群的存儲空間有近70T，要重構整個節點需要耗費的時間和成本較高，一天以內是弄不完的，而且在重構的過程中還對原有的節點存在風險。

3）整個集群的水平擴展在之前缺少嚴格的演練和測試，儘管從哪理論上可行，但是集群現在已經具備規模，不能接受未經評估驗證的方案。

4）雖然後續做了磁碟修復，但是單塊磁碟的空間過大，導致rebuild的耗時差不多在13個小時，如果這個期間出現磁碟問題，就前功盡棄了。

所以在這個過程中發現了一些很明顯的問題，也有一些改進措施。

1）對於磁碟的配置，建設設置為RAID5+hotspare的模式，至少可以容忍壞兩塊盤。

2）集群的節點設計屬於過度設計，早期更多考慮了功能和性能，而對可用性的考慮有所欠缺

服務計算優化的背景

目前的業務增長量超過預期5倍，隨著業務需求的接入，對於服務可用性的要求也越來越高，部分業務從原本的T+1模式升級為近實時的數據分析，而一些業務的優先順序也隨著需求的接入而顯得更加重要，比如在指定的時間前需要提供好指定的數據分析結果，這屬於公司運營的重要參考指標。

在現有的情況下，我們經過上述的評估，發現原有的問題需要改進，同時業務的優先順序提升，計算能力目前還難以擴展。所以在現有的資源配置下，是難以實現上述的兩個需求的。

我們可以設計如下的改進策略。

1）充分利用現有的資源，比如測試資源等。

2）對現有的集群問題進行優化和改進

3）業務層實現雙活需求，比如某個集群真不可用，我們可以較為平滑的把計算任務遷移到另一個集群開始計算，不應該碰到卡脖子的情況。

所以這個方案的一種合理解決思路就是申請一個新的集群，分為如下的幾個步驟：

1）集群1–遷移到–新集群

2）集群1進行重構，已有的歷史數據可以通過ETL重建

3）集群2–遷移到–集群1

4）集群2重構

5）集群資源重構和優先順序配置

整體來說，能夠解決現有問題，也能夠優化資源的配置。算是一種合理的解決方案。