☰

Ubuntu 16.04 - フリーズした mdadm アレイ

tag-icon • tag-icon ubuntu lvm mdadm
Ubuntu 16.04 - フリーズした mdadm アレイ

私は6台の4TBディスクで構成されたRAID5アレイを稼働させていました。Smartdはディスクの1台が故障し始めたことを報告しました。私は1回の操作でいくつかのことを行うことにしました: 1) 故障したディスクを削除する 2) 代わりに新しいディスクを追加する 3) アレイにさらにディスクを追加して拡張する

（3）には小さいディスクしかなかったので、LVMを使用して4TBを超えるボリュームに小さいディスクを結合しました。

私が実行したシーケンスは次のとおりです。

1) vgcreate vg_sdi_sdj /dev/sdi1 /dev/sdj1
2) vgcreate vg_sdj_sdl /dev/sdk1 /dev/sdl1
3) lvcreate -l 100%FREE -n all vg_sdi_sdj
4) lvcreate -l 100%FREE -n all vg_sdk_sdl
5) mdadm --manage /dev/md1 --add /dev/sdg1
6) mdadm --manage /dev/md1 --add /dev/vg_sdi_sdj/all
7) mdadm --manage /dev/md1 --add /dev/vg_sdk_sdl/all
8) mdadm --manage /dev/md1 --fail /dev/sdc1
9) mdadm --grow --raid-devices=8 --backup-file=/home/andrei/grow_md1.bak /dev/md1

最初はすべてがほぼ順調に進んでいました。アレイの再構築が始まりました。唯一の奇妙な点は、バックアップファイルが作成されなかったことです。

watch -n 1 mdadm --detail /dev/md1
nmon

状況を監視できるようにバックグラウンドで実行します。再構築が行われている間も、アレイにアクセスできました。

しかし、プロセスの 9% で、/dev/sdb と /dev/sdb1 の 100% 読み取りを除いて、アレイ上のすべての I/O が停止しました。watch -n 1 mdadm を強制終了すると、それも停止しました。

以下は、mdadm --detail からの最近の出力です。

/dev/md1:
Version : 1.2   Creation Time : Sun Jan  8 22:16:01 2017
Raid Level : raid5
Array Size : 19534430720 (18629.49 GiB 20003.26 GB)   Used Dev Size : 3906886144 (3725.90 GiB 4000.65 GB)    Raid Devices : 8   Total
Devices : 8
Persistence : Superblock is persistent

Intent Bitmap : Internal

Update Time : Sun Jan 15 21:38:17 2017
      State : clean, degraded, reshaping  Active Devices : 7 Working Devices : 8  Failed Devices : 0   Spare Devices : 1

     Layout : left-symmetric
 Chunk Size : 512K

 Reshape Status : 9% complete   Delta Devices : 2, (6->8)

       Name : server:1  (local to host server)
       UUID : bec66f95:2975e7ae:8f8ba15c:8eb3a33f
     Events : 79504

Number   Major   Minor   RaidDevice State
   0       8       17        0      active sync   /dev/sdb1
   9     252        0        1      spare rebuilding   /dev/dm-0
   2       8       49        2      active sync   /dev/sdd1
   3       8      145        3      active sync   /dev/sdj1
   4       8      161        4      active sync   /dev/sdk1
   6       8      177        5      active sync   /dev/sdl1
   8     252        1        6      active sync   /dev/dm-1
   7       8      129        7      active sync   /dev/sdi1

アレイ上で I/O を実行できませんでした。htop を実行すると、1 つの CPU コアが I/O 操作を 100% 実行していることが示されました。

マシンを再起動しました。アレイは再組み立てされませんでした。次のコマンドを実行して手動で再組み立てしました。

mdadm --assemble /dev/md1 --force /dev/sdb1 /dev/sdd1 /dev/sdi1 /dev/sdj1 /dev/sdk1 /dev/sdl1 /dev/vg_sdi_sdj/all /dev/vg_sdk_sdl/all

(再起動後、ディスクの名前が変更されました)。ただし、lvm はボリュームとグループを正しく検出し、起動しました。

強制的に実行しないと、ボールは動きません。アセンブルされ、上記の --detail レポートが表示されました。

しかし、それでも I/O は許可されないため、マウント コマンドはフリーズしました (そこに単一のディスク LVM があり、内部に ext4 ファイルシステムがあります)。htop では、I/O で固定された 1 つの CPU コアも表示されました。

ただし、ディスク アクティビティ LED はどれも点灯しません。

