這次要廢話的主題回到 Compellent 吧
前面介紹了 Compellent 與其他廠牌 Storage 最大不同
在於他是業界最早導入 Auto-Tiering 機制的 Storage.
而且 Tiering block 細度可以到 4MB, 2MB, 512KB
目前似乎還沒有其他家廠商有做到這個
(不過後來好像也慢慢不是很重要了, 畢竟現在 Storage 廠商也被打得亂七八糟就是了)
這邊就來廢話一下 當要規劃 Compellent Storage with Auto-Tiering 的時候的注意事項
如果是以前傳統 Storage, 很簡單 User 要多少空間 要多少 IOPS
就換算成要多少 Disk, 哪種形態的 Disk, 直接買齊給他就好 (當然 User 出$$的話)
不過當你要把 User 系統放在 Enable Auto-Tiering 的 Compellent 上面的話呢.
建議就要再細部一點 例如
1. 預計 User 每天寫入資料量
2. 預計 User 資料熱門程度
3. 短 中 長期 資料熱門程度以及趨勢分析
4. 中 長期各型態 Disk 空間利用 及 負荷狀況
5. 短期 長期 不同資料型態的升降級
第一項 如果是現有系統的話就很好估算
跑個一段時間的 Dell DPACK 就可以估算到每天的資料寫入量加個 buffer 50% ~ 200% 不等 (看老闆要給你多少$$) 就可以當成你的 Tier 1 空間
但如果是新系統的話就會比較麻煩
問 User 大概也都會估很鬆 (畫大餅) 出錢的老闆也都知道 這些大餅都是畫的
管 Storage 的 大概就是想辦法取中間值
一般來說 Tier 1 大概是 User 預估資料成長量的 10% ~ 20% 不等
第二項 關於資料的熱門程度
如果你的 Compellent Auto-Tiering 打算分成三層式架構這項估出來的結果就是 Tier 2 所需的空間及 Disk 型態
不過比較麻煩的是 這部分資料就算是 Dell DPACK 都跑不出來
因為 DPACK 不會知道哪些資料是熱門資料
跟 User 談的話 一般絕對都會想把他們的資料全部放在 Tier 2.
同樣的 Storage Admin 要是膽敢拿 User 提的需求直接去跟老闆要錢 不被殺頭才怪
當然 如果那部分都是 User 自己出錢 當然 Happy Happy 囉
所以無論新舊系統 大概估算都是整體資料量的 20~40%
要是跟老闆提案的時候 當然一定會被要求 先從 20% 開始吧 吧 吧 吧 (回音~~~~)
不過依照經驗 老闆出過一次$$之後 幾乎不可能要求老闆在針對同一件事情花第二次$$
所以 能爭取多少就多少吧
不然哪天就是 Tier 2 空間使用爆炸 User 抱怨效能有些問題
Storage Admin 得想辦法跟老闆多要一點 co co 解決 User 效能問題
第三項 短 中 長期 資料熱門程度與趨勢分析
這又更虛無飄渺了~~如果是 User 系統已經是一套很穩定的生產系統
這樣的話每天寫入資料量 熱門資料量 應該就是很穩定了
但是很不幸的 在現實面就算是很穩定運作的系統
也可能因為因為一次事件 辦個活動 User Import 資料而改變平衡
例如說 某個 User 明明每天正常寫入量就是 100G, 可是因為 User 一次系統改版
Database 要來改個 Schema, 當天給你來個寫入 2T
更有可能的是 User 要做這件事情也不會事先跟 Storage Admin "告知"
等到 User 發現效能下降的時候才緊急”找“你求救 (幹樵)
你除了發現 Tier 1 空間爆炸 開始把資料直接寫入 Tier 2.
更慘的是 Tier 3 都要開始來幫忙承接資料
你大概也只能頭殼抱著讓他燒吧
該怎麼避免這狀況發生呢
平常多多跟 User "教育" 他們所在的 Storage 需要多一點照顧
平常都處於某種平衡 如果有需要做任何事情 請"記得"找 Storage Admin 先問過
假設 有 User 問說 既然 Compellent 做事情那麼多限制 那為啥還用它咧...
因為很便宜 很便宜 非常便宜啊~~~~~ (很重要 要說三次.)
Auto Tiering 可以讓冷門熱門資料分布在該在的 Disk 上
不用全部採購高規格 SAS15K 甚至 SSD. 就可以提供一樣該有的效能
照顧得好 可以用低很多的成本做到傳統 Storage 做到的事情與效能
另外就是 Storage Admin 可以定期出各個 Tier 空間 負荷趨勢
這樣可以先讓老闆有個心理準備 是否該增加投資了
就算沒有決定增加投資 也可有個準備 是否該 review 該降到全 Tier 3的系統
或是乾脆該下線的系統
第四項 中 長期各型態 Disk 空間利用 及 負荷狀況
一般來說 當 Compellent 規劃出三層架構 大概都會是 WISSD(SLC), SAS 15K, SAS 7K不過近來因為 RISSD(TLC) 價格越降越多 單位成本已經跟 SAS15K 相同
也開始有以 WISSD(SLC), RISSD (TLC), SAS 7K 為規劃方式
也就是像下圖的規劃方式
Tier 1 Disk 為 SLC SSD, 專門承接寫入的資料
Tier 2 Disk 為 TLC SSD, 專門負擔熱門資料的讀取 以及 SLC 降下來的資料
Tier 3 Disk 為 SAS 7K, 就是空間大 單位成本低 用來負擔比較少需要讀取的資料
上述圖表 依照"完美比例" 各Tier 3%, 26%, 71% 配置
我們只要買全部空間 3%的 SLC SSD, 跟 26%的 TLC SSD 就可提供該有的 Service Level
老闆看到他的 coco 被這樣省著花用不知道會不會來摸摸頭..
觀察重點 最簡單的部分就是各層空間 尤其是 Tier 1 SLC, Tier 2 TLC 最好不要塞好塞滿
因為 SLC 滿了 會開始有 TLC 開始承接原本 SLC 該支援的資料
更慘的是 TLC 也滿了 連 7K disk 都得一起進來支援
這時候就是開始 頭殼抱著燒拉~~~~
最好的方式 就是長期觀察各層 尤其是 Tier 1, 2 的資料成長狀況
將趨勢抓下來 好作為跟老闆提案要求投資的依據
不然也可以開始準備趕人 給 User 各系統也來個劃分階級制度
跟 User 協調 比較不需要高效能空間的系統 可以慢慢限制在只能用下層空間
另外就是傳統 Storage 比較不會去注意到的部分
Compellent 除了各Tier 空間使用率被當成一種資源
Disk IO 也是需要特別去注意
依據之前跟 Compellent Consultant 口頭敘述 數字可能有些誤差 完全憑記憶
各種不同型態Disk 建議可乘載的 IOPS 最大值如下
SLC Read 2000, Write 2000
MLC Read 2000, Write 1000
TLC Read 2000, Write 200
SAS15K Read 200, Write 200
SAS7K Read 80, Write 80
當然 這些 Disk 一定可以乘載更高的數字 但是 Consultant 說明
這數字是在開始出現比較嚴重的 latency 之前的建議上限
當Disk 開始要求提供超過建議上限的 IOPS 時
Disk 就會開始出現較高的 Latency 了
而有了這資料 就是要進去 Compellent 看每個 Disk IO狀況是否有超過上述建議值
當然不是要你一顆一顆去看 通常同一個 Group, 同一個 Type Disk Loading 都會很接近
每個 Disk Group 每一種 Type 挑幾顆看就好
如果超過上述建議 IOPS, 就算該 Tier 還沒滿 也是有可能的
就開始上面的做法吧 請老闆投資 或是開始敢人了
第五項 短期 長期 不同資料型態的升降級
會有這狀況 通常就是上面兩種資源 要馬 Tier 1/2 空間快滿了 要嘛 Disk IOPS超過建議值了此時老闆要是覺得增加投資來維持原來的 Service Level 不是很有效益
這時候通常就是 Storage Admin 要開始跟 User 談 系統要分階級拉
不大重要的系統 就給我往貧民區 Tier 3 Disk 趕
比較重要的賺錢系統 繼續住在 Tier 1,2,3 VIP套房
這些動作 User 完全不需要針對系統做任何更動 完全由 Storage Admin來處理即可
不過問題通常不是技術面上的問題
你說我的系統要住貧民區 我就答應讓你搬啊
另外一種狀況
有些系統可能一季也才跑那一次 平常閒閒沒事幹 都在睡覺
可是當他要跑的時候 必須要有非常高的效能
這時候 User 跟 Storage Admin 就可以協調 Tiering 的更動
當平常時間 就降到 Tier 3 讓他好好睡覺
當需要開跑前幾天 Storage Admin 就將 Data 先昇到 Tier 1, 2
之後改成 Tier 1,2,3 全Tier
這樣的話一樣可以達成省成本 又符合系統需求的經濟效益
結論
廢話那麼多 總結就是因為 Compellent Auto-Tiering 的關係
投資 Storage 成本效益上 會比一般傳統 Storage 高上許多
老闆永遠希望 可以用最少成本 達到一樣的目的
不過也因為這特性 要多花一點時間照顧 也最好及早知道 Auto-Tiering 限制或是極限所在
所以... 老闆 我可以把 SAS15K 都換成 SSD TLC 嗎... :p
我想讓 User 通通升級總統套房拉~~~~
No comments:
Post a Comment