MFS分布式文件系统实战（2）——搭建基本的MFS系统（client端+master端+chunk端）

1.搭建实验环境

主机信息	主机功能
server1（172.25.2.1）	mfs master节点
server2（172.25.2.2）	mfs chunk节点
server3（172.25.2.3）	mfs chunk节点
真机（172.25.2.250）	mfs client客户端

（1）在真机中创建三个全新的快照并且开启，用来做此次实验

（2）用真机连接三台虚拟机



到此为止基本的实验环境已经搭建完毕

2.搭建基本的MFS系统

（1）给server1安装mfs master以及mfs cgi



（2）在server1上做解析


（3）查看mfs master节点的配置文件并且开启服务

（4）查看server1上开启的端口

mfs master开启了三个端口:9419,9420,9421

metalogger监听的端口地址	（默认是9419）
用于chunkserver连接的端口地址	（默认是9420）
用于客户端挂接连接的端口地址	（默认是4921）

（5）在server1上开启mfs cgi
开启了端口9425，这个是监控各个分布节点的端口

（6）在浏览器访问172.25.2.1：9425，可以看到分布式文件系统的监控页面
想监控哪一项信息，就选择哪个加号


ls -i显示文件的inode信息
索引节点（index inode简称为“inode”）是Linux中一个特殊的概念，
具有相同的索引节点号的两个文本本质上是同一个文件（除文件名不同外）。

（7）给server2和server3安装mfs chunk
真正存储数据的节点安装chunkserver





安装之后在两个节点都会生成一个mfs用户

（8）接下来做一些最基本的测试
注意：在这里我们可以给server2添加虚拟磁盘进行分区，然后挂在做实验
也可以实际使用server2的/目录下的空间，都可以
查看一下存储端server2上的内存使用情况

在临时目录/mnt下面创建一个实验目录

修改该目录的权限为mfs用户

在server2上做解析


在server3上面做解析


=编辑server2上的配置文件

写入存储数据的目录

=开启服务

开启服务之后会发现改目录下会有256个目录

浏览器查看，可以看到server2这个存储节点
同理，在server3上再次测试




可以看出server2和server3同时通过server1的9420端口与server1进行交互



浏览器再次查看，此时server2和server3两个存储节点都在监控当中了

以上配置好了MFS系统的master节点和chunkserver节点，接下来配置客户端

（9）在真机上配置客户端


编写客户端的配置文件，将分布文件系统的数据目录挂在本地/mnt/mfs/目录上


在客户端做解析


建立挂在目录，注意必须是一个空目录
并且进行挂载

在挂载目录下建立两个实验目录
可以看出两个实验目录目录下的数据存储均分为两个副本

将第一个目录的副本个数变为1个
然后在改目录下面存储一个文件，发现文件完整的存储在server3上面

然后给第二个实验目录拷贝一份文件
发现这个文件存储在server2和server3上面

停止server3上面的chunk服务

发现客户端存储在server2上的数据还在，存储在server3上面的数据没有了

第一个实验目录下的文件置存储在server3上，因此数据没有了

再次开启server3上面的chunk服务

发现第一个目录和第二个目录下面的数据全部回来了

再次测试，在第一个目录下面生成一个100M的文件
可以看出该文件被分成了两部分存储在两个chunk节点上面，各个chunk节点的副本个数均为1

同理，在第二个实验目录下面生成一个100M的文件
发现该文件被存储在两个chunk节点上面，并且每个chunk节点上面存储数据的副本个数均为2个

关闭server3上面的chunk服务

发现第二个实验目录下面的数据完整在server2上存在一份
发现第一个实验目录下面的数据存储在chunk3上的数据不见了

再次开启server3上面的chunk服务

再次验证

总结一下整个过程的实验思想
其实就是我们的客户端（真机）在存储数据的时候，先去找mfs server端（server1的9421端口），
然后mfs server端（server1的9420端口）后面挂着很多台真正存储数据的mfs chunk端（server2和server3），
其实server1会根据自己内部的均衡算法把客户端的数据合理的存储在后端的各个节点上面，
其实也就是server1把客户端的大文件拆分成很多的小文件，然后分布存储在后端的各个节点上面，
这样做的好处就是，存储效率高，客户端的读取速率也会很快，
而且分布存储也可以设置副本的个数，这样也不至于后台一台chunk端挂了，导致客户端所有的数据丢失，
因为每一个服务器的io都是有限制的，如果只针对一个节点来存储的话，性能会变的很差，
而且分布存储的关键在于master端的分配与调用，
我们的客户端会仍然感觉自己的文件还是一个大文件形式的存储
好了，就先说这么多吧！！！！！！！！！！！！！！！！

（10）接下来验证一个文件删除之后恢复的过程


稍后补充