關於分佈式存儲

分佈式存儲存在的風險,其實就是因爲“共享”、“大數據量”、“高性能”和X86服務器+廉價的磁盤爲載體之間的矛盾所產生的,不是有些讀者說的“數據架構”的問題。其實任何存儲都存在這個問題,只是分佈式存儲更嚴重。

本文其實是從主機的網絡、磁盤的吞吐角度分析存在的風險,所以和用那個廠家的存儲無關。

還有人說你是危言聳聽,如果按照你說的,這麼多人用了分佈式存儲有這樣的地雷豈不是要炸飛?軟件定義的東西其實有很多BUG,重要的是能發現問題,事先做好彌補或方案。

還有人說,分佈式存儲用到現在也不超過2年,發生你說的問題還早。但是我們已經發現問題了,不能擱置不管。釣魚島問題擱置了,現在還不是造成麻煩了嗎?

拋磚引玉

存儲最重要的指標是什麼?

很多人包括存儲專家都會認爲是存儲的性能指標,比如IOPS和吞吐量。但是我認爲存儲最重要的是數據的安全性。

一個跑的飛快的存儲,突然數據丟失了,後果會怎麼樣?數據的丟失,對於任何系統來說,都是滅頂之災。

所以,不管什麼樣的存儲,數據的安全可靠都是第一位的。

原來傳統的存儲使用了專用硬件,從可靠性上有比較高的保證,所以大家首先會關注性能指標。但是用X86爲基礎的SRVSAN的可靠性就不容樂觀。

爲什麼說傳統存儲這個問題不是太突出呢?

除了專用設備外,還有應用場景和數據量不同等原因。在傳統行業如電信、銀行原來的系統建設是煙囪模式。不但網絡是獨立一套,存儲也是。

往往是數據庫服務和日誌記錄,用2臺服務器和8個端口的小光交相連,小光交下只掛一個存儲。數據量也沒有這樣大,存儲的容量也在5T以下。這樣存儲的數據遷移是很容易和快速的,方法也很多。

由於是專用存儲,所以完全可以採用“非在線”的手段,數據量也不大,可以在夜深人靜的時候停機完成。

進入雲計算時代,存儲是共享的,數據是應用可靠,提供者不可控,數據量海量增加……傳統的方法失靈了。(可見顧炯的雲世界的“資源池內存儲特點”的文章)

我們在2014年下半年,開始搭建以X86爲載體的分佈式塊存儲,經過嚴格的測試,在同年底投入商用,是業界首個商用的軟件定義的分佈式存儲,當時各種媒體都爭相報道。

到現在爲止已經商用了近2年,存儲運行穩定,表現優良。並從原來2P裸容量擴容到4.5P。

但是近段時間我卻越來越擔心,因爲SRVSAN與生俱來的數據安全隱患,一直被人忽視了,而且主流廠家也沒有意識到這個問題。如果這個隱患在若干年以後爆發,會發生重大性系統故障。

其實我在寫這篇文章前2個月,我已經將這個擔憂和想法告訴了現有分佈式塊存儲的產品線總經理,得到他的重視,已經在彌補了。很多軟件定義的東西,就怕想不到,突然發生了,想到了就會有相應的解決方案。

存儲這個東西,大部分讀者並不是太瞭解,從比較基礎知識開始寫,並引出問題和大家一起討論解決的辦法。盤算了一下大致分爲七個部分,由於篇幅限制,在本篇將先介紹前三部分:

一、存儲類型

二、文件系統

三、存儲介質

四、Raid和副本

五、SRVSAN的架構

六、SRVSAN的安全隱患

七、解決的方法

一、存儲類型

一般情況下,我們將存儲分成了4種類型,基於本機的DAS和網絡的NAS存儲、SAN存儲、對象存儲。對象存儲是SAN存儲和NAS存儲結合後的產物,汲取了SAN存儲和NAS存儲的優點。

圖1

我們來了解一下應用是怎麼樣獲取它想要的存在存儲裏的某個文件信息,並用大家熟悉的Windows來舉例,如圖1。

  • 1、應用會發出一個指令“讀取本目錄下的readme.txt 文件的前1K數據”。
  • 2、通過內存通信到目錄層,將相對目錄轉換爲實際目錄,“讀取C:\ test\readme.txt文件前1K數據”
  • 3、通過文件系統,比如FAT32,通過查詢文件分配表和目錄項,獲取文件存儲的LBA地址位置、權限等信息。

