使用 QNAP QES 系列建構超大容量儲存系統
技術概觀與適用場景
有鑑於高可用性檔案伺服器,企業私有雲的雲端儲存,線上視訊串流,數位監控儲存等等,皆需要超大容量儲存設備。一般消費級NAS受限於軟硬體架構,難以承擔企業級高壓力、高可用性的環境;且傳統檔案系統並未對超大容量做最佳化,包括單儲存空間最大容量限制,不具備確保資料完整性的功能等等。
QNAP ES 系列具備幾無停機的高可用性(High-Availability)、資料自我修復能力(Self-Healing)、資料壓縮與重複刪除、幾無數量限制快照(Snapshot)、以及瞬間建構磁碟陣列等功能,不僅具備所有基礎所需功能,並提供最高性價比的超大容量儲存方案。
示範場景
超大容量儲存池之建構
準備磁碟擴充櫃
QNAP QES系統提供跨擴展櫃的儲存池建構,以ES1640dc為例,此一儲存設備內建16個磁碟插槽,若要建構超大容量系統,須另外搭配其所附屬的磁碟擴充櫃,以得到數量足夠的擴充空間。其中雙控制器的ES及其JBOD每櫃皆提供16個磁碟插槽,根據雙控制器的ES1640dc系列的設計,最多可串接7台EJ JBOD,故單一系統將可提供16x(1+7)=128的磁碟插槽。
又QNAP雙控系列的ES1640dc v2支援EJ1600 v2磁碟擴充櫃,與NAS主機之間採SAS 12Gb/s介面連接,比USB介面有更低的延遲時間。又EJ系列磁碟擴充櫃也是採雙控制器設計,互相提供備援,每組控制器又具備2埠SAS擴充埠,讓ES NAS跟EJ擴充櫃之間能以雙迴路、4組SAS連接埠架構串接,且互連總頻寬達到48 Gbps,打造最高效能,最可靠的高可用性基礎環境。
QNAP ES NAS與EJ擴充櫃建議連接架構
其中ES NAS跟EJ JBOD皆為雙控制器架構,每組控制器上內建2組外接SAS連接埠,為了有效建置雙迴路拓樸,建議每組機箱依照上圖架構進行串接,以確保單點故障時,儲存系統依舊能保持正常的運行。完成雙迴路連線後,將可允許系統任一邊NAS控制器,與任一邊JBOD控制器同時故障;即便任一條線路異常損毀時,系統依舊從另一組迴路存取資料。
註:最下方一台JBOD將需要2條較長的SAS線,以接回ES NAS本體(Loop Back)。硬體與線材的詳細配置,可參考下方的物料清單表。
可安裝磁碟數與相對應的物料清單
QNAP ES NAS |
QNAP |
0.5M SAS短線 |
Loop back SAS長線 |
SAS線總數 |
可安裝磁碟總數 |
最大原始容量 (註) |
|---|---|---|---|---|---|---|
| 1台 | 0台 | 0條 | 0條 | 0條 | 16 | 160 TB |
| 1台 | 1台 | 2條 | 2條 (0.5M) | 4條 | 32 | 320 TB |
| 1台 | 2台 | 4條 | 2條 (1M) | 6條 | 48 | 480 TB |
| 1台 | 3台 | 6條 | 2條 (1M) | 8條 | 64 | 640 TB |
| 1台 | 4台 | 8條 | 2條 (1M) | 10條 | 80 | 880 TB |
| 1台 | 5台 | 10條 | 2條 (2M) | 12條 | 96 | 960 TB |
| 1台 | 6台 | 12條 | 2條 (2M) | 14條 | 112 | 1120 TB (1.12PB) |
| 1台 | 7台 | 14條 | 2條 (2M) | 16條 | 128 | 1280 TB (1.28PB) |
註:以單顆原始容量10 TB硬碟計算,實際可用有效容量較此值小。
若需精確估計實際可用容量,請使用ES NAS ZFS容量計算工具:
(https://enterprise-nas.qnap.com/en/calculator/)
需要 SSD 嗎?
雙控制系列的ES NAS系統支援將SSD設定為讀取快取(Read Cache)使用,但SSD容量小價格貴,而且也會占用硬碟插槽,該如何抉擇?以技術觀點分析,SSD將可提供硬碟達不到的低延遲反應速度,倘若應用場景對於讀取方面重視低延遲,像是資料庫、虛擬桌面等等,SSD將可發揮它的價值;倘若主要應用是檔案伺服器,多半只注重大容量與讀寫頻寬,則可視情況,以純硬碟架構進行儲存系統的佈建。
規劃RAID架構與熱備援磁碟
一旦儲存系統所置放的資料越多,其所產生不可控制的災難損失也將隨之增加,因此資料的可靠性與備份計畫將是一大重要課題。在建構整體系統之前,我們可以依照資料的重要性、容量利用率、及資料損失的承受度規劃磁碟陣列架構。
由於QES是基於ZFS檔案系統為基礎所發展出來的儲存系統,對於資料保護的完整性、磁碟陣列模式與儲存管理的設計更為成熟,其中包括全域熱備援 (Global Hot Spare)技術,允許同時故障3顆硬碟的RAIDTP模式,資料3倍保護的Triple-Mirror模式等等。在強調多重備份的環境下,QES允許您大幅犧牲效能與容量利用率,成全絕對的可靠性。
對於一般用途來說,建議使用ZFS RAID Group的架構,以每台NAS/JBOD的10~15顆磁碟為一單位,建立RAID6模式,並預留1顆空白磁碟,搭配全域熱備援技術,即可兼顧完整的資料保護與災難容錯效果。其建議設定如下表與次頁圖片。
128顆磁碟RAID配置範例
| 在哪裡 | 安裝磁碟數量 | 陣列模式 | 熱備援預留 |
|---|---|---|---|
| ES NAS | 16顆 | 11顆RAID6 | 1顆 |
| (4顆系統碟不列入儲存池) | |||
| EJ JBOD#1 | 16顆 | 15顆RAID6 | 1顆 |
| EJ JBOD#2 | 16顆 | 15顆RAID6 | 1顆 |
| EJ JBOD#3 | 16顆 | 15顆RAID6 | 1顆 |
| EJ JBOD#4 | 16顆 | 15顆RAID6 | 1顆 |
| EJ JBOD#5 | 16顆 | 15顆RAID6 | 1顆 |
| EJ JBOD#6 | 16顆 | 15顆RAID6 | 1顆 |
| EJ JBOD#7 | 16顆 | 15顆RAID6 | 1顆 |
| 總計 | 128顆 | 8組RAID6 Group組成 | 8顆 |
| RAID60儲存池 |
在建立磁碟陣列時,建議預留空白硬碟,不將其劃入任何陣列中,根據QES系統架構的機制,這些預留的磁碟將被視為熱備援硬碟,不須額外特別設定。當系統發生硬碟故障事件時,即可觸發全域熱備援的機制,自動抓取任一ES NAS或JBOD上的空白硬碟,主動重建RAID陣列。
NAS硬碟配置:
JBOD#1硬碟配置:
JBOD#7硬碟配置:
圖片從上到下分別是1台ES NAS、7台EJ JBOD擴充櫃的建議設置方式。若第一台ES NAS是以 4顆SSD系統快取碟進行配置,則可由11顆磁碟組成RAID6陣列,並預留1顆熱備援硬碟;倘若系統中並未佈建SSD快取,則可用15顆磁碟來建構RAID6陣列;其餘的擴充櫃都是採15顆磁碟RAID6陣列,並各留1顆熱備援硬碟進行架構配置。
如何增建RAID60
依照上述架構,在建立第一個RAID Group之後,可藉由擴充儲存池(Expand Pool)的方式,擴增更多的RAID Group。由於每個RAID Group彼此是Striped關係,當資料寫入時,將同時寫到這幾個RAID Group,讀取時亦然,如此即可在 QES中建立RAID60的儲存池,兼顧效能與可靠性。
基礎應用與效能數據
依照上述的系統架構,本節將建立一個容量至數百TB的超大儲存池,透過共享資料夾為例,掛載於對應的應用情境。在受測的情境中,模擬基礎應用場景,並實測其效能數據。
測試平台
| 儲存系統 | |
|---|---|
| NAS機種 | 1x QNAP ES1640dc v2 |
| 擴充櫃機種 | 7x QNAP EJ1600 v2 |
| NAS與擴充櫃連接方式 | 4x Mini-SAS 12Gb/s, Dual Loop |
| SSD機種 | 4x Samsung PM863 240GB |
| HDD機種1 | 12x HGST HUH721010AL5200 10TB |
| HDD機種2 | 112x Seagate ST8000NM0075 8TB |
| 磁碟總數 | 4x SSD+124x HDD |
| NAS資料埠網卡 | Intel X520-SR2 SFP+ |
| SFP+連接方式 | 光纖 |
| SFP+ GBIC | Intel FTLX8571D3BCV |
| 系統版本 | QES 1.1.3 |
| 儲存池結構 | 8個RAID6 Group, 共124顆HDD |
在總數10台Windows Server 2012 R2的伺服主機上,掛載同一個共享資料夾,同時執行IO測試,模擬多台伺服主機同時存取,ES NAS所能提供的吞吐能力。
低容量水位的讀寫效能
從下列實測的數據可以清楚觀察到,SSD快取加速對於小區塊隨機讀取的效能有顯著幫助。
單一客戶端測試
| 測試項目 | 負載方式 | 無SSD快取 | 開啟SSD快取 |
|---|---|---|---|
| AJA System Test循序讀取 | HD-1080i, 16GB, 10bit YUV | 603 MB/s | 410 MB/s |
| Iometer 256K循序讀取 | Thread=1, Queue depth=1 | 304.36 MB/s | 236.71 MB/s |
| Iometer 4K隨機讀取 | Thread=1, Queue depth=1 | 48.8 IOPS | 108.29 IOPS |
| Iometer 4K隨機讀取 | Thread=1, Queue depth=16 | 974.5 IOPS | 4434 IOPS |
| AJA System Test循序寫入 | HD-1080i, 16GB, 10bit YUV | 520 MB/s | 500 MB/s |
| Iometer 256K循序寫入 | Thread=1, Queue depth=1 | 233.18 MB/s | 295.78 MB/s |
| Iometer 4K隨機寫入 | Thread=1, Queue depth=1 | 1474 IOPS | 2959.64 IOPS |
| Iometer 4K隨機寫入 | Thread=1, Queue depth=16 | 2281 IOPS | 2801.89 IOPS |
多客戶端同時存取測試
| 測試項目 | 負載方式 | 無SSD快取 | 開啟SSD快取 |
|---|---|---|---|
| AJA System Test循序讀取 | HD-1080i, 16GB, 10bit YUV | N/A註 | N/A註 |
| Iometer 256K循序讀取 | Thread=1, Queue depth=1 | 1017.34 MB/s | 1017.17 MB/s |
| Iometer 4K隨機讀取 | Thread=1, Queue depth=1 | 476.1 IOPS | 7027.98 IOPS |
| Iometer 4K隨機讀取 | Thread=1, Queue depth=16 | 974.76 IOPS | 18821.64 IOPS |
| AJA System Test循序寫入 | HD-1080i, 16GB, 10bit YUV | N/A註 | N/A註 |
| Iometer 256K循序寫入 | Thread=1, Queue depth=1 | 796.38 MB/s | 659.79 MB/s |
| Iometer 4K隨機寫入 | Thread=1, Queue depth=1 | 2628.61 IOPS | 3200.6 IOPS |
| Iometer 4K隨機寫入 | Thread=1, Queue depth=16 | 2602.41 IOPS | 2863.7 IOPS |
註:因AJA System Test不支援多客戶端同時存取的測試,故無數據。
大量檔案寫入測試
為了滿足大量的檔案負載,本節測試採用Disk tools (File Generator)檔案產生工具,調整其所產生的檔案大小、數量、內容(重複或隨機文字),進而模擬大量檔案的寫入的效能測試。
網路連接方式
網路拓樸方面,藉由兩個10Gb的網路埠,分別將ES NAS上的兩個共享資料夾掛載至伺服主機上。
測試負載來源
| 路徑1 (\\33.31.1.102) (Z:\) |
路徑2 (\\33.31.1.102) (Z:\1) |
路徑3 (\\33.32.1.102) (Y:\2) |
||
|---|---|---|---|---|
| 寫入負載1 | 寫入負載3 | 寫入負載5 | 寫入負載7 | 寫入負載9 |
| 單檔大小30MB | 單檔大小40MB | 單檔大小20MB | 單檔大小60MB | 單檔大小50MB |
| 寫入負載2 | 寫入負載4 | 寫入負載6 | 寫入負載8 | 寫入負載10 |
| 單檔大小30MB | 單檔大小50MB | 單檔大小50MB | 單檔大小80MB | 單檔大小100MB |
為了驗證高強度的寫入負載,產生出來的模擬檔案將分別介於20MB至100MB不等,且檔案內容為完全隨機,進而對儲存系統進行長時間的寫入,並驗證結果如下。
寫入測試結果
- 總寫入資料量722TB
- 總寫入時間耗時約713小時
- 平均寫入速度294.75MB/s (每小時約1TB)
- NAS端CPU使用率50~55%
- Host端CPU使用率80~90%
- ZFS檔案系統底層實際寫入頻寬850~1000MB/s,IOPS約9K~11K,平均IO大小為94KB
- ZFS檔案系統底層寫入放大率約3倍
高容量水位的使用效能
經過長時間密集寫入後,總容量與檔案數量都將達一個巨大數量,基於這樣情況下監測儲存系統的讀取效,加以模擬高強度使用下的穩定狀態如下。
讀取效能實測
| 測試項目 | 負載方式 | 結果 |
|---|---|---|
| Iometer 256K循序讀取 | Thread=1, Queue depth=1 | 421.40 MB/s |
| Thread=1, Queue depth=2 | 719.17 MB/s | |
| Thread=1, Queue depth=4 | 751.45 MB/s | |
| Thread=4, Queue depth=4 | 1084.06 MB/s | |
| Iometer 4K隨機讀取 | Thread=1, Queue depth=1 | 2240.47 IOPS |
| Thread=1, Queue depth=4 | 8225.18 IOPS | |
| Thread=4, Queue depth=4 | 14141.09 IOPS |
經實測,在儲存容量近乎飽和的情況下,NAS讀取效能仍然可以維持在一定水準,且循序讀取的效率最高依舊可貼近單線10Gb網路頻寬上限,有效提供長時間穩定的效能輸出。
災難復原與陣列重建
在建構超大容量儲存系統,儲存池需要大量硬碟的支持,而在動輒數十顆,甚至上百顆硬碟同時運作的環境下,如何因應硬碟故障的事件便會是個重要的課題;基於上述章節所提到的,QES透過軟硬體技術,實作多層資料保護關卡,即便發生硬碟故障,依舊可以透過全域熱備援機制,與快速資料重建技術這2道關卡來保證資料運行的可靠性。
磁碟故障處理流程
以上述實驗架構為例,儲存池由8組RAID Group共116顆硬碟組成,並預留8顆硬碟作熱備援用。若在使用空間高達722 TB,容量水位已達99.97%的飽和下,發生硬碟機故障事件,QES系統全域熱備援的機制將立即抓取待命硬碟,利用快速資料重建技術,進行資料重建的工作,盡可能降低災難再度擴大可能性。
陣列重建實測
經過實測,在近乎飽和的儲存池中,若發生單顆8 TB硬碟故障的事件,系統將由另一顆8 TB熱備援硬碟重建資料,下列實驗數據實測數據重建所需的約略時間。
| 儲存池容量水位 | 已使用空間 | 8TB HDD故障重建時間 |
|---|---|---|
| 99.97% | 722.0 TB/722.2 TB | 276H 23M (約11.5天) |
擴充櫃故障處理流程
若遭遇整台擴充櫃故障事件,為了確保既有資料的正確性,QES系統將主動對儲存池進行離線的資料保護機制,待擴展櫃重新上線,並恢復儲存池的狀態時,再繼續提供服務。
結語
QNAP QES系統具備多層資料保護技術、超大單一儲存空間、即時資料壓縮、重複數據刪除等多項特性,對於打造超大容量應用環境,都是相當實用的功能。再搭配多樣化RAID與儲存池組態,可以有效幫助使用者彈性安排其儲存規劃。即便遭遇意外與災難,也能借助快速重建技術,盡可能降低重建過程中,災難再度擴大的可能性。對外有多埠10Gb網路介面,並同時支援iSCSI、NFS、CIFS等通訊協定,對於各種不同應用與場景,有更強的適用性。