以云計算的速度部署云計算基礎(chǔ)設(shè)施
譯文為了以最終用戶所需要的速度部署新的基礎(chǔ)設(shè)施,企業(yè)IT部門需要擁有基本模塊架構(gòu)和真正DIY功能的可視化自動化工具。
云計算的兩個主要價值就是速度和靈活性。云計算編排和自動化工具有望讓IT部門大大加快運營速度,并且成為更具競爭力的服務(wù)型部門。雖然一旦虛擬化系統(tǒng)落實到位,編排工具在靈活地部署應(yīng)用程序方面通常做得很到位,可是遺留的非虛擬化底層基礎(chǔ)設(shè)施其靈活性或自動化程度不是很高。人們沒有正面解決這個問題。相反,許多人把精力放在了解決物理基礎(chǔ)設(shè)施問題上,試圖獲得靈活性時,這就成了致命弱點。不過,可以避免這種情況。
為什么基礎(chǔ)設(shè)施靈活性至關(guān)重要?
企業(yè)IT部門面臨許多方面的壓力:上頭下達的任務(wù)、預(yù)算、用戶期望以及與競爭對手之間的差距。
首先,這是個不言而喻的現(xiàn)實:企業(yè)IT部門面臨的任務(wù)正在迅速轉(zhuǎn)向支持靈活創(chuàng)新。不過,預(yù)算并沒有相應(yīng)增加,幫助IT部門滿足這個要求。根據(jù)知名調(diào)研機構(gòu)Gartner的《2014年CIO議程報告》的調(diào)查結(jié)果顯示,全球CIO聲稱,2014年累計的IT預(yù)算增幅只有區(qū)區(qū)0.2%。
原因可是帶來壓力的另一個方面:用戶要求IT部門提供IT消費化,這促使用戶從別處獲取服務(wù)。在Gartner的同一份報告中,有CIO聲稱,25%的IT開支出現(xiàn)在IT預(yù)算外面――這僅僅是他們所看到的。換句話說,企業(yè)的IT部門將“市場份額”拱手讓給了公共云計算服務(wù)。
一方面是幾乎立馬就能提供的公共云資源,另一方面是傳統(tǒng)IT流程交付的速度較慢的服務(wù),這種競爭差距或許可以解釋這種轉(zhuǎn)變。據(jù)企業(yè)管理協(xié)會(EMA)的《2014年軟件定義數(shù)據(jù)中心》研究顯示,47%的企業(yè)自稱,為應(yīng)用程序開發(fā)人員和測試人員部署基礎(chǔ)設(shè)施所需的時間短至一星期、長達一個月。
基礎(chǔ)設(shè)施交付時間
來源:企業(yè)管理協(xié)會(EMA)的《2014年軟件定義數(shù)據(jù)中心》報告。
相比只需要短短“幾分鐘”就能獲得公共云資源,這個競爭差距相當大。當然,并非一切都會很快向公共云轉(zhuǎn)移。在將來,會有好多基礎(chǔ)設(shè)施事務(wù)需要IT部門處理好,不過提高標準對IT部門來說有百利而無一害。
物理基礎(chǔ)設(shè)施仍是云靈活性面臨的一大障礙
云計算及相應(yīng)云計算自動化的兩大原則就是,所有的基礎(chǔ)設(shè)施變成虛擬化;擁有對自動化友好、***是代表性狀態(tài)傳輸(REST)式樣的應(yīng)用編程接口(API)。這無疑是一種大有幫助的、簡化操作的愿景。這讓人們有可能將“基礎(chǔ)設(shè)施變成代碼”,因為一切都是抽象處理的、軟件定義的、可編程的。
這個愿景方面鼓舞人心的主要例子有Netflix等大規(guī)?;ヂ?lián)網(wǎng)公司,它們的業(yè)務(wù)運營有賴于亞馬遜網(wǎng)絡(luò)服務(wù)公司(AWS)等提供商提供的公共云基礎(chǔ)設(shè)施。遺憾的是,大多數(shù)企業(yè)組織的歷史不像這些互聯(lián)網(wǎng)公司那么短,也沒有似乎無限制的IT預(yù)算;對它們來說,IT基礎(chǔ)設(shè)施的實際現(xiàn)狀可能顯得相當混亂。據(jù)NTT通信公司在2013年的一項調(diào)查顯示,58%的CIO表示,阻礙自己采用云計算的***障礙之一就是,現(xiàn)有系統(tǒng)錯綜復(fù)雜。任何已經(jīng)存在了10多年的IT部門擁有沒有虛擬化的遺留基礎(chǔ)設(shè)施,這些基礎(chǔ)設(shè)施可能不會在短時間內(nèi)馬上消失。
物理基礎(chǔ)設(shè)施的現(xiàn)狀影響著IT取得類似云服務(wù)的靈活性,這體現(xiàn)在幾個不同的方面:
•零日部署。如今,大多數(shù)企業(yè)在IT基礎(chǔ)設(shè)施方面的投入仍然側(cè)重私有云,而IT團隊購買基礎(chǔ)設(shè)施設(shè)備的方式已發(fā)生了翻天覆地的變化。以前的方法是,購買計算、網(wǎng)絡(luò)、存儲和虛擬化這每個類別的同類中***解決方案,然后自行把這些部分集成起來?,F(xiàn)在,人們越來越追捧VCE Vblock等融合型基礎(chǔ)設(shè)施產(chǎn)品、EMC VSPEX等參考架構(gòu),甚至Nutanix或最近宣布的VMWare EVO:RAIL等超融合型解決方案。融合型基礎(chǔ)設(shè)施、參考架構(gòu)和超融合型解決方案具有諸多優(yōu)點,包括:它們本身已經(jīng)過集成、測試和兼容性認證,能夠達到某些性能基準,或者支持一定數(shù)量的虛擬機或桌面。這為企業(yè)的IT部門減輕了扮演系統(tǒng)集成商的壓力。然而,即便有了集成的產(chǎn)品,搭建基于這些產(chǎn)品和架構(gòu)的小型集裝箱式數(shù)據(jù)中心(pod)所需的零日配置也絕非易事。這通常需要多個領(lǐng)域的專家協(xié)同工作,針對某一個特定的部署場合來進行手動配置。這往往需要一到三個星期的時間。如果不是那么浪費人才,如果這么長的配置和部署時間與公共云提供商的解決方案不是相差甚遠(可以在短短數(shù)分鐘內(nèi)構(gòu)建好虛擬機),那這很好。
•供應(yīng)鏈??紤]到部署時間方面與公共云服務(wù)提供商之間的競爭差距,有必要強調(diào)一點:私有云基礎(chǔ)設(shè)施的部署與供應(yīng)鏈確實密切相關(guān)。如今的大多數(shù)數(shù)據(jù)中心基礎(chǔ)設(shè)施是通過分銷和系統(tǒng)集成渠道而購買的。究其原因,那是由于,即使我們假設(shè)分銷商保持充足的庫存量(在適時物流世界),那樣根本不存在設(shè)備制造商發(fā)貨引起的滯后時間,分銷商或系統(tǒng)集成商通常不得不執(zhí)行某種程度的配置工作。我們也別忘了,IT產(chǎn)品分銷行業(yè)靠相對較薄的利潤來運作。因此,雖然利潤豐厚得多的制造商有許多高度專業(yè)化的人才,但分銷渠道擁有的這方面人才比較少。這就意味著,如果配置工作需要專家們在房間里待三星期,可供調(diào)派的專家就比較少。然后,哪怕IT企業(yè)的小組只是想及時收到基礎(chǔ)設(shè)施,供應(yīng)鏈也會成為一大制約因素。如果企業(yè)的IT部門受到反應(yīng)迅速的公共云/影子IT這個競爭對手的威脅,那么供應(yīng)鏈也受到威脅。
•基礎(chǔ)設(shè)施即服務(wù)。構(gòu)建私有云或混合云基礎(chǔ)設(shè)施即服務(wù)(IaaS)解決方案時,許多IT部門面臨這個事實的挑戰(zhàn):它們必須處理物理基礎(chǔ)設(shè)施資產(chǎn),比如非虛擬化/專用服務(wù)器、網(wǎng)絡(luò)交換機和遺留的非虛擬化存儲陣列。這些資產(chǎn)的存在絕對不是什么小事。比如說,EMA的軟件定義數(shù)據(jù)中心研究發(fā)現(xiàn),83%的IT部門在專用服務(wù)器上運行應(yīng)用程序。此外,雖然軟件定義網(wǎng)絡(luò)(SDN)現(xiàn)處于炒作周期的高峰期,但事實上,實際部署的SDN幾乎就沒有,尤其在企業(yè)IT環(huán)境中。實際上,2014年8月開展的一項調(diào)查發(fā)現(xiàn),三分之二的調(diào)查對象估計至少三五年后才會部署SDN。因此,無法處理好虛擬化基礎(chǔ)設(shè)施和非虛擬化基礎(chǔ)設(shè)施的IaaS可能會淪為另一個孤島,無法幫助整個行業(yè)向前推進。
編排和自動化適合何處?
如今市面上不乏出色的編排和自動化工具;然而,絕大多數(shù)工具屬于兩大類,沒有哪一類真正面對基礎(chǔ)設(shè)施靈活性的實際現(xiàn)實:
•純虛擬化編排。大多數(shù)編程和自動化工具實際上假設(shè):一切系統(tǒng)都是虛擬化的。無論是面向整個堆棧,還是可能面向網(wǎng)絡(luò)虛擬化,這類解決方案根本沒有以任何一種有意義的方式來處理物理基礎(chǔ)設(shè)施。
•垂直集成的編排。大多數(shù)數(shù)據(jù)中心計算基礎(chǔ)設(shè)施廠商提供編排工具,以處理物理基礎(chǔ)設(shè)施和虛擬基礎(chǔ)設(shè)施。然而,所有這些基礎(chǔ)設(shè)施必須由同一家廠商來提供,它很少可以延伸到其他所有已落實到位的物理或遺留基礎(chǔ)設(shè)施。
當然,這不是說這兩種解決方案都缺乏有效性、都沒有用――它們顯然適合特定的使用場合和環(huán)境,但它們也明顯存在局限性。
通常來說,為了克服這些挑戰(zhàn)而提供的解決方案就是API:你可以使用API,擴展工具的業(yè)務(wù)邏輯,以便處理原本無法處理的對象,包括物理基礎(chǔ)設(shè)施。這種辦法確實存在著一些問題,但我只想說一句:就算有意愿,大多數(shù)企業(yè)的IT團隊也無力構(gòu)建和維護一套內(nèi)部自行開發(fā)的自動化架構(gòu)(通常意味著面臨一大堆難以維護的腳本),以便滿足這些需求、與那些API進行集成。
靈活基礎(chǔ)設(shè)施編排技術(shù)和***實踐
好消息是,現(xiàn)在已經(jīng)有編排技術(shù)和與之配套的***實踐,可以克服異構(gòu)基礎(chǔ)架構(gòu)這個挑戰(zhàn)。方法包括下面這些主要原則:
1. 基本模塊對象架構(gòu)。為了滿足將物理庫存和虛擬化資源編排成公共資源池這一需要,所有的資源及配置接口都表示成或編碼成基本模塊對象。這意味著,可以為基礎(chǔ)設(shè)施庫存資源分配公共屬性,以便識別應(yīng)該使用哪些配置對象。比如說,它們是虛擬機、是IOS或IOS-XR交換機,還是運行Linux的非虛擬化的戴爾或惠普服務(wù)器?配置對象還有著同樣的公共屬性,以便從底層API語法抽取輸入?yún)?shù)。這種方法的一大優(yōu)點是,它為自動化重復(fù)使用奠定了基礎(chǔ),因而大大減少了維護自動化所需要的成本和時間。這與基于脆弱腳本的系統(tǒng)形成了鮮明對照:腳本系統(tǒng)往往難以維護,這是由于在幾百個或數(shù)百個不同的腳本之間有著太多重復(fù)的公共函數(shù)或API調(diào)用,另外由于腳本比較難以理解,特別是由于它們往往缺少詳細的說明文檔。
2. 創(chuàng)建即開即用、自己動手(DIY)的配置接口。對自動化工具廠商們來說,為公共云API構(gòu)建庫比較容易。試圖支持在企業(yè)IT部門多年來部署的基礎(chǔ)設(shè)施這個龐大環(huán)境里面的所有一代又一代的接口,好比試圖把整個海洋燒開,無疑是白費力氣。如果完全依賴自動化工具廠商來構(gòu)建和維護這些接口,自動化過程也就喪失了大部分靈活性,因為代碼更新可能需要耗時幾個月,甚至在開始為那些接口編寫代碼之前可能需要與業(yè)務(wù)部門洽談相關(guān)事宜。在許多情況下,配置基礎(chǔ)設(shè)施其實只需要API的一小部分。所以,想保持自動化方面的靈活性,能夠自行創(chuàng)建配置對象的DIY方法必不可少。
3. 可視化編排和自動化創(chuàng)作工具。如前所述,大多數(shù)企業(yè)的IT小組沒有大批程序員。這些部門最不希望被沒有根據(jù)本企業(yè)的人員狀況而開發(fā)的一套方法捆住手腳。企業(yè)的IT人員習慣于使用用戶界面(UI)工具。GUI編排工具相當常見,但它們應(yīng)該具有真正的靈活性,以便構(gòu)建資源環(huán)境,包括任意的網(wǎng)絡(luò)拓撲結(jié)構(gòu),以便連接可能需要的所有不同資源。編排工具應(yīng)該可以將物理資源和虛擬資源都能拖放到設(shè)計畫布,并且在物理層和虛擬層都能管理好連接。一旦自動化對象創(chuàng)建起來,你沒必要讓業(yè)務(wù)邏輯與環(huán)境構(gòu)建、僅由程序員構(gòu)建的配置混在一起??梢暬詣踊瘎?chuàng)作工具讓見多識廣的非程序員也可以通過拖放操作來設(shè)計工作流程。對象重復(fù)使用和可視化創(chuàng)作工具這對組合意味著,你可以增加實現(xiàn)和維護自動化的人員的數(shù)量,而這有助于形成一種真正可持續(xù)發(fā)展的自動化實踐。
企業(yè)的IT團隊確實很需要提高部署基礎(chǔ)設(shè)施方面的靈活性。在競相構(gòu)建和證明這種靈活性的過程中,別忘了全面顧及最終用戶需要的所有基礎(chǔ)設(shè)施,包括物理基礎(chǔ)設(shè)施。然后,選擇一種編排技術(shù),并確立自動化實踐,以便有效管理該基礎(chǔ)設(shè)施,讓你可以為長遠目標構(gòu)建和維護自動化。