文件系統先查詢緩存中有沒有數據,如果有直接返回數據;沒有,文件系統通過內存通信傳遞到下一環節命令“讀取起始位置LBA1000,長度1024的信息”。

  • 4、卷(LUN)管理層將LBA地址翻譯成爲存儲的物理地址,並封裝協議,如SCSI協議,傳遞給下一環節。
  • 5、磁盤控制器根據命令從磁盤中獲取相應的信息。

如果磁盤扇區大小是4K,實際一次I/O讀取的數據是4K,磁頭讀取的4K數據到達服務器上的內容後,有文件系統截取前1K的數據傳遞給應用,如果下次應用再發起同樣的請求,文件系統就可以從服務器的內存中直接讀取。

不管是DAS、NAS還是SAN,數據訪問的流程都是差不多的。DAS將計算、存儲能力一把抓,封裝在一個服務器裏。大家日常用的電腦,就是一個DAS系統,如圖1。

圖2

如果將計算和存儲分離了,存儲成爲一個獨立的設備,並且存儲有自己的文件系統,可以自己管理數據,就是NAS,如圖2。

計算和存儲間一般採用以太網絡連接,走的是CIFS或NFS協議。服務器們可以共享一個文件系統,也就是說,不管服務器講的是上海話還是杭州話,通過網絡到達NAS的文件系統,都被翻譯成爲普通話。

所以NAS存儲可以被不同的主機共享。服務器只要提需求,不需要進行大量的計算,將很多工作交給了存儲完成,省下的CPU資源可以幹更多服務器想幹的事情,即計算密集型適合使用NAS。

圖3

計算和存儲分離了,存儲成爲一個獨立的設備,存儲只是接受命令不再做複雜的計算,只幹讀取或者寫入文件2件事情,叫SAN,如圖3。

因爲不帶文件系統,所以也叫“裸存儲”,有些應用就需要裸設備,如數據庫。存儲只接受簡單明瞭的命令,其他複雜的事情,有服務器端幹了。再配合FC網絡,這種存儲數據讀取/寫入的速度很高。

但是每個服務器都有自己的文件系統進行管理,對於存儲來說是不挑食的只要來數據我就存,不需要知道來的是什麼,不管是英語還是法語,都忠實記錄下來的。

但是隻有懂英語的才能看懂英語的數據,懂法語的看懂法語的數據。所以,一般服務器和SAN存儲區域是一夫一妻制的,SAN的共享性不好。當然,有些裝了集羣文件系統的主機是可以共享同一個存儲區域的。

從上面分析,我們知道,決定存儲的快慢是由網絡和命令的複雜程度決定的。

內存通信速度>總線通信>網絡通信

網絡通信中還有FC網絡和以太網絡。FC網絡目前可以實現8Gb/s,但以太網絡通過光纖介質已經普及10Gb/s,40Gb/s的網卡也在使用了。也就是說傳統以太網絡已經不是存儲的瓶頸了。除了FCSAN,IPSAN也是SAN存儲的重要成員。

對存儲的操作,除了熟悉的讀/寫以外,其實還有創建、打開、獲取屬性、設置屬性、查找等等。

對於有大腦的SAN存儲來說,除了讀/寫以外的命令,都可以在本地內存中完成,速度極快。

而NAS存儲缺乏大腦,每次向存儲傳遞命令,都需要IP封裝並通過以太網絡傳遞到NAS服務器上,這個速度就遠遠低於內存通信了。

  • DAS特點是速度最快,但只能自己用;
  • NAS的特點速度慢點但共享性好;
  • SAN的特點是速度快,但共享性差。

總體上來講,對象存儲同兼具SAN高速直接訪問磁盤特點及NAS的分佈式共享特點。

NAS存儲的基本單位是文件,SAN存儲的基本單位是數據塊,而對象存儲的基本單位是對象,對象可以認爲是文件的數據+一組屬性信息的組合,這些屬性信息可以定義基於文件的RAID參數、數據分佈和服務質量等。

