@_hito_さんのRAID5や6の話を聞こう

hito @_hito_

RAID5や6の話をしよう。業界人には常識ではあるんだけど。

hito @_hito_

みんなのトラウマRAID5さんについて。「一台壊れてデグレードしてる時にもう一台壊れる」みたいな話はよくある。「リビルドしてもう一台にトドメ刺した」とか。でも、本当の恐怖はそこにはない。

hito @_hito_

RAID5の本当の恐怖は「リビルド中にbad blockに遭遇して終了」というところにある。bad blockつーのは要するに「HDD上にある読めないセクタ」とか「読もうとするとランダムにエラーを吐くセクタ」だと思って頂きたい。

hito @_hito_

bad blockごときでなぜ死ぬのか、文字で説明すると大変なので、■が死んでいるデータ領域だと思って以下を見てみよう。Disk1が故障したときの模式図。 　Disk1：■■■■■　Disk2：□□□□□　Disk3：□□□□□ (cont..)

hito @_hito_

bad blockがまじると、Disk1：■■■■■　Disk2：□■□□□　Disk3：□□□□□みたいな状態になる。この状態でリビルドがかかると、左から順番にアクセスしていくものの、Disk2の左から2個目の「■」のところでリビルドが止まる。データストライプ足りないもん。

hito @_hito_

全Diskが正常な状態なら、Bad Blockは問題にならない。Disk1：□□□□□　Disk2：□■□□□　Disk3：□□□□□みたいな状態であれば、2D1Pなら左から2番目のデータにアクセスするときはDisk1と3を見れば元データは取り返せる。

hito @_hito_

で、最大の問題は「Bad Blockはアクセスしてみないと存在が検知できない」ってこと。つまり、「知らない間に虫食い的にbad blockができてリビルドが失敗する状態になっているが、実際にアクセスしてみるか、壊れてリビルドを試みるまでわからない」という状態に陥っている。

hito @_hito_

こいつを防ぐために、マトモなRAID5実装には「Patrol Read」なんて名前で全域をナメて、bad blockを見つけたら自動的にケアしてくれたりする。……んだけど、知らない間にstorage I/Oが生じて不評なので、デフォルトでoffになっていることがよくある。

hito @_hito_

でだ。お使いのシステムにRAID5が存在する皆様、patrol readが有効かどうか、きちんと把握されてますでしょうか。把握していない場合は故障の用意はできておいででしょうか。

hito @_hito_

Debian/Ubuntu環境でLinux MDをお使いの場合、Patrol Read相当のデータチェック機能がcronで回ってます。運が良ければ、そしてHDDのファームウェアの実装がしくっていなければ、HDD側の暗黙の代替処理で回復しているかもしれません。

hito @_hito_

なんで運の良さが必要かっつーと、ものすごーく最近のカーネルでなければmdのbad block handling入ってないから……。

hito @_hito_

Linux mdベースのNAS製品は、最近まで各社独自にbad block handlingを入れていたわけです、はい。なにしろHDD側の代替（remap）は発動するかどうかごにょごにょごにょな感じなので。

hito @_hito_

で、話を戻すと。RAID5のリスクは「1台故障したらRAID0」なだけでなく、「潜在的bad block一発で終了してしまう地雷原を、リビルド時に強制的に全ナメしないといけない」ところにある。このコンテキストはRAID0より危険だったりする。

hito @_hito_

「RAID0より危険」つーのはどういうことかってーと、RAID0なら「ふだんから使ってない場所にはどうせ触らない」から。RAID5でのリビルドみたいな寝た子を起こすマネをしないので、潜在的bad blockは不発弾のまま眠っていてくれる。

hito @_hito_

んで、この10年ぐらいの単体RAID製品は、「潜在的なbad block踏んだら、無視してリビルド続ければ死なないよね？」という発想で回避実装が入っている。メーカー各社で名前を適宜つけてるけど、bad block skip rebuildとかそんなお名前。

hito @_hito_

このへんの機能、要するにpatrol read/bad block handling/bad block skip rebuildは単体disk装置ではお約束の機能ではあるはずなんだけども、お手元の機械にちゃんと搭載されているかどうか確認したほうがいいです。

hito @_hito_

そしてこの手の「RAID5のホラー」は、RAID6だと大分改善されている。特にbad blockまわりのホラーは、「1台故障」の状態ならあんまり気にしなくていい。RAID6でも2台故障してたら怖いけど。

hito @_hito_

そして、RAIDにおけるHDDのロット揃え・ファームウェア揃えの話をしよう。古代のdisk arrayでは型番とロットとファームと容量を揃えるのが常識だった。細かな差があると、その差に起因したトラブルが起きていた / 起こると信じられていたからだ。

hito @_hito_

ところが最近は、型番レベルで別のものを混ぜて使うケースが多い。たとえばこの10年ぐらいに旧Sunの製品をお買い上げの場合、指定がかかってなければRAID1は型番混在になっていたはず。

hito @_hito_

なんで型番を揃えないのか、というのは「バスタブカーブの終焉部分（摩耗期）が同時に訪れるから」というのが答えの一つ。もうひとつは、特にRAID1の場合、「同じ型番・同一ファームだと同じバグを踏んで同時に止まる可能性があるから」。

hito @_hito_

@tetsuro_n 不幸にしてバスタブカーブが終焉してることより、「それまでになかったアクセスパターン」でトドメが刺さるケースのほうが多いですね……。特定領域を触ると突然故障するHDDとか良くいます。

hito @_hito_

最近のDisk Arrayの実装にはちょっとホラーな点がある。2007年ぐらいまでのDisk ArrayはMarvellのマルチポートSATAチップで構成されていることが多かったんだけども、ここ最近はポートマルチプライヤが流行っている。

hito @_hito_

たいていのSATA/SAS石はポート（≒チャネル）単位で壊れたり、刺さったりする。もちろん内部実装によっては2ポート単位とかもあるのだけども。……でだ。ポートマルチプライヤ使ってると、ポート単位の故障の影響範囲も倍率ドン。

hito @_hito_

ポートマルチプライヤ経由でsoftware raidを組んでいる皆さん、マルチプライヤまたいで構成してはいけません。全台が同時に死ぬならまだしも大丈夫ですが、8台ずつ別のものにぶらさがってる実装だと、16台中8台がいきなり死亡とかいう即死打撃が飛んできます。