四台 debian 服务器下如何优雅地保持某个超大文件夹下的文件同步?

2023-08-01 03:40:04 +08:00
 spediacn

有四台 debian11 服务器,在其上保持四台服务器都能读写某一个文件夹并在其他服务器上实时同步,看看各位有什么脑洞?

注意:

  1. 这个文件夹下文件和子文件夹数量很庞大,可以达到百万;
  2. 可以用共享文件夹协议,也可以用文件同步协议,也可以用各种高速缓存组件,不考虑磁盘占用的空间浪费,可以冗余最高 4 份;服务器配置相同,内存均为 512G ,硬盘数量相同,CPU 也相同;写入频次和增量大约每秒 100 个文件或每秒 100M 数据量,读的频次很高,大约每秒读 500 个文件或者 300M 数据量
  3. 只有一个目的:该文件夹的读写是四台服务器高速共用的,网卡都是多个万兆口,不论同步预读还是共享,希望实际环境中不要长时间把带宽拉满哦。
4031 次点击
所在节点    Linux
45 条回复
ConfusedBiscuit
2023-08-01 10:44:17 +08:00
1. “写入频次和增量大约每秒 100 个文件或每秒 100M 数据量,读的频次很高,大约每秒读 500 个文件或者 300M 数据量”,这频率,这容量,syncthing 之类的一般同步就不要想了,同步速度很可能跟不上变更速度。而且一处变更要发给另 3 台机器,带宽占用不会小
2. NFS ,CFS ,FastCFS 之类的共享文件存储是个可行的方案,但是要注意不同实例间是否会并发写同一个文件,需不需要加锁之类的问题。还有,这个方案不一定占用带宽最高,毕竟其他实例写的文件,如果这个实例不读,是不需要同步过来的
3. 强一致和最终一致的问题,如果能从强一致放宽到最终一致,那就简单的多,搞个主从,一个实例写,其他实例拉变更就行
bao3
2023-08-01 10:52:58 +08:00
这全需求只能用共享存储,除了 nfs 等等,iSCS 也可以。集群加存储也可以解决。就是要注意上面大佬提到的,保护锁的问题。同一个文件是否存起异地读写的可能
kobe718
2023-08-01 11:09:35 +08:00
ceph 之类的分布式文件系统吧
itsjoke
2023-08-01 11:37:18 +08:00
用过 Glusterfs ,不过貌似一段时间需要重启一下服务,不然 Volume 容易 Down 掉。我使用的场景没那么大,OP 可以一度。
jurassic2long
2023-08-01 11:50:45 +08:00
大数据? 试试 HDFS
mayli
2023-08-01 12:15:49 +08:00
我有个穷人的方案 假如你不想上 ceph
可以所有机器都上 nfs
然后 autofs 全部挂载
最后 mergerfs 空间合并
优点是技术架构简单 性能也还行
缺点是没办法存储超过单节点大小的文件
aru
2023-08-01 12:40:19 +08:00
文件数量太多了,上 ceph 吧,最好给 ceph 单独的存储网络
nuk
2023-08-01 13:42:50 +08:00
@mayli mergerfs+nfs ,你是嫌炸的不够快,我公司用了同方案,基本上隔段时间就读写卡死。
u20237
2023-08-01 14:00:46 +08:00
rsync 感觉特别费 CPU 和内存,
打包传输或者直接 HTTP 下载比较合适
torrent 配置有些麻烦
westoy
2023-08-01 14:07:31 +08:00
DRBD
ruanimal
2023-08-01 15:41:51 +08:00
感觉像是 x-y 问题
longbow0
2023-08-01 15:49:39 +08:00
加一个单独的存储服务器,配置好 NFS 服务,公共数据放在存储上;
其他 4 台服务器通过 NFS 访问存储的数据就行了

如果数据量巨大,实时存储不大现实
longbow0
2023-08-01 15:51:58 +08:00
这也是很多超算采用的存储方法,多个计算节点+1 个存储节点,公共数据放存储节点
tool2d
2023-08-01 15:54:20 +08:00
巨量小文件应该用数据库,并合理规划读写分离流程。

你这同步一锅端的方案,实在不太看好。
thevita
2023-08-01 16:11:00 +08:00
题主没把 workload 说清楚

1. 看写文件会不会有冲突, 如果能避免冲突(比如 append only+ node_id 分区文件名/目录) 就可以多机分别写
2. 读的 pattern 和要求是怎么样的,一致性要求?目录同步必然不能强一致, 读 pattern 是怎么样的,随机/还是顺序? 是否存在热点读

根据以上可选的有,比如:

1. 最好当然是有比较好的共享存储设备/集群, 比如有单独的团队,不用管运维,多好
2. 可以避免写冲突且容忍最终一致性,可以设计一些文件同步逻辑 来同步,好处是可以利用本地 io 来处理比较高的 iops ,也比较简单
3. 如果读有热点可以 cache + s3 这样的低成本方案也行啊
thevita
2023-08-01 16:22:06 +08:00
@thevita

文件同步的方案我觉得不一定不行,如果规模就是这么大,存储又能接受,是可以的,关键是简单
至于以上说的弱点:
a) 带宽问题,目前也不大吧,完全用不着 rsync 这样的,搞个什么简单的单向同步就行了(反正也需要保证不会冲突),带宽利用率还是很高的,rsync 需要 diff 完全没必要嘛
b) 巨量小文件是个问题,但是还是看场景的,况且也不是不能优化
rrfeng
2023-08-01 16:28:15 +08:00
「四台同步」是你想出来的方案。

不如把业务需求讲出来,肯定有更合理的方案。
zyq2280539
2023-08-01 18:40:44 +08:00
rsync 每 30 秒同步一次即可吧,差别也不大
aapeli
2023-08-01 18:47:14 +08:00
文件同步没有锁,同一个文件在多个机子上被修改 会裂开,考虑选择共享文件系统?对象存储之类的解决方案?
例如 cluster-fs, minio, ceph ,swift ,nfs 等等方案
0superx0
2023-08-01 19:07:12 +08:00
四台拿一台来开 NFS 文件共享不就行了?其它三台开机持载,这样随便一台对文件更改都是同时的

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/961366

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX