遠離宕機?存儲自動運維了解一下

2020-12-24 和訊科技

  美國太平洋(601099,股吧)時間12月14日凌晨3點47分左右,YouTube、Google雲端硬碟,Gmail,Google Meet,Google文檔,Google搜索,Google Play,Google Home,Google Maps停服,這是谷歌近半年內第三次出現大規模宕機事件。

  經過近50分鐘的緊急處理,相關服務在當地時間凌晨4點32分恢復正常,並向受到該問題影響的所有用戶表示歉意。

  至於這次宕機的原因,來自谷歌官方的表述是「internal storage quota issue」。在谷歌后續的一份初步調查報告中,提到導致宕機的原因為「我們的自動配額管理系統出現了問題,降低了谷歌中央身份管理系統的容量,導致其在全球範圍內返回錯誤。因此,我們無法驗證用戶請求是否經過認證,並向用戶提供錯誤。」

  那麼,這個「自動配額管理」是什麼意思呢?

  存儲專家解釋道,數據在存儲盤中的存放,並不是「既來之,則安之」,而是需要規劃一個存儲池,被劃在這個池中的數據只能在對應的空間中存放。池子有多大,就是通過上面的「配額」來管理的。

  這次導致谷歌宕機的「自動配額管理系統出現了問題」,就好比我們去坐火車,先要有一張票,才能上車。但是現在售票員在工作時間划水跑了,大家沒有買到票,結果人在站外著急瞪眼,車在站裡空空如也。

  想要徹底避免類似問題,就需要我們的運維工作不僅僅監控磁碟是否寫滿並報警,還要做出資源池級別的容量監控,以便更進一步做出提前預測,避免自動額度管理系統「罷工」。華為AI運維提供面向池級、盤級、系統級的容量閾值監控、容量預測告警,同時,華為也提供自動資源發放管理的能力。

  近期,科技巨頭公司、證券公司頻頻故障癱瘓,影響小則波及一個區域,大則波及全球。IT基礎設施層面的高可靠構築誠然是前提,是「金剛鑽」,但問題往往出現在運維階段,「手藝」怎麼樣,才是決定「瓷器活」能否做成的決定性因素。

  有著深厚先進技術積累的科技、金融領域企業尚且在運維上頻頻觸礁,其他領域的風險和困境可想而知。

  調查數據顯示,隨著全球數據規模的爆炸性增長,企業數據中心的故障中,存儲設備相關故障已經佔到70%以上。以某國際網際網路社交企業為例,每天需要修複數據高達24TB,每天修復帶來的跨機架流量高達180TB。技術和新應用的層出不窮,也帶來運維複雜化的副作用。

  傳統的運維高度依賴人的經驗和精力,運維人員的一天就是從虛機、存儲,再到數據、網絡,更像一名企業的救火隊員。在全球產業邁進數位化、智能化的背景下,如何使能統一的AI運維,扭轉傳統「人拉肩抗」的局面,從而實現支持企業業務平穩運行,業務戰略突破的目標,已經逐漸成為全球行業頭部企業的共同訴求:

  01

  首先,運維系統從一個追求穩態的系統,走向追求穩態+敏態的系統。這就意味著,運維系統不僅要追求7*24小時的穩健運行,還要追求對業務的敏捷使能。

  02

  其次,運維已經不僅僅只是一個支撐系統,更多的是要與業務融合,成為一個生產系統,給業務帶來新的價值;

  03

  最後,運維的流程將慢慢地從「以人為中心」向「面向自動化的業務流程重構」,最終走向「自動駕駛」的IT運維系統。

  在數據基礎設施運維層面,運維的自動化水平是數位化轉型的核心體現之一。特別是面向核心系統或新興業務,運維將更多地參與到生產系統中去,運維與業務的結合會越來越緊密。

  只有讓更多的運維人員從繁雜的例行工作解放出來,才能投入到更加有創新性的工作中去。華為存儲基於智能運維平臺DME逐步構建面向智能運維的AI能力,圍繞客戶關心的設備異常、容量預警等關鍵場景為客戶業務的正常運行保駕護航。

  具體來看看華為智能存儲運維有哪些「法寶」?

  設備側+雲端容量預測

  假設客戶能夠提前預知陣列或存儲池,甚至更細粒度對象的容量變化趨勢,那麼,由於容量配額不足所導致的服務宕機情況則會大大減少。華為提供「雲上+本地」聯動的運維能力,基於時序預測等關鍵技術,能夠向客戶提供未來最長365天的容量趨勢預測,並能夠提前預警80%配額,提醒用戶提前擴容。

  提前14天風險盤預測

  如今,通過華為存儲的異常檢測模型服務,可以提前14天預測到硬碟故障。華為硬碟異常檢測模型服務基於S.M.A.R.T.(Self-Monitoring Analysis and Reporting Technology)技術,每日採集數據中心硬碟數據(硬碟ID、SN、硬碟非安全斷電次數、通電時長),從歷史數據中識別硬碟不同屬性的突變模式對當前狀態進行預測,結合用戶反饋數據,定期執行模型自優化,持續提升預測精度。為DC硬碟提供主動運維。

  截止目前,華為硬碟異常檢測模型已經服務於200+企業DC,幫助客戶提前14天識別硬碟故障或風險,預測的誤報率低於0.1%。

  存儲性能異常預測管理

  基於時間序列預測等關鍵技術的性能預測特性,以及基於閾值觸發的性能潮汐預警,能夠讓客戶預知設備關鍵性能指標變化趨勢。時延、IOPS、塊帶寬盡在掌握,以提早發現設備性能瓶頸點,輔助客戶儘早規避可能發生的異常。

  傳統的專家經驗規則或靜態閾值預警,無法覆蓋大多數性能異常場景,且可能存在誤報漏報的情況。華為提供基於機器學習的關鍵性能KPI異常檢測及根因定界特性,無監督自學習的異常檢測模型能夠實時檢測設備時延是否異常,現網數據測試驗證,異常檢測準確率近90%;存儲設備內置基於多集成樹算法融合模型,外加皮爾遜相關性關聯分析算法,實現異常根因的定界分析。

  華為智能存儲引擎DME基於「雲-中心-設備」三層AI架構,攜手客戶在智能運維的自動駕駛之路上不斷創新,持續擴大自動化的邊界。從被動運維走向主動運維,持續降低運維門檻及成本,實時確保客戶業務體驗最優。