現時点では、大量のデータが入っている非機能的な配列で行き詰まっています。理想的には、データを取得したいと思います。

おそらく、LVM 論理ボリュームを mdadm「ディスク」として使用するのは間違いだったのでしょう。ただし、それが機能しないことを示す情報は見つかりませんでした。

アレイを回復する方法についてアドバイスやヒントをいただければ幸いです。

journalctl -xe を詳しく調べたところ、次のことがわかりました。

Jan 15 22:41:15 server sudo[1612]:   andrei : TTY=tty1 ; PWD=/home/andrei ; USER=root ; COMMAND=/sbin/mdadm --assemble /dev/md1 --force /dev/sdb1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1 /dev/sdh1 /dev/vg_sdi_sdj/all /dev/vg_sdk_sdl/all
Jan 15 22:41:15 server sudo[1612]: pam_unix(sudo:session): session opened for user root by andrei(uid=0)
Jan 15 22:41:15 server kernel: md: md1 stopped.
Jan 15 22:41:15 server kernel: md: bind<dm-1>
Jan 15 22:41:15 server kernel: md: bind<sdd1>
Jan 15 22:41:15 server kernel: md: bind<sdg1>
Jan 15 22:41:15 server kernel: md: bind<sdh1>
Jan 15 22:41:15 server kernel: md: bind<sdf1>
Jan 15 22:41:15 server kernel: md: bind<dm-0>
Jan 15 22:41:15 server kernel: md: bind<sde1>
Jan 15 22:41:15 server kernel: md: bind<sdb1>
Jan 15 22:41:15 server mdadm[879]: NewArray event detected on md device /dev/md1
Jan 15 22:41:15 server mdadm[879]: DegradedArray event detected on md device /dev/md1
Jan 15 22:41:15 server kernel: md/raid:md1: reshape will continue
Jan 15 22:41:15 server kernel: md/raid:md1: device sdb1 operational as raid disk 0
Jan 15 22:41:15 server kernel: md/raid:md1: device sde1 operational as raid disk 7
Jan 15 22:41:15 server kernel: md/raid:md1: device dm-0 operational as raid disk 6
Jan 15 22:41:15 server kernel: md/raid:md1: device sdf1 operational as raid disk 5
Jan 15 22:41:15 server kernel: md/raid:md1: device sdh1 operational as raid disk 4
Jan 15 22:41:15 server kernel: md/raid:md1: device sdg1 operational as raid disk 3
Jan 15 22:41:15 server kernel: md/raid:md1: device sdd1 operational as raid disk 2
Jan 15 22:41:15 server kernel: md/raid:md1: allocated 8606kB
Jan 15 22:41:15 server kernel: md/raid:md1: raid level 5 active with 7 out of 8 devices, algorithm 2
Jan 15 22:41:15 server kernel: RAID conf printout:
Jan 15 22:41:15 server kernel:  --- level:5 rd:8 wd:7
Jan 15 22:41:15 server kernel:  disk 0, o:1, dev:sdb1
Jan 15 22:41:15 server kernel:  disk 1, o:1, dev:dm-1
Jan 15 22:41:15 server kernel:  disk 2, o:1, dev:sdd1
Jan 15 22:41:15 server kernel:  disk 3, o:1, dev:sdg1
Jan 15 22:41:15 server kernel:  disk 4, o:1, dev:sdh1
Jan 15 22:41:15 server kernel:  disk 5, o:1, dev:sdf1
Jan 15 22:41:15 server kernel:  disk 6, o:1, dev:dm-0
Jan 15 22:41:15 server kernel:  disk 7, o:1, dev:sde1
Jan 15 22:41:15 server kernel: created bitmap (30 pages) for device md1
Jan 15 22:41:15 server kernel: md1: bitmap initialized from disk: read 2 pages, set 7 of 59615 bits
Jan 15 22:41:16 server kernel: md1: detected capacity change from 0 to 20003257057280
Jan 15 22:41:16 server kernel: md: reshape of RAID array md1
Jan 15 22:41:16 server kernel: md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
Jan 15 22:41:16 server kernel: md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reshape.
Jan 15 22:41:16 server kernel: md: using 128k window, over a total of 3906886144k.
Jan 15 22:41:16 server mdadm[879]: RebuildStarted event detected on md device /dev/md1
Jan 15 22:41:16 server sudo[1612]: pam_unix(sudo:session): session closed for user root
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589312 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589320 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589328 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589336 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589344 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589352 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589360 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589368 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759589376 on sdf1)
Jan 15 22:41:23 server kernel: md/raid:md1: read error corrected (8 sectors at 759582288 on sdf1)
...
Jan 15 22:43:36 server kernel: INFO: task md1_reshape:1637 blocked for more than 120 seconds.
Jan 15 22:43:36 server kernel:       Not tainted 4.4.0-59-generic #80-Ubuntu
Jan 15 22:43:36 server kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 15 22:43:36 server kernel: md1_reshape     D ffff88021028bb68     0  1637      2 0x00000000
Jan 15 22:43:36 server kernel:  ffff88021028bb68 ffff88021028bb80 ffffffff81e11500 ffff88020f5e8e00
Jan 15 22:43:36 server kernel:  ffff88021028c000 ffff8800c6993288 ffff88021028bbe8 ffff88021028bd14
Jan 15 22:43:36 server kernel:  ffff8800c6993000 ffff88021028bb80 ffffffff818343f5 ffff8802144c7000
Jan 15 22:43:36 server kernel: Call Trace:
Jan 15 22:43:36 server kernel:  [<ffffffff818343f5>] schedule+0x35/0x80
Jan 15 22:43:36 server kernel:  [<ffffffffc01d2fec>] reshape_request+0x7fc/0x950 [raid456]
Jan 15 22:43:36 server kernel:  [<ffffffff810c4240>] ? wake_atomic_t_function+0x60/0x60
Jan 15 22:43:36 server kernel:  [<ffffffffc01d346b>] sync_request+0x32b/0x3b0 [raid456]
Jan 15 22:43:36 server kernel:  [<ffffffff81833d46>] ? __schedule+0x3b6/0xa30
Jan 15 22:43:36 server kernel:  [<ffffffff8140c305>] ? find_next_bit+0x15/0x20
Jan 15 22:43:36 server kernel:  [<ffffffff81704c5c>] ? is_mddev_idle+0x9c/0xfa
Jan 15 22:43:36 server kernel:  [<ffffffff816a20fc>] md_do_sync+0x89c/0xe60
Jan 15 22:43:36 server kernel:  [<ffffffff810c4240>] ? wake_atomic_t_function+0x60/0x60
Jan 15 22:43:36 server kernel:  [<ffffffff8169e689>] md_thread+0x139/0x150
Jan 15 22:43:36 server kernel:  [<ffffffff810c4240>] ? wake_atomic_t_function+0x60/0x60
Jan 15 22:43:36 server kernel:  [<ffffffff8169e550>] ? find_pers+0x70/0x70
Jan 15 22:43:36 server kernel:  [<ffffffff810a0c08>] kthread+0xd8/0xf0
Jan 15 22:43:36 server kernel:  [<ffffffff810a0b30>] ? kthread_create_on_node+0x1e0/0x1e0
Jan 15 22:43:36 server kernel:  [<ffffffff8183888f>] ret_from_fork+0x3f/0x70
Jan 15 22:43:36 server kernel:  [<ffffffff810a0b30>] ? kthread_create_on_node+0x1e0/0x1e0

