雲計算引擎：按需供應服務的自動化技術

日前由BMC軟體舉辦的雲計算管理技術大會在上海舉行，會上各路專家將就雲計算願景、雲計算應用、雲計算管理、業務服務管理（BSM）等話題展開精彩探討。 以下是BMC中國高級軟體顧問邱兢先生的精彩演講：





　　其實相對於自服務門戶或者監控工具來說，自動化在雲計算裡面是比較吃虧的，因為自動化技術是隱含在雲計算平臺後面，對客戶來講即看不到自服務的介面，運維人員也無法看到非常漂亮的監控介面。 但就像大家選車一樣，車的引擎好壞往往決定了這部車的價值。 自動化之于雲計算，正如車的引擎。 接下來的時間裡，我將就雲計算裡面，BMC是怎麼通過自動化解決方案為客戶提供完整的雲計算服務進行介紹。





　　首先請大家看兩組圖，左上角是郵局，在過去沒有自動郵件分撿機時需要花大量人力做這樣的分類，這樣在一個地區裡面可能有幾十甚至上百個人專門做郵件的分類，但當90年代引入了這種郵件自動分撿機以後整個效率大大提高了， 這是自動化的好處。 第二組圖是80年代電話程式控制交換器引入前，我們打電話需要有專門的人員進行接線，一個人員只能處理十幾條線路；但有了電話程式控制交換器，今天一個通信管理人員已經能夠負責上萬家用戶線路。 所以我們可以發現，即使是在傳統行業，採用了自動化以後，首先是整體成本下降了，因為人力減少。 第二，效率提升了。 現在郵件傳達的速度，甚至我們打電話的速度，跟原來是不可同日而語的。 除此之外，對於我們作為使用者來講是一個服務體驗的改變及服務品質的提升。 這兩個是非常好的例子，告訴我們說，即使沒有IT，沒有雲計算，傳統行業也是需要有自動化技術。





今天我們講雲計算，對於一個企業來講，我們認為其實是一條曲折的道路，這裡面會經歷以下四個階段，我們稱之為雲所需具備的能力。 第一，具備單點設備的能力。 首先我需要一個基礎的架構，在這個基礎架構上面搭建一個虛擬化環境。 第二，在此基礎架構上需要具備自動化能力，能夠通過自動化的方式對相關設備進行驅動，這個設備有可能是虛擬化平臺，甚至有可能是虛擬化平臺裡面的資料庫或者是中介軟體這樣的元件級物件。 第三是整合管理能力，我們所需要的不僅是單點設備處理能力，更希望雲平臺提供端到端的管理能力。 最終我們要站在服務的角度去進行使用者需求的捕捉，其目的是能夠讓IT資源以可以讓使用者理解的方式直接提供給最終使用者。 這四個能力無論是私有雲，混合雲還是公共雲來講，都是需要的。





　　在08年雲計算剛開始在業界出現時，BMC發現所謂的雲計算思路跟BSM的概念基本是吻合的，因為雲計算相當於是BSM(業務服務管理)的一個最佳實踐。 在這個最佳實踐當中，自動化是非常重要的一個組成部分，從應用自動化，資料庫自動化，伺服器自動化，網路自動化都是屬於這種關鍵的能力，也是雲計算所需要的能力。 可能有人要問，為什麼我們需要IT的自動化，今天管理IT，如果不需要自動化也可以管理得蠻好，用了IT自動化以後可能成本還會增加。 我們從以下四個方面解釋為什麼需要IT的自動化。 首先從成本考慮，一個伺服器管理成本基本等於你去購買一台全新的物理伺服器成本的三倍。 今天我們還要在物理伺服器上虛擬多個伺服器，因此其實我們所面向的管理物件比原來更多，那麼管理成本的劇增是毫無疑問的。 第二，品質。 根據每三方機構的調查，在所有IT故障當中，有80%是因為不恰當的變更配置造成的。 在這種情況下，我們引用IT自動化手段可以把配置步驟流程化和合理化，儘量減少人為失誤。 第三，90%的問題是已知和可避免的，在IT自動化範疇裡面我們需要做一些合規檢查，能夠在問題還沒有發生之前，通過合規檢查的手段及早發現存在的一些技術風險和漏洞。 第四，應用發佈速度的問題。 今天不管是哪個行業，企業的業務系統越來越複雜，涉及的邏輯元件和相關部件會越來越多，對於企業來說應用發佈所需要的環節複雜化了，通常應用發佈所需要時間比預期超出60%。 如果沒有自動化軟體的協助，這些時間是無法縮短的。





根據我們BMC在許多自動化專案的經驗，我們總結出一個企業在邁向自動化運維過程當中，可能會有四個階段，分別為標準化，腳本化，產品化和服務化。 標準化的意思是說，在這個階段，企業可能意識到我需要有一些IT操作的流程，雖然我沒有一些自動化的工具，但是我可以通過人，通過文檔的方式把IT日程的操作固化下來形成一個標準。 這樣以後涉及到相同類似操作的時候我們沿用這個標準來進行操作的執行。 第二個階段是腳本化，當我有了標準化以後，之前所設定的一些簡單標準化IT操作流程可以通過腳本實現，這種情況下可以讓內部的IT人員寫一些腳本，再派人定期去運行一些腳本，或者利用crontab自動運行腳本。 進入第三個階段，當腳本使用越來越多的時候，企業會考慮到我要引用一些產品進來，可能是針對伺服器的自動化，可能是針對桌面機，可能是針對網路的自動化。 第四個階段是服務化。 服務化更多是指雲計算當中的自動化概念，在這個階段自動化不僅僅面向IT運維的部門，而是通過自動化把IT資源便利地交付給最終使用者，這個我們稱之為服務化的概念。 對於大部分企業來講，不一定一定會經過這四個階段，但是基本上會經歷這些事情，有可能是三個階段有可能是兩個階段，但是你該做的這些事還是需要去做的。





第一個階段我們稱之為標準化階段，哪一些東西我們可以把它標準化流程化呢？ 我們在銀行的客戶比較常見，就是每天做巡檢。 早上來了以後要安排一個人員登入到每一台伺服器上面去，敲一個指令或者多個指令查看系統的狀態，或者有時候沒辦法做正常監控的時候，可能要看一下應用系統設定檔的情況是怎麼樣的，這些都屬於日常的操作。 另外還有一個例子，我們經常會有一些業務系統的升級，一般來講，一套固定的業務系統，我升級步驟基本是固定的，從做資料庫的欄位表修改，到應用的檔分發，或者檔的解壓等等這些都是標準化流程。 企業會把這些東西作為IT的流程固化形成一個文檔，交給下面的人去做。 首先在不考慮其他情況下，不考慮人力成本，不考慮出錯的情況下，我們認為這已經比完全沒有流程要好。 但我們可以算一下工作量。 比如今天有200台伺服器可能是一個中型企業需要管理的，以我們做日常巡檢為例子，一個人需要登入一台伺服器查看設定檔，登入一台機器需要花兩分鐘時間， 200台伺服器共花6.7個小時，如果每天都安排一個人去做這樣的事情，每週需要耗時33.5人時，或3.5人天，每年需要182.5人天。 這還僅僅是一項檢查，而我們常常可以看到，客戶的這種巡檢清單往往長達上百個。 當我的巡檢範圍更多的情況下，我們耗的人天會更加大。





　　所以在第二個階段，我們可以看看剛才的問題有沒有可能通過腳本來實現。 這裡是一個很基本的腳本代碼，把這個腳本到那台機器上運行之後去採集一個資料，接下來對檢查結果進行輸出，貌似用腳本的方式可以把時間成本降低了，因為我只要把這個腳本發下去，最後回收上來一個回饋值，我就可以完成工作了， 大不了我把這個值再拿一個表記下來。 但是使用腳本會有什麼問題呢？ 第一，腳本應該怎麼樣進行定向發佈，剛才我講的只是一個通用腳本，但是很多時候，我們的伺服器組是按照我業務系統類型進行劃分的，我需要去檢查的這些項並不是保證我每一台伺服器都是一樣。 第二個問題，這個檢查要求變了怎麼辦，我們還需要派人專門去修改特定的腳本。 所以我們使用腳本程式存在三大問題，第一類是不安全性。 腳本是以明文出現的，包括你需要登入的話要有使用者名/密碼，另外會摻雜其它訪問資訊。 第二是難維護，當你進行修改的時候，你怎麼來維護腳本。 第三部分是難管理。





所以在第三階段，企業考慮我能不能引用一些業界成熟的產品。 這個圖上我們以應用發佈為例，基本來講，我們會涉及到四個團隊，首先業務系統會有應用開發的小組進行一個應用系統的打包，打完包在真正把的業務包部署到生產環境之前需要做一些驗證，這是由我們測試或QA部門來完成的， 接下來當這些包已經發下去以後，運維團隊要進行維護，這個維護除了要維護業務系統以外，還要保證你現有伺服器系統本身上面作業系統版本是能夠按照你的應用系統要求進行升級的。 第四部分安全的管理團隊可能也需要定期做檢查。 通常來說，如果是一些產品化的話，我們會引用不同產品。 但BMC我們提供的是一整套的自動化管理的平臺，它能夠把我剛才講的這幾個方面，從OS到資料庫到中介軟體到應用，從發佈到控制等的所有環節在一個平臺上完整的去實踐它。





