透過谷歌當機事故看儲存運維三大重要趨勢
近日,谷歌又出現大面積癱瘓事件,導致全球範圍內多款Google服務崩潰,這已經是谷歌近半年第三次出現大規模當機事件,堪稱上演當機“帽子戲法”。
回顧此次當機事件,谷歌在出現當機之後的反應倒是挺快。根據谷歌雲官方推特表述,經過谷歌運維工程師近50分鐘的緊急處理,相關服務在當地時間凌晨4點32分恢復正常,真是“ 同是天涯運維人,凌晨加班曾相識”。
再來看看此次當機事件的“元兇”--“internal storage quota issue”,谷歌後續的一份初步調查報告中稱:此次當機的原因是“我們的自動配額管理系統出現了問題,降低了谷歌中央身份管理系統的容量,導致其在全球範圍內返回錯誤。因此,我們無法驗證使用者請求是否經過認證,並向使用者提供錯誤。”
何謂“自動配額管理”問題?難道之前大部分媒體報導的“磁碟寫滿”當機原因都是錯的?亦或是“磁碟寫滿”是表象,“自動配額管理”才是誘因?帶著好奇心,大資料線上小編找到了資深儲存專家李工,請他詳細分析了此次谷歌當機事件背後的大瓜。
請教完大神之後,小編對資料中心當前運維情況進行了一番調研。現階段,金融、政務、交通等行業的資料中心,無論是規模、裝置數量還是應用種類、複雜性都遠勝過去。Gartner首席分析師Pankaj Prasad分析,企業IT基礎架構和應用程式所產生的資料量正以每年2-3倍的速度增長,其中像指標、日誌等機器所產生的資料型別多樣且增長迅速,未來會給運維帶來極大挑戰。
根據相關調查資料顯示, 隨著全球資料規模的爆炸性增長,在企業資料中心的故障中,儲存裝置相關故障已經佔到70%以上,成為資料中心故障的“主力軍”,以某國際網際網路社交企業為例,每天需要修復資料24TB,每天因修復帶來的跨機架流量高達180TB。並且,近期銀行、證券等金融行業也是頻頻故障癱瘓,有著深厚先進技術積累的科技、金融領域企業尚且在運維上頻頻觸礁,其他領域的風險和困境可想而知。
可以說,解決儲存裝置故障問題等於給資料中心買來一份“保險”。顯然,在資料中心技術和新應用的層出不窮的今天, 傳統運維依然高度依賴人的經驗和人的精力,運維人員就像一群救火隊員,不是在解決問題就是在解決問題的路上,以至於好多運維人員感嘆自己是操著賣白fen的心賺著賣白菜的錢。。。
如何拯救運維人員於水火之中?徹底解決資料中心複雜化帶來的運維複雜化?智慧運維絕對是大勢所趨,小編也大致分析了一下當前智慧運維解決方案的近況。當前,智慧運維圍繞裝置異常、容量預警等關鍵場景,融入AI相關特性,讓運維走向自動化和智慧化,但號稱智慧運維解決方案的多如牛毛,你搜尋一下,搞不好是“X田系”搞的……小編又請教了一下儲存大牛老李,他說需要從三個方面來衡量一款智慧運維解決方案的優劣。
首先需要具備容量預測能力(裝置側+雲端均具備)。假設客戶能夠提前預知陣列或儲存池,甚至是更細粒度物件的容量變化趨勢,那麼容量配額不足導致服務當機的發生可能性則會大大降低。智慧運維解決方案需要雲上+本地聯動運維能力,並且能夠基於時序預測等關鍵技術,最好可以向客戶提供未來最長365天的容量趨勢預測,並能夠提前預警80%配額,提醒使用者提前擴容。
其次需要具備風險盤預測能力(異常檢測模型服務提前14天預測硬碟故障),智慧運維方案需要每日採集資料中心硬碟資料(硬碟ID、SN、硬碟非安全斷電次數、通電時長),從歷史資料中識別硬碟不同屬性的突變模式對當前狀態進行預測,結合使用者反饋資料,定期執行模型自最佳化,持續提升預測精度,並且為資料中心硬碟提供主動運維。風險盤預測能力考驗的是方案商的演算法模型能力,突變模型服務企業越多、模型訓練越久,識別風險故障就越正確。
如果廠商一上來就說自己模型準確率高達99.9%,這十有八九是騙子,勸你趕緊報警。
最後,具備儲存效能異常預測管理能力(圍繞儲存效能相關問題提供全面分析處理方案)。這種能力又分為三塊:第一是效能預測及潮汐預警,需要基於時間序列預測等關鍵技術的效能預測特性以及基於閾值觸發的效能潮汐預警,能夠讓客戶預知裝置關鍵效能指標變化趨勢(如時延、IOPS、塊頻寬),提早發現裝置效能瓶頸點,輔助客戶儘早規避可能發生的異常;
另外,第二是效能異常檢測與根因定界分析,針對“傳統的專家經驗規則或靜態閾值預警,無法覆蓋大多數效能異常場景,且可能存在誤報漏報的情況”,方案可以基於機器學習的關鍵效能KPI異常檢測及根因定界特性,無監督自學習的異常檢測模型能夠實時檢測裝置時延是否異常,異常檢測準確率越高越好;另外有些廠商在儲存裝置中內建基於多整合樹演算法融合模型,外加皮爾遜相關性關聯分析演算法,實現異常根因的定界分析,大幅提升客戶發現效能問題、定位問題邊界的效率。
第三就是常見效能故障自修復,有能力將逐步實現異常場景的快速自愈,降低客戶運維門檻,降低客戶運維成本,實時保障客戶業務不受干擾。
小編又進一步調研了當前的市場情況,在眾多資料中心智慧運維解決方案中,以華為為代表中國廠商的解決方案近年來不斷進步,甚至達到了業界領先水平。以華為資料管理引擎DME為例,目前在銀行、證券、政府等多個行業廣泛應用,在保護使用者資料隱私的前提下,有效地幫助金融等行業使用者構建構築端到端的感知能力、智慧的分析能力以及可信的執行能力來實現運維自動化閉環,大幅提升運維和資源利用效率。
面向未來,隨著智慧運維技術的不斷成熟與完善,小編相信資料中心運維人員不再是那個忙得四腳朝天的“熱鍋螞蟻”,而是故障圍困萬千重,我自巋然不動,任憑風雲起,穩坐釣魚臺,談笑間,故障已灰飛煙滅。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69965091/viewspace-2744526/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 看2024年儲存趨勢的七大預測
- 浪潮儲存基於智慧運維技術,加速儲存自治運維
- 展望2015儲存趨勢 浪潮將發力高階儲存
- 自動化運維的發展趨勢介紹!運維
- Ceph分散式儲存-運維操作筆記分散式運維筆記
- 資料儲存技術的演進趨勢研判
- Redis Cluster 當機引發的事故Redis
- SQL Server 儲存過程的運用SQLServer儲存過程
- 透過運維編排實現自動化智慧運維與故障自愈運維
- TimesTen常用維護內建的儲存過程[TimesTen運維基礎]儲存過程運維
- Linux運維命令重要嗎?運維入門Linux運維
- 全場景資料保護儲存應用趨勢
- 什麼是YottaChain儲存,為什麼說是未來資料儲存的趨勢?AI
- 摩杜雲:物件儲存可以透過哪些方式使用?物件
- 使用error stack 抓取儲存過程的當前SQLError儲存過程SQL
- 儲存比展現更重要
- 什麼是Linux?Linux運維未來發展趨勢Linux運維
- 自動化運維發展趨勢以及好用工具推薦運維
- 銀行智慧運維探索:打造通用指標趨勢預測模型運維指標模型
- Mybatis中運用小技巧(三)儲存過程的運用MyBatis儲存過程
- 當開發遇到運維運維
- 2020 儲存技術熱點與趨勢總結
- 執行緒池運用不當的一次線上事故執行緒
- 透過現象看本質,圖解支援向量機圖解
- MySQL儲存過程詳解 mysql 儲存過程MySql儲存過程
- Clobotics 計算機視覺場景儲存實踐:多雲架構、 POSIX 全相容、低運維的統一儲存HB計算機視覺架構運維
- 當前CRM軟體市場趨勢
- oracle plsql儲存過程_運算子優先順序OracleSQL儲存過程
- AI儲存的需求是什麼?未來趨勢是怎樣的?AI
- 儲存過程與儲存函式儲存過程儲存函式
- 透過視覺化運維配置,實現故障秒級自愈視覺化運維
- 由中行IBM大型機當機談銀行系統運維IBM運維
- 儲存過程儲存過程
- 機器人當前的六個發展趨勢,你造嗎?機器人
- 如何透過Hibernate/JPA在MySQL中儲存UTC時區?MySql
- MySQL怎樣透過Adjacency List儲存樹形結構?MySql
- 突如其來的當機,不知所措的運維!運維
- SQL學習-隨機數,儲存過程SQL隨機儲存過程