神秘失蹤的硬碟
一塊硬碟告警，處於「只讀」狀態…
什麼？管理員又告知，硬碟神秘失蹤了！
硬碟，去哪兒了？
悲催的故事還在上演，請繼續往下看…
這家公司目前一共有3套DIY的開源的軟體定義存儲（以下簡稱SDS）在同時運行，3個節點/5個節點/25個節點各一套，3節點和5節點的SDS均是採用利舊的伺服器，為開發測試平台提供服務。25節點的SDS中有一半是利舊的伺服器，一半是新購的伺服器，為OA、影音文件管理等平台服務。SDS軟體是我公司運維人員安裝部署的。
最初出現問題的是5節點的那套，業務系統在使用過程中，監控提示錯誤信息，經診斷，是一個節點上的一塊硬碟告警，硬碟處於只讀狀態，雖然SDS的多節點容錯架構並沒有影響應用的正常運行，但硬碟是數據的根本，一定要找到是什麼原因造成的。就在大家開會討論對策和診斷方案的時候，管理員又告知，在SDS下的這塊硬碟不見了。。。神秘失蹤？趕緊報修硬碟，800迅速介入，收日誌，檢查系統錯誤，沒壞啊，硬碟好好的閃爍著綠燈，奇怪了，硬碟去哪了？排查了架構里每一個環節，居然都顯示正常，但硬碟就是不見了......最終萬般無奈的情況下，重新啟動了一下這個節點，居然回來了，硬碟又識別到了。
故事似乎真的還在繼續，就在我們還在思考這個問題的根源所在時，25節點的集群居然真的出現了類似問題，先是一塊硬碟只讀，還沒等到重啟接連第二塊硬碟也告警，在SDS集群里兩個硬碟神秘消失。這可不是那5個節點的測試系統了，由於OA運行在這套SDS集群上，公司內部流程沒辦法通過系統造成，各個部門的人都跳出來讓運維部門儘快解決問題。於是我們想按照之前成功的辦法試著嘗試重啟節點，但問題比我們想像的還嚴重，重啟後不但SAS盤沒找到，作為緩存的SSD其中有2塊也不見了。這著實驚到了客戶，馬上開Case讓原廠後台介入，查找問題所在。但問題又來了，這套SDS系統是客戶自己搭建的，服務的真沒有。。。
此時，秉著對客戶負責的心態，Dell EMC通過內部資源，找來各路SDS的大牛們，積極幫客戶找到問題所在，避免後期使用再出現問題。經過各路高人的診斷，我們發現了一個有趣的問題，出現問題的SAS盤和SSD盤都是後期用戶自己購買添加的，他們磁碟類型在SDS的兼容表裡，而其Firmware版本卻不在，而原來第一次部署的各個節點的磁碟Firmware是和SDS完全匹配的，所以也沒出現這樣的問題。
經歷了這樣一個慘痛的經歷，我們已經意識到，雖然開源的DIY SDS採用節點集群作為容錯，但整體架構還是有安全隱患的。於是經過討論後，我們放棄原全部開源的想法，重新考量了Dell EMC公司推薦的全商用的VxRail超融合架構和半開源半商用的vSphere+VSAN方式，最終選擇了vSphere+VSAN+RP4VM+存儲的解決方案，具體如下圖所示。
方案特點1：
虛擬機方式，部署快速、簡單；
專為虛擬化環境設計；
與vCenter無縫集成；
錄像一樣記錄VM IO變化；
VM任意時間點恢復；
一致性組保證應用一致性；
存儲無關、網路無關；
支持同步和非同步保護；
支持本地和遠程容災。
方案特點2：
通過vCenter Plug-In在vSphere Web Client界面管理。
搭建完畢後，我們在這套系統上做了大量的實踐演練，通過CDP刻錄機一樣的恢復顆粒度，能夠找到最近的時間點，並且在災備的SCv3000上可以直接啟動虛擬機，業務也可以成功切換到存儲上，幾乎沒有數據的損失。
總結，無論是開源還是商用的SDS，其兼容性要求都很高，部署前需要檢查各種硬體的型號和Firmware（包含磁碟、1Gb網卡、10Gb網卡、Raid卡等），如果不經過嚴格的兼容測試，會有很多意想不到問題出現。所以客戶如果想使用SDS來承載關鍵業務，建議選擇由各大廠家提供的各種超融合或融合架構，並且通過有效的保護方式進行災備。
TAG:至頂網 |