歡迎來到太平洋安防網!
微信號
掃描上方二維碼
加入網站訂閱號
掃描上方二維碼
加入商城公眾號
手機站
掃描上方二維碼
訪問手機站
太平洋安防資訊
資訊
當前位置:安防首頁 > 資訊 > 行業資訊

ZStack教您構建“正確的”云平臺存儲

2019-11-22 14:24:06來源:全球財經網已被 319 人閱讀

內容摘要:從 2015 年到現在,ZStack 有一條宗旨一直沒有變過,就是向客戶交付穩定、可靠、高性能的云平臺,這條宗旨在前幾年讓我們一直聚焦云平臺本身,包括虛擬化、云網絡、云編排、存儲管理等等這些功能。
從 2015 年到現在,ZStack 有一條宗旨一直沒有變過,就是向客戶交付穩定、可靠、高性能的云平臺,這條宗旨在前幾年讓我們一直聚焦云平臺本身,包括虛擬化、云網絡、云編排、存儲管理等等這些功能。

在這里面最讓我們頭痛的,即使不是第一也能進前三的存在,就是存儲管理。

 

考慮到存儲對業務的無比的重要性,以及我們作為一家創業公司的支持能力,我們一開始一直是基于一些開源的存儲方案對客戶提供服務:

1. XFS,作為 RHEL 默認的本地文件系統,我們原本一直對 XFS 是比較信任的,但實際上 XFS 在使用過程中問題多多,我們幫客戶繞過了很多坑,也在考慮別的替代方案;

2. NFS,NFS 是一個對云平臺很簡單的方案,因為它屏蔽了很多存儲的復雜性,用文件系統的方式提供了共享存儲,使得我們可以用類似本地文件系統的管理方式管理共享存儲,既簡單又支持熱遷移等高級功能,看似完美,但實際上 NFS 幾乎是我們最不推薦的生產用存儲方案之一,細節將在后面討論;
3. OCFS2,當用戶只有 SAN 存儲,也無法提供 NFS 接口時,我們的選擇并不多,此時 Oracle 的 OCFS2 成為一個值得青睞的方案,其優點是在小規模使用時基本上很穩定,部署后也可以使用文件系統的方式使用,但在性能、大規模的擴展性和部分功能(例如文件鎖)上支持也并不完美;
4.Ceph,基于 Ceph 可以提供很棒的存儲方案,但 Ceph 相對復雜的部署運維對部分客戶還是比較難接受,特別是在私有云中,很多客戶習慣了 SAN 存儲帶來的性能和安全感,對他們來說也沒有超大容量的需求或者隨時需要靈活擴容,反而大廠商帶來的安全感,或者能夠將之前用在VMware 上的 SAN 存儲繼續用起來才是最重要的。
綜合考慮前面的各種存儲,NFS、OCFS2 的不完美促使我們提供一個能夠管理共享存儲的存儲方案,這個方案要能達到下面的要求:

1. 部署速度要足夠快,ZStack 的部署速度一向是業界前列,我們的標準一直是對于 Linux 有基本理解的人能夠在 30 分鐘內完成部署,這個時間是包括部署主存儲、鏡像倉庫的時間的。
2. 能夠擴展到足夠大的規模,根據 SAN 存儲的性能,單個集群應該可以接管幾十到上百的服務器(因為一般來說單個 SAN 存儲能支撐的服務器數量有限)。
3. 性能能夠完整發揮 SAN 存儲的性能,IO 模式能夠發揮 SAN 存儲的cache 性能,對于 OCFS2 我們可以通過調整block size 來優化 OCFS2 性能,但如果在分層SAN 存儲上測試就會發現由于大 block size 帶來的IO pattern 變化,如果測試 4k 小文件隨機寫,性能并不穩定,無法像直接在物理機上對 LUN 測試前期全部寫到高速盤上,帶來了測試數據的不理想。
4. 高穩定性,與互聯網、公有云業務不同,私有云均部署在客戶機房,甚至是一些隔離、保密機房,這意味著我們無法像互聯網環境一樣執行“反復試錯”的策略,我們無法控制用戶的升級節奏,無法時刻監控運維存儲狀態,也無法再客戶環境進行灰度測試、鏡像驗證。

