MFS(二)---mfs使用数据恢复 StorageClass详解

绝地灬酷狼 2023-02-20 12:15 21阅读 0赞

# 一、数据恢复 #

在mfs分布式文件系统删除文件后，系统并不会在磁盘上将文件删除，而是有一个回收时间，回收时间可以使用以下命令在客户端的mfs目录查看：

[root@foundation1 data1]# mfsgettrashtime .
    .: 86400

以上结果表示回收时间为86400秒即24小时，当删除文件24小时后才会真正的进行删除。

测试删除文件：

[root@foundation1 mfs]# cd data1/
    [root@foundation1 data1]# ls
    bigfile  passwd
    [root@foundation1 data1]# rm -f passwd

在这24小时内想要恢复数据的话需要将元数据（metadata）挂载：

[root@foundation1 mnt]# mkdir mfsmeta		#建立元数据挂载目录
    [root@foundation1 mfsmeta]# cd
    [root@foundation1 ~]# mfsmount -m /mnt/mfsmeta/
    mfsmaster accepted connection with parameters: read-write,restricted_ip
    [root@foundation1 ~]# cd /mnt/mfsmeta/
    [root@foundation1 mfsmeta]# ls
    sustained  trash

挂载后查看元数据目录下的`trash`目录，共有4097个子目录，可以查找删除的文件：

[root@foundation1 trash]# find -name *passwd*
    ./004/00000004|data1|passwd
    [root@foundation1 trash]# cd 004/
    [root@foundation1 004]# ls
    00000004|data1|passwd  undel

恢复数据需要将删除的文件移动到`undel`目录中：

[root@foundation1 004]# mv 00000004\|data1\|passwd undel/

这时数据已经恢复：

[root@foundation1 ~]# cd /mnt/mfs/data1/
    [root@foundation1 data1]# ls
    bigfile  passwd
    [root@foundation1 data1]# cat passwd 
    root:x:0:0:root:/root:/bin/bash
    ......

# 二、 StorageClass详解 #

## 1 什么是storage class ##

在moosefs中，storage class允许指定文件的chunks存放在哪些chunkservers上。

storage class使用label进行表达。

为了与早期的版本的goal功能兼容，**moosefs 3.0以上会自动在系统中建立1～9 storage class**。goal工具将默认在对应的storage class下进行工作。

[root@foundation1 mfs]# mfsscadmin list
    1
    2
    3
    4
    5
    6
    7
    8
    9

在网页端查看：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70]

## 2 什么是label ##

`label`是可以被分配给`chunkserver`的字母（`a~z`，26个字母可选），每个`chunkserver`可以被打上多个标签（即标记上多个字母，但最多可以打26个label）

完整的label表达式可以由多个子表达式构成，每个子标签之间用逗号分隔。每个子表达式特指文件副本的一种存储模式。子表达式可以为星号`＊`或一个`label schema`。

`label schema`可以是一个label或由加法、乘法和括号构成的复杂表达式。

**加法是逻辑“或”的含义**，即文件的副本可以被存放在任意含有加法元素label的chunkserver上。例如，一个文件的storage class是a+b+c，那么任何含有a、b或c标签的chunkserver都可以用来存储该文件的副本。

**乘法是逻辑“与”的含义**，即文件的副本仅可以存放在包含所有label的chunkserver上。例如，一个文件的storage class是abc，那么只有当一台chunkserver同时含有abc三个标签时，它才能用于存放该文件的副本。

相同的子表达式可以通过在表达式前加数字的方式来表示，而不用重复显示声明多次。

**标签表达式示例：**

*  `A,B` –文件将有两个副本，一个副本将存储在带有标签A的chunkserver上，另一个位于chunkserver上，标签为B
 *  `A,*` –文件将有两个副本，一个副本将存储在带有标签A的chunkserver上，任何chunkserver上的另一个
 *  `*,*`–文件将有两个副本，存储在任何chunkserver上（每个副本存储的chunkserver不同）
 *  `AB,C+D`–文件将有两个副本，一个副本将存储在具有标签A和B（标签的乘法）的chunkserver上，另一个副本将存储在具有标签A或B（标签的乘法）d的chunkserver上
 *  `A,B[X+Y],C[X+Y]`–文件将有三个副本，一个副本将存储在任何具有标签A的chunkserver上，第二个副本将存储在任何具有B标签和X或Y标签的chunkserver上，第三个将存储在任何具有C标签和X或Y标签的chunkserver上
 *  `A,A`表达式等于`2A`表达式
 *  `A,BC,BC,BC`表达式等同于`A,3BC`表达式
 *  `*,*`表达式等于`2*`表达式等于`2`表达式

