以應用為中心的企業混合雲管理

 
嘉賓簡介  

徐桂林

• FIT2CLOUD 總監，負責公司的技術佈道和生態合作。

• 在此之前先後供職於意法半導體、Autodesk和阿里雲。

• 熱衷於雲端計算（尤其是公有云IaaS平臺），有過多年AWS的生產環境工作經歷，是較早在國內分享AWS上實踐經驗的作者之一。

演講實錄  

 

隨著網際網路和移動網際網路的深入普及，傳統商業執行模式正在被深刻影響甚至變革。現在，越來越多的網際網路企業利用其強大的IT服務能力快速切入傳統商業的方方面面，影響著人們的各種日常決策。而傳統企業也在不斷加強其IT服務能力，並寄於此來完成組織的轉型和升級。所以，企業IT服務能力已經成為當代企業的核心競爭力之一。如果重新審視現如今的企業IT，會發現支撐企業IT服務能力的基礎設施正在發生一個巨大變化，即企業IT基礎設施已經進入一個全新的專業雲時代。具體來說：

• IaaS已經成為新常態，企業的IT基礎設施形態已經從傳統的物理機和虛擬化環境轉向IaaS平臺。

• 混合雲成為專業雲時代的主流。企業級雲基礎設施普遍選擇混合雲形態（公有云與私有云的混合），以滿足企業資料安全、業務合規以及成本考量等多方面的要求。

類似於在傳統IT時代企業需要IT管理平臺（以ITIL為代表）一樣，專業雲時代的IT管理需要全新的雲管理平臺（Cloud Management Platform），來適應IT基礎設施全面雲化的需求。

在過去十年裡，雲端計算從一個概念迅速發展成為一個大家普遍接受、並廣泛應用於實際生產中的新型IT基礎設施。尤其是在公有云IaaS領域，以AWS、阿里云為代表的廠商都取得了令人矚目的成就。隨著越來越多傳統企業接受雲端計算並開始實施企業雲戰略，專業雲時代也已經到來。根據RightScale的最新報告（如下圖），目前1000人以上的大企業基本都已經有了明確的企業雲戰略，而這其中有超過八成會選擇多雲平臺方案（其中混合雲佔比超過半數）。

如上圖所示，企業多雲和混合雲策略成為主流選擇，而這些企業自然會有云管理（尤其是混合雲管理）的迫切需求。對於這些企業CIO或者IT經理來說，新型雲管理平臺一定要能夠支撐企業採納雲的初心，即促進業務創新，而不是使用傳統的IT方式把雲平臺做為一個新的資源池簡單管理起來。所以，企業需要一個全新的視角來擁抱雲管理平臺，即圍繞業務團隊（DevOps團隊）構建混合雲管理方案，也就是以應用為中心的混合雲管理平臺。

一個以應用為中心的企業級混合雲管理平臺主要解決的問題是如何讓業務團隊（即DevOps團隊）更高效地使用好混合雲基礎設施，並以此促進業務發展和創新。為此，其需要解決以下幾個主要問題。

問題一：如何統一管理不同來源的IT資源

如前所述，混合雲已經成為企業雲戰略的首選，這意味這企業雲資源的來源會多樣化（如下圖）。除此之外，企業還有大量的歷史遺留基礎設施（包括物理機器以及虛擬化環境等），這會使得企業IT資源的來源更加碎片化。

所以，如何統一管理不同來源IT資源並集中交付給業務DevOps團隊使用就會成為一個新的挑戰。具體來說，企業需要解決如下幾個問題：

• 如何統一管理公有云主機、私有云主機和物理機？

• 如何以應用視角管理基礎設施？

• 如何整合雲API，實現自動伸縮？

企業級混合雲管理平臺只有解決了以上幾個基本問題才能實現對於不同來源基礎設施進行標準化無差別管理，同時還能夠充分發揮雲平臺帶來的彈性資源交付優勢。

問題二：如何為業務團隊提供自助式IT

自助式IT是一個傳統IT環境下就存在的概念。但是傳統自助式IT基本都是通過工單方式提供服務，並不能夠做到實時全自動化交付資源給業務團隊。由於雲平臺資源的可程式設計化，雲上自助式IT已經真正可做到實時全自動化的交付資源。進入專業雲時代，通過混合雲管理平臺提供真正意義上的自助式IT成為充分釋放雲生產力，支援業務團隊更好進行業務創新的關鍵所在。具體來說，企業雲管理平臺需要解決以下幾個問題：

• 如何實現十五分鐘內交付虛機、一個小時內交付完整業務叢集？

