1. 首頁 > 生活百科 > >

存儲集成問題如何破壞基礎設施自動化

自動化

存儲集成問題如何破壞基礎設施自動化

當你可以進行更基礎的集成時 ， 為什么要糾結于API？
基礎設施團隊采用自動化工具 ， 期望消除手動流程并創建可預測的部署 。 他們實施Terraform、Ansible和Packer進行編排 ， 使用Prometheus和Grafana進行監控 。 概念驗證成功了 ， 但當他們嘗試在多個存儲平臺上擴展時 ， 自動化策略就出現了分裂 。
問題不在于自動化工具本身 ， 而在于每個存儲平臺都需要單獨的集成代碼 ， 即使是來自同一供應商的產品也作為獨立系統運行 ， 具有不兼容的API 。 當團隊將虛擬機管理程序和網絡自動化加入其中時 ， 復雜性成倍增加 。 分散的基礎設施通過強制將硬件復雜性引入管道的每一層來破壞自動化 。
每個供應商都是獨立平臺的集合
存儲供應商將自己宣傳為統一的提供商 ， 但他們的產品組合實際上是作為不同的API系列運行的 。 每個系列都需要單獨的客戶端代碼、身份驗證流程和對象模型 。
主要存儲供應商通常在其產品線中提供兩個或更多不同的REST API 。 企業級陣列共享一個具有一致端點和身份驗證的API模型 。 中端和超融合產品使用完全不同的REST API ， 具有不兼容的資源定義和URL結構 。 適用于一個產品系列的自動化代碼在另一個系列上會失敗 。 團隊在單一供應商關系下維護多個獨立的存儲后端 。
這種模式在整個行業中重復出現 。 擁有廣泛產品組合的供應商為每條產品線公開單獨的REST API 。 URL結構不同 ， 身份驗證流程不同 ， 對象模型不同 。 在一個平臺上有效的卷創建調用在另一個平臺上使用完全不同的JSON結構和端點 。 團隊無法編寫通用的特定供應商存儲代碼 ， 他們必須為供應商產品組合中的每個產品編寫單獨的集成路徑 。
即使是架構相似的產品也存在差異 。 處理塊存儲的陣列使用一種REST模式 ， 處理文件和對象存儲的產品使用不同的REST模式 。 兩者可能都使用HTTPS和JSON ， 但端點、對象和Token處理方式各不相同 。 即使陣列來自同一供應商 ， 塊和文件操作也需要單獨的客戶端實現 。
相似的功能 ， 不同的實現
分散化不僅限于產品系列 ， 還延伸到功能實現 。 存儲平臺通過不兼容的代碼路徑支持相似的功能 。
卷配置存在于所有塊平臺中 ， 但API調用存在很大差異 。 一些平臺使用簡單的Token身份驗證 ， 其他平臺需要返回會話頭的登錄調用 。 一些平臺在較新的固件版本中包含CSRF Token 。 功能集保持一致 ， 但集成代碼必須考慮特定于供應商和版本的身份驗證模式 。
版本控制引入了額外的變量 。 一些平臺使用基于URL的版本控制 ， 其他平臺依賴基于頭的版本協商 。 較新的固件公開了額外的端點或字段 ， 而較舊版本會默默忽略或拒絕這些內容 。 為一個固件級別編寫的自動化代碼在陣列升級或團隊向現有集群添加新型號時會失效 。
對象模型也存在差異：
塊平臺圍繞卷、LUN、主機、啟動器和映射對象組織 。
文件和對象平臺以文件系統、存儲桶、導出和策略對象為中心 。
概念上的重疊很少 。 團隊需要構建單獨的塊和文件/對象接口并同時維護兩者 。
基礎設施即代碼無法解決問題
組織通常認為Terraform提供程序或Ansible集合可以抽象存儲差異 ， 但事實并非如此 。 基礎設施即代碼工具只是集成工具使用的相同REST API的簡單包裝器 ， 底層復雜性仍然存在 。
供應商為每條產品線提供單獨的Terraform提供程序和Ansible集合 。 每個提供程序公開具有不同參數結構的不同資源 。 為一個平臺編寫的Terraform模塊無法移植到同一供應商系列中的另一個平臺 。 團隊需要為每個平臺維護單獨的基礎設施即代碼模塊 。
基礎設施即代碼層不能統一存儲語義 ， 它以不同的語法再現了分散化 。 團隊用HCL或YAML替換REST API調用 ， 但條件邏輯、版本處理和特定于平臺的參數仍然存在 。
多層問題
存儲集成代表問題的一個維度 。 虛擬機管理程序和網絡自動化引入了獨立運行的額外層 。 虛擬機管理程序管理依賴于具有自己身份驗證模型的單獨API 。 網絡結構配置通過使用特定于供應商的構造的不同控制器實現 。 完整的自動化框架必須協調跨存儲、計算和網絡層 ， 而這些層不共享任何通用模式 。
當虛擬機在主機之間移動時 ， 存儲路徑行為可能會根據陣列模型而改變 。 當服務器硬件刷新時 ， 網絡適配器順序變得不可預測 。 自動化通過條件邏輯吸收這些跨層依賴關系 ， 這些邏輯隨著每一代硬件和固件更新而增長 。
私有AI基礎設施使問題進一步復雜化 。 組織為AI工作負載部署具有不同性能配置文件和對象模型的單獨存儲堆棧 。 自動化框架現在必須維護傳統塊陣列、文件系統、對象存儲和AI優化平臺的存儲集成代碼 。 每次添加都會增加維護負擔 。
對可擴展性的影響
當存儲集成需要針對每個平臺和每個產品的代碼時 ， 基礎設施自動化變得難以擴展 。 團隊編寫的Terraform模塊在一個數據中心中有效 ， 但在另一個數據中心中失敗 ， 因為存儲供應商不同 。 他們為每個陣列系列維護單獨的Ansible角色分支 。 災難恢復站點與生產環境出現偏差 ， 因為自動化無法解決位置之間的平臺差異 。
硬件刷新周期也會破壞自動化 。 新的存儲型號引入需要模塊更新的API更改 。 固件升級公開了舊代碼無法處理的字段 。 團隊花在維護集成代碼上的時間比通過自動化節省的時間還多 。 基礎設施即代碼的承諾變成了基礎設施異常即代碼 。
原本應該隱藏平臺差異的抽象層反而記錄了這些差異 。 存儲后端成倍增加 ， 條件邏輯在模塊和角色中蔓延 。 版本檢測變得強制性 。 隨著環境擴展 ， 代碼庫變得脆弱 。
架構替代方案
存儲供應商提供REST API ， 但僅有REST并不能創建一致性 。 構建可擴展自動化的組織必須考慮跨供應商、供應商產品組合內以及跨功能實現的分散化 。
統一基礎設施平臺采用不同的方法 。 像VergeOS這樣的平臺通過單一API將存儲、計算和網絡集成到單一代碼庫中 。 存儲抽象發生在操作系統級別 ， 而不是通過針對每個供應商的集成代碼 。 團隊編寫引用存儲服務而不是存儲陣列的Terraform模塊和Ansible角色 。 硬件變化對自動化層不可見 ， 因為平臺在內部處理抽象 。
評估自動化策略的團隊應該評估其框架必須維護多少存儲集成路徑 。 他們應該測量現有模塊中已經存在的條件邏輯 。 他們應該估計存儲刷新后更新代碼所需的時間 。 他們應該測試相同的自動化是否在所有集群中有效 ， 而無需特定于平臺的分支 。 答案決定了基礎設施架構是支持還是抵制自動化 。
當代碼可以描述意圖而不編碼硬件異常時 ， 基礎設施即代碼才有效 。 當每個平臺需要單獨的實現路徑時 ， 就會出現存儲集成挑戰 ， 但自動化工具按設計運行 。 它們下面的基礎引入了破壞可擴展性的復雜性 。 解決方案是將該基礎統一到單一代碼庫的基礎設施操作系統中 。
要了解更多信息 ， 請注冊我們的實時網絡研討會：構建端到端自動化鏈
本文由VergeIO貢獻 。
Q&A
Q1：為什么存儲平臺的API集成會破壞基礎設施自動化？
A：因為每個存儲平臺都需要單獨的集成代碼 ， 即使是同一供應商的不同產品也使用不兼容的API 。 當團隊嘗試跨多個存儲平臺擴展自動化時 ， 需要為每個產品系列編寫和維護單獨的集成路徑 ， 導致條件邏輯成倍增長 ， 代碼庫變得脆弱 ， 維護成本超過自動化帶來的收益 。
Q2：Terraform和Ansible這類基礎設施即代碼工具能解決存儲集成的分散化問題嗎？
A：不能 。 這些工具只是對REST API的簡單包裝 ， 底層的復雜性仍然存在 。 供應商為每條產品線提供單獨的Terraform提供程序和Ansible集合 ， 每個提供程序使用不同的資源和參數結構 。 團隊仍需為每個平臺維護單獨的模塊 ， 只是用HCL或YAML替換了API調用 ， 但平臺特定的參數和條件邏輯依然存在 。
Q3：如何從架構層面解決存儲自動化的復雜性問題？
A：可以采用統一基礎設施平臺 ， 如VergeOS這類將存儲、計算和網絡集成到單一代碼庫的平臺 。 這種平臺在操作系統級別進行存儲抽象 ， 而不是通過針對每個供應商的集成代碼 。 團隊編寫的自動化代碼引用存儲服務而非具體存儲陣列 ， 硬件變化對自動化層不可見 ， 從而從根本上消除了多平臺集成的復雜性 。
【存儲集成問題如何破壞基礎設施自動化】

    推薦閱讀