【品高雲7年】四、生產運行支撐到底對雲有什麼需求

1.概述

  時代已經進入二十一世紀,第四次工業革命已經到來,信息化已經成爲企業生存的“必要條件”,而各種支撐業務運行的IT系統,就如同企業前進的發動機,必須得到無微不至的、持續的呵護與安全保障。

  業務系統的安全保障是個系統工程,它講究的是木桶原理——短板決定了上限。因此除了機房風火水電等基建設施需要符合相關規範外,包括用於支撐業務運轉的硬件系統(如服務器、存儲、交換機、負載均衡等)、基礎軟件系統(如操作系統、中間件、數據庫等)、應用系統(如CRM、ERP、OA)等多方系統都具備更高的能力,方能確保業務的可靠運轉。

  另一方面,因爲雲計算技術的引入,上述系統被【虛擬化】(如:硬件設備變成了虛擬資源)和【雲化】(如:傳統應用架構變成了分佈式架構) ,因此遵從疊加原則,雲平臺需要在傳統的、物理的保障架構上,提供更多的保駕護航能力,才讓企業能值回票價。

  綜合品高雲已有大型央企、金融、製造、政府、公安等對生產運行有着高要求的客戶需求的總結,發現客戶對雲平臺的需求主要集中在:雲平臺要經過安全認證、多維度的HA保障、擴展性保障、從容面對突發狀況、更便捷的備份以及給“雲外 ”資源提供保障等6個需求。

2.經過驗證的安全性

  一個人跟你說他會開車(主觀),你可能不信,如果碰巧你也不會開,那恐怕他說再多的技術道理你也很難相做出判斷;而一堆人都說這個人可以,而且他還亮出駕駛證,甚至開車到你面前(客觀),你就不得不信了。

  雲平臺就是這樣的東西,需要通過多方面的安全的客觀證據來證明他的安全性,它們應該包括:

2.1. 產品安全方法論(體系靠譜嗎?)

  產品的安全應該基於某種約定俗成的安全標準,而且不僅要說明清楚自己的安全功能,還應該說明產品的安全邊界在哪裏,對於邊界外的事物給予建議,這樣用戶才能用着放心。

這裏寫圖片描述
(圖:雲安全責任共擔模型)

2.2. 產品安全資質(技術靠譜嗎?)

  現在市面上針對雲產品的安全標準化有很多,如針對公有云有國際的CSA(雲安全聯盟)的STAR測評、國內的可信雲測評;針對私有云有國內的等級測評、公安部的信息安全測評、解放軍的信息安全測評等,通過測評機構的專業化經驗,可以有效幫助企業提前過濾一些安全分風險。

  近些年隨着雲計算的火熱,一批雲計算的安全測評機構也如雨後春筍般冒出來,建議企業針對自身的業務場景來查看產品的安全資質,如果公有云場景可以參考可信雲,如果企業私有云可以參考公安部測評,而政務雲可參考等保或解放軍的測評。

這裏寫圖片描述
(圖:公安部信息安全產品對雲操作系統的檢測)

2.3. 公司安全資質(公司靠譜嗎?):

  有句話說的好“跑的了和尚跑不了廟”,再好的技術產品,如果研發的企業自身存在安全漏洞弊端,也會爲客戶實施雲計算埋下不穩定因素,針對企業的安全認證有ISO20000、ISO27001等,下面是摘抄百度百科上對ISO27001的介紹:

  • 信息安全管理體系標準(ISO27001)可有效保護信息資源,保護信息化進程健康、有序、可持續發展。
  • 通過(ISO27001) 認證能保證和證明組織所有的部門對信息安全的承諾。
  • 通過(ISO27001) 認證可改善全體的業績、消除不信任感。
  • 獲得國際認可的機構的認證(ISO27001) 證書,可得到國際上的承認

這裏寫圖片描述
(圖:品高軟件通過ISO27001的資質證明)

2.4.案例應用場景(客戶相信嗎?)

  俗話說“光說不練假把式”,獲得再多的資質僅僅只是底線門檻,雲平臺只有在安全剛需客戶的生產環境中部署,才能夠最終證明產品的安全可靠程度,這些客戶場景包括:政府政務雲、公安警務雲、金融雲、部隊雲,甚至企業公有云等。

