前奏曲：

私はコードサルであり、私の小さな会社のシステム管理者としての任務をますます受けています。私のコードは私たちの製品であり、ますます私たちはSaaSと同じアプリを提供しています。

約18か月前、私はサーバーをプレミアムホスティング中心のベンダーからティアIVデータセンターのベアボーンラックプッシャーに移動しました。（文字通り、通りの向こう側。）このことは、ネットワーキング、ストレージ、監視など、はるかに多くのことを行っています。

大きな動きの一環として、ホスティング会社からリースされた直接接続ストレージを置き換えるために、SuperMicroシャーシ、3ware RAIDカード、Ubuntu 10.04、20個のSATAディスク、DRBDおよびに基づいて9TB 2ノードNASを構築しました。すべての愛情を込めて3件のブログの記事に記載されます：アップの構築＆新9TB SATA RAID10 NFSv4のNASをテスト：パートI、パートIIとパートIIIを。

また、Cacit監視システムもセットアップします。最近、SMART値など、より多くのデータポイントを追加しています。

私はせずに、このすべてを行っていることができなかった素晴らしい boffins で ServerFaultの。楽しくて教育的な経験でした。私の上司は幸せです（$$$のバケットを節約しました）、顧客は幸せです（ストレージコストは下がっています）、私は幸せです（楽しい、楽しい、楽しい）。

昨日まで。

停止および回復：

昼食後しばらくして、オンデマンドストリーミングメディアCMSであるアプリケーションからパフォーマンスの低迷のレポートを取得し始めました。ほぼ同時期に、Cacti監視システムが猛烈な電子メールを送信しました。より重要なアラートの1つは、iostat待機のグラフでした。

パフォーマンスが非常に低下したため、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]:

そこで、アレイ内のディスクのCactiグラフを確認しに行きました。ここで、はい、syslogが言うように、ディスク7が抜け落ちていることがわかります。しかし、ディスク8のSMART Read Errosが変動していることもわかります。

syslogにはディスク8に関するメッセージはありません。さらに興味深いのは、ディスク8の変動値が高いIO待機時間と直接相関していることです！ 私の解釈は：

• ディスク8には、断続的な長時間の動作を引き起こす奇妙なハードウェア障害が発生しています。
• 何らかの理由で、ディスク上のこの障害状態がアレイ全体をロックアップしています

より正確または正確な説明があるかもしれませんが、最終的な結果は、1つのディスクがアレイ全体のパフォーマンスに影響を与えていることです。

質問）

• ハードウェアSATA RAID-10アレイ内の単一のディスクが、アレイ全体をきしむように停止させるにはどうすればよいですか？
• RAIDカードはこれを処理すべきだったと思うのはナイーブですか？
• 単一の動作不良のディスクがアレイ全体に影響を及ぼすのを防ぐにはどうすればよいですか？
• 何か不足していますか？

重要な実稼働環境では「SATAを使用しない」と言いたくないのですが、この状況はよく見ます。SATAドライブは、通常、説明するデューティサイクル用ではありませんが、セットアップで24時間365日の動作に特化した仕様のドライブを使用しました。私の経験では、SATAドライブは予測不可能な方法で故障する可能性があり、多くの場合、RAID 1 + 0を使用している場合でも、ストレージアレイ全体に影響を及ぼします。バス全体を停止させるような方法でドライブが故障する場合があります。注意すべきことの1つは、セットアップでSASエクスパンダーを使用しているかどうかです。これにより、ドライブ障害による残りのディスクへの影響に違いが生じる可能性があります。

しかし、ミッドライン/ニアライン（7200 RPM）SASドライブではなくSATA ドライブを使用するほうが理にかなっているかもしれません。SATAに比べて価格は若干高くなりますが、ドライブは予測どおりに動作/故障します。SASインターフェイス/プロトコルのエラー修正とレポートは、SATAセットよりも堅牢です。そのため、機構が同じドライブでも、SASプロトコルの違いにより、ドライブ障害時に経験する痛みが防げた可能性があります。

単一のディスクでアレイを停止するにはどうすればよいですか？答えはそうすべきではないということですが、停止の原因に依存します。ディスクが動作する方法で死ぬ場合、それはダウンするべきではありません。しかし、コントローラーが処理できない「エッジケース」の方法で失敗する可能性があります。

あなたはこれが起こるべきではないと思っているのですか？いいえ、そうは思いません。そのようなハードウェアRAIDカードは、ほとんどの問題を処理するはずでした。

それを防ぐ方法は？このような奇妙なエッジケースは予測できません。これはシステム管理者の一部です...しかし、あなたはそれがあなたのビジネスに影響を与えないようにするために回復手順に取り組むことができます。今すぐこれを修正する唯一の方法は、別のハードウェアカードを試してみるか（おそらくやりたいことではありません）、ドライブをSATAではなくSASドライブに変更して、SASがより堅牢かどうかを確認することです。また、RAIDカードのベンダーに連絡して、何が起こったのかを伝え、彼らが何を言っているかを確認することもできます。結局のところ、彼らは不安定なドライブエレクトロニクスの詳細を知ることに特化することになっている会社です。信頼できる人だけでなく、ドライブの仕組みに関する技術的なアドバイスもあります。適切な人と話をすることができれば。

何か見逃しましたか？ドライブにエッジケース障害があることを確認する場合は、アレイから引き出します。アレイは劣化しますが、（劣化したアレイの状態を除いて）奇妙な速度低下やエラーが発生することはないはずです。あなたは今、それはうまく機能しているように見えると言っていますが、ディスク読み取りエラーが発生している場合は、できる限りドライブを交換する必要があります。大容量のドライブには、別のドライブに障害が発生するまで表示されないUREエラー（RAID 5を実行しない最良の理由）があります。また、その1つのドライブからエッジケースの動作が発生している場合、破損したデータをアレイ内の他のドライブに移行することは望ましくありません。

