四台 debian 服务器下如何优雅地保持某个超大文件夹下的文件同步？
spediacn · 2023-08-01 03:40:04 +08:00 via iPhone · 3943 次点击这是一个创建于 482 天前的主题，其中的信息可能已经有所发展或是发生改变。
有四台 debian11 服务器，在其上保持四台服务器都能读写某一个文件夹并在其他服务器上实时同步，看看各位有什么脑洞？
注意：
- 这个文件夹下文件和子文件夹数量很庞大，可以达到百万；
- 可以用共享文件夹协议，也可以用文件同步协议，也可以用各种高速缓存组件，不考虑磁盘占用的空间浪费，可以冗余最高 4 份；服务器配置相同，内存均为 512G ，硬盘数量相同，CPU 也相同；写入频次和增量大约每秒 100 个文件或每秒 100M 数据量，读的频次很高，大约每秒读 500 个文件或者 300M 数据量
- 只有一个目的：该文件夹的读写是四台服务器高速共用的，网卡都是多个万兆口，不论同步预读还是共享，希望实际环境中不要长时间把带宽拉满哦。
 |
1
serafin 2023-08-01 04:35:47 +08:00
好像这 4 台服务器没有主从关系。试试 类似 Resilio Sync 这类 P2P 同步。
|
 |
2
sNullp 2023-08-01 04:37:04 +08:00
ceph
|
 |
3
dcsuibian 2023-08-01 04:38:56 +08:00
做成 NAS 呢，只存在一份就不用同步了
|
|
4
serafin 2023-08-01 04:54:32 +08:00
万兆口应该用基于 iSCSI 的 SAN 而不是 NAS
|
 |
5
liangkang1436 2023-08-01 06:38:01 +08:00 via Android
试试 nfs
|
 |
6
neroxps 2023-08-01 06:54:26 +08:00 via iPhone
ceph
|
 |
7
Jirajine 2023-08-01 06:54:50 +08:00  1
只能用共享存储协议，任何同步方式都无法保证足够的实时性和一致性。
|
 |
8
hawhaw 2023-08-01 07:00:32 +08:00 via Android
syncthing 了解一下
|
 |
9
PerFectTime 2023-08-01 07:59:38 +08:00 via iPhone
Resilio Sync 在本地会有一个超大的索引 db 文件，百万级文件应该会超大吧。之前同步 200g 文件，索引 db 有 10g
|
 |
10
liuguangxuan 2023-08-01 08:12:48 +08:00 via Android
rsync
|
 |
11
lerry 2023-08-01 08:16:14 +08:00 via iPhone
minio
|
 |
12
mokiki 2023-08-01 08:20:35 +08:00 1
关键是四台机器怎么写的。会同时写一个文件吗？还是服务器之间有锁机制？
这个不讲清楚，贸然行动，会导致文件混乱。 |
 |
13
ice2016 2023-08-01 08:25:33 +08:00
fastdfs 也可以实现
|
 |
14
everyx 2023-08-01 08:27:27 +08:00
在用 juicefs ，你可以试试
|
 |
15
litguy 2023-08-01 08:30:02 +08:00
glusterfs 试试呢，感觉和你场景是匹配的
|
 |
17
fiht 2023-08-01 08:51:55 +08:00
|
 |
18
dusu 2023-08-01 08:58:42 +08:00 via iPhone
看什么数据了 除开日志之类的普通文件
先存 s3 从四台机器上做反代访问 s3 数据 同时缓存热数据 既能低成本 还能提高可靠性 啥？ s3 怕单点问题 就异步存多个 s3 |
 |
20
hefish 2023-08-01 09:31:25 +08:00
oracle 的 ocfs2 好像也行的。
|
 |
21
ConfusedBiscuit 2023-08-01 10:44:17 +08:00
1. “写入频次和增量大约每秒 100 个文件或每秒 100M 数据量，读的频次很高，大约每秒读 500 个文件或者 300M 数据量”，这频率，这容量，syncthing 之类的一般同步就不要想了，同步速度很可能跟不上变更速度。而且一处变更要发给另 3 台机器，带宽占用不会小
2. NFS ，CFS ，FastCFS 之类的共享文件存储是个可行的方案，但是要注意不同实例间是否会并发写同一个文件，需不需要加锁之类的问题。还有，这个方案不一定占用带宽最高，毕竟其他实例写的文件，如果这个实例不读，是不需要同步过来的 3. 强一致和最终一致的问题，如果能从强一致放宽到最终一致，那就简单的多，搞个主从，一个实例写，其他实例拉变更就行 |
 |
22
bao3 2023-08-01 10:52:58 +08:00
这全需求只能用共享存储，除了 nfs 等等，iSCS 也可以。集群加存储也可以解决。就是要注意上面大佬提到的，保护锁的问题。同一个文件是否存起异地读写的可能
|
 |
23
kobe718 2023-08-01 11:09:35 +08:00
ceph 之类的分布式文件系统吧
|
 |
24
itsjoke 2023-08-01 11:37:18 +08:00
用过 Glusterfs ，不过貌似一段时间需要重启一下服务，不然 Volume 容易 Down 掉。我使用的场景没那么大，OP 可以一度。
|
 |
25
jurassic2long 2023-08-01 11:50:45 +08:00
大数据? 试试 HDFS
|
 |
