web-dev-qa-db-ja.com

Ubuntu16.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コアが100％I/O操作を実行していることがわかりました。

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

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が許可されないため、mountコマンドがフリーズしました（単一のディスク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
ubuntulvmmdadm
3
Ghostrider

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

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

MDアレイからLVを正常に削除し、劣化した（ただし正常な）状態に戻すことをお勧めします。 LVM上のMDは、バグを壊すときに人々が気にするものではないことに注意してください。あなたは未知の領域にいます、そしてあなたが働くことを期待することは明白な理由なしに失敗するかもしれません。

このデータが重要でバックアップされていない場合は、LVMとMDを本当によく知っているオンサイトの誰かに任せたいと思うでしょう。ここで聞いているので、持っていないのではないかと思いますので、必要に応じて会話しましょう。そのルートに行かなければならない場合は、興味深い詳細でこれを更新します。今のところ、LVMの混乱をメンバー用のプレーンな古いディスクに置き換えて、バックペダルを実行してみてください。

8
Spooler