當(dāng)你可以進(jìn)行更基礎(chǔ)的集成時，為什么要糾結(jié)于API？

基礎(chǔ)設(shè)施團(tuán)隊采用自動化工具，期望消除手動流程并創(chuàng)建可預(yù)測的部署。他們實施Terraform、Ansible和Packer進(jìn)行編排，使用Prometheus和Grafana進(jìn)行監(jiān)控。概念驗證成功了，但當(dāng)他們嘗試在多個存儲平臺上擴(kuò)展時，自動化策略就出現(xiàn)了分裂。

問題不在于自動化工具本身，而在于每個存儲平臺都需要單獨的集成代碼，即使是來自同一供應(yīng)商的產(chǎn)品也作為獨立系統(tǒng)運(yùn)行，具有不兼容的API。當(dāng)團(tuán)隊將虛擬機(jī)管理程序和網(wǎng)絡(luò)自動化加入其中時，復(fù)雜性成倍增加。分散的基礎(chǔ)設(shè)施通過強(qiáng)制將硬件復(fù)雜性引入管道的每一層來破壞自動化。

每個供應(yīng)商都是獨立平臺的集合

存儲供應(yīng)商將自己宣傳為統(tǒng)一的提供商，但他們的產(chǎn)品組合實際上是作為不同的API系列運(yùn)行的。每個系列都需要單獨的客戶端代碼、身份驗證流程和對象模型。

主要存儲供應(yīng)商通常在其產(chǎn)品線中提供兩個或更多不同的REST API。企業(yè)級陣列共享一個具有一致端點和身份驗證的API模型。中端和超融合產(chǎn)品使用完全不同的REST API，具有不兼容的資源定義和URL結(jié)構(gòu)。適用于一個產(chǎn)品系列的自動化代碼在另一個系列上會失敗。團(tuán)隊在單一供應(yīng)商關(guān)系下維護(hù)多個獨立的存儲后端。

這種模式在整個行業(yè)中重復(fù)出現(xiàn)。擁有廣泛產(chǎn)品組合的供應(yīng)商為每條產(chǎn)品線公開單獨的REST API。URL結(jié)構(gòu)不同，身份驗證流程不同，對象模型不同。在一個平臺上有效的卷創(chuàng)建調(diào)用在另一個平臺上使用完全不同的JSON結(jié)構(gòu)和端點。團(tuán)隊無法編寫通用的特定供應(yīng)商存儲代碼，他們必須為供應(yīng)商產(chǎn)品組合中的每個產(chǎn)品編寫單獨的集成路徑。

即使是架構(gòu)相似的產(chǎn)品也存在差異。處理塊存儲的陣列使用一種REST模式，處理文件和對象存儲的產(chǎn)品使用不同的REST模式。兩者可能都使用HTTPS和JSON，但端點、對象和Token處理方式各不相同。即使陣列來自同一供應(yīng)商，塊和文件操作也需要單獨的客戶端實現(xiàn)。

相似的功能，不同的實現(xiàn)

分散化不僅限于產(chǎn)品系列，還延伸到功能實現(xiàn)。存儲平臺通過不兼容的代碼路徑支持相似的功能。

卷配置存在于所有塊平臺中，但API調(diào)用存在很大差異。一些平臺使用簡單的Token身份驗證，其他平臺需要返回會話頭的登錄調(diào)用。一些平臺在較新的固件版本中包含CSRF Token。功能集保持一致，但集成代碼必須考慮特定于供應(yīng)商和版本的身份驗證模式。

版本控制引入了額外的變量。一些平臺使用基于URL的版本控制，其他平臺依賴基于頭的版本協(xié)商。較新的固件公開了額外的端點或字段，而較舊版本會默默忽略或拒絕這些內(nèi)容。為一個固件級別編寫的自動化代碼在陣列升級或團(tuán)隊向現(xiàn)有集群添加新型號時會失效。

對象模型也存在差異：

塊平臺圍繞卷、LUN、主機(jī)、啟動器和映射對象組織。

