当前项目中传统简单的fastdfs存储架构总结
发布： 2013-10-01 00:16

目前我们的图片存储系统，大概每个月使用1T的存储空间。
再加上图片处理后的图片，可能还会扩大2，3倍的存储容量。
之前使用NAS存储，已经无法满足这样的存储需求。
在上半年考虑使用分布式文件系统，经过调研，选用了开源的fastdfs。
由于初次使用，并没有使用太复杂的架构模式，而使用比较传统的使用模式。
先说下硬件情况，
现有同机房的4台fastdfs存储服务器，每台服务器使用6块2T的sata硬件做成raid5，大概可用存储容量为10多G。

在设计时，考虑足够的容灾要求，把4台服务器做成两组group1，group2。
这样，这个集群的容量为20G，远比使用NAS来的简单许多。
另外，由于在测试使用fastdht组件时遇到了问题，目前没有使用自带的文件去重功能。准备在研究出来原因之前，使用代码级别的去重，在使用异步去重计算的辅助情况下，去重效果理论上与fastdfs自带的排重功能一致。

目前项目上线2个月，已经存储了2T的图片文件。
目前的架构：
M1/group1/tracker1 ===== M2/group1/tracker2
M3/group2 ===== M4/group2

后续需要考虑跨机房的情况，以及重新平衡文件分布的相关机制，让整个系统的负载与存储分布更合理。
由于在跨机房的情况下，每个机房都必须部署tracker服务，并且再tracker分配storage的时候，必须支持当前请求写入当前机房的storage中，需要在代码层，通过fastdfs API中指定tracker与storage定稿的方式，替代默认情况下由fastdfs自动选取服务的方式优化系统运行，同机房读写在同机房内完成。
而互为镜像的一组存储服务器，需要分布在不同的机房，还会考察fastdfs 的跨机房镜像的特性与实际运行效果。

这种设计让每个机房都有一个数据的镜像，优化读写，但是当某机房内的fastdfs存储出现问题，在数据量为nTB的情况下，恢复起来会需要相当长的时间。这个还需要通过添加相应的同机房镜像的方式来解决。

未来的架构：
RDC1 RDC2
M1/group1 ===== M4/group1
M2/group2 ===== M5/group2
M3/gracker1 ===== M6/tracker1


原文： http://qtchina.tk/?q=node/766

Powered by zexport