硬體 SATA RAID-10 陣列中的單個磁碟如何使整個陣列戛然而止？
序幕：
我是一隻程式碼猴子，越來越多地為我的小公司承擔系統管理員的職責。我的程式碼是我們的產品，我們越來越多地提供與 SaaS 相同的應用程序。
大約 18 個月前，我將我們的伺服器從以優質託管為中心的供應商轉移到了 IV 級數據中心的準系統機架推送器。（字面意思是街對面。）這讓我們自己做的更多——比如網路、儲存和監控。
作為重大舉措的一部分，為了替換我們從託管公司租用的直接附加儲存，我建構了一個基於 SuperMicro 機箱、3ware RAID 卡、Ubuntu 10.04、兩打 SATA 磁碟、DRBD 和 . 這一切都在三篇部落格文章中詳細記錄：建構和測試新的 9TB SATA RAID10 NFSv4 NAS：第一部分、第二部分和第三部分。
我們還設置了一個 Cacti 監控系統。最近我們一直在添加越來越多的數據點，例如 SMART 值。
如果沒有ServerFault 的出色 研究人員，我不可能完成這**一切**。這是一次有趣和有教育意義的經歷。我的老闆很高興*（我們節省了大量的美元），我們的客戶很高興（儲存成本下降），我很高興（有趣，有趣，有趣）*。
直到昨天。
中斷和恢復：
午飯後的一段時間，我們開始從我們的應用程序（一個按需流媒體 CMS）中收到關於性能緩慢的報告。大約在同一時間，我們的 Cacti 監控系統發送了大量電子郵件。更能說明問題的警報之一是 iostat await 圖表。
性能變得如此下降，以至於 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 在波動。
syslog 中沒有關於磁碟 8 的消息。更有趣的是，磁碟 8 的波動值與高 IO 等待時間直接相關！ 我的解釋是：
- 磁碟 8 遇到奇怪的硬體故障，導致間歇性長時間執行。
- 不知何故，磁碟上的這種故障情況鎖定了整個陣列
也許有更準確或更正確的描述，但最終結果是一個磁碟正在影響整個陣列的性能。
問題
- 硬體 SATA RAID-10 陣列中的單個磁碟如何使整個陣列戛然而止？
- 我是否天真地認為 RAID 卡應該處理這個問題？
- 如何防止單個異常磁碟影響整個陣列？
- 我錯過了什麼嗎？
我討厭在關鍵生產環境中說“不要使用 SATA”，但我經常看到這種情況。SATA 驅動器通常不適用於您描述的佔空比，儘管您在設置中做了專門針對 24x7 執行的規格驅動器。我的經驗是 SATA 驅動器可能會以不可預知的方式出現故障，通常會影響整個儲存陣列，即使在使用 RAID 1+0 時也是如此，就像您所做的那樣。有時，驅動器發生故障會導致整個匯流排停頓。需要注意的一件事是您是否在設置中使用 SAS 擴展器。這可能會影響剩餘磁碟如何受到驅動器故障的影響。
但是使用中線/近線 (7200 RPM) SAS 驅動器與 SATA 相比可能更有意義。與 SATA 相比，價格溢價很小，但驅動器的執行/故障更可預測。SAS 介面/協議中的糾錯和報告比 SATA 集更強大。因此，即使對於機械結構相同的驅動器，SAS 協議的差異也可能避免了您在驅動器故障期間所經歷的痛苦。