　　自動化層面上我們會涉及包括從底層網路設備自動化；第二，伺服器自動化，無論是物理的伺服器，或者虛擬化平臺；第三是資料庫的自動化；另外是中介軟體自動化以及應用自動化。 接下來再做一個對比，我們做一個業務系統上線，下面是傳統用手工的方式去做的，上面是通過BMC自動化軟體去完成的。 首先可以看到，在手工階段，可能是由一個業務系統的使用者提出這麼一個變更要求，一個新的業務系統上線我們需要去購買伺服器，即使今天不去購買物理的伺服器也需要去部署一個虛擬的伺服器，這樣我就需要有專門人去做。 接下來交給網管，按照企業本身的要求，把指定的IP綁定，把我的伺服器接入到網路當中去。 接下來伺服器要放到生產環境去，需要打補丁，需要有專門的技術人員做伺服器的加固。 前面三部分完成之後才是業務系統的部署，專門一個人來做業務系統應用的部署。 最後企業考慮到，可能這個系統面向的使用者量比較大，還需要增加一個Load balance。 在真實的企業環境中，當然不是每個環境同一個人，也許是同一個人做不同的事，但是整個過程耗時是比較長的，需要從底層基礎到應用。 通過BMC自動化，我們可以實現：首先使用者提出這麼一個變更要求，自動化管理軟體可以通過操作流程的邏輯調度把它串聯起來，當這個步驟失敗的話，應該怎麼處理，通過這樣一整套平臺讓業務系統能夠快速上線。 當然講到這裡，其實我們還沒有到雲，這是在自動化管理的階段。





第四個階段，也就是雲計算的階段，我們稱之為服務化，自動化是面向服務的。 自動化管理所對應的是資源管理，首先資源管理主要分為幾大塊，一個是伺服器和應用自動化，另外網路上面我們可以直接對物理的網路設備做配置。 再一個是資料庫的自動化，在雲環境當中部署相應資料庫的軟體。 包括對於存儲，可以直接到存儲物理的層面上對它進行空間劃分。 BMC的Cloud Lifecycle Management能夠支援業界主流的平臺和系統，如VMWare、XEN等主流的虛擬化平臺。 對於網路這塊我們開箱支援思科網路設備。 在存儲方面我們支援Netapp等。 這些都是對於現有主流產品的支援。 將來怎麼辦呢？ 我們可以看到在資源管理這裡我們有供應者API，這個API是BMC留給將來更多廠商的一個介面。 如果對於客戶新增加的設備，可以利用API來對它進行支援，通過API你可以調用協力廠商設備的專業管理平臺來進行統一管理。 第二，雲平臺管理員服務藍圖，這是把服務的定義轉化為真正的IT部署。 在部署當中，我可以部署在單台的VM或者兩台的VM，除了在VM裡面安裝作業系統外，接下來VM是要接入到網路層面去，我們會在網路層面上通過虛擬的網卡進行配置，這裡面做的事情遠遠不像我們看到的那麼簡單， 它在底下做了很多自動化的操作配置。 第三，端到端的自動化的部署。 在我們方案裡面，我們進行作業系統部署和應用部署，並且提供作業系統的加固。 什麼是加固呢？ 當你完成這些應用部署以後，你需要去做一些合規檢查，這些都是在部署過程當中完成的，所以我們稱之為端到端，而不是僅僅停留在某一個層面上。 第四個特性我們可以按照服務等級進行資源配置。 比如在一個製造行業，今天要用雲計算，我可能要把兩個業務系統放到雲計算裡面來，一個是OA系統，一個是面向外面使用者的網站。 我們的策略引擎是通過標籤的技術，當業務系統部署前要選擇一個服務的級別，它會根據服務等級的判斷該業務系統應該放在哪一個預先定義好服務等級的資源池，然後調用資源管理模組完成真正的部署。





我們網路自動化的配置可以根據多租戶進行劃分，，在網路部署上會做Vlan的自動劃分，保證不同租戶的資料流程在不同的Vlan中。 另外，CLM自動化網路部署的時候，不光配置路由器交換器，同時也支援像防火牆、負載均衡這一類設備。 這個我們稱之為在實體層面上保證多租戶使用者資料的安全。 第二個跟安全相關的是，當我的業務系統進入到雲平臺以後，其實它是需要定期做合規檢查的，一個是本身系統級別補丁的合規，另外業務系統本身由於公司制度所要求也需要有一個合規的檢查。 這時候對雲管理平臺的自動化要求就不僅僅是軟體或作業系統部署，而具有合規檢查的能力。 所以，從這兩個方面保證了使用者雲計算平臺的安全。 一個是應用層面一個是網路實體層面。





　　接下來介紹兩個案例，第一個案例是服務自動化的案例，客戶是摩根士丹利。 在業務需求方面，由於摩根史坦萊有兩個服務中心，他們發現在業務系統的升級過程中，首先，需要花人工去做的時間比較長，沒辦法保證業務的連續性；第二，人工去做有時候會有一些失誤造成計畫外宕機。 所以在這種情況下，他們經過了多方比較，最後選擇了BMC的Bladelogic解決方案，通過Bladelogic説明他們提高了員工效率，估計每年節省27萬美元。 第二個案例是公共雲的案例，客戶是澳洲電信，使用CLM後，澳洲電信日常操作和安裝任務所花的時間從天降到分鐘級。





　　每個企業的IT願景是不同的，在座各位無論你們目前是處於自動化的第一階段還是第二階段，或者希望往第三階段，第四階段邁進。 BMC作為業界自動化領先的廠商，我們希望通過豐富的解決方案和專案當中大量豐富的經驗，能夠給大家提供更多的支援，能夠為大家實現IT管理目標作出我們最大的努力，謝謝。

(責任編輯：蒙遺善)