V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Distributions
Ubuntu
Fedora
CentOS
中文资源站
网易开源镜像站
spediacn
V2EX  ›  Linux

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

  •  
  •   spediacn · 213 天前 via iPhone · 3381 次点击
    这是一个创建于 213 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    注意:

    1. 这个文件夹下文件和子文件夹数量很庞大,可以达到百万;
    2. 可以用共享文件夹协议,也可以用文件同步协议,也可以用各种高速缓存组件,不考虑磁盘占用的空间浪费,可以冗余最高 4 份;服务器配置相同,内存均为 512G ,硬盘数量相同,CPU 也相同;写入频次和增量大约每秒 100 个文件或每秒 100M 数据量,读的频次很高,大约每秒读 500 个文件或者 300M 数据量
    3. 只有一个目的:该文件夹的读写是四台服务器高速共用的,网卡都是多个万兆口,不论同步预读还是共享,希望实际环境中不要长时间把带宽拉满哦。
    45 条回复    2023-08-31 17:42:19 +08:00
    serafin
        1
    serafin  
       213 天前
    好像这 4 台服务器没有主从关系。试试 类似 Resilio Sync 这类 P2P 同步。
    sNullp
        2
    sNullp  
       213 天前
    ceph
    dcsuibian
        3
    dcsuibian  
       213 天前
    做成 NAS 呢,只存在一份就不用同步了
    serafin
        4
    serafin  
       213 天前
    万兆口应该用基于 iSCSI 的 SAN 而不是 NAS
    liangkang1436
        5
    liangkang1436  
       213 天前 via Android
    试试 nfs
    neroxps
        6
    neroxps  
       213 天前 via iPhone
    ceph
    Jirajine
        7
    Jirajine  
       213 天前   ❤️ 1
    只能用共享存储协议,任何同步方式都无法保证足够的实时性和一致性。
    hawhaw
        8
    hawhaw  
       213 天前 via Android
    syncthing 了解一下
    PerFectTime
        9
    PerFectTime  
       213 天前 via iPhone
    Resilio Sync 在本地会有一个超大的索引 db 文件,百万级文件应该会超大吧。之前同步 200g 文件,索引 db 有 10g
    liuguangxuan
        10
    liuguangxuan  
       213 天前 via Android
    rsync
    lerry
        11
    lerry  
       213 天前 via iPhone
    minio
    mokiki
        12
    mokiki  
       213 天前   ❤️ 1
    关键是四台机器怎么写的。会同时写一个文件吗?还是服务器之间有锁机制?
    这个不讲清楚,贸然行动,会导致文件混乱。
    ice2016
        13
    ice2016  
       213 天前
    fastdfs 也可以实现
    everyx
        14
    everyx  
       213 天前
    在用 juicefs ,你可以试试
    litguy
        15
    litguy  
       213 天前
    glusterfs 试试呢,感觉和你场景是匹配的
    litguy
        16
    litguy  
       213 天前
    @ice2016 fastdfs 不是 posix 兼容的,他需要 fastdfs 的儿子: fastcfs
    fiht
        17
    fiht  
       213 天前
    nfs 应该是正解,参见现在云厂商的方案。

    楼主应该是想要一个 https://cloud.tencent.com/product/cfs 的方案。
    dusu
        18
    dusu  
       213 天前 via iPhone
    看什么数据了 除开日志之类的普通文件
    先存 s3
    从四台机器上做反代访问 s3 数据 同时缓存热数据
    既能低成本 还能提高可靠性
    啥? s3 怕单点问题 就异步存多个 s3
    ice2016
        19
    ice2016  
       213 天前
    @litguy 第一次听说 FastCFS ,看着很强大的样子
    hefish
        20
    hefish  
       213 天前
    oracle 的 ocfs2 好像也行的。
    ConfusedBiscuit
        21
    ConfusedBiscuit  
       213 天前
    1. “写入频次和增量大约每秒 100 个文件或每秒 100M 数据量,读的频次很高,大约每秒读 500 个文件或者 300M 数据量”,这频率,这容量,syncthing 之类的一般同步就不要想了,同步速度很可能跟不上变更速度。而且一处变更要发给另 3 台机器,带宽占用不会小
    2. NFS ,CFS ,FastCFS 之类的共享文件存储是个可行的方案,但是要注意不同实例间是否会并发写同一个文件,需不需要加锁之类的问题。还有,这个方案不一定占用带宽最高,毕竟其他实例写的文件,如果这个实例不读,是不需要同步过来的
    3. 强一致和最终一致的问题,如果能从强一致放宽到最终一致,那就简单的多,搞个主从,一个实例写,其他实例拉变更就行
    bao3
        22
    bao3  
       213 天前
    这全需求只能用共享存储,除了 nfs 等等,iSCS 也可以。集群加存储也可以解决。就是要注意上面大佬提到的,保护锁的问题。同一个文件是否存起异地读写的可能
    kobe718
        23
    kobe718  
       213 天前
    ceph 之类的分布式文件系统吧
    itsjoke
        24
    itsjoke  
       213 天前
    用过 Glusterfs ,不过貌似一段时间需要重启一下服务,不然 Volume 容易 Down 掉。我使用的场景没那么大,OP 可以一度。
    jurassic2long
        25
    jurassic2long  
       213 天前
    大数据? 试试 HDFS
    mayli
        26
    mayli  
       213 天前 via Android
    我有个穷人的方案 假如你不想上 ceph
    可以所有机器都上 nfs
    然后 autofs 全部挂载
    最后 mergerfs 空间合并
    优点是技术架构简单 性能也还行
    缺点是没办法存储超过单节点大小的文件
    aru
        27
    aru  
       213 天前
    文件数量太多了,上 ceph 吧,最好给 ceph 单独的存储网络
    nuk
        28
    nuk  
       213 天前
    @mayli mergerfs+nfs ,你是嫌炸的不够快,我公司用了同方案,基本上隔段时间就读写卡死。
    u20237
        29
    u20237  
       213 天前
    rsync 感觉特别费 CPU 和内存,
    打包传输或者直接 HTTP 下载比较合适
    torrent 配置有些麻烦
    westoy
        30
    westoy  
       213 天前
    DRBD
    ruanimal
        31
    ruanimal  
       213 天前
    感觉像是 x-y 问题
    longbow0
        32
    longbow0  
       213 天前
    加一个单独的存储服务器,配置好 NFS 服务,公共数据放在存储上;
    其他 4 台服务器通过 NFS 访问存储的数据就行了

    如果数据量巨大,实时存储不大现实
    longbow0
        33
    longbow0  
       213 天前
    这也是很多超算采用的存储方法,多个计算节点+1 个存储节点,公共数据放存储节点
    tool2d
        34
    tool2d  
       213 天前
    巨量小文件应该用数据库,并合理规划读写分离流程。

    你这同步一锅端的方案,实在不太看好。
    thevita
        35
    thevita  
       213 天前
    题主没把 workload 说清楚

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

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

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

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

    不如把业务需求讲出来,肯定有更合理的方案。
    zyq2280539
        38
    zyq2280539  
       213 天前
    rsync 每 30 秒同步一次即可吧,差别也不大
    aapeli
        39
    aapeli  
       213 天前
    文件同步没有锁,同一个文件在多个机子上被修改 会裂开,考虑选择共享文件系统?对象存储之类的解决方案?
    例如 cluster-fs, minio, ceph ,swift ,nfs 等等方案
    0superx0
        40
    0superx0  
       213 天前
    四台拿一台来开 NFS 文件共享不就行了?其它三台开机持载,这样随便一台对文件更改都是同时的
    vivisidea
        41
    vivisidea  
       212 天前
    需求细节还有些不清晰,比如“四台服务器都能读写某一个文件夹”具体会读写到同一个文件么? 如果两台服务器都在写同一个文件,以谁为准?怎么同步?

    另外就是写的过程中可能会被读么?读到不完整文件会有什么问题么?
    vivisidea
        42
    vivisidea  
       212 天前
    我会优先考虑对象存储,比如 S3 、MinIO ,其次会考虑 NFS 、ceph 、glusterfs 这些方案
    mayli
        43
    mayli  
       207 天前
    @nuk 所以是穷人的方案
    spediacn
        44
    spediacn  
    OP
       203 天前 via iPhone
    一直忙着部署,没空上来看一下,今天来看居然有好多!感谢大家的建议,我列一下我的场景:

    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 的冗余策略测试一下,再和大家汇报
    spediacn
        45
    spediacn  
    OP
       183 天前 via iPhone
    @0superx0 主要每一台都有本地硬盘,不用会感觉浪费。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1012 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 18:46 · PVG 02:46 · LAX 10:46 · JFK 13:46
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.