從資料恢複角度分析騰訊雲靜默損壞

騰訊雲在這次事件中的結論表述為因受所在實體硬碟固件版本Bug導緻的靜默錯誤，檔案系統中繼資料損壞：

根據這個表述，故障應出現在硬碟固件故障導緻的檔案系統中繼資料損壞。這其中，涉及具備因果關系的三個知識點：

硬碟固件故障—>檔案系統中繼資料損壞—>檔案損壞。

在此大緻畫一下騰訊雲可能用到的存儲架構方案。

帶*号的是不一定存在的存儲鍊。事實上，這個邏輯肯定不準确，比如有些環節精減或不需要，有些環節有更詳細的設計等。但是不是和真實場景一緻不重要，重要的是，問題如果出現，總會出現在我列出的項或我沒列出的項中(廢話)，這些項是互相關聯的。

我們再重複一下現象：硬碟固件故障(層1故障)導緻的檔案系統中繼資料損壞，進而導緻部分檔案校驗出錯，導緻檔案損壞。針對現象，努力從上述10個環節比對，每一層會有可能出錯，導緻上述故障嗎：

第1層：存儲媒體

以硬碟為例，每個構成資料的最小機關扇區都會有嚴格的校驗，包括扇區頭部的CRC校驗以及位址辨別校驗。理論上，如果層1的資料出現磁力失真(或閃存狀态丢失)等比特出錯，其頭部校驗不比對時，媒體控制器就會向上層回報錯誤(一般表現為壞扇區)，上層會啟動修正模式進行修正。

當然也有例外，比如硬碟内部程式出錯，根本不按上述原則執行，忽略校驗值的情況下，任何對資料的篡改都是可以的。可以表現為騰訊所說的靜默損壞（即層1在合理的邏輯裡偷梁換柱)。這種情況，基本大帽子就能扣在硬碟固件BUG這上面了，但硬碟固件這種BUG是緻命的，等同于我們存進銀行的錢不知什麼原因變多或變少，沒有硬碟廠商站出來承認，也沒有緊急釋出BUG修複固件，完全歸因于硬碟固件，可能偏激了些(也可能事件背後有固件BUG的原因，那也應該是添油加醋型的)。

第2層：RAID

RAID自身有備援算法，可實作在部分媒體（硬碟）損壞後，由其他成員及算法控制來接管損壞硬碟的資料服務，保證上層業務不中斷，不出故障。但RAID也并非完全可靠。

一種錯誤是軟RAID中的寫漏洞(write hole)，如果是軟RAID，這無法避免，可能導緻騰訊本次事故。但軟RAID是玩具産品，自然騰訊是不會用這種方案的。

還有可能的錯誤是buffer?dirty，當緩沖資料掉電清空，或有意無意損壞後，會導緻資料出現本例的表現錯誤。但這個原因可以很容易推到控制器BUG上面，騰訊沒提及這個原因，或者是他們沒找到病根，或者的确和這個無關。

還有最可能的錯誤是RAID中超過備援數量的磁盤損壞。比如RAID5隻支援一塊盤損壞，但現實中出現了：

情形1：同時2塊或以上硬碟損壞

情形2：1塊損壞後未及時重建，第2塊又損壞

情形2出現的可能性非常大，幾乎IT類公司沒有不濕鞋的，隻是資料或不重要，或未千萬公衆效應。本次騰訊事故，情形2導緻的資料災難，不是沒有可能。想象一下，以RAID5為例，若底層RAID有硬碟壞，管理人員沒及時跟進重建，希捷負載加重後，其他硬碟壞，是非常正常的事情。更有一種情況，與硬碟固件有關，就是硬碟已經有壞道了，但并未碰觸到壞道區，這時表現一切完好，一旦重建，就會導緻RAID崩潰。

一般而言，工程師的修複方法就是強制上線，讓帶病的硬碟強行工作，也可能不懂的工程師随便上線了舊掉線的硬碟，這時，就會表現為大多數資料可通路，但部分資料（尤其較新）出現損壞，與騰訊公開的表現相似。

第3層：虛拟卷層

虛拟卷往往用在大的雲存儲中心，簡單地舉例來說，如果由1000個硬碟構成的一個存儲系統，再按8硬碟一組的方式進行存儲劃分，會有很多問題(高故障、空間利用不集中等)。為此，很多廠商開始提及虛拟化存儲，方法各有不同，但基本就是存儲池化---意思是所有可用的空間在確定案例的前提下，彙總到一個統一管理的“池”中，再根據需求靈活配置設定虛拟磁盤。

一種方法是把所有硬碟放到池子裡，再切塊組RAID，再組個存儲池，再劃分虛拟卷。華為把這個技術稱為RAID2.0，其實HP EVA、3PAR也都按這個技術在實作(網絡上的主流資料描述HP EVA的算法均有誤)，DELL康貝(Compellent)都是這樣實作。這種思路硬碟如果足夠多，在使用前期安全性很好（有足夠多的混在隊伍中的替補，可以快速替換故障資料塊），但後期随着損壞硬碟數量的增加(尤其越是自動替換，管理人員就越松懈)，故障率就會增加。

