公司內使用的 NetApp 已經過了保固,同時容量也因為東挪西挪的所剩不多,所以計畫在今年度把他替換掉,所以在去年就跟廠商要求要拿一台來做一下測試,以免實際情況與估算的有落差。
跟公司四、五年前的介面有蠻大的差異,雖同樣有這些功能,但UI介面感覺比較”大眾”一點,也需要先安裝個 NetApp OnCommand System Manager 3 的Clinet端程式,方便可以管理多台主機,但很不幸的這個 System Manager 是無法相容公司的舊主機,只管理一台的情況下有點多餘。
登入介面如下,同樣的名詞並沒有隨著版本異動而更新,如果有玩過 NetApp 產品應該很快的可以上手,廠商借測的機器有插12個 Sas 硬碟,每顆都是 900G 的容量,偷拔下來觀察都是使用 Toshiba 的產品。
扣掉2顆硬碟做 Parity Check 及 1 顆 Spare 硬碟,實際可用空間約 6.62TB,反推約只有 61.3% 的實際容量,為了提高系統可用率,最多可以損壞3顆硬碟。
此次測試會隨著測試內容在 volume 的大小會隨時調整,目前廠商是切系統區有200G的空間,約使用到 11.76G (其實不是很了解為啥要系統區要切那麼大,測試這幾天也沒有看他有大幅度成長),其他的就自己亂切。
另外有一個可以玩的是 Storage Efficiency 的設定,這個可以打開 deduplication 及 Compression 兩個選項,可以大幅降低檔案分享的容量。
顯示 Volume 底下也有四個頁籤可以快速檢查容量相關
在 volume 選擇 edit 可以去變更 Volume 的設定,Security Style 可以設定是 NTFS / Unix / Mixed 幾種模式
選擇 Storage Efficiency 可以去調整讓整個儲存更有效率,不過這個會相當吃系統資源,尤其是把兩者 (deduplication 及 Compression ) 都打開,並設定儲存時運算,這樣在大量複製時會把整個 CPU 吃滿,同時會影響到儲存效率,建議先把資料寫入後,等周末系統有空或晚上在排程去運算吧。
最後一個 Advanced 選項是可以選擇這個 volume 是不是可以自己長大,當然你的 aggregation 要有空間,及底下的幾個選項
設定SnapShot 則是更直覺式的選擇要做 snapshot 的時間,
變更 Volume 大小,單純的輸入變更後數字,跟先前一樣
變更時也可以同時刪除掉一些不 Snapshot 節省空間
最後還是顯示個 Summary 畫面確認,本次範例是由 4.5TB 縮小到 4TB,同時刪除掉 7 個 Snanshots
完成後系統也會顯示處理結果,可能要花上 30秒的時間
設定分享
Volume 建立完畢後,就可以設定把這個空間要如何分享出去,公司內只會要到 NFS (給VMware)用,或是 CIFS (給檔案分享用)
在CIFS設定上並沒有太奇特的地方
但在作NFS分享時 (Exports 功能)就有蠻大的差異喔,為求測試期間的順暢,我做的分享都是檔案權限全開,實際上線就要考量一下喔。
在先前的測試直接把公司檔案的備份資料倒進去,打開 Storage Efficiency 功能,可以發現重複檔案有 35%,壓縮效率有22%,合計可節省 45%的空間,由 1.6xTB 降至 1.1TB
再測試另一個檔案分享路徑,其中有一大部分是儲存影片/照片,只能省下來 110.6G 佔 26%, 壓縮比不大只有3%,但仍有 24% 的檔案是屬於重複
在測試 NFS 效率時,跟舊的 FA2020 SAS 的配置做個比較,首先把我們公司資料庫測試主機分別複製(clone)到兩台 NetApp 上,分別在兩台 VMWare ESXi 主機同時執行資料庫回復的指令 (rman Restore),不過此時 FA2020 仍提供其他服務,出來的數據會比較不利一點。
由於 Restore 吃I/O 會比吃 CPU 更重,其間過程中也只有吃到30% 上下的程度,我覺得可以排除CPU 不同所產生的差異(都是屬於 Xeon 規格),實際測試約在13:10開始執行回復,完成時間約在 15:28,兩台主機約差異17分鐘
雖然這個FA2240的功能比 FA2020 功能並沒有大幅度改變(或許說是我們還沒有用到),效能進步也是只有一點點(可能在插入更多硬碟,甚至加入 SSD做 Cache 會有更大幅度的改善),在節省儲存空間上功能及介面上就進步許多。
全速複製中的畫面,其中Compression 及 deduplication 是放到周末比對執行
另外一個複製檔案分享可省下 40% 的儲存空間
測試後期,我們再跟廠商借了三個 SSD 硬碟來改善存取速度,我猜單純作檔案存取也必須要靠機率,所以我再把oracle Restore 作業再拿來測試一下
可以看到底下的統計,於資料庫Rman restore 時約有 50%的機會是由Cache 中取得,寫入幫助就不大
磁碟 I/O效率都保持在 30MB/Sec 以上,短期內會衝到50MB/Sec,備份時間也重早上8:18執行到 10:04,約一小時56分完成, 比對前次還原約兩小時,其實進步時間不大,以價格來看有點不划算。
在作 Compression 及 deduplication 時,有 SDD 作用看起來不大,不過這個也符合邏輯啦.
你好,我是某小工程師,想修正一下您測試的部份
基本上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
Ethan,
感謝您的修正喔,目前我手邊已經把 2240 還回去給廠商,不過我們改採購 2552, 應該也是可以把 sysvol 縮成162G 吧.. 另外SSD的設備也是跟廠商借的,也只給最低的配置,他設定好之後我就直接測試,沒有再進行後續的更改,是很可惜沒有讓他發揮最佳的效能。
我們也是小公司,只有預算買最低階的產品,FAS8 系列就只能看看圖片而已,廠商可能也不會借給我玩..^__^
最後也感謝您的糾正喔。