OVH遭遇伺服器冷卻液泄漏事故 導致長達24小時服務中斷

近日，一套外部水冷系統發生冷卻液泄漏事故，直接導致OVH公司在巴黎數據中心內的一台戴爾-EMC VNX存儲陣列遭受損壞，進而引發超過5000個網站在接下來的24小時內無法正常訪問。冷卻液泄漏給該公司位於巴黎數據中心內的VNX陣列帶來滅頂之災。

OVH公司為目前全球第三大互聯網託管廠商，其在世界17個國家擁有20座數據中心以及多達26萬台伺服器，其中託管著約1800萬款Web應用程序。

此次事故發生於6月29日晚7點左右，直接影響到OVH公司位於巴黎的P19數據中心——這亦是該公司於2003年建立的首座數據中心。不過其規模隨後被位於格拉沃利納的新數據中心所超越，後者為目前歐洲最大數據中心，部署有約40萬台伺服器。

OVH公司在其P19數據中心之內採用自主研發的水冷解決方案。冷卻液經由伺服器機架及其它部件通過組件級熱交換裝置進行循環冷卻，且與頂架式水箱熱交換裝置相對接。在完成一輪循環後，其與地下水進行熱交換以實現自身冷卻。這套方案能夠有效替代以空調系統為核心的風冷機制，從而節約大量電力。

OVH公司機架水冷系統

根據事故記錄顯示，P19數據中心亦在地下室內部署有多台設備，負責通過外界空氣實現冷卻效果。

OVH公司於2012年從EMC手中購買了數台VNX 5400陣列。此次發生事故的陣列在其三台機架當中裝有96塊SSD、15套本地磁碟架以及標準的主動-主動控制器對。該公司表示：「這套架構的設計目標在於確保數據的本地可用性以及數據控制器與磁碟的強大容錯能力。」

在此之後，該公司又陸續開發出新的解決方案，其被應用于格拉沃利納數據中心，能夠通過非專用商業陣列配合Ceph與ZFS以擺脫對專用設備的依賴。事實上，此次受到影響的陣列原本也已經被納入清退計劃。這兩台VNX陣列作為資料庫伺服器使用，負責為託管網站的動態頁面提供數據、用戶相關信息以及博客平台中的文章文本與評論內容。

根據事件報告撰文，「6月29日星期四下午6:48，P19數據中心內的3號機房中，由於水冷系統的塑料軟管發生破裂，因而導致冷卻液泄漏至伺服器系統之內。」

「我們兩套專用存儲托架（機架）中的一套並未使用水冷機制，但由於位置毗鄰而受到影響，並直接引發電氣故障，最終造成該托架徹底關閉。」

OVH公司承認其將兩種採用不同冷卻機制的伺服器安裝在同一機房之內是個錯誤。「我們做出了錯誤的判斷，我們本應為這些存儲設施提供最大程度的保護，正如我們在其它站點中所做的那樣。」

故障，又見故障

在此之後，音頻警報系統內發生的故障則更為複雜。能夠檢測機架內液體的探針確實在整座數據中心之內廣播了音頻警報消息。然而由於此前未能成功為該系統添加多語言支持功能，因此其警報時間點相較泄漏事故出現了延遲，並最終造成長達11分鐘的時間間隔。

當天晚6：59，工作人員嘗試重啟該陣列。當天晚9：25，工作人員未能成功完成重啟，並決定採取雙管齊下的處理方式——繼續嘗試重啟該故障陣列（A計劃），同時嘗試利用備份將其數據恢復至輔助系統（B計劃）。

A計劃

當晚8：00，OVH方面向戴爾-EMC公司撥打求電話，並最終完成了陣列重啟。然而，運行20分鐘後由於安全機制被觸發，陣列再度陷入停止狀態。面對這樣的情況，OVH公司技術人員決定從法國魯貝數據中心內選定第三台VNX 5400陣列並將受影響設備上的磁碟驅動器轉移至新機架當中，從而替換髮生故障的電源模塊及控制器。

來自魯貝數據中心的這套系統於次日清晨4:30被運送至巴黎數據中心，6：00全部磁碟驅動器轉移完成。同日早7：00，替代系統啟動完成，但遺憾的是磁碟上的數據仍然無法訪問。OVH於早8：00再次聯繫戴爾-EMC技術支持人員，並申請了現場服務。

B計劃

B計劃使用的資源來自一套日常備份方案，OVH方面指出「這是一套全局基礎設施備份，屬於我們業務恢復計劃中的組成部分，而非客戶能夠直接訪問的資料庫快照。」

「進行數據恢復不僅意味著需要將備份數據由冷存儲介質遷移至共享託管技術平台中的空餘空間內，同時說需要對整體生產環境進行重建。」

具體來講，為了完成數據恢復，OVH公司需要：

• 在P19數據中心之內從現有伺服器上找到充足的可用存儲空間。
• 遷移整套支持服務運行環境（即負責運行資料庫的虛擬機、相關操作系統、其特定軟體包以及配置文件）。
• 將數據遷移至新的託管基礎設施當中。

這一流程此前雖然進行過基礎測試，但卻從未以高達5萬個網站的規模進行實際操作。整個流程通過腳本實現，且直到次日凌晨3：00，虛擬機克隆工作才正式開始進行。

次日早9：00，已經有20%的實例得以恢復。時間繼續推移，「次日晚23：40，最後一個實例的恢復工作終告完成，所有用戶皆可正常訪問其站點。惟一的問題在於，部分用戶原本託管的MySQL 5.1實例被恢復成了MySQL 5.5版本。」

後見之明

很明顯，受影響陣列的災難恢複流程並不順利。而且儘管OVH公司的技術支持人員表現出色，但這種狀況本可以得到避免。

VNX陣列被安裝在了錯誤的機房當中，除此之外，其還缺少必要的故障轉移規劃。事實上，主動災難恢復計劃與測試並未能起到應有的作用。

與受影響用戶間的溝通亦飽受詬病，OVH公司的表現相當消極。「作為事件的起源，水冷系統冷卻液泄漏讓我們徹底陷入了恐慌。」

我們該從中總結出哪些經驗？

• 不要將存儲陣列與液體同置一室。
• 面向全部關鍵性系統組件建立完善的災難恢復計劃與測試方案。
• 應定期進行審查以配合系統組件的更換。
• 除非對更新規程進行嚴格測試，否則不要輕易對關鍵性系統組件加以更新。

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