アカウント名:
パスワード:
の2種類があります。演算サーバと言うのはようするに数値計算のようにメモリとCPUパワーは必要だがストレージは全然必要としない計算を専用にやるマシン。ストレージサーバは文字通りストレージとして機能し、データを保管するサーバです。 普通のご家庭で演算サーバが必要だとは思えないし、例に出ているのもことごとくストレージサーバなので、ここからはストレージサーバだとしましょう。 ストレージサーバは大雑把に4種類あります。
# cat /proc/mdstat
むしろハードウェアRAIDカードの方に不信感を持ってますね。
んなわけあるかい。何のためのRAIDだよ。ドライブがこけたら勝手にデグレードモードになるっつーの。
不安定以前にカーネルがAPICを再初期化した時点で動かなくならないか?
一旦failマーク付けたらアクセス自体しなくなって勝手には復活しないので(2)があり得ない。
SMMIは完全にマスクできる。
少なくとも2.6以降のLinuxのsoftRAIDではアクセスできないセクタが発生してリトライが頻発した時点でfailにマークしちゃうし、
これは誤りです。I/Oのリトライはscsi(libata)やIDEドライバで行っているためmdドライバでfaultと判定する時点では既に何度かリトライして諦めた状態です。
sdのタイムアウトは30秒でリトライが5回なのでディスクから応答が無いときには2分30秒も待たされます。単純にタイムアウトしてくれればいいのですが、粘るディスクだと2分くらいでなんとか応答を返してくる場合もあり、こういう壊れ方をするとデグレードさせずに延々と遅いまま動き続けます。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
まずもって目的を考えよ (スコア:-1, 荒らし)
の2種類があります。演算サーバと言うのはようするに数値計算のようにメモリとCPUパワーは必要だがストレージは全然必要としない計算を専用にやるマシン。ストレージサーバは文字通りストレージとして機能し、データを保管するサーバです。
普通のご家庭で演算サーバが必要だとは思えないし、例に出ているのもことごとくストレージサーバなので、ここからはストレージサーバだとしましょう。
ストレージサーバは大雑把に4種類あります。
fjの教祖様
Re: (スコア:0)
# cat /proc/mdstat
自動的に切り離してホットスペアを入れてresync、までやろうとすると確かに割と大変ですね。
ただfailしたディスクは一発で分かるし、mdadmの機能でメール通知させることも可能です。
むしろハードウェアRAIDカードの方に不信感を持ってますね。
failしたデ
Re:まずもって目的を考えよ (スコア:1)
これは /home とかそういう「末端」が Raid 化している場合にしか使えません。 / がぶち飛んでいると、catも見つからないし、/proc も探せないのよ。その辺が考慮されていないのが、根本的な問題。
それは BIOS Raid では?カードだという事はPCIとかのスロットに挿すタイプでしょう?? それは十中八九擬似ハードRaid。このタイプは、CPUとして本体のプロセッサパワーをBIOSの制御モードで使おうとするので、ものすごく不安定です。一部機能をチップに押し出していてそちら自体はいいのだが、故障時のように例外処理が大量に発生すると、ボロボロ。
本当に本当のハードウェアRaidは、本体とPCとの接続には SATAとか SAS のケーブルしかありません。
fjの教祖様
Re:まずもって目的を考えよ (スコア:1)
んなわけあるかい。何のためのRAIDだよ。ドライブがこけたら勝手にデグレードモードになるっつーの。
そうならないのはRAIDとは言わない。
>本当に本当のハードウェアRaidは、本体とPCとの接続には SATAとか SAS のケーブルしかありません。
その場合の構成とRAIDボードをスロットに挿した場合、違いを考えてみたらおかしいとわかりそうなもんだけどな。
つまり拡張ボードであるかどうかは関係ない。てかイマドキBIOSをストレージの制御に使うOSってどのくらいあるよ。
その「疑似RAID」の作りだと不安定以前にカーネルがAPICを再初期化した時点で動かなくならないか?
Re:まずもって目的を考えよ (スコア:1)
「ドライブがこけた」事を実験するのに、HDD丸ごと引っこ抜く場合しか考えない人はよくそういう。が,それは間違いだ。
HDD障害で非常に多く発生するのは、bad sector の中でもTrack管理領域が死滅するケース。代替セクターの位置も記録できなくなって、IO不可能なセクターが出る。これが起こると、
1) retry が山のように発生してしまう
2) デグレードモードに落ちようとしてHDDの存在をチェックすると、ちゃんと生きていると返ってくるので復活してしまう
を繰り返すようになり、処理が全然前に進まなくなる。これはHDDが丸ごと応答しなくなるケースの1万倍近く多く発生する。
通常ファイルでも十分泣きたくなる状態(特に libc.so とか)に陥るが、メタデータ領域にこれを食らうとげんなり。
Raid1で4重化していたシステムが、この現象で立ち上がらなくなり、どれがおかしいのか1つづつ抜いてみるしかなかったときはもう…。 ならない。SMMコードが先に制御を取り返す。
fjの教祖様
Re:まずもって目的を考えよ (スコア:1)
勝手に想定するのは勝手だし、想定しないと話を進められないので勝手に想定する事自体は否定しないが、その想定は間違いだ。
まず、それはいつの話?
少なくとも2.6以降のLinuxのsoftRAIDではアクセスできないセクタが発生してリトライが頻発した時点でfailにマークしちゃうし、一旦failマーク付けたらアクセス自体しなくなって勝手には復活しないので(2)があり得ない。そもそもリトライを頻発するようなドライブにいつまでもアクセスしに行ってたら遅くてかなわん(=可用性を確保できてるとは言えない)。
failマークは揮発性なので再起動した時にドライブが見えてるとそのまま追加されてデータが壊れちゃうし(RAID1でも読む時はストライピングになるので一つでもデータが壊れてると読んだデータは壊れてる可能性がある)、あるいはswapもRAIDに置いてないと固まったりするけどな。まさかそんな状況の事は言ってないと思うけど、でも症状としては前者が非常に近いなぁ...ダメなのが入ってるとダメで、ダメなの抜けば直るとか。
>ならない。SMMコードが先に制御を取り返す。
SMMが動くためにはAPICでSMMIを許可しておく必要があるけどSMMIは完全にマスクできる。普通のLinuxがどうしてるかまでは知らんけど、ACPIで使うし許可してるかも知れんからそういう事もあるかも知れん(をれが仕事で扱ってるLinuxは普通じゃないのでSMMIは禁止してる)。
だけどハードRAIDがダメなのはそんな理由じゃない。壊れた時に復活できるハードが入手できないことがままあるのが決定的にダメで「不安定」とかの理由はそんなに大きくはない。不安定なら使わなきゃいいんだからデータは失われないけど、代替手段がないとデータが失われちゃう。softRAIDなら違うメーカーのハードであっても代替できるじゃん?
Re:まずもって目的を考えよ (スコア:1)
RHEL4でも5でも発生する事だ。そういう「実験しないで予想でモノをいう」のはやめよう。
ダウト。それはたまたまそういうBIOSバージョンに当たっているだけだ。
一般にはSMMIはBIOSによってロックされている。
fjの教祖様
Re:まずもって目的を考えよ (スコア:1)
これは誤りです。I/Oのリトライはscsi(libata)やIDEドライバで行っているためmdドライバでfaultと判定する時点では既に何度かリトライして諦めた状態です。
sdのタイムアウトは30秒でリトライが5回なのでディスクから応答が無いときには2分30秒も待たされます。単純にタイムアウトしてくれればいいのですが、粘るディスクだと2分くらいでなんとか応答を返してくる場合もあり、こういう壊れ方をするとデグレードさせずに延々と遅いまま動き続けます。
Re:まずもって目的を考えよ (スコア:1)
過去日記漁ってみ?
# かなり恥晒しではあるが根拠にはなってるよ?
>ダウト。それはたまたまそういうBIOSバージョンに当たっているだけだ。
>一般にはSMMIはBIOSによってロックされている。
(をれ自身が触ってるのはPCじゃないが)リアルタイムLinuxな仕事しててメイン開発者から出た話だから、そのくらいの信憑性はあると思うけど?
そもそもSMMI殺せなくてリアルタイムって言えると思う?