26
mayli 2023-08-01 12:15:49 +08:00 via Android
我有个穷人的方案 假如你不想上 ceph
可以所有机器都上 nfs 然后 autofs 全部挂载 最后 mergerfs 空间合并 优点是技术架构简单 性能也还行 缺点是没办法存储超过单节点大小的文件 |
 |
27
aru 2023-08-01 12:40:19 +08:00
文件数量太多了，上 ceph 吧，最好给 ceph 单独的存储网络
|
 |
29
u20237 2023-08-01 14:00:46 +08:00
rsync 感觉特别费 CPU 和内存，
打包传输或者直接 HTTP 下载比较合适 torrent 配置有些麻烦 |
 |
30
westoy 2023-08-01 14:07:31 +08:00
DRBD
|
 |
31
ruanimal 2023-08-01 15:41:51 +08:00
感觉像是 x-y 问题
|
 |
32
longbow0 2023-08-01 15:49:39 +08:00
加一个单独的存储服务器，配置好 NFS 服务，公共数据放在存储上；
其他 4 台服务器通过 NFS 访问存储的数据就行了 如果数据量巨大，实时存储不大现实 |
|
33
longbow0 2023-08-01 15:51:58 +08:00
这也是很多超算采用的存储方法，多个计算节点+1 个存储节点，公共数据放存储节点
|
 |
34
tool2d 2023-08-01 15:54:20 +08:00
巨量小文件应该用数据库，并合理规划读写分离流程。
你这同步一锅端的方案，实在不太看好。 |
 |
35
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 这样的低成本方案也行啊 |
|
36
thevita 2023-08-01 16:22:06 +08:00
@thevita
文件同步的方案我觉得不一定不行，如果规模就是这么大，存储又能接受，是可以的，关键是简单 至于以上说的弱点: a) 带宽问题，目前也不大吧，完全用不着 rsync 这样的，搞个什么简单的单向同步就行了（反正也需要保证不会冲突），带宽利用率还是很高的，rsync 需要 diff 完全没必要嘛 b) 巨量小文件是个问题，但是还是看场景的，况且也不是不能优化 |
 |
37
rrfeng 2023-08-01 16:28:15 +08:00 1
「四台同步」是你想出来的方案。
不如把业务需求讲出来，肯定有更合理的方案。 |
 |
38
zyq2280539 2023-08-01 18:40:44 +08:00
rsync 每 30 秒同步一次即可吧，差别也不大
|
 |
39
aapeli 2023-08-01 18:47:14 +08:00
文件同步没有锁，同一个文件在多个机子上被修改 会裂开，考虑选择共享文件系统？对象存储之类的解决方案？
例如 cluster-fs, minio, ceph ，swift ，nfs 等等方案 |
 |
40
0superx0 2023-08-01 19:07:12 +08:00
四台拿一台来开 NFS 文件共享不就行了？其它三台开机持载，这样随便一台对文件更改都是同时的
|
 |
41
vivisidea 2023-08-02 15:12:39 +08:00
需求细节还有些不清晰，比如“四台服务器都能读写某一个文件夹”具体会读写到同一个文件么? 如果两台服务器都在写同一个文件，以谁为准？怎么同步？
另外就是写的过程中可能会被读么？读到不完整文件会有什么问题么？ |
|
42
vivisidea 2023-08-02 15:13:55 +08:00
我会优先考虑对象存储，比如 S3 、MinIO ，其次会考虑 NFS 、ceph 、glusterfs 这些方案
|
 |
44
spediacn OP 一直忙着部署，没空上来看一下，今天来看居然有好多！感谢大家的建议，我列一下我的场景：
1. 这四台服务器配置为 Intel Silver 4416Y/521G DDR4/960G SSD*3/4T SATA 7200RPM*9 2. 要部署一套 4 节点高性能 ArcGIS Server 集群，集群需要依赖一个高速共享存储空间，用于存放集群配置和地图数据包，高速共享存储空间 ArcGIS Server 并没有做过多验证，他只要有一个文件夹能够四台服务器同时读写即可，但如果做同步的话，延迟不可太高，检测时如果写入完毕后超过十几秒后另外几台读不到文件就会出现离线判定； 3. ArcGIS Server 主要用于发布地图服务，也就是说读的业务量较大，但大部分服务在首次访问前会自动渲染缓存数据（瓦片 Tiles ），每个服务大约会生成 3000 万个 100-500KB 的瓦片文件，因此在渲染缓存时有超巨量的小文件写入，如果采用同步方式的话，此时同步压力巨大（我实测 rsync 会崩、fastdfs 扛住了、fastcfs 打算试试） 4. ArcGIS Server 存储瓦片有两种方式：分散模式和紧凑模式，分散模式每个瓦片存一个文件，紧凑模式按内置规则约 1000 个瓦片打包为 bundle 文件（ zip ）存储为一个文件 5. ArcGIS Server 提供大约 1600 个地图数据服务，由此产生的文件数量即使用紧凑模式也还是惊人的，本来用一台高性能 NAS 是最好解决方案，但目前没有，我只好用很土的办法，自己在底层直接挂 4T 裸盘然后用 zfs 组成一个存储池，再加入一块 ssd 做缓存，每台可提供 28TB 的存储空间 6. 目前不确定的是假如我在 zfs 之上叠一层 fastdfs/fastcfs ，他的同步性能如何？目前只能说没有崩溃，不过都在测试，后续我打算看看 fastdfs/fastcfs 的冗余策略测试一下，再和大家汇报 |
Select Language