阿裏雲NAS文件存儲部署方案介紹和對比
NAS業務上雲的背景
作為國內最大的公有雲廠商,阿裏雲為廣大的個人用戶、初創團隊和企業提供了多種多樣的公有雲服務,包括彈性計算,數據庫,存儲和網絡等。阿裏雲彈性伸縮,按需付費,無限容量,便捷使用等特性吸引了大量的客戶把他們的應用以及服務部署到阿裏雲,其中就包括一部分部署NAS應用的客戶,對於這些客戶,麵臨的一個問題就是如何以最大的性價比來將原有的NAS應用部署到雲上。本文介紹了三種可能的部署方案,並比較了他們的優缺點,包括用戶最關心的價格,性能以及擴展性等。
對於企業級NAS應用,大部分企業都會在IDC中部署圖1(圖片來源,EMC Isilon網站)所示的架構
圖1 基於本地服務器的NAS業務部署架構
圖1中計算節點既可以是運行一些企業應用的服務器,也可以是簡單的員工工作終端(PC,MAC等),而網絡設備和存儲節點則分別負責網絡連通和支持NAS協議的文件存儲,其中NAS存儲節點,企業一般會選擇專業存儲廠商產品,比如EMC的Isilon, NetApp的FAS係列,華為的OceanStor係列等,這些產品提供了標準的文件訪問協議NFS和CIFS/SMB,以及豐富的企業級存儲服務,但價格也是不菲的,對於初次部署有比較高的門檻。
公有雲提供了方便,快捷,彈性伸縮的業務部署能力,利用公有雲廠商提供的產品,企業可以將圖1的架構方便地遷移到雲上。一般來說,業務的遷移有兩種方案:1是整體搬遷,包括計算節點、存儲節點和網絡設備都會放到公有雲上;2是計算節點不變,僅僅在雲上部署並使用高可靠、高可用、彈性擴展的高性能文件存儲。從中可見,不管是采用哪種方案,雲上的高性能NAS存儲都是業務順利遷移的保證。對於NAS存儲上雲,企業一般有三種不同方案來實現:
1. 公有雲的NAS文件存儲服務,比如阿裏雲的文件存儲。
2. 在公有雲上自建文件存儲服務,比如利用阿裏雲的ECS和雲盤,利用操作係統的文件共享或者基於一些開源的NAS軟件。
3. 使用軟網關提供的文件存儲服務,比如阿裏雲即將推出的軟網關產品。
那麼這三種雲上的方案從架構、部署、運維、成本等方麵分別都有什麼特點呢?我們結合一個最簡單的應用場景(服務器數據共享和日誌共享)來進行一些分析,其中大部分分析同樣也適用於其他一些NAS應用場景。
對於服務器數據共享和日誌共享的應用,典型的部署方式就是把上文說的圖1轉換成公有雲版本,如圖2所示:
圖2 服務器數據和日誌共享場景
對於Web服務器,或者移動端APP的服務器,該架構中一般會部署多台ECS服務器來處理業務請求,完成用戶生成數據(比如照片,音頻,視頻或者一些運動類APP的特定數據)寫入和讀取,之所以使用多台ECS服務器是出於彈性擴容和負載均衡的考慮,這也對後端存儲提出了多ECS共享數據的需求。對於後端存儲的選擇,該場景下客戶一般都會使用文件存儲,這是因為客戶的軟件大多是基於標準的文件訪問接口(比如Posix或者Windows API)開發的,對於這些標準的文件訪問接口,文件存儲天然就有這樣的支持;而如果采用其他的存儲方式,以最常見的對象存儲或者塊存儲為例的話,就會麵臨一些限製,比如使用對象存儲的話需要對現有軟件進行改造,來適配對象存儲的SDK;而使用塊存儲的話本質上軟件看到是一塊硬盤,需要借助操作係統對其進行格式化(ext3, ext4,NTFS等),相對於文件存儲和對象存儲,這樣的使用方式缺乏多ECS共享存儲的能力。
NAS業務上雲的三種方案
我們接下來就要分析的就是分別用前述的三種方案來實現圖2中的“NAS共享文件存儲”。
方案一:利用公有雲的NAS文件存儲服務
這是最直觀也是最簡單的方案,後端存儲直接使用阿裏雲的文件存儲服務,所有的ECS實例都可以同時掛載同一個文件係統來進行數據的共享,對於數據的訪問,從最簡單的文件讀寫鎖的控製,文件和目錄權限的控製,到整個服務的高可用,高可靠,彈性擴展,都可以完全由阿裏雲文件存儲NAS托管。用戶隻需要完成如下三個簡單步驟,就能完成圖2中文件存儲的部署:
1. 創建文件係統,不需要顯式指定文件係統容量,因為容量是隨著用戶的真實使用情況完全彈性擴展的。
2. 為文件係統添加掛載點,支持VPC方式和經典網絡方式。
3. 在ECS上掛載文件係統,推薦的方式是在Linux服務器上使用NFS協議掛載文件係統,而在Windows服務器上使用CIFS/SMB協議掛載。
關於這三個步驟的圖文示例可以參考這兩個鏈接,從中可以看到,僅僅需要輕點幾下鼠標,圖2中的NAS文件存儲部署就完成了!
方案二:在公有雲上自建文件存儲服務
這種方案下,用戶需要自己搭建NAS文件存儲服務,可以僅支持NFS或者CIFS/SMB,也可以同時支持兩種協議。一個典型的方式是如圖3所示:
圖3: 用ECS+雲盤來構建NAS存儲服務
這種部署方式下,用戶需要配置一台額外的ECS,以及配置一塊雲盤,將雲盤格式化並掛載在ECS上,作為文件係統的存儲,同時在ECS上用戶還選擇依賴於操作係統的支持,或者自己部署支持NFS、CIFS/SMB的軟件(一般是開源軟件,也可以自己開發),把雲盤上創建的文件係統通過NFS或者CIFS/SMB輸出給需要訪問共享文件係統的其他ECS。
使用該方式有幾個明顯的缺陷:
1. 容量的限製,雲盤的單盤容量最大是32T,萬一達到了這個限製,需要部署更多的雲盤,然後使用類似LVM的方式管理多塊盤,這需要用戶對使用容量有一個明確的預期,而這卻恰恰是很難的,用戶把數據放在公有雲上的一個重要原因就是看中公有雲的彈性擴展功能,容量應該是按使用自動擴展,而且可以認為是無限擴展,而不應該是在業務部署之初就決定的!
2. 為了適配自己的業務需求,用戶往往需要自己部署運維開源NAS軟件,並對軟件進行一些修改和調優,這些都需要很大的技術積累!
3. 單點故障問題,如果ECS上的NAS軟件出了問題,比如程序出錯重啟,那麼NAS服務在這段時間是中斷的,並且,在一般情況下為處於性能的考慮,NAS軟件會使用write-back的cache,那麼當NAS軟件意外重啟時還有很大的幾率出現數據丟失的情況發生;如果ECS本身出了故障,同樣會有數據丟失的風險;更糟糕的是,如果ECS嚴重故障導致掉線,那麼整個存儲的訪問都會癱瘓,對用戶來說將是一場災難!
4. 性能無法線性擴展,表現在兩個方麵:
a) 需要提前規劃作為文件服務服務器的ECS的規格,如果一開始選擇規格較低的ECS,當業務量增大時,文件服務器ECS的資源(CPU,內存等)都會成為性能瓶頸;而一開始就選擇合適的ECS規格有將會麵臨諸多挑戰:1. 初期部署價格過高;2. 無法準確預知未來的業務量和對ECS性能的需求。
b) 不管是ECS還是雲盤,都有帶寬限製;在這種部署方式下,帶寬的瓶頸往往發生在提供NFS和CIFS/SMB服務的ECS上,由於ECS虛擬網卡的內網帶寬一般在幾十至100MBps,這也意味著當多台ECS服務器訪問共享文件係統是,總帶寬會受限於這個值。
5. 另外,采用這種方式,企業投入的成本會比方案1高很多(詳情可見後文的對比分析)
針對第3點和第4點,可以有兩種解決方案:
a) 部署多套ECS+雲盤,以Active/Standby的方式提供NAS存儲,此時需要把Active節點上的雲盤內容實時同步到Standby節點的雲盤上,否則在發生切換的時候會丟數據,另外用戶還需要自己管理所有軟件的HA功能。這樣的改進可以解決單點故障問題,但依然沒法做到性能的線性擴展!
b) 部署多套ECS+雲盤,使用NAS軟件的集群功能來以Active/Active的方式提供NAS存儲,此時為了配合NAS軟件的集群功能,需要在多個ECS間部署集群文件係統(比如LusterFS,GlusterFS等),來保證多ECS上NAS軟件看到的一個單一命名空間的文件係統。這種方式下,對用戶的技術積累有極高的要求,並且需要用戶在業務的早期就對這方麵進行仔細的考慮,並把係統設計成分布式文件係統+集群NAS的方式(否則未來會麵臨如何將本地文件係統平滑升級到分布式文件係統的困境),而如果這樣做的話,對於前期的部署投入非常大,是非常不合算的!
方案三:使用軟網關提供的文件存儲服務
軟網關的部署方式如圖4所示,
圖4: 用軟網關來構建NAS存儲服務
該方案和方案二非常類似,主要不同之處在於:
1. 用軟網關產品替換ECS+NAS軟件,幫用戶省掉了對NAS軟件運維的投入,用戶僅需要購買軟網關,並將其部署在ECS上即可。
2. 後端存儲從雲盤切換到了OSS對象存儲,降低了成本,並去除了存儲容量不能彈性擴容限製。
可見,方案三解決了方案二中前兩個痛點,但對於後麵幾個痛點,包括單點故障問題,橫向擴展的限製等,方案三從架構上和方案二還是一樣的。另外,值得一提的是,
- 對於網絡帶寬,因為軟網關和前端ECS服務器以及後端OSS存儲都是走的同一塊虛擬網卡,那麼在網關Cache Miss的情況下,從前端ECS訪問軟網關的帶寬理論上也隻能達到虛擬網卡帶寬的一半。
- 由於軟網管對於NAS數據的緩存功能(數據先存儲在軟網關,定時同步到後端),當發生時ECS宕機時,會有數據丟失的概率。因此雖然OSS能提供10個9的數據可靠度,但方案三的整體數據可靠性會大打折扣。
三種方案的價格和性能對比
以上討論了三種方案功能上的差異,以下讓我們從用戶最關心的性價比,來對比一下這三個方案。
方案一的成本完全在於存儲:
阿裏雲NAS提供了性能型(全SSD存儲)和容量型(SSD和SATA混合存儲)兩種方案,取決於用戶對於訪問性能的要求,用戶可以選擇兩者之一。
兩種類型NAS形態的性能和價格對比如下表所示:
|
性能型 |
容量型 |
最大容量 |
1PB |
10PB |
性能-最大IOPS |
10K+ |
10K+ |
訪問時延 |
ms級 |
ms級 |
性能-最大帶寬 |
0.04MB/s * 文件係統存儲空間(GB) + 60MB/s |
0.02MB/s * 文件係統存儲空間(GB) + 30MB/s |
價格(每GB每月) |
1.2~2元 |
0.3~0.55元 |
表1:性能型NAS和容量型NAS對比
方案二的成本由ECS和雲盤兩者組成:
阿裏雲的雲盤也分為多種,容量和性能如下表所示。
塊存儲類型 |
SSD 雲盤 |
高效雲盤 |
普通雲盤 |
單盤最大容量 |
32768GB |
32768GB |
2000GB |
單盤最大IOPS |
20000 |
3000 |
數百 |
單盤最大吞吐量 |
256MBps |
80MBps |
20~40MBps |
性能計算公式 |
IOPS=min{30*容量,20000} |
IOPS=min{1000+6*容量,3000} |
不適用 |
訪問時延 |
0.5 - 2ms |
1 - 3ms |
5 - 10ms |
價格(每GB每月) |
1.0元 |
0.35元 |
0.3元 |
表2:不同類型雲盤對比
顯然普通雲盤的性能不適合我們這邊討論的場景,我們隻會考慮SSD雲盤和高效雲盤這兩種情況。
另外對於ECS的選型,阿裏雲提供了很多種型號供選擇,因為在NAS場景下文件緩存對於性能有比較大的影響,我們選擇內存型ECS中中檔的ecs.e3.large(4核32GB內存)來作為文件服務器。
此外,采用這種方案,用戶需要自己管理NAS的運維,在比較中我們假設對運維人員的投入是每年50000元(一個普通運維工程師的收入應該遠高於這個數字)。
方案三的成本由ECS、軟網關以及OSS三者組成。對比中,ECS選擇了和方案二中相同的ecs.e3.large(4核32GB內存)型號;由於軟網關目前還沒有官方報價,我們這裏假設其為50000元每年; OSS是對存儲量和數據請求量同時收費的,對於數據請求,我們假設經過軟網關對於NAS數據讀寫緩存,每TB到達OSS的請求是50次每秒(對於典型的NAS應用,由於大量小文件的存在,這個IOPS的估計還是相當保守的)。
圖5和圖6顯示了不同方案部署方式下的成本和文件係統最大訪問帶寬的對比。
圖5 三種NAS部署方案一年總體擁有成本(TCO)對比
圖6 三種NAS部署方案最大帶寬對比
從圖5和圖6中可以看出:
1. 價格方麵,
i. 方案一整體要好於方案二(性能型對比SSD雲盤,容量型對比高效雲盤)。
ii. 和方案三相比,在容量小於10TB容量的情況下,直接使用阿裏雲NAS的方案,不管是性能型還是容量型,都具有明顯的優勢;在容量小於100TB情況下,容量型NAS依然具有優勢,直到容量接近1PB的情況下,使用方案三才會與容量型NAS有差不多的價格。
2. 最大訪問帶寬方麵,由於方案二和方案三都會受限於ECS虛擬網卡的帶寬(100MBps),而直接使用阿裏雲NAS的方案支持完全橫向擴展,具有明顯的優勢,尤其是在容量增大的情況下。
總結
最後,讓我們以對這三個方案的多維度對比來做一個總結,如表3。
|
阿裏雲 NAS |
ECS + 雲盤 + 開源NAS軟件 |
軟網關 + OSS |
|
NAS協議支持 |
NFS3、NFS4 SMB2、SMB3 |
取決於開源NAS軟件 |
NFS和SMB 具體協議取決於網關的能力 |
|
高可用 |
完全橫向擴展,多機頭Active |
不支持
|
不支持 |
|
高可靠 |
10個9可靠度 |
數據可靠性低 當ECS出現故障時,會有數據丟失的風險 |
數據可靠性低 當軟網關出現故障時,會有數據丟失的風險 |
|
容量上限 |
10PB(容量型) 1PB(性能型) |
32TB*雲盤數 |
理論上無上限 |
|
支持容量橫向擴展的能力 |
Y |
N
|
Y |
|
訪問延時 |
毫秒級 |
依賴於ECS性能,可以達到毫秒級 |
網關cache miss:幾十毫秒級; 網關cache hit:毫秒級(部分依賴於ECS性能) |
|
訪問帶寬 |
最高2GBps |
受限於ECS網卡帶寬100MBps |
受限於ECS網卡帶寬100MBps |
|
支持性能橫向擴展的能力 |
Y |
N |
N |
|
用戶NAS運維開銷 |
無 |
高 |
無 |
|
成本 |
低 |
高 |
高 在數據量達到PB級時才和容量型NAS相當 |
表3:NAS部署方案綜合對比
從中可以看到,從多方麵(功能,性能和價格)綜合考慮,使用阿裏雲NAS文件存儲是企業NAS業務上雲的最好選擇。
參考文獻:
1. 阿裏雲文件存儲 https://www.aliyun.com/product/nas
2. 初探阿裏雲存儲網關 https://yq.aliyun.com/articles/72714?spm=5176.100239.0.0.wieqpt
最後更新:2017-05-19 16:38:19