這是學習筆記的第 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）叢集資源重構和優先級配置
整體來說，能夠解決現有問題，也能夠優化資源的配置。算是一種合理的解決方案。