傳統架構雲化後的運維，維護的是什麼？

雲栖号資訊：【 點選檢視更多行業資訊

】

在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！

傳統的IT架構使用了這麼多年，所有的監控裝置以及網絡架構都是基于此打造，那麼在傳統架構虛拟化、雲化後的今天，如何針對虛拟化、雲計算的環境如IaaS、PaaS進行運維?應該注重哪些領域?本文提出了非常清晰的思路，可供參考。

背景

在雲時代我們完全看不到任何實體裝置，也不再關心硬體的穩定性和可靠性，因為當我們的硬體發生故障時，業務會第一時間切換到其他的節點，甚至切換到其他的資料中心，這樣我們的硬體維修完全可以等到友善的時候再進行。運維自動化是整個雲運維的核心。要面對成千上萬台的伺服器，産生的運維已經是人工方式不可能完成的任務，這就需要一整套高效自動化的運維管理工具，來幫我們實作運維的自動化。當運維的自動化程度越來越高的時候，我們會發現其實雲運維維護的是代碼，而傳統運維維護的是硬體。最後，雲運維對我們維護能力的要求也越來越高，我們不但要掌握作業系統，還要不停學習各種雲計算相關的知識和理論，還要掌握一些開源的工具，同時還要具備開發定制的能力，要不停的去開發定制自動化的運維工具和腳本。

一、現狀和面臨的挑戰

傳統的IT架構使用了這麼多年，所有的監控裝置以及網絡架構都是基于此打造，那麼在傳統架構虛拟化、雲化後的今天，如何針對虛拟化、雲計算的環境如IAAS、PAAS進行運維?

傳統監控系統主要是基于傳統的環境建構。主要是針對基礎的硬體裝置、業務系統的監控，對于虛拟化環境的覆寫是不足甚至可以說是零覆寫的，特别是在虛拟化技術引入之後，每台主控端裡面的衆多虛拟機怎麼去運維?衆多的容器 、微服務 、APP怎麼運維 ?如何監控是雲化後運維監控面臨的挑戰。

目前主要面臨的問題：

1.虛拟機配置變化更快，資料不準确，很難做到及時更新。

配置變化更頻繁，是以對其配置狀态的跟蹤更複雜，整個系統範圍内的資産資訊更難掌握，運用老套的統計辦法不及時也不準确，耗費人力、物力。

2.容量性能評估難，難以有效配置設定資源。

虛拟機不同于實體機，一台主控端上的各個虛機之間的關系是即争用又共享，虛拟機對于CPU、記憶體不僅僅是占用、很大一部分是共享的關系。對此特殊的配置設定機制，傳統的系統級CPU、記憶體的占用已失去絕對指導意義，并不能完全代表虛拟機是否存在瓶頸。同樣的道理，難以判斷實體伺服器資源是否得到了充分利用、是否有必要優化、虛拟機密度是否恰當，進而導緻多數組織内部存在較廣泛的資源閑置情況。

3.管理缺乏标準和規範

虛拟化在整個IT系統建構中占的位置越來越重要，但與作業系統相比，IT系統級的加強和檢査機制相對薄弱，成熟度及普及度都不高，存在系統缺陷、安全漏洞、管理不規範等薄弱環節，容易成為新的短闆現象。

4.系統狀态邊界化模糊，難以準确評估狀态。

雲計算環境涉及IT基礎硬體、作業系統以及業務系統等，傳統的裝置邊界不再那麼清晰，承載的VM對資源既共享又競争，是以系統處于不斷地動态調整中，故障域的耦合更加緊密，針對問題根源的判斷更加困難。

5.容器

由于不需要為每個容器加載作業系統和核心，是以與傳統的虛拟化環境相比，容器化環境能夠在給定數量的基礎架構内實作更高的工作負載密度。是以，在整個生産環境中建立、監視和銷毀的元件需求總量呈指數級增長，進而顯著增加了基于容器的管理環境的複雜性。Docker的生态系統複雜多變。在過去幾年中，第三方工具和服務大量出現，幫助開發人員在開發過程中部署、配置和管理他們的容器化工作流程。基于開源技術，這些工具和服務的變化之快以及新文檔的數量之多，使建構穩定的技術棧以實作在生産中運作容器變得充滿挑戰。容器的主要優點之一就在于它們是可移植的——一個應用程式，其所有的依賴關系可以捆綁到一個獨立于Linux核心、平台分布或部署模型的主機版本的單個容器中。是以利用容器使應用程式跨不同基礎設施需要的不僅僅是一個用于運輸代碼的标準化單元，它還需要基礎設施服務，包括：

