騰訊云磁盤故障導致“前沿數控”數據丟失一事，有關各方進行了一系列解讀，但大多沒有擺脫借題炒作之嫌，真正地技術解讀倒是被棄之一旁，這也是一種悲哀！

在國內環境條件下，對于故障進行技術解讀是一個很困難的事情，主要障礙在于事件的信息披露，牽涉到追責的問題，當事方常常不能如實透露事件真相，從而讓技術解讀成為了無源之水。

為騰訊云點贊！

與國內大多數故障事件不同，騰訊云對于云磁盤故障信息披露，實事求是的態度值得點贊！

試想如果騰訊云堅持以“部分云硬盤IO異常”為由進行搪塞，那么真相就不會公之于眾，更談不上什么技術分析。就像人會生病一樣，IT系統會發生故障，其實是最正常不過的事情，沒有什么好隱瞞的！

在8月8日聲明中，騰訊云故障進行了還原。

首先是云存儲系統擴容要進行數據遷移，在數據遷移過程中，為了追求速度，人為/運維違章操作，沒有進行數據校驗，原有數據過早刪除。恰逢磁盤靜默錯誤，導致數據無法恢復！

這里提到了磁盤靜默錯誤，簡單說就是數據處理過程都是正常的，但是使用時才會發現數據錯誤，造成靜默數據錯誤，磁盤本身的原因主要是固件錯誤以及硬盤介質本身的原因（如噪聲、電磁等）。

橫向擴展和數據遷移

此次故障原因清楚了，但也衍生、延展出來更多技術話題。

首先，數據遷移是由存儲系統擴容引起的。對于云存儲來說，不是橫向擴展Scale out嗎？擴容就是了，為什么要進行數據遷移呢?

這是一個非常有意思的話題。

為此，我也請教了軟件定義存儲的專業廠商，得到鵬云網絡、華云網際等廠商專家的支持！在技術方面，他們是很有實力的廠商。以鵬云網絡為例，創始人陳靚曾長期擔任美國亞馬遜AWS 核心構架師，帶領團隊進行 S3 云存儲系統深度優化，并主持 Glacier 存儲系統的設計和研發。

專家提示說，軟件定義存儲或者稱云存儲有不同的技術實現方式，有Paxos /Raft 、Zookeeper、DHT（Distributed Hash Table）等不同元數據管理方法。

其中，DHT是根據一致性哈希的方式計算出來，其好處是極大降低了元數據服務存儲壓力和訪問壓力。但弱點在于對于容量規模要有很好的預計，如果涉及添加節點，移除節點，添加磁盤，移除磁盤的情況，由于哈希環會發生變化，一部分數據需要重新分布，會在集群中產生不必要的數據遷移，而且數據量往往非常大。

這也是為什么，有推測認為騰訊云存儲采用了DHT方式來構建，當然推測未經過證實。

實際上，即使不采用DHT。云存儲單一資源池的規模也是有上限的，也就是說，集群內節點數量是由最佳實踐的。以VSAN為例，有64個節點數量的限制；Ceph（DHT）是256，超過出這個限，節點之間網絡通信的復雜度，以及效率都難以得到保障。

對于騰訊云存儲來說，對外提供公有云服務，同時支持多個用戶，數據規模和增長速度達到上限，這是可以想象的事情。因此，數據遷移在所難免！這一點，鵬云網絡、華云網際的專家都是肯定的。

數據遷移的話題

專家指出：數據遷移不是災難，磁盤靜默錯誤也不是大問題，甚至違章操作關閉檢驗也不是致命的問題！

那么數據是怎么丟的呢？

實際上，磁盤靜默錯誤是非常小概率的事件，是個別磁盤問題。要知道云存儲數據有多副本保護，完全可以應對小概率事件導致的錯誤。

試想一下，如果是對云存儲系統進行完整的數據遷移，即使關閉了校驗，仍然有三副本(或者兩副本)數據存儲，應該可以應對磁盤靜默錯誤。

那么，副本為什么沒有發揮作用呢？

據專家推測，其數據遷移的過程并沒有進行完整的數據遷移；估計就是遷移了主數據樣本，并制作了三副本保護，遷移過程違章關閉了檢驗。如果主數據有誤，其制作的副本數據也是錯誤的。加上，原有數據刪除過早，造成了難以挽回的錯誤。

所以數據遷移、靜默錯誤、關閉校驗都不是問題的元兇！一系列問題疊加才是數據丟失的根本原因。

試想，騰訊云支持租戶眾多，為什么只有“前沿數控”中招了呢？只能說這是一個小概率事件！

“對于云存儲或稱軟件定義存儲，高性能和高可擴展度是必須考慮的因素，以鵬云ZettaStor DBS為例，可從幾臺服務器起步，擴展至上百萬臺服務器規模 , 且保持穩定和高性能。從底層進行磁盤性能優化，實現了同樣數量磁盤3倍以上的性能表現。”專家說。

全流程數據校驗更是需要著重考慮問題。分布式緩存一致、全流程數據校驗、磁盤修復等全方位技術手段，也是鵬云ZettaStor DBS的顯著特征。

快照和備份的話題

當事件發生之后，數據保護肯定是一個繞不開的話題。

很可悲的是，美國服務器租用，很多云租戶會認為：備份、快照是云存儲天生具備的屬性，這樣的想法就太天真了。

一來不是所有的應用都需要保護的；二來如果作為默認的屬性，那么由此導致的價格提升，這是用戶愿意承受的嗎？