雙峰io分布成為确切了解陣列性能水準的理想途徑。
我們采訪了dimitris krekoukiasnimbe storage公司全球技術與政策架構師，旨在共同探讨存儲陣列性能方面的議題——他對此有着一些強烈的個人觀點，特别是關于pure storage的性能實作方案。
pure 公司對于krekoukias的觀點給出了響應，這部分内容亦被添加到本次采訪當中。雙方的思路都認為，單純的io水準并不足以适應全部性能特性需求。
dimitris krekoukias: 存儲性能（或者其它任意性能名額）被市場宣傳所過分誇大了。有時候營銷人員會對其過分誇張地加以宣傳，并将現實與數學計算相扭曲，進而讓結論更加可信。
案例分析：pure storage公司給出的并非其32 kb資料塊下的平均存儲i/o，而是表示其陣列能夠在32 kb i/o大小下提供高性能表現。
記者：您能不能具體加以解釋？
dimitris krekoukias: 平均數值其實是一種最為基本的平均性能誤導方式：一台超級跑車的平均時速為60英裡。這裡表達的雖然是實際情況，也就是表達了超級跑車的平均駕駛性能（因為需要将城市、高速與鄉村路段進行綜合），但其在解釋該車輛在不同實際條件下的性能表現時卻缺少真正的指導意義。
再舉另一個與汽車相關的例子：pure公司宣稱某汽車品牌系列專門為四英尺高、100磅重的乘坐者所設計——這是因為兩名成年人與兩到三名兒童的正常家庭恰好能夠給出這樣的平均數值。然而，這樣的車輛顯然毫無用處——因為我們實際需要的是一輛适合五英尺八英寸、180磅重成年人以及四英尺高、45磅重兒童的車型。
記者：那麼nimble公司是否更了解存儲io這一特性？
dimitris krekoukias: nimble storage公司利用infosight進行全面的分析工作，這款工具負責收集更多存儲陣列相關資訊，旨在建立起一套極端精确的真實世界陣列使用方式視圖。每天一天，都有跨越成千上萬台陣列的數萬億個資料點由一套龐大的大資料後端進行處理與分析。
這些資料點當中包含有充足的資訊，不僅能夠預測并預防各類問題，同時也可以指明其它一些重要趨勢——例如不同應用在實際運作當中對i/o的确切需求。
數量龐大的操作隻需要使用小規模i/o。小規模i/o在處理延遲敏感型工作負載時更具效率。應用程式大多數以不足16 kb的水準使用i/o塊，而且絕大部分集中在4到8 kb區間。這類i/o通常更具延遲敏感性且随機度很高。縱觀全部客戶與應用，大部分操作（全部讀取操作中的52%，全部寫入操作中的74%）都屬于小規模i/o範疇。
大規模資料則傾向于以大型i/o進行傳輸（大于64 kb）。大型i/o在處理高通量資料傳輸時效率更高。事實上，大部分此類資料（全部資料讀取操作中的84%，全部資料寫入操作中的72%）采用大于64 kb的i/o塊大小。此類i/o更具連續性，且對于延遲并不敏感。
其中的一大執行個體在于sql server。其存在着明顯的雙峰i/o密度特性——大部分i/o處于8 k或者大于64 k區間，其中相當一部分在高強度事務、延遲敏感型oltp環境中被轉化為小型i/o，而大型i/o則出現在olap類環境内。
由于資料分布呈現出雙峰特性（即使是在同一應用當中），是以其極限值可能出現在兩個極端方向，這意味着利用單一平均值來定義i/o大小并無意義。實際上，i/o明顯并不能依靠平均數來表達。
記者：這會對陣列基準測試帶來怎樣的影響？
dimitris krekoukias: 由于我們現在更多使用統計資料，同時了解不同方向及類型應用當中的i/o數量、類型與大小，是以我們能夠更為精确地對存儲方案進行基準測試。很明顯，基準測試應當遵循真實應用場景下的雙峰特性：
較小的随機塊會帶來較高寫入占比。一台出色的陣列應當有能力以極低且穩定的延遲完成大量寫入操作。
大型連續塊（其中讀取操作數量略高于寫入操作）。一台出色的陣列需要具備高通量水準。
記者：您是否在實際 poc當中使用了這一方案？
dimitris krekoukias: 是的。pure公司公開宣稱其//m70陣列擁有32 k資料塊條件下30萬iops性能水準。最近，一家客戶對nimble af7000（并非nimble旗下最快的機型）
pure //m70（截至2016年8月pure公司釋出的最高端機型）進行了性能比較。
其中一項測試是以讀取與寫入操作五五開的方式執行，資料塊則為較小的4 kb大小。pure陣列的陣列隻能實作相當于其宣傳水準一半的iops數字。nimble陣列在這方面勝出了，但這并不是重點所在。
其中的重點在于，pure公司并沒能真正踐行其公布的性能水準，而事實上全閃存陣列的存在意義正是為了彌補性能需求制品，且為事務i/o提供具備可行性的i/o大小。是以pure方面公布的32 kb iops數字（我們認為其應該全部為讀取iops）在真實世界的應用環境内并無意義。
記者：那麼您希望通過這個故事表達的是……
dimitris krekoukias: 一台裝置當中包含閃存，并不代表着其就一定能為客戶提供必要的性能提升。是以，大家至少應該同時向供應商詢問相關産品在小型随機塊與大型連續i/o層面的性能數字，其中亦包括高強度寫入操作情況。另外，也别忘了詢問小型塊性能場景下的延遲水準。
pure storage與32 kb io問題
pure公司的一位發言人對krekoukias提出的觀點進行了詳盡回應，并表示pure公司“100%贊同，目前存儲行業确實存在出于市場營銷目标而利用特定塊大小過度宣傳存儲性能的情況。”
這些固定塊大小并不能真正代表一台陣列在運作工作負載時的實際性能水準。正因為如此，pure公司才在過去兩年中一直緻力于由釋出4 k iops數字轉向釋出32 k iops數字，這是因為我們認為後者更能代表真實世界中的工作負載情況（詳見下文）。也正是出于這一理由，我們始終鼓勵客戶利用自己的真實工作負載副本進行測試，進而評估各類存儲系統。
“nimble公司似乎認為pure方面将32 k io視為全球通用型或者說平均資料塊大小。如果大家查閱我們的博文，就會發現具體情況取決于您希望單純了解io大小還是實際資料傳輸（即大小權重型io）。博文中對我們決定選擇32 k而非4 k或者8 k的理由作出了明确闡述; 然而，這還隻是與客戶們就塊大小進行探讨的一個起點。”
“flasharray中并不存在32 kb io大小假設或者優化。與大多數傾向于針對特定塊中繼資料架構（例如4 k、8 k、16 k乃至32 k等等）工作負載進行優化的供應商，我們從開始設計時起就一直堅持使用可變塊大小，是以能夠在全部陣列當中實作可變io大小（特别是在混合型/虛拟化工作負載當中）。”
“pure storage flasharray的突出優勢在于，其始終能夠很好地處理混合型io大小，且無需進行調整或者監控，進而保持穩定的性能水準與最大化資料量削減。我們在架構中并沒有設定任何基礎塊大小。換句話來說，我們不會像經典存儲系統那樣在進行中等大小io時發生拆分以及資源浪費的情況。旁注：舉例來說，nimble的資料削減機制需要在每個分卷基礎之上進行設定/調整，進而操作固定的塊大小……在我們看來，這并不是對當下雲/混合型工作負載的正确架構處理思路。”
“那麼我們既然沒有在架構設計中針對特定io大小進行優化，又為什麼要以32 k為機關釋出iops規格？在全閃存陣列發展早期，市場仍然遵循以固定塊大小進行儲存設備基準測試的習慣。事實上，大多數标準化基準測試都會着眼于特定塊大小。由于我們必須選擇其中一種大小，是以我們選擇了更能代表工作負載在陣列中合并後實際情況的塊大小。”
“旁注：有趣的是，我們發現nimble公司并沒有在其公布的性能規格當中透露任何iops塊大小。”
“當然，我們發現其陣列中的io大小權重平均值恰好接近32 k。正如我們的資料科學團隊最近釋出的博文所言，這一陣列權重平均io在考慮進行各類工作負載合并之後基本就是在32 k左右。”
“從宏觀層面來看，當大家考慮各類存儲系統中的實際工作負載情況時，16 k或者更低塊大小在iops方面更具優勢，而64 k以上塊大小的傳輸通量則更為出色。通過我們的部落格，大家會看到資料分布确實存在着雙峰模式。”
“我們很高興地看到，其它供應商也開始進行類似的資料驅動型研究，而我們走得更遠，也在基于這些研究結果緻力于為各類資料服務提供更為理想的可變塊大小設計方案。”
“我們一直在公開對此進行讨論，并鼓勵整個市場重新審視長久以來被作為标準的塊大小議題。”
感興趣的朋友可以點選此處檢視pure公司在不同工作負載場景下給出的深層塊大小分析結論。他們給出的共同的論點：單純以4 k或者8 k形式進行基準測試并無意義，因為應用程式io遠遠不隻是單一塊大小的簡單重複。
原文釋出時間為：2016年9月27日
本文作者：黃雅琦
本文來自雲栖社群合作夥伴至頂網，了解相關資訊可以關注至頂網。