• 運作Docker容器的主機(CPU、記憶體、存儲和網絡連接配接)，包括在本地以及雲上運作的虛拟機 或實體機器;協調好端口映射或軟體定義的網絡，使不同主機上的容器能夠互相通信;向Internet提供負載均衡器服務;DNS，通常用于實作服務發現;內建的健康檢查，確定應對請求的使用的都是健康的容器服務;某些事件觸發執行操作時的應對措施，例如在主機發生故障後重新啟動新容器，確定可用的正常容器始終維持一個固定的數量，或者建立新主機和容器以響應增加的負載;通過現有容器建立新容器來擴充服務;借助存儲快照和備份功能以備份狀态容器，進而進行災難恢複;
• 微服務是一系列職責單一、細粒度的服務，是将我們的業務進行拆分為獨立的服務單元，伸縮性好，耦合度低，不同的微服務可以用不同的語言開發，每一個服務處理的單一的業務。微服務可以劃分為前端服務(也叫邊緣服務)和後端服務(也叫中間服務)，前端服務是對後端服務做必要的聚合和剪裁後暴露給外部不同的裝置(PC、Phone等)，所有的服務啟動時都會到Eureka伺服器進行注冊，服務之間會有錯綜複雜的依賴關系。

二、雲化架構采取的應對措施

計算和虛拟化環境缺乏有效深入的監控措施，導緻管理被動，無法及時發現問題，無法有效分析問題，安全管理上缺乏對虛拟化環境的管理規範、手段及工具，安全短闆問題較明顯。

針對于以上幾大問題，在雲化後的運維，應該注重以下領域：

1、容量管理

容量管理分為容量優化和容量規劃。容量優化關注優化資源配置，提高現有資源使用率。發現并回收低效、未使用的資源，以便合理調整虛拟機大小、回收閑置資源，在不影響性能的情況下優化整合率和虛拟裝置密度。容量規劃關注容量不足和超額配置情況，以提前規劃資源擴容，指導采購，并規避資源風險。

(1) 業務處理量：反映在對外接口部分，主要評估響應時間要求内的最大并發能力， 由于對外接口可能提供的服務是多個，按實際場景分析最大和最小容量;典型的服務接入 如WEB 叢集、 Web service(叢集)、 socket 等;服務接入後一般交背景程式進行處理，處 理結果最終傳回服務接入端，是以可以每個服務(交易)的響應時間作為容量評估的一個 參數，其反映的是背景程式的處理能力，表現的是一段時間内的服務通過量;處理量相關部分容量名額：交易量、TPS，系統響應時間、響應率。

(2) 業務承載量：承載能力相對靜态，表示該應用系統能夠容納的資料量，在交易 型系統中，存量資料多少會影響服務處理的效率，進而影響處理能力，為了保障對外能力， 存量資料必然有所限制，比如資料庫中存放的曆史交易資訊一定不能是無限制的;大部分 系統都有批處理，批處理大部分會讀寫檔案或資料庫，作為整體處理能力的一部分，批處 理也需要納入容量管理範圍，允許的批處理時間視窗内，能夠處理的資料量就是容量管理 的一部分名額;承載量相關部分容量名額：最大使用者數，資料保留周期，活動數量。

(3)業務容量名額對應的系統性能容量參數：無論業務承載量還是業務處理量，最終在系統上反映的，都是系統的軟硬體配置、參數等實際對應值，從業務容量名額到系統容量名額的翻譯非常困難，與各應用系統的複雜程度相關，主要的系統容量或性能名額包括：

A、網絡性能及容量：帶寬、網速;

B、網絡裝置：端口數、背闆帶寬等;

C、伺服器：網卡、光纖卡、 CPU、記憶體、磁盤;

D、存儲：IO、容量;

E、資料庫：最大連接配接數、表空間;

F 、檔案系統：空間、類型;

G、應用伺服器(WAS、Weblogic)：連接配接池數量、 JVM 大小、端口連接配接數;

H、 Web 伺服器：端口數

I、消息中間件(MQ)：隊列深度

J、應用程式：處理速度

K、批處理：作業的視窗

2、閑置資源回收、調整虛拟比