這裏寫圖片描述
(圖:基於品高雲的廣州電子政務雲的等保測試報告)

3.多維度的HA保障

  世界上有一個廣爲人知的理論——木桶理論。說的是:木桶是由多塊模板組裝而成,而最短的那塊木板決定了盛水的多少。而對於業務系統的可用性也是同樣的道理,無論你的服務器多麼強大,如果操作系統藍屏了,那麼服務也將終止。

  因此要達到應用系統的高可用(HA)就要從多個層面去考慮,一般包括:硬件層、虛擬化層、基礎軟件層、應用架構層以及雲管理平臺層等5個層面:

這裏寫圖片描述
(圖:多維度HA的雲平臺架構)

3.1. 硬件層HA

  一般是指承載業務運行的物理設備,傳統上的解決思路一般是冗餘,例如:容錯內存、磁盤raid、網絡鏈路聚合等,還有更多這裏不一一列舉,總之硬件層的HA和錢是成正比的,單機越可靠,成本就越多。而云化之後反而對硬件的要求降低了(雲計算採用集羣可靠性來替代對單機可靠性的依賴),類似google這樣的極端情況,甚至自己定製標準將不必要的硬件模塊裁掉,同時從ODM而不是OEM廠商採購服務器,可以更進一步降低成本。當然傳統企業還可以繼續沿用自己信賴的硬件廠商,只不過實施雲計算之後,不必被銷售綁架買最貴的產品了。

3.2. 虛擬化層HA(需要將基礎設施雲化)

  虛擬化相當於運行在物理設備和應用之間的“中間件”,它將底層物理設備的計算(如cpu)/存儲(如磁盤)/網絡(如通信)能力,通過“編程方式”重新組合分配給應用,既可以模擬出一臺規模更小的虛擬機(VM)也可以組合出一臺容量更大的存儲設備。而要保證虛擬化層的HA,主要依靠的是分佈式架構。而核心思路是“雞蛋不要放在一個籃子裏”和“螞蟻雄兵”。在者兩個思路下,主要關注點就是“籃子和螞蟻的多少”,它們越多整個系統就越可靠。

3.3. 基礎軟件層HA(需要將傳統軟件雲化)

  在企業中有這麼一類軟件,對於業務部門,根本沒聽過它們,也用不上它們,而每年IT部門卻要付出大量的成本進行維護;一旦它們出了問題,整個業務系統也將灰飛煙滅。它們就是基礎軟件,在企業內部稱之爲中間件和數據庫,如:websphere、weblogic、tomcat、oracle、sqlserver、mysql等。其實這些軟件本身隨着業務的進化,已經具備了高可用的集羣能力,例如WAS集羣、oracle的RAC等技術的部署和調優,雲平臺要做的就是把這些能力“自動化”,讓它們的使用方式“更傻瓜化”。

這裏寫圖片描述
(圖:oracle高可用dataguard自動化雲服務)

3.4.應用架構層HA(需要將應用組件雲化)

  最新的應用系統往往採用了多層架構,如MVC架構、微服務架構等,而每個層面也都相應部署了HA。但是其中涉及的數據庫、附件存儲、消息隊列、甚至負載均衡等,往往還是採用傳統技術實現,這在一定程度上需要程序開發人員還要去了解數據庫、存儲乃至消息隊列的HA技術,才能讓應用HA。但是正所謂“應該讓專業的人幹專業的事”,一般雲平臺自身提供了大量的“雲服務技術”如nosql服務、彈性伸縮服務、消息隊列服務、負載均衡技術、對象存儲等技術,而這些技術自身都是“容錯”架構的,而針對這些服務所設計出來的雲架構模式被成爲CDP(雲設計模式),這種模式下可以更好的發揮雲計算的HA能力,讓應用更具可用性。

這裏寫圖片描述
(圖:一個電子商務支付的CDP應用架構設計—以AWS服務爲例 )

