如何評價阿里雲發布的新一代存儲產品家族?

原文:阿里雲發布新一代存儲產品家族,認為線上線下的儲存邊界正在消失


作為全程經歷者,感慨萬千,怒答一發。

發布會上已經展示了光鮮亮麗的性能數據,這裡我嘗試從另外一個角度來說下這一路走下來的痛並快樂著的艱辛歷程,說下團隊在鐵棒磨針過程中的若干細節。

舞動的橋

  • 1940年11月7日,竣工才4個月的塔科馬海峽大橋在微風中大幅度舞動,橋上的汽車急速滑動,很快就戲劇性的垮塌。這件事故給建築工程行業造成極大的震驚,很違反直覺,很低的風速居然會吹垮一座鋼鐵建造的大橋,在此之前所有的橋樑專家都沒有意識到這個問題,事實上若干年後 橋樑結構學與空氣動力學得到極大發展,人類才徹底解決這個問題。在工程領域通常將這類事前缺少認知,只有發生後才能意識到的問題統稱為險惡性問題,這類問題殺傷力極大,對於pangu 這樣的分散式系統同樣會面臨這類險惡性問題,既然對問題都沒有認知,又防禦何談呢?陽光之下並無新事,我們從各種安全至關重要的行業中廣泛的學習,發現各個行業在面對這類問題時,已經有較為豐富的經驗了,同樣以橋樑為例,早於的塔科馬海峽大橋的金門大橋(1937年建成通車)已經巍然屹立了80多年,可謂飽經風霜,後人在分析其設計者留下的設計手稿時發現早期的設計者在面對未知世界時非常謙卑,他們知道有些問題他們搞不清楚,可能會有風險,所以他們做了充分的冗餘設計來抵禦這種未知的風險,通過充分的冗餘來斬斷可能形成的故障鏈。
  • 其實存儲是一個高危行業,首先要保障的是不錯,不丟,可訪問,只有在這個前提下,極致的性能才有意義。不錯,不丟,可訪問,看起來平淡無奇,但實踐下來常有如履薄冰之感,因為分散式問題太過複雜,因為操作系統、硬體都不是絕對可靠的,因為代碼不可能絕對無bug,運維也不可能從不出錯。有太多險惡性問題,即使行業先行者AWS 先後在澳洲,北美 都出現過數據丟失和不可用。在pangu設計之初我們學習了上文中冗餘設計的做法,承認自己所知有限,在很多地方做了冗餘設計來抵禦未知風險,並且在長期的演進中不但強化這類冗餘設計,絕不為了性能或者其他的目標來做冗餘設計上的妥協。這些年來團隊兄弟們始終心存畏懼,鐵棒磨針,始終專註於提供穩定可靠高性能的存儲,天道酬勤,10年來我們做到了數據不錯,不丟,非常慶幸。下面我分享幾個我們的冗餘設計。

E2E的數據校驗

  • 磁碟可能出錯,內存也會出現出現bit反轉,內核和應用程序更可能出錯,甚至我們遇到過某廠的一塊CPU在做某些特定運算時就會出錯,在這樣一堆不可靠的軟硬體環境下,要構建出一個穩定可靠的存儲平台(沒有哪個用戶能接受哪怕一個bit的錯誤),是非常困難的,一般的做法是端到端的逐層做數據校驗,pangu 很早就做了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住,導致出現前面這些匪夷所思的怪事。

今天雲計算已經成為互聯網的基礎設施,隨著眾多電力,水務,醫療企業上雲,我們又成了這些基礎設施的基礎設施,任何一個黑天鵝都有可能帶來難以估量的影響。只有對這個未知的世界保持敬畏,保持謙卑,才能走得更遠。


原來,雲存儲雖然擁有彈性,但由於伺服器和存儲並不存在物理上的連接而通過網路溝通,其延時是用戶較為關注的問題。如今,阿里雲等公有雲廠商通過不斷優化性能來彌合之間的差距,兩者之間的差距逐步縮小。顯然阿里雲這家公有雲廠商正在嘗試從線上到線下進入華為、新華三,EMC等傳統企業存儲市場,瞄準企業服務。這些產品和服務不僅面向天生長在雲上的微博、芒果TV、OFO等互聯網客戶,也瞄準了天文、海洋、氣象、基因等領域的非互聯網,國家天文台已經將3.5億顆恆星的數據存儲在阿里雲OSS上,用於計算、分析,並向公眾開放。


我個人其實還是滿喜歡線上存儲的,數據安全,使用方便,而且一般不會發生丟失的現象。阿里雲還是值得信賴的。


阿里雲霸佔了互聯網行業的大半個江山 已經讓小公司苟延殘喘了


土豪請直接購買試用。非土豪想用不過可以等,等產品的測評或者消費者反饋結果再決定,或者乾脆等產品更新換代後再來關注了解。


瀉藥...

阿里雲的產品用得少. 邀請我也沒法答.


阿里發布雲儲存技術肯定放心的,畢竟經過阿里那麼多年的風雨洗禮,但是價格是用戶考慮的因素之一,但數據安全是肯定非常重要的


強者逾強,雲存儲供應商越來越多,阿里需要快速推出新產品,加強產品更新迭代速度,以保持市場領先地位。


首先謝邀。

然後,雖然之前用過阿里雲的EMC,但也只是做了基礎的服務部署,沒有太多感受(也可以從側面說明其可靠性?),印象最深的就是晚上10點多提交的工單居然半小時之內就有回應了,工作人員辛苦了(鞠躬

其次,對於新一代的存儲產品家族,我也是剛剛知道。。。大概看了一下連接中的內容,作為一個小嘍嘍,還是很興奮的,因為本身在金融行業,所以對文中提到的極速OSS還是很感興趣的(雖然不一定能用得上),以及能看出來阿里的野心不僅僅是服務企業這麼簡單,是想要做出國家級甚至世界級的東西,作為一個小透明,真的很敬佩。

再次,文中沒有提到,或者沒有明確提到費用,技術方面,我對阿里還是比較放心的,費用方面之前使用過EMC,感覺價格稍微有點高,但也在接受範圍內,不過這也不在我的考慮範圍內,畢竟用不用不是我說了算。。

最後,至於怎麼評價,其實在沒有真正使用之前,我也只能喊666了。。


其實現在雲儲存是很好用的,安全性也有保障,不一定要求本地部署,本地服務不定跟得上雲儲存的


有前途,整體看好。


阿里雲在線直播技術與應用分享,1月19日與阿里雲專家面對面交流,雲里霧裡北京等你


邁開大步子,胃口大,想得遠,阿里的目標,可不僅僅是要做存活一個世紀的企業


不怎麼關心這個,中小企業一般用雲伺服器比較多,啥時候雲伺服器能儲存空間變多,價格變更低就好了


阿里的布局越來越大


瀉藥。。。雖然我並不知道為什麼會有人邀請我。

阿里巴巴這個公司怎麼說,雲計算產品做的相當不錯,至於讀寫。非常抱歉我一直做的是VPN,所以對於沒什麼接觸的我來說。也就吐槽一下咯~

其實做硬體,不是很看好互聯網公司來做。比如360硬體,樂視手機。。。等等等等。優勢是用戶體驗,劣勢是沒有技術沉澱。

其它不多說,看法就是。我還是會買金士頓


推薦閱讀:

數據分析中有哪些常見的數據模型?
逆無線充電板
什麼是銀行理財產品以及銀行理財產品有哪些類型?

TAG:產品 | 阿里雲 | YunOS |