最終,在2018 年我們決定自己開發一個面向共享塊存儲的存儲方法,命名很直接就叫 SharedBlock。整個方案是這樣的:

1. 基于塊設備,直接基于塊設備向虛擬機提供虛擬云盤,通過避免文件系統開銷可以明顯提升性能和穩定性;

2. 在塊設備上基于 Paxos 實現分布式鎖來管理塊設備的分配和節點的加入、心跳、IO 狀態檢查;

3. 通過 Qemu 的接口實現對用戶磁盤讀寫狀況進行監控;

 

SharedBlock在推出后,應用在了很多的生產客戶上,特別是可以利舊 SAN 存儲特點讓 SharedBlock 快速部署在大量以往使用虛擬化的客戶上。
后來隨著 5G 和物聯網、云端互聯的發展,讓市場迫切需要一個價格不高、可以簡便部署、軟硬一體的超融合產品,因此我們就在考慮一個兩節點一體機的產品,通過和硬件廠商合作設計,可以實現 2U 的一體機包含足夠用戶使用的硬盤、獨立的模塊和雙電冗余,我們希望能通過這個產品將客戶的原本單節點運行的應用平滑升級到兩節點備份,讓客戶的運行在軌道站點、制造業工廠這些“端”應用既享受到云的便利,又不需要復雜的運維和部署。這就是我們的Mini Storage。

 

在開發這些存儲產品的過程中,我們踩了無數的坑,也收獲了很多經驗。

下面先說說將存儲做正確有多難,在今年說這個話題有一個熱點事件是避不開的,就是今年的 FOSDEM 19' 上 PostgreSQL 的開發者在會上介紹了 PostgreSQL 開發者發現自己使用 fsync() 調用存在一個十年的 bug——

1. PG使用 writeback 機制,特別是在過去使用機械硬盤的時代,這樣可以大大提高速度,但這就需要定時 fsync 來確保把數據刷到磁盤;

2. PG使用了一個單獨線程來執行 fsync(),期望當寫入錯誤時能夠返回錯誤;

3.但其實操作系統可能自己會將臟頁同步到磁盤,或者可能別的程序調用 fsync();

4. 無論上面的哪種情況,PG 自己的同步線程在 fsync 時都無法收到錯誤信息;

這樣 PG 可能誤以為數據已經同步而移動了 journal 的指針,實際上數據并沒有同步到磁盤,如果磁盤持續沒有修復且突然丟失內存數據就會存在數據丟失的情況。

在這場 session 上 PG 的開發者吐槽了 kernel 開發以及存儲開發里的很多問題,很多時候 PG 只是想更好地實現數據庫,但卻發現經常要為 SAN/NFS 這些存儲操心,還要為內核的未文檔的行為買單。

 

這里說到 NFS,不得不多提兩句,在 Google 上搜索 "nfs bug" 可以看到五百萬個結果,其中不乏 Gitlab 之類的知名廠商踩坑,也不乏 Redhat 之類的操作系統嘗試提供遇到 NFS 問題的建議:

 

從我們一個云廠商的角度看來,虛擬機存儲使用 NFS 遇到的問題包括但不限于這幾個:

1. 部分客戶的存儲不支持 NFS 4.0 帶來一系列性能問題和并發問題,而且 4.0 之前不支持 locking;
2. nfs服務本身會帶來安全漏洞;
3. 對于在 server 上做一些操作(例如 unshare)帶來的神秘行為;
4. 使用 async 掛載可能會帶來一些不一致問題,在虛擬化這種 IO 棧嵌套多層的環境可能會放大這一問題,而使用 sync 掛載會有明顯的性能損失;
5. NFS本身的 bug;
最終我們的建議就是生產環境、較大的集群的情況下,最起碼,少用 NFS 4.0 以前的版本……
另一個出名的文章是發表在 14 年 OSDI 的這篇 AllFile Systems Are Not Created Equal,作者測試了數個文件系統和文件應用,在大量系統中找到了不乏丟數據的 Bug, 在此之后諸如 FSE'16 的 Crash consistency validation made easy 又找到了gmake、atom 等軟件的各種丟數據或導致結果不正確的問題:

 

 