3.5.雲管理平臺層HA(需要控制器集羣化)

  作爲負責資源全局調度的“控制器”,雲管理平臺中分別針對服務器資源的【集羣控制】、針對存儲資源的【存儲控制器】、針對網絡資源的【SDN控制器】乃至上層的UI控制檯和負責應用調用的API服務都需要具備HA的能力,並且最好具備“集羣”能力,因爲只有這樣才能同時解決性能瓶頸和單點故障問題,因此考量雲管理平臺的可靠性重點應該放這些方面。企業用戶可以在實際項目中,採用類似整個機櫃掉電的方式,來檢查雲平臺整體的可靠性。

這裏寫圖片描述
(圖:機櫃掉電控制器遷移示意圖)

4.擴展性保障

  當我們去購買筆記本電腦的時候,銷售人員總會推薦我們買有更多內存插槽的產品(這樣的電腦往往價格更高),理由是:當你未來想玩大型遊戲的時候,小內存是很苦惱的,再花錢買一臺新電腦成本更高。這裏面說的就是產品的擴展性

  在這裏,我們不敢苟同銷售人員的趨利目的,但是擴展性,的確是企業在採購雲平臺需要注意的問題。試想下未來生產上了雲後,發現很快到達了平臺的某個瓶頸,到時候想換產品或技術路線也爲時已晚。而對於雲平臺來講,擴展性意味着:更大的單集羣規模、更快的第三方技術整合。

4.1.更大的單集羣規模

  單集羣規模指的是在一個HA集羣中,物理服務器的數量。因爲在HA集羣中任意物理機宕機,其中的服務會自動遷移到另外的物理機,因此集羣規模越大,說明可靠性越高(想象下冷兵器時代,因爲兵器都差不多,因此軍團數量越大說明戰鬥力越強)。同時更高的集羣上限,也意味着未來的擴展性更高,否則就需要部署多個小的獨立集羣,可能存在:服務宕機後沒有可用資源給到它,或者另外的集羣有空閒但用不上的窘迫局面。

這裏寫圖片描述
(圖:品高雲在某客戶的單集羣1K臺物理服務器)

4.2.更快的整合第三方技術(開放架構)

  現代技術正在飛速發展中,客戶的需求永遠不可能被一家廠商滿足,因此不同領域有不同的專家存在,這就需要雲平臺可以融合更多第三方技術。這就需要雲平臺提供一個開放的架構,在計算、存儲、網絡、服務等多個層面提供能力的開放。例如:通過網絡能力的開放融合第三方安全產品(如防火牆、WAF、IPS、防毒牆等)增強客戶的安全防火能力;通過存儲能力開放允許第三方應用(如網盤、視頻轉碼、大數據處理等)增強客戶業務的吞吐量等;通過編排能力的開放允許用戶定製自己的個性化雲服務(如銀行的WAS集羣服務、高校的HPC服務、動漫業的3D渲染服務等等)。

這裏寫圖片描述
(圖:通過SDN能力擴展雲平臺的安全能力)

5.從容面對突發狀況

  現如今企業面臨着內部創新需求、外部互聯網倒逼的雙重壓力,使得以往被封鎖和保護的內部IT系統,開始突破防火牆的束縛,越來越多的業務系統需要跟internet打交道,這種情況下互聯網客戶訪問的不確定性、週期性問題就凸顯出來。例如:一個醫療行業的ERP系統,過去都是企業內部在使用,人員和訪問時間都比較固定,而隨着產業鏈上下游(如物流、電商、醫院等)加入到這個系統,那麼它的訪問將變得更加需要彈性能力;另一個例子是公安的互聯網系統,隨着服務型政府被提出,公安的報警、查詢、辦事等業務也可能被搬上app store,被廣大市民使用,也會造成訪問的不確定性。

  雲平臺在應對來自互聯網訪問壓力時,一般需要三個應對策略組件,分別是:SDN負載均衡、彈性伸縮、雲監控。

這裏寫圖片描述
(圖:雲平臺彈性伸縮功能原理)

