これまでのキャリアで、さまざまな環境 (CentOS/Debian ボックス、Synology/QNAP NAS など) で、故障したディスクを処理できないように見える mdadm RAID セット (RAID1+0、5、6 など) に何度も遭遇しました。これは、完全に死んではいないものの、何万もの不良セクタがあり、I/O を処理できないディスクです。ただし、完全に死んではおらず、まだなんとか機能しています。カーネル ログは通常、UNC エラーでいっぱいです。
SMART によってディスクが故障していると判断される場合もあれば、I/O が遅い以外に症状がない場合もあります。
実際には、I/O が遅いとシステム全体がフリーズします。SSH 経由での接続には非常に時間がかかり、WebGUI (NAS の場合) は通常動作を停止します。SSH 経由でのコマンドの実行にも非常に時間がかかります。これは、ディスクをアレイから切断するか、意図的に「失敗」させるまで続きます。その後、状況は「正常」に戻ります。これは、劣化したアレイで可能な限り正常な状態です。
ディスクの読み取り/書き込みに時間がかかる場合、ディスクをアレイから外して、ログにメッセージを残してそのまま続行したらどうでしょうか。1 つのディスクがおかしいためにシステム全体が停止すると、RAID を使用する主な利点の 1 つ (フォールト トレランス - ディスクが故障しても実行を継続できる機能) が完全に無効になるようです。単一ディスクのシナリオ (たとえば、システムに SATA ディスクが 1 つしか接続されておらず、読み取り/書き込みを適切に実行できない場合) ではこれが壊滅的であることは理解できますが、RAID セット (特にフォールト トレランスの「パーソナリティ」) では、煩わしいだけでなく常識に反しているように思われます。
mdadm のデフォルトの動作が、誰かがリモートから接続して手動で修正するまで、基本的にボックスの機能を停止させることになっているのには、何か正当な理由があるのでしょうか?
答え1
一般的に、レイド選択したレイドレベルに応じて、主要な目標間のバランスが異なります。 データの冗長性、 可用性、 パフォーマンスそして容量。
具体的な要件に基づいて、保管場所所有者の責任さまざまな要素のバランスが与えられた目的に合っているかどうかを決定し、信頼性のある解決。
選択された RAID ソリューション (ここではソフトウェアについて説明していますmdadm) の役割は、何よりもまずデータ保護を確保することです。これを念頭に置くと、データの整合性よりもビジネス継続性を重視することは RAID ソリューションの役割ではないことは明らかです。
言い換えると、mdadm の役割は RAID の失敗を回避することです。「異常な動作をするディスク」が完全に壊れていない限り、それは RAID に依然として影響を及ぼします。
では、異常な動作をしているディスクをアレイから外し、ログにメッセージを残してそのまま進めてみてはいかがでしょうか?そうすると、データが失われるリスクが高まるからです。
つまり、おっしゃる通り、現時点では、ビジネスの観点からは、そのまま続行する方がよい解決策のように思えます。しかし、実際には、ログにドロップされたメッセージは検出されないままになる可能性があり、RAID の劣化状態は検出されないままになります。しばらくすると、同じ RAID 内の別のディスクが故障し、その結果、故障した RAID に保存されていたデータは最終的に失われます。
それに加えて、「異常な動作をするディスク」が何であるかを正確に定義することは困難です。別の言い方をすると、ディスク アレイ内で動作する単一のディスクの許容可能な動作とは何でしょうか。
「ディスクにエラーがいくつか表示されています」と答える人もいるでしょう。「エラーを修正できる限り、問題ありません」と答える人もいるでしょう。「ディスクが指定された時間内にすべてのコマンドに応答する限り、問題ありません」と答える人もいるでしょう。「ディスクの温度が、同じアレイ内のすべてのディスクの平均温度と比較して 5°C 以上異なる場合」と言う人もいます。別の答えとしては、「スクラブでエラーが見つからない限り」、または「SMART でエラーが表示されない限り」というものがあります。
書かれている内容は長くはなく、また完全なリストでもありません。
重要なのは、「ディスクの許容可能な動作」の定義は解釈の問題であり、したがってストレージ所有者の責任でもあり、mdadm が独自に決定するものではないということです。
答え2
重要な問題は、故障したSATAディスクドライブが内部エラー回復手順中にバス全体をフリーズさせる可能性があるということです。このため、TLER 対応RAID アレイ内のドライブのみ (エンタープライズ グレードのモデルが望ましい)。
SAS ドライブはこの問題の影響をあまり受けませんが、完全に回避できるわけではありません。
答え3
言われたことに加えて、私も意見を述べたいと思いますが、これは重要な考慮事項です。
何ドライブセクターの読み取りが遅い場合はどうなりますか?
単独で動作するように設計されたドライブ、たとえば典型的な「デスクトップ」ドライブは、不良セクタに保存されたデータを取得する他の方法はないと想定しています。長期間にわたって、あらゆる手段を講じてデータを取得しようと何度も繰り返します。もちろん、そのセクタは障害があるとマークされるため、次回書き込み時に再マップされますが、そのためには書き込みを行う必要があります。再書き込みを行うまで、その場所から読み取るたびにドライブが停止します。RAID 設定では、これは RAID ではドライブがまだ動作しており、ドライブを強制終了する理由がないことを意味しますが、アプリケーションではアレイの速度が極端に低下します。
一方、「エンタープライズ」ドライブ、特に「ブランド」ドライブは、常にRAID設定で使用されることを想定していることが多い。「ブランド」コントローラは、「ブランド」ドライブを見ると、実際には通知するRAID の存在に関するファームウェアの警告。そのため、ドライブは早期に停止し、セクターの読み取りを数回試行できたとしても、I/O エラーを報告します。その後、コントローラは読み取り命令を兄弟ドライブにミラーリングして (不良ドライブをアレイから追い出して)、より速く応答する機会を得ます。追い出されたドライブを徹底的に取り出して調査/テストすると、明らかな問題は見つかりません。コントローラのロジックによると、一瞬だけ速度が低下し、使用を停止するのに十分だったということです。
これはおそらく唯一の「デスクトップ」ドライブと「ブランド」/「エンタープライズ」NL-SAS および SATA ドライブの違い。これがおそらく、実際には東芝が製造した「HPE」ドライブを購入すると、「東芝」ブランドのドライブを購入する場合と比べて 3 倍の料金を支払うことになる理由です。
ただし、一部のドライブでは、これの一般的な制御をサポートしています。これはSCT ERCと呼ばれ、SMARTコマンドトランスポートエラー回復制御. では次のようになりますsmartctl:
サポートされていない
# smartctl --all /dev/sda
=== START OF READ SMART DATA SECTION ===
SCT capabilities: (0x3037) SCT Status supported.
SCT Feature Control supported.
SCT Data Table supported.
サポートされている
=== START OF READ SMART DATA SECTION ===
...
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
運が良ければ、この機能を で制御できますsmartctl。再読み込みを試行する時間と再書き込みを試行する時間の 2 つのタイムアウトを取得または設定できます。
# smartctl -l scterc /dev/sda
SCT Error Recovery Control:
Read: 70 (7.0 seconds)
Write: 70 (7.0 seconds)
# smartctl -l scterc /dev/sde
SCT Error Recovery Control:
Read: Disabled
Write: Disabled
# smartctl -l scterc /dev/sdd
Warning: device does not support SCT Error Recovery Control command
smartctl -l scterc,120,60 /dev/sde
つまり、読み取りの再試行には 120 分の 1 秒、書き込みの再試行には 60 分の 1 秒かかります。ゼロは「死ぬまで再試行する」ことを意味します。ドライブによって、このデフォルト設定は異なります。
したがって、「RAID エディション」ドライブだけを使用する場合は、ERC タイムアウトをゼロに設定することをおすすめします。そうしないと、データが失われる可能性があります。一方、ドライブを RAID で使用する場合は、ゼロ以外の適切な低い設定にすることをお勧めします。
PS そして SAS についての注意。 を使用するとsdparm、これのより多くの制御がサポートされます。
答え4
ディスクが動作しなくなり、何らかの理由でコントローラーが故障したという状況がありました。
歴史的には、マスター ドライブとスレーブ ドライブが同じケーブル上にある PATA ではこれが可能であり、1 つのドライブが故障すると、もう 1 つの正常なドライブへのアクセスが妨げられる可能性があります。故障したドライブを取り外すと、残りのドライブへのアクセスが再度有効になるか、電源サイクルが必要になる場合がありますが、RAID が劣化した状態で起動し、回復を開始できます。
SATA はこれに対してそれほど脆弱ではありませんが、それでもコントローラーが影響を受ける可能性があります。ソフトウェア RAID の経験から言うと、より高性能な専用 RAID コントローラーによって隠される、より内部のひどい部分が露出していることが多いです。
SAS や NVME ではこのようなことは経験していませんが、SAS は多くの場合、内部的にディスク処理のスマートさが強化されたハードウェア RAID コントローラーを意味します。