如果三個data stream還不夠多的話，那是什么加速了data stream的增加?一個最直接的答案就是：more CPU power + Virtualization -> increased VM density -> more pressure on storage -> I/O Blender

我來解釋一下上面的這段話。CPU原本是通過增加晶體管和時鐘頻率來提升性能的，但近年來的一個轉(zhuǎn)變是【multi-core + multithreading】，這本身就助長了I/O Randomization。考慮這樣一個服務(wù)器配置【dual socket, 6 cores/socket, 2 threads/core】 -> 2*6*2 = 24 unique data streams。如此強悍的服務(wù)器只承載單個App是否過于浪費了(Map-Reduce style data-intensive workload除外)?所以越來越的企業(yè)采用Server Virtualization來host multi-VM，這再一次加劇了I/O Randomization。如果多臺這樣的物理服務(wù)器連接同一臺存儲，來自成百上千的混合流量立刻會使得存儲的workload變得completely random，這就是所謂的I/O Blender。

再簡單一點，Massive Consolidation + Intensive Randomization -> I/O Blender。下圖是我們目前服務(wù)器使用存儲的常見情況，雖然服務(wù)器依舊只有三臺，但對于存儲來說，已不僅僅是三個workload，而是一堆。

所以I/O Blender給盡可能順序化I/O的設(shè)計初衷帶來了挑戰(zhàn)，但人類總喜歡master complexity，所以會繼續(xù)面對挑戰(zhàn)，目前的對策有如下這些：

增加存儲緩存容量：支持TB級別的緩存對于企業(yè)級存儲來講已經(jīng)不稀奇了，更大的Cache加大了聚合分散隨機I/O的可能性。缺點也顯而易見，cache memory貴啊，而且read performance依然是個問題，random reads導(dǎo)致cache miss，從而不得不訪問后端磁盤。

把流量分散到更多的磁盤：如果workload越來越隨機化，那么我們就需要更多的盤來增加IOPS。缺點也很多，cost + space + power consumption + inefficient capacity UT，而且東西多了，規(guī)劃自然也就更復(fù)雜。

添加flash tier or flash cache：添加SSD的確加速了性能，不過本質(zhì)問題依舊，設(shè)計不匹配，SSD一不小心就會overload整個存儲，適得其反。值得注意的是，用于cache之后，flash將經(jīng)常遭遇write cycle(promotion <->write back)，所以需要耐久度(endurance)更高的SLC閃存。另外，caching和tiering的效率取決于App，即便只有10%的I/O go to backend disk，App的serialization transaction通常都會受到響應(yīng)時間的限制。所以要維持一個始終可預(yù)測的高性能對于caching/tiering這種方案來說并不總是可行的。

不錯，你可以通過這些方案來應(yīng)對I/O Blender，但CPU性能的增長勢頭也預(yù)示著海嘯般的流量沖垮caching/tiering是遲早的事情，大量的活躍數(shù)據(jù)要求more memory + more flash as cache，要知道這種無限增長是不可能的。再者，即便前邊的caching/tiering防線守住了，為機械硬盤所設(shè)計的控制器可能根本擋不住這么大的流量，這也是為什么我們在VNX/CLARiiON上會考慮如何不讓FAST Cache沖垮CPU和backend bus的問題了(雖然VNX SAS的24Gbps后端抵抗力要強很多)。

其實很多問題都是相同的，一種架構(gòu)不可能服務(wù)到永遠，master complexity也只會導(dǎo)致更為復(fù)雜的系統(tǒng)，帶來新的問題。解決方案只有一個，推到重來。最近SDN的概念其實如出一轍，Internet架構(gòu)是幾十年前的設(shè)計了，之所以還能建在是因為人類的偉大，無數(shù)牛人絞盡腦汁來master complexity，是時候back to simplicity了。

huanghui