舉個HP-EVA的例子，一組存儲144個硬碟，在崩潰臨界點，先後有近40個硬碟報故障。故障的根源其實來源于硬碟預警失效、控制器又完全呆傻的BUG。40個故障硬碟遠遠超過可以激活系統的故障數量，就導緻所有部署在本存儲上的資料全部下線。一般HP官方的最高解決辦法(美國的一線)，就是用指令強行激活存儲，讓存儲自己計算缺失資料，當資料的确落到壞道處無法校驗生成時，就會用舊狀态資料(EVA快速重建時會可能保留某些資料塊的舊狀态)或全0代替。這樣，就會導緻上層檔案系統故障。檔案系統故障就是表現為元檔案故障，否則元檔案沒壞，檔案系統就不會壞，頂多表現為檔案内容不正确。

騰訊本次的事故也有這個可能。

另一種方法是把所有硬碟按xD+yP的方式建構RAID(如8個硬碟的資料，配一個硬碟的校驗)，再把所有的RAID放到池裡，再從池中劃分虛拟磁盤。IBM DS8000、HP X20000、DELL EqualLogic都用這個方案。這是非常垃圾的方案，IBM和HP的上述兩類存儲都是上千萬一套的産品，但故障風險極大，我們的國企，政府常用，也常出問題，隻是沒人知道。故障主要來源于不斷放大的RAID風險，每一組RAID假設有1/10000的機率損壞(如第2層中的情形2)，如果1000個硬碟，有100組，損壞機率就放大了100倍，想想也可怕。但騰訊本次事故不太可能用IBM、HP、EMC的存儲，因為太貴了，又不是存自己的核心資料。可能有小廠商或騰訊自己用軟體定義的方式搭建本類存儲，損壞的可能也就如同第2層中的情形2。

第4層：虛拟卷快照

快照是對某個資料集某個時間段的差異資料組合。快照集疊加到其父集上，就可以表現為最新的資料副本。集中在快照上的故障往往因人為發生，比如以為某個快照副本已經失效，删除後發現删錯了；比如在回到某個快照狀态時選錯了，再也退不回去等等。

如果照着騰訊本次的事故，至少有一種可能會導緻故障現象的發生：管理人員因故(遷移、維護等原因)對資料做了快照，在清理臨時資料時不小心删除了快照副本，緊急搶救後，快照資料救回來有部分損壞，快照合并後表現為部分資料損壞。當然，這個可能性不大，騰訊本次事故中沒有選擇資料恢複專業公司介入(隻要有選擇資料恢複方案，北亞不會不知道)，應該不會有這種實施可能。

第5層：大資料或雲存儲層

出問題的騰訊雲是基于虛拟化技術建構的，涉及虛拟化，就一定會設計資源的集中配置設定。涉及資料部分，單一或獨立存儲很難響應IO的不确定性峰谷請求，是以，騰訊應該會設計Hadoop之類的平台來提供資料資源配置設定。

在大資料平台的設計邏輯裡，資料IO資源會以可能平均地配置設定在所有節點中。而管理他們的中繼資料或集中或分布式。邏輯上，使用者資料與中繼資料是獨立的。

但現在的大資料平台往往是基于傳統單機檔案系統為載體進行架構。單機檔案系統的操作手段、指令并未廢止。是以，在一些情況下，大資料平台出故障，可能會導緻騰訊類似的資料災難。

僅僅是舉幾個想象的例子。

如果維護人員不小心删除大資料平台下一層檔案系統上的某些資料塊，大資料平台的備援也無法還原某個資料塊的話，就會表現某個使用者的虛拟機資料缺失。

如果維護人員沒及時維護節點，某些節點損壞，超過了備援級别，也會導緻某個使用者的虛拟機資料缺失（也有可能用VMware vSAN之類的技術，同樣這種可能也存在）。

騰訊的事故是否如此，不得而知。

第6層：虛拟化檔案系統

VMware?vsphere、Xen、KVM或Hyper-V是專門的虛拟化系統平台。這些虛拟化平台，為了實作塊級别的同時通路，且适應虛拟機的大塊配置設定原則，有時要設計自己的檔案系統，最為典型的是VMware的VMFS。

以VMFS為例，對VMFS引發本次事故表現的可能舉舉例子，如下：

1、VMFS是典型的共享塊裝置檔案系統，是基于每台VMWARE伺服器的約定，如果接入存儲網絡的是普通單機，他可不管是不是共享，有時就會獨占儲存設備，導緻VMFS的破壞。強行修複後，就會出現某台虛拟機資料損壞的情況。

2、VMFS管理時不小心删除資料，或擴容、縮容，也會導緻VMFS檔案系統損壞，修複後，可能出現某台虛拟機資料損壞的情況。

第7~8層：虛拟磁盤檔案與快照

虛拟機的資料載體是虛拟磁盤，往往表現為宿主系統上的一個檔案或一個獨立區域。以檔案形式表現的居多，如RAW、VMDK、VHD、VHDX、QCOW2等格式。

這些虛拟磁盤和普通檔案表現相同，就會面臨和普通檔案一樣的損壞可能。比如上層誤删除檔案、上層格式化、檔案截斷、檔案遷移時中斷等。這些檔案一旦破壞，即使恢複回來，也可能不是100%，就會與騰訊本次資料災難的表現相同。

磁盤檔案快照與第四層的卷快照原理相似，Hyper-V對其稱為差異磁盤，表述直接明了。快照檔案丢失或損壞後，也可能與騰訊本次資料災難表現相同。

第9層：虛拟機檔案系統

第10層：檔案

建議