☰

序幕：

tag-icon • tag-icon performance hard-drive hardware-raid sata sas
序幕：

序幕：

我是一個代碼猴子，越來越多地承擔我的小公司的系統管理員職責。我的程式碼就是我們的產品，我們越來越多地提供與 SaaS 相同的應用程式。

大約 18 個月前，我將我們的伺服器從以高級託管為中心的供應商轉移到了 IV 級資料中心的準系統機架推式伺服器。 （就在街對面。）這需要我們自己做更多的事情——例如網路、儲存和監控。

作為重大舉措的一部分，為了替換我們從託管公司租用的直連存儲，我構建了一個基於 SuperMicro 機箱、3ware RAID 卡、Ubuntu 10.04、兩打 SATA 磁碟、DRBD 和 .這一切都被精心記錄在三篇部落格文章中：建置並測試新的 9TB SATA RAID10 NFSv4 NAS：第一部分,第二部分和第三部分。

我們也設定了 Cacti 監控系統。最近，我們新增了越來越多的數據點，例如 SMART 值。

如果沒有驚人的 科學家 在 伺服器故障。這是一次有趣且有教育意義的經驗。我的老闆很高興（我們省了一桶$$$），我們的客戶很高興（儲存成本下降）， 我很高興（有趣，有趣，有趣）。

直到昨天。

斷電與恢復：

午餐後一段時間，我們開始收到我們的應用程式（一個點播串流 CMS）表現緩慢的報告。大約在同一時間，我們的 Cacti 監控系統發送了大量電子郵件。更能說明問題的警報之一是 iostat wait 的圖表。

在此輸入影像描述

效能變得如此嚴重，以至於 Pingdom 開始發送「伺服器關閉」通知。整體負載適中，沒有出現流量高峰。

登入應用程式伺服器、NAS 的 NFS 用戶端後，我確認幾乎所有東西都經歷了高度間歇性和異常長的 IO 等待時間。當我跳到主 NAS 節點本身時，在嘗試導航問題陣列的檔案系統時，同樣的延遲也很明顯。

是時候進行故障轉移了，一切順利。 20 分鐘內，一切都被確認已恢復並完美運行。

屍檢：

在發生任何和所有系統故障後，我都會進行事後分析以確定故障原因。我做的第一件事是 ssh 回到盒子並開始查看日誌。它完全離線了。是時候去資料中心一趟了。硬體重置、備份並運作。

我/var/syslog發現了這個看起來很可怕的條目：

Nov 15 06:49:44 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_00], 6 Currently unreadable (pending) sectors
Nov 15 06:49:44 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_07], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 171 to 170
Nov 15 06:49:45 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_10], 16 Currently unreadable (pending) sectors
Nov 15 06:49:45 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_10], 4 Offline uncorrectable sectors
Nov 15 06:49:45 umbilo smartd[2827]: Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
Nov 15 06:49:45 umbilo smartd[2827]: # 1  Short offline       Completed: read failure       90%      6576         3421766910
Nov 15 06:49:45 umbilo smartd[2827]: # 2  Short offline       Completed: read failure       90%      6087         3421766910
Nov 15 06:49:45 umbilo smartd[2827]: # 3  Short offline       Completed: read failure       10%      5901         656821791
Nov 15 06:49:45 umbilo smartd[2827]: # 4  Short offline       Completed: read failure       90%      5818         651637856
Nov 15 06:49:45 umbilo smartd[2827]:

所以我去檢查陣列中磁碟的仙人掌圖。在這裡我們看到，是的，磁碟 7 正在消失，就像 syslog 所說的那樣。但我們也看到磁碟8的SMART Read Erros在波動。

在此輸入影像描述

系統日誌中沒有有關磁碟 8 的訊息。更有趣的是磁碟 8 的波動值與高 IO 等待時間直接相關！ 我的解釋是：

  • 磁碟 8 遇到奇怪的硬體故障，導致間歇性長時間運作。
  • 不知何故，磁碟上的這種故障情況鎖定了整個陣列

也許有更準確或更正確的描述，但最終結果是一個磁碟影響了整個陣列的性能。

問題

  • 硬體 SATA RAID-10 陣列中的單一磁碟如何使整個陣列突然停止？
  • 我是否天真地認為 RAID 卡應該處理這個問題？
  • 如何防止單一故障磁碟影響整個陣列？
  • 我錯過了什麼嗎？

答案1

我討厭在關鍵生產環境中說“不要使用 SATA”，但我經常看到這種情況。 SATA 磁碟機通常不適用於您描述的佔空比，儘管您確實指定了專為 24x7 運作而設計的驅動器在你的設定中。我的經驗是，SATA 硬碟可能會以不可預測的方式發生故障，通常會影響整個儲存陣列，即使在使用 RAID 1+0 時也是如此，正如您所做的那樣。有時，驅動器發生故障會導致整個匯流排停頓。需要注意的一件事是您是否在設定中使用 SAS 擴展器。這可能會對剩餘磁碟受磁碟機故障的影響產生影響。

