傳統 Storage 大都是把所有資料放在同一種型態的硬碟
如 SSD, 15K RPM, or 7K RPM
因為這幾種硬碟的單位成本不同 當然效能越高 單位價格就越貴
有時候會為了作效能與成本的有效運用 就會根據不同的資料型態 配置不同的硬碟
例如 熱門的交易資料 就在放置在 SSD 或是 15K RPM
沒有高效能需求的資料 比如說Log, Backup. 就放置在 7K RPM 硬碟
不過近幾年來 總會有人注意到 就算都是熱門的交易之料
也總會有一部分比例的資料 一個月才會需要查詢到一次
比較冷門的資料 有時候就是會在某個時間點冒出尖峰查詢時間
以往以 Volume Base 的切割方式 並沒辦法做更細微的控制
如 資料庫為例 就是很難去把同一個資料庫中 特定資料根據熱門程度分不同效能的硬碟存放
往往就只能全部放在 15K 硬碟 或是乾脆就是全放貴到快被鬼抓走的 SSD
為了維持系統的效能 老闆大概都還是只能乖乖花錢買單
不過這幾年 業界開始有發展不少 可以提高效能 成本 的技術
像是更好的 Cache 演算法, Server side cache..
而 Compellent 算是非常早就開始提出另一種玩法 Data Progression
其實就是我們這次要提的 Data Auto-Tiering.
Compellent Data Progression 搭配之前說明的 Block Level RAID
Block size 可以是 512K, 2M, 4M
就可以達到根據每個 Block 冷熱程度 在不同形態的硬碟中移動
Server 端完全不會察覺目前 Block 在 SSD, 15K, or 7K
完全是 Compellent Controller 底層運作
因為一般來說 一整個 Database 內部大概都只有 20% 是熱門資料
如果只需要採購 20% size 的高速空間 其他 80% 可以配置在低成本空間
這樣整體成本會下降非常多
當然 不同系統 或是不同產業 可能比率也會不同 這得先做過行為分析才知道
Dell 有提供類似的評估軟體 可以先錄下 Server 端的行為
作為評估 不同分層 size 的依據
如下圖 標準配置下 Compellent 會把 SSD, SAS 15K, SAS 7K 分成三種 Disk Group
每個 Block 會根據被存取的狀況 在這三種 Disk Group 中移動
而在這三層 Disk Group 中, Compellent 還會去判斷 Block 要以哪種 RAID 來存放
當然 都是以效能優先
而根據 Compellent 標準
熱門資料 三天後會往上移一層
冷門資料 十四天後會往下降一層
每天會啟動一次 看需要移動的資料量 少則數十分鐘 多則數小時完成
而且還得配上 Storage Snapshot 把 Block 變成 read only 狀態
啟動 Data Progression 搬資料的時候 只會搬已經被 Snapshot read only 的 Block
這些規則目前還是沒法修改 一定會有人吐槽 哪來的那麼死 那麼呆的規則
當然 後面會有不少變化方式來解決這問題
上述配置是完全由 Compellent 內定的配置方式
而 如果對上面的配置方式不滿意
或是手癢 想玩玩看 Compellent Data Progression 可以到何種程度的
可以選擇手動配置
不過咧 你想決定要玩手動配置的時候 需要去 Compellent Controller 作設定
而且是 Storage 整台變成手動配置 改不回來喔
如果擔心的話 可以不用去改這設定
不過我手上的全改拉... 因為自己設定有一定的好處
一旦改成手動配置 第一種玩法可以如下
SSD (R10), SAS15K (R5), SAS7K (R6)
比較不熱門的資料 就配置 SAS 15K, 且 R5 資料保護 且避免 R10 設定導致的空間消耗
冷門資料 就全丟 SAS 7K, 會使用 R6 是因為 SAS7K 一般來說容量都較大
萬一 Disk 毀損 會需要比較久的時間重建, 重建的當下資料保護性會較差 所以選用 R6
之後就讓 Controller 根據資料冷熱門程度來決定放置位置了
一樣的 Block 根據存取頻率在不同 disk 之間移動
當然 並不是所有 Volume 需要到 SSD
這時候就可以根據需求 設定特定 Volume 可使用的 Disk Group 及 Raid Type
Volume 1 需要比較好效能 所以 SSD, SAS15K, SAS7K 都可用
而且 SSD 還是 R10, 提供最好的效能
Volume 2 不需要那麼好的效能 所以設定只能使用 SAS15K, SAS7K
這樣就不會佔用到 SSD 的空間
當然還有另一種進階玩法 如下圖
搭配上 Storage Snapshot 機制 當資料寫入的時候 一律往 SSD R10 丟
而 Compellent 在跑 Daily Data Progression 的時候 因為只搬 Snapshot Read Only Block
這些 Block 會被立刻往下一層 SAS15K 搬 此時 SSD 又會有空間繼續承接資料寫入
而 熱門資料除了是剛被寫入 SSD 的部分 就屬被下轉到 SAS15K的部分了
這好處就是 SAS 15K 專心供應熱門讀取需求 不會因為同時要應付寫入需求而降低讀取效能
當然 冷門資料還是會在十四天之後降至 SAS7K
而這兩年 SSD 也開始有多種型態出現 價格也下降到一個程度
所以 Compellent 也提供另一種玩法 SSD 也開始分型態分層
SSD 分為三種 SLC, MLC, TLC
當然 一分錢一分貨 三種SSD 單位成本與效能 SLC > MLC > TLC
所以 Compellent all flush 玩法就變成如下
基本上 依照 Compellent 的資料 三種 SSD 讀取效能都差不多
差別在於寫入效能 SLC 最快, TLC 最慢 不過還是比 SAS15K 快
尤其是兩年前 Compellent TLC SSD 出現之後 因為單位成本跟 SAS 15K差不多
再加上單位密度比 SAS15K高很多 同樣2.5吋 有4.8TB 版本
所以近年來非 all flush 的三層配置方式變成如下
這是目前看來C/P最高的配置方式
有 SLC的寫入效能, TLC 的讀取效能 成本也不至於太高
再加上 SAS 7K 每顆HDD 動輒 4T, 6T 的低成本高密度優勢
說到這邊 為啥不能同時 SLC, MLC, TLC, SAS7K 一起用耶
因為 Compellent 最多一個Group 支援三層
再來就是每層的配置比例是多少?
一般就是先找Dell 幫忙跑過分析軟體 DPACK
此時會知道所有系統IO, 資料寫入讀出的狀況 以此判斷各層的配置比例
不過照經驗大概是實際可用空間 1:2:7 的配置比例
那 下篇來廢話這幾年Compellent Admin的抱怨..
No comments:
Post a Comment