採取的是“控制信息”和“數據存儲”分離的模式,客戶端用對象ID+偏移量作爲讀寫的依據,客戶端先從“控制信息”獲取數據存儲的真實地址,再直接從“數據存儲”中訪問。

對象存儲大量使用在互聯網上,大家使用的網盤就是典型的對象存儲。對象存儲有很好的擴展性,可以線性擴容。並可以通過接口封裝,還可以提供NAS存儲服務和SAN存儲服務。

VMware的vSAN本質就是一個對象存儲。分佈式對象存儲就是SRVSAN的一種,也存在安全隱患。因爲這個隱患是X86服務器帶來的。

二、文件系統

計算機的文件系統是管理文件的“賬房先生”。

  • 首先他要管理倉庫,要知道各種貨物都放在哪裏;
  • 然後要控制貨物的進出,並要確保貨物的安全。

如果沒有這個“賬房先生”,讓每個“夥計”自由的出入倉庫,就會導致倉庫雜亂無章、貨物遺失。

就像那年輕紡城機房剛啓用的時候,大家的貨物都堆在機房裏,沒有人統一管理,設備需要上架的時候,到一大堆貨物中自行尋找,安裝後的垃圾也沒有人打掃,最後連堆積的地方都找不到,有時自己的貨物找不到了,找到別人的就使用了……。

大家都怨聲載道,後來建立了一個倉庫,請來了倉庫管理員,用一本本子記錄了貨物的歸宿和存儲的位置,建立貨物的出入庫制度,問題都解決了,這就是文件系統要做的事情。

文件系統管理存取文件的接口、文件的存儲組織和分配、文件屬性的管理(比如文件的歸屬、權限、創建事件等)。

每個操作系統都有自己的文件系統。比如windows就有常用的FAT、FAT32、NTFS等,Linux用ext1-4的等。

存儲文件的倉庫有很多中形式,現在主要用的是(機械)磁盤、SSD、光盤、磁帶等等。

拿到這些介質後,首先需要的是“格式化”,格式化就是建立文件存儲組織架構和“賬本”的過程。比如將U盤用FAT32格式化,我們可以看到是這樣架構和賬本(如圖4):

圖4

主引導區:記錄了這個存儲設備的總體信息和基本信息。比如扇區的大小,每簇的大小、磁頭數、磁盤扇區總數、FAT表份數、分區引導代碼等等信息。

分區表:,即此存儲的賬本,如果分區表丟失了,就意味着數據的丟失,所以一般就保留2份,即FAT1和FAT2。分區表主要記錄每簇使用情況,當這位置的簇是空的,就代表還沒有使用,有特殊標記的代表是壞簇,位置上有數據的,是指示文件塊的下一個位置。

目錄區:目錄和記錄文件所在的位置信息。

數據區:記錄文件具體信息的區域。

通過以下的例子來幫助理解什麼是FAT文件系統。

假設每簇8個扇區組成一個簇,大小是512*8=4K。根目錄下的readme.txt文件大小是10K,如圖5:

圖5

  • 1、在目錄區找到根目錄下文件readme.txt在FAT表中的位置是0004
  • 2、在0004位置對應簇的8個扇區讀取相應文件塊readme(1)保存在內存,並獲取下一個數據塊的位置0005。
  • 3、在0005位置對應簇的8個扇區讀取相應文件塊readme(2)保存在內存,並獲取下一個數據塊的位置0008。
  • 4、在0005位置對應簇的4個扇區讀取相應文件塊readme(3)保存在內存,並獲得結束標誌。
  • 5、將readme(1)、readme(2)、readme(3)組合成爲readme文件。

在這個例子中,我們看到在FAT文件系統,是通過查詢FAT表和目錄項來確定文件的存儲位置,文件分佈是以簇爲單位的數據塊,通過“鏈條”的方式來指示文件數據保存的文字。

當要讀取文件時,必須從文件頭開始讀取。這樣的方式,讀取的效率不高。

不同的Linux文件系統大同小異,一般都採取ext文件系統,如圖6.

圖6

啓動塊內是服務器開機啓動使用的,即使這個分區不是啓動分區,也保留。

超級塊存儲了文件系統的相關信息,包括文件系統的類型,inode的數目,數據塊的數目