• 如何支援虛機及叢集的全自動初始化？

• 如何提供豐富的自定義虛機及叢集模板？

現在，主流公有云供應商基本都在產品級別解決了上面這些問題。所以，企業級混合雲管理平臺必須能夠在企業內部完整解決這些挑戰，才能在不影響業務DevOps團隊日常開發效率的前提下過渡到企業的混合雲解決方案中。

問題三：如何高效運維越來越多的虛機

隨著網際網路+浪潮的逐步深入推進，企業IT系統承載的業務會越來越多，也越來越重要。這也意味著需要更高效的運維方式管理越來越多的IT基礎設施，尤其是需要管理日益增多的虛機。同樣來自於RightScale 2015年的報告，大部分企業的虛機數量已經超過50臺（如下圖）

一般來說，超過50臺虛機的規模意味著傳統手工運維管理已經很難保證效率和質量。這時候企業日常運維管理就會經常遇到如下這些常見的問題：

• 如何同時給1000臺虛機打補丁？

• 如何實現端到端的監控？

• 如何實現故障自動修復？

要解決企業IT基礎設施規模增加帶來的運維挑戰，自動化成為現代運維管理系統普遍的選擇。這就要求企業級混合雲管理平臺能夠幫助企業落實自動化運維的一系列最佳實踐。

問題四：如何支撐DevOps團隊實現持續交付

現如今IT系統的交付週期越來越短，而且還需要在持續交付的過程中保證服務的高可用和效能的高穩定。但是，整個IT系統的持續部署和交付流程需要一個較長的流程。例如，下圖就是一個典型的從程式碼到最終服務的流程。

在這過程中，企業會遇到以下阻礙整個持續交付流程順利進行下去的常見問題：

• 如何建立統一的Artifact倉庫?

• 如何保證測試環境和生產環境的一致性？

• 如何實現部署後快速反饋？

企業在實施IT系統持續交付過程中經常會因為未解決以上常見問題而導致最終的持續交付流程流於形式，未能達到支援業務創新的目標。企業級混合雲管理平臺需要能夠為此提供足夠好的支撐工具，幫助團隊解決以上常見問題並能融入的日常雲管理中。

針對如上幾個問題， FIT2CLOUD提供了以應用為中心的混合雲管理及DevOps協作平臺（結構圖如下），希望寄與此幫助企業更好地管理好混合雲並充分釋放雲的能力，達到促進業務創新的目標。

如果從技術架構角度看，整個產品的架構圖如下：

如上圖所示，FIT2CLOUD是典型的傳統的C/S架構。在服務端，整個系統包括訊息引擎、管理控制檯和REST API組成。客戶端則有一個非常輕量級的客戶端Agent（基於Python開發）。客戶端和服務端直接通過Message Queue保持通訊。具體功能如下：

 

– 服務端：提供介面（Web或者API）供使用者管理使用，對接不同雲平臺申請、釋放和查詢雲資源，向客戶端傳送訊息命令，接受客戶端上報資料（監控資料，命令執行結果等），處理並儲存所有需要長期儲存的資料（包括監控資料、操作日誌、使用者配置資料等）

 

– 客戶端：主要負責接受服務端命令並執行操作、按要求向服務端彙報資料。

 

對照前面提到的幾個基本問題，我們希望能在我們的平臺中逐一解決。首先，針對企業IT基礎設施碎片化的問題，我們希望通過一個大管理平臺加不同外掛的方式解決這個問題。換句話說，我們平臺定義一套外掛介面框架，然後針對不同的雲平臺按照這個介面框架封裝其API。這樣，管理平臺和不同雲平臺就能夠解耦，讓外掛來適配不同雲平臺的差異性。從使用者的角度看，你需要對接哪個雲平臺，指需要安裝、配置一下這個雲平臺的外掛就可以了，如下圖：

我們這個外掛框架做得還不錯，如果你有新的雲平臺對接，只需要按標準開發一個外掛，然後安裝到系統內就能管理該雲平臺上的資源了。

具體來說，每個雲平臺外掛內部主要包括下面幾個方面的功能：

1）封裝對於雲平臺提供的API和SDK，例如虛機生命週期的管理（建立、停止、啟動、刪除等操作），還有各種雲資源的查詢、更新及配置操作。

2）對雲管理平臺提供一致性的介面，遮蔽掉不同雲平臺API不一致的地方。

如果你對於我們的外掛框架感興趣的話，可以參考我們的線上文件（http://docs.fit2cloud.com/v1.1/plugin/architecture-overview.html），裡面有現成的例項程式碼和介面說明。