5.1.SDN負載均衡

  通過將負載均衡軟件固化在雲中,提供類似硬件F5的能力,將雲中的vm組成集羣,抵抗併發壓力。而傳統的軟件負載均衡軟件主要有【反向代理模式】和【DR模式】兩個類型,反向代理模式的負載均衡存在單點問題(因爲所有流量都要經過負載均衡服務器);而DR模式(下行流量由後端vm直接發向客戶端)由於需要所有VM和負載均衡都需要額外配置VIP,從而對運維管理和自動化造成了挑戰。

  如果雲平臺可以提供DR模式的負載均衡,同時又避免運維操作,將是一個十分優化的方案。這種架構下就需要SDN能力的引入,通過將負載均衡作爲一個NFV組件進行管理,而VIP的事情交給流表處理,而用戶則無需關係這一細節。未來還可以按需加入WAF等功能,進一步增強用戶應用的可靠性。

這裏寫圖片描述
(圖:SDN負載均衡的架構示意圖)

5.2.彈性伸縮

  雲平臺必須具備的能力,它通過模板定義應用的部署案,並配置了當負載上升、下降時的應對策略。好一些的雲平臺還允許設定彈性的週期性有效性,例如:12306系統只在春運期間有突發流量時做出響應,而平時則作爲事件上報監控系統,通知管理員。

5.3.雲監控

  傳統IT中,監控可能只作爲一個報表系統,而在雲中雲監控的地位至關重要。一方面,它需要時刻蒐集資源的各種數據如cpu變化、I/O讀寫、網絡吞吐等,並同時進行彙總生成top10、折線圖、導出excel等;另一方面,在設定的閾值到達時需要觸發後續操作,如發送郵件給管理員、上報企業的CMDB變更、觸發彈性等。同時對於應用層面的變化量還需要允許用戶自定義監控指標,如客戶註冊數、數據庫進程內存等,從更精確的觸發後續動作。

這裏寫圖片描述
(圖:雲監控系統示意圖)

6.更便捷的備份

  如果說企業裏面什麼是最重要的,那麼備份恐怕要排到前三,備份技術的發展,也從早期的磁帶的定時備份向raid技術的實時備份發展、從SAN存儲的雙機鏡像備份向分佈式的多副本冗餘發展。如果說傳統模式下的備份還侷限在單數據中心內,那麼隨着業務可靠性需求的提高,越來越多的企業尤其是金融和重點政府單位開始考慮多數據中心間的備份。

  而對於雲平臺來講,除了支持傳統的物理設備雙機的模式外,還應該提供異構存儲設備(如SAN到分佈式),異地數據中心間的數據備份,而支持備份的對象應該包括虛擬機、虛擬硬盤和網絡架構等。在這種架構能力下:A數據中心的資源被異步或同步的備份到災備中心,在災備中心可以隨時發起演練操作(由於雲採用SDN架構,因此除了虛擬機和虛擬硬盤被快速模擬之外,網絡配置和IP等也可如此,真正模擬全生產環境)從而做到有備無患。

這裏寫圖片描述
(圖:跨數據中心雲資源災備)

7.提升“雲外資產”可靠性

  正如gartner所說:“雲計算將成爲未來業務的基礎平臺”,而如果企業建設好的基礎平臺,只能服務雲內的虛擬化資源,那隻能說它只發揮了一半功效。

  衆所周知,傳統企業長期的IT建設道路中有大量的遺留應用,而這些應用有些不得不、有些則必須運行在物理設備中;前者可能是年代太久,開發商已經不提供支持,而企業自己不敢輕舉妄動;後者則對硬件有特殊要求,如加密卡、行業軟件的硬件綁定等。

  而實際上雲平臺的一個重要作用,是能力的開放。如果可以將雲平臺中可靠的計算、存儲、網絡能力通過API或其他方式直接提供給物理機設備中的應用直接使用,那麼將進一步提升應用的健壯性。而這裏面存儲能力的開放往往是首當其衝的,因爲分佈式存儲池的建設,第一次使得企業有了更大的存儲容量和更低的成本(以前的SAN更貴、維護成本更高),正好可以建設企業的【綜合雲存儲服務中心】。

  與以往僅保存數據庫和文檔等兩類數據的存儲定位不同,隨着業務應用系統的豐富,而產生了更多諸如NoSQL數據庫、內存數據庫、影音、圖片、文檔等結構/非結構化數據。因爲對存儲性能、業務的需求各不相同,如果能針對不同應用提供更加符合業務化的存儲服務,勢必能夠進一步加速業務應用的處理效力。

  同時通過在雲平臺自身提供,或通過IaaS+(自動化軟件交付)模式整合客戶所熟知的第三方提軟件,提供針對物理設備的備份、CDP、磁帶庫等服務內容,也可以進一步充分使用存儲能力,釋放。

  關於【綜合雲存儲服務中心】的建議服務如下:

