IBM存儲重刪壓縮技術之四回歸硬體
IBM存儲重刪壓縮技術之四
題記：上一篇我們簡單分析了A系列的數據縮減技術，雖然重刪壓縮率和性能都不錯，但是整體方案成本太高，在全快閃記憶體大講特講降低TCO的時代，顯得格格不入。IBM的蜿蜒曲折之路又開始了新的篇章。我們再來看看IBM的硬體壓縮實現之道。
IBM的實現之路是比較曲折的，先是用SVC組合，再是用XIV組合，但是一路走來都是不盡人意，總是差那麼一口氣讓人感覺做的是一個臨時版本。
2017年12月，IBM又更新了自己的全快閃記憶體，這次是從硬體上下手，而不是組合新的方案。我們來看看主要做了什麼變化。
IBM FLashsystem900支持壓縮
IBM Flashsystem900 AE3,單看外表和之前幾代沒有任何區別。但是硬體內部還是發生了一些大的改變。
1，持續降成本，將顆粒從MLC換成3D TLC
2，支持硬體壓縮功能
3，碟片大小提升到18TB
4，NVMeof Ready
我們將目光主要放在壓縮處理上。
更換TLC商務更節省
當前業界3D TLC最成熟的當屬三星，已經銷售了2年多，東芝、鎂光一系列落後廠商一直在追趕，國內的紫光估計要到2020左右才能量產，所以三星一直在坐收紅利。
2017年下半年，終於東芝和鎂光的3DTLC開始量產，預計2018年上半年可以大量供貨，IBM跟鎂光合作比較多，估計本次的3D TLC用的鎂光的。
IBM為了擔心跟之前的盤混用，給自己每個3D TLC的盤都編了一個特殊的名字。比如說「T S03 B」
其中T就是為了標識顆粒類型是TLC，S則是大小的意思，03意味著單個顆粒採用3TB的NAND。
壓縮的硬體實現
IBM的快閃記憶體模塊並沒有採用ASIC而是使用FPGA，意味著它可以快速的開發上線，而不至於等待很長時間。
使用FPGA實現了關於顆粒的管理、垃圾回收、FTL等，在最新版本也實現數據的壓縮和解壓。
不同容量大小包含的FPGA不一樣，3.6TB的盤包含一個FPGA和12個NAND，8.6T的盤包含2個FPGA和28個NAND，18TB的盤依然是2個FPGA但是顆粒數量增加到了56個。
由於FPGA數量不一樣，導致性能也有差異，從整個FS900的維度看，不同配置可以發揮性能如下：
可以看出也並不是完全線性，但是總的來說容量大的兩個模塊性能更好。
壓縮的實現就是基於上述的MicrolatencyModules實現的。
1，演算法優化，基於Gzip修改，宣傳效果非常好，最大可達128：1
2，有效容量受制於分配的內存大小（LPT (Logical-to-Physical) DRAM）
3，會做數據監測，如果判斷無法壓縮則不經過壓縮引擎
4，壓縮過程發生在RAID之下，快閃記憶體模塊內存下顆粒之前
5，壓縮永遠運行，沒法關閉，並且AE3版本沒有精簡配置
數據進入壓縮引擎後，會首先進入壓縮模塊，建立一個獨有的哈夫曼樹（其實我也不懂）。然後壓縮完成後還要再解壓一次進行數據比對。
沒有最奇葩，神奇的空間管理策略
三種模塊的壓縮演算法實現完全一致，為什麼壓縮率會有所區別？
IBM將對外可以承諾的客戶可用容量稱之為OutOf Physical Space (OOPS)。當我們用12塊3.6TB的快閃記憶體模塊建立一個FS900系統
1，按照RAID5 10+1（校驗）+1（熱備），可用容量應該為3.61*10=36TB
2，但是在界面和CLI裡面看到的是10.99*10 =109TB
假設這個時候寫入數據，有兩種情況會發生
1，假設數據無法壓縮，那麼會發生「物理容量」消耗，一旦寫入數據超過36TB，則會出現物理容量耗盡的提示
2，假設數據可以壓縮（4：1），那麼就會消耗「有效容量」，當寫入109TB後，有效容量則會被耗盡，這個時候儘管物理容量只用了27.5TB，還有接近8個TB的物理空間，但是這部分空間無法被客戶使用。
註：這個奇葩的設計是在系統中寫死的，無法被改變。
IBM的管理界面上對於超過預設的壓縮率一樣會顯示為實際的縮減率，這真讓人無語，哪怕你是100：1的數據縮減也沒有用啊，用到3：1之後就不會讓你用了。竟然還顯示出來，這個讓人完全無法理解啊。
並且IBM針對數據縮減率低於預設值得場景做了一系列防護手段，進行相關的限制，防止出現物理空間耗盡的問題。
個人認為這個寫死的操作估計會在後續版本刷新。
性能無損的壓縮
AE3開啟壓縮後，性能和AE2比起來絲毫不遜色，確實歸功於硬體盤內的優秀實現，因此國產廠商可以不要整天想著去做ASIC，耗時耗力，完全可以先用FPGA來進行相關的實現來迎接當前的快閃記憶體時代。
不過我沒有看到IBM如何做ECC的，在TLC時代FPGA做ECC可能壓力很大。
FS900不管是管理、運算還是Flash模塊都是採用FPGA，這也是歷史遺留問題，畢竟作FS的人都是當年的TMS的人，同樣的DS8880就是用的ASIC來做快閃記憶體框的RAID。
在ASIC難搞的情況下是否可以考慮用FPGA快速實現硬體加速？
Flashsystem V9000 AE3粉墨上場
內存升級：新的V9000所有的內存都可以被用於業務處理，而不用劃分一部分出來執行壓縮，同時雙控從原來的128GB升級到了256GB
CPU多核處理：釋放所有的CPU資源，不用給壓縮預留
我們來看看最新的Flashsystem性能的情況。採用一台V9000的雙控，掛載兩台fs900 AE3，每台配置8*8.5Tb快閃記憶體模塊。
峰值可達一個非常好的值。
壓縮率為1：1場景
由於採用壓縮實現，可以看出讀寫差異並不大，畢竟V9000的機頭上並沒有做RAID，所以沒有寫放大，所以在8KB場景不管什麼模型，都可以達到350K~400k的性能，這是一個極高的性能，可以和當前業界最高的HDS VSP F1500媲美。
但是由於1：1的壓縮率時候並不會經過壓縮模塊，所以性能出現這麼高也正常。
16kb和8KB類似，有少量下降，但是下降幅度很小，基本上可以保持在300K@1ms的水平。
跳變真正發生在32kB開始，實驗開始分化，主要是由於IO快拆分和合併導致的寫IO性能下降。
總結：在壓縮率1:1場景由於數據不經過壓縮模塊，因此性能非常好。
壓縮率2：1
可以看出在有了壓縮率之後，數據的寫入處理的時延開始影響業務，一旦超過能力值，時延會急劇上升，但是整個性能確實不錯，總體保持在300~350K IOPS@1ms
16KB時候性能也不錯，大概保持在250K@1ms左右。不過問題是為什麼300K~350K之間是一根這樣的曲線確實讓人很難捉摸，我個人理解是軟體對於CPU限流所做的反饋而導致的。
32KB表現完全看不出來區別，可見硬體實現對於IO大小並沒有太大的在意。
混合業務場景
IBM選取了一個大型機場景下的典型交易系統的workload進行驗證。
實際性能曲線也是非常漂亮。
可見在混合業務場景IBM的性能都是可以保持在300K~350k的。
總結：新發布的Flashsystem 900 AE3，已經用到了V9000和A9000裡面，不過在A9000裡面，並沒有刪除軟體的壓縮功能，我理解主要是改動不值當。而V9000的效果則是立竿見影。A9000因為起配規模大，成本高這個問題導致IBM在快閃記憶體市場節節敗退，現在有出一個V9000來，是否能夠挽回頹勢？這個就是仁者見仁智者見智的事了。
TAG:圍爐煮酒論IT |