Inodes塊是存儲文件的inode信息,每個文件對應一個inode。包含文件的元信息,具體來說有以下內容:

文件的字節數

文件擁有者的User ID

文件的Group ID

文件的讀、寫、執行權限

文件的時間戳,共有三個:ctime指inode上一次變動的時間,mtime指文件內容上一次變動的時間,atime指文件上一次打開的時間。

鏈接數,即有多少文件名指向這個inode

文件數據block的位置

當查看某個目錄或文件時,會先從inode table中查出文件屬性及數據存放點,再從數據塊中讀取數據。

數據塊:存放目錄和文件數據。

通過讀取\var\readme.txt文件流程,來理解ext文件系統,如圖7。

 

圖7

  • 1、根目錄A所對應的inode節點是2,inode1對應的數據塊是d1。
  • 2、在檢索d1內容發現,目錄var對應的inode=28,對應的數據塊是d5。
  • 3、檢索d5內容發現readme.txt對應的是inode=70。
  • 4、Inode70指向數據區d2、d3、d6塊。讀取這些數據塊,在內存中組合d2、d3、d6數據塊。

硬盤格式化的時候,操作系統自動將硬盤分成兩個區域。

  • 一個是數據區,存放文件數據;
  • 另一個是inode區,存放inode所包含的信息。

當inode資源消耗完了,儘管數據區域還有空餘空間,都不能再寫入新文件。

總結:Windows的文件系統往往是“串行”的,而linux的文件系統是“並行”的。

再來看分佈式的文件系統。

如果提供持久化層的存儲空間不是一臺設備,而是多臺,每臺之間通過網絡連接,數據是打散保存在多臺存儲設備上。也就是說元數據記錄的不僅僅記錄在哪塊數據塊的編號,還要記錄是哪個數據節點的。

這樣,元數據需要保存在每個數據節點上,而且必須實時同步。做到這一點其實很困難。如果把元數據服務器獨立出來,做成“主從”架構,就不需要在每個數據節點維護元數據表,簡化了數據維護的難度,提高了效率。

Hadoop的文件系統HDFS就是一個典型的分佈式文件系統。

圖8

  • 1、Client將FileA按64M分塊。分成兩塊,block1和Block2。
  • 2、Client向nameNode發送寫數據請求,如圖紫色虛線1。
  • 3、NameNode節點,記錄block信息。並返回可用的DataNode給客戶端,如圖紅色虛線2。

Block1: host11,host22,host31

Block2: host11,host21,host32

  • 4、client向DataNode發送block1;發送過程是以流式寫入。

流式寫入過程:

1)將64M的block1按64k的package劃分;

2)然後將第一個package發送給host11;

3)host11接收完後,將第一個package發送給host22,同時client想host11發送第二個package;

4)host22接收完第一個package後,發送給host31,同時接收host11發來的第二個package。

5)以此類推,如圖黑色虛線3所示,直到將block1發送完畢。

6)host11,host22,host31向NameNode和 Client發送通知,說“消息發送完了”。

7)client收到發來的消息後,向namenode發送消息,說我寫完了。這樣就真完成了。

8)發送完block1後,再向host11,host21,host32發送block2,如圖藍色虛線4所示。

……….

HDFS是分佈式存儲的雛形,分佈式存儲將在以後詳細介紹。

三、存儲介質

倉庫有很多種存儲的介質,現在最常用的是磁盤和SSD盤,還有光盤、磁帶等等。磁盤一直以性價比的優勢佔據了霸主的地位。

圓形的磁性盤片裝在一個方的密封盒子裏,運行起來吱吱的響,這就是我們常見的磁盤。磁片是真正存放數據的介質,每個磁片正面和背面上都“懸浮”着磁頭。

磁盤上分割爲很多個同心圓,每個同心圓叫做磁道,每個磁道又被分割成爲一個個小扇區,每個扇區可以存儲512B的數據。當磁頭在磁片上高速轉動和不停換道,來讀取或者寫入數據。

其實磁片負責高速轉動,而磁頭只負責在磁片上橫向移動。決定磁盤性能的主要是磁片的轉速、磁頭的換道、磁盤、每片磁片的容量和接口速度決定的。轉速越高、換道時間越短、單片容量越高,磁盤性能就越好。