本文首發於微信公眾號:略懂的小咖。文章內容屬作者個人觀點,不代表和訊網立場。投資者據此操作,風險請自擔。

(責任編輯:張洋 HN080)

相關焦點

  • 透過谷歌宕機事故看存儲運維三大重要趨勢
    再來看看此次宕機事件的「元兇」--「internal storage quota issue」,谷歌后續的一份初步調查報告中稱:此次宕機的原因是「我們的自動配額管理系統出現了問題,降低了谷歌中央身份管理系統的容量,導致其在全球範圍內返回錯誤。因此,我們無法驗證用戶請求是否經過認證,並向用戶提供錯誤。」
  • 微博為何總宕機?
    微博方面回應稱,確實是發生宕機,原因是流量瞬間暴增,超出伺服器最大訪問閥值。並稱後續將仔細復盤,加強技術儲備,完善應對方案。發生了幾次宕機事件後,吃瓜群眾們對此表示已經習慣,甚至很多人認為,如果明星突然宣布結婚或分手微博還沒宕機,只能證明該明星還不夠火。今年的兩次宕機,發生在「志玲姐姐」結婚和「範爺」分手上。
  • NAS數據遷移到對象存儲太麻煩?90分鐘納管1000萬文件了解一下
    在交付廣發證券檔案中心對象存儲項目時,客戶原有NAS存儲了近6000萬文件,總容量近40TB,客戶利用業務空窗期通過傳統方式進行歷史數據搬遷,耗時長達2個月,運維工作也需要持續的人力投入。如果對象存儲能夠快速納管能力,業務上線時間將會大幅縮短,運維人力將得到釋放,客戶效益也將進一步提升。
  • 智能運維:質心算法實現網絡故障無差別自動定位
    作者簡介朱鋒廣東行動網路運維監控專家謝謝大家,其實很榮幸今天來到這個舞臺來講這些東西,我今天的主題是叫智能運維,我們用的質心算法實現網絡故障無差別自動定位今天上午講的平臺我不太懂,架構我接觸的也比較少,所以說今天只能講一個我實際工作當中的案例,其實是一個小而美運維的實踐。看到目錄就和他們不太一樣,大家都是做運維的,都知道運維的困難非常多,但是我們運維人的辦法更多,辦法比困難多,很多辦法的效果還不錯,特別在 DevOps 時代,運維開發,然後人工智慧這些工作,運維的未來其實是非常值得期待的。
  • 揭秘本月幾樁離奇宕機事故
    這兩起宕機事故,目前宕機故障報告還未出現,具體宕機原因還未可知。不過除了今天的宕機事件,本月已經有不少網際網路巨頭因各種奇葩的理由而宕機,比如騰訊雲、谷歌、百度等。北京時間11月11日,谷歌旗下的雲服務、YouTube等網絡服務在全球範圍內均發生了數小時的宕機,外媒稱因遭到來自中國電信IP的BGP劫持導致故障發生。
  • 企業級分布式高性能KV存儲資料庫,騰訊Tendis正式開源
    比特網了解到,Tendis使用了去中心化集群架構,每個數據節點都擁有全部的路由信息,用戶可以訪問集群中的任意節點,通過redis的move協議,使路由到達正確的節點。   據悉,節點之間通過gossip 協議進行通訊,類似於redis cluster的分布式實現,可指定 hashtag 來控制數據分布和訪問,使用和運維成本極低。   適合的場景   1、兼容Redis協議,需要大容量且較高訪問性能的溫冷數據存儲場景。
  • 【IDCC2020】廣東浩雲長盛網絡股份有限公司全國運維總經理朱紅兵...
    我們再看一下數據中心運營的痛點,第一個痛點就是宕機的風險,事故的種類大概有三大類,第一類是設備類的,包括UPS、發電機、空調,因為我們的設備跟生物體一樣也有生命周期,設備本身也有磨合期、穩定期、衰退期,設備天然的性能落後這是一個大的原因;第二個原因是人為的原因,第三個是自然災害環境的原因。設備的故障通過有效地預防性維護手段進行降低。
  • IT巨人的血液——IT統一運維軟體
    IDC《中國IT統一運維軟體產品市場跟蹤報告,2019年下半年》報告顯示,IT統一運維軟體市場總體規模在2019年達到5.2億美元規模,處於平穩上漲趨勢。
  • 微博宕機復盤:什麼樣的技術架構,可支持80個明星並發出軌?
    發生了幾次宕機事件後,吃瓜群眾們對此表示已經習慣,甚至很多人認為,如果明星突然宣布結婚或分手微博還沒宕機,只能證明該明星還不夠火。 今年的兩次宕機,發生在「志玲姐姐」結婚和「範爺」分手上。 6月6日,林志玲結婚喜訊宣布後,在微博搜索上林志玲的名字顯示搜索失敗,請重試。
  • 熱點一波接一波,吃瓜群眾幾度崩潰,微博為何總宕機?
    為什麼微博總是宕機?隨著5G時代來臨,邊緣計算廣泛應用後,宕機情況還會繼續發生嗎?衡量明星火不火就看微博是否為他宕機過不得不承認,明星的內容與流量支撐起了微博的大半江山。每次明星爆出熱點事件,觀眾都會第一時間奔向微博吃瓜,瞬間湧入的流量也直接導致了微博宕機。
  • 騰訊宣布企業級分布式高性能KV存儲資料庫Tendis正式開源
    所有節點之間通過 gossip 協議進行通訊,類似於 redis cluster 的分布式實現,所有節點通過 gossip 協議通訊,可指定 hashtag 來控制數據分布和訪問,使用和運維成本極低。
  • 如何使用 K8s 兩大利器"審計"和"事件"幫你擺脫運維困境?
    集群的節點發生了自動擴容,是什麼觸發的?什麼時間觸發的?以前,排查這些問題,對客戶來說並不容易。從騰訊雲容器團隊長期運維 K8s 集群的經驗來看,審計和事件並不是可有可無的東西,善用它們可以極大的提高集群的可觀測性,為運維帶來巨大的便利。下面讓我們先來簡單認識一下它們。什麼是 Kubernetes 審計?
  • 交通銀行數據中心網絡運維數位化轉型探索
    如何高質量、高效率地運維龐雜的網絡環境,已經成為網絡運維人員的必答題。2019年起,交通銀行數據中心啟動了智能數據中心建設,開啟了運維工作智能化轉型的序幕。在此背景下,網絡部依託大數據、遠程遙測等技術建成了網絡運維數據中臺,喚醒了海量的網絡運維數據,並在此基礎上結合自動化、可視化、智能化等運維手段和清單革命等先進的運維管理理念,邁出了網絡運維的數位化轉型之路。
  • 騰訊開源分布式存儲系統 Tendis,可完全兼容 Redis
    近日,騰訊宣布開源一個與 Redis 協議完全兼容的高性能分布式存儲系統 Tendis。
  • 谷歌服務全球範圍癱瘓,宕機45分鐘,原因是磁碟滿了?
    據了解,在北京時間晚7:50左右,谷歌旗下的Gmail,YouTube,Google Map,AdSense,Google Pay,Google Home,Nest等產品均出現了中斷服務大規模的宕機,導致谷歌用戶根本無法登入帳號,正常使用服務。
  • 「機器人管家」調配資源 智能化運維實現精準管理
    原標題:「機器人管家」調配資源 智能化運維實現精準管理 在數位技術日新月異的當今,運維智能化重要性愈發成為工業界的共識。近日,由清華大學、中國移動、中國計算機協會網際網路專業委員會主辦的第三屆國際智能運維(AIOps)挑戰賽決賽在杭州舉行,旨在加強工業界與學術界的交流,促進AIOps技術的迅速發展和落地。 來自全國產學研各界的141個企業與高校團隊、673名選手報名參賽。經過五個多月的激烈角逐,微眾銀行智能運維團隊首次參賽便挺進六強,最終獲得全國季軍。此次挑戰賽的課題是「微服務」應用系統的故障排查。
  • 全球敏捷運維峰會(Gdevops)即將於上海盛大收官
    、對敏捷運維的定義與革新、運維人員在技術更迭中的迷思與挑戰,我們一一道來。 王喆(廣東移動南方基地資深雲架構師,高級運維開發工程師)《跬步千裡:移動雲網絡自動運維之路》首度曝光:本演講主要分享中國移動自有公眾服務雲「移動雲」的相關實踐經驗,其中涉及一款小型、輕量的網絡設備自動運維工具Forward,將詳細介紹其構建原理及核心邏輯,以應對複雜的網絡運維場景
  • 華青融天戰略拓展總監王旭詳解IT運維的九陽神功
    如果系統已經出現了性能劣化,甚至應用已經宕機,你肯定不希望明天早晨才發現。所以,對於應用監控系統來說,性能計算和告警的時效性是關鍵,第一時間發現問題先兆,聽風辨器、及時預警、防患於未然,才是運維的最高境界。業界往往把數據分為熱數據(實時)、溫數據(warm)和冷數據,對於關鍵性的業務監控系統而言,對於數據的要求一定是最高熱度的,正所謂至陽熱氣。
  • 破解運維告警管理「老大難」?AnyRobot智能告警來出招!
    實時告警難:現有監控告警工具迫於系統持續穩定運行的要求,告警通知不及時,導致業務運營緩慢或中斷,存在業務宕機風險;海量告警信息處理難:單一告警規則設定下,監控越精準,告警規則設定越多。一旦有告警產生,運維人員就淹沒在海量告警信息中,故障處理效率低下;告警故障根源定位難:跨系統應用的監控指標多重依賴,無法快速排查關鍵告警,難以快速定位故障根源;告警信息管理難:告警規則複雜多變,運維人員很難對告警規則進行快速、靈活管理,並且難以將告警規則快速應用於多種告警場景,造成運維管理成本增加。