上面我們舉了很多軟件、文件系統的例子,這些都是一些單點問題或者局部問題,如果放在云平臺的存儲系統上的話,復雜度就會更高:

1. 首先,私有云面臨的是一個離散碎片的環境,我們都知道 Android 開發者往往有比 iOS 開發者有更高的適配成本,這個和私有云是類似的,因為客戶有:

1)不同廠商的設備;

2)不同的多路徑軟件;

3)不同的服務器硬件、HBA 卡;

雖然 SCSI 指令是通用的,但實際上對 IO 出錯、路徑切換、緩存使用這些問題上,不同的存儲+多路徑+HBA 可以組成不同的行為,是最容易出現難以調試的問題地方,例如有的存儲配合特定 HBA 就會產生下面的 IO 曲線:

 

2. 由于我們是產品化的私有云,產品化就意味著整套系統不可能是托管運維,也不會提供駐場運維,這樣就會明顯受客戶參差不齊的運維環境和運維水平限制:

1)升級條件不同,有的用戶希望一旦部署完就再也不要升級不要動了,這就要求我們發布的版本一定要是穩定可靠的,因為發出去可能就沒有升級的機會了,這點和互聯網場景有明顯的區別;

2)聯網條件不同,一般來說,來自生產環境的數據和日志是至關重要的,但對產品化的廠商來說,這些數據卻是彌足珍貴,因為有的客戶機房不僅不允許連接外網,甚至我們的客戶工程師進機房的時候手機也不允許攜帶;

3)運維水平不同,對于一個平臺系統,如果運維水平不同,那么能發揮的作用也是不同的,比如同樣是硬件故障,對于運維水平高的客戶團隊可能很快能夠確認問題并找硬件廠商解決,而有的客戶就需要我們先幫忙定位分析問題甚至幫助和硬件廠商交涉,就需要消耗我們很多精力;

3. 漫長的存儲路徑,對于平臺來說,我們不僅要操心 IO 路徑——Device Mapper、多路徑、SCSI、HBA 這些,還要操心虛擬化的部分——virtio 驅動、virtio-scsi、qcow2…… 還要操心存儲的控制平面——快照、熱遷移、存儲遷移、備份…… 很多存儲的正確性驗證只涉及選舉、IO 這部分,而對存儲管理并沒有做足夠的關注,而根據我們的經驗,控制平面一旦有 Bug,破壞力可能比數據面更大。

 

說了這么多難處,我們來說說怎么解決。提到存儲的正確性,接觸過分布式系統的同學可能會說 TLA+,我們先對不熟悉 TLA+ 的同學簡單介紹下 TLA+。

2002Lamport 寫了一本書《SpecifyingSystems》基本上算是 TLA+ 比較正式的第一本書,了解的朋友可能知道在此之前 Lamport 在分布式系統和計算結科學就很出名了——LaTex、Lamport clock、PAXOS 等等,TLA+ 剛開始的時候沒有特別受重視,他的出名是來自 AWS 15 年發表在 ACM 會刊的《How Amazon Web Services Uses FormalMethods》。

從本質上講,形式化驗證并不是新東西,大概在上世紀就有了相關的概念,TLA+ 的優勢在于它特別適合驗證分布式系統的算法設計。因為對于一個可驗證的算法來說,核心是將系統時刻的狀態確定化,并確定狀態變化的條件和結果,這樣 TLA+ 可以通過窮舉+剪枝檢查當有并發操作時會不會有違反要求(TLA+ 稱之為 invariant)的地方——例如賬戶余額小于 0,系統中存在了多個 leader 等等。

 

看最近的幾場 TLA Community Meeting,可以看到 Elasticserach、MongoDB 都有應用。

