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

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

為騰訊云點贊！

與國內(nèi)大多數(shù)故障事件不同，騰訊云對于云磁盤故障信息披露，實事求是的態(tài)度值得點贊！

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

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

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

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

橫向擴展和數(shù)據(jù)遷移

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

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

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

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

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

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

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

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

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

數(shù)據(jù)遷移的話題

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

那么數(shù)據(jù)是怎么丟的呢？

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

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

那么，副本為什么沒有發(fā)揮作用呢？

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

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

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

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

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

快照和備份的話題

當事件發(fā)生之后，數(shù)據(jù)保護肯定是一個繞不開的話題。

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

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

有人指出：作為一家1000萬元業(yè)務規(guī)模的公司，“前沿數(shù)據(jù)”不知都對數(shù)據(jù)進行保護，數(shù)據(jù)處于近乎“裸奔”的狀態(tài)，這樣的經(jīng)營意識也是沒誰了！咎由自??！

類似的事情很多，很多時候，也不是水平和意識的問題，還是跟錢有關系。

數(shù)據(jù)保護是要花錢的！而且應對的是小概率事件！

鋌而走險，有時候也是無奈之舉。

那么，騰訊云不是提供了免費的快照服務嗎？

既然，如此當事者就應該責怪自己，為什么不在快照的選項上打個√呢？即使打了√，用戶也應該知道并不是萬事大吉的。

快照有它的作用和限制。

首先，沒有辦法***制的打快照，因為會影響性能；二來，快照只是記錄了磁盤數(shù)據(jù)變化的一種狀態(tài)，數(shù)據(jù)恢復需要依賴磁盤原始的數(shù)據(jù)；單純依賴快照是沒有辦法恢復數(shù)據(jù)的。

有關數(shù)據(jù)備份，所針對的包括硬件故障，其這一點的作用和副本是相同；不同之處在于，數(shù)據(jù)備份還可以針對邏輯故障，在這種情況下，錯誤不是硬件造成的，而是人員操作失誤造成的，如輸入錯誤，刪錯數(shù)據(jù)等。借助快照、日志等數(shù)據(jù)備份，可以對錯誤進行修正。

一句話，不同的應用需要不同的數(shù)據(jù)保護。從雙活數(shù)據(jù)中心，到CDP、備份，等級不同，效果和作用也不同，當然其費用支出也不同。因此，鋌而走險也是可以的，需要的前提是：你的運氣足夠好！

小結(jié)

亡羊補牢，從中汲取教訓是當務之急！

但是更加重要的，還是應該是對于技術的掌握和了解！相同的是：它們都叫軟件定義存儲或者云存儲，不同的是，他們的技術方案不盡相同。以校驗為例，鵬云網(wǎng)絡的方案設計、華云網(wǎng)際、VASN、Ceph的方案設計各不相同。

對于這些不同設計方案的選型，其實沒有捷徑的方法可以選擇！惟有不斷地了解技術，并根據(jù)應用的實際情況加以選擇，別無他法！