误删Lustre后端文件系统数据的影响
概述
- 此次演练Lustre文件系统中
ldiskfs-osd后端存储上的对象被删除后,Lustre文件系统的表现。核心演练两个场景，一个是MDS中的ldiskfs中的ROOT中文件被删除；另外一个是OST中的文件对象被删除。 Lustre MDS通过mount -t ldiskfs /dev/sdb /mnt/mdt挂载后端存储后，此次我们关注ROOT目录,ROOT目录是所有Lustre文件系统客户端看到的统一的posix的视图,在这个目录里操作对应的Lustre内部对象Lustre OST通过类似的方法挂载后端存储，这里我们关注O/0目录，这个目录存储了Lustre文件系统的数据的分片，我们会找到写入文件的分片位置，来操作O/0下面的分片数据。
Lustre环境
节点 | IP地址 | 磁盘 | Lustre 版本 |
|---|---|---|---|
Lustre-MGS-MDS | 192.168.28.129 | sdb | 2.15.2 |
Lustre-OST1 | 192.168.28.50 | sdb | 2.15.2 |
Lustre-OST2 | 192.168.28.34 | sdb | 2.15.2 |
Lustre-Client | 192.168.28.189 | sdb | 2.15.2 |
场景模拟
数据准备
// 查看挂载点
[root@Lustre-Client ~]$ df -h |grep bigfs
192.168.28.129@tcp:/bigfs 251G 2.5M 238G 1% /mnt/bigfs
// 创建data1、data2文件
[root@Lustre-Client ~]$ cp anaconda-ks.cfg /mnt/bigfs/data1
[root@Lustre-Client ~]$ cp anaconda-ks.cfg /mnt/bigfs/data2
[root@Lustre-Client /mnt/bigfs]$ ls -l
total 8
-rw-------. 1 root root 1094 Feb 6 17:53 data1
-rw-------. 1 root root 1094 Feb 6 17:53 data2
// 获取布局信息，lustre默认的选择OST的策略是RR模式，会轮训选择OST进行数据写入
// 文件的位于 ost index={obdidx},O/{group}/d{{objid}%32}/{obdidx}文件
[root@Lustre-Client ~]$ lfs getstripe -v /mnt/bigfs/*
/mnt/bigfs/data1
lmm_magic: 0x0BD10BD0
lmm_seq: 0x200000401
lmm_object_id: 0x1
lmm_fid: [0x200000401:0x1:0x0]
lmm_stripe_count: 1
lmm_stripe_size: 1048576
lmm_pattern: raid0
lmm_layout_gen: 0
lmm_stripe_offset: 2
obdidx objid objid group
2 2 0x2 0
/mnt/bigfs/data2
lmm_magic: 0x0BD10BD0
lmm_seq: 0x200000401
lmm_object_id: 0x2
lmm_fid: [0x200000401:0x2:0x0]
lmm_stripe_count: 1
lmm_stripe_size: 1048576
lmm_pattern: raid0
lmm_layout_gen: 0
lmm_stripe_offset: 1
obdidx objid objid group
1 2 0x2 0
删除MDS下ROOT目录文件
Lustre客户端数据数据初始化后，可以在MDS后端文件系统挂载后查看ROOT目录，这个目录中文件名称对应的是客户端每个写入文件的文件名称，大小都是0;对于目录大小为4k.在MDS端删除ROOT下面对象后，Lustre客户端是找不到这个文件，也就是这个文件对应的元数据信息在MDS端丢失，但是这些文件对应的OST上的数据分片也会被清理掉删除MDS端ROOT中的目录
// 数据初始化后，ROOT目录里的数据和客户端看到的保持一致
[root@Lustre-MGS-MDS ~]$ df -h |grep mnt
/dev/sdb 73G 5.6M 67G 1% /mnt/mdt
[root@Lustre-MGS-MDS ~]$ cd /mnt/mdt/ROOT/
[root@Lustre-MGS-MDS /mnt/mdt/ROOT]$ ls -l -1h
total 0
-rw-------. 1 root root 0 Feb 6 17:53 data1
-rw-------. 1 root root 0 Feb 6 17:53 data2
// 删除ROOT下所有的文件,MDS端未做sync
[root@Lustre-MGS-MDS ~]$ rm -rf /mnt/mdt/ROOT/*
[root@Lustre-MGS-MDS ~]$ ls -l /mnt/mdt/ROOT/
total 0
// 客户端缓存依旧可以看到
[root@Lustre-Client ~]$ ls -l /mnt/bigfs/
total 8
-rw-------. 1 root root 1094 Feb 6 17:53 data1
-rw-------. 1 root root 1094 Feb 6 17:53 data2
// mds端执行sync操作
[root@Lustre-MGS-MDS ~]$ cd /mnt/mdt/ROOT/
[root@Lustre-MGS-MDS /mnt/mdt/ROOT]$ sync
// mds端sync后，客户端显示data1和data2不存在;但是仅仅是这2个文件受影响。
[root@Lustre-Client /mnt/bigfs]$ ls -l
ls: cannot access 'data2': No such file or directory
ls: cannot access 'data1': No such file or directory
total 0
-????????? ? ? ? ? ? data1
-????????? ? ? ? ? ? data2
[root@Lustre-Client /mnt/bigfs]$ cat data1
cat: data1: No such file or directory
[root@Lustre-Client /mnt/bigfs]$ cat data2
cat: data2: No such file or directory
// 客户端重新挂载后，MDS的ROOT目录中删除的对象已经在客户端消失
[root@Lustre-Client ~]$ umount /mnt/bigfs
[root@Lustre-Client ~]$ mount -t lustre Lustre-MGS-MDS@tcp0:/bigfs /mnt/bigfs
[root@Lustre-Client ~]$ cd /mnt/bigfs/
[root@Lustre-Client /mnt/bigfs]$ ls -l
total 0
// MDS端删除ROOT下目录后，对应的OST上的数据也会被清除，OST1上已经找不到data1这个文件的数据了
[root@Lustre-OST1 ~]$ cd /mnt/ost1/O/0
[root@Lustre-OST1 /mnt/ost1/O/0]$ ls
d0 d1 d10 d11 d12 d13 d14 d15 d16 d17 d18 d19 d2 d20 d21 d22 d23 d24 d25 d26 d27 d28 d29 d3 d30 d31 d4 d5 d6 d7 d8 d9 LAST_ID
[root@Lustre-OST1 /mnt/ost1/O/0]$ cd d2
[root@Lustre-OST1 /mnt/ost1/O/0/d2]$ ls
[root@Lustre-OST1 /mnt/ost1/O/0/d2]$ ls -l
total 0
// OST2上已经也找不到data2这个文件数据了
[root@Lustre-OST2 ~]$ cd /mnt/ost2/O/0
[root@Lustre-OST2 /mnt/ost2/O/0]$ cd d2
[root@Lustre-OST2 /mnt/ost2/O/0/d2]$ ls
[root@Lustre-OST2 /mnt/ost2/O/0/d2]$ ls -l -1h
total 0
[root@Lustre-OST2 /mnt/ost2/O/0/d2]$删除OST下O/0数据分片
OST上的文件对应的数据分片删除后，Lustre客户端访问这些文件的元数据都不存在任何的问题，但是访问OST上的实际数据就会进程卡主的问题但是不会影响到整个文件系统的使用，针对这种情况就需要定期备份磁盘或者基于Lustre Changelog写个客户端的服务消费数据变化来备份数据。
// 客户端写入两个文件demo1和demo2
[root@Lustre-Client ~]$ cp anaconda-ks.cfg /mnt/bigfs/demo1.txt
[root@Lustre-Client ~]$ cp anaconda-ks.cfg /mnt/bigfs/demo2.txt
[root@Lustre-Client ~]$ cd /mnt/bigfs/
// 发起sync命令同步元数据和数据到mds和ost
[root@Lustre-Client /mnt/bigfs]$ sync
// 查看demo1和demo2的布局
[root@Lustre-Client /mnt/bigfs]$ lfs getstripe -v ./
(Default) ./
lmm_fid: [0x200000007:0x1:0x0]
stripe_count: 1 stripe_size: 1048576 pattern: 0 stripe_offset: -1
.//demo2.txt
lmm_magic: 0x0BD10BD0
lmm_seq: 0x200000403
lmm_object_id: 0x2
lmm_fid: [0x200000403:0x2:0x0]
lmm_stripe_count: 1
lmm_stripe_size: 1048576
lmm_pattern: raid0
lmm_layout_gen: 0
lmm_stripe_offset: 2
obdidx objid objid group
2 4 0x4 0
.//demo1.txt
lmm_magic: 0x0BD10BD0
lmm_seq: 0x200000403
lmm_object_id: 0x1
lmm_fid: [0x200000403:0x1:0x0]
lmm_stripe_count: 1
lmm_stripe_size: 1048576
lmm_pattern: raid0
lmm_layout_gen: 0
lmm_stripe_offset: 1
obdidx objid objid group
1 3 0x3 0
// 查看ost2上的demo2.txt数据
[root@Lustre-OST2 ~]$ cd /mnt/ost2/O/0/d4
[root@Lustre-OST2 /mnt/ost2/O/0/d4]$ ls
4
[root@Lustre-OST2 /mnt/ost2/O/0/d4]$ cat 4
#version=RHEL8
# Use graphical install
graphical
/*********忽略剩余内容显示*****/
// 删除这个文件对象，但是MDS端的依旧存在
[root@Lustre-OST2 /mnt/ost2/O/0/d4]$ rm -rf 4
[root@Lustre-OST2 /mnt/ost2/O/0/d4]$ sync
// 客户端清除pagecache
[root@Lustre-Client /mnt/bigfs]$ echo 1 > /proc/sys/vm/drop_caches
[root@Lustre-Client /mnt/bigfs]$ sync
// 查看demo2.txt的元数据依旧就可以正常访问
[root@Lustre-Client /mnt/bigfs]$ stat demo2.txt
File: demo2.txt
Size: 1094 Blocks: 8 IO Block: 4194304 regular file
Device: a51ef1a0h/2770268576d Inode: 144115205306056706 Links: 1
Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root)
Context: unconfined_u:object_r:unlabeled_t:s0
Access: 2023-02-06 18:31:41.000000000 -0500
Modify: 2023-02-06 18:24:07.000000000 -0500
Change: 2023-02-06 18:24:07.000000000 -0500
Birth: 2023-02-06 18:24:07.000000000 -0500
[root@Lustre-Client /mnt/bigfs]$ ls -l demo2.txt
-rw-------. 1 root root 1094 Feb 6 18:24 demo2.txt
// 访问demo2.txt直接卡主
[root@Lustre-Client /mnt/bigfs]$ cat demo2.txt
^C
// 查看进程后通过kill是无法停止，这个卡主仅仅是影响单个文件的数据读取，并不影响整个客户端的情况
[root@Lustre-Client /mnt/bigfs]$ ps -ef|grep cat
root 2041 1746 0 18:31 pts/1 00:00:00 cat demo2.txt
root 2065 1476 0 18:35 pts/0 00:00:00 grep --color=auto cat
[root@Lustre-Client /mnt/bigfs]$ kill -9 2041
[root@Lustre-Client /mnt/bigfs]$ ps -ef|grep cat
root 2041 1746 0 18:31 pts/1 00:00:00 cat demo2.txt
root 2067 1476 0 18:35 pts/0 00:00:00 grep --color=auto cat思考
- 如果
MDS对应的后端存储已经把inode占满导致MDS不可用，如何进行恢复? - 如果
OST上的文件的数据分片所消耗的inode资源超过系统最大限制，导致OST不可用如何进行恢复?
本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。
原始发表：2023-02-07，如有侵权请联系 cloudcommunity@tencent.com 删除
评论
登录后参与评论
推荐阅读
目录
相关产品与服务
对象存储
对象存储（Cloud Object Storage，COS）是由腾讯云推出的无目录层次结构、无数据格式限制，可容纳海量数据且支持 HTTP/HTTPS 协议访问的分布式存储服务。腾讯云 COS 的存储桶空间无容量上限，无需分区管理，适用于 CDN 数据分发、数据万象处理或大数据计算与分析的数据湖等多种场景。
腾讯云开发者
