大家好！ 透過這篇文章，AERODISK 開設了 Habré 部落格。 萬歲，同志們！
Habré 先前的文章討論了有關儲存系統的架構和基本配置的問題。 在本文中，我們將考慮一個以前未涉及但經常被問到的問題 - 關於 AERODISK ENGINE 儲存系統的容錯能力。 我們的團隊將盡一切努力確保 AERODISK 儲存系統停止運作，即停止運作。 打破它。
碰巧，關於我們公司的歷史、我們的產品以及成功實施範例的文章已經掛在 Habré 上，為此 非常感謝我們的合作夥伴 - TS Solution 和 Softline 公司。
因此，我不會在這裡訓練複製貼上管理技能，而只是提供這些文章原文的連結：
我也想分享一個好消息。 當然，我將從問題開始。 作為一個年輕的供應商，我們經常面臨這樣一個事實：許多工程師和管理員根本不知道如何正確操作我們的儲存系統。
顯然，從管理員的角度來看，管理大多數儲存系統看起來大致相同，但每個製造商都有自己的特點。 我們這裡也不例外。
因此，為了簡化IT專家的訓練任務，我們決定今年致力於免費教育。 為此，我們在俄羅斯的許多大城市開設了 AERODISK 能力中心網絡，任何有興趣的技術專家都可以完全免費參加課程，並獲得管理 AERODISK ENGINE 儲存系統的證書。
在每個能力中心，我們將安裝一個完整的 AERODISK 儲存系統示範台和一台實體伺服器，我們的老師將在上面進行面對面的培訓。 我們將在能力中心出現後公佈其工作時間表，但我們已經在下諾夫哥羅德開設了一個中心，下一個是克拉斯諾達爾市。 您可以使用下面的連結報名參加培訓。 以下是目前已知的有關城市和日期的資訊：
- 下諾夫哥羅德 （已經開放 – 您可以在這裡註冊 );
16年2019月16日前，任何工作時間均可到中心參觀，2019年XNUMX月XNUMX日將舉辦大型培訓課程。 - 克拉斯諾達爾 （即將開放 - 您可以在這裡註冊 );
9年25月2019日至25月2019日，您可以在任何工作時間來中心參觀，XNUMX年XNUMX月XNUMX日將舉辦大型培訓課程。 - 葉卡捷琳堡 （即將開放，請關注我們網站或 Habré 上的資訊）；
2019 年 XNUMX 月至 XNUMX 月。 - 新西伯利亞 （遵循我們網站或 Habré 上的資訊）；
2019 年 XNUMX 月。 - 克拉斯諾亞爾斯克 （遵循我們網站或 Habré 上的資訊）；
2019 年 XNUMX 月。
當然，如果莫斯科離您不遠，那麼您可以隨時訪問我們在莫斯科的辦公室並接受類似的培訓。
全部。 我們已經完成了行銷，讓我們轉向科技吧！
在 Habré 上，我們將定期發布有關我們的產品、負載測試、比較、使用功能和有趣的實現的技術文章。
AERODISK ENGINE N2儲存系統碰撞測試、強度測試
警告！ 讀完這篇文章後，您可以說：好吧，當然，供應商會自我檢查，以便一切都「順利」、溫室條件等。 我會回答：沒有那樣的！ 與我們的外國競爭對手不同，我們位於這裡，離您很近，您可以隨時來找我們（在莫斯科或任何中央委員會）並以任何方式測試我們的儲存系統。 因此，將結果調整為理想的世界圖景對我們來說沒有太大意義，因為我們很容易檢查。 對於那些懶得去、沒有時間的人，我們可以組織遠端測試。 我們為此有一個專門的實驗室。 聯繫我們。
ACHTUNG-2！ 該測試不是負載測試，因為這裡我們只關心容錯能力。 幾週後，我們將準備一個更強大的支架並對儲存系統進行負載測試，並在此發布結果（順便說一下，接受測試請求）。
那麼，讓我們去打破它。
試驗台
我們的展位由以下硬體組成：
- 1 個 Aerodisk Engine N2 儲存系統（2 個控制器、64GB 快取、8 個 FC 連接埠 8Gb/s、4 個乙太網路連接埠 10Gb/s SFP+、4 個乙太網路連接埠 1Gb/s）； 儲存系統中安裝了以下磁碟：
- 4 個 SAS SSD 磁碟 900 GB；
- 12 個 SAS 10k 磁碟 1,2 TB；
- 1 x 實體伺服器，配備 Windows Server 2016（2xXeon E5 2667 v3、96GB RAM、2xFC 連接埠 8Gb/s、2x乙太網路連接埠 10Gb/s SFP+）；
- 2 個 SAN 8G 交換器；
- 2 個 LAN 10G 交換器；
我們透過 FC 和 10G 乙太網路透過交換器將伺服器連接到儲存系統。 展位圖如下。
我們需要的元件（例如 MPIO 和 iSCSI 啟動器）已安裝在 Windows Server 上。
在 FC 交換器上設定區域，在 LAN 交換器上設定對應的 VLAN，並在儲存連接埠、交換器和主機上安裝 MTU 9000（如何執行這一切在我們的文件中有描述，因此我們不再描述這個過程在這裡）。
測試方法
撞擊測試計劃如下：
- 檢查FC埠和乙太網路埠故障。
- 電源故障檢查。
- 控制器故障檢查。
- 檢查組/池中的磁碟故障。
所有測試都將在合成負載條件下執行，我們將由 IOMETER 程式產生該負載條件。 同時，我們將執行相同的測試，但條件是將大檔案複製到儲存系統。
IOmeter配置如下：
- 讀/寫 – 70/30
- 塊 – 128k（我們決定以大塊的形式清洗儲存系統）
- 執行緒數 – 128（與生產負載非常相似）
- 全隨機
- 工作人員數量 – 4（2 個用於 FC，2 個用於 iSCSI）
該測試有以下目標：
- 確保合成載入和複製過程在各種故障情況下不會中斷或導致錯誤。
- 確保切換連接埠、控制器等的過程足夠自動化，並且在發生故障時不需要管理員操作（也就是說，在故障轉移期間，當然我們不是在談論故障復原）。
- 確保日誌中的資訊正確顯示。
準備主機和儲存系統
我們使用 FC 和乙太網路連接埠（分別為 FC 和 iSCSI）在儲存系統上設定區塊存取。 TS Solution 的人員在上一篇文章中詳細描述如何執行此操作（）。 當然，沒有人取消手冊和課程。
我們使用我們擁有的所有驅動器建立了一個混合組。 將 2 個 SSD 磁碟新增至快取中，新增 2 個 SSD 磁碟作為附加儲存層（線上層）。 我們將 12 個 SAS10k 磁碟機分組為 RAID-60P（三重奇偶校驗），以便同時檢查群組中三個磁碟機的故障。 留下一張磁碟用於自動替換。
我們連接了兩個 LUN（一個通過 FC，一個通過 iSCSI）。
兩個 LUN 的所有者都是 Engine-0 控制器
讓我們開始測試吧
我們使用上面的設定啟用 IOMETER。
我們記錄的吞吐量為 1.8 GB/s，延遲為 3 毫秒。 沒有錯誤（錯誤總數）。
同時，從主機的本機磁碟機“C”，我們使用其他介面並行開始將兩個 100GB 大檔案複製到 FC 和 iSCSI 儲存 LUN（Windows 中的磁碟機 E 和 G）。
上面是複製到LUN FC的過程，下面是複製到iSCSI的過程。
測試 #1：停用 I/O 端口
我們從後面接近儲存系統））），稍微移動一下手，我們就可以從 Engine-10 控制器上拔出所有 FC 和乙太網路 0G 電纜。 這就好像一位拿著拖把的清潔女工走過來，決定在鼻涕所在和電纜所在的地方清洗地板（即控制器仍然工作，但 I/O 端口已損壞）。
讓我們看看 IOMETER 和複製檔案。 吞吐量下降至 0,5 GB/s，但很快就恢復到先前的水平（約 4-5 秒）。 沒有錯誤。
複製檔案並沒有停止，速度有所下降，但這並不重要（從 840 MB/s 下降到 720 MB/s）。 抄襲還沒停止。
我們查看儲存系統日誌，看到一條有關連接埠不可用和群組自動重定位的訊息。
資訊面板也告訴我們，FC 連接埠並非一切順利。
儲存系統在 I/O 連接埠故障中倖存下來 成功地。
測試 2. 停用儲存控制器
幾乎立即（將電纜插回儲存系統後），我們決定將控制器從機箱中拉出來完成儲存系統。
我們再次從後面接近儲存系統（我們喜歡它））），這次我們拉出 Engine-1 控制器，此時它是 RDG（該組移動到的）的所有者。
IOmeter中的情況如下。 I/O 停止了大約 5 秒。 錯誤不會累積。
5 秒後，I/O 以大致相同的吞吐量恢復，但延遲為 35 毫秒（延遲在大約幾分鐘後修正）。 從截圖中可以看出，Total error count值為0，即沒有出現寫入或讀取錯誤。
讓我們看看複製我們的文件。 正如您所看到的，它沒有被中斷，性能略有下降，但總體而言一切都恢復到相同的 ~ 800 MB/s。
我們進入儲存系統，在資訊面板中看到一個咒語，表示Engine-1控制器不可用（當然，我們殺死了它）。
我們還在日誌中看到類似的條目。
儲存控制器也倖免於難 成功地。
測試 3：斷開電源。
為了以防萬一，我們再次開始複製文件，但沒有停止 IOMETER。
我們拉動電源裝置。
另一個警報已新增至資訊面板中的儲存系統。
此外，在感測器選單中，我們看到與拔出電源相關的感測器已變成紅色。
儲存系統繼續工作。 電源單元的故障不會對儲存系統的運作產生任何影響；從主機的角度來看，複製速度和IOMETER指標保持不變。
斷電測試通過 成功地。
在最終測試之前，我們決定讓儲存系統恢復一點活力，放回控制器和電源單元，並將電纜整理好，儲存系統很高興地在其運行狀況面板中透過綠色圖示通知我們這一點。
測試 4. 一組中的三個磁碟發生故障
在這次測試之前，我們進行了額外的準備步驟。 事實上，ENGINE儲存系統提供了一個非常有用的東西——不同的重建策略。 TS Solution 之前寫過這個功能，但讓我們回顧一下它的本質。 儲存管理員可以指定重建過程中資源分配的優先順序。 無論是在 I/O 效能方向，即重建時間較長，但沒有效能下降。 或朝著重建速度的方向發展，但生產力會降低。 或者是一個平衡的選擇。 由於磁碟組重建期間的儲存效能始終是令管理員頭痛的問題，因此我們將測試偏向 I/O 效能並以重建速度為代價的策略。
現在讓我們檢查磁碟是否有故障。 我們也允許記錄到 LUN（檔案和 IOMETER）。 由於我們有一個具有三重奇偶校驗（RAID-60P）的群組，這意味著系統必須能夠承受三個磁碟的故障，並且故障後，自動替換必須起作用，一個磁碟必須取代其中一個故障的磁碟在RDG 中，重建必須從它開始。
開始。 首先，透過儲存介面，突出顯示我們要拔出的磁碟（以免錯過並拔出自動更改磁碟）。
我們檢查硬體上的指示。 一切正常，我們看到三個突出顯示的磁碟。
我們取出這三個磁碟。
我們來看看主機上有什麼。 然後……沒有什麼特別的事情發生。
刪除磁碟並開始重建時，複製指標（它們比開始時更高，因為快取已預熱）和 IOMETER 變化不大（5-10% 以內）。
讓我們看看儲存系統上有什麼。
從集團的現況來看，我們看到重組的進程已經開始，並且接近完成。
在RDG骨架中可以看到2個磁碟處於紅色狀態，其中3個已經被更換。 自動替換磁碟不再存在；它替換了第三個故障磁碟。 重建花了幾分鐘，3塊磁碟故障時寫檔案沒有中斷，I/O效能沒有太大變化。
磁碟故障測試肯定通過了 成功地。
結論
此時，我們決定停止針對儲存系統的暴力行為。 我們總結一下：
- FC 連接埠故障檢查 - 成功
- 乙太網路連接埠故障檢查 - 成功
- 控制器故障檢查 - 成功
- 電源故障測試 - 成功
- 檢查組池中的磁碟故障 - 成功
沒有任何故障停止記錄或導致合成負載錯誤；當然，性能受到影響（我們知道如何克服它，我們很快就會做到），但考慮到這些都是幾秒鐘，這是完全可以接受的。 結論：AERODISK儲存系統所有組件的容錯能力都在正常水平，沒有任何故障點。
顯然，在一篇文章中我們無法測試所有故障場景，但我們試圖涵蓋最常見的故障場景。 因此，請發送您的意見、對未來出版物的建議，當然還有充分的批評。 我們很樂意討論（或者更好的是，參加培訓，我複製時間表以防萬一）！ 直到新的測試！
- 下諾夫哥羅德 （已經開放 – 您可以在這裡註冊 );
16年2019月16日前，任何工作時間均可到中心參觀，2019年XNUMX月XNUMX日將舉辦大型培訓課程。 - 克拉斯諾達爾 （即將開放 - 您可以在這裡註冊 );
9年25月2019日至25月2019日，您可以在任何工作時間來中心參觀，XNUMX年XNUMX月XNUMX日將舉辦大型培訓課程。 - 葉卡捷琳堡 （即將開放，請關注我們網站或 Habré 上的資訊）；
2019 年 XNUMX 月至 XNUMX 月。 - 新西伯利亞 （遵循我們網站或 Habré 上的資訊）；
2019 年 XNUMX 月。 - 克拉斯諾亞爾斯克 （遵循我們網站或 Habré 上的資訊）；
2019 年 XNUMX 月。
來源： www.habr.com