發布時間: 2021-11-18 11:38:02
商業市場的快速變化導致企業尋求不斷加快數字化轉型,不斷推出新的應用以吸引客戶并提升用戶滿意度。
為了縮短應用開發和上線周期,他們正在尋求實施持續交付/持續集成 (CI/CD) 實踐;并且為了降低成本、提高系統抗風險能力,使用著包括裸機服務器、虛擬機和容器在內的各種計算基礎設施,將應用從本地擴展到跨多個公共云的“數據中心”。應用開發人員以及應用所有者,希望通過 GitOps 或 CI/CD 流水線方法,自動化地完成應用的多次、多位置的重復部署。但是應用最終是運行在“基礎設施層”之上,在運行和維護方式上,現代化應用層與基礎設施層之間的差距是巨大的。
應用層使用 DevOps 和 CI/CD 方法時,最佳選擇是只需面向一種抽象出來的底層架構,而不是面向多種硬件設備的多種 API。如果應用層要做的針對不同的底層設備 API 進行 DevOps 開發,人員和時間方面耗費巨大;如果出于對多種底層環境的陌生感而僅適配其中一種,就等于被鎖定在特定的硬件之上——難道以“敏捷應用”和“DevOps 和 CI/CD”之名,將應用重新拉回“軟硬件一體化”的時代?DevOps 和 CI/CD 需要跨多云環境的智能自動化和一致的網絡服務,以消除由數據中心的負載均衡設備、云中的虛擬 ADC 或容器網絡的開源解決方案造成的孤島。
VMware 站在應用開發人員的角度,在應用與底層基礎設施之間定義了“現代應用連接”這個虛擬化層,為 DevOps 和 CI/CD 屏蔽了底層設備的差異,打通了應用自動化開發、部署和維護之路。NSX 是“現代應用連接”解決方案中的重要支柱,自帶了很多自動化元素,可以自頂向下進行基于 API 的意圖自定義,而無需定義執行細節;NSX 高級負載均衡負責應用交付的自動化。VMware 的方案,將抹平應用層與基礎架構層之間差異,使現代化應用的 DevOps 和 CI/CD 方法可以貫徹到“底”。
對于任何以“設備”為中心的基礎架構,都面臨這樣的困境。隨著虛擬化技術的普及,“設備”可能物理盒子,也可能被改造成虛擬機形態,但只要它們的工作原理沒有變化,就不支持彈性擴縮、自恢復、自主決策這些真正的“自動化”特點。這個架構無法在 DevOps 環境中,真正支撐業務所需的自動化和自助服務。本文討論的重點是負載均衡和應用交付,因為路由和交換等基礎設施可以在應用發生更新變化時保持相對的穩定性,硬件設施和軟件策略配置無需隨應用頻繁變更。而應用交付是直接為應用服務的,是連接客戶與應用的必經之路,決定著新上線的應用是否能夠被客戶穩定且安全地使用。
傳統應用交付方法的困境
應用交付的起源和核心是“負載均衡”?;凇霸O備”概念的構建的負載均衡器欠缺自動故障恢復功能,也缺乏跨多個云擴展的能力和自動化,欠缺根據流量模式自動擴張(或者縮減)負載均衡的能力,并且需要對每個“設備”實例進行大量的手動配置和單獨管理。參見圖 1。
圖 1:創建虛擬服務的傳統方法
圖 1 中的架構和方法不是為 DevOps 和 CI/CD 的流水線設計的,因為這樣的環境非常復雜、僵化和脆弱,它的使用方法嚴重地依賴“設備”——以設備為中心,而不是以業務和應用為中心。
VMware NSX 高級負載均衡(本文中簡化縮寫為 NSX-ALB)使用軟件定義的架構,將中央控制平面(控制器)與分布式數據平面(服務引擎)分開??刂破魇钦麄€系統的“大腦”,充當分布式數據平面的智能、管理和控制單點,使其完全自動化并與 CI/CD 管道無縫連接以進行應用交付??刂破魈峁┗陂]環遙測的全面可觀察性,并提供易用的深度分析,以根據應用監控、端到端計時、可搜索的流量日志、安全分析、日志分析、客戶端分析等信息做出自動化決策、部署和執行。
API ≠決策自動化
以應用為中心的架構需要自動化并向業務線提供自助服務。自動化和自助服務代表了現代智能網絡的發展。很多時候,在為負載均衡、WAF、GSLB 和容器 Ingress 網絡等應用服務提供 “API” 和“交付自動化”之間存在巨大鴻溝。問題是在于:人工編寫腳本調用 API,不是自動化;而讓系統閉環智能執行日常運維的“決策”,才是自動化。NSX-ALB 采用的聲明式“決策自動化”可簡化操作、提高敏捷性并提高安全性。
決策自動化允許管理員設定網絡運行的預期結果,然后自動部署、配置、按需提供服務,并管理應用服務的整個生命周期,包括自動故障恢復。在閉環機器學習的幫助下,聲明式模型中指定的計劃和策略會自動實施、交付和強制執行。這避免了繁重的腳本手動編寫腳本以應對特定場景的要求。決策自動化還允許 IT 架構師甚至應用所有者指定他們的意圖,而無需依賴 IT 工程師手動輸入或編寫專用腳本。見圖 2。
圖 2:任務腳本與決策自動化
我們可以打一個比方:圖 2 中左側依靠 API 調用任務腳本的方式,就好像是操作提線木偶,一舉一動都離不開人工干預;而真正的人工智能和機器人,則如圖 2 右側所示,具備自主決策和自我管理的行動能力。雖然現有的“機器人”都不完美,但已經從本質上與“提線木偶”區別開來。
NSX-ALB 的決策自動化采用軟件定義的、與底層無關的、基于云原生的架構。該架構將重點從基礎設施轉移到應用,將專有硬件轉移到軟件,從手動配置轉移到集中策略。它允許調用程序接口 API ,但更重要的是可以實現更好的自動化、系統交付的結果并降低運維成本。參見圖 3。
圖 3:Avi 高層架構
自動化應用交付
使用 NSX-ALB 創建 VIP 的決策自動化
讓我們舉一個網絡管理員日常工作可能面臨的例子:比如,新業務上線,需要在負載均衡系統中為這個新業務的服務器創建一個新的虛擬服務。虛擬服務,就是負載均衡器后面的業務系統的所使用的虛擬 IP 和端口。
對于基于硬件的應用交付系統,首先按下面圖中的列表進行自查:已有的負載平衡器是什么?是否配置在正確的網絡環境中?它現有的性能水平是否足以正常運行?它有能力滿足業務未來增長的需求嗎?除了這些,還有其他依賴條件嗎?
然后,一旦有了這些問題的答案,需要做出設計決定:是否需要調整網絡環境,是否繼續沿用現有的硬件,是否需要購買新硬件?如何配置負載均衡器?為這個應用預留哪一個 IP 地址作為虛擬 IP ?如何配置上下游相關的防火墻和路由?如何配置統一身份驗證?設置哪些系統告警?這些需求調研、設計、測試、實施的過程需要幾天到幾周的時間,如果需要購買并添加新設備,則需要幾個月。參見圖 4。
圖 4:創建新虛擬服務的傳統部署流程
以上步驟顯然不是對現代化應用架構和 DevOps 流程友好的方式。讓我們看看如何使用 NSX-ALB 做到應用發布的自動化、流程化、敏捷化。
管理員只需在控制器上聲明本次發布的應用所對應的虛擬服務屬性(位置、協議、端口號、代理模式等),然后控制器將進行完整的自動化策略配置:控制器在所有適配的基礎架構環境中自動找到最佳位置(數據中心或公有云)、最佳主機來自動部署新的服務引擎、自動從地址池分配 IP 地址、配置網卡、下發虛擬服務策略、WAF 策略、安全策略、配置身份驗證和授權、將虛擬應用的 FQDN 注冊到 DNS、自動配置和獲取 SSL 證書……參見圖 5。
圖 5:NSX-ALB 自動化部署創建新的虛擬服務
自動增加容量和重新平衡
NSX-ALB 的服務引擎(SE)是工作在數據平面的負載均衡器和 Web 應用防火墻 (WAF) ,可提供流量管理和應用安全性,同時從流量中收集實時分析。在執行應用交付任務時,服務引擎 SE 可能會遇到資源耗盡的情況。這可能是由于部署了新應用或已有應用的訪問量提高,導致 CPU 利用率或內存利用率或流量出現大幅增長。
從 SE 實時監控多個應用和網絡遙測數據,控制器實現了在應用的整個生命周期中基于決策的 SE 自動化管理和運維。從 SE 的初始部署開始,到根據需求動態增加 SE 數量或跨本地、多云和多區域部署的自動故障恢復。見圖 6。
圖 6:彈性 SE 擴展——數量和位置
多生態集成
借助 NSX-ALB ,企業可以毫不費力地跨多個云移動工作負載。通過在流量高峰期間自動將應用擴展到云上,使企業能夠使用公有云作為其數據中心的自然擴展。NSX-ALB 控制器可以在公有云中自動創建應用資源,以吸收突增的流量??刂破骺梢耘c vCenter 和公有云的 API 進行對話。因此,如果您希望在 任何環境中部署負載均衡器或服務引擎,管理員只需要聲明虛擬服務屬性“我想將此應用部署到xx環境中”,隨后,控制器可以將負載均衡自動實例化為服務引擎 SE,并將虛擬服務自動配置到 SE 上。
NSX-ALB 本身并不是技術孤島,它需要與周圍的環境、周圍的生態系統相結合。它可以通過與 Infoblox 或其他 IP 地址管理工具來協作自動配置 IP, 也可以通過與 Amazon 的 Route53 之類的功能協作來自動將虛擬服務注冊到 DNS 中。它是如何工作的,應用所有者和開發者真的不需要知道,他們也不關心。所以從應用所有者的角度來看,就非常簡單,只需要啟動一個應用的部署意圖, NSX-ALB 的控制器就會自動實例化它。參見圖 7。
圖 7:生態系統整合
與自動化工具集成
NSX-ALB 可以通過 Terraform、Ansible、VRO、VRA ,或 Python 腳本輕松構建自定義策略,并通過控制器內置的決策自動化智能來完成端到端的自動化。參見圖 8。
圖 8 NSX-ALB 與應用自動化工具的集成
總結
VMware 的 NSX 高級負載均衡通過集成的策略管理器、決策智能中心、應用監控和分析、安全性、預測性自動擴展和多云部署,提供了自動化的應用交付系統,同時實現了現代化應用架構中的運維流水線。無論應用是部署在私有數據中心或多個公有云的混合環境中,都可以提供統一的架構和一致的用戶體驗,以及基于集中控制的決策自動化、執行自動化和運維自動化。
下一篇: 什么是算力網絡