私は専門家ではありませんが、RAIDコントローラーとストレージアレイの経験に基づいて、暗闇でワイルドショットを撮ります。

ディスクはさまざまな方法で故障します。残念ながら、パフォーマンスに深刻な影響を及ぼしますが、RAIDコントローラーは障害とは見なされないため、ディスクに障害が発生したり、障害が発生したりすることがあります。

ディスクに明らかな障害が発生した場合、RAIDコントローラーソフトウェアは、ディスクからの応答の欠如を検出し、それをプールから削除し、通知を発行するのに非常に優れているはずです。ただし、ここで何が起こっているのかについての私の推測は、ディスクに異常な障害が発生しており、何らかの理由でコントローラー側で障害が発生していないことです。そのため、コントローラーが影響を受けるディスクから書き込みフラッシュまたは読み取りを実行している場合、復帰するのに時間がかかり、IO全体、つまりアレイが動作しなくなります。何らかの理由で、RAIDコントローラーが「ああ、故障したディスク」になるのに十分ではありません。おそらくデータが最終的に戻ってくるからです。

私のアドバイスは、故障したディスクをすぐに交換することです。その後、RAIDカードの構成を調べて（3wareで、かなり良いと思いました）、故障したディスクと見なされるものを見つけます。

PS SMARTをcactiにインポートする良いアイデア。

エンタープライズクラスのストレージデバイスの機能が必要です。特に、WD RE 4エンタープライズドライブには、RAIDアレイでこの動作を防ぐために必要な2つの機能があります。以下にリストされている最初の技術は、回転調和振動がハードドライブの機械部品の不必要な摩耗を引き起こすことを防ぎます。2番目のテクノロジーが問題の原因であり、SATAプロトコルにはこの機能がありません。これらの機能を使用するにはSASが必要です。SA​​TAドライブを使用する場合は、LSISS9252などのSAS to SATA Interposerカードを購入できます。

強化されたRAFFテクノロジー高度な電子機器がドライブを監視し、線形振動と回転振動の両方をリアルタイムで補正します。その結果、前世代のドライブと比較して、高振動環境でのパフォーマンスが大幅に向上します。

RAID固有の時間制限エラー回復（TLER）デスクトップドライブに共通の拡張ハードドライブエラー回復プロセスによるドライブのフォールアウトを防ぎます。

http://en.wikipedia.org/wiki/Error_recovery_control#Overview

以下のリンクもご覧ください。

http://en.wikipedia.org/wiki/Error_recovery_control#Raid_Controllers

エラー回復プロセスを詳細に説明しているWestern Digital TLERドキュメントも参照してください。WD Caviar RAID EditionシリアルATAハードドライブのエラー回復フォールアウト防止：

http://www.3dfxzone.it/public/files/2579-001098.pdf

推測では、ハードディスクはエラーを報告するのではなく、読み取りエラーで再試行するように構成されています。これはデスクトップ設定では望ましい動作ですが、RAIDでは逆効果になります（コントローラは、他のディスクからの読み取りに失敗したセクターを書き換える必要があるため、ドライブはそれを再マッピングできます）。

暗闇での私のショット：

• ドライブ7に障害が発生しています。使用できない障害ウィンドウがいくつかあります。

• ドライブ8にもいくつかの「軽い」エラーがあります。再試行して修正しました。

• RAID10は通常「複数のRAID1ペアのRAID0」ですが、ドライブ7と8は同じペアのメンバーですか？

もしそうなら、同じペアで2つのディスクに障害が発生した場合に「発生しない」ケースに遭遇したようです。RAID10を殺すことができるのはほとんど唯一のことです。残念ながら、すべてのドライブが同じ出荷ロットからのものである場合に発生する可能性があるため、それらが同時に死亡する可能性がわずかに高くなります。

ドライブ7の障害時に、コントローラーがすべての読み取りをドライブ8にリダイレクトしたため、エラーを再試行すると大きな遅延が発生し、凍結タスクが雪崩し、しばらくパフォーマンスが低下したと思います。

ドライブ8がまだ死んでいないように見えるのは幸運であるため、データ損失なしで修正できるはずです。

私は両方のドライブを変更することから始め、ケーブル接続を確認することを忘れないでください。接続が緩んでいるとこれが発生する可能性があり、しっかりとルーティングされない場合は、隣接するドライブで発生する可能性が高くなります。また、一部のマルチポートカードには複数の2ポートコネクタがあります。ドライブ7とドライブ8が同じものである場合、問題の原因になっている可能性があります。

SATAインターポーザーカードは別のソリューションです。

私は最近、まったく同じ運命を経験し、このスレッドを見つけました。全体的な傾向として、SATAには機能が欠けているため、SAS プロトコルはSATAよりRAIDに適しています。これが、同じ物理ドライブにSASコントローラーが装備され、Nearline SASとして販売されている理由です。

さらに検索して、私は見つけた：

http://www.lsi.com/products/storagecomponents/Pages/LSISS9252.aspx

これらのバッチでストレージの1つをアップグレードすることを調査しています。現在、3 TB SATAとSASの価格差は400％です（バニラ価格、同じブランド、仕様、ショップ、ドイツ）。この戦略がうまく機能するかどうかは明らかにわかりませんが、試してみる価値はあります。

コメントは大歓迎です:-)

壊れた電子機器を搭載したSATAディスクがAreca 12のファームウェアの初期化をしっかりとロックしているのを見ました。検索ファッション。