概述
此次演练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 bigfs192.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 -ltotal 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/data1lmm_magic: 0x0BD10BD0lmm_seq: 0x200000401lmm_object_id: 0x1lmm_fid: [0x200000401:0x1:0x0]lmm_stripe_count: 1lmm_stripe_size: 1048576lmm_pattern: raid0lmm_layout_gen: 0lmm_stripe_offset: 2 obdidx objid objid group 2 2 0x2 0/mnt/bigfs/data2lmm_magic: 0x0BD10BD0lmm_seq: 0x200000401lmm_object_id: 0x2lmm_fid: [0x200000401:0x2:0x0]lmm_stripe_count: 1lmm_stripe_size: 1048576lmm_pattern: raid0lmm_layout_gen: 0lmm_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 -1htotal 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 -lls: cannot access "data2": No such file or directoryls: cannot access "data1": No such file or directorytotal 0-????????? ? ? ? ? ? data1-????????? ? ? ? ? ? data2[root@Lustre-Client /mnt/bigfs]$ cat data1cat: data1: No such file or directory[root@Lustre-Client /mnt/bigfs]$ cat data2cat: 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 -ltotal 0// MDS端删除ROOT下目录后，对应的OST上的数据也会被清除，OST1上已经找不到data1这个文件的数据了[root@Lustre-OST1 ~]$ cd /mnt/ost1/O/0[root@Lustre-OST1 /mnt/ost1/O/0]$ lsd0 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 -1htotal 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.txtlmm_magic: 0x0BD10BD0lmm_seq: 0x200000403lmm_object_id: 0x2lmm_fid: [0x200000403:0x2:0x0]lmm_stripe_count: 1lmm_stripe_size: 1048576lmm_pattern: raid0lmm_layout_gen: 0lmm_stripe_offset: 2 obdidx objid objid group 2 4 0x4 0.//demo1.txtlmm_magic: 0x0BD10BD0lmm_seq: 0x200000403lmm_object_id: 0x1lmm_fid: [0x200000403:0x1:0x0]lmm_stripe_count: 1lmm_stripe_size: 1048576lmm_pattern: raid0lmm_layout_gen: 0lmm_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]$ ls4[root@Lustre-OST2 /mnt/ost2/O/0/d4]$ cat 4#version=RHEL8# Use graphical installgraphical/*********忽略剩余内容显示*****/// 删除这个文件对象，但是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 fileDevice: a51ef1a0h/2770268576d Inode: 144115205306056706 Links: 1Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root)Context: unconfined_u:object_r:unlabeled_t:s0Access: 2023-02-06 18:31:41.000000000 -0500Modify: 2023-02-06 18:24:07.000000000 -0500Change: 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 catroot 2041 1746 0 18:31 pts/1 00:00:00 cat demo2.txtroot 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 catroot 2041 1746 0 18:31 pts/1 00:00:00 cat demo2.txtroot 2067 1476 0 18:35 pts/0 00:00:00 grep --color=auto cat思考
如果MDS对应的后端存储已经把inode占满导致MDS不可用，如何进行恢复?如果OST上的文件的数据分片所消耗的inode资源超过系统最大限制，导致OST不可用如何进行恢复? 