文件和對象平臺以文件系統(tǒng)、存儲桶、導(dǎo)出和策略對象為中心。

概念上的重疊很少。團(tuán)隊需要構(gòu)建單獨的塊和文件/對象接口并同時維護(hù)兩者。

基礎(chǔ)設(shè)施即代碼無法解決問題

組織通常認(rèn)為Terraform提供程序或Ansible集合可以抽象存儲差異，但事實并非如此?；A(chǔ)設(shè)施即代碼工具只是集成工具使用的相同REST API的簡單包裝器，底層復(fù)雜性仍然存在。

供應(yīng)商為每條產(chǎn)品線提供單獨的Terraform提供程序和Ansible集合。每個提供程序公開具有不同參數(shù)結(jié)構(gòu)的不同資源。為一個平臺編寫的Terraform模塊無法移植到同一供應(yīng)商系列中的另一個平臺。團(tuán)隊需要為每個平臺維護(hù)單獨的基礎(chǔ)設(shè)施即代碼模塊。

基礎(chǔ)設(shè)施即代碼層不能統(tǒng)一存儲語義，它以不同的語法再現(xiàn)了分散化。團(tuán)隊用HCL或YAML替換REST API調(diào)用，但條件邏輯、版本處理和特定于平臺的參數(shù)仍然存在。

多層問題

存儲集成代表問題的一個維度。虛擬機(jī)管理程序和網(wǎng)絡(luò)自動化引入了獨立運(yùn)行的額外層。虛擬機(jī)管理程序管理依賴于具有自己身份驗證模型的單獨API。網(wǎng)絡(luò)結(jié)構(gòu)配置通過使用特定于供應(yīng)商的構(gòu)造的不同控制器實現(xiàn)。完整的自動化框架必須協(xié)調(diào)跨存儲、計算和網(wǎng)絡(luò)層，而這些層不共享任何通用模式。

當(dāng)虛擬機(jī)在主機(jī)之間移動時，存儲路徑行為可能會根據(jù)陣列模型而改變。當(dāng)服務(wù)器硬件刷新時，網(wǎng)絡(luò)適配器順序變得不可預(yù)測。自動化通過條件邏輯吸收這些跨層依賴關(guān)系，這些邏輯隨著每一代硬件和固件更新而增長。

私有AI基礎(chǔ)設(shè)施使問題進(jìn)一步復(fù)雜化。組織為AI工作負(fù)載部署具有不同性能配置文件和對象模型的單獨存儲堆棧。自動化框架現(xiàn)在必須維護(hù)傳統(tǒng)塊陣列、文件系統(tǒng)、對象存儲和AI優(yōu)化平臺的存儲集成代碼。每次添加都會增加維護(hù)負(fù)擔(dān)。

對可擴(kuò)展性的影響

當(dāng)存儲集成需要針對每個平臺和每個產(chǎn)品的代碼時，基礎(chǔ)設(shè)施自動化變得難以擴(kuò)展。團(tuán)隊編寫的Terraform模塊在一個數(shù)據(jù)中心中有效，但在另一個數(shù)據(jù)中心中失敗，因為存儲供應(yīng)商不同。他們?yōu)槊總€陣列系列維護(hù)單獨的Ansible角色分支。災(zāi)難恢復(fù)站點與生產(chǎn)環(huán)境出現(xiàn)偏差，因為自動化無法解決位置之間的平臺差異。

硬件刷新周期也會破壞自動化。新的存儲型號引入需要模塊更新的API更改。固件升級公開了舊代碼無法處理的字段。團(tuán)隊花在維護(hù)集成代碼上的時間比通過自動化節(jié)省的時間還多?；A(chǔ)設(shè)施即代碼的承諾變成了基礎(chǔ)設(shè)施異常即代碼。

原本應(yīng)該隱藏平臺差異的抽象層反而記錄了這些差異。存儲后端成倍增加，條件邏輯在模塊和角色中蔓延。版本檢測變得強(qiáng)制性。隨著環(huán)境擴(kuò)展，代碼庫變得脆弱。

