摘要： 近日，阿里雲推出了首個百萬iops的essd雲盤服務，效能上有50倍的飛躍，同時還具備超高吞吐、超低時延等特性，在真實業務場景中，postgresql資料庫的寫入速度快了26倍。 如此超高的效能，有人會問，阿里雲到底用了什麼秘密技術？安全係數如何？ 本文將從冗餘設計思路出發，分享阿里雲是如何建立儲存冗餘體系，抵禦未知風險，解決故障率的。
2023年11月7日，竣工才4個月的塔科馬海峽大橋在微風中大幅度舞動，橋上的汽車急速滑動，很快就戲劇性的垮塌。這件事故給建築工程行業造成極大的震驚，很違反直覺，很低的風速居然會吹垮一座鋼鐵建造的大橋，在此之前所有的橋梁專家都沒有意識到這個問題，事實上若干年後橋梁結構學與空氣動力學得到極大發展，人類才徹底解決這個問題。
在工程領域通常將這類事前缺少認知，只有發生後才能意識到的問題統稱為險惡性問題，這類問題殺傷力極大，對於盤古這樣的分布式系統同樣會面臨這類險惡性問題，既然對問題都沒有認知，又防禦何談呢？陽光之下並無新事，我們從各種安全至關重要的行業中廣泛的學習，發現各個行業在面對這類問題時，已經有較為豐富的經驗了，同樣以橋梁為例，早於的塔科馬海峽大橋的金門大橋（2023年建成通車）已經巍然屹立了80多年，可謂飽經風霜，後人在分析其設計者留下的設計手稿時發現早期的設計者在面對未知世界時非常謙卑，他們知道有些問題他們搞不清楚，可能會有風險，所以他們做了充分的冗餘設計來抵禦這種未知的風險，通過充分的冗餘來斬斷可能形成的故障鏈。
其實儲存是乙個高危行業，首先要保障的是不錯，不丟，可訪問，只有在這個前提下，極致的效能才有意義。不錯，不丟，可訪問，看起來平淡無奇，但實踐下來常有如履薄冰之感，因為分布式問題太過複雜，因為作業系統、硬體都不是絕對可靠的，因為**不可能絕對無bug，運維也不可能從不出錯。有太多險惡性問題，即使行業先行者也出現過資料丟失和不可用。在盤古設計之初我們學習了上文中冗餘設計的做法，承認自己所知有限，在很多地方做了冗餘設計來抵禦未知風險，並且在長期的演進中不但強化這類冗餘設計，絕不為了效能或者其他的目標來做冗餘設計上的妥協。
這些年來阿里雲儲存團隊的同事們始終心存畏懼，鐵棒磨針，始終專注於提供穩定可靠高效能的儲存，天道酬勤，10年來我們做到了資料不錯，不丟，非常慶幸。
下面我分享幾個阿里雲在儲存方面的冗餘設計：
e2e的資料校驗
磁碟可能出錯，記憶體也會出現bit反轉，核心和應用程式更可能出錯，甚至我們遇到過某廠的一塊cpu在做某些特定運算時就會出錯，在這樣一堆不可靠的軟硬體環境下，要構建出乙個穩定可靠的儲存平台（沒有哪個使用者能接受哪怕乙個bit的錯誤），是非常困難的，一般的做法是端到端的逐層做資料校驗，盤古很早就做了e2e 的資料校驗。但一次在乙個長時間大壓力的測試環境上mysql 報資料錯，核對資料發現crc和資料是匹配的，並沒有出錯，核對另外2份拷貝，發現另外兩份資料也是crc自洽的，而且另外兩份完全一致，但與mysql讀取的這乙份差異非常大。初步判定是mysql讀取的這乙份資料出錯了，但這份錯誤的資料是crc自洽的，這就非常奇怪了，如果是儲存介質出錯，不太可能還保持crc自洽，在讀寫鏈路上檢視了所有日誌，沒有找到任何異常。調查的同事反覆核對三份拷貝，說這乙份看起來就不像是這個檔案的資料。
說者無心，聽者有意，另外乙個同事想在哪種情況下會出現這樣的錯誤，由於我們的crc和資料是邏輯空間上是相鄰的，會不會是這片資料其實不屬於當前檔案，而是和另外乙個檔案搞串了？大膽假設，小心求證，全盤掃瞄後果然證實了猜想：a和b兩個檔案中間有一部分內容寫串了，詳細調查後確認是ext4 檔案系統的bug，它在做空間管理的時候出錯，導致a檔案的乙個資料片寫入到檔案b, 檔案b中有乙個資料片寫入到檔案a中，由於寫入的流程一致，crc又和資料放置在一起，導致crc無法發現這個問題，確認問題後解決起來就很簡單了，要麼將crc和資料分開放置，要麼在計算crc的時候加上檔案的乙個特徵值。
有e2e的資料校驗是否就安全了呢？呵呵坑深不見底，硬體行業的人知道磁碟極小的概率發生靜默錯誤（讀出來的資料是錯誤的，但底層介面不報錯，磁碟本身也不報錯），如果三份拷貝很長時間都未被讀取，而在這個較長的時間視窗內，如果有三份拷貝所在的3塊盤都發生了靜默錯誤，使用者讀取資料時，儲存系統就會發現3份crc校驗都不通過，儘管知道出差錯了，卻沒有任何辦法修復。為了降低這種情況發生的概率，我們會定期掃瞄冷資料，校驗其crc。
壓縮檢驗
一天新來的同事問大家：「我們在做壓縮的時候，為啥壓縮完後，立刻又解壓縮一次，並且將解壓資料和原始資料再去比對一次？直接壓縮不就完了嗎？」，眾人笑而不語，他思考良久，也未能找到足夠的理由。團隊內老司機告訴他，壓縮本身是乙個很複雜的東西，有些庫是第三方提供的，儘管我們會review**，有嚴格的引入測試，但沒人能保障其絕對正確，萬一壓縮出來的內容是錯的怎麼辦？cpu也可能存在一些偶發性的錯誤，如果壓縮時發生這類小概率的偶發性錯誤，該怎麼辦呢？但戶資料是絕對不能錯的，所以我們這裡採取防禦性程式設計，壓縮完後立即解壓，再和原始內容比對，確保資料不錯。
paxos
說到分布式儲存，很多人就言必稱paxos和raft，paxos儼然就成了救世主。paxos, raft 的確是好東西，但並不是所有的場景都適用。在乙個分布式系統中，大家會認為在乙個較小的時間視窗內同時發生2臺機器failover是乙個小概率事件，但隨著集群規模的擴大，集群數量的增多，最終小概率事件長期積累，就變成必然事件了，在quorum=3的時候，paxos 協議是無法處理double fail的，甚至無法自癒，需要緊急人為干預才能恢復。想想半夜收到告警，你能在幾分鐘能處理好使用者的io hang？ 適合的才是最好的，實踐是檢驗真理的唯一標準。
磁碟錯誤
對於做儲存的人來說，磁碟故障是司空見慣的事情了，本身有一套成熟的處理機制。但百密一疏，我們還是在這上面栽過跟頭，程序主動檢測到binary所在的系統盤故障，老司機當然知道此時不能再在該盤上發起任何io 操作，日誌寫入到記憶體中，呼叫exit, 安靜的退出，不帶走一片雲彩即可。但程序居然無法退出，呼叫exit 無法退出！而此時其它執行緒還在繼續工作，在幹壞事。所有人都覺得匪夷所思，為啥主線程呼叫 exit, 程序未能退出，其他執行緒在長達幾分鐘內還在繼續幹壞事？團隊大牛反覆推演，不放過任何乙個蛛絲馬跡，終於搞明白了，原來磁碟故障後，exit這段**本身並不在記憶體中，呼叫時會產生major fault, 中斷處理程式會嘗試從磁碟上load相應的**段，而磁碟已經故障了，load 被hang住，導致出現前面這些匪夷所思的怪事。
今天雲計算已經成為網際網路的基礎設施，隨著眾多電力、水務、醫療企業上雲，阿里雲又成了這些基礎設施的基礎設施，任何乙個黑天鵝都有可能帶來難以估量的影響。只有對這個未知的世界保持敬畏，保持謙卑，才能走得更遠。
阿里雲的雲盤掛載
為這個問題困擾過好幾次，實在是不願意看阿里雲官方提供的密密麻麻的說明文字。這次又遇到阿里雲ecs伺服器公升級遷移，又需要重新掛盤操作。諮詢了好幾個阿里雲售後工單的工程師之後，我是怒了，簡單的掛盤問題非要回答得那麼複雜晦澀難懂。後來遇到乙個售後工程師的溝通，才算是說到了關鍵點上，順利解決了問題。售後工...
阿里雲Centos6資料盤擴容的問題處理
阿里雲擴容的處理有官方文件 但是因為操作阿里雲後台進行擴容操作的執行人並沒有按照文件來執行，並且也不是技術人員，導致後續處理遇到了問題。1 找出資料盤上執行的所有程序，然後全部殺死 lsof grep home home是掛載點 然後用kill 9 程序號 2 強制取消掛載 umount l hom...
記一次阿里雲盤擴容遇到的坑
生產環境使用了阿里雲並且以mongo作為伺服器，由於業務發展需要資料盤的400g的容量已經用到81 所以需要對磁碟做無損擴容操作。在控制台上擴容資料盤的磁碟空間 官方文件 在按照官網操作完成後，始終無法顯示擴容後的容量一直w為400g。經過各種資料查詢最終得到結果 由於centos6和centos7...