2021年08月27日
在云時代我們完全看不到任何物理設(shè)備，也不再關(guān)心硬件的穩(wěn)定性和可靠性，因為當(dāng)我們的硬件發(fā)生故障時，業(yè)務(wù)會第一時間切換到其他的節(jié)點，甚至切換到其他的數(shù)據(jù)中心，這樣我們的硬件維修完全可以等到方便的時候再進(jìn)行。運(yùn)維自動化是整個云運(yùn)維的核心。要面對成千上萬臺的服務(wù)器，產(chǎn)生的運(yùn)維已經(jīng)是人工方式不可能完成的任務(wù)，這就需要一整套高效自動化的運(yùn)維管理工具，來幫我們實現(xiàn)運(yùn)維的自動化。當(dāng)運(yùn)維的自動化程度越來越高的時候，我們會發(fā)現(xiàn)其實云運(yùn)維維護(hù)的是代碼，而傳統(tǒng)運(yùn)維維護(hù)的是硬件。最后，云運(yùn)維對我們維護(hù)能力的要求也越來越高，我們不但要掌握操作系統(tǒng)，還要不停學(xué)習(xí)各種云計算相關(guān)的知識和理論，還要掌握一些開源的工具，同時還要具備開發(fā)定制的能力，要不停的去開發(fā)定制自動化的運(yùn)維工具和腳本。
傳統(tǒng)的IT架構(gòu)使用了這么多年，所有的監(jiān)控設(shè)備以及網(wǎng)絡(luò)架構(gòu)都是基于此打造，那么在傳統(tǒng)架構(gòu)虛擬化、云化后的今天，如何針對虛擬化、云計算的環(huán)境如IAAS、PAAS進(jìn)行運(yùn)維？
傳統(tǒng)監(jiān)控系統(tǒng)主要是基于傳統(tǒng)的環(huán)境構(gòu)建。主要是針對基礎(chǔ)的硬件設(shè)備、業(yè)務(wù)系統(tǒng)的監(jiān)控，對于虛擬化環(huán)境的覆蓋是不足甚至可以說是零覆蓋的，特別是在虛擬化技術(shù)引入之后，每臺宿主機(jī)里面的眾多虛擬機(jī)怎么去運(yùn)維？眾多的容器 、微服務(wù) 、APP怎么運(yùn)維 ?如何監(jiān)控是云化后運(yùn)維監(jiān)控面臨的挑戰(zhàn)。
當(dāng)前主要面臨的問題：
1.虛擬機(jī)配置變化更快，數(shù)據(jù)不準(zhǔn)確，很難做到及時更新。
配置變化更頻繁，因此對其配置狀態(tài)的跟蹤更復(fù)雜，整個系統(tǒng)范圍內(nèi)的資產(chǎn)信息更難掌握，運(yùn)用老套的統(tǒng)計辦法不及時也不準(zhǔn)確，耗費(fèi)人力、物力。
2.容量性能評估難，難以有效分配資源。
虛擬機(jī)不同于物理機(jī)，一臺宿主機(jī)上的各個虛機(jī)之間的關(guān)系是即爭用又共享，虛擬機(jī)對于CPU、內(nèi)存不僅僅是占用、很大一部分是共享的關(guān)系。對此特殊的分配機(jī)制，傳統(tǒng)的系統(tǒng)級CPU、內(nèi)存的占用已失去絕對指導(dǎo)意義，并不能完全代表虛擬機(jī)是否存在瓶頸。同樣的道理，難以判斷物理服務(wù)器資源是否得到了充分利用、是否有必要優(yōu)化、虛擬機(jī)密度是否恰當(dāng)，從而導(dǎo)致多數(shù)組織內(nèi)部存在較廣泛的資源閑置情況。
3.管理缺乏標(biāo)準(zhǔn)和規(guī)范
虛擬化在整個IT系統(tǒng)構(gòu)建中占的位置越來越重要，但與操作系統(tǒng)相比，IT系統(tǒng)級的加固和檢査機(jī)制相對薄弱，成熟度及普及度都不高，存在系統(tǒng)缺陷、安全漏洞、管理不規(guī)范等薄弱環(huán)節(jié)，容易成為新的短板現(xiàn)象。
4.系統(tǒng)狀態(tài)邊界化模糊，難以準(zhǔn)確評估狀態(tài)。
云計算環(huán)境涉及IT基礎(chǔ)硬件、操作系統(tǒng)以及業(yè)務(wù)系統(tǒng)等，傳統(tǒng)的設(shè)備邊界不再那么清晰，承載的VM對資源既共享又競爭，所以系統(tǒng)處于不斷地動態(tài)調(diào)整中，故障域的耦合更加緊密，針對問題根源的判斷更加困難。
5.容器
由于不需要為每個容器加載操作系統(tǒng)和內(nèi)核，因此與傳統(tǒng)的虛擬化環(huán)境相比，容器化環(huán)境能夠在給定數(shù)量的基礎(chǔ)架構(gòu)內(nèi)實現(xiàn)更高的工作負(fù)載密度。因此，在整個生產(chǎn)環(huán)境中創(chuàng)建、監(jiān)視和銷毀的組件需求總量呈指數(shù)級增長，從而顯著增加了基于容器的管理環(huán)境的復(fù)雜性。Docker的生態(tài)系統(tǒng)復(fù)雜多變。在過去幾年中，第三方工具和服務(wù)大量出現(xiàn)，幫助開發(fā)人員在開發(fā)過程中部署、配置和管理他們的容器化工作流程?；陂_源技術(shù)，這些工具和服務(wù)的變化之快以及新文檔的數(shù)量之多，使構(gòu)建穩(wěn)定的技術(shù)棧以實現(xiàn)在生產(chǎn)中運(yùn)行容器變得充滿挑戰(zhàn)。容器的主要優(yōu)點之一就在于它們是可移植的——一個應(yīng)用程序，其所有的依賴關(guān)系可以捆綁到一個獨立于Linux內(nèi)核、平臺分布或部署模型的主機(jī)版本的單個容器中。因此利用容器使應(yīng)用程序跨不同基礎(chǔ)設(shè)施需要的不僅僅是一個用于運(yùn)輸代碼的標(biāo)準(zhǔn)化單元，它還需要基礎(chǔ)設(shè)施服務(wù)，包括：
運(yùn)行Docker容器的主機(jī)（CPU、內(nèi)存、存儲和網(wǎng)絡(luò)連接），包括在本地以及云上運(yùn)行的虛擬機(jī) 或物理機(jī)器；協(xié)調(diào)好端口映射或軟件定義的網(wǎng)絡(luò)，使不同主機(jī)上的容器能夠相互通信；向Internet提供負(fù)載均衡器服務(wù)；DNS，通常用于實現(xiàn)服務(wù)發(fā)現(xiàn)；集成的健康檢查，確保應(yīng)對請求的使用的都是健康的容器服務(wù)；某些事件觸發(fā)執(zhí)行操作時的應(yīng)對措施，例如在主機(jī)發(fā)生故障后重新啟動新容器，確?？捎玫恼Ｈ萜魇冀K維持一個固定的數(shù)量，或者創(chuàng)建新主機(jī)和容器以響應(yīng)增加的負(fù)載；通過現(xiàn)有容器創(chuàng)建新容器來擴(kuò)展服務(wù)；借助存儲快照和備份功能以備份狀態(tài)容器，從而進(jìn)行災(zāi)難恢復(fù)；
微服務(wù)是一系列職責(zé)單一、細(xì)粒度的服務(wù)，是將我們的業(yè)務(wù)進(jìn)行拆分為獨立的服務(wù)單元，伸縮性好，耦合度低，不同的微服務(wù)可以用不同的語言開發(fā)，每一個服務(wù)處理的單一的業(yè)務(wù)。微服務(wù)可以劃分為前端服務(wù)（也叫邊緣服務(wù)）和后端服務(wù)（也叫中間服務(wù)），前端服務(wù)是對后端服務(wù)做必要的聚合和剪裁后暴露給外部不同的設(shè)備（PC、Phone等），所有的服務(wù)啟動時都會到Eureka服務(wù)器進(jìn)行注冊，服務(wù)之間會有錯綜復(fù)雜的依賴關(guān)系。
計算和虛擬化環(huán)境缺乏有效深入的監(jiān)控措施，導(dǎo)致管理被動，無法及時發(fā)現(xiàn)問題，無法有效分析問題，安全管理上缺乏對虛擬化環(huán)境的管理規(guī)范、手段及工具，安全短板問題較明顯。
針對于以上幾大問題，在云化后的運(yùn)維，應(yīng)該注重以下領(lǐng)域：
容量管理分為容量優(yōu)化和容量規(guī)劃。容量優(yōu)化關(guān)注優(yōu)化資源配置，提高現(xiàn)有資源利用率。發(fā)現(xiàn)并回收低效、未使用的資源，以便合理調(diào)整虛擬機(jī)大小、回收閑置資源，在不影響性能的情況下優(yōu)化整合率和虛擬設(shè)備密度。容量規(guī)劃關(guān)注容量不足和超額配置情況，以提前規(guī)劃資源擴(kuò)容，指導(dǎo)采購，并規(guī)避資源風(fēng)險。
（1） 業(yè)務(wù)處理量：反映在對外接口部分，主要評估響應(yīng)時間要求內(nèi)的最大并發(fā)能力， 由于對外接口可能提供的服務(wù)是多個，按實際場景分析最大和最小容量；典型的服務(wù)接入 如WEB 集群、 Web service（集群）、 socket 等；服務(wù)接入后一般交后臺程序進(jìn)行處理，處 理結(jié)果最終返回服務(wù)接入端，因此可以每個服務(wù)（交易）的響應(yīng)時間作為容量評估的一個 參數(shù)，其反映的是后臺程序的處理能力，表現(xiàn)的是一段時間內(nèi)的服務(wù)通過量；處理量相關(guān)部分容量指標(biāo)：交易量、TPS，系統(tǒng)響應(yīng)時間、響應(yīng)率。
（2） 業(yè)務(wù)承載量：承載能力相對靜態(tài)，表示該應(yīng)用系統(tǒng)能夠容納的數(shù)據(jù)量，在交易 型系統(tǒng)中，存量數(shù)據(jù)多少會影響服務(wù)處理的效率，進(jìn)而影響處理能力，為了保障對外能力， 存量數(shù)據(jù)必然有所限制，比如數(shù)據(jù)庫中存放的歷史交易信息一定不能是無限制的；大部分 系統(tǒng)都有批處理，批處理大部分會讀寫文件或數(shù)據(jù)庫，作為整體處理能力的一部分，批處 理也需要納入容量管理范圍，允許的批處理時間窗口內(nèi)，能夠處理的數(shù)據(jù)量就是容量管理 的一部分指標(biāo)；承載量相關(guān)部分容量指標(biāo)：最大用戶數(shù)，數(shù)據(jù)保留周期，活動數(shù)量。
（3）業(yè)務(wù)容量指標(biāo)對應(yīng)的系統(tǒng)性能容量參數(shù)：無論業(yè)務(wù)承載量還是業(yè)務(wù)處理量，最終在系統(tǒng)上反映的，都是系統(tǒng)的軟硬件配置、參數(shù)等實際對應(yīng)值，從業(yè)務(wù)容量指標(biāo)到系統(tǒng)容量指標(biāo)的翻譯非常困難，與各應(yīng)用系統(tǒng)的復(fù)雜程度相關(guān)，主要的系統(tǒng)容量或性能指標(biāo)包括：
A、網(wǎng)絡(luò)性能及容量：帶寬、網(wǎng)速；
B、網(wǎng)絡(luò)設(shè)備：端口數(shù)、背板帶寬等；
C、服務(wù)器：網(wǎng)卡、光纖卡、 CPU、內(nèi)存、磁盤；
D、存儲：IO、容量；
E、數(shù)據(jù)庫：最大連接數(shù)、表空間；
F 、文件系統(tǒng)：空間、類型；
G、應(yīng)用服務(wù)器（WAS、Weblogic）：連接池數(shù)量、 JVM 大小、端口連接數(shù)；
H、 Web 服務(wù)器：端口數(shù)
I、消息中間件（MQ）：隊列深度
J、應(yīng)用程序：處理速度
K、批處理：作業(yè)的窗口
由于云計算環(huán)境的資源共享和動態(tài)配置特性，云計算環(huán)境下的資源管理變得更加復(fù)雜難控，資源的驚人浪費(fèi)和局部資源的緊張情況同時存在。如何判斷充分利用這些資源，配置合理的虛擬設(shè)備比例是新環(huán)境下的運(yùn)維能力的硬性要求。
運(yùn)用專業(yè)的監(jiān)控工具進(jìn)行批量全面化的信息采樣，收集虛擬化層面的所有信息（包含計算資源的信息、網(wǎng)絡(luò)信息以及存儲存儲）。
具體包含：部署的 vSphere 版本、模板數(shù)量、 CPU 與內(nèi)存使用情況、網(wǎng)卡數(shù)量、 HBA 卡數(shù)量、是否處于維護(hù)模式、是否打開了 vMotion 、啟動運(yùn)行時間、對應(yīng)的 vSwitch 收集各種網(wǎng)絡(luò)配置信息、 Datastore 的相關(guān)信息、 VM 配置信息、包括名稱、 IP 地址、 CPU 預(yù)留、內(nèi)存預(yù)留、內(nèi)存 limit 、內(nèi)存擴(kuò)展預(yù)留、總的 CPU 請求、是否安裝了 VMware Tools 等等。
在云計算環(huán)境中，有很多比較容易忽略的安全隱患，可能被惡意利用。而且云計算環(huán)境是一個高度動態(tài)的環(huán)境，一兩次的檢查工作并不能保證整個 IT 環(huán)境的持續(xù)合規(guī)，必須要高頻的掃描檢測才能減少安全風(fēng)險。常見的安全檢測策略：拒絕 MAC 被更改、確保密碼復(fù)雜度、配置宿主機(jī)防火墻、配置 NTP 服務(wù)、設(shè)施 Shell 超時策略、不容許安裝未簽名的 VIB 、關(guān)閉 ESXi 與互聯(lián)網(wǎng)的通信、補(bǔ)丁安裝升級、集中保存 core dumps 日志等。
全面將各個廠家的存儲設(shè)備納入存儲監(jiān)控進(jìn)行統(tǒng)一管理，實時監(jiān)控存儲容量以及其他設(shè)備如光纖交換機(jī)的性能?？梢詫Mware虛擬機(jī)，虛擬機(jī)上安裝的不同操作系統(tǒng)，操作系統(tǒng)上運(yùn)行的各種應(yīng)用和業(yè)務(wù)系統(tǒng)進(jìn)行深度監(jiān)控，及時發(fā)現(xiàn)IT系統(tǒng)的運(yùn)行故障，降低企業(yè)在虛擬化和云計算過程中的風(fēng)險。
組織需要一種更便捷的方法來編排容器，以及管理多容器、多主機(jī)應(yīng)用程序的底層基礎(chǔ)架構(gòu)服務(wù)。這對于具有微服務(wù)體系結(jié)構(gòu)的應(yīng)用程序尤為重要，例如，一個Web應(yīng)用程序，包括一個容器集群運(yùn)行Web服務(wù)器前端的多個實例的主機(jī)（故障轉(zhuǎn)移和負(fù)載均衡）以及多個后端服務(wù)，是各自運(yùn)行在不同的容器中的。搭建基于容器和微服務(wù)監(jiān)控平臺。
App 性能監(jiān)控是將 App運(yùn)行時產(chǎn)生的性能數(shù)據(jù)進(jìn)行獲取及處理和分析, 通過平臺發(fā)現(xiàn)應(yīng)用對用戶影響最大的性能問題并通過云端對性能數(shù)據(jù)進(jìn)行存儲、分析, 以郵件、微信方式推送。讓行業(yè)經(jīng)驗沉淀成為一個完整的閉環(huán), 使應(yīng)用的性能可以得到持續(xù)的監(jiān)控與提升。APP性能監(jiān)控是模擬用戶真實操作場景對APP在實際運(yùn)行中的性能數(shù)據(jù)（響應(yīng)耗時，數(shù)據(jù)流量，CPU/內(nèi)存占用率等）進(jìn)行持續(xù)性監(jiān)控。
網(wǎng)站業(yè)務(wù)撥測是一種網(wǎng)絡(luò)鏈路質(zhì)量的測試手段。撥測，非常類似于爬蟲，更準(zhǔn)確地講，非常類似于黑客控制“肉雞”發(fā)起DDos攻擊。這里的“肉雞”，就是某個互聯(lián)網(wǎng)服務(wù)的客戶端，比如PC端、手機(jī)端。目的：探測各地區(qū)用戶到各個服務(wù)接入點的鏈路狀況，這樣，服務(wù)調(diào)度系統(tǒng)就可以根據(jù)探測結(jié)果為用戶提供最佳的接入點。
呼叫中心業(yè)務(wù)撥測，模擬用戶的業(yè)務(wù)操作過程，獲得完成業(yè)務(wù)的操作過程性能數(shù)據(jù)和操作結(jié)果數(shù)據(jù)。
全稱 Application Performance Management ， 提供分布式追蹤功能。
被用于追蹤、監(jiān)控和診斷分布式系統(tǒng)，特別是使用微服務(wù)架構(gòu)，云原生或容積技術(shù)。提供以下主要功能：
分布式追蹤和上下文傳輸
應(yīng)用、實例、服務(wù)性能指標(biāo)分析
根源分析
應(yīng)用拓?fù)浞治?/span>