ecm系統内部故障-tft每日頭條

從這項研究中，我們得出了上一篇文章中表中總結的五個重要的高層次發現。下面詳細描述下這五個重要的發現。

3.1各種根本原因

找出硬件故障慢的根本原因是一項艱巨的任務，因為它可能由多種根本原因引起，如表3所示。硬件性能故障可能由設備内部的根本原因引起，如固件問題（FW）或設備錯誤/磨損（ERR），這将在第4節中讨論。然而，完美工作的設備也可能因許多外部根本原因而降級，如配置（CONF）、環境（ENV）、溫度（TEMP）和功率（PWR）相關問題，這些問題将在§5節中介紹。請注意，一份報告可能有多個根本原因（環境和電源/溫度問題），因此表3（112）中的總數大于101份報告。

根本原因

SSD

Disk

Mem

Net

CPU

Total

ERR

ecm系統内部故障（大規模系統中的亞健康故障）1

表4：不同硬件類型的亞健康故障症狀。該表描述了不同硬件類型出現的亞健康故障症狀。該表見第3.3節。永久性減速、瞬時減速、部分減速以及瞬時停止這四種症狀。

ecm系統内部故障（大規模系統中的亞健康故障）2

表5：無根本原因的亞健康故障症狀。該表見第3.3節。根本原因縮寫可在表3的标題中找到。永久性減速、瞬時減速、部分減速以及瞬時停止這四種症狀。

•永久性減速：第一個症狀（圖1a）是永久性減速，設備最初工作正常，但随後其性能下降，并且不會出現異常情況（直到手動修複問題）。該模式是四種模式中最簡單的，因為操作員可以始終看到問題。如表4所示，這種症狀（幸運的）是最常見的。

•瞬時減速：第二種（圖1b）是瞬時減速，其中設備性能在正常條件和顯著退化之間波動，這更難排除故障。例如，當環境太冷/太熱時，磁盤和網絡性能可能會降低，但當溫度恢複正常時，磁盤和網絡性能會恢複；當多個磁盤同時處于繁忙狀态時，偶爾會發生振動，這會使磁盤速度降低幾個數量級；而産生巨大負載的應用程序可能會導緻機架電源控制向其他機器提供的電源不足（降低其性能），直到耗電的應用程序完成。

•部分減速：第三種模式（圖1c）是部分減速，其中隻有設備的某些部分會出現減速。換句話說，這是部分故障停止轉換為部分減速的情況（§3.2）。例如，内存的某些故障部分需要執行更多ECC檢查；網絡路由器緩沖區的某些部分被破壞，隻會導緻受影響的數據包被重新發送；在一次事件中，40%的大數據包丢失，而小數據包沒有丢失。部分故障轉換成的亞健康模式還使調試複雜化，因為某些操作會經曆減速，但其他操作（在同一設備上）不會受到影響。

•瞬時停止：最後一個（圖1d）是瞬時停止的情況，設備偶爾會自行重新啟動，随後性能降至零。例如，一個有缺陷的固件使得SSD有時從RAID控制器“消失”，然後重新出現；SAS/SCSI命令中偶爾的位翻轉導緻主機總線适配器反複重新啟動；節點在熱節流閥上自動重新啟動（例如，當風扇固件沒有快速反應時）。

在一個（搞笑的）故事中，在數據中心，有一個方便的用于登台的桌子，一個操作員在存儲集群旁邊放了一把辦公椅。操作員喜歡坐在椅子上搖搖晃晃，反複将熱插拔驅動器從機箱中彈出（這是一個很難診斷的關聯）。

3.4連鎖原因和影響

亞健康故障的另一個複雜性是級聯事件鍊：首先，在實際的根本原因和硬件的亞健康故障之間，有一個級聯原因鍊。其次，亞健康故障的症狀會對高級軟件堆棧産生級聯影響，并可能對整個集群産生影響。

下面是導緻亞健康故障的長級聯根本原因的一些示例。計算節點中的一個風扇停止工作，使其他風扇以最大速度運行以補償死機風扇，從而導緻大量噪音和振動，進而降低磁盤性能。主闆中的一個有故障的傳感器向操作系統報告了一個錯誤的值，使得CPU在節能模式下運行速度變慢。電源中斷導緻的電源不足可能會導緻許多類型的硬件、磁盤、處理器和網絡組件運行不理想。電源故障本身也可能引起亞健康故障，例如，供應商遺漏了一個120V保險絲，該保險絲與故障電容器一起裝運，在電源循環時，故障電容器極有可能短路，從而導緻小電氣火災，并串接至機架級電源故障。

接下來，當硬件進入亞健康狀态速度變慢時，它不僅會影響主機，還會在整個集群中造成級聯影響。例如，一台機器中的降級NIC（從1 Gbps到1 Kbps）會導緻連鎖反應，從而減慢整個100台機器集群的速度（因為受影響的連接任務會占用容器/信号很長時間，并且由于信号不足，新作業無法運行）。在HDFS HA（高可用性）部署中，當其中一個磁盤速度非常慢時，名稱節點的仲裁将挂起。在HBase部署中，存儲卡以正常速度的25%運行會導緻積壓、内存不足和崩潰。類似地，一個降級的磁盤創建了一個一直到客戶機VM的積壓工作，給用戶彈出了“死亡藍屏”；

3.5罕見但緻命：長檢測時間

我們報告中的亞健康故障事件需要數小時甚至數月才能檢測（精确定位）。更具體地說，1%的問題在幾分鐘内發現，13%在幾小時内發現，13%在幾天内發現，11%在幾周内發現，17%在幾個月内發現（未知時間為45%）。一些工程師稱之為“昂貴的調試尾巴”。在一個故事中，整個工程師團隊被拉去調試這個問題，花費了該機構數萬美元。檢測時間（TTD）過長的原因有很多。

首先，亞健康故障的發生率沒有故障停止案例那麼頻繁，這一事實意味着當今的軟件系統不能完全預見（即破壞）這種情況。因此，雖然可以快速解決更頻繁的故障，但頻率較低但更複雜的故障（系統無法緩解）可能會大大耗費工程師的時間。

第二，如前所述，根本原因可能不是由亞健康的硬件引起的（例如，§3.3中的耗電應用程序導緻的瞬時減速需要幾個月的時間才能解決，因為問題并非源于速度緩慢的機器或電源）。

第三，超出操作員控制範圍的外部環境條件可能延長診斷時間（例如，數月來，供應商未能在其低水位測試設施中再現亞健康故障減速症狀，因為硬件僅在高水位時減速）。

最後，運營商并不總是能夠完全了解整個硬件堆棧（例如，由于運營商無法了解電源設備的運行狀況，因此事件需要幾天時間才能解決）。

Comments

Welcome to tft每日頭條 comments! Please keep conversations courteous and on-topic. To fosterproductive and respectful conversations, you may see comments from our Community Managers.