## 3 存储类示例1 ##

再添加两个chunkserver（server4和server5），配置方法与server2相同,下面以server4的配置为例：

[root@server4 ~]# yum install -y moosefs-chunkserver
    [root@server4 ~]# vim /etc/hosts
    172.25.1.1 server1 mfsmaster			#添加master的解析
    [root@server4 ~]# mkdir /mnt/chunk3
    [root@server4 ~]# chown mfs.mfs /mnt/chunk3
    [root@server4 ~]# vim /etc/mfs/mfshdd.cfg
    [root@server4 ~]# tail -1 /etc/mfs/mfshdd.cfg
    /mnt/chunk3
    [root@server4 ~]# systemctl start moosefs-chunkserver

配置好server4和server5并启动后查看网页端：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 1]  
可以看出添加成功，接下来进行实验。

假设server2和server3在A机房，server4和server5在B机房，我们只想要往A机房的主机存储数据，此时就需要用到StorageClass，StorageClass通过label来进行选择，首先为主机添加标签（label）：

[root@server2 ~]# cd /etc/mfs/
    [root@server2 mfs]# vim mfschunkserver.cfg
    [root@server2 mfs]# cat -n mfschunkserver.cfg | grep 84
        84	LABELS = A
    [root@server2 mfs]# systemctl reload moosefs-chunkserver.service

![在这里插入图片描述][20200626204912502.png]其他三台主机的操作相同，只是设置的标签不同，设置完标签后用网页端查看：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 2]2和3设置的标签为A，4和5设置的标签为B。

在客户端创建StorageClass：

[root@foundation1 mfs]# mfsscadmin create 2A class2A
    storage class make class2A: ok			
    
    # 2A为标签表达式，class2A为名称
    
    [root@foundation1 mfs]# mfsscadmin list
    1
    2
    3
    4
    5
    6
    7
    8
    9
    class2A

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 3]  
在mfs目录下有文件`data2/fstab` 有两个副本：

[root@foundation1 mfs]# cd data2/
    [root@foundation1 data2]# mfsfileinfo fstab 
    fstab:
    	chunk 0: 0000000000000002_00000001 / (id:2 ver:1)
    		copy 1: 172.25.1.4:9422 (status:VALID)
    		copy 2: 172.25.1.5:9422 (status:VALID)

可以看出现在两个副本均在机房B（server4和server5）的主机上，将其`storageclass`更改为`2A`：

[root@foundation1 data2]# mfssetsclass -r class2A .
    .:
     inodes with storage class changed:              2
     inodes with storage class not changed:          0
     inodes with permission denied:                  0

此时副本所在位置并不会立即更新，我们可以在文件中写入内容触发更新：

[root@foundation1 data2]# echo 132 >> fstab 
    [root@foundation1 data2]# mfsfileinfo fstab 
    fstab:
    	chunk 0: 0000000000000002_00000001 / (id:2 ver:1)
    		copy 1: 172.25.1.2:9422 (status:VALID)
    		copy 2: 172.25.1.3:9422 (status:VALID)

可以看出更新后副本就被存储到了具有标签A的主机上了。

创建一个大文件测试：

[root@foundation1 data2]# dd if=/dev/zero of=bigfile bs=1M count=100
    100+0 records in
    100+0 records out
    104857600 bytes (105 MB) copied, 8.89989 s, 11.8 MB/s
    [root@foundation1 data2]# mfsfileinfo bigfile 
    bigfile:
    	chunk 0: 0000000000000005_00000001 / (id:5 ver:1)
    		copy 1: 172.25.1.2:9422 (status:VALID)
    		copy 2: 172.25.1.3:9422 (status:VALID)
    	chunk 1: 0000000000000006_00000001 / (id:6 ver:1)
    		copy 1: 172.25.1.2:9422 (status:VALID)
    		copy 2: 172.25.1.3:9422 (status:VALID)

由于文件大于64M，因此会被切分成两个`chunk`来进行存储，每个chunk又有两个副本，此时若将server2宕机，文件依然能正常读取。

## 4 存储类示例2 ##

有些时候存储的媒介也会有区别，比如HDD和SSD，因此我们也可以设置数据仅存储在SSD上或仅存储在HHD上。

比如server2和server4为SSD存储，而server3和server5为HDD存储，我们需要为每个主机添加标签，下面以server2为例：

[root@server2 mfs]# vim mfschunkserver.cfg
    [root@server2 mfs]# cat -n mfschunkserver.cfg | grep 84
        84	LABELS = A,S
    [root@server2 mfs]# systemctl reload moosefs-chunkserver.service

每个主机的标签添加完成后在网页端查看：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 4]  
创建`storageclass`：

[root@foundation1 mfs]# mfsscadmin create 2S class2S
    storage class make class2S: ok

修改`data2/`的`storageclass`(从class2A修改为class2S)：

[root@foundation1 mfs]# mfsxchgsclass -r class2A class2S data2
    data2:
     inodes with storage class changed:              3
     inodes with storage class not changed:          0
     inodes with permission denied:                  0

查看文件信息：

[root@foundation1 mfs]# cd data2
    [root@foundation1 data2]# mfsfileinfo fstab 
    fstab:
    	chunk 0: 0000000000000002_00000001 / (id:2 ver:1)
    		copy 1: 172.25.1.2:9422 (status:VALID)
    		copy 2: 172.25.1.4:9422 (status:VALID)

若没有更新可以手动触发更新，从结果可以看出由于设置的`storageclass`为2S，因此2个副本被保存在具有标签`S`的主机上了。

修改`data2/`的`storageclass`(从class2S修改为class2H)：

[root@foundation1 mfs]# mfsscadmin create 2H class2H
    storage class make class2H: ok
    [root@foundation1 mfs]# mfsxchgsclass -r class2S class2H data2
    data2:
     inodes with storage class changed:              3
     inodes with storage class not changed:          0
     inodes with permission denied:                  0
    [root@foundation1 mfs]# 
    [root@foundation1 mfs]# cd data2/
    [root@foundation1 data2]# echo 4654 >> fstab 
    [root@foundation1 data2]# mfsfileinfo fstab 
    fstab:
    	chunk 0: 0000000000000002_00000002 / (id:2 ver:2)
    		copy 1: 172.25.1.3:9422 (status:VALID)
    		copy 2: 172.25.1.5:9422 (status:VALID)

从结果可以看出，当`storageclass`发生变化时，副本的存储位置也会发生变化。

## 5 存储类示例3 ##

各chunkserver的标签如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 5]

创建`storageclass`：

[root@foundation1 mfs]# mfsscadmin create AS,BS classASBS
    storage class make classASBS: ok

以上的`storageclass`表示数据有两个副本，第一个副本存储在有标签A和S的chunkserver上，第二个副本存储在有标签B和S的chunkserver上。

设置目录的`storageclass`：

[root@foundation1 mfs]# mkdir data3 
    [root@foundation1 mfs]# mfssetsclass classASBS data3
    data3: storage class: 'classASBS'

放入测试文件：

[root@foundation1 data3]# cp /etc/passwd .
    [root@foundation1 data3]# ls
    passwd
    [root@foundation1 data3]# mfsfileinfo passwd 
    passwd:
    	chunk 0: 0000000000000007_00000001 / (id:7 ver:1)
    		copy 1: 172.25.1.2:9422 (status:VALID)
    		copy 2: 172.25.1.4:9422 (status:VALID)

可以看出副本一存储在server2（标签AS）上，副本二存储在server4（标签BS）上。

## 自动打包和移动数据 ##

假设您要快速写入大量重要数据，并且您的计算机更靠近服务器机房A。因此，您想要在服务器机房A的SSD块服务器上以两份副本（`-C 2AS`）存储。但是您的目标是在服务器机房A中拥有此数据的一个副本，而在服务器机房B中具有另一个副本，这两个副本均在SSD服务器上。 MooseFS将负责复制过程（`-K AS,BS`）。最后，在30天后，您希望MooseFS将此数据移动到服务器机房A和B（`-A AH,BH -d 30`）中的HDD块服务器中。

**即存储时存储在SSD服务器上，过一段时间（30天）后再自动打包并移动到HHD服务器上。**

