Silent Data Corruption 幽靈殺手

為了提高數據在存儲系統中的可靠性，我們使用冗餘的辦法來抵禦不穩定因素，如副本或糾刪碼。然而單憑冗餘策略，我們不僅不能完全保障數據安全，可能還會面臨系統雪崩的風險。這類被大多數人忽視，或是不甚了解的潛在錯誤無時無刻不在威脅著我們的系統安全。

那麼是什麼如幽靈一般存在呢？我們如何抗擊它呢？在這篇文章中，我們將一起來追蹤這位幽靈殺手。

Silent Data Corruption，原來是你

通常我們認為硬體是完全可靠的，然而，有些錯誤可以穿透這些校驗機制，從而造成潛在的危害與事故。我們稱這一類錯誤為 Silent Data Corruption (SDC)。儘管 SDC 出現的概率並不高，但對於有大量數據交互的服務來說，可以認為它是必現的，有時它能造成難以修復的故障。

「亡魂」

AWS S3 因 bit corruption 造成 36 小時的服務中斷[1]

Facebook 遇到 10%-15% 的圖片無法訪問 (48 小時)[2]

Netflix 宕機超過 3 天[3]

…

以上這些重大事故的無一例外，都是 Silent Data Corruption 這位鬼魅般的數據殺手的 「傑作」。

捉鬼有方

我們固然可以執行非常嚴厲的計劃來避免 SDC 問題，然而無論多麼精巧的設計都不能 100% 避免問題的發生，而且會急劇降低系統的整體性能。這就要求我們學會在 性能 與 可靠性 之間做工程上的平衡。

但這並不意味著放棄抵抗或是拍腦袋決策，我們率先需要認真考察 SDC 出現的場景和影響。從而進行提出有針對性的方案。

對數據流分類

分類依據：目的

根據數據的目的，我們可以將數據流分為 控制流 和 文件流 兩種形態。這兩種形態對於數據的完整性提出了不同的要求。對於控制流，我們必須保證整條數據流中任意兩端的完整性，這是因為控制流出錯可能引發出大的災難。

對於文件流，我們只需要提供最終完整的機制即可。如客戶可以拿本地的 SHA1 與存儲系統返回的 SHA1 進行對比。（值得注意的是，任意一端的 SHA1 可能並不反映真實的數據情況）

分類依據：媒介

根據數據的媒介，我們可以將數據流分為 網路流 和 本地流 兩種形態。分別代表伺服器之間的通信過程和服務內部的通信過程。

幽靈魅影

在本小節點中，我們將根據上文的分類去分析 SDC 出現的場景以及預防機制。

網路流

在應用層之下，我們已經擁有 switch 的 CRC32 與 TCP Checksum 的防護機制，然而數據經流的每一台 switch 都會重新計算 CRC32 (除非是兩台機器簡單的通過一台 switch 相連)，也就是說，目前我們擁有的機制無法避免 switch 內部錯誤。如果經過了路由，情況會變得更加複雜。 TCP Checksum 的設計目標之一就是為了預防這樣的錯誤，但其強度太低，不足以勝任這樣的任務。[4]

CRC32 與 Adler32 (Fletcher 的替代品) 的設計目的都是為了做乙太網 frame (around 1500B) 的校驗，其中 Adler32 的強度還要低於 Fletcher32[5]

我們所需要考察的是，在較大的數據尺度上（校驗在應用層上做），這兩種演算法能否滿足我們提高系統可靠性的要求。

出錯原因

主要為 bit flipping 錯誤，以及交換機/路由的固件和邏輯問題。因此既要預防少量的 bit 隨機反轉，也要能應對成片的錯誤。在交換機日誌上可能會看到被交換機糾錯過的記錄，如果錯誤日誌相關條目的數據量非常大，可以考慮進行對交換機的維護/更換。

所需要校驗的數據特徵

上文中，我們指出應對數據流做區別對待，其中要更加註重控制流（即指令參數等控制信息）。原因如下：

對於存儲系統來說，我們並不能控制客戶端行為。如果客戶端在上傳時不提供數據摘要，也就是說不能實現完整的 end-to-end data integrity

文件流危害範圍小，不會造成系統雪崩

控制流呈現如下特點：

數據量相對較小，通常小於 1MB。哪怕設計到集群信息也一般在百MB以下

信息相對比較重要，部分出錯需要零容忍。比如文件唯一 id 由於 bit flipping 出現重複

數據一般進行了封裝，以便 unmarshal 成可以使用的數據結構。而數據結構本身具備一定的抗隨機錯誤的能力

無論是 CRC32 IEEE802.3 還是 Adler32 或者 Fletcher32 在上述最大數據尺度上其 hamming distance 均為 2。對於校驗演算法來說，hamming distance 指的是其最少多少位錯誤的情況下會有 1bit 無法檢測。這裡的 2 是指，只要有 2bit 錯誤至少會有 1bit 錯誤無法被識別到。

因此，如果覺得強度不滿意。還可以選擇非加密的散列演算法，如 xxhash[6] 或 seahash[7]。

本地流

與磁碟進行數據交互的可以分為三類：定位，讀取，寫入

這三個過程互相組合，需要我們有不同的應對方案

定位

主要是寫定位錯誤 (Misdirected writes) ，數據寫入的磁碟位置與預期不符。這個錯誤可能導致兩個文件同時被污染。