但與它一起使用可能更有意義中線/近線 (7200 RPM) SAS 驅動器與 SATA 相比。與 SATA 相比，價格稍有溢價，但驅動器的運作/故障更加可預測。 SAS 介面/協定中的糾錯和報告功能比 SATA 集更強大。所以即使有驅動器其機制相同，SAS 協定差異可能可以避免您在磁碟機故障期間經歷的痛苦。

答案2

單一磁碟如何導致陣列癱瘓？答案是不應該，但這取決於導致中斷的原因。如果磁碟以正常的方式死亡，它不應該把它取下來。但它可能會以控制器無法處理的“邊緣情況”方式失敗。

你是否天真地認為這不應該發生？不，我不這麼認為。像這樣的硬體 RAID 卡應該可以解決大多數問題。

如何預防呢？你無法預料到像這樣奇怪的邊緣情況。這是系統管理員的一部分......但您可以製定恢復程序以防止其影響您的業務。現在嘗試解決此問題的唯一方法是嘗試另一個硬體卡（可能不是您想要做的）或將磁碟機變更為 SAS 磁碟機而不是 SATA，以查看 SAS 是否更強大。您也可以聯絡您的 RAID 卡供應商，告訴他們發生了什麼事，看看他們怎麼說；畢竟，他們是一家應該專門了解不穩定的驅動電子設備的來龍去脈的公司。如果您能找到合適的人交談，他們可能會就驅動器的工作原理以及可靠性提供更多技術建議。

你錯過了什麼嗎？如果要驗證磁碟機是否有邊緣情況故障，請將其從陣列中拉出。陣列將被降級，但您不應該遇到更多奇怪的減速和錯誤（除了降級的陣列狀態之外）。您是說，現在它似乎工作正常，但如果出現磁碟讀取錯誤，您應該盡可能更換磁碟機。高容量驅動器有時可能會出現 URE 錯誤（旁注，這是不運行 RAID 5 的最佳理由），直到另一個驅動器出現故障時才會出現這些錯誤。如果您在該一個磁碟機上遇到邊緣情況行為，您不希望損壞的資料遷移到陣列中的其他磁碟機。

答案3

我不是專家，但我將根據我在 RAID 控制器和儲存陣列方面的經驗，在黑暗中大膽嘗試。

磁碟會以多種不同的方式發生故障。不幸的是，磁碟可能會發生故障或故障，其效能會受到嚴重影響，但 RAID 控制器不會將其視為故障。

如果磁碟以明顯的方式發生故障，任何 RAID 控制器軟體都應該非常擅長檢測磁碟缺乏警報，將其從池中刪除並發出任何通知。然而，我對這裡發生的情況的猜測是磁碟正在遭受不尋常的故障，由於某種原因，該故障不會觸發控制器端的故障。因此，當控制器對受影響的磁碟進行寫入刷新或讀取時，需要很長時間才能返回，進而掛起整個 IO 操作，從而掛起陣列。無論出於何種原因，這都不足以讓 RAID 控制器發出「啊，磁碟故障」的訊息，可能是因為資料最終會返回。

我的建議是立即更換故障磁碟。之後，我會查看您的 RAID 卡的配置（它是 3ware，我認為它們非常好）並找出它認為什麼是故障磁碟。

PS 將 SMART 導入仙人掌是個好主意。

答案4

我在黑暗中拍攝的：

  • 驅動器 7 出現故障。它有一些不可用的故障視窗。

  • 驅動器 8 也有一些“較輕”的錯誤；透過重試糾正。

  • RAID10 通常是“多個 RAID1 對的 RAID0”，磁碟機 7 和 8 是同一對的成員嗎？

如果是這樣，那麼您似乎遇到了同一對磁碟上「不應該發生」的兩個磁碟故障的情況。幾乎是唯一可以殺死 RAID10 的東西。不幸的是，如果您的所有驅動器都來自同一發貨批次，則可能會發生這種情況，因此它們同時失效的可能性稍大一些。

我猜想在驅動器 7 發生故障期間，控制器將所有讀取重定向到驅動器 8，因此任何錯誤重試都會導致很大的延遲，從而導致大量凍結任務，從而暫時降低效能。

你很幸運，驅動器 8 似乎還沒有壞掉，所以你應該能夠修復而不丟失資料。

我首先要更換兩個驅動器，並且不要忘記檢查佈線。連接鬆動可能會導致這種情況，如果佈線不牢固，則更可能發生在相鄰驅動器中。另外，某些多連接埠卡有多個二埠連接器，如果驅動器 7 和驅動器 8 在同一個連接器上，則可能是麻煩的根源。

相關內容