傀儡師の館.Python

傀儡師の館.Python

PR

×

Calendar

Keyword Search

▼キーワード検索

Archives

2026.07
2026.06
2026.05
2026.04
2026.03
2026.02
2026.01
2025.12
2025.11
2025.10

Profile

kugutsushi

kugutsushi

Free Space

設定されていません。
2008.12.07
XML
カテゴリ: Solaris10
そういえば、Blade 1000 に Solaris 10 08/10 をインストールし直したら、そのとき D2 ( Sun StorEdge D2 を買った (2008.06.21) ) を切ったままにしたせいか分からないが、D2 のディスクが見えなくなってしまった。以前と同様 devfsadm を実行したら見えるようになった。( デバイスへのアクセス (概要) )。ディスクが見えるようになったら zpool import poolname でインポート。ほっと一息。

以前はストライプにしていたのだが、ついでなので信頼性重視で、 RAID-Z で作り直すことにした。ダブルパリティーを使うことにする。HDD は中古のやつだし、いつ壊れるか分からないからw

1 つまたは 2 つのデバイスで障害が発生しても、データを失うことなく処理を続行できることを意味します。raidz2 キーワードを指定すれば、ダブルパリティー RAID-Z 構成にすることができます。あるいは、raidz または raidz1 キーワードを指定すれば、シングルパリティー RAID-Z 構成にすることができます。



そういえば、 ZFS Disk Crash Demo ZFS is Smashing Baby とか、端的に分かりやすいデモだけど、でもでも、まったくもう。。。。って感じ。まあ、銃弾打ち込んだり、爆破したりするのに比べたらましだけど。

ディスクが 7 台あるので、6台で RAID を組んで 1台をホットスペアにしてみる。

ZFS データを送信および受信する など参照。

# zfs snapshot mypool/mydata@snap1
# zfs send mypool/mydata@snap1 | ssh another-host zfs recv mypool/mydata_snap1

リモートの storage_snap1 のところは、使われていない名前を指定するか、あらかじめ作ってあってもアンマウントできる状態にしておく。アンマウントできない状態だとエラーになるみたい。

ちなみに、root で、これをやるには受け側のホストで root で ssh ログインできるようにしておかないとダメなので、/etc/ssh/sshd_config で PermitRootLogin yes と一時的にしておく。でも、セキュリティ上、受ける側を user@another-host とした方がいいな。

それにしても、こういうのをやるときにはネットワークがギガビット対応でないと時間がかかる。。。。加えて ssh 使うから CPU をそれなりに使うのね。あまりロースペックなマシンだと、ここでもだと時間がかかる。

ssh 使わずにできないのか。。。。 ssh を使わない zfs send/recv という手もあるのね。 mbuffer を使って ZFS data stream を送受信してあげるのね。

おぉ、

ちなみに、zfs recv の -v オプションを利用すると、全ての data stream 受信完了後、受信にかかった時間や受信データ量、1 秒間の平均転送速度を出してくれます。

このオプションは気づいていなかった。-v つけるようにしよっと。

んー、でも、ssh を使う場合は、送信側だけでえいとやれるのに、mbuffer を使う場合は受信側でも用意をしてから、投げないとダメなのが若干、面倒。特に自動化する場合とか。ちなみに、zfs data stream を送受信中に他のホストからゴミを投げつけるとか、別のバックアップ開始しちゃったら壊れるかw 他のホストからは、そのポートに通信を受けないようにしておけば安心できるか。自動化するなら、ホストごとにポートを変えるだな。時間が予想以上かかって別のマシンから送られてきたらドカンじゃまずいものね。

バックアップができたら、いったん、ちゃんとバックアップができたか確認してからプールを破壊して、作り直す。とりあえず、1台は念のためスペアにして、raidz2 で作成。

# zpool destroy mypool
# zpool create xpool raidz2 c2t0d0 c2t1d0 c2t2d0 c2t3d0 c2t8d0 c2t9d0 spare c2t10d0



ちなみに、今回は raidz2 でホットスペア 1台にしてみた。稼働中のディスクが仮に 2台すっ飛んでも、1台はホットスペアが入るから、さらに 1台飛んでも死なないかなと。さすがに 4台すっ飛ぶ間に手は打てるだろうと。

とりあえず 1台引っこ抜いて、ちょっと待つと。ホットスペアが機能して、使用中になる。

NAME STATE READ WRITE CKSUM
xpool DEGRADED 0 0 0
raidz2 DEGRADED 0 0 0
c2t0d0 ONLINE 0 0 0
c2t1d0 ONLINE 0 0 0
c2t2d0 ONLINE 0 0 0
spare DEGRADED 0 0 0
c2t3d0 FAULTED 0 110 0 エラーが多すぎます
c2t10d0 ONLINE 0 0 0
c2t8d0 ONLINE 0 0 0
c2t9d0 ONLINE 0 0 0
スペア
c2t10d0 INUSE 現在使用中です


