備份系統執行資料收集及分析的設計 | 運維進階
【作者】陳萍春,現就職於保險行業,擁有多年的系統、儲存以及資料備份等運維工作經驗。
前言
資訊系統的執行雖然遵循一定的執行規律,但也呈現出動態的、易干擾、難以預測的特徵。對於 IT 系統運維人員來說,我們最關注的是系統的穩定執行,有時會過於擔憂系統的執行風險,有時也對某些執行中的風險麻痺大意,甚至在面對潛在的、未知的故障時,還會十分恐慌。恐懼源於未知, IT 運維人員需要克服這種恐懼,讓運維從容不迫。本文將從個人運維實踐經驗出發,研究設計備份系統執行資料採集及分析方法,從而能更加洞察系統的執行規律,希望對同行有一定的借鑑和參考價值。
1. 需求
資料備份是為應對潛在的資料丟失風險,而將業務系統中的資料加以複製並轉儲到備份儲存的工作。為統一排程不同的資料備份作業,整合管理資料備份伺服器以及不同型別的備份儲存介質,企業需要規劃建設與業務系統架構相適應的資料備份系統。
作為資料安全的一道重要防線,穩定執行的資料備份系統是至關重要的。備份系統運維側重於關注備份作業是否出現報錯,備份儲存是否存在異常,出現異常或故障時如何去排查、分析、干預等方面。基於備份系統執行資料的收集及分析,來構建備份系統較全面的數字模型,主要用於解決以下三個痛點:
缺乏有效的故障預警:粗粒度、滯後性的運維方式增加了備份系統的故障率,進而影響了備份作業的成功率。
故障溯源困難:故障會導致執行錯誤,故障分析定位的過程則是從執行錯誤回溯到故障,找出錯誤源頭,這也是傳統運維方式的痛點之一。
系統管控能力不足:備份系統 不同於一般的業務系統,往往會忽略了運維的過程管理,包括配置管理、變更管理、容量管理等。如果系統管控能力不足,會大大增加運維風險,嚴重影響系統的穩定執行。
2. 設計策略
部分大資料、智慧化運維專案更注重於形,即先搭平臺,資料收集起來,再慢慢看能做什麼樣的資料分析和應用。這樣的設計策略沒有認識到資料質量的重要性,也輕視了系統執行規律和運維經驗的指導作用,系統的有效性大大降低。如果資料質量不高或缺失了某些關鍵指標資料,資料分析的結果必然會有偏差。
因此,總體設計策略應先關注領域分析,即有必要深入分析備份系統的整體架構,瞭解系統各元件之間的關係、資料流路徑;然後是資料的場景化設計,針對具體的運維場景確定資料分析及應用場景,再追溯確認需要採集的指標資料;最後詳細設計資料收集和資料分析方法。整體設計流程如圖 1 所示:
圖 1. 設計策略流程圖
3. 領域分析
3.1 備份系統整體架構
備份系統主要包括備份管理系統、備份客戶端、備份網路以及備份儲存介質這幾種元件,如圖 2 所示:
圖 2. 備份系統整體架構圖
備份管理系統
包括備份管理軟體和備份管理伺服器,承擔備份作業排程管理、備份儲存介質管理等責任,是典型的 C/S 架構,讀取備份客戶端資料,並將資料寫入備份介質中。
備份客戶端
執行備份任務的業務主機,是使用者感知層,一般需安裝備份軟體客戶端代理程式,並與備份服務端通訊。
備份網路
承擔備份資料流的傳輸任務,一般分為基於 TCP/IP 的備份 LAN 和基於 FC 的備份 SAN 。
備份儲存介質
承擔備份資料儲存的備份裝置或介質,常見的包括磁帶庫,虛擬帶庫, NAS 儲存等。
3.2 備份資料流
圖 3. 備份作業資料流圖
圖 4. 恢復作業資料流圖
4. 場景設計
4.1 故障管理場景
故障管理是運維場景中最重要的一環,一般可分為事前、事中、事後三個階段。事前階段的重點是評估分析,做好故障預防;事中階段則包括故障告警、故障處理和恢復;事後階段需要做好分析改進。下文將對備份系統常見的故障場景做具體分析。
4.1.1 作業時長增加
資料備份和恢復作業的時長增加是一種隱性故障,一般影響較小。但對於關鍵業務系統來說,超出備份時間視窗,帶來的影響有時也是無法容忍的;而資料恢復作業時長有時也決定了故障恢復時間長短。
資料備份恢復時長一般隨資料量的增長而緩慢增長,但異常情況下,備份恢復速度也會降低。在事前階段,我們可以判斷資料量是否有突增,可以提前調整備份時間;事中階段可關注資料吞吐量,如達不到速度預期,甚至嚴重超出備份時間視窗,可能需要及時中止備份恢復作業;事後階段主要是排查定位速度下降的原因,主要排查方向是備份網路頻寬被佔用、讀取資料來源的速度下降以及寫入備份儲存的速度下降這三類。
4.1.2 硬體故障
硬體故障的影響依賴於硬體冗餘情況,備份伺服器、備份網路、磁帶機、磁帶等等硬體都需要有冗餘,這種問題對備份系統的影響一般是一次性的。除了硬體裝置自身故障以外,還可能存在相容性問題導致的硬體故障問題,這類問題可能會間歇性的影響到備份作業的成功率,定位難度也比較高。
在事前階段,我們需要關注硬體自身的狀態,可提前預防硬體故障帶來的影響;事中階段,一般來說硬體故障會導致作業報錯,即使硬體自身狀態正常,但透過執行日誌能判斷到硬體故障的可能性較大,需要及時將故障硬體排除出去,先保障備份作業的成功率;事後階段,綜合執行日誌情況和故障處理情況,可進一步去定位是硬體自身故障還是相容性問題,為故障最終處理提供依據。
4.1.3 軟體異常
一般軟體異常指的是軟體提供的服務不達預期,可能是程式碼缺陷或服務異常終止,可以分為前端和後端異常,前端異常會導致備份恢復作業報錯,後端異常主要是影響 server 後端作業。前端異常涉及到備份軟體 server 和 client , client 影響的是使用該代理的備份作業, server 端的影響較大。
在事前階段,我們需要確認備份軟體程式和服務埠是否正常,防患於未然;在事中階段應根據作業報錯或受影響情況,結合執行日誌去判斷異常的軟體元件,從而權衡需要如何去幹預軟體執行中異常;事後階段則需要覆盤執行狀態和執行日誌,為後續類似的軟體異常能預防和定位,提供更多資料依據。
4.1.4 資源爭用
備份系統是一種 C/S 架構系統,會共享備份伺服器和備份儲存資源。資源共享會帶來資源爭用,也是資源容量不足引起的。典型的資源爭用引起的故障場景主要有磁帶機可用數量不足、備份伺服器計算資源或網路資源佔滿、備份儲存容量不足或服務能力不足,會帶來備份作業報錯或效能下降導致的作業超出時間視窗等不利影響。
在事前階段,我們需要做好資源排程規劃,合理配置不同時間段的備份任務;在事中階段,可以透過監視資源排程情況和執行日誌中的資源等待情況,及時判斷出是否發生了資源爭用,可及時中止以確保優先順序更高的作業任務的完成;事後階段則是根據執行中出現的資源爭用情況來修改資源排程規劃,必要時也可以申請更多的備份資源。
4.2 運維管理場景
運維管理是透過制度化、流程化、標準化的運維手段來指導 IT 系統的運維,是一套持續改進的機制。相比故障管理場景,運維管理場景更關注的是在平時運維工作中如何去應用備份系統執行資料,以達到持續改進最佳化的目的。透過資料收集及資料分析,可以更好地實現對備份系統管控,主要集中在下面幾個場景。
4.2.1 資料管理
資料管理的目標是保障資料安全可靠,對備份系統來說,個人認為主要是三點內容需要關注:一是定時備份作業是否成功,可透過收集備份作業結果來確認;二是重要的備份資料通常還會做資料複製,保持主備站點兩到三份相同的資料備份,需要定期確認資料是否成功同步;三是備份的資料需要有資料恢復驗證機制,可定期確認備份介質中資料的完整性,並針對不同資料型別的備份做資料恢復,以驗證資料正確性。
4.2.2 容量管理
備份系統容量管理工作中主要關注的是資料儲存和效能兩方面的容量場景。資料儲存容量場景關注多的是備份資料來源的容量增長趨勢、備份儲存介質可用容量等,及時做好容量預估,容量估算過程中還需要考慮到重複資料刪除和資料壓縮技術的應用;效能容量場景是對備份系統整體的服務能力做評估,評估備份作業併發的能力、資料傳輸的吞吐、備份客戶端和服務端的計算資源消耗情況等等。
4.2.3 配置管理
配置管理場景可以關注新增或最佳化的備份策略資訊以及備份介質中儲存的備份資料資訊。備份策略資訊包括主控伺服器、備份伺服器、備份客戶端、備份策略集、儲存策略、定時策略以及儲存庫等的詳細配置資訊,是備份管理軟體的核心邏輯資訊,需要妥善儲存;備份介質主要包括線上介質和離線介質,備份介質離線儲存後,更需要關注備份介質中儲存的備份資料資訊,以便即使調取訪問,該配置資訊變化頻率較快,需要保持最新版本的配置資訊。
4.2.4 監控最佳化
監控最佳化場景主要關注三個方向:一是豐富監控指標,二是監控閾值最佳化,三是告警關聯。原有的備份系統監控指標主要集中在備份系統軟硬體的執行狀態、備份作業的成功失敗情況,這些監控指標對於潛在故障的覆蓋程度不夠,系統執行日誌中的部分關鍵字也是監控的重點;監控指標中部分閾值設定時可能採用的是通用經驗方式,會出現告警誤報的情況,是需要更加系統執行情況來動態調整的;告警關聯則更利於故障溯源,利用運維經驗、系統規則可將分散的監控告警資訊關聯起來,便於定位故障。
4.2.5 統計報表
統計報表是運維工作中一項重要工作,可定期回顧系統執行情況。統計報表場景中,可結合執行資料訂製每日、每週、每月的執行情況定時報表,包括特定時間段內的不同備份資料物件的備份作業統計資訊,包括完成作業數、失敗作業數、執行中的作業數、備份儲存消耗情況等等。
5. 資料收集設計
場景設計確定了資料分析的應用場景,也進一步可以確定所需收集的資料。那麼資料收集設計的目標是至少涵蓋到已設計場景中所需的指標資料,並且這些指標資料可在多種資料來源中獲得。
設計總體目標是資料收集能夠兼顧到高效和低開銷,同時對 IT 系統來說是低影響、無風險的。具體設計方面可按照資料來源的不同進行分類,並針對不同資料來源設計不同的資料收集方法、資料採集週期以及採集的資料指標資訊。
5.1 執行日誌
備份軟體的執行日誌一般針對記錄不同的元件的執行日誌及其錯誤日誌,是研究備份系統執行的重要資料來源。日誌檔案有一定的固定格式,每一行日誌一般可分為日期、時間、日誌級別、詳細資訊等欄位,對應於一條記錄資訊,傳送到 Kafka ,並最終儲存到 ELK 。
備份軟體是 C/S 架構, server 與 client 的日誌採集方法和週期設定上會做區分。Server 端日誌資料較多,產生速度快,且不屬於一般業務系統,可以在 server 端伺服器上安裝 Log agent (可自己編寫日誌代理程式,也可使用 filebeat 等輕量級日誌採集工具)去實時採集;client 端伺服器上一般執行著業務系統,為降低對其他系統的影響,可設定定時任務,每分鐘執行指令碼將 client 日誌傳送到日誌伺服器上,再有日誌代理程式傳送資料。日誌採集的整體架構設計如圖 5 所示:
圖 5. 日誌採集架構圖
5.2 硬體裝置資訊
硬體裝置主要指的是備份儲存、磁帶庫、虛擬帶庫、 SAN 交換機等專有硬體裝置,一般可透過 snmp 輪詢、訪問硬體裝置 API 以及 CMD 命令輸出等方法來收集硬體狀態資訊,適宜於設定定時任務定時採集硬體裝置資訊。
硬體裝置上可採集的指標資料包括硬體整體及其各部件狀態資訊、硬體的邏輯配置拓撲和容量資訊、備份儲存控制器 CPU 負載、備份儲存 IO 頻寬和延時、 SAN 交換機對應埠的吞吐資料、網路埠 IO 錯誤計數器資訊等。
5.3 備份軟體介面資料
備份軟體也會有對應的 API 介面或 CMD 介面來獲取備份軟體的具體資訊,可自行程式設計定期抓取相關資料。備份軟體介面資料可分成配置資料和執行資料,其中配置資料的頻度較低,可以每天抓取一份資訊即可;而執行資料是動態的,變化頻率較高,定時抓取頻率可設為分鐘級。配置資料主要包括主控伺服器、備份伺服器、備份客戶端、備份策略集、儲存策略、定時策略以及儲存庫等的詳細配置資訊;執行資訊主要包括每日的定時備份作業以及其他後臺作業完成資訊、備份作業關聯的備份介質資訊、備份介質中儲存的備份資料資訊、軟體執行事件及告警資訊。
5.4 其他監控資料來源
其他監控資料來源中需要收集的資料主要是備份客戶端和服務端的作業系統效能資料 , 包括 CPU 負載、磁碟 IO 、網路卡 IO 吞吐資訊等監控系統中通用的監控資料指標,另外還需要收集備份軟體相關的程式和服務埠資訊。監控軟體一般都留有資料介面,也可以直接訪問監控資料庫直接獲取監控資料,資料的採集週期則依照其他監控資料域的更新頻率來設定。
6 資料分析設計
資料分析是處理加工收集到的資料,並對資料加以詳細研究和概況總結,提取有用資訊並形成結論。拋開一些具體的工具方法,我總結了一下日常運維中通用的資料經驗,主要是兩點:一是對技術的深入理解,我們會對不同型別的元件做分類,也會找出元件之間的各種關聯,這樣才能對一些技術更加了解;二是對資料變化的敏感性,比較典型的例子是我們對一個系統每日做巡檢, CPU 負載可能穩定在某些值附近或者在特定時刻才好發生數值突變,如果某一天 CPU 負載資料不再遵循這樣的波動規律,這種資料的變化就是我們需要捕獲並深入關注的。
在備份系統的具體資料分析工作中,可以從上文提到的資料場景出發來應用不同的資料分析方法,但我個人覺得也可以以場景為輔助,而從資料型別入手。上文已設計了不同資料來源的資料收集方法,個人覺得也可以分為靜態配置資料、動態執行資料以及日誌資料這三種型別資料。下文將詳細介紹這三種型別資料的資料分析方法。
6.1 靜態配置資料
在備份系統的資料分析中,靜態配置資料是骨。靜態配置資料的資料分析最適宜採用的方法是詳細分類和關聯分析,理清配置不同種類的資料元素以及它們之間關聯關係。
備份系統的配置資料主要包括硬體裝置及其元件的配置資訊、備份軟體層的備份策略資訊以及網路拓撲資訊等。關聯可分為簡單關聯、時序關聯、因果關聯。優先對配置資料進行分析,可以幫助我們理清備份作業的靜態時序資訊、備份作業和儲存資源的關係、硬體裝置間的聯絡、不同備份客戶端的基礎資訊以及架構拓撲資訊等。
6.2 動態執行資料
在備份系統的資料分析中,動態執行資料則是血肉。在靜態配置資料的分析結果的基礎上,動態執行資料可以提供更加詳細的關聯關係,不在是元素種類之間的關聯,而是具體元素之間的關聯;根據時序資訊,回溯歷史資料可以刻畫同一元素的資料趨勢圖;結合資料詳細分類結果,運用資料對比的分析方法,橫向比較可以刻畫出同型別元素之間的資料趨勢對比圖,縱向比較可以將現時與歷史一段時間內的資料趨勢做對比。
備份系統的動態執行資料主要包括硬體狀態、軟體程式執行狀態、作業執行資訊、網路 IO 資訊、備份儲存 IO 資訊、備份儲存使用資訊、備份伺服器系統資源使用資訊、事件及告警等。出了進一步完善分類與關聯關係外,備份系統執行資料的做單維度分析可以得到每日作業完成情況圖、整體儲存使用趨勢圖、備份網路 IO 趨勢圖、單個備份作業儲存資源使用趨勢圖、備份儲存 IO 趨勢圖等,如圖 6 所示;多維度分析可以得到不同客戶端使用的儲存資源對比趨勢圖、不同備份儲存使用情況對比圖及 IO 對比圖、不同備份作業 IO 與歷史資料對比圖等,如圖 7 所示。
6.3 日誌資料
在備份系統的資料分析中,日誌資料可以說是重要寶藏。目前主流的日誌分析工具解決了日誌儲存的方法,但主要是基於 Web 日誌分析,採用關鍵詞搜尋、詞頻統計等方法來做分析。而在備份系統執行的場景中,這方便了日誌檢索,我們還需要做的是基於日誌資訊來抽象串聯出備份系統執行中一個個子工作流程。
靜態與動態資料的資料分析已經相對生動了,但還是缺少很多細節資訊。我們就以一個備份作業的執行日誌為例,來串聯出這個例子的工作流程細節,如圖 8 所示:首先定時排程計劃被觸發,會先檢查客戶端狀態,然後按照定時計劃指令碼中的配置和備份策略資訊開啟備份作業會話,每一個備份作業會話會去申請磁帶機或其他備份資料儲存路徑,這時會話會處於等待狀態,直到申請的資源被滿足;介質管理元件接到資源申請後,會根據當前的資源使用情況和申請的優先順序,分配磁帶機及磁帶給對應的作業會話;一旦作業會話發現其申請的資源已被分配並被掛載後,這時客戶端會讀取 源資料,並 將資料傳輸到已掛載的備份儲存,直到作業會話結束;當所有作業會話都成功完成後,該作業才會返回成功。
圖 8. 備份作業工作流程細節
整個工作流程中,會以作業 ID 、作業會話 ID 、備份裝置 ID 等資訊與實際元件相對應,從而能還原出該備份作業的執行情況。如果其中某個子流程出現問題,透過日誌分析就能還原該故障過程,迅速定位故障對應的作業 ID 、會話 ID 、客戶端或備份裝置 ID 等。
結語
資料收集及分析工作是一項長期性的工作,需要持續改進、不斷最佳化的,這正如 IT 系統不斷演化,也如我們所從事的運維工作一樣,需要日積月累,才能日益精進。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69994525/viewspace-2784849/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 資料治理對運維資料體系的思考與啟發 | 運維進階運維
- Mysqldump備份說明及資料庫備份指令碼分享-運維筆記MySql資料庫指令碼運維筆記
- Oracle運維指令碼-收集統計資訊Oracle運維指令碼
- Linux系統資深運維工程師的進階祕籍Linux運維工程師
- 如何進行系統分析與設計
- DM聯機執行SQL語句進行資料庫備份SQL資料庫
- Elasticsearch 使用 NFS 進行資料備份ElasticsearchNFS
- 進階寶典一|SqlServer資料庫自動備份設定SQLServer資料庫
- Docker Swarm 進階:資料卷備份與恢復DockerSwarm
- Hadoop高階資料分析 使用Hadoop生態系統設計和構建大資料系統Hadoop大資料
- 使用MySQL Workbench進行資料庫備份MySql資料庫
- 初探MySQL資料備份及備份原理MySql
- Dedecms備份的資料檔案位置及備份資料庫的方法資料庫
- Jtti:CentOS系統中如何進行系統備份和恢復?JttiCentOS
- python使用多執行緒備份資料庫Python執行緒資料庫
- Shell多執行緒備份資料庫的指令碼執行緒資料庫指令碼
- 使用Handy Backup 6.2進行資料備份方法
- Oracle統計資訊的收集和維護Oracle
- Ghost備份及還原系統
- 前端進階演算法1:如何分析、統計演算法的執行效率和資源消耗?前端演算法
- 運維審計系統運維
- 企業資料庫安全管理規範 | 運維進階資料庫運維
- 11. shell多執行緒備份資料庫執行緒資料庫
- 系統日誌及資料庫相關資訊收集資料庫
- Linux運維進階之路Linux運維
- mongdb遭遇勒索,用備份進行資料恢復資料恢復
- 使用離線工具dmbackup進行資料庫備份資料庫
- [譯] 使用 Pandas 對 Kaggle 資料集進行統計資料分析
- 備份資料再利用:高頻、敏捷的運維需求,ZDBM滿足你敏捷運維
- mssql資料庫異地進行異地備份的方法SQL資料庫
- 如何使用傳統資料庫思維進行實時資料流分析? – thenewstack資料庫
- 如何建立SQL Server分析系統資料收集組BSSQLServer
- vivo 資料庫備份恢復系統演化資料庫
- 資料視覺化設計的小白高階進階攻略視覺化
- OLAP引擎:基於Druid元件進行資料統計分析UI元件
- 多執行緒程式設計進階——Java類庫中的鎖執行緒程式設計Java
- win10系統如何設定自動備份資料檔案Win10
- Linux系統Shell指令碼如何執行?linux運維繫統工程師Linux指令碼運維工程師