答え1

これに LVM を使用するのは確かに間違いでした。作成者以外の人にとっては不必要に複雑なストレージ スタックになるだけでなく、MD アレイは LVM アレイの前に構築されるため、MD メンバーとして動作している LV で MD スキャンを手動で呼び出す必要があります。

さらに、永続的な構成ではカーネル デバイス名 (sda、sdb など) の使用を避けてください。これは、ボリューム グループに名前を付けるときに特に関係します。VG は基礎となるストレージを抽象化し、PV 間で自由に移動できるためです。カーネル デバイス名も永続的とは見なされず、さまざまな理由でいつでも変更される可能性があります。これは LVM PV では問題になりません (これらは大規模なディスク スキャンの一部であり、ほとんど何でも検出するため)。ただし、作成した状況では、VG 名はすぐに現実を反映しなくなります。

MD アレイから LV を正常に削除し、劣化した (ただし正常な) 状態に戻すことをお勧めします。LVM 上の MD は、バグを潰すときに人々が気にするものではないことに注意してください。未知の領域であり、動作すると期待していたものが、明らかな理由もなく失敗する可能性があります。

このデータが重要で、バックアップされていない場合は、LVM と MD を本当によく知っているオンサイトの担当者に任せたほうがよいでしょう。ここで質問しているということは、そのような担当者はいないと想定していますので、必要な場合は話し合いましょう。その方法を採用する必要がある場合は、興味深い詳細があればこれを更新します。今のところは、LVM の混乱をメンバーの単純な古いディスクに置き換えることで、後退を試みてください。

関連情報