那么既然這個東西這么好,為什么在國內開發界似乎并沒有特別流行呢?我們在內部也嘗試應用了一段時間,在 Mini Storage 上做了一些驗證,感覺如果 TLA+ 想應用更廣泛的話,可能還是有幾個問題需要優化:

1. 狀態爆炸,因為 TLA+ 的驗證方式決定了狀態數量要經過精心的抽象和仔細的檢查,如果一味地增加狀態就可能遇到狀態爆炸的問題;

2. TLA+Spec 是無法直接轉換成代碼的,反過來,代碼也無法直接轉換成 Spec。那么換句話說,無論是從代碼到 Spec 還是從 Spec 到代碼都有出錯的可能,輕則有 Bug,重則可能導致你信心滿滿的算法其實與你的實現根本不同;

3. 外部依賴的正確性,這一點可能有點要求過高,但卻也是可靠系統的重要部分,因為用戶是不管產品里是否用到了開源組件,不論是 qemu 的問題還是 Linux 內核的問題,客戶只會認為是你的問題,而我們不太可能分析驗證每個依賴;

當然了,涉及到算法的正確性證明,形式化證明依然是不可替代的,但不得不說目前階段在云平臺存儲上應用,還沒做到全部覆蓋,當然了我們也看到 TLA+ 也在不斷進步——

1. 可視化;

2. 增強可讀性;

3. Spec的可執行;

 

 

 

這里特別是第三點,如果我們的 Spec 能夠被轉換成代碼,那么我們就可以將核心代碼的算法部分抽象出來,做成一個單獨的庫,直接使用被 Spec 證明過的代碼。

分布式系統的測試和驗證,這幾年還有一個很熱門的詞匯,就是混沌工程。

混沌工程對大多數人來說并不是一個新鮮詞匯,可以說它是在單機應用轉向集群應用,面向系統編程轉向到面向服務編程的必然結果,我們已經看到很多互聯網應用聲稱在混沌工程的幫助下提高了系統的穩定性如何如何,那么對于基礎架構軟件呢?

在一定程度上可以說 ZStack 很早就開始在用混沌工程的思想測試系統的穩定性,首先我們有三個關鍵性的外部整體測試:

1. MTBF,這個概念一般見于硬件設備,指的是系統的正常運行的時間,對我們來說會在系統上根據用戶場景反復操作存儲(創建、刪除虛擬機,創建、刪除快照,寫入、刪除數據等)在此之上引入故障檢查正確性;

2. DPMO,這個是一個測試界很老的概念,偏向于單個操作的反復操作,例如重啟 1000 次物理機,添加刪除 10000 次鏡像等等,在這之上再考慮同時引入故障來考察功能的正確性;

3. Woodpecker,這是 ZStack 從最開始就實現的測試框架,代碼和原理都是開源的,它會智能的組合ZStack 的上千個 API自動找到可以持續下去的一條路徑,根據資源當前的狀態判斷資源可以執行的 API,這樣一天下來可以組合執行數萬次乃至上百萬次,與此同時再考慮引入錯誤;

上面這些方法,在大量調用 API、測試 IO 之外,很重要的一點就是注入錯誤,例如強制關閉虛擬機、物理機,通過可編程 PDU 模擬斷電等等,但是這些方法有一些缺陷:

1. 復雜場景的模擬能力有限,例如有些客戶存儲并不是一直 IO 很慢,而是呈現波峰波谷的波浪型,這種情況和 IO 始終有明顯 delay 是有比較大的區別的;

2. 不夠靈活,例如有的客戶存儲隨機 IO 很差但順序 IO 性能卻還可以,也不是簡單的降低 IO 性能就可以模擬的;

總之大部分混沌工程所提供的手段(隨機關閉節點、隨機殺進程、通過 tc 增加延時和 iproute2、iptables改變網絡等等)并不能滿足 ZStack 的完全模擬用戶場景的需求。

在這種情況下,我們將擴展手段放在了幾個方向上:

libfiu,libfiu 可以通過 LD_PRELOAD 來控制應用調用 POSIX API 的結果,可以讓應用申請內存失敗、打開文件失敗,或者執行 open 失敗;

使用 fiurun + fiuctl 可以對某個應用在需要的時刻控制系統調用;

 

fiu對注入 libaio 沒有直接提供支持,但好在 fio 擴展和編譯都極為簡單,因此我們可以輕松的根據自己的需求增加 module;

2. systemtap,systemtap 是系統界的經典利器了,可以對內核函數的返回值根據需求進行修改,對內核理解很清晰的話,systemtap 會很好用,如果是對存儲進行錯誤注入,可以重點搜 scsi 相關的函數,以及參考這里:Kernel Fault injection framework using SystemTap;

3. device-mapper,device-mapper 提供了 dm-flakey、dm-dust、dm-delay,當然你也可以寫自己的 target,然后可以搭配 lio 等工具就可以模擬一個 faulty 的共享存儲,得益于 device-mapper 的動態加載,我們可以動態的修改 target 和參數,從而更真實的模擬用戶場景下的狀態;

4. nbd,nbd 的 plugin 機制非常便捷,我們可以利用這一點來修改每個 IO 的行為,從而實現出一些特殊的 IO pattern,舉例來說,我們就用 nbd 模擬過用戶的順序寫很快但隨機寫異常慢的存儲設備;

5. 此外,還有 scsi_debug 等 debug 工具,但這些比較面向特定問題,就不細說了;

 

 

上面兩張圖對這些錯誤注入手段做了一些總結,從系統角度來看,如果我們在設計階段能夠驗證算法的正確性,在開發時注意開發可測試的代碼,通過海量測試和錯誤注入將路徑完整覆蓋,對遇到的各種 IO 異常通過測試 case 固化下來,我們的存儲系統一定會是越來越穩定,持續的走在“正確”的道路上的。

參加太平洋安防網微信公眾號活動即有機會獲贈全年雜志、太平洋安防官網免費廣告位。安防廣告隨你登,免費雜志任你領!
還等什么呢?微信掃描上方二維碼關注吧!
免責聲明:凡注明來源本網的所有作品,均為本網合法擁有版權或有權使用的作品,歡迎轉載,注明出處。非本網作品均來自互聯網,轉載目的在于傳遞更多信息,并不代表本網贊同其觀點和對其真實性負責。
[責任編輯:]
0條 [查看全部]  相關評論

閱讀推薦

摩根中央公園項目采用海康威視全系列地產解決方案

南陽,古稱宛,河南省轄地級市,位于河南省西南部、豫鄂陜三省交界地帶,因地處伏牛..

英飛拓的自我革新之路 簽訂3.5億合作協議

2019年對于英飛拓而言,似乎是其正式揚帆起航、開疆擴土元年。自開年后,英飛拓中標..

錢林股份攜手山東銀商 打造校園自助充值機

你是否在學校中遇到過這樣的情況呢?想要吃飯,校園卡沒錢!想要充值,窗口人數眾多..

3年后中國無人機市場前景規模將突破500億元

近年來,中國人工智能技術逐漸完善,推動著無人機行業快速發展,伴隨著無人機應用場..

我國應急管理體系發展難點及趨勢

2018年3月,我國應急管理部門成立,按照深化黨和國家機構改革部署要求,我國應急管..

技術資料

【太平洋安防訊】視頻監控系統產品包含光端機,光纜終端盒,云臺,云臺解碼器,視頻..

?

客服專線:0755-83977321|廣告合作:0755-83977123|市場招商熱線:0755-83977388 / 83977188

廣告
合作
:2250409004
網站
客服
:1351574492
新聞
投稿
:1197354471
技術
支持
:712700030

網站備案號:粵ICP備12031422號-1 經營許可證編號:粵B2-20090398 深圳互聯網科技創新企業

太平洋安防網版權所有 2006-2020 互聯網違法和不良信息舉報中心:0755-83977321 [email protected]

百宝彩11选5基本走势图