讀取

最常見的 SDC 錯誤發生過程，這是因為其本質上可能是多種錯誤導致的最終結果。最常見的情況有：

超過扇區 ECC 檢錯能力的錯誤

讀取過程中的 bit flipping

所讀取的數據在寫入過程中的錯誤

主要為寫丟失 (lost writes)，這個錯誤意味這沒有寫入成功的情況下返回寫入完成（注意和掉電導致的緩存數據未刷入非易失性存儲介質的情況相區別）。其後果是在正確的位置讀到舊數據。

另外，需要注意的是，SDC 在 HDD 上有擴散趨勢[8]

磁碟保護

磁碟廠商針對 SDC 能做的是盡量保證數據在磁碟內不出問題，各家廠商都有自己的 end-to-end integrity 技術。我們的存儲系統主要是由 SATA 和少量 SSD 組成。伺服器系統盤則可能為 SAS 盤（以上均為企業級磁碟）。其中絕大多數的 SATA 盤中並沒有 SDC 防禦機制。

SAS 盤提供 Fat-Sector 來進行保護。其中包括 CRC, 地址標籤，程序標籤。[9]

SSD 的 flash media 層以及 DRAM 都不易發生 bit flipping 。但在 controller 中有大量 SRAM CMOS 是非常容易發生錯誤的。 Intel 為企業級 SSD 在做了一系列保護之後，還進行了 high intensity particle beams 實驗來做 SDC 測試[10]

文件系統保護

比如 xfs 提供了元數據的一致性保護[11]，其措施能避免 讀 與 misdirected 錯誤。由於對象存儲不存在修改文件元數據信息的場景，因此 lost writes 的未處理可以接受。相對而言， zfs 則提供了全面的一致性校驗[12]。但 zfs 的文件級別的保護並不適用於對象存儲 append-only 的場景。

Scrub

Scrub 可以分為兩類，一類是 Media Scrubs (可以通過 SCSI cmd 觸發)，另一種是 Data Scrubs。這分別代表磁碟內部對扇區進行掃描，以及在應用層對數據摘要的對比掃描。

我們常說的就是 Data Scrubs。這種 Scrub 的目的是檢測 silent corruption，它可能說明本地流中某個或某幾個環節有問題，但不能直接表明扇區有錯誤，儘管我們可以通過這樣一個過程來發現扇區故障。

實踐

控制流

必須進行 end-to-end integrity 校驗。使用 seahash 演算法在請求體中追加校驗值，接受方必須進行數據對比。

副本集群

副本集群採用最終一致性的策略要預防 SDC。對於多個副本來說，同時發生寫錯誤的概率微乎其微。因此我們在讀時校驗，在校驗失敗後鎖定相應磁碟即可。

需要注意的是，將原始數據與摘要分開存放並不能處理 misdirected writes 錯誤。

對於使用的 xfs 文件系統來說，由於其開啟了 metadata 保護，因此文件系統層面很難出現 misdirected 錯誤。因此，倘若我們要進行 misdirected writes 保護，只需要在原先的 checksum 前加上該數據在大文件塊中的偏移量即可。偏移量一致且能返回數據和 checksum 的概率幾乎可以忽略不計（在數據錯誤的情況下）

特別需要說明的是 lost writes 錯誤，lost writes 的應對方案主要有兩種：

read-after-write

checksum 與 data 分開存放

這兩種方案的代價都非常高昂。在對象存儲 append-only 的場景下，lost writes 發生且校驗一致的概率微乎其微。因此 lost writes 在副本集群下不採取特別的措施。

糾刪碼集群

EC 由於沒有副本機制保護，因此必須進行 misdirected writes 保護，其方法與多副本中描述一致，這裡就不在贅述了。

資料庫集群

資料庫要面臨的 SDC 風險與本地流一致，利好消息是資料庫集群為多副本架構。在 chekcusm match 之後，就意味著獲得的值不會造成系統風險。如果發生了 misdirected writes 或者 lost writes 錯誤導致查詢失敗，我們幾乎可以肯定的能從其它副本中獲得正確的數值。除了加入 checksum 欄位之外，為資料庫所使用的 SSD 必須符合我們對於可靠性的要求。

結語

此篇文章如同幽靈一般結束了。。。

附錄

Amazon S3 Avaliability Event: July 20, 2008,http://status.aws.amazon.com/s3-20080720.html

Facebook temporarily loses more than 10% of photos in hard drive failure,http://www.computerworld.com/s/article/9129263

Netflix Outage Blamed on Hardware,https://www.pcmag.com/article2/0,2817,2328778,00.asp

Jonathan Stone and Craig Partridge, When The CRC and TCP Checksum Disagree

Theresa Maxino, Revisiting Fletcher and Adler Checksums

xxhash,http://www.xxhash.com

SeaHash: Explained:http://ticki.github.io/blog/seahash-explained/

An Analysis of Data Corruption in the Storage Stack

HGST End-to-end Data Protection

Data integrity in solid state drives: what supernovas mean to you,https://itpeernetwork.intel.com/data-integrity-in-solid-statedrives-what-supernovas-mean-to-you/

XFS Self Describing metadata,https://www.kernel.org/doc/Documentation/filesystems/xfs-self-describing-metadata.txt

End-to-end Data Integrity for File Systems: A ZFS Case Study

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