架構(gòu)替代方案

存儲供應(yīng)商提供REST API，但僅有REST并不能創(chuàng)建一致性。構(gòu)建可擴(kuò)展自動化的組織必須考慮跨供應(yīng)商、供應(yīng)商產(chǎn)品組合內(nèi)以及跨功能實現(xiàn)的分散化。

統(tǒng)一基礎(chǔ)設(shè)施平臺采用不同的方法。像VergeOS這樣的平臺通過單一API將存儲、計算和網(wǎng)絡(luò)集成到單一代碼庫中。存儲抽象發(fā)生在操作系統(tǒng)級別，而不是通過針對每個供應(yīng)商的集成代碼。團(tuán)隊編寫引用存儲服務(wù)而不是存儲陣列的Terraform模塊和Ansible角色。硬件變化對自動化層不可見，因為平臺在內(nèi)部處理抽象。

評估自動化策略的團(tuán)隊?wèi)?yīng)該評估其框架必須維護(hù)多少存儲集成路徑。他們應(yīng)該測量現(xiàn)有模塊中已經(jīng)存在的條件邏輯。他們應(yīng)該估計存儲刷新后更新代碼所需的時間。他們應(yīng)該測試相同的自動化是否在所有集群中有效，而無需特定于平臺的分支。答案決定了基礎(chǔ)設(shè)施架構(gòu)是支持還是抵制自動化。

當(dāng)代碼可以描述意圖而不編碼硬件異常時，基礎(chǔ)設(shè)施即代碼才有效。當(dāng)每個平臺需要單獨的實現(xiàn)路徑時，就會出現(xiàn)存儲集成挑戰(zhàn)，但自動化工具按設(shè)計運(yùn)行。它們下面的基礎(chǔ)引入了破壞可擴(kuò)展性的復(fù)雜性。解決方案是將該基礎(chǔ)統(tǒng)一到單一代碼庫的基礎(chǔ)設(shè)施操作系統(tǒng)中。

要了解更多信息，請注冊我們的實時網(wǎng)絡(luò)研討會：構(gòu)建端到端自動化鏈

本文由VergeIO貢獻(xiàn)。

Q&A

Q1：為什么存儲平臺的API集成會破壞基礎(chǔ)設(shè)施自動化？

A：因為每個存儲平臺都需要單獨的集成代碼，即使是同一供應(yīng)商的不同產(chǎn)品也使用不兼容的API。當(dāng)團(tuán)隊嘗試跨多個存儲平臺擴(kuò)展自動化時，需要為每個產(chǎn)品系列編寫和維護(hù)單獨的集成路徑，導(dǎo)致條件邏輯成倍增長，代碼庫變得脆弱，維護(hù)成本超過自動化帶來的收益。

Q2：Terraform和Ansible這類基礎(chǔ)設(shè)施即代碼工具能解決存儲集成的分散化問題嗎？

A：不能。這些工具只是對REST API的簡單包裝，底層的復(fù)雜性仍然存在。供應(yīng)商為每條產(chǎn)品線提供單獨的Terraform提供程序和Ansible集合，每個提供程序使用不同的資源和參數(shù)結(jié)構(gòu)。團(tuán)隊仍需為每個平臺維護(hù)單獨的模塊，只是用HCL或YAML替換了API調(diào)用，但平臺特定的參數(shù)和條件邏輯依然存在。

Q3：如何從架構(gòu)層面解決存儲自動化的復(fù)雜性問題？

A：可以采用統(tǒng)一基礎(chǔ)設(shè)施平臺，如VergeOS這類將存儲、計算和網(wǎng)絡(luò)集成到單一代碼庫的平臺。這種平臺在操作系統(tǒng)級別進(jìn)行存儲抽象，而不是通過針對每個供應(yīng)商的集成代碼。團(tuán)隊編寫的自動化代碼引用存儲服務(wù)而非具體存儲陣列，硬件變化對自動化層不可見，從而從根本上消除了多平臺集成的復(fù)雜性。