开放原子开发者工作坊

前言:

      由于公司项目需要，最近开始学习一下分布式存储相关知识，确定使用FastDFS这个开源工具。学习之初，自己利用VMware虚拟机搭建了一个5台机器的集群，摸清了安装过程中可能出现的问题和解决方案(http://www.cnblogs.com/PurpleDream/p/4510279.html )。后来在正式环境搭建的时候，自己安装的还是很顺利的，但是因为是线上环境，所以安装的时候就要注意集群设计等方面的问题。

      如果您是第一次安装FastDFS5.0.5，建议先仔细看下我的http://www.cnblogs.com/PurpleDream/p/4510279.html 这篇文章，虽然是在虚拟机上搭建的集群，但是涉及的问题和解决问题的方案绝对是比较全面的。

      本篇文章主要是在上一篇虚拟机搭建FastDFS5.0.5的基础上，探讨线上环境搭建的注意点和不同点，请注意~

 

===============================================================长长的分割线====================================================================

 

正文:

 

      第一步，确认资源&明确设计:

      因为所属本部门的线上服务器比较紧张，所以暂时只能提供给我三台线上服务器供我使用，另外由于当前的第一使用场景只有本部门的一些业务系统接入，没有到公司级别，评估了初期的总数据量和并发量，初期集群用这三台是可以接受的，上线稳定后，如果存储不足，再相应的加机器。下面为了说明问题方便，我将这三台服务器暂时命名为:线上A、线上B、线上C。 

      在设计集群存储的时候，我是这样考虑的:

      1. 既然是分布式存储，那么无论是tracker还是storage，在设计中一定要避免“单点”的情况出现。

      2. 我理解的FastDFS集群中只有一个group倒是无所谓的，因为多个group只是为了负载均衡以及更重要的是获得更大的存储空间。

      3. 每个group的storage两台是最合适的，两台以上完全没有必要，因为同步那么多台机器，99.99%的情况下是浪费了服务器的存储空间，只有0.01%可能会在其中两台机器同时挂了的情况下，起到备份的作用。所以基于以上三个原则，我的设计方案如下:

      

      

 

　　第二步，FastDFS安装:

      此处在线上安装的时候，基本和我在vmware虚拟机上模拟的没有出入，可以操作参考http://www.cnblogs.com/PurpleDream/p/4510279.html 我的这篇文章，文章中提示的一些重点问题，只要在安装过程中按照文章中的方式解决，就可以避免。

      需要注意的是，有些公司的线上机器运维是做了一定的初始化的，perl和nginx等软件的版本与我所安装的版本的差异性造成的一些在我的文章中没有提及的可能出现的问题。

 

      第三步，Nginx安装:

      此处在安装tracker和storage的nginx时，其实也与我之前的文章是一致的。但是我的线上有个设计是在之前的虚拟机搭建过程中没有涉及的。就是在在安装线上B这台机器时，由于这台机器上同时安装了tracker和storage，所以我们在nginx时既要配置tracker应该提供的负载均衡的功能，还要提供storage的映射文件下载路径的功能。

      如果你对如何配置一台服务器上只有tracker或者storage没有太深的了解，可以参考我的上一篇文章http://www.cnblogs.com/PurpleDream/p/4510279.html，这里我们直接讲如何处理tracker和storage在同一台服务器nginx的配置情况。此处我们需要在nginx中配置两个server，一个server用来做负载均衡，另外一个server做路径映射。详细如下:

#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;

    sendfile        on;
    tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;

    #gzip  on;

    server_names_hash_bucket_size 128;
    client_header_buffer_size 32k;
    large_client_header_buffers 4 32k;

    client_max_body_size 300m;

    proxy_redirect off;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    proxy_connect_timeout 90;
    proxy_send_timeout 90;
    proxy_read_timeout 90;

    proxy_buffer_size 16k;
    proxy_buffers 4 64k;
    proxy_busy_buffers_size 128k;
    proxy_temp_file_write_size 128k;
   
    proxy_cache_path /fastdfs/cache/nginx/proxy_cache levels=1:2 
    keys_zone=http-cache:500m max_size=10g inactive=30d;
    proxy_temp_path /fastdfs/cache/nginx/proxy_cache/tmp;

    upstream fdfs_group1 {
         server 10.9.18.13:8088 weight=1 max_fails=2 fail_timeout=30s;
         server 10.9.18.14:8088 weight=1 max_fails=2 fail_timeout=30s;
    }

    server {
        listen       8085;
        server_name  localhost;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

        location /group1/M00 {
            proxy_next_upstream http_502 http_504 error timeout invalid_header;
            proxy_cache http-cache;
            proxy_cache_valid  200 304 12h;
            proxy_cache_key $uri$is_args$args;
            proxy_pass http://fdfs_group1;
            expires 30d;
        }
  
        location ~/purge(/.*) {
            allow 127.0.0.1;
            allow 10.9.18.0/24;
            allow 10.58.99.0/24;
            deny all;
            proxy_cache_purge http-cache  $1$is_args$args;
        }     

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }

    server {
        listen       8088;
        server_name  localhost;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

        location / {
            root   html;
            index  index.html index.htm;
        }

        location ~/group1/M00{
            root /fastdfs/fastdfs_storage_data/data;
            ngx_fastdfs_module;
        }

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }

}

 

      如上面的配置所示，我一共配置了两个server，第一个server监听8085端口，提供tracker的负载均衡功能，最终将http请求分发到线上机器B和线上机器C的8088端口；第二个server监听的是8088端口，当线上机器B收到tracker分发的请求后，然后利用这个server将请求映射到文件的真实存储路径。

 

      第四步，安装番外篇:

      其实本文的核心或者是我在安装过程中的最大体会就是，一定要在虚拟机环境或者线下环境尽可能的将安装流程模拟清楚，这样就会事半工倍。如果你做过充分的模拟的话，相信在线上环境安装时经过上边的这几步，99%的情况下你已经成功了。

      我在我的上一篇虚拟机安装FastDFS文章http://www.cnblogs.com/PurpleDream/p/4510279.html中，已经提到了FastDFS维护的常用命令。但是我还要介绍一下如何在删除线上的某个group的storage。之所以讨论这个问题，是因为我在第一次安装线上时，group1的storage多了一台线上A，后来想想完全是没有必要的，所以就想删掉它。

      当时第一次操作的时候，是直接kill掉线上A中的storage线程。然后修改配置文件中的配置。最后重启之后利用fdfs_monitor命令查看集群时，发现这个storage还是存在于group1这个组中，只不过storage状态是OFFLINE，这就说明我的删除方法是有问题的，为了不影响线上使用，我又紧急花费了一些时间将集群先恢复成原来的配置。

      后来静下心后查阅了资料，并且在虚拟机上模拟了几遍后，删除线上某个group中的storage的过程总结如下:

      1. 停掉要删除的storage节点。

      2. 在一台依然运行的storage上执行如下命令:

           /usr/bin/fdfs_monitor /etc/fdfs/storage.conf delete group1  线上A的IP

      3. 将每个节点的/etc/fdfs/mod_fastdfs.conf文件中涉及删除掉的存储节点的配置都注释掉，注意，这个我们可以先看看我们之前在安装的时候都配置了哪些属性，然后逐一查看一下即可，要细心哦。

      4. 依次重启tracker。

      5. 然后再使用fdfs_monitor,查看一下情况，此时storage和处于ACTIVE状态的数量应该都是的2。个别情况下可能剩下的两个storage状态不是ACTIVE，则可以将storage节点再重启一下即可。

      6. 注意将tracker的nginx配置修改一下，尤其是http请求分发的配置，要将已经删除掉的storage节点的配置注释掉。 

      7. 将开机启动中的启动storage节点的代码注释掉。

 

 

      第五步，线上维护篇（截止到2015年11月25日）:

      这第五部分的内容是线上集群在运行的过程中，我遇到的问题和解决方式:

      事故一:

          事故现象: 2015年11月11日下午16:30，调用我的业务方发现调用我的存储集群突然全部失败了，注意是全部失败。但是通过fdfs_monitor发现集群应该是正常的，未使用的存储空间也还是有的。

          解决过程: 由于当时本人在封闭开发更紧急的项目，所以此问题一出现，可能自己脑子太热一开始就想的过于复杂了，直接用源码调试了一下，发现是获取不到storage，由于对源码不是很熟悉，在报异常和异常信息不是很明确，一直认为是tracker获取storage时链接没有建立。所以一直在从网络层面进行调试，额。。。于是越走越远。

          解决问题:由于运维和我一起抓包等都看不出网络层面的问题，所以心灰意冷的回家了。洗了澡之后，仔细想了想自己当初搭建的过程，又重新看了一遍自己当初在虚拟机上搭建成功时写的这篇博客http://www.cnblogs.com/PurpleDream/p/4510279.html。于是直接在集群上开始直接使用命令“/usr/bin/fdfs_upload_file  /etc/fdfs/client.conf  /etc/fdfs/http.conf”测试一下上传一个名字为http.conf的文件到集群，报了如下截图中的错误:

           

           额。。。。No Space，然后通过搜索错误“tracker_query_storage fail, error no: 28, error info: No space left on devic”，把问题定位到了tracker.conf中的一个名为reserved_storage_space的属性上，这个属性的默认值一般是4G(当然也支持直接写百分比)，当storage中空闲存储空间最小的那一台的容量也小于这个大小的时候，tracker就取不到可用的storage了，所以也就不存储了。而我当时搭建集群的时候，把这个值配置的是10%，所以虽然我的空间还够，但是已经低于10%了。

         问题总结:戒骄戒躁，冷静下来分析问题，有些东西也许真的是你想的太多了！