由于雲計算環境的資源共享和動态配置特性，雲計算環境下的資源管理變得更加複雜難控，資源的驚人浪費和局部資源的緊張情況同時存在。如何判斷充分利用這些資源，配置合理的虛拟裝置比例是新環境下的運維能力的硬性要求。

3、配置及資産管理

運用專業的監控工具進行批量全面化的資訊采樣，收集虛拟化層面的所有資訊(包含計算資源的資訊、網絡資訊以及存儲存儲)。

具體包含：部署的 vSphere 版本、模闆數量、 CPU 與記憶體使用情況、網卡數量、 HBA 卡數量、是否處于維護模式、是否打開了 vMotion 、啟動運作時間、對應的 vSwitch 收集各種網絡配置資訊、 Datastore 的相關資訊、 VM 配置資訊、包括名稱、 IP 位址、 CPU 預留、記憶體預留、記憶體 limit 、記憶體擴充預留、總的 CPU 請求、是否安裝了 VMware Tools 等等。

4、安全及合規管理

在雲計算環境中，有很多比較容易忽略的安全隐患，可能被惡意利用。而且雲計算環境是一個高度動态的環境，一兩次的檢查工作并不能保證整個 IT 環境的持續合規，必須要高頻的掃描檢測才能減少安全風險。常見的安全檢測政策：拒絕 MAC 被更改、確定密碼複雜度、配置主控端防火牆、配置 NTP 服務、設施 Shell 逾時政策、不容許安裝未簽名的 VIB 、關閉 ESXi 與網際網路的通信、更新檔安裝更新、集中儲存 core dumps 日志等。

5、存儲管理、對虛拟化主機、虛機、網絡和存儲計算資源的全面監控

全面将各個廠家的儲存設備納入存儲監控進行統一管理，實時監控存儲容量以及其他裝置如光纖交換機的性能。可以對VMware虛拟機，虛拟機上安裝的不同作業系統，作業系統上運作的各種應用和業務系統進行深度監控，及時發現IT系統的運作故障，降低企業在虛拟化和雲計算過程中的風險。

6、容器和微服務管理

組織需要一種更便捷的方法來編排容器，以及管理多容器、多主機應用程式的底層基礎架構服務。這對于具有微服務體系結構的應用程式尤為重要，例如，一個Web應用程式，包括一個容器叢集運作Web伺服器前端的多個執行個體的主機(故障轉移和負載均衡)以及多個後端服務，是各自運作在不同的容器中的。搭建基于容器和微服務監控平台。

7、使用者體驗監控

App 性能監控是将 App運作時産生的性能資料進行擷取及處理和分析, 通過平台發現應用對使用者影響最大的性能問題并通過雲端對性能資料進行存儲、分析, 以郵件、微信方式推送。讓行業經驗沉澱成為一個完整的閉環, 使應用的性能可以得到持續的監控與提升。APP性能監控是模拟使用者真實操作場景對APP在實際運作中的性能資料(響應耗時，資料流量，CPU/記憶體占用率等)進行持續性監控。

網站業務撥測是一種網絡鍊路品質的測試手段。撥測，非常類似于爬蟲，更準确地講，非常類似于黑客控制“殭屍電腦”發起DDos攻擊。這裡的“殭屍電腦”，就是某個網際網路服務的用戶端，比如PC端、手機端。目的：探測各地區使用者到各個服務接入點的鍊路狀況，這樣，服務排程系統就可以根據探測結果為使用者提供最佳的接入點。

呼叫中心業務撥測，模拟使用者的業務操作過程，獲得完成業務的操作過程性能資料和操作結果資料。

8、APM監控

全稱 Application Performance Management ， 提供分布式追蹤功能。

被用于追蹤、監控和診斷分布式系統，特别是使用微服務架構，雲原生或容積技術。提供以下主要功能：

• 分布式追蹤和上下文傳輸
• 應用、執行個體、服務性能名額分析
• 根源分析
• 應用拓撲分析
• 應用和服務依賴分析
• 慢服務檢測
• 性能優化

9、統一日志管理和監控

日志監控可以采用大資料技術實作，大緻可以分為兩大子產品：

離線資料處理：比如說電商、營運商出現的大批量的日志，可以由flume、sqoop或者其他路徑，導入到HDFS中，然後經過資料清洗，使用Hive進行分析和處理，對于優化伺服器資源等有很好的作用;