7.1. 對象雲存儲服務(少許改造應用)

  傳統應用可以通過API將附件數據(如文檔、視頻、圖片等)保存在雲存儲中,並且是高可用、可加密以及支持熱擴容。而付出的成本僅僅是改造附件上傳和下載處的UI控件邏輯。

7.2. 關係數據庫服務RDS(不改造應用)

  傳統應用直接通過數據庫的API鏈接到雲中創建好的數據庫實例(虛擬機)。常見的RDS服務包括mysql、sqlserver、oracle等。

7.3. NoSQL服務(需要大改應用)

  傳統應用通過改造,將分析性(如BI、數據挖掘)和事務性(如交易類)的存儲分離後,將事務性數據繼續保留在RDS中,而將非結構化數據保存在雲中的NoSQL數據庫中,而云平臺負責NoSQL數據庫的安裝、擴容和後續備份維護。常見的NoSQL包括hive、hbase等。

7.4. 內存數據庫服務(需要中量改造應用)

  傳統應用通過改造,將關係數據庫常見的查詢數據放入內存中,實現快速檢索。而應用需要引入內存數據庫驅動程序來實現這一效果。常見的內存數據庫包括redis、memcache等。

7.5. 流媒體存儲服務(需要少量改造應用)

  傳統媒體類應用將轉碼和保存的工作剝離出來,通過API使用雲中的這一服務,專注上層的媒資管理、媒資處理、易用性等工作。而云平臺負責底層的轉碼、流媒體服務器、視頻存儲等能力,且支持彈性資源配置和容量擴展。

7.6. 虛擬帶庫服務(無需改造應用)

  傳統備份軟件可以直接使用虛擬帶庫協議,將應用或服務器的數據備份到雲存儲中,並且無需承擔昂貴的額外硬件成本。

7.7. 存儲網關(無需改造應用)

  傳統軟件可以直接使用傳統協議,如NFS、iscis、samba等協議鏈接到存儲網關,並且通過異步定時或實時的方式將數據放入其中。本質是將分佈式存儲之上疊加通用訪問協議,其定位是一般是通用備份存儲。

7.8. CDP服務(無需改造應用)

  傳統各個廠商的CDP軟件可以通過IaaS+(應用自動化交付)的方式在雲中部署,而這些軟件後臺可以直接使用雲存儲的大容量服務。企業用戶無需改變自己的備份習慣。常見的CDP廠商如:賽門鐵克、愛數、英方、數騰等。

7.9. 網盤服務(無需改造應用)

  員工的工作數據可以統一被企業管理,並且按需備份和授權。避免使用公共網盤帶來的數據泄露和運營商關停的尷尬。

這裏寫圖片描述
(圖:企業綜合雲存儲服務中心 模式)

8.收益總結

  通過上述需求分析可以看到,生產運行場景相對於開發測試場景,更注重安全、可用、可靠和擴展性。而云平臺正是需要在這些方面盡其所能做到更好,才能滿足企業近乎苛刻的要求,而這一切在得到實施之後,對於企業來講不僅僅獲得了提升業務99.999999%的可用性這個看得見的回報。更重要的是,隨着各種雲服務需求被不斷被提出和實施,企業在使用雲計算的思路已經從IT運維向IT運營——這個終極目標邁進。而實際上對於IT運營層面的需求KPI和雲需求,卻又是另外一番光景了。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章