測試 NetApp 2240

公司內使用的 NetApp 已經過了保固,同時容量也因為東挪西挪的所剩不多,所以計畫在今年度把他替換掉,所以在去年就跟廠商要求要拿一台來做一下測試,以免實際情況與估算的有落差。

跟公司四、五年前的介面有蠻大的差異,雖同樣有這些功能,但UI介面感覺比較”大眾”一點,也需要先安裝個 NetApp OnCommand System Manager 3 的Clinet端程式,方便可以管理多台主機,但很不幸的這個 System Manager 是無法相容公司的舊主機,只管理一台的情況下有點多餘。

登入介面如下,同樣的名詞並沒有隨著版本異動而更新,如果有玩過 NetApp 產品應該很快的可以上手,廠商借測的機器有插12個 Sas 硬碟,每顆都是 900G 的容量,偷拔下來觀察都是使用 Toshiba 的產品。

image001

扣掉2顆硬碟做 Parity Check 及 1 顆 Spare 硬碟,實際可用空間約 6.62TB,反推約只有 61.3% 的實際容量,為了提高系統可用率,最多可以損壞3顆硬碟。

image002

此次測試會隨著測試內容在 volume 的大小會隨時調整,目前廠商是切系統區有200G的空間,約使用到 11.76G (其實不是很了解為啥要系統區要切那麼大,測試這幾天也沒有看他有大幅度成長),其他的就自己亂切。

另外有一個可以玩的是 Storage Efficiency 的設定,這個可以打開 deduplication 及 Compression 兩個選項,可以大幅降低檔案分享的容量。

image003

顯示 Volume 底下也有四個頁籤可以快速檢查容量相關

image004

在 volume 選擇 edit 可以去變更 Volume 的設定,Security Style 可以設定是 NTFS / Unix / Mixed 幾種模式

image005

選擇 Storage Efficiency 可以去調整讓整個儲存更有效率,不過這個會相當吃系統資源,尤其是把兩者 (deduplication 及 Compression ) 都打開,並設定儲存時運算,這樣在大量複製時會把整個 CPU 吃滿,同時會影響到儲存效率,建議先把資料寫入後,等周末系統有空或晚上在排程去運算吧。

image006

最後一個 Advanced 選項是可以選擇這個 volume 是不是可以自己長大,當然你的 aggregation 要有空間,及底下的幾個選項

image007

設定SnapShot 則是更直覺式的選擇要做 snapshot 的時間,

image008

變更 Volume 大小,單純的輸入變更後數字,跟先前一樣

image009

變更時也可以同時刪除掉一些不 Snapshot 節省空間

image010

最後還是顯示個 Summary 畫面確認,本次範例是由 4.5TB 縮小到 4TB,同時刪除掉 7 個 Snanshots

image011

完成後系統也會顯示處理結果,可能要花上 30秒的時間

image012

設定分享

Volume 建立完畢後,就可以設定把這個空間要如何分享出去,公司內只會要到 NFS (給VMware)用,或是 CIFS (給檔案分享用)

image013

在CIFS設定上並沒有太奇特的地方

image014

但在作NFS分享時 (Exports 功能)就有蠻大的差異喔,為求測試期間的順暢,我做的分享都是檔案權限全開,實際上線就要考量一下喔。

image015

在先前的測試直接把公司檔案的備份資料倒進去,打開 Storage Efficiency 功能,可以發現重複檔案有 35%,壓縮效率有22%,合計可節省 45%的空間,由 1.6xTB 降至 1.1TB

image016

再測試另一個檔案分享路徑,其中有一大部分是儲存影片/照片,只能省下來 110.6G 佔 26%, 壓縮比不大只有3%,但仍有 24% 的檔案是屬於重複

image017

在測試 NFS 效率時,跟舊的 FA2020 SAS 的配置做個比較,首先把我們公司資料庫測試主機分別複製(clone)到兩台 NetApp 上,分別在兩台 VMWare ESXi 主機同時執行資料庫回復的指令 (rman Restore),不過此時 FA2020 仍提供其他服務,出來的數據會比較不利一點。

由於 Restore 吃I/O 會比吃 CPU 更重,其間過程中也只有吃到30% 上下的程度,我覺得可以排除CPU 不同所產生的差異(都是屬於 Xeon 規格),實際測試約在13:10開始執行回復,完成時間約在 15:28,兩台主機約差異17分鐘

image018

雖然這個FA2240的功能比 FA2020 功能並沒有大幅度改變(或許說是我們還沒有用到),效能進步也是只有一點點(可能在插入更多硬碟,甚至加入 SSD做 Cache 會有更大幅度的改善),在節省儲存空間上功能及介面上就進步許多。

全速複製中的畫面,其中Compression 及 deduplication 是放到周末比對執行

image019

另外一個複製檔案分享可省下 40% 的儲存空間

image020

測試後期,我們再跟廠商借了三個 SSD 硬碟來改善存取速度,我猜單純作檔案存取也必須要靠機率,所以我再把oracle Restore 作業再拿來測試一下

可以看到底下的統計,於資料庫Rman restore 時約有 50%的機會是由Cache 中取得,寫入幫助就不大

image021

磁碟 I/O效率都保持在 30MB/Sec 以上,短期內會衝到50MB/Sec,備份時間也重早上8:18執行到 10:04,約一小時56分完成, 比對前次還原約兩小時,其實進步時間不大,以價格來看有點不划算。

image022

在作 Compression 及 deduplication 時,有 SDD 作用看起來不大,不過這個也符合邏輯啦.

image023

在〈測試 NetApp 2240〉中有 2 則留言

  1. 你好,我是某小工程師,想修正一下您測試的部份
    基本上2240在DataONTAP 8.1.3 7-mode裡,root volume是可以縮到162G的
    你測試SSD的方式可能可以再修改一下
    SSD也是同樣有raid,預設同樣是raid-DP,所以借了三顆空間是只有一顆在進行r/w cache
    低銷2顆SSD後,只有一顆來做cache會有點可惜
    另外你可以嘗試測試FAS8020 cluster-mode,這台比較適合拿來跑Oracle

    1. Ethan,

      感謝您的修正喔,目前我手邊已經把 2240 還回去給廠商,不過我們改採購 2552, 應該也是可以把 sysvol 縮成162G 吧.. 另外SSD的設備也是跟廠商借的,也只給最低的配置,他設定好之後我就直接測試,沒有再進行後續的更改,是很可惜沒有讓他發揮最佳的效能。

      我們也是小公司,只有預算買最低階的產品,FAS8 系列就只能看看圖片而已,廠商可能也不會借給我玩..^__^

      最後也感謝您的糾正喔。

發表迴響

%d 位部落客按了讚: