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

一、数据恢复

在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

在网页端查看：

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并启动后查看网页端：

可以看出添加成功，接下来进行实验。

假设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 

其他三台主机的操作相同，只是设置的标签不同，设置完标签后用网页端查看：
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

在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 

每个主机的标签添加完成后在网页端查看：

创建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的标签如下：

创建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服务器上。

设置主机的标签如下：

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

[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

以上命令中-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进程处于停止状态。

执行后即可正常使用。