本次采用两台服务器,都分别安装完整的单节点文件服务器。安装完成后,设置服务器 1 和服务器 2 上面的 storage 分别属于 group1 和 group2。两个 storage 的 tracker 地址设置为两个,具体关系如下:
简要说明:
一个 tracker 跟踪器配置多个 storage 的方法参考 FastDFS 文件服务器扩容文档。分别在服务器 1 和服务器 2 上面配置好文件后,启动服务,在两台服务器中输入指令:/usr/bin/fdfs_monitor /etc/fdfs/storage.conf。截图如下:
文件服务器配置好后,利用 keepalived 做虚拟 ip,具体操作请参考 nginx 和 keepalived 实现 nginx 高可用文档,虚拟 ip 设置成功后访问截图如下:
配置好文件服务器后,程序调用虚拟 ip 地址 10.63.0.158 可上传文件,在服务器上面测试时,直接调用文件上传命令如:/usr/bin/fdfs_upload_file /etc/fdfs/client.conf /home/1.png 上传文件,在服务器 1 和服务器 2 中上传的文件均可通过虚拟 ip10.63.0.158 访问。演示界面如下:
仔细梳理整个文件上传,存储流程。在两台服务器上面搭建的这一套文件服务器并能算一个完整的文件服务器集群。在 tracker 指向 storage 的设计模式时,是采用了 nginx 代理分发的模式。目前一个是自身,一个是另外一台服务器,以后再次扩展存储服务器时,可继续沿用。但是在 keepalived 做 nginx 高可用时,并没有做基于 tracker 的负载分发,笔者也尝试在现有服务器上面做 nginx.conf 文件配置,但由于本身又设置了 tracker 到 storage 的分发,keepalived 到 tracker 的分发并未生效。所以,目前两台文件服务器一个虚拟 ip 的模式,算是主备的关系。
由于设置在服务器 10.63.0.154 上面的 keepalived 的优先值高于在 10.63.0.155 服务器上面的优先值,故当服务器 10.63.0.154 正常运作时,文件上传只会走服务器 10.63.0.154 上面的 tracker 服务, tracker 根据配置规则存储文件到 group1 下面的存储器或 group2 下面的存储器。当服务器 10.63.0.154 出现异常时,keepalived 已经不可用,文件上传会走备用的服务器 10.63.0.155 上面的 tracker 服务存储文件。
文件服务器集群搭建目前需要四台服务器,在上面主备模式基础上,在加上两台服务器可做集群处理。集群关系图如下:
额外增加两台服务器,专门做 keepalived 与 nginx 的负载高可用,通过 nginx 管理后面两台服务器的 tracker 服务,做代理转发。可完成文件服务器集群搭建。其中,在两台新服务器的 nginx.conf 配置文件如下:
- #user nobody; worker_processes 1; #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; #pid logs/nginx.pid; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; #log_format main '$remote_addr - $remote_user [$time_local] "$request" ' # '$status $body_bytes_sent "$http_referer" ' # '"$http_user_agent" "$http_x_forwarded_for"'; #access_log logs/access.log main; sendfile on; #tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 65; #gzip on; upstream fastdfs_tracker { server 10.63.0.154:8888 weight=1 max_fails=2 fail_timeout=30s; server 10.63.0.155:8888 weight=1 max_fails=2 fail_timeout=30s; } server { listen 8888; server_name localhost; #charset koi8-r; #access_log logs/host.access.log main; location /fastdfs { root html; index index.html index.htm; proxy_pass http://fastdfs_tracker/; proxy_set_header Host $http_host; proxy_set_header Cookie $http_cookie; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; client_max_body_size 300m; } #error_page 404 /404.html; # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } } }
在实际使用中,通常是把 tracker 服务和 storage 服务安装在不同的服务器上,参考 CSDN 一位大牛的明细设计方案如下:
设计介绍文档地址: 手把手教你搭建 FastDFS 集群(下) ,该博主一共发布了上中下三篇文章,明确详细的介绍了文件服务器的搭建过程,经过测试可用,可谓是业界良心。在整个方案中,没有涉及到文件服务器迁移模块的知识,没有采用 storage_id.conf 的 id 配置模式,不便迁移。
来源: http://www.cnblogs.com/wlandwl/p/fastdfsGroup.html