圖9

圖10

圖11

衡量磁盤性能主要參考 IOPS 和吞吐量兩個參數。

IOPS就是一秒鐘內磁盤進行了多少次的讀寫。

吞吐量就是讀出了多少數據。

其實這些指標應該有前提,即是大包(塊)還是小包(塊),是讀還是寫,是隨機的還是連續的。一般我們看到廠家給的磁盤IOPS性能一般是指小包、順序讀下的測試指標。這個指標一般就是最大值。

目前在X86服務器上我們常使用的 SATA、SAS磁盤性能:

圖12

實際生產中估算,SATA 7200轉的磁盤,提供的IOPS爲60次左右,吞吐量在70MB/s。

我們2014年首次使用的裸容量2P的SRVSAN存儲的數據持久化層採用57臺X86服務器,內置12塊SATA7200 3TB硬盤。共684塊磁盤,大約只提供41040次IOPS和47.88GB/s。

這些指標顯然是不能滿足存儲需要的,需要想辦法“加速”。

機械磁盤其實也做了很多優化,比如扇區地址的編號不是連續的。

因爲磁片轉的夠快(7200轉/分鐘即1秒鐘轉120轉,轉一圈是8.3毫秒,也就是在讀寫同一個磁道最大時延是8.3秒),防止磁頭的讀寫取錯過了,所以扇區的地址並不是連續的,而是跳躍編號的,比如2:1的交叉因子(1、10、2、11、3、12…..)。

同時磁盤也有緩存,具有隊列,並不是來一個I/O就讀寫一個,而是積累到一定I/O,根據磁頭的位置和算法完成的。I/O並不是一定是“先到先處理”,而是遵守效率。

加速最好的辦法就是使用SSD盤。磁盤的控制部分是由機械部分+控制電路來構成,機械部分的速度限制,使磁盤的性能不可能有大的突破。而SSD採用了全電子控制可以獲得很好的性能。

SSD是以閃存作爲存儲介質再配合適當的控制芯片組成的存儲設備。目前用來生產固態硬盤的NAND Flash有三種:

單層式存儲(SLC,存儲1bit數據)

二層式存儲(MLC,存儲4bit數據)

三層式存儲(TLC,存儲8bit數據)

SLC成本最高、壽命最長、但訪問速度最快,TLC成本最低、壽命最短但訪問速度最慢。爲了降低成本,用於服務器的企業級SSD都用了MLC,TLC可以用來做U盤。

圖13

SSD普及起來還有一點的障礙,比如成本較高、寫入次數限制、損壞時的不可挽救性及當隨着寫入次數增加或接近寫滿時候速度會下降等缺點。

對應磁盤的最小IO單位扇區,page是SSD的最小單位。

比如每個page存儲512B的數據和218b的糾錯碼,128個page組成一個塊(64KB),2048個塊,組成一個區域,一個閃存芯片有2個區域組成。Page的尺寸越大,這個閃訊芯片的容量就越大。

但是SSD有一個壞習慣,就是在修改某1個page的數據,會波及到整塊。需要將這個page所在的整塊數據讀到緩存中,然後再將這個塊初始化爲1,再從緩存中讀取數據寫入。

對於SSD來說,速度可能不是問題,但是寫的次數是有限制的,所以塊也不是越大越好。當然對於機械磁盤來說也存在類似問題,塊越大,讀寫的速度就越快,但浪費也越嚴重,因爲寫不滿一塊也要佔一塊的位置。

不同型號不同廠家的SSD性能差異很大,下面是我們的分佈式塊存儲作爲緩存使用的SSD參數:

採用PCIe 2.0接口,容量是1.2T,綜合讀寫IOPS(4k小包)是260000次,讀吞吐量1.55GB/s,寫吞吐量1GB/s。

在1臺SRVSAN的服務器配置了一塊SSD作爲緩存和12塊7200轉 3T SATA盤,磁盤只提供1200次、1200M的吞出量。

遠遠小於緩存SSD提供的能力,所以直接訪問緩存可以提供很高的存儲性能,SRVSAN的關鍵是計算出熱點數據的算法,提高熱點數據的命中率。

用高成本的SSD做爲緩存,用廉價的SATA磁盤作爲容量層。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章