fastDFS文件服务器（三）：集群和高可用环境篇

解决两个组轮询存储文件问题
上篇文章中我们搭建了单机版的fastDFS,其中storage有两个group，分别为head和other,我们在测试的时候发现文件每次上传都会到head目录下，如果你希望other和head目录存文件的几率是一样的，那么我们需要修改tracker.conf文件

vi /etc/fdfs/tracker.conf
store_lookup=0         
 #选择组的方法上传文件
  #0：轮转
  # 1：指定组
  # 2：负载平衡，选择最大的自由空间群上传文件
  修改为0后重启tracker服务
  /usr/local/fastDFS/FastDFS/tracker/fdfs_trackerd /etc/fdfs/tracker.conf restart
  再多次上传文件，则发现head和other的机会是均等的了

轮询后

storage集群环境

实际上在正式的生产环境中，如果只有一台机器是storage，那么当这台机器出现故障时会影响整个系统都不能存储和访问文件，所以需要再另一台机器上也有同样的storage,
两台机器组成集群环境。

1、环境准备

虚拟机环境
liunx服务器（三）：192.168.31.130

2、在192.168.31.130上安装storage

按照上篇文章中安装对应storage及其相关依赖包
安装成功后启动head和other
/usr/local/fastDFS/FastDFS/storage/fdfs_storaged /etc/fdfs/storage.conf restart
/usr/local/fastDFS/FastDFS/storage/fdfs_storaged /etc/fdfs/storage_other.conf restart
查看/fdfs/head/data和/fdfs/other/data生成的目录

256个子目录

3、在192.168.31.130上安装nginx

按照上篇文章中按照nginx及其相关插件包
安装和配置完成后需要修改192.168.31.128中nginx配置文件
vi /usr/local/fastDFS/trackerNginx/conf/nginx.conf
替换之前的这里的信息
#设置head的服务器
  upstream fdfs_head {
      server 192.168.31.129:8080 weight=1 max_fails=2  fail_timeout=10s;
      server 192.168.31.130:8080 weight=1 max_fails=2  fail_timeout=10s;
  }
  #设置other的服务器
  upstream fdfs_other {
      server 192.168.31.129:8080 weight=1 max_fails=2  fail_timeout=10s;
      server 192.168.31.130:8080 weight=1 max_fails=2  fail_timeout=10s;
  }
重启nginx

4、测试文件存储

此时在tracker中上传两次文件
/usr/local/fastDFS/FastDFS/client/fdfs_upload_file /etc/fdfs/client.conf /home/test.png
执行两次上面的命令，如下图所示

上传文件

在192.168.31.129中查看对应head和other目录下文件信息

在192.168.31.130中查看对应head和other目录下文件信息

image.png

5、测试文件访问
访问：http://192.168.31.128:8888/head/M00/00/00/wKgfgVrGEtyANsiaAAENlfmOar0820.JPG

清除缓存，停掉129上的storage

缓存清除
http://192.168.31.128:8888/purge/head/M00/00/00/wKgfgVrGEtyANsiaAAENlfmOar0820.JPG

缓存清除

停掉129上storage
ps -ef | grep storage
kill掉对应进程

停止成功

再次访问，任然成功

tracker高可用问题

在实际生产环境中，tracker也是成对出现的，既可以保证tracker的高可用性，也可以起到分流、实现负载均衡。

环境准备

虚拟机环境
liunx服务器（四）：192.168.31.131

首先按照上一篇文章中的tracker安装步骤安装好tracker和对应的nginx

1、修改client.conf配置文件

  修改四台机器的client.conf配置文件
  #之前的基础上修改tracker_server为两个即可
  tracker_server=192.168.31.128:22122  
  tracker_server=192.168.31.131:22122

2、修改/etc/fdfs下面的storage中storage.conf和storage_other.conf

vi /etc/fdfs/storage.conf
#只需要修改下面tracker_server部分即可
tracker_server=192.168.31.128:22122
tracker_server=192.168.31.131:22122

vi /etc/fdfs/storage_other.conf
#只需要修改下面tracker_server部分即可
tracker_server=192.168.31.128:22122
tracker_server=192.168.31.131:22122

3、修改/etc/fdfs下面的mod_fastdfs.conf

vi /etc/fdfs/mod_fastdfs.conf
#只需要修改下面tracker_server部分即可
tracker_server=192.168.31.128:22122
tracker_server=192.168.31.131:22122

4、重启tracker和storage测试文件上传
我们分别重启四台机器上对于的tracker和storage及其nginx
确认都重启成功后，我们进行测试
在128上上传文件如下图所示，分别上传到storage的head和other中

128文件上传

然后在131上传文件如下图所示，分别上传到storage的head和other中

131文件上传

我们到129和130两台storage中都可以找到上面的四张图片

129上的文件

130上的文件

129和130中storage的other下面的文件此处不再截图展示了。

此时停止掉128上的tracker进程，我们会看到131中的日志信息，131的tracker成为了新的leader

131中tracker日志

此时再次上传文件，会发现128中任然可以成功，131中也可以成功，因为client.conf文件中配置了两个tracker服务器，由于我们停止了128中tracker，所以这里会报错

仍然OK

下篇文章中将会结合代码进行文件上传。

fastDFS文件服务器（三）：集群和高可用环境篇

你可能感兴趣的:(fastDFS文件服务器（三）：集群和高可用环境篇)