昨年12月にHDDを一台交換したraidz2(ST4000DM004:7台+WD40EZRZ:1台構成)ですが、また一台のHDDでCurrent_Pending_Sector, Offline_Uncorrectableが発生しました。
数日様子見して数値の増加はありませんでしたが、二桁だったので交換することに。
今回も前回と同じくWD40EZRZと入れ替えました。
稼働23,353時間で交換となりました。
今のところST4000DM004の8台中4台が3年未満で故障となっています。
ST3000DM001よりも故障が早いかな？と言う気がします。
2021年1月23日土曜日
2020年12月28日月曜日
raidz2のST4000DM004をWD40EZRZに交換
今年6月にHDD二台が故障したraidz2(ST4000DM004の8台構成)ですが、scrubを実行したところread failとなるHDDが二台出てしまいました。
うち一台は一時的なものだったようですが、他方は下記の感じでCurrent_Pending_Sector, Offline_Uncorrectableが3桁台に…。 8台中3台が3年未満で故障とは。
Reallocated_Sector_Ctが0のままなんですが、こう言うものなんでしょうか。
SMARTの情報ってイマイチ見方が分からないんですよね。
さて、前回交換時は多重障害になってしまいましたがresilverに数日かかったので、今回はCMRのものを試そうとWD40EZRZに変えてみました。
たまたまセール中にあたりST4000DM004より安く買えたのでお財布にも優しくラッキーでした。
で、resilverにかかった時間ですが、17時間弱で完了しました。
私の用途ではST4000DM004でも普段使っている時は全く問題ないんですけど、resilverなど長時間書き込みが発生すると影響が出てしまうような感じです。
大容量で安いCMRのHDDって無いんですよね。
うち一台は一時的なものだったようですが、他方は下記の感じでCurrent_Pending_Sector, Offline_Uncorrectableが3桁台に…。 8台中3台が3年未満で故障とは。
# smartctl -A /dev/sdf smartctl 7.0 2018-12-30 r4883 [x86_64-linux-3.10.0-1160.6.1.el7.x86_64] (local build) Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 059 055 006 Pre-fail Always - 10386248 3 Spin_Up_Time 0x0003 096 096 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 96 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 087 060 045 Pre-fail Always - 513462226 9 Power_On_Hours 0x0032 075 075 000 Old_age Always - 22634 (210 239 0) 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 96 183 Runtime_Bad_Block 0x0032 099 099 000 Old_age Always - 1 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 187 Reported_Uncorrect 0x0032 088 088 000 Old_age Always - 12 188 Command_Timeout 0x0032 100 099 000 Old_age Always - 2 3 3 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 068 045 040 Old_age Always - 32 (Min/Max 27/45) 191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 935 193 Load_Cycle_Count 0x0032 099 099 000 Old_age Always - 2628 194 Temperature_Celsius 0x0022 032 055 000 Old_age Always - 32 (0 20 0 0 0) 195 Hardware_ECC_Recovered 0x001a 070 064 000 Old_age Always - 10386248 197 Current_Pending_Sector 0x0012 098 098 000 Old_age Always - 720 198 Offline_Uncorrectable 0x0010 098 098 000 Old_age Offline - 720 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 21826h+07m+03.803s 241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 14648100184 242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 28880173058longtestでもエラーとなり、smartdもsyslogにメッセージを出すようになったので交換しました。
Reallocated_Sector_Ctが0のままなんですが、こう言うものなんでしょうか。
SMARTの情報ってイマイチ見方が分からないんですよね。
さて、前回交換時は多重障害になってしまいましたがresilverに数日かかったので、今回はCMRのものを試そうとWD40EZRZに変えてみました。
たまたまセール中にあたりST4000DM004より安く買えたのでお財布にも優しくラッキーでした。
で、resilverにかかった時間ですが、17時間弱で完了しました。
私の用途ではST4000DM004でも普段使っている時は全く問題ないんですけど、resilverなど長時間書き込みが発生すると影響が出てしまうような感じです。
大容量で安いCMRのHDDって無いんですよね。
# zpool status
pool: tank
state: ONLINE
scan: resilvered 3.27T in 0 days 16:47:29 with 0 errors on Sun Dec 27 03:04:23 2020
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
ata-ST4000DM004-2CV104_aaaaaaaa-part1 ONLINE 0 0 0
ata-ST4000DM004-2CV104_bbbbbbbb-part1 ONLINE 0 0 0
ata-ST4000DM004-2CV104_cccccccc-part1 ONLINE 0 0 0
ata-ST4000DM004-2CV104_dddddddd-part1 ONLINE 0 0 0
ata-ST4000DM004-2CV104_eeeeeeee-part1 ONLINE 0 0 0
ata-WDC_WD40EZRZ-22GXCB0_WD-ffffffffffff-part1 ONLINE 0 0 0
ata-ST4000DM004-2CV104_gggggggg-part1 ONLINE 0 0 0
ata-ST4000DM004-2CV104_hhhhhhhh-part1 ONLINE 0 0 0
errors: No known data errors
2020年6月12日金曜日
raidz2のST4000DM004交換
raidz2(ST4000DM004の8台構成)で運用中のHDDが一台、I/Oエラー頻発ということなく突然死という感じで故障しました。
他HDDのSMART情報から大体17740時間で壊れたようです。
予備と交換してresilver中にもう一台壊れました...。
たまたま二台とも故障時にPCの近くにいましたが、どちらも突然カッコン、カッコンと嫌な音を立てたあと鳴り止み御臨終です。
どちらもSMART情報も取れない状態。
まだ、1台目のresilverが完了していない状況ですが、zpool statusで進捗を確認するとDEGRADED状態のHDDが1台発生。
こちらはSMART情報が取れたので確認するとエラーが記録されていました。
何とか完了まで持ち堪えて欲しい。
初ST4000DM004ですが、2年で二台故障、一台エラー発生と耐久性が低いような感じがします。
2020/6/20追記)
一台目のresilver中に全HDDがDEGRADEDステータスになりヒヤッとしましたが、リブート後無事再開することができました。
一台目のresilver完了後に、二台目のHDDを入れ替えresilverを開始しましたが何方も6日程度時間がかかり、およそ12日で復旧となりました。
処理時速度は、resilver開始後に暫くして3桁MB/sになるも、直ぐに70MB/s程度になり徐々に減速し終了間際は52MB/s程度になり非常に低速です。
SMRが原因と思われるので、次に入れ替える時はCMRを選んでみようと思います。 4TBのHDD入れ替えで6日は、厳しいかなと思います。
ちなみに、プールの使用率は90%程度で空きが1.5TB程度ある状態、正常時の書き込みが激遅になっていないので、空き容量としては許容範囲かなと考えています。
Seagate BarraCudaはコスパが良くて気に入っていたのですが、SMRとzfsの相性はやはり悪そうです。
普段利用している時は特に不都合は感じないのですが、resilverの長時間書き込みではデメリットが顕著になるように感じました。
最近組んだPCのHDDもBarraCudaなのでSMRなんですよね、しかも6TBにしてしまいました。
他HDDのSMART情報から大体17740時間で壊れたようです。
予備と交換してresilver中にもう一台壊れました...。
たまたま二台とも故障時にPCの近くにいましたが、どちらも突然カッコン、カッコンと嫌な音を立てたあと鳴り止み御臨終です。
どちらもSMART情報も取れない状態。
まだ、1台目のresilverが完了していない状況ですが、zpool statusで進捗を確認するとDEGRADED状態のHDDが1台発生。
こちらはSMART情報が取れたので確認するとエラーが記録されていました。
何とか完了まで持ち堪えて欲しい。
初ST4000DM004ですが、2年で二台故障、一台エラー発生と耐久性が低いような感じがします。
2020/6/20追記)
一台目のresilver中に全HDDがDEGRADEDステータスになりヒヤッとしましたが、リブート後無事再開することができました。
一台目のresilver完了後に、二台目のHDDを入れ替えresilverを開始しましたが何方も6日程度時間がかかり、およそ12日で復旧となりました。
処理時速度は、resilver開始後に暫くして3桁MB/sになるも、直ぐに70MB/s程度になり徐々に減速し終了間際は52MB/s程度になり非常に低速です。
SMRが原因と思われるので、次に入れ替える時はCMRを選んでみようと思います。 4TBのHDD入れ替えで6日は、厳しいかなと思います。
ちなみに、プールの使用率は90%程度で空きが1.5TB程度ある状態、正常時の書き込みが激遅になっていないので、空き容量としては許容範囲かなと考えています。
Seagate BarraCudaはコスパが良くて気に入っていたのですが、SMRとzfsの相性はやはり悪そうです。
普段利用している時は特に不都合は感じないのですが、resilverの長時間書き込みではデメリットが顕著になるように感じました。
最近組んだPCのHDDもBarraCudaなのでSMRなんですよね、しかも6TBにしてしまいました。
2018年6月2日土曜日
新PC
サーバ利用しているPCの利用期間がそろそろ5年になるので、下記構成で新PCを作りました。
CentOS7, ZFS on Linuxをインストールして数日動かしていましたが安定しているようなので、ぼちぼちメイン環境を旧PCから移行しようと思います。
とりあえず、作業予定は以下です。
先日ようやく戻ってきて完成となったのですが、HDDが安くなってたり、XG-C100Cが日本で普通に買えるようになっていたりで微妙な気分です…。
- ASRock C236M WS
- Intel Xeon E3-1245v6
- DDR4-2400 8GB x2
- Seagate ST4000-DM004 x8
- HGST HDT725032VLA360 x1
- AREA SD-PE4SA3ES4L
- ASUS XG-C100C
CentOS7, ZFS on Linuxをインストールして数日動かしていましたが安定しているようなので、ぼちぼちメイン環境を旧PCから移行しようと思います。
とりあえず、作業予定は以下です。
- PT3の移設
- KVM環境の移行
- SoftEther VPN移行
先日ようやく戻ってきて完成となったのですが、HDDが安くなってたり、XG-C100Cが日本で普通に買えるようになっていたりで微妙な気分です…。
2017年10月30日月曜日
raidz2のHDD交換
I/Oエラーが頻発するようになったためHDDを交換しました。
SMARTの情報によると33716時間で交換です。
ST3000DM001からST3000DM008になりました。
SMARTの情報によると33716時間で交換です。
ST3000DM001からST3000DM008になりました。
2017年8月7日月曜日
2017年2月4日土曜日
2016年11月21日月曜日
2015年6月9日火曜日
raidz2のHDD交換
raidz2で使用しているHDDが1台壊れました。
SMARTから情報が取れなくなっていましたが、大体24000時間超は動作していたようです。
同時期に使い始めたHDDが同じプールにあるので、そろそろ交換かな？と思いながら、zfs replaceしたらresilver中にもう1台も壊れました。
RAID障害時にありがちなリビルド中の二重故障、raidz2にしていて良かった。
HDDを2台交換して作業終了。
HDD1台あたり、resilverに約14時間(2.7TB)かかりました。
SMARTから情報が取れなくなっていましたが、大体24000時間超は動作していたようです。
同時期に使い始めたHDDが同じプールにあるので、そろそろ交換かな？と思いながら、zfs replaceしたらresilver中にもう1台も壊れました。
RAID障害時にありがちなリビルド中の二重故障、raidz2にしていて良かった。
HDDを2台交換して作業終了。
HDD1台あたり、resilverに約14時間(2.7TB)かかりました。
2013年12月29日日曜日
ZFS on CentOS 6.5
新PCにCentOS 6.5をセットアップして、 ZFS on Linux をインストールしました。
構成はこんな感じです。
ブート時に高頻度でストールして、しばらく待っているとタイムアウトして起動するという状態で、安定性に欠けるため今回は諦めて、急遽、退役したものを引っ張りだしてきたという訳です。
さて、 ZFS on Linux ですが、RPMが用意されていてインストールが楽になっていました。
手順は、 RHEL/CentOS/SL のページにあります。
おまけにDKMS対応になっているので、Kernelアップデート時も楽ちんです。有難いですね。
今回は、RAIDZ-2でセットアップして、bonnie++で性能を測ってみました。
まあ、HDDは同じでも接続がSATA3で、CPUスペックも違うので当たり前なんですが。
構成はこんな感じです。
- ASRock H87E-ITX/ac
- Intel Core i7-4770S
- メモリ16GB
- HGST HDT725032VLA360 x1台
- Seagete ST3000DM001 x5台
ブート時に高頻度でストールして、しばらく待っているとタイムアウトして起動するという状態で、安定性に欠けるため今回は諦めて、急遽、退役したものを引っ張りだしてきたという訳です。
さて、 ZFS on Linux ですが、RPMが用意されていてインストールが楽になっていました。
手順は、 RHEL/CentOS/SL のページにあります。
おまけにDKMS対応になっているので、Kernelアップデート時も楽ちんです。有難いですね。
今回は、RAIDZ-2でセットアップして、bonnie++で性能を測ってみました。
# zpool status
pool: dtpool
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
dtpool ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
scsi-SATA_ST3000DM001-AAAAAAAAAAAA-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-BBBBBBBBBBBB-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-CCCCCCCCCCCC-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-DDDDDDDDDDDD-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-FFFFFFFFFFFF-part1 ONLINE 0 0 0
errors: No known data errors
#
bonnie++の結果はこんな感じです。
# zpool sttus
$ bonnie++
〜 略 〜
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
abcde.locald 31208M 155581 98 484348 42 196870 22 124679 78 423075 17 148.9 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 +++++ +++ +++++ +++ 7014 91 30914 94 +++++ +++ 17554 99
abcde.locald,31208M,155581,98,484348,42,196870,22,124679,78,423075,17,148.9,0,16,+++++,+++,+++++,+++,7014,91,30914,94,+++++,+++,17554,99
以前、MicroServerで計測した
stripe 、
raidz と比べると速いですね。まあ、HDDは同じでも接続がSATA3で、CPUスペックも違うので当たり前なんですが。
2013年11月26日火曜日
MicroServerのHDD故障
ワンセグ野郎で使用しているHP ProLiant MicroServerのHDDが壊れました。
ZFSの情報は次のような感じで、Express5800/GT110dのHDDと同じように物理的に認識しなくなっていました。
壊れたHDDの情報は読めないので、起動用HDDのS.M.A.R.Tの情報を確認すると通電時間は13536時間でした。 3年位は持ってほしいなぁ。
＃壊れたHDDのRMA期間は過ぎていました。残念。
ZFSの情報は次のような感じで、Express5800/GT110dのHDDと同じように物理的に認識しなくなっていました。
# zpool status
pool: dtpool
state: DEGRADED
status: One or more devices are faulted in response to persistent errors.
Sufficient replicas exist for the pool to continue functioning in a
degraded state.
action: Replace the faulted device, or use 'zpool clear' to mark the device
repaired.
scan: scrub repaired 44K in 66h55m with 0 errors on Tue Sep 10 20:31:00 2013
config:
NAME STATE READ WRITE CKSUM
dtpool DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
scsi-SATA_ST3000DM001-AAAAAAAAAAAA-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-BBBBBBBBBBBB-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-CCCCCCCCCCCC-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-DDDDDDDDDDDD-part1 FAULTED 0 854 0 too many errors
errors: No known data errors
ZFSのHDDリプレースは二回目なので、サクッと対応完了。壊れたHDDの情報は読めないので、起動用HDDのS.M.A.R.Tの情報を確認すると通電時間は13536時間でした。 3年位は持ってほしいなぁ。
＃壊れたHDDのRMA期間は過ぎていました。残念。
2013年9月14日土曜日
raidzのディスク交換
Express5800/GT110dで使用しているZFSが調子悪くなっていました。
zpool statusの結果はこんな感じです。
# zpool status
pool: dtpool
state: DEGRADED
status: One or more devices are faulted in response to IO failures.
action: Make sure the affected devices are connected, then run 'zpool clear'.
see: http://zfsonlinux.org/msg/ZFS-8000-HC
scan: resilvered 766G in 2h10m with 0 errors on Sun Dec 30 19:11:52 2012
config:
NAME STATE READ WRITE CKSUM
NAME STATE READ WRITE CKSUM
dtpool DEGRADED 18 4 0
raidz1-0 DEGRADED 48 12 0
scsi-SATA_ST3000DM001-AAAAAAAAAAAA-part1 FAULTED 0 286 0
too many errors
scsi-SATA_ST3000DM001-BBBBBBBBBBBB-part1 ONLINE 79 12 0
scsi-SATA_ST3000DM001-CCCCCCCCCCCC-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-DDDDDDDDDDDD-part1 ONLINE 0 0 0
errors: 20 data errors, use '-v' for a list
# zpool status -v
pool: dtpool
state: DEGRADED
status: One or more devices are faulted in response to IO failures.
action: Make sure the affected devices are connected, then run 'zpool clear'.
see: http://zfsonlinux.org/msg/ZFS-8000-HC
scan: resilvered 766G in 2h10m with 0 errors on Sun Dec 30 19:11:52 2012
config:
NAME STATE READ WRITE CKSUM
dtpool DEGRADED 18 4 0
raidz1-0 DEGRADED 48 12 0
scsi-SATA_ST3000DM001-AAAAAAAAAAAA-part1 FAULTED 0 286 0
too many errors
scsi-SATA_ST3000DM001-BBBBBBBBBBBB-part1 ONLINE 79 12 0
scsi-SATA_ST3000DM001-CCCCCCCCCCCC-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-DDDDDDDDDDDD-part1 ONLINE 0 0 0
errors: Permanent errors have been detected in the following files:
dtpool/ts:<0x0>
dtpool/ts:<0x4cf02>
dtpool/ts:<0x50c65>
dtpool/ts:<0x34d69>
dtpool/ts:<0x16271>
dtpool/ts:<0x47086>
dtpool/ts:<0x47088>
dtpool/ts:<0x4708b>
dtpool/ts:<0x4708d>
dtpool/ts:<0x4708f>
dtpool/ts:<0x47095>
dtpool/ts:<0x514a6>
dtpool/ts:<0x514a7>
dtpool/ts:<0x514a8>
dtpool/ts:<0x514ab>
dtpool/ts:<0x514ac>
dtpool/ts:<0x514b0>
dtpool/ts:<0x46fb6>
dtpool/ts:<0x330c1>
dtpool/ts:<0xffffffffffffffff>
#
zpool clearを実行しろとのことなので、実行してみます。
# zpool clear dtpool cannot clear errors for dtpool: I/O errorいやな予感。
# zpool status
pool: dtpool
state: UNAVAIL
status: One or more devices are faulted in response to IO failures.
action: Make sure the affected devices are connected, then run 'zpool clear'.
see: http://zfsonlinux.org/msg/ZFS-8000-HC
scan: resilvered 766G in 2h10m with 0 errors on Sun Dec 30 19:11:52 2012
config:
NAME STATE READ WRITE CKSUM
dtpool UNAVAIL 0 0 0
insufficient replicas
raidz1-0 UNAVAIL 0 0 0
insufficient replicas
scsi-SATA_ST3000DM001-AAAAAAAAAAAA-part1 FAULTED 0 0 0
too many errors
scsi-SATA_ST3000DM001-BBBBBBBBBBBB-part1 FAULTED 0 0 0
too many errors
scsi-SATA_ST3000DM001-CCCCCCCCCCCC-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-DDDDDDDDDDDD-part1 ONLINE 0 0 0
errors: 20 data errors, use '-v' for a list
#
2台、逝っちゃった？
rebootしてみると、FAULTEDになっているHDD2台が物理的に認識されていないようです。
少し離れた場所にあるのでshutdownして、翌日見に行くことにしました。
で、翌日。
raidzなので、2台壊れてたとなるとデータ復旧できないな…と考えながら電源を入れると、カッコン、カッコンと例の壊れたHDDの音を立てながら起動してきました。
幸いなことに認識しないのは1台だけになってました。 まあ、いずれ壊れるのでしょうけど。
zpool statusの結果はこんな感じ。
# zpool status -v
pool: dtpool
state: DEGRADED
status: One or more devices could not be used because the label is missing or
invalid. Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
see: http://zfsonlinux.org/msg/ZFS-8000-4J
scan: resilvered 766G in 2h10m with 0 errors on Sun Dec 30 19:11:52 2012
config:
NAME STATE READ WRITE CKSUM
dtpool DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
scsi-SATA_ST3000DM001-AAAAAAAAAAAA-part1 UNAVAIL 0 0 0
scsi-SATA_ST3000DM001-BBBBBBBBBBBB-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-CCCCCCCCCCCC-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-DDDDDDDDDDDD-part1 ONLINE 0 0 0
errors: No known data errors
早速、shutdownしてHDDを入れ替え、zpool replaceしてみます。
# ls /dev/disk/by-id/scsi-SATA_ST3000DM001-EEEEEEEEEEEE-part1 /dev/disk/by-id/scsi-SATA_ST3000DM001-EEEEEEEEEEEE-part1 # # zpool replace -f dtpool scsi-SATA_ST3000DM001-AAAAAAAAAAAA-part1 scsi-SATA_ST3000DM001-EEEEEEEEEEEE-part1 cannot replace scsi-SATA_ST3000DM001-AAAAAAAAAAAA-part1 with scsi-SATA_ST3000DM001-EEEEEEEEEEEE-part1: no such device in pooloffline, detatchも試してみましたが、
no such device in poolになります。
あれこれと試しながら、ググると情報(zpool attach throws "no such device in pool" error)があったので、試すとうまくいきました。使用しているバージョンは、zfs-0.6.0-rc9です。
こんな感じ。
# zpool replace -f dtpool /dev/disk/by-id/scsi-SATA_ST3000DM001-AAAAAAAAAAAA-part1 scsi-SATA_ST3000DM001-EEEEEEEEEEEE-part1
#
# zpool status
pool: dtpool
state: DEGRADED
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Sun Sep 8 16:04:04 2013
33.7G scanned out of 6.27T at 267M/s, 6h47m to go
8.42G resilvered, 0.52% done
config:
NAME STATE READ WRITE CKSUM
dtpool DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
replacing-0 UNAVAIL 0 0 0
scsi-SATA_ST3000DM001-AAAAAAAAAAAA-part1 UNAVAIL 0 0 0
scsi-SATA_ST3000DM001-EEEEEEEEEEEE-part1 ONLINE 0 0 0 (resilvering)
scsi-SATA_ST3000DM001-BBBBBBBBBBBB-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-CCCCCCCCCCCC-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-DDDDDDDDDDDD-part1 ONLINE 0 0 0
errors: No known data errors
#
うまくいってよかった。
2012年12月22日土曜日
ZFSの書き込み低速化?
ワンセグ野郎サーバがストールしていました。
リモートからログイン出来ず、ディスプレイ、キーボードも接続してなかったので電源断して再起動で対応。syslogにはこれといったメッセージは記録されていなかったが、3日ほどストールしていたようでした。
で、ワンセグ野郎の起動スクリプトを実行して復旧となったはずでしたが、数日後TSファイルが正常に記録されていないことに気がつきました。
番組表は更新されていたので気がつきませんでした…見たい番組がある時に限って。
ログを見るとdvbstreamが再起動を繰り返していて、ts.plのタイムアウト処理にかかっているのが直接原因のようです。
そこでdvbstramを単体で動かしてみましたが、シグナルレベルなどは問題ないようです。
しばらく調べていると出力をリダイレクトしたファイルサイズの増え方が遅いことに気がつきました。
まだ150GB位空きがあったので気にしていませんでしたが、どうもZFSは空き容量が少なくなると性能が低下するようです。取り合えず、200GBの空きを確保して試すと正常動作するようになりました。
時間と環境が出来たら、このあたり調べておきたいなぁ。
リモートからログイン出来ず、ディスプレイ、キーボードも接続してなかったので電源断して再起動で対応。syslogにはこれといったメッセージは記録されていなかったが、3日ほどストールしていたようでした。
で、ワンセグ野郎の起動スクリプトを実行して復旧となったはずでしたが、数日後TSファイルが正常に記録されていないことに気がつきました。
番組表は更新されていたので気がつきませんでした…見たい番組がある時に限って。
ログを見るとdvbstreamが再起動を繰り返していて、ts.plのタイムアウト処理にかかっているのが直接原因のようです。
そこでdvbstramを単体で動かしてみましたが、シグナルレベルなどは問題ないようです。
しばらく調べていると出力をリダイレクトしたファイルサイズの増え方が遅いことに気がつきました。
まだ150GB位空きがあったので気にしていませんでしたが、どうもZFSは空き容量が少なくなると性能が低下するようです。取り合えず、200GBの空きを確保して試すと正常動作するようになりました。
時間と環境が出来たら、このあたり調べておきたいなぁ。
2012年7月21日土曜日
ZFS mirror(2台)からraidz(4台)に移行
HDD4台でZFSを使うときに使用しそうなパターンで、4KセクタHDD向けの設定比較をして来ました。
結果を見ると設定した方が良いのかなという感じです。
さて、一通り試したいことは出来たので、2台のmirrorから4台のraidzに移行しようと思います。
環境は、こんな感じです。
まず、mirrorで使用していたHDD1台と、性能比較で使用したHDD3台(poolはdestroy済み)を接続します。
dtpoolとして使用していたものをopoolでインポートしています。
次に、移行先のraidzを作るためのダミーデバイスを作ります。
次のようにraidzのプールを作ります。
ダミーデバイス(ファイル)は、オフラインにしないとデータ移行時に書き込まれてしまうのでオフラインにします。/varに3TBなんてありません。
情報をみるとこんな感じになります。
zfsのsend,receiveでも良かったんですが、今回は進捗を見たかったのでrsyncを使いました。
TSデータ以外は、バックアップして整理したら意外と少なくなりました。
データ移行が完了したら、mirrorプールを削除して、raidzプールのダミーデバイスをリプレースします。
リプレース開始から暫くすると転送レートが安定して、それなりの終了時間がわかるようになります。
結果を見ると設定した方が良いのかなという感じです。
さて、一通り試したいことは出来たので、2台のmirrorから4台のraidzに移行しようと思います。
環境は、こんな感じです。
- HP ProLiant MicroServer
- Seagete ST3000DM001 x4台
- CentOS 6.2
- ZFS on Linux (0.6.0 RC8)
まず、mirrorで使用していたHDD1台と、性能比較で使用したHDD3台(poolはdestroy済み)を接続します。
$ cd /dev/disk/by-id $ ls scsi*ST3000*part1 scsi-SATA_ST3000DM001-9YN_Z1F0AAAA-part1 scsi-SATA_ST3000DM001-9YN_Z1F0BBBB-part1 scsi-SATA_ST3000DM001-9YN_Z1F0CCCC-part1 scsi-SATA_ST3000DM001-9YN_Z1F0DDDD-part1次のようにしてmirrorプールをimportします。
dtpoolとして使用していたものをopoolでインポートしています。
# zpool import -d /dev/disk/by-id/ dtpool opool
pool: opool
id: 3916950419245301417
state: DEGRADED
status: One or more devices contains corrupted data.
action: The pool can be imported despite missing or damaged devices. The
fault tolerance of the pool may be compromised if imported.
see: http://zfsonlinux.org/msg/ZFS-8000-4J
config:
opool DEGRADED
mirror-0 DEGRADED
ata-ST3000DM001-9YN166_Z1F0AAAA-part1 ONLINE
sdb1 FAULTED corrupted data
なんか、sta-*でimportされました。次に、移行先のraidzを作るためのダミーデバイスを作ります。
$ dd if=/dev/zefo of=/var/tmp/dummy bs=1024K count=1 seek=3000000raidzのデバイスの1つに穴開きファイルを使って、データ移行後に入れ換える作戦です。
次のようにraidzのプールを作ります。
# zpool create -o ashift=12 -f dtpool raidz \
/var/tmp/dummy \
scsi-SATA_ST3000DM001-9YN_Z1F0BBBB-part1 \
scsi-SATA_ST3000DM001-9YN_Z1F0CCCC-part1 \
scsi-SATA_ST3000DM001-9YN_Z1F0DDDD-part1
# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
dtpool 10.9T 912K 10.9T 0% 1.00x ONLINE -
opool 2.72T 2.32T 412G 85% 1.00x DEGRADED -
#
ashift=12で、4Kセクタ用の設定を指定しています。ダミーデバイス(ファイル)は、オフラインにしないとデータ移行時に書き込まれてしまうのでオフラインにします。/varに3TBなんてありません。
情報をみるとこんな感じになります。
# zpool offline dtpool /var/tmp/dummy
# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
dtpool 10.9T 912K 10.9T 0% 1.00x DEGRADED -
opool 2.72T 2.32T 412G 85% 1.00x DEGRADED -
# zpool status
pool: dtpool
state: DEGRADED
status: One or more devices has been taken offline by the administrator.
Sufficient replicas exist for the pool to continue functioning in a
degraded state.
action: Online the device using 'zpool online' or replace the device with
'zpool replace'.
scan: none requested
config:
NAME STATE READ WRITE CKSUM
dtpool DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
/var/tmp/dummy OFFLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0BBBB-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0CCCC-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0DDDD-part1 ONLINE 0 0 0
errors: No known data errors
pool: opool
state: DEGRADED
status: One or more devices could not be used because the label is missing or
invalid. Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
see: http://zfsonlinux.org/msg/ZFS-8000-4J
scan: resilvered 39K in 0h0m with 0 errors on Fri Jun 29 22:41:17 2012
config:
NAME STATE READ WRITE CKSUM
opool DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
ata-ST3000DM001-9YN166_Z1F0AAAA-part1 ONLINE 0 0 0
9459549258261188968 UNAVAIL 0 0 0 was /dev/sdb1
errors: No known data errors
次のようにして移行元のマウントを変更します。# zfs set mountpoint=/old/ts opool/ts # zfs set mountpoint=/old/backup opool/backup # zfs mount -a # df -h Filesystem Size Used Avail Use% Mounted on : /dev/sde3 20G 1.2G 18G 7% /var dtpool 7.8T 256K 7.8T 1% /dtpool opool 369G 128K 369G 1% /opool opool/ts 2.7T 2.4T 369G 87% /old/ts opool/backup 372G 2.7G 369G 1% /old/backup #移行先の領域をつくります。
# zfs create dtpool/ts # zfs create dtpool/backup # zfs set mountpoint=/data/ts dtpool/ts # zfs set mountpoint=/data/backup dtpool/backup # zfs mount -a # df -h Filesystem Size Used Avail Use% Mounted on : dtpool 7.8T 128K 7.8T 1% /dtpool opool 369G 128K 369G 1% /opool opool/ts 2.7T 2.4T 369G 87% /old/ts opool/backup 372G 2.7G 369G 1% /old/backup dtpool/ts 7.8T 128K 7.8T 1% /data/ts dtpool/backup 7.8T 128K 7.8T 1% /data/backup #領域が出来たのでデータ移行します。
zfsのsend,receiveでも良かったんですが、今回は進捗を見たかったのでrsyncを使いました。
TSデータ以外は、バックアップして整理したら意外と少なくなりました。
データ移行が完了したら、mirrorプールを削除して、raidzプールのダミーデバイスをリプレースします。
# zpool destroy opool
# zpool list
AME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
dtpool 10.9T 3.27T 7.61T 30% 1.00x DEGRADED -
# zpool status
pool: dtpool
state: DEGRADED
status: One or more devices has been taken offline by the administrator.
Sufficient replicas exist for the pool to continue functioning in a
degraded state.
action: Online the device using 'zpool online' or replace the device with
'zpool replace'.
scan: none requested
config:
NAME STATE READ WRITE CKSUM
dtpool DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
/var/tmp/dummy OFFLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0BBBB-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0CCCC-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0DDDD-part1 ONLINE 0 0 0
errors: No known data errors
# zpool replace dtpool /var/tmp/dummy scsi-SATA_ST3000DM001-9YN_Z1F0AAAA-part1
リプレース中は、次のような状態になります。リプレース開始から暫くすると転送レートが安定して、それなりの終了時間がわかるようになります。
# zpool status
pool: dtpool
state: DEGRADED
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Sun Jul 1 19:01:13 2012
35.4G scanned out of 3.27T at 232M/s, 4h3m to go
8.84G resilvered, 1.06% done
config:
NAME STATE READ WRITE CKSUM
dtpool DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
replacing-0 OFFLINE 0 0 0
/var/tmp/dummy OFFLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0AAAA-part1 ONLINE 0 0 0 (resilvering)
scsi-SATA_ST3000DM001-9YN_Z1F0BBBB-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0CCCC-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0DDDD-part1 ONLINE 0 0 0
errors: No known data errors
で、大体4時間後に完了しました。
# zpool status
pool: dtpool
state: ONLINE
scan: resilvered 836G in 3h51m with 0 errors on Sun Jul 1 22:53:02 2012
config:
NAME STATE READ WRITE CKSUM
dtpool ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0AAAA-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0BBBB-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0CCCC-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0DDDD-part1 ONLINE 0 0 0
errors: No known data errors
# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
dtpool 10.9T 3.28T 7.60T 30% 1.00x ONLINE -
時間はかかりましたが、特に問題なく移行完了できました。
2012年7月14日土曜日
ZFS ashift比較その4 - stripe(4台)
ZFSでの4KセクタHDD向け設定比較の最後はstripeです。
4台構成のstripeで、ashiftオプションの設定による違いを確認します。
次のようにしてpoolを作ります。
Sequential Writeのrewriteが2割強UPして、Block Readは1割UPしています。
4台構成のstripeで、ashiftオプションの設定による違いを確認します。
次のようにしてpoolを作ります。
# zpool create tank \
scsi-SATA_ST3000DM001-9YN_Z1F0AAAA-part1 \
scsi-SATA_ST3000DM001-9YN_Z1F0BBBB-part1 \
scsi-SATA_ST3000DM001-9YN_Z1F0CCCC-part1 \
scsi-SATA_ST3000DM001-9YN_Z1F0DDDD-part1
# zpool status
pool: tank
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0AAAA-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0BBBB-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0CCCC-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0DDDD-part1 ONLINE 0 0 0
errors: No known data errors
# zdb |grep ashift
ashift: 9
ashift: 9
ashift: 9
ashift: 9
# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
tank 10.9T 80.5K 10.9T 0% 1.00x ONLINE -
ashift=9の場合の結果は、次のようになります。
$ bonnie++
～ 略 ～
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
abcde.locald 15488M 44318 99 334959 92 139748 49 43830 95 279734 42 353.9 6
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 12951 99 +++++ +++ 13327 99 12333 99 +++++ +++ 14310 99
abcde.localdomain,15488M,44318,99,334959,92,139748,49,43830,95,279734,42,353.9,6,16,12951,99,+++++,+++,13327,99,12333,99,+++++,+++,14310,99
次はashift=12を指定してpoolを作ります。
# zpool destroy tank
# zpool create -o ashift=12 tank \
scsi-SATA_ST3000DM001-9YN_Z1F0AAAA-part1 \
scsi-SATA_ST3000DM001-9YN_Z1F0BBBB-part1 \
scsi-SATA_ST3000DM001-9YN_Z1F0CCCC-part1 \
scsi-SATA_ST3000DM001-9YN_Z1F0DDDD-part1
# zdb |grep ashift
ashift: 12
ashift: 12
ashift: 12
ashift: 12
# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
tank 10.9T 872K 10.9T 0% 1.00x ONLINE -
ashift=12の場合の結果は、次のようになります。
$ bonnie+++
～ 略 ～
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
abcde.locald 15488M 44671 99 347417 94 175133 62 44037 97 307946 47 374.0 6
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 12908 99 +++++ +++ 14430 99 11167 99 +++++ +++ 13170 98
abcde.localdomain,15488M,44671,99,347417,94,175133,62,44037,97,307946,47,374.0,6,16,12908,99,+++++,+++,14430,99,11167,99,+++++,+++,13170,98
並べるとこんな感じです。Sequential Writeのrewriteが2割強UPして、Block Readは1割UPしています。
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
ashift=9 15488M 44318 99 334959 92 139748 49 43830 95 279734 42 353.9 6
ashift=12 15488M 44671 99 347417 94 175133 62 44037 97 307946 47 374.0 6
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
ashift=9 16 12951 99 +++++ +++ 13327 99 12333 99 +++++ +++ 14310 99
ashift=12 16 12908 99 +++++ +++ 14430 99 11167 99 +++++ +++ 13170 98
Sequential Block Write/Readは、2台構成のmirrorと比べ大体3倍になっています。ZFS ashift比較その3 - raidz(4台)
今回は、RAIDZ構成で比較します。
4台構成のraidzで、ashiftオプションの設定による違いを確認します。
まずは、ashit=9でpoolを作ります。
Sequential Writeのrewriteが2割強UPして、Block Readが3割強DOWNしています。
2台のmirror構成から4台のraidz構成に移行を考えているので、ashiftの設定をどちらにするか悩ましいところです。
4台構成のraidzで、ashiftオプションの設定による違いを確認します。
まずは、ashit=9でpoolを作ります。
# zpool create tank raidz \
scsi-SATA_ST3000DM001-9YN_Z1F0AAAA-part1 \
scsi-SATA_ST3000DM001-9YN_Z1F0BBBB-part1 \
scsi-SATA_ST3000DM001-9YN_Z1F0CCCC-part1 \
scsi-SATA_ST3000DM001-9YN_Z1F0DDDD-part1
# zpool status
pool: tank
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0AAAA-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0BBBB-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0CCCC-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0DDDD-part1 ONLINE 0 0 0
errors: No known data errors
# zdb |grep ashift
ashift: 9
# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
tank 10.9T 148K 10.9T 0% 1.00x ONLINE -
ashift=9の場合の結果は、次のようになります。
$ bonnie++
～ 略 ～
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
abcde.locald 15488M 45119 98 198220 54 96029 35 41985 94 353884 55 233.7 5
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 13007 99 +++++ +++ 13452 98 12167 99 +++++ +++ 14491 99
abcde.localdomain,15488M,45119,98,198220,54,96029,35,41985,94,353884,55,233.7,5,16,13007,99,+++++,+++,13452,98,12167,99,+++++,+++,14491,99
次は、ashift=12でpoolを作ります。
# zpool destroy tank
# zpool create -o ashift=12 tank raidz \
scsi-SATA_ST3000DM001-9YN_Z1F0AAAA-part1 \
scsi-SATA_ST3000DM001-9YN_Z1F0BBBB-part1 \
scsi-SATA_ST3000DM001-9YN_Z1F0CCCC-part1 \
scsi-SATA_ST3000DM001-9YN_Z1F0DDDD-part1
# zdb |grep ashift
ashift: 12
# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
tank 10.9T 1.08M 10.9T 0% 1.00x ONLINE -
ashift=12の場合の結果は、次のようになります。
$ bonnie++
～ 略 ～
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
abcde.locald 15488M 44184 98 217651 57 120804 43 43254 93 228627 36 227.7 5
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 12981 99 +++++ +++ 13074 98 12308 99 +++++ +++ 14327 99
abcde.localdomain,15488M,44184,98,217651,57,120804,43,43254,93,228627,36,227.7,5,16,12981,99,+++++,+++,13074,98,12308,99,+++++,+++,14327,99
並べるとこんな感じになります。Sequential Writeのrewriteが2割強UPして、Block Readが3割強DOWNしています。
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
ashift=9 15488M 45119 98 198220 54 96029 35 41985 94 353884 55 233.7 5
ashift=12 15488M 44184 98 217651 57 120804 43 43254 93 228627 36 227.7 5
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
ashift=9 16 13007 99 +++++ +++ 13452 98 12167 99 +++++ +++ 14491 99
ashift=12 16 12981 99 +++++ +++ 13074 98 12308 99 +++++ +++ 14327 99
Sequential block readで、性能ダウンするのは少し予想と違う結果になりました。2台のmirror構成から4台のraidz構成に移行を考えているので、ashiftの設定をどちらにするか悩ましいところです。
2012年7月8日日曜日
ZFS ashift比較その2 - raid10
今回は、RAID10構成で比較します。
4台でmirror+stripeの構成を作り、ashiftオプションの設定による違いを確認します。
まずは、ashift=9から。
次は、ashift=12。
並べるとこんな感じになります。
Sequential Writeが2割強UPしてるのが目立ちます。
まずは、ashift=9から。
# zpool create tank \
mirror scsi-SATA_ST3000DM001-9YN_Z1F0AAAA-part1 \
scsi-SATA_ST3000DM001-9YN_Z1F0BBBB-part1 \
mirror scsi-SATA_ST3000DM001-9YN_Z1F0CCCC-part1 \
scsi-SATA_ST3000DM001-9YN_Z1F0DDDD-part1
# zpool status
pool: tank
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0AAAA-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0BBBB-part1 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0CCCC-part1 ONLINE 0 0 0
scsi-SATA_ST3000DM001-9YN_Z1F0DDDD-part1 ONLINE 0 0 0
errors: No known data errors
# zdb |grep ashift
ashift: 9
ashift: 9
# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
tank 5.44T 110K 5.44T 0% 1.00x ONLINE -
ashift=9のbonnie++の結果は、次のようになります。
# bonnie++
～ 略 ～
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
abcde.locald 15488M 45686 99 190095 60 99181 36 43745 93 192523 32 335.0 6
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 12889 97 +++++ +++ 14336 99 12505 99 +++++ +++ 14838 99
abcde.localdomain,15488M,45686,99,190095,60,99181,36,43745,93,192523,32,335.0,6,16,12889,97,+++++,+++,14336,99,12505,99,+++++,+++,14838,99
次は、ashift=12。
# zpool destroy tank
# zpool create -o ashift=12 tank \
mirror scsi-SATA_ST3000DM001-9YN_Z1F0AAAA-part1 \
scsi-SATA_ST3000DM001-9YN_Z1F0BBBB-part1 \
mirror scsi-SATA_ST3000DM001-9YN_Z1F0CCCC-part1 \
scsi-SATA_ST3000DM001-9YN_Z1F0DDDD-part1
# zdb |grep ashift
ashift: 12
ashift: 12
# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
tank 5.44T 110K 5.44T 0% 1.00x ONLINE -
ashift=12の結果は、次のようになります。
# bonnie+++
～ 略 ～
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
abcde.locald 15488M 44152 99 240200 74 112329 42 44438 95 195719 32 342.1 6
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 12948 99 +++++ +++ 13296 98 12095 99 +++++ +++ 14483 99
abcde.localdomain,15488M,44152,99,240200,74,112329,42,44438,95,195719,32,342.1,6,16,12948,99,+++++,+++,13296,98,12095,99,+++++,+++,14483,99
並べるとこんな感じになります。
Sequential Writeが2割強UPしてるのが目立ちます。
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
ashift=9 15488M 45686 99 190095 60 99181 36 43745 93 192523 32 335.0 6
ashift=12 15488M 44152 99 240200 74 112329 42 44438 95 195719 32 342.1 6
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
ashift=9 16 12889 97 +++++ +++ 14336 99 12505 99 +++++ +++ 14838 99
ashift=12 16 12948 99 +++++ +++ 13296 98 12095 99 +++++ +++ 14483 99
前回の2台構成のmirrorと比べるとRAID1とRAID10の比較になるので予想通りですが、Sequential Read/Writeがほぼ2倍になっていることが分かります。2012年7月7日土曜日
ZFS ashift比較その1 - mirror(2台)
4KBセクタのHDDを使用しているHP ProLiant MicroServer, CentOS 6.2, ZFS on Linuxという環境で、ashiftの設定による性能を比較します。
環境はこんな感じです。
まずは、今まで使用していた2台構成のmirrorで、ashiftオプションの設定による違いを確認します。
ashiftには、512byteセクタの場合は9、4096byteの場合は12を指定することになります。
こんな感じでpoolを作ります。
Seagate ST3000DM001は、論理セクタサイズを512byteと返すので、デフォルトだとashiftは9が使用されるようです。
次は、4096byte用の設定を試します。
pool作製時に、
Sequrntial Block Write/Readが大体1,2割性能UPしています。
Per charは、まあそんな感じかという値ですが、Random Create/Delteは、面白い結果ですね。
環境はこんな感じです。
$ uname -r 2.6.32-220.23.1.el6.x86_64 $ rpm -q zfs-* spl-* zfs-0.6.0-rc8.x86_64 spl-0.6.0-rc8.x86_64
まずは、今まで使用していた2台構成のmirrorで、ashiftオプションの設定による違いを確認します。
ashiftには、512byteセクタの場合は9、4096byteの場合は12を指定することになります。
こんな感じでpoolを作ります。
Seagate ST3000DM001は、論理セクタサイズを512byteと返すので、デフォルトだとashiftは9が使用されるようです。
# zpool create tank mirror \
scsi-SATA_ST3000DM001-9YN_Z1F0AAAA-part1 \
scsi-SATA_ST3000DM001-9YN_Z1F0BBBB-part1
# zdb |grep ashift
ashift: 9
# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
tank 2.72T 552K 2.72T 0% 1.00x ONLINE -
#
ashift=9の場合の結果は、次のようになりました。
# bonnie++
～ 略 ～
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
abcde.locald 15488M 45832 99 114327 36 47687 20 41445 90 93675 16 265.3 4
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 13073 99 +++++ +++ 14567 99 7688 99 +++++ +++ 5378 99
abcde.localdomain,15488M,45832,99,114327,36,47687,20,41445,90,93675,16,265.3,4,16,13073,99,+++++,+++,14567,99,7688,99,+++++,+++,5378,99
次は、4096byte用の設定を試します。
pool作製時に、
-o ashift=12を指定します。
# zpool destroy tank
# zpool create -o ashift=12 tank mirror \
scsi-SATA_ST3000DM001-9YN_Z1F0AAAA-part1 \
scsi-SATA_ST3000DM001-9YN_Z1F0BBBB-part1
# zdb |grep ashift
ashift: 12
# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
tank 2.72T 552K 2.72T 0% 1.00x ONLINE -
#
ashift=12の場合の結果は、次のようになりました。
# bonnie++
～ 略 ～
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
abcde.locald 15488M 43242 99 135921 41 58642 24 43621 93 105678 19 284.4 5
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 12874 99 +++++ +++ 14309 99 11690 99 +++++ +++ 13996 99
abcde.localdomain,15488M,43242,99,135921,41,58642,24,43621,93,105678,19,284.4,5,16,12874,99,+++++,+++,14309,99,11690,99,+++++,+++,13996,99
結果を並べるとこんな感じになります。Sequrntial Block Write/Readが大体1,2割性能UPしています。
Per charは、まあそんな感じかという値ですが、Random Create/Delteは、面白い結果ですね。
------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
ashift=9 15488M 45832 99 114327 36 47687 20 41445 90 93675 16 265.3 4
ashift=12 15488M 43242 99 135921 41 58642 24 43621 93 105678 19 284.4 5
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
ashift=9 16 13073 99 +++++ +++ 14567 99 7688 99 +++++ +++ 5378 99
ashift=12 16 12874 99 +++++ +++ 14309 99 11690 99 +++++ +++ 13996 99
それぞれの設定についてbonnie++で数回計測したところ、大体同じような結果になったので初回実行時の結果を載せています。
2012年6月30日土曜日
ProLiant MicroServerにHDDを追加する
現在、HP ProLiant MicroServerに2台のHDDを入れてZFSのmirrorで使用しています。
使用しているHDDは、Seagate ST3000DM001で、4Kセクタのドライブです。
セットアップ時に、partedの情報で論理セクタサイズが512バイトに見えている事は分かっていましたが、SmartAlign技術が搭載されていたはずだということで気にしていませんでした。
が、ZFSで4Kセクタ向けの設定をすれば、もう少し性能が出るのでは?と今更ながら思いつきました。
調べるまでも無く、ZFS on LinuxのFAQにAdvanced Formet Drivesについての記述がありましたよ。
そう言えば、セットアップのときは、Write Cacheの件で面倒くさくなって適当に切り上げたんだった…。
もう少しHDDの値段が下がるのを待てばよかったんですが、結局、ST3000DM001を追加で買ってしまったので、軽く性能を比べてからmirrorからraidzに移行しようと思います。
使用しているHDDは、Seagate ST3000DM001で、4Kセクタのドライブです。
セットアップ時に、partedの情報で論理セクタサイズが512バイトに見えている事は分かっていましたが、SmartAlign技術が搭載されていたはずだということで気にしていませんでした。
が、ZFSで4Kセクタ向けの設定をすれば、もう少し性能が出るのでは?と今更ながら思いつきました。
調べるまでも無く、ZFS on LinuxのFAQにAdvanced Formet Drivesについての記述がありましたよ。
そう言えば、セットアップのときは、Write Cacheの件で面倒くさくなって適当に切り上げたんだった…。
もう少しHDDの値段が下がるのを待てばよかったんですが、結局、ST3000DM001を追加で買ってしまったので、軽く性能を比べてからmirrorからraidzに移行しようと思います。
2012年6月2日土曜日
ワンセグ野郎 with ProLiant MicroServer
少し間が空きましたが実験の続きです。
ZFS on Linuxでmirror設定のプールにDeduplicationを有効にして、ワンセグ野郎を動作させ8ch分のTSデータの記録を始めました。
約一日動かして様子をみるとワンセグ野郎だけ動作させた状態だと、いつものサイズ(188,70x,xxx ±188byte数個分)で安定してTSファイルを書き込むことができるようです。
しかし、ファイルサーバとしても使う予定なので、ワンセグ野郎が安定動作するだけでは足りません。
次は、ワンセグ野郎を動かしつつ、旧PCに溜まった約900MBのTSファイルをrsyncして負荷をかけます。
…しばらく動かしていると、dvbstreamが終了してしまいました。ts.plによって起動し直されるので、定期的に再起動を繰り返します。
どうも字幕データの取り込み処理が動くタイミングでdvbstreamが終了してしまうようですが、当該処理をcronから外しても、タイミングがずれるだけでdvbstreamはやはり終了してしまうため、直接原因というわけではなさそうです。
結局、dvbstreamにstraceかけ、ざっとソースを見てもあたりが付かず、ライブデバックするまでのモチベーションも無かったので原因特定は諦めました。（タイミングの問題っぽくて、面倒くさそうだったのもあります）
で、Deduplicationを無効にして再開すると、問題なくrsyncが完了したのでこの設定で運用することにしました。
zdbの情報によると、TSデータでは、Deduplicationの効果はあまりでないようです。
ZFS on Linuxでmirror設定のプールにDeduplicationを有効にして、ワンセグ野郎を動作させ8ch分のTSデータの記録を始めました。
約一日動かして様子をみるとワンセグ野郎だけ動作させた状態だと、いつものサイズ(188,70x,xxx ±188byte数個分)で安定してTSファイルを書き込むことができるようです。
しかし、ファイルサーバとしても使う予定なので、ワンセグ野郎が安定動作するだけでは足りません。
次は、ワンセグ野郎を動かしつつ、旧PCに溜まった約900MBのTSファイルをrsyncして負荷をかけます。
…しばらく動かしていると、dvbstreamが終了してしまいました。ts.plによって起動し直されるので、定期的に再起動を繰り返します。
どうも字幕データの取り込み処理が動くタイミングでdvbstreamが終了してしまうようですが、当該処理をcronから外しても、タイミングがずれるだけでdvbstreamはやはり終了してしまうため、直接原因というわけではなさそうです。
結局、dvbstreamにstraceかけ、ざっとソースを見てもあたりが付かず、ライブデバックするまでのモチベーションも無かったので原因特定は諦めました。（タイミングの問題っぽくて、面倒くさそうだったのもあります）
で、Deduplicationを無効にして再開すると、問題なくrsyncが完了したのでこの設定で運用することにしました。
zdbの情報によると、TSデータでは、Deduplicationの効果はあまりでないようです。
# zdb -S dtpool
Simulated DDT histogram:
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 7.48M 950G 950G 950G 7.48M 950G 950G 950G
2 1.27K 84.9M 84.9M 84.9M 2.89K 175M 175M 175M
4 283 1.26M 1.26M 1.26M 1.32K 6.77M 6.77M 6.77M
8 110 882K 882K 882K 1.09K 8.42M 8.42M 8.42M
16 8 132K 132K 132K 182 3.09M 3.09M 3.09M
32 1 512 512 512 42 21K 21K 21K
64 1 512 512 512 78 39K 39K 39K
Total 7.48M 950G 950G 950G 7.49M 950G 950G 950G
dedup = 1.00, compress = 1.00, copies = 1.00, dedup * compress / copies = 1.00
登録:
投稿 (Atom)