大家好！ 正如所承諾的，我們將發布俄羅斯製造的資料儲存系統 - AERODISK ENGINE N2 的負載測試結果。
在上一篇文章中，我們破壞了儲存系統（即我們進行了崩潰測試）並且崩潰測試的結果是肯定的（即我們沒有破壞儲存系統）。 您可以查看碰撞測試結果 .
在上一篇文章的評論中，要求進行額外的、更複雜的碰撞測試。 我們已將它們全部記錄下來，並且一定會在以下一篇文章中實現它們。 同時，您可以隨時造訪我們在莫斯科的實驗室（步行或透過網路遠端進行）並親自執行這些測試（您甚至可以針對特定項目進行測試:-)）。 寫信給我們，我們會考慮所有情況！
此外，如果您不在莫斯科，您仍然可以透過參加離您最近的城市的能力中心的免費培訓活動來更加熟悉我們的儲存系統。
以下是能力中心即將舉辦的活動和營運日期的清單。
- 葉卡捷琳堡。 16 年 2019 月 XNUMX 日。 培訓研討會。 您可以使用以下連結註冊：
- 葉卡捷琳堡。 20 年 21 月 2019 日至 2 月 XNUMX 日。 能力中心。 隨時來現場示範AERODISK ENGINE NXNUMX儲存系統。 稍後將提供具體地址和註冊連結。 按照資訊進行操作。
- 新西伯利亞請關注我們網站或 HUBRA 上的資訊。
2019年XNUMX月 - 喀山。 請關注我們網站或 HUBRA 上的資訊。
2019年XNUMX月 - 克拉斯諾亞爾斯克請關注我們網站或 HUBRA 上的資訊。
2019 年 XNUMX 月
我們還想分享一個好消息：我們終於得到了 您可以觀看過去活動影片的頻道。 我們定期在那裡發布我們的培訓影片。
試驗台
那麼，回到測試。 我們透過安裝額外的 SAS SSD 硬碟以及前端光纖通道 2G 轉接器來升級我們的 ENGINE N16 實驗室儲存系統。 我們以對稱方式升級了運行負載的伺服器，並添加了 FC 16G 適配器。
因此，在我們的實驗室中，我們有一個 2 控制器儲存系統，配備 24 個 SAS SSD 1,6 TB、3 個 DWPD 磁碟，透過 SAN 交換器透過 FC 16G 連接到實體 Linux 伺服器。
測試台示意圖如下圖所示。
測試方法
為了獲得最佳的區塊存取效能，我們將使用 DDP（動態磁碟池）池，我們曾經專門為全快閃系統建立該池。
為了進行測試，我們建立了兩個容量為 1 TB 且具有 RAID-10 保護等級的 LUN。 我們將每個LUN「分佈」在12個磁碟（總共24個）上，以充分利用儲存系統中安裝的每個磁碟的潛力。
我們透過不同的控制器將LUN呈現給伺服器，以盡可能地利用儲存資源。
每項測試將持續一小時，測試將由Flexible IO (FIO)程式執行；FIO資料將自動上傳到Excel，為了清晰起見，Excel中已經建立了圖表。
負載曲線
總共，我們將執行三項測試，每次一小時，不包括預熱時間，我們將為此分配 15 分鐘（這正是預熱 24 個 SSD 驅動器陣列所需的時間）。 這些測試模擬最常遇到的負載配置文件，特別是某些 DBMS、視訊監控系統、媒體內容廣播和備份。
此外，在所有測試中，我們故意停用了快取到儲存系統和主機上 RAM 的功能。 當然，這會使結果惡化，但我們認為，在這種情況下測試會更加公平。
測試結果
測試 1 號。 小塊隨機加載。 高負載事務 DBMS 的模擬。
- 塊大小 = 4k
- 讀/寫 = 70%/30%
- 作品數 = 16
- 隊列深度 = 32
- 載入字元=完全隨機
試驗結果：
總的來說，使用初級中階 Engine N2 系統，我們獲得了 438k IOPS，延遲為 2,6 毫秒。 考慮到系統的級別，我們認為結果相當不錯。 為了了解這是否是系統的限制，我們將查看儲存控制器的資源使用率。
我們主要對 CPU 感興趣，因為如上所述，我們故意停用 RAM 緩存，以免扭曲測試結果。
在兩個儲存控制器上，我們看到大致相同的圖片。
即CPU負載為50%。 這表明這遠未達到該儲存系統的極限，並且仍然可以輕鬆擴展。 讓我們稍微提前一下：以下所有測試也顯示控制器處理器上的負載約為 50%，因此我們不會再次列出它們。
根據我們的實驗室測試，如果我們以 2k 區塊計算隨機 IOPS，則 AERODISK Engine N4 系統的舒適極限約為 700 IOPS。 如果這還不夠，你需要爭取一百萬，那我們有舊型號的 ENGINE N000。
也就是說，百萬IOPS的故事是ENGINE N4，如果一百萬對你來說太多了，那就冷靜地使用N2。
讓我們回到測試。
測試 2 號。 以大塊順序記錄。 模擬視訊監控系統，將資料載入到分析 DBMS 中或記錄備份副本。
在此測試中，我們不再對 IOPS 感興趣，因為當按順序載入大塊時，它們沒有任何意義。 我們主要感興趣的是：寫入流量（每秒兆位元組）和延遲，當然，大塊的寫入流量會比小塊的寫入流量更高。
- 塊大小 = 128k
- 讀/寫 = 0%/100%
- 作品數 = 16
- 隊列深度 = 32
- 載入字元 – 順序
總計：我們每秒錄製 2 GB 數據，延遲 XNUMX 毫秒。 與最接近的國外競爭對手相比，我們認為結果非常出色，而且也不是 ENGINE NXNUMX 系統的極限。
測試 3 號。 大塊順序讀取。 模擬廣播媒體內容、從分析 DBMS 產生報表或從備份還原資料。
與先前的測試一樣，我們對流量和延遲感興趣。
- 塊大小 = 128k
- 讀/寫 = 100%/0%
- 作品數 = 16
- 隊列深度 = 32
- 載入字元 – 順序
可以預見的是，串流讀取效能略優於串流寫入效能。
有趣的是，延遲指標在整個測試過程中都是相同的（直線）。 這不是一個錯誤；當按順序讀取大塊時，在我們的例子中這是一種常見情況。
當然，如果我們將系統以這種形式保留幾週，我們最終會看到圖表中的週期性跳躍，這將與外部因素相關。 但一般來說，它們不會影響畫面。
發現
透過雙控制器 AERODISK ENGINE N2 系統，我們取得了相當不錯的結果（約 438 IOPS 和約每秒 000-5 GB）。 負載測試表明我們絕對不為我們的儲存系統感到羞恥。 相反，各項指標都非常不錯，對應著一個好的儲存系統。
雖然，正如我們上面所寫的，Engine N2 是一個初級型號，而且本文中顯示的結果並不是它的限制。 稍後我們將發布來自舊版 ENGINE N4 系統的類似測試。
當然，我們不可能在一篇文章的框架內涵蓋所有可能的測試，因此我們再次敦促讀者在評論中分享他們對未來測試的願望；我們一定會在未來的出版物中考慮到它們。
另外，我們提醒您，今年我們正在積極開展培訓，因此我們邀請您來到我們的能力中心，在這裡您可以接受AERODISK儲存系統的培訓，同時度過一段有趣而愉快的時光。
我複製有關即將舉行的培訓活動的資訊。
- 葉卡捷琳堡。 16 年 2019 月 XNUMX 日。 培訓研討會。 您可以使用以下連結註冊：
- 葉卡捷琳堡。 20 年 21 月 2019 日至 2 月 XNUMX 日。 能力中心。 隨時來現場示範AERODISK ENGINE NXNUMX儲存系統。 稍後將提供具體地址和註冊連結。 按照資訊進行操作。
- 新西伯利亞請關注我們網站或 HUBRA 上的資訊。
2019年XNUMX月 - 喀山。 請關注我們網站或 HUBRA 上的資訊。
2019年XNUMX月 - 克拉斯諾亞爾斯克請關注我們網站或 HUBRA 上的資訊。
2019 年 XNUMX 月
來源： www.habr.com