實時資料處理：對于有些業務需要，可能第二天或者更晚的時候進行分析無關緊要，但對于一些高頻的金融交易來說，實時性就太重要了。

主要子產品：日志收集子產品、日志處理子產品

主要工具：

Filebeat：Filebeat就是一個完美的替代者，它基于Go語言沒有任何依賴，配置檔案簡單，格式明了，同時，filebeat比logstash更加輕量級，是以占用系統資源極少，非常适合安裝在生産機器 。

kafka：消息緩沖隊列，大資料進行中常用的緩沖隊列，用于資料爆炸的時候，避免拖垮後續的處理邏輯，将消息先存放到隊列中，延遲一定的時間進行處理。

Apache Flink：具有真正的流處理特性以及低延遲和高吞吐量流處理功能，非常适合CEP工作負載。

Spring boot：建構資料配置服務，友善使用者配置自己的日志資料，比如郵件發給何人，短信發給何人，都可以自由指定。

zookeeper：資料配置中心，在本項目用途中，主要是用于配置資料的管理。

1：日志收集子產品

在日志收集子產品中，針對我們自身的業務，可以分為兩大部分：

Nginx日志和資料庫運作日志：首先是Nginx，作為業内比較強大的負責均衡工具，其性能比較優良，我們在日常的服務中，也是使用該工具來進行負載均衡的功能實作。對于Tomcat類型的服務，選擇使用log4j内置的flume-appender方式來實作。對于收集到的日志，統一采用kafkaSink的方式，輸送到後續的kafka中，以備後續的處理。

2：日志處理子產品

對于收集到的日志的處理，我們采用的是Apache Flink工具，将其與kafka對接，對于收集到的每一條資料進行處理。

10、大膽嘗試使用AIOPS

AIOPS可以實作曆史資料分析 、 毛刺檢測 、 名額預測 、 異常判定 。

通過海量資料源 (性能名額、日志、告警)、使用TensorFlow等成熟算法庫、輕量化計算可以實作告警準确率提升到80%，告警覆寫率提升到95%、告警配置人力下降60%，一句話：降本增效體質。

AIOPS在深度上可以實作智能故障發現，更一步實作日志異常檢測、告警壓縮和關聯、告警根因分析以及容量預測;在廣度上讓AIOPS在更多運維領域落地開花。

随着雲的普及，IT環境表現出三個特征：規模更大，産生的資料更多 ;動态，雲的彈性決定了IT環境是不斷變化的 ;更複雜，從主機層面有實體機，虛拟機，雲主機，容器等，從形态上有私有雲、公有雲、混合雲等。越來越多的資料，複雜環境頻繁的警報，大量重複工作，要求提升自動化水準，AIOps是解決這些問題的利器，使用AIOps隻是時間問題。

三、總結

雲化環境運維應該以交易監控和APM項目為抓手，以業務品質和客戶體驗為核心，以可管控、可視化、可度量為目标，從使用者體驗出發，建立端到端全鍊路監控、告警+投訴預警+客服關聯形成完整閉環管理。在強化基礎設施監控的基礎上，補充和完善應用性能監控和業務品質監控能力，保障業務的穩定性和客戶感覺。引入自動化手段，封裝标準模闆，通過自動化配置打通CMDB、監控、告警資料流，實作一鍵批量建立監控、告警政策的功能，實作自動化提速;通過使用ETL工具如Kattle等開發抽取告警平台曆史資料，最終裝載到大資料分析平台中，進行多元度的資料分析，實作資料化賦能;建立豐富、多樣、靈活的視圖與報表，提供直覺高效的巡檢、定位工具，結合智能化手段提升監控預警能力，實作智能化增效。

從業界的發展曆程來看，技術的标準化是一個必然的演進過程，運維自動化其實就是标準化的一種展現。從入手SRE的第一步開始，應該整理和梳理工作職責，把需要解決的問題都文檔成檢查清單。友善業務上的快速實施。緊接着就是可視化這些業務名額和場景，幫助企業降低營運成本，量化服務體系的目标。

【雲栖号線上課堂】每天都有産品技術專家分享！

課程位址：

https://yqh.aliyun.com/zhibo

立即加入社群，與專家面對面，及時了解課程最新動态！

【雲栖号線上課堂 社群】

https://c.tb.cn/F3.Z8gvnK

原文釋出時間：2020-03-30

本文作者：twt社群

本文來自：“

51CTO

”，了解相關資訊可以關注“

”