さらに1台ディスクを引っこ抜く。ホットスペアがもうないので、DEGRADED になる。そうすると、

状態: DEGRADED
状態: 1 つまたは複数のデバイスが、持続エラーへの応答に失敗しています。
十分な複製が存在するため、プールは縮退状態で動作を継続
できます。
アクション: 失敗したデバイスを置き換えるか、または修復されたデバイスを 'zpool clear' を使用して
マークしてください。
スクラブ: Sun Dec 7 00:00:00 2008
上で 0 エラーが発生した 0h0m のあとの resilver completed

構成:

NAME STATE READ WRITE CKSUM
xpool DEGRADED 0 0 0
raidz2 DEGRADED 0 0 0
c2t0d0 ONLINE 0 0 0
c2t1d0 ONLINE 0 0 0
c2t2d0 FAULTED 0 207 0 エラーが多すぎます
spare DEGRADED 0 0 0
c2t3d0 FAULTED 0 110 0 エラーが多すぎます
c2t10d0 ONLINE 0 0 0
c2t8d0 ONLINE 0 0 0
c2t9d0 ONLINE 0 0 0
スペア
c2t10d0 INUSE 現在使用中です

とりあえず、2台死んでもまだ大丈夫(実質、ホットスペアが機能しているので 1台が死んだ状態)。

ダブルパリティだから、もう1台死んでも大丈夫なはず。さらにもう 1台ディスクを引っこ抜く。

プール: xpool
状態: DEGRADED
状態: 1 つまたは複数のデバイスが、持続エラーへの応答に失敗しています。
十分な複製が存在するため、プールは縮退状態で動作を継続
できます。
アクション: 失敗したデバイスを置き換えるか、または修復されたデバイスを 'zpool clear' を使用して
マークしてください。
スクラブ: Sun Dec 7 00:10:53 2008
上で 0 エラーが発生した 0h0m のあとの resilver completed
構成:

NAME STATE READ WRITE CKSUM
xpool DEGRADED 0 0 0
raidz2 DEGRADED 0 0 0
c2t0d0 ONLINE 0 0 0
c2t1d0 FAULTED 0 128 0 エラーが多すぎます
c2t2d0 FAULTED 0 207 0 エラーが多すぎます
spare DEGRADED 0 0 0
c2t3d0 FAULTED 0 110 0 エラーが多すぎます
c2t10d0 ONLINE 0 0 0
c2t8d0 ONLINE 0 0 0
c2t9d0 ONLINE 0 0 0
スペア
c2t10d0 INUSE 現在使用中で

エラー: 既知のデータエラーはありません



さて、もう 1台引っこ抜くとどうなるか。つまり、7台中、4台引っこ抜く。残り3台。これで壊れるはず。

なかなかステータスが返ってこない。うー、全然返ってこない。この状態で zfs list とか、zpool list とかやっても返ってこない。意外な弱点。ひょえぇ。もし、こういうダメ状態になったときに、ステータスが返ってこないと対処できないじゃん。

それにしても、壊滅的に壊れた場合の追試が必要だなぁ。壊滅的に壊れてから zfs status でどのディスクが壊れているか確認できないのが辛い。もし、いつでも、こうなっちゃうとすると、万が一に備えてもう少しディスクを増やして、さらに一台ホットスワップのディスクを用意した方がいいか。。。。

それにしても、zpool status や zpool listや zfs list のプロセスは Ctrl-C しても殺せない。kill コマンドも効かない。ssh のセッションごと殺しちゃえ。いえいえ、それでもプロセスはまだまだ生き延びてます。ちなみに、こういう状態でも、恐ろしいことに、その pool をマウントしたところで読み書きできるなぁ。生きているディスクだけに書き込みするのか。

試しにここで、強引に reboot してみる。

うー、なかなか起動時の処理が終わらない。生き残ったディスクがガリガリやっている。ログインもできない状態が続く。

ZFS が強いと言っても、ほんとうに壊れちゃうところまでやると、やっぱり、大変なことになるようだw

仕様上、壊れるところまでやって壊れるのは当然だからよいとして、その後、お手上げ状態になるのがちと困るな。壊滅的に壊れた後の運用ノウハウもきちんと身につけておかないといかんね。


なかのひと Firefox meter 携帯アクセス解析






お気に入りの記事を「いいね!」で応援しよう

Last updated  2008.12.07 08:02:41コメント(0) | コメントを書く
[Solaris10] カテゴリの最新記事


【毎日開催】
15記事にいいね!で1ポイント
10秒滞在
いいね! -- / --
おめでとうございます!
ミッションを達成しました。
※「ポイントを獲得する」ボタンを押すと広告が表示されます。
x
X

© Rakuten Group, Inc.
X
Design a Mobile Website
スマートフォン版を閲覧 | PC版を閲覧
Share by: