Chinaunix首页 | 论坛 | 博客
  • 博客访问: 60933
  • 博文数量: 9
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 96
  • 用 户 组: 普通用户
  • 注册时间: 2014-05-26 12:24
文章分类

全部博文(9)

文章存档

2016年(6)

2015年(1)

2014年(2)

我的朋友

分类: 系统运维

2016-01-25 23:35:35


由于业务需求, 所以shou55在生产环境中也使用分布式的系统, 当然比如分布式存储, 分布式计算, 分布式数据库这么多分布式到是没有接触的那么全面. 这里主要说一下我所使用到的分布式存储, 这里只涉及存储不涉及分布式计算.

shou55在生产环境中使用过2种分布式存储, 一种是fastdfs , 另外一种就是标题所说的seaweedfs, 在国内而言fastdfs的使用者目前比seaweedfs的使用者要多很多. 但是我一直觉得fastdfs没有一个正式的官网, 很多说明文档和ppt都是分散在chinaunix的论坛上的不同帖子里, 实在不方便系统查看. 算了, 这些都是费话, 入正题吧.

seaweedfs最常见的2种角色是master和volume, 相关的文档也很全面, google一下前几条肯定就能看到. 如何安装启动这些wiki文档上都有, 直接看英文原文就可以了, 这里说一下我在使用过程中遇到的一些问题以及在部署和监控上的一些个人实践.

备注一条:
因为master和volume要使用的节点较多, 一台服务器上可以使用不同的端口和目录来模拟部署. 或者使用docker来模拟部署, shou55在测试seaweedfs的时候就是使用的docker来模拟部署的, 比较方便.

关于master
(1)-pulseSeconds
这个值越小, 当DataNode宕机后隔离出去的时间就越短, 同时多个master时这个值越小, master之间的故障切换时间就越短

(2)-ip
这个选项也特别重要, 尤其是在有多个master, 要设置peers时.    该参数设置为所在服务器的出口ip即可, 相当于表明自己是谁

(3)-peers
比如A,B,C共有3个master, 这3个的peers参数都可以设置为其中一个的ip地址, 比如ABC这3个master启动时都设置peers参数为A的ip地址. 同时volume在启动的时候也可以只到一个固定的ip, 同样可以都设置为A服务器的ip地址. 且需要特别注意:
shou55实测如果有3个master, 则只允许一个master down机, 3个中宕一个, 可以自动切换, 如果再宕一个, 则无法切换了.  且3个master必须同时存在过, 不能先启动A,B, 等A宕机以后再启动C, 这样则会有问题, 必须ABC都启动, 完成以后如果有其中一台宕机, 则是没有问题的.

另外, shou55实测发现, master启动前把日志和相关配置清理掉才最好, 否则重新启动时可能会有影响, 比如通过api查看到的peers信息不正确

另外:
关于Replication其实有很多需要思考的地方, 但是这个与具体的应用场景关系比较密切. shou55个人偏向于使用001这种备份方式, 因为逻辑层次浅, 结构清晰, 扩展和管理也非常方便.  我在考虑使用何种Replication时也有借鉴fastdfs的group的因素.

举例:
./weed -log_dir='/path/to/seaweedfs/master/logs'  master  -defaultReplication="001" -mdir="./master"  -peers="1.1.2.2:9333"   -volumeSizeLimitMB=10  



关于volume
假设启动方式如 ./weed volume -max=5 -mserver=localhost:9333 -dir=./data 所示, 则在-dir所对应选项的目录下会最多生成5组文件, 每一组文件形如1.dat  1.idx  . 前面的数字是变的, 如果有5个则依次是1,2,3,4,5, 如果有ttl到了被自动删除, 则再申请时就可能变成6,7,8,9,10这样, 依此类推.  如果在创建的时候使用了curl ""  这种参数, 则生成的文件名会以collection名为前缀, 变成turbo_1.dat turbo_1.idx这种格式

有几个重要选项:
-mserver
假设有A,B,C共3个master, 和5个volume, 则volume启动的时候都可以只指向A这一个master即可, 也完全正常的.

-rack
因为我前面使用的是001这种备份方式, 所以rack一定要相匹配, 一个rack中至少要有2台服务器. 为方便管理其实也只建议用2台服务器, 然后其它的服务器以新的rack加入. 但是因为shou55所使用的硬件比较特殊, 所以我在实际部署中是使用的是1个rack  3个data node的形式.

-ip
设置成volume server自己的服务器ip


举例:
./weed  -log_dir='/path/to/seaweedfs/volume/logs'   volume -dir="volume" -ip="1.1.2.3" -max="3" -mserver='1.1.2.2:9333'  -rack='rack2' 


建议在启动服务时都指定一下log_dir, 否则使用的默认值是/tmp目录, 生成的文件较多, 很难看.


FAQ
一个DataNode down机以后, 隔离的时间可不可以短一些?
可以的, 通过pulseSeconds参数可以设置, master和volume都要设置且volume的要<=master的此参数. 同事通过源码分析出来切换的时长在[3*n,5*n)范围内, 与shou55实际验证的切换时间范围符合. 所以目前这个值我都设置成1s的


只有2个master是否可以自动切换, 他们之间切换的时间可不可以短一些?
第1个小问题:
shou55实测过, 只有2个master不可以实现自动切换, 至少3个master才可以故障自动切换, 这种与keepalived这类不同, 具体的Raft protocol 原理我也没看明白.
假设有3个master, 当第一个坏了以后可以自动切换, 但是当第一个和第二个相继都坏了之后, master之间就无法自动切换了, 剩下的最后一个master不会变成Leader. 也就是3个master中至少要保证有2个是存活的才能正常写入, 如果3个中只剩下最后一个是存活的, 那么整个集群都将无法写入.


至于master主备的切换时间:
这个还是pulseSeconds参数在起作用, shou55实测当所有master的这个值都设置为1的时候, 切换大概在5秒左右, 但是如果这个参数设置为100, 则切换时长大约在7m41s, 与上面的切换时间范围也吻合.  但是因为shou55在测试的时候volume的pulseSeconds设置的是1,而master的这个值为100,  由此导致的问题是在master切换的过程中, volume一直与之前的主master连接失败, 当master切换完成以后, 结果已经无法获取到后端的volume了,  必须把所有的volume都重启一次才可以正常使用.  所以, 虽然文档中说需要volume的值小于等于master,但是在上面的例子中可以看到, volume的1是明显小于master的100, 一样有问题, 因此shou55认为master和volume的pulseSeconds都设置为相同的值是比较好的.


文件写入流程?
(1)Assign a file key :  
curl ""
{
  "fid": "182,8bd26721e6",
  "url": "172.17.0.8:8080",
  "publicUrl": "172.17.0.8:8080",
  "count": 1
}
通过master先申请分配文件的fid, 和publicUrl

(2)Upload File:
curl -F file=@/home/chris/myphoto.jpg
把publicUrl和fid 拼接成一个完整的url, 然后上传


文件读取流程?
(1)通过fid确定publicUrl
curl ""
{
  "volumeId": "11",
  "locations": [
    {
      "url": "172.17.0.8:8080",
      "publicUrl": "172.17.0.8:8080"
    },
    {
      "url": "172.17.0.2:8080",
      "publicUrl": "172.17.0.2:8080"
    }
  ]
}


(2)
根据上一步得到publicUrl以及已有的fid拼接成一个完整的url,  
即可访问.




如何监控?
shou55自己想到的是监控以下4点, 基本可以保证无论是master, volume还是整体功能都是正常的.
(1)tcp端口监控

(2)测试写入, 每1分钟写入1次
[{"fileName":"/tmp/anaconda-post.log","error":"Post dial tcp 172.17.0.7:9333: connection refused"}]  不正常的返回结果
[{"fileName":"abc.txt","fileUrl":"172.17.0.8:8080/9,01b16f4a4c2f","fid":"9,01b16f4a4c2f","size":83}]    正常的返回结果

(3)各master的 结果, 必须要有Leader,且同一组master服务器的Leader值要相同.另外因为线上是按3个master部署的, 所以Peers中要有2个才对.   监控这一条是为了保证在出现一个master异常时, 其它master可以自动切换, 否则几个master之间的状态已经不对了, 当主master故障时就没有办法自动切换了.

(4)curl ""  检查DataNodes的数量, 这个值表示的是从master中查看到的DataNode的数量. 如果连续2次获取到的DataNode数量不相同, 则表明有节点down机或新扩容了节点






阅读(3260) | 评论(0) | 转发(0) |
0

上一篇:我与lvs的2015年

下一篇:简易版分布式mysql

给主人留下些什么吧!~~