將此篇文章跟 Facebook 上的朋友分享將此篇文章跟 Plurk 上的朋友分享將此篇文章跟 Twitter 上的朋友分享列印轉寄
2018/8/2

地端控管配置延伸到雲端 一致性政策簡化維運複雜度

授權模式貼近雲端服務 補強南北向負載平衡

羿漣
快速演進中的雲端原生應用與微服務開發架構,部署建置環境大多採以多雲平台,已內建負載平衡功能,促使ADC技術必須跟進整合,以應用為核心補強自動化機制的能力,同時確保可用性與安全性。
Radware雲端架構師詹凱富觀察,台灣已經開始採用雲端服務的企業,主要是營運業務的特性為對外提供顧客服務,至於既有用於提高效率的內部系統,至今仍難以遷移到雲端平台,多數障礙即在於機敏資料。「會被選擇建置在公有雲運行的系統類型,首先是非關鍵任務,其次是有高度運算需求,典型的案例即是人工智慧與機器學習演算法,這類應用需要建置龐大運算、儲存資源,採用雲端平台不僅可符合需求,同時也降低成本。至於AWS、Azure之所以在台灣廣受歡迎,關鍵因素在於IT人力不足的中小型企業,採用公有雲服務更具成本效益。」

全域彈性許可證以吞吐量配置授權

然而,即使建置在雲端平台的是低機敏與高運算系統,同樣會面臨負載平衡的需求。對此,雖然公有雲服務供應商已內建提供,且成本又低,可惜僅能提供最基本功能,這正是ADC解決方案發揮的機會,因此幾乎全數廠商皆採以Virtual Appliance在主流公有雲線上商城中提供訂閱服務。尤其是現代化DevOps團隊相當看重的持續整合/持續部署(CI/CD),須盡可能縮短發布上線須耗費的時間,即可以內部自建Radware Alteon為基礎,搭配訂閱Radware雲端服務,讓設定配置具一致性,建立自動化運行模式。 在公有雲線上商城中提供的Radware虛擬主機服務,透過訂閱即可啟用,對此Radware發展出集中化授權機制,可幫助客戶節省成本。詹凱富舉例,多數企業採購伺服器負載平衡,會依照需求開出規格,例如至少必須具備10G吞吐量,但當資料量快速增長,原本的10G須增加到20G吞吐量才足以因應,此時再添購更高規格機種,恐浪費了原有的投資。

「Radware可說是所有ADC廠商中首家提出統一授權的商業模式,以公司為單位,提供最小1G、最高400G吞吐量的選項,讓客戶可依照實際應用需求選擇軟體版本或硬體設備的建置。稱為Alteon全域彈性許可證(Global Elastic License,GEL),軟體版本的資源配置只要動態調整即可,至於硬體建置,則會提供未綁定任何授權限制的設備,凡是在硬體本身可承載的範圍內均可配置用量。」詹凱富說,當然只要是實體建置皆有其擴充極限,萬一真的必須更換高規格機種時,舊設備的授權則可回收,配置到其他設備繼續使用,不至於浪費既有投資。

維運工作App化簡化操作縮短學習曲線

▲ Radware雲端架構師詹凱富觀察,亞太區採用雲端平台的驅動力之一在於降低IT成本,如此思維下,即可透過全域彈性許可證機制,以最低成本的解決方案提升新興應用架構的控管能力。
降低IT成本開支可說是推動全球企業遷移上雲的重要力量,此現象也反映在開放原始碼被廣為接受與採用。詹凱富說明,針對內部應用遷移到公有雲平台,除了前述提到的低機敏、高運算需求,同時也包括已開始採用開放陣營技術的微服務架構的應用系統。

傳統應用系統為多層式架構,至少會具備前端操作介面、商用邏輯程式、資料庫系統,最終都需要跟後端資料庫溝通存取。自從雲端運算出現後,更適合運行於雲平台的微服務開發方式打破多年來的應用系統架構,對既有的ADC而言,可說是相當大的挑戰。他進一步說明,ADC主要服務的架構為傳統應用系統,根本無法直接套用在新興的微服務架構,如何跟進支援與整合運行,可說是ADC廠商的重要課題。更何況Kubernetes、Open Foundry、Mesos等開源社群維護的平台,皆已內建提供容器環境的負載平衡功能,未必會繼續有ADC的需求。

詹凱富引述IDC調查統計,2016年傳統三層式應用系統架構為80%,另外20%是新的雲端原生應用系統,預估持續發展到2020年,將會呈現各佔一半的態勢。應用系統架構演進到雲端原生,首先會面臨的問題是體驗品質不穩定,畢竟台灣主流的公有雲服務供應商,多未在島內建置資料中心,網路延遲時間與海纜傳輸速率息息相關,若連線品質無法得到完整保障,雲端原生應用所提供的服務也就難以確保品質。另一方面,在網路攻擊威脅持續增長之下,雲端原生應用系統更須建置防範滲透與DDoS攻擊威脅,以免影響用戶體驗,導致業務損失。

其次則是IT基礎架構的更迭演進速度加快,新與舊技術混雜之下維運複雜度較以往更高,增加勞動密集型的操作,例如為避免SSL憑證過期,導致網站連線失效,維運人員須定期逐台登入檢查,相當耗時費工。

Radware設計提供的Operator Toolbox工具包,可把諸如此類日常維運重複性高的工作打包成App,當用戶需要部署新的應用服務,透過操作介面以點選方式,輸入相關參數值,即可完成配置。例如IT人員可點選SSL憑證檢查的App,在功能項目中選擇所有Alteon設備,即可自動爬找相關資訊,藉此來提高維運效率。此外,當IT人員頻繁異動,擔心技術無法傳承時,可透過Operator Toolbox工具包,讓資深技術人員依照經驗知識增添控管機制,以縮短新進人員學習曲線,同時簡化無效率的維運操作。

KAP補強南北向負載平衡機制

針對微服務架構趨勢,Radware亦有發展出整合Kubernetes方案。詹凱富說明,在DevOps工作模式環境採用容器技術實作,常見的工具為Docker、Rocket,Kubernetes則負責管理調度(Orchestration)多個容器組成的Pod,此型態又稱為容器即服務(CaaS),可運用免費的Ingress負載平衡機制,讓Kubernetes負責配置Node連接埠東西向的通訊。

「東西向的通訊或許不須ADC協助,但若為南北向連線傳輸,也就是要發布應用服務供外部用戶端存取,Kubernetes公布的是實體伺服器介面設定的IP位址,萬一發生故障,必須手動切換到另一台IP位址,因為欠缺南北向的負載平衡機制,此時即需要ADC協助。在DevOps工作模式環境中,開發人員撰寫完應用服務後,須通知IT人員在ADC系統上發布該服務的IP位址,才開始對外提供服務。」

Radware是運用最新發展的KAP(Kubernetes Automation Plug-in)管理元件執行,作法是基於Kubernetes發布的Frontend IP位址或主機名稱,以及提供的連接埠,執行Workflow,依據KAP設計的圖形化配置步驟輸入相關參數,即可完成Alteon的部署,補強欠缺的Layer 4到Layer 7控管機制,確保安全性與遞送效能。

這篇文章讓你覺得滿意不滿意
送出
相關文章
跨雲容器傳輸 ADC新契機
全軟體ADC展累積功力 助DevOps實作自動化
架構計費隨應用演進 延伸舊設備免重新學習
挾專精強項補雲端弱點 ADC伴企業轉型架構
穿透SSL迷霧 為DevOps打底
留言
顯示暱稱:
留言內容:
送出