在解決了雲平臺資源對接後，為了相容歷史遺留主機（以及已經存在的雲上主機），系統還提供了“匯入主機”的功能。這樣就能夠讓已經存在的主機資源也得以加入到系統進行管理。

為了給業務團隊提供足夠方便的雲上自服務能力，FIT2CLOUD系統提供了雲平臺的虛機建立模板功能（如下圖），使用者可以按照自己的需求把常見的虛機模板提前定義好，需要時候直接啟動，甚至利用FIT2CLOUD平臺提供的自動伸縮功能按需求自動啟動或者釋放。

但是，如前所述，一個簡單的虛機建立模板是不足以滿足使用者自服務IT的要求。使用者需要的是從資源申請，初始化、應用部署到上線服務的整個鏈條自動化。所以，FIT2CLOUD還可以在設定虛機建立模板的時候指定初始化操作、程式碼部署以及掛載負載均衡器等各種設定。例如，下圖就說明當虛機啟動後能夠自動部署應用的指定版本。

接下來講講FIT2CLOUD如何看待業務運維管理這個事情。在雲環境下，企業運維管理一個最大的變化在於企業基礎運維（機器、網路及儲存）已經被雲供應商服務化並通過SLA來保證其服務的質量，企業運維的核心變成了應用運維。所以，FIT2CLOUD對於企業運維的觀點就是一定以應用為重心來操作。這其中包括：

1）所有基礎設施資源都以應用視角來組織管理和展示，通過“叢集/虛機組/虛機”三層概念對應一個業務應用常見的“應用/層/例項”這個技術架構。

2）所有監控資料都以應用視角進行展示（如下圖），使用者可以在一個介面看到叢集、虛機組和虛機的監控指標，並能夠drop-in和drop-out。

3）運維人員的日常運維工作也以應用視角執行，方便運維人員按照應用來執行批量指令碼等運維操作，並且結合告警集中提供“自動修復”功能。

4）自動伸縮是雲上最為重要的運維管理工具，對應於傳統運維中的“擴/縮容”操作。如果你的應用已經能夠做到“狀態無關”，那這個工具一定是你最好的幫手，可以大幅度降低日常運維的工作量，而且還能夠保證運維的質量。FIT2CLOUD的自動伸縮優勢在於基於自己的Agent上報的監控資料獨立實現，不會被任何雲平臺提供的自動伸縮服務所繫結。現在，FIT2CLOUD提供兩種模式的自動伸縮功能，定時伸縮和情景伸縮（如下圖）：

總結來說，以應用視角為中心，結合各種自動化、批量工具來幫助使用者提高運維效率。

最後，來說說如果提高團隊的持續交付能力。首先，我把FIT2CLOUD推薦的持續交付架構圖展示如下：

通過上面的圖，讓我們看看FIT2CLOUD如何解決前面提到的幾個問題。

1）關於統一Artifact管理的問題，現在已經有很多非常好的開源或者商業軟體，而且都和如Jenkins構建環境對接好了。保證每次構建出來的Artifact（製品）都能夠準確無誤的保持到製品庫內部。同時，為了方便雲上使用者，FIT2CLOUD還支援使用阿里雲OSS和AWS的S3作為製品庫來儲存製品。並且提供了Jenkins到OSS的外掛（Jenkins到S3的外掛已經有開源版本）。

2）為了保證不同環境上的部署流程自動化、標準化。FIT2CLOUD提供相容AWS CodeDeploy標準的“程式碼部署”功能。使用者只需要按照這個標準在構建時候打包元件，就可以利用FIT2CLOUD完成在不同環境裡面的自動部署。AWS CodeDeploy標準就是亞馬遜內部自己使用的程式碼部署標準，其所有服務都是基於此部署。在去年，亞馬遜基於此標準完成了5000萬次的部署。所以，這個標準無論是從靈活性，還是穩定性都是經過了考驗的。

3）為了打通從構建到部署的流程，FIT2CLOUD提供了Jenkins For FIT2CLOUD外掛。當jenkins構建完成一個版本後，會把相應的製品上傳到製品庫的同時把相關資訊自動註冊到FIT2CLOUD中，這樣，FIT2CLOUD就可以在系統內部使用改版本進行部署。這樣就徹底打通了從構建到部署的流程。

基於上面這些功能，FIT2CLOUD已經能夠完成從程式碼check-in到部署服務整個鏈路，非常有益於業務團隊提高部署效率，實現持續部署。

本文來自雲棲社群合作伙伴”DBAplus”，原文釋出時間：2015-12-16