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

在网页端查看:
MFS(二)---mfs使用 数据恢复 StorageClass详解_第1张图片

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并启动后查看网页端:
MFS(二)---mfs使用 数据恢复 StorageClass详解_第2张图片
可以看出添加成功,接下来进行实验。

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

在这里插入图片描述其他三台主机的操作相同,只是设置的标签不同,设置完标签后用网页端查看:
MFS(二)---mfs使用 数据恢复 StorageClass详解_第3张图片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(二)---mfs使用 数据恢复 StorageClass详解_第4张图片
在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 

每个主机的标签添加完成后在网页端查看:
MFS(二)---mfs使用 数据恢复 StorageClass详解_第5张图片
创建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的标签如下:
MFS(二)---mfs使用 数据恢复 StorageClass详解_第6张图片

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

设置主机的标签如下:
MFS(二)---mfs使用 数据恢复 StorageClass详解_第7张图片

首先,创建一个目录并设置存储类:

[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

MFS(二)---mfs使用 数据恢复 StorageClass详解_第8张图片
以上命令中-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进程处于停止状态。

执行后即可正常使用。

你可能感兴趣的:(企业实战)