设置主机的标签如下：  
![在这里插入图片描述][2020062621250178.png]

首先，创建一个目录并设置存储类：

[root@foundation1 mfs]# mkdir data4
    [root@foundation1 mfs]# mfsscadmin create -C 2AS -K AS,BS -A AH,BH -d 7 classauto
    storage class make classauto: ok

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 6]  
以上命令中`-C 2AS`表示初始存储到有`2AS`标签（2表示2个副本）的服务器上，`-K AS,BS`表示最终存储到有`AS,BS`标签的服务器上，`-A AH,BH`表示打包移动时移动到有`AH,BH`标签的服务器上,`-d 7`表示7天后进行移动，`classauto`为存储类名称。

数据将是安全的，并且在创建时（非常靠近此服务器机房）非常快速地存储在服务器机房A中的SSD块服务器上，也由MooseFS复制到服务器机房B中，并在7天后自动移动到HDD块服务器中。

创建测试文件：

[root@foundation1 mfs]# cd data4/
    [root@foundation1 data4]# dd if=/dev/zero of=bigfile bs=1M count=100
    100+0 records in
    100+0 records out
    104857600 bytes (105 MB) copied, 16.0903 s, 6.5 MB/s
    [root@foundation1 data4]# mfsfileinfo bigfile 
    bigfile:
    	chunk 0: 0000000000000008_00000001 / (id:8 ver:1)
    		copy 1: 172.25.1.3:9422 (status:VALID)
    		copy 2: 172.25.1.4:9422 (status:VALID)
    	chunk 1: 0000000000000009_00000001 / (id:9 ver:1)
    		copy 1: 172.25.1.3:9422 (status:VALID)
    		copy 2: 172.25.1.4:9422 (status:VALID)

可以看出初始存储时存储在有标签AS的主机(server3和server4)上。

# 三、overcommit\_memory 内核参数 #

1.  overcommit\_memory是什么？
    
    overcommit\_memory是一个内核对内存分配的一种策略。 具体可见`/proc/sys/vm/overcommit_memory`下的值
2.  overcommit\_memory有什么作用？
    
    overcommit\_memory取值又三种分别为0， 1， 2

*  overcommit\_memory=0，表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。
 *  overcommit\_memory=1， 表示内核允许分配所有的物理内存，而不管当前的内存状态如何。
 *  overcommit\_memory=2， 表示内核允许分配超过所有物理内存和交换空间总和的内存

## MFS管理服务器master的恢复 ##

如果master进程被`kill`，再启动时就不能启动：

[root@server1 mfs]# ps -ax | tail -10
     8269 ?        Ss     0:00 sshd: root@pts/0
    11489 pts/0    Ss     0:00 -bash
    13111 ?        S      0:00 pickup -l -t unix -u
    13113 ?        S      0:00 [kworker/0:1]
    13116 ?        S      0:00 [kworker/0:2]
    13130 ?        S      0:00 [kworker/0:0]
    13164 ?        S<     0:00 /usr/sbin/mfsmaster start
    13165 ?        S<     0:00 mfsmaster (data writer)
    13167 pts/0    R+     0:00 ps -ax
    13168 pts/0    R+     0:00 tail -10
    [root@server1 mfs]# kill -9 13164
    [root@server1 mfs]# systemctl start moosefs-master.service 
    Job for moosefs-master.service failed because the control process exited with error code. See "systemctl status moosefs-master.service" and "journalctl -xe" for details.

此时需要最后一个元数据改变日志changelog和主要的元数据文件`metadata.mfs`。这个操作可以通过mfsmaster(在1.7版本以前用mfsmetarestore)命令来完成。命令如下所示：

[root@server1 mfs]# mfsmaster -a  #执行这个命令的时候，确保mfsmaster进程处于停止状态。

执行后即可正常使用。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200626203810319.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200626204338789.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2,size_16,color_FFFFFF,t_70
[20200626204912502.png]: https://img-blog.csdnimg.cn/20200626204912502.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200626205818301.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20200626210114958.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20200626211456217.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20200626212932408.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2,size_16,color_FFFFFF,t_70
[2020062621250178.png]: https://img-blog.csdnimg.cn/2020062621250178.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 6]: https://img-blog.csdnimg.cn/20200626214908225.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2,size_16,color_FFFFFF,t_70