哪個韌體版本最“正確”和“有效”？ 如果儲存系統保證99,9999%的容錯率，是否代表即使沒有軟體更新，它也能不間斷地運作？ 或者，相反，為了獲得最大的容錯能力，您應該始終安裝最新的韌體？ 我們將根據我們的經驗嘗試回答這些問題。
簡短介紹
我們都知道，每個版本的軟體，無論是作業系統還是設備驅動程序，通常都包含缺陷/錯誤和其他“功能”，這些“功能”可能直到設備使用壽命結束或“開放”時才會“出現”僅在某些條件下。 這些細微差別的數量和重要性取決於軟體的複雜性（功能）以及開發過程中的測試品質。
通常，用戶會保留「出廠韌體」（著名的「它可以工作，所以不要弄亂它」）或始終安裝最新版本（在他們的理解中，最新意味著最有效）。 我們使用不同的方法 - 我們查看所使用的所有內容的發行說明 設備並為每台設備仔細選擇合適的韌體。
正如他們所說，我們根據經驗得出了這個結論。 透過我們的操作範例，我們將告訴您為什麼如果您不及時監控軟體更新和說明，儲存系統所承諾的 99,9999% 可靠性就毫無意義。 我們的案例適用於任何供應商的儲存系統的用戶，因為任何製造商的硬體都可能發生類似的情況。
選擇新的儲存系統
去年年底，我們的基礎架構中新增了一個有趣的資料儲存系統：IBM FlashSystem 5000 系列的初級型號，在購買時稱為 Storwize V5010e。 現在它以 FlashSystem 5010 的名稱出售，但實際上它是相同的硬體基礎，內部具有相同的 Spectrum Virtualize。
順便說一句，統一管理系統的存在是 IBM FlashSystem 之間的主要差異。 對於年輕系列的模型來說，它實際上與更俱生產力的模型沒有什麼不同。 選擇特定型號僅提供適當的硬體基礎，其特徵使得可以使用一種或另一種功能或提供更高級別的可擴展性。 該軟體識別硬體並為該平台提供必要且充分的功能。
IBM 快閃記憶體系統 5010
簡單介紹一下我們的型號5010。這是一款入門級雙控制器塊儲存系統。 它可以容納NLSAS、SAS、SSD磁碟。 其中不支援 NVMe 放置，因為此儲存模型定位於解決不需要 NVMe 磁碟機效能的問題。
購買儲存系統是為了容納檔案資訊或不經常存取的資料。 因此，其功能的標準集對我們來說就足夠了：分層（Easy Tier）、精簡配置。 NLSAS 磁碟在 1000-2000 IOPS 水準上的效能也讓我們非常滿意。
我們的經驗-我們如何沒有按時更新韌體
現在談談軟體更新本身。 購買時，系統已經安裝了稍微過時版本的 Spectrum Virtualize 軟體，即 8.2.1.3.
我們研究了韌體描述併計劃更新 8.2.1.9。 如果我們效率更高一點，這篇文章就不會存在——這個 bug 就不會出現在更新的韌體上。 但由於某些原因，該系統的更新被推遲了。
結果，輕微的更新延遲導致了極其不愉快的畫面，如連結中的描述所示： .
是的，在該版本的韌體中，所謂的 APAR（授權程式分析報告）HU02104 是相關的。 如下圖所示。 在負載下，在某些情況下，快取開始溢出，然後系統進入保護模式，在該模式下停用池的 I/O。 在我們的例子中，它看起來像是在 RAID 3 模式下斷開 RAID 群組的 6 個磁碟，斷開連接發生了 6 分鐘。 接下來，恢復對池中磁碟區的存取。
如果有人不熟悉 IBM Spectrum Virtualize 上下文中邏輯實體的結構和命名，我現在將簡要地解釋一下。
儲存系統邏輯元素結構
磁碟被收集到稱為 MDisk（託管磁碟）的群組中。 MDisk 可以是經典的 RAID (0,1,10,5,6、XNUMX、XNUMX、XNUMX、XNUMX) 或虛擬化的 RAID - DRAID（分散式 RAID）。 使用 DRAID 可以提高陣列的效能，因為... 將使用群組中的所有磁碟，並且重建時間將減少，因為僅需要恢復某些區塊，而不是故障磁碟中的所有資料。
在 RAID-5 模式下使用分散式 RAID (DRAID) 時，資料區塊在磁碟之間的分散。
下圖顯示了在一個磁碟發生故障時 DRAID 重建如何運作的邏輯：
一塊磁碟故障時DRAID重建的邏輯
接下來，一個或多個 MDisk 形成一個所謂的池。 在同一池中，不建議在同一類型的磁碟上使用具有不同 RAID/DRAID 等級的 MDisk。 我們不會太深入地討論這個問題，因為… 我們計劃在以下一篇文章中介紹這一點。 事實上，池分為多個卷，這些卷使用一種或另一種區塊存取協定呈現給主機。
因此，由於上述情況，我們 阿帕HU02104由於三個磁碟的邏輯故障，MDisk 停止運行，進而導致 Pool 和相應的 Volume 故障。
由於這些系統非常智能，因此可以連接到基於雲端的 IBM Storage Insights 監控系統，如果出現問題，該系統會自動向 IBM 支援人員發送服務請求。 建立應用程式後，IBM 專家將遠端執行診斷並聯繫系統使用者。
因此，問題很快就得到了解決，並且從支援服務收到了及時建議，將我們的系統更新到先前選擇的韌體 8.2.1.9，當時該韌體已經修復。 它證實了 .
結果和我們的建議
俗話說：「善始善終」。 韌體中的錯誤並未造成嚴重問題 - 伺服器已盡快恢復並且沒有資料遺失。 有些客戶必須重新啟動虛擬機，但總的來說，我們已經做好了應對更多負面後果的準備，因為我們每天都會對所有基礎架構元素和客戶端電腦進行備份。
我們已收到確認，即使是承諾可用性 99,9999% 的可靠系統也需要關注和及時維護。 根據實際情況，我們得出了一些結論並分享我們的建議：
-
必須監視更新的發布，研究發行說明以糾正潛在的關鍵問題，並及時執行計劃的更新。
這是一個組織性的、甚至是相當明顯的觀點，似乎不值得關注。 然而，在這個「平坦的地面」上，你很容易絆倒。 其實，正是這一刻，才增加了上述的麻煩。 制定更新法規時要非常小心，並同樣仔細地監控其遵守情況。 這一點更涉及「紀律」的概念。
-
最好讓系統保持最新的軟體版本。 而且，目前的並不是數字較大的那一款，而是發售日期較晚的那一款。
例如，IBM 為其儲存系統保留了至少兩個最新的軟體版本。 在撰寫本文時，這些是 8.2 和 8.3。 8.2 的更新較早發布。 8.3 的類似更新通常會稍微延遲發布。
8.3 版具有許多功能優勢，例如，能夠透過新增一個或多個新磁碟來擴展 MDisk（在 DRAID 模式下）（此功能從版本 8.3.1 開始出現）。 這是一個相當基本的功能，但不幸的是，在 8.2 中沒有這樣的功能。
-
如果由於某種原因無法更新，則對於版本 8.2.1.9 和 8.3.1.0 之前的 Spectrum Virtualize 軟體版本（與上述錯誤相關的情況），為了降低其發生的風險，IBM 技術支援建議在池層級限制系統效能，如下圖所示（該圖是在俄羅斯化版本的GUI 中拍攝的）。 以10000 IOPS為例，請依照您的系統特性進行選擇。
限制 IBM 儲存效能
-
有必要正確計算儲存系統的負載並避免過載。 為此，您可以使用 IBM sizer（如果您有權存取它），也可以藉助合作夥伴或第三方資源。 了解儲存系統上的負載概況非常重要，因為MB/s 和 IOPS 性能差異很大，至少取決於以下參數：
-
操作類型：讀或寫，
-
操作塊大小，
-
讀寫操作佔總 I/O 流的百分比。
此外，操作速度也受到資料區塊讀取方式的影響：順序讀取或隨機讀取。 在應用程式端執行多個資料存取操作時，存在依賴操作的概念。 也建議考慮到這一點。 所有這些都有助於查看作業系統、儲存系統、伺服器/虛擬機器管理程式的效能計數器的整體數據，以及了解應用程式、DBMS 和其他磁碟資源「消費者」的操作特性。
-
-
最後，請確保備份是最新且有效的。 應根據業務可接受的 RPO 值來配置備份計劃，並定期驗證備份的完整性檢查（相當多的備份軟體供應商在其產品中實現了自動驗證），以確保可接受的 RTO 值。
感謝您閱讀到最後。
我們準備在評論中回答您的問題和意見。 還，其中我們定期舉辦促銷活動（IaaS 折扣和 VPS 促銷代碼贈品高達 100%），在 Habr 博客上撰寫有趣的新聞並發布新文章。
來源： www.habr.com