重启机器导致lvm莫名丢失

写在前面

喜欢ceph的话欢迎关注奋斗的cepher微信公众号阅读更多好文！

有段日志没更新了，最近又是扩容集群，又是上线新池，事情较多，尤其是其中一个比较大的项目，总计上线超过100PB，今天更新的诡异现象，就是在这个百PB项目中发现的。

发现问题

按部就班自动化部署、自动化配置、自动化测试，都进行得挺顺利的，测试结果一看，有一个集群cosbench性能明显比其他集群低，大概低了30%，其他集群的16K并发测试，基本都能跑到5w-6w之间，而这个集群却只有4w左右，性能低这么多肯定是有啥不可告人的隐患

检查了一遍，配置没啥问题，数据流入也挺平均，应该不是某些osd拖累的，嗯～～重启一下集群的所有集群？

说干就干，测试集群问题不大，马上来个ansible all -i hosts -m shell -a '/usr/sbin/reboot' -become

等了10分钟，一看集群，傻眼了，居然有900多个osd没起来！随机挑了一台进去看

[root@osd72 log]# lsblk
NAME                                                                                                  MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                                                                                                     8:0    0   1.1T  0 disk
├─sda1                                                                                                  8:1    0   300M  0 part /boot/efi
├─sda2                                                                                                  8:2    0     2G  0 part /boot
├─sda3                                                                                                  8:3    0    10G  0 part /
├─sda4                                                                                                  8:4    0   100G  0 part /home
├─sda5                                                                                                  8:5    0    16G  0 part [SWAP]
├─sda6                                                                                                  8:6    0    14G  0 part /tmp
├─sda7                                                                                                  8:7    0    10G  0 part /usr
└─sda8                                                                                                  8:8    0 964.4G  0 part /var
sdb                                                                                                     8:16   0   9.1T  0 disk
sdc                                                                                                     8:32   0   9.1T  0 disk
└─ceph--27a4b227--1005--4e0f--a947--412897e8c8b2-osd--block--58e2bc2c--dc21--4983--b1f3--3f7050941cbb 253:12   0   9.1T  0 lvm
sdd                                                                                                     8:48   0   9.1T  0 disk
└─ceph--9a6412f2--48ff--4966--8138--3eda754c3b50-osd--block--9ca1e1a3--0639--4451--8dfe--6dd382660b75 253:7    0   9.1T  0 lvm
sde                                                                                                     8:64   0   9.1T  0 disk
sdf                                                                                                     8:80   0   9.1T  0 disk
sdg                                                                                                     8:96   0   9.1T  0 disk
sdh                                                                                                     8:112  0   9.1T  0 disk
sdi                                                                                                     8:128  0   9.1T  0 disk
sdj                                                                                                     8:144  0   9.1T  0 disk
...
sdw                                                                                                    65:96   0   9.1T  0 disk
sdx                                                                                                    65:112  0   9.1T  0 disk
sdy                                                                                                    65:128  0   9.1T  0 disk
└─ceph--dbb2bbaa--1a2c--4452--bf38--afb0e565a99c-osd--block--fac47bc4--8955--4674--8c28--28de836d2cc5 253:1    0   9.1T  0 lvm

错落无致地显示，有很多osd盘光秃秃的，没有lvm…，更惨的是，有接近30台机器的盘全部变成了初始状态，没有任何lvm信息，其他机器则像上述机器一样，有的盘有lvm有的盘没有

这太可怕了！！

调查

查了一圈，没有任何报错，dmesg没有，message也没有，osd日志也没有，这就尴尬了-.-

网上查了一圈，说要重新命令扫描一下，手工激活，可是不管运行什么pvscan、vgscan，抛出的都是一样的信息

WARNING: Failed to connect to lvmetad. Falling back to device scanning

看来可能是这个进程搞的鬼，这个进程是什么呢

lvmetad is a metadata caching daemon for LVM. The daemon receives notifications from udev rules (which must be installed for LVM to work correctly when lvmetad is in use). Through these notifications, lvmetad has an up-to-date and consistent image of the volume groups available in the system.

原来是lvm的元数据管理器，手工起起来再看看

systemctl start lvm2-lvmetad.service

进程起起来了，然而并没有啥用，啥事也没有发生，osd的lvm没有回来，完了完了。。。

观察到一个现象，所有lvm都丢失的机器，重启起来后，这个lvm2-lvmetad.service都是dead状态的，而丢一部分不丢一部分lvm的机器，这个服务是running的，那是不是这个进程要在系统启动的时候就要跑上，否则就会有问题呢？

尝试一下，enable然后重启机器

systemctl enable lvm2-lvmetad.service

然而还是没有效果，它还是dead的，是不是其他服务拉它的呢？

[store@osd72 ~]$ systemctl cat lvm2-lvmetad.service
# /usr/lib/systemd/system/lvm2-lvmetad.service
[Unit]
Description=LVM2 metadata daemon
Documentation=man:lvmetad(8)
Requires=lvm2-lvmetad.socket
After=lvm2-lvmetad.socket
DefaultDependencies=no
Conflicts=shutdown.target

[Service]
Type=simple
NonBlocking=true
ExecStart=/usr/sbin/lvmetad -f
Environment=SD_ACTIVATION=1
Restart=on-abort
PIDFile=/run/lvmetad.pid

应该就是lvm2-lvmetad.socket了，看了一眼，它自己也没有起来，也没有enable，于是再systemctl enable lvm2-lvmetad.socket，重启机器，嗯！好了！lvm2-lvmetad.socket和lvm2-lvmetad.service都起来了，只是lvm仍然没有回来

猜想

会不会是当初建osd的时候，这个lvm2-lvmetad.service没有正常运行，建立lvm的时候，操作实际上没有落盘(这有点不科学，不过也只能这么猜测了)，导致重启后丢失了这些内容？它管理的是元数据，如果元数据出问题了，很有可能就会导致这个现象

查了一下建osd时候的日志，果然，如果lvm2-lvmetad.service没有正常运行，就会一直报上面那个WARNING

实践

在enable了lvm2-lvmetad并正常运行的情况下，重新对整个集群的osd做了重建，并且做了性能测试，然后进行重启验证。多次重启后，lvm信息均没有丢失，集群正常，认为问题解决

总结

第一次遇到这种重启导致lvm信息丢失的问题，后来经过排查，是集群在建设过程中的某个步骤，将默认的所有服务都disable了，然后对只必须的服务做重新的enable，但是这个集群不知道怎么回事(因为其他集群也是这样操作，没有重新enable lvm2-lvmetad服务，但一直未有问题)，lvm2-lvmetad不在运行时建立osd就会导致lvm丢失，真是个有价值的坑！这要上了线才发现，这锅得多大！！所以，在测试阶段，一定要进行多次重启测试

喜欢ceph的话欢迎关注奋斗的cepher微信公众号阅读更多好文！