V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
heiya
V2EX  ›  程序员

对搭建 MinIO 对象存储的一些疑问

  •  
  •   heiya · 1 天前 · 4010 次点击

    背景

    • 最近对已搭建的 MinIO 做了一些性能测试。服务为单实例部署,服务器配置为阿里云 ECS 实例 2c8g 、100Mbps 外网带宽、ESSD Entry 硬盘。
    • 在文件大小为 1000kb 、并发为 10 、持续时间 300s 、90%读文件的维度上,测试结果是(以读文件数据为例):平均响应时间是 606ms ,服务器处理时间是 29ms ,吞吐量是 16.35op/s ,服务器带宽被完全占满,cpu ,内存,硬盘各项指标均正常。
    • 由此可见主要的瓶颈是服务器的外网带宽,于是想到组建 MinIO 集群的方法提高吞吐量。

    疑问

    • 问题随之而来。假设采用四台上述相同配置的 ECS 实例组成集群,使用单实例 Nginx (官方推荐的负载均衡器之一)做负载,理论上在 MinIO 层面带宽比单实例的带宽会高,吞吐量也会随之提高。但是否部署 Nginx 所在的服务器的带宽(假设也是 100Mbps )会是性能瓶颈?
    • 如果是性能瓶颈,那我现在想到的办法是做成 Nginx 集群,然后使用更高层的负载均衡器(例如 DNS 轮询、F5 等)将流量分发到不同的 Nginx 服务器上。不知道我这种想法是否正确?
    • 如果我的想法不正确,请不吝赐教。
    72 条回复    2025-03-26 22:48:45 +08:00
    hefish
        1
    hefish  
       1 天前   ❤️ 13
    minio 建公网上啊。。。 图啥?
    minio 用 nginx 负载均衡啊? 图啥?
    heiya
        2
    heiya  
    OP
       1 天前   ❤️ 33
    @hefish 我觉得你要不想赐教可以不答,一味的反问衬托自己有多么精通只显得你素质低下。在这种社区有你这样的回答真是拉低档次。话都不会好好说吗?我图啥?我图明天多吃俩馍!
    sujin190
        3
    sujin190  
       1 天前 via Android
    既然带宽是瓶颈,说了半天也没见你说是外网带宽被占满了还是内网带宽小猫了,内网占满多机器当然有效果,外网当然是花钱了,话说为啥不用七牛又拍或者 oss ?从带宽或者存储成本可用性都更便宜吧
    Zhuzhuchenyan
        4
    Zhuzhuchenyan  
       1 天前
    1. 假设只有一个 Nginx 做出口,Nginx 出口的带宽会成为新的瓶颈
    2. 第二个思路大体是正确的,不过需要注意的是如何尽可能均衡的将负载给到多个入口
    CHS
        5
    CHS  
       1 天前
    @heiya 既然你不喜欢别人的回复,那你发出来问的意义何在?你自己都说了瓶颈是带宽,那用 Nginx 集群又有什么用?
    heiya
        6
    heiya  
    OP
       1 天前
    @sujin190 嗯嗯,在背景中的第三条中说明了是外网带宽是瓶颈。实际上目前是 OSS+MinIO 都使用了,OSS 中存储的一些热点资源、静态文件、小文件等,MinIO 存了一些大文件,比如动辄就几百 M ,一个 G 多。这么用的原因是当时我看到 OSS 忙时外网流出收费的价格是 0.50 元/GB ,比 ECS 的流量费贵。
    MADBOB
        7
    MADBOB  
       1 天前
    都用阿里云了为啥不直接用 OSS ?又方便可靠性肯定比自己搭的高,容量和速度也不用担心。MINIO 一般自己内网/有自己物理服务器搭比较适合。ECS 按流量 0.8/g ,OSS 0.5/g
    heiya
        8
    heiya  
    OP
       1 天前   ❤️ 9
    @CHS 你的逻辑十分混乱。首先我从未说过不喜欢别人的回复,请看一下他回复的内容。社区指导规则中明确指出:友好互助,保持对陌生人的友善。用知识去帮助别人。他的回答既看不出友善,更谈不上帮助,短短两行充斥着不屑。就这种严重背离社区原则的回答你竟然还帮着说话,足见你没什么正确的价值观。 其次,“你自己都说了瓶颈是带宽,那用 Nginx 集群又有什么用?” 这句话感觉你基本没理解我的疑惑在哪,这很可能是我的语言表达能力有问题,不怪你。
    heiya
        9
    heiya  
    OP
       1 天前
    @Zhuzhuchenyan 感谢回复,所以我现在的疑惑点是有哪些更高层的负载均衡器可以将流量分发到不同的 Nginx 服务器上,F5 在云服务器是貌似使用不了,DNS 轮询不能保证完全均匀。
    heiya
        10
    heiya  
    OP
       1 天前
    @MADBOB 感谢回复,目前是 OSS 和 MinIO 都在使用,现在 MinIo 是在阶段性尝试,只有一小部分数据在上边。我刚才翻了一下文档,确实是 ECS 按流量 单价:0.80 元/GB 。
    Mithril
        11
    Mithril  
       23 小时 15 分钟前   ❤️ 3
    我们之前用 Ceph 试过,并没有比云厂商的 OSS 服务更好。你节省的那点流量费,一次炸锅的人工和损失就全兜回来了。

    主要是你要做多层负载均衡,这系统架构就简单不了。你这好几台 ECS 要搞监控,报警,维护,等等一系列东西下来成本并不低。而且这对于你们来说也不是核心系统,你也要考虑花大精力去调查维护这东西到底值不值。

    我觉得你有精力折腾这个,只为了节省这么点流量费,不如花点时间去跟云厂商要点折扣。或者把这些大文件存储业务单独换到别的更便宜的厂商去做更靠谱一点。
    Mithril
        12
    Mithril  
       23 小时 6 分钟前   ❤️ 2
    另外 MiniIO 还有 License 问题,你要考虑你的情况是否适用他那个 AGPL 的 License 。因为你这种架构本质上是在云平台上使用 MiniIO 搭建了对象存储服务,并提供给你的客户(如果你客户是直接拿链接从这个服务里下载文件的话)。

    那么根据 AGPL ,你需要公开相关的所有代码。

    本身 AGPL 就不是个很严谨的 License ,MiniIO 选择它也就是看中了这点,好方便他们推自己的商用 License ,所以大家当时都在骂。如果你的公司比较看重法务合规这块,那还是别省这么点流量费了。
    keller
        13
    keller  
       22 小时 19 分钟前
    要做存储 可能带宽的单位要换成 G
    erhandsome
        14
    erhandsome  
       22 小时 4 分钟前
    @heiya #9 你需要的是云厂商的负载均衡( SLB )服务
    kk2syc
        15
    kk2syc  
       21 小时 38 分钟前
    搞 minio 又配上 nginx 确实很迷惑行为,但是人家说的没错,接受批评
    Int100
        16
    Int100  
       20 小时 46 分钟前 via iPhone   ❤️ 1
    一楼虽然冲了点,但还是有价值的.
    存储放公网,你采取了什么安全措施吗?
    对于存储来说,可靠、安全、冗余这些优先于性能瓶颈.

    其次,一楼这种表达方式隐含的不理解,也是因为 op 没有说明原始需求. 目测 op 只是弄来学习研究的,如果是这样,那怎么折腾都可以了.
    chinanala
        17
    chinanala  
       18 小时 22 分钟前
    分享下我们在用的低成本自建 OSS 方案:
    阿里云买 2 台轻量 200M 机器做前端入口,普通 ECS 带块大硬盘,两者之间走内网。
    只需要几百块,就能得到不限流量大带宽(晚高峰限速)大空间的自建存储,比直接用 OSS 要买好几个套餐包划算很多。
    laminux29
        18
    laminux29  
       16 小时 55 分钟前   ❤️ 11
    社区就是这样,你是来提问的,大家不是你家长,不会惯着你。1 楼已经说的很明白了,你听不懂还嫌人家态度不好。

    MinIO 、CephFS 之类的东西,本来就是低成本的线下内网部署,你在高溢价的云服务器上部署,根本不划算,而且这种云服务器最贵的就是外网带宽。就算要用云服务,直接去买云对象存储会更好,所以 1 楼才问你:图啥。
    kosgug
        19
    kosgug  
       16 小时 19 分钟前 via iPhone
    最近我一个项目确实在公网搭建了 minio ,原因是未来存在本地私有化的可能性,直接迁移数据即可,不用改项目代码引用的 SDK ,当然有可能 SDK 兼容我没科普过
    chaoschick
        20
    chaoschick  
       16 小时 5 分钟前
    直接 买 4 台 ECS 组集群测试就行,实践是检验真理的唯一标准
    superchijinpeng
        21
    superchijinpeng  
       15 小时 54 分钟前 via iPhone
    1 楼说的不明白吗
    wunonglin
        22
    wunonglin  
       15 小时 31 分钟前
    @heiya #10 另外,阿里云的 OSS 搭配阿里云的 CDN ,我记得价格最低可以节省到 0.15 左右。自建何必
    hnbcinfo
        23
    hnbcinfo  
       15 小时 27 分钟前   ❤️ 1
    一楼回复没问题,并没有恶意,只是调侃的方式建议你别这么搞。你又何必这么玻璃心呢。
    你自己认真想一想,心里回答一下一楼的问题,难道不觉得人家的建议很有价值吗
    vopsoft
        24
    vopsoft  
       15 小时 19 分钟前 via Android
    MinIO 集群能在线扩容吗
    wy315700
        25
    wy315700  
       15 小时 15 分钟前
    @heiya #6 ECS 的流量费我没记错是 0.8 元/G 怎么也轮不到比 OSS 贵。而且为啥不套 CDN 呢
    songyoucai
        26
    songyoucai  
       15 小时 8 分钟前
    MinIO + CDN
    kzfile
        27
    kzfile  
       15 小时 2 分钟前
    云厂商的 oss 综合成本比自建的低,实在想不出自建的必要性,除非有特殊的定制业务?
    NessajCN
        28
    NessajCN  
       14 小时 41 分钟前
    @heiya 1 楼说得对
    而且人家也没说啥不好听的,你应激什么?
    明明最不友善的就是你自己
    本来还想跟你好好讨论的,一看你这臭嘴那我也不客气了

    「奇葩需求没事找事,建议直接买百度云会员」
    hefish
        29
    hefish  
       14 小时 40 分钟前
    我觉着还是用在内网吧。。
    我觉着能用 oss 之类的,还是 oss ,自建需要强大的能力和精力。 当然,一两个节点也许是可以的。 不过一两个节点不如多搞几块盘跑单机啊。。。
    Karte
        30
    Karte  
       14 小时 26 分钟前   ❤️ 1
    说实在的, 有 OSS 不用非得自己搭. 图啥啊?

    自建存在以下问题:
    - 安全措施 (即使 MINIO 有账户校验和链接校验, 但只要有漏洞数据就全丢了)
    - 磁盘限制 (云厂商提供的硬盘是按照容量分配 IOPS 的, 你容量越小, IO 越小. 存个大文件直接把 IO 吃满了)
    - 带宽限制 (你也说了带宽瓶颈了, 既然你是对外提供服务, 为什么不选择 CDN ?)
    - 高可用 (自建没有现成的好)


    PS: 如果只是出于学习的目的, 那尽管折腾.
    tclm
        31
    tclm  
       14 小时 22 分钟前
    我以前采取的是 OSS+CDN 替换本地自建 MinIO ,主要带宽成本太高,而且容易成瓶颈,自己的运维硬件还要考虑容灾,多备,还不如全走云。
    clf
        32
    clf  
       14 小时 20 分钟前
    我们这边用下来。建议直接 CDN+OSS 的方案,可能成本比你买服务器的硬盘便宜。如果这么搞的话,你甚至可以把外网带宽缩了,api 访问用不到这么大的宽带。
    layxy
        33
    layxy  
       14 小时 20 分钟前
    1.有瓶颈
    2.可行
    3.如果你 2 可以做,也可以把 minio 直接暴漏公网,可以节省 nginx 集群资源,这套方案下来我感觉成本还是使用云厂商的对象存储比较好
    defunct9
        34
    defunct9  
       14 小时 20 分钟前
    这么多人都支持用云产品,我提个反例。aws 的极光数据库,真的拉跨,又贵吧,还它瞄的恢复又慢。自建的话便宜多了。所以我支持自建,总以为它们水平很高,结果啪啪打脸。
    billbob
        35
    billbob  
       13 小时 58 分钟前
    怕贵,你可以买 OSS,走内网,买个 ES 代理走固定带宽.

    你如果是给公司弄的,只能说你不专业,坑老板

    你给你自己弄,那你随便.
    viking602
        36
    viking602  
       13 小时 27 分钟前
    我们用 minio 都是在内网 公网都是 OSS 如果一定在云上那还是用 OSS 最好
    heiya
        37
    heiya  
    OP
       13 小时 24 分钟前
    @Mithril 感谢回复,您的回复对我而言十分有用。另外,如果是把 MinIO 部署到内网上,也需要公开相关的所有代码吗?
    heiya
        38
    heiya  
    OP
       13 小时 19 分钟前
    @kzfile 是的,这个项目有私有部署的要求,在私有部署的机器上不通外网,于是采用了 MinIO 的方案。
    heiya
        39
    heiya  
    OP
       13 小时 17 分钟前
    @erhandsome 好的 谢谢
    heiya
        40
    heiya  
    OP
       13 小时 15 分钟前
    @kosgug 我这边也是公网部署和私有化部署
    heiya
        41
    heiya  
    OP
       13 小时 13 分钟前
    @laminux29 说真的,我不是不能接受批评的人,如果他在反问之后再追加你说的这些,我会谢谢他。最后,谢谢你的回复,对我而言很有价值。
    heiya
        42
    heiya  
    OP
       13 小时 3 分钟前
    @chinanala 我现在的方案也是两台 ECS ,一台部署前端和 Nginx ,Nginx 转发到了另一台内网相通部署了 MinIO 的机器上。找这么说,咱们的方案是不是一样的?
    heiya
        43
    heiya  
    OP
       13 小时 0 分钟前
    @NessajCN 你说我臭嘴我同意,你要说他说的好听我不认可。你看别人的回答什么叫友好互助,良好沟通。
    abc0123xyz
        44
    abc0123xyz  
       12 小时 55 分钟前
    大厂 100m 公网可不便宜
    heiya
        45
    heiya  
    OP
       12 小时 52 分钟前
    @Karte 感谢回复,这对我非常有价值。我现在已采用的有两种方案,一种是公网部署,采用 OSS+MinIO ;另一种是私有化部署,不通外网,采用 MinIO 。另还有一个问题想咨询一下,如果一个文件几百 M 、上 G ,采用 CDN 是否合理呢?
    heiya
        46
    heiya  
    OP
       12 小时 52 分钟前
    @layxy 好的,谢谢
    heiya
        47
    heiya  
    OP
       12 小时 50 分钟前
    @clf @layxy 感谢回复。那如果一个文件几百 M 、上 G ,采用 CDN 是否合理呢?
    chinanala
        48
    chinanala  
       12 小时 43 分钟前
    @heiya #42 本质上不同,因为如果没有低价的大带宽机器,我就不会自建 MinIO 。如果只是两台常规的服务器,那就没必要一台搭建 Nginx 一台搭建 MinIO ,没有任何优势。一台大带宽做入口,一台大硬盘做业务,这种搭配多好
    heiya
        49
    heiya  
    OP
       12 小时 37 分钟前
    @chinanala 我明白了,感谢。这两天在阿里云上也在找大带宽的机器,结果没找到。另外,有一个点与#12 楼说的一致,在公网上部署 MinIO 需要公开该项目的所有代码,如果不想公开需要商业授权;在内网不需要。您这边是怎么解决这个的呢?
    pengtikui
        50
    pengtikui  
       12 小时 28 分钟前   ❤️ 1
    好奇觉得一楼没问题的人都是啥人,平时说话都这么阴阳怪气吗
    ryan4290
        51
    ryan4290  
       12 小时 3 分钟前
    @billbob 对,你这个方案不错。
    mx1700
        52
    mx1700  
       12 小时 0 分钟前 via Android
    如果你仅仅是因为 OSS 外网流量价格高而部署 MinIO ,那不去直接 ECS 反代 OSS ,OSS 内网流量应该是免费的。
    skiy
        53
    skiy  
       11 小时 37 分钟前
    我看海外很多 devploy 之类的平台,很多都是用 Traefik 。
    wunonglin
        54
    wunonglin  
       11 小时 36 分钟前
    OSS 内网是免费的。。。仅仅收存储费
    Mithril
        55
    Mithril  
       11 小时 23 分钟前   ❤️ 1
    @heiya 那倒是不需要。GPL 系的核心是你的客户要能拿到代码,内网部署你自己就是你的客户了,自然无所谓。

    但如果你是在客户的内网部署,按理说也需要。但和 SaaS 不同,你能私有化部署的客户相当于是筛选过一遍的,一般没这么闲的去起诉你要代码。只是当你的客户要在你这产品的基础上发布他们的产品时,他也要考虑这个问题。

    很多人都会忽略掉,这种风险以及研究清楚这些问题要花的时间和精力其实也是一种成本。而且从 Github 的 Issue 来看,MinIO 这公司在这项上还是比较激进的。你甚至去提个 issue ,都会警告你拿它商用可能违反 license 。

    https://github.com/minio/minio/discussions/13571#discussioncomment-1583482

    不过这不重要,毕竟还有 Swift 什么的一大堆的替代选项。总之一个可靠性高,性能不错的存储系统的复杂度并不低,维护成本也很高。所以只是建议你在考虑成本的时候除了流量费以外把这些也算进去。
    当然你要给客户私有化部署那就没办法了。你在你的 App 端做 S3 接口,然后去客户那里根据数据量选解决方案就行。比如说小型客户不在乎 License 直接跑 MinIO ,大型客户,有自己专业 IT 团队的,让他们自己去部署 Ceph 或者 Swift 。

    当然还有个更好的选项,让客户直接买带 S3 API 的存储产品。毕竟你存储量上去以后肯定要买专门的存储设备,Dell 一类的厂商,有直接带 S3 API 的存储服务器。这样维护什么的问题直接甩给 Dell 就好了,毕竟需要买这些设备保存重要数据的客户,也不差那点服务费。
    wangyzj
        56
    wangyzj  
       11 小时 19 分钟前
    minio 没有那种流量 redirect 方式吗
    chihuokobe
        57
    chihuokobe  
       10 小时 41 分钟前
    @kk2syc 为什么很迷惑?难道你玩的是单机版?官网集群模式推荐 Nginx 和 HAProxy 你没看到?
    SingeeKing
        58
    SingeeKing  
       10 小时 35 分钟前
    minio 部署在云服务上,硬盘成本远远比 OSS 高吧
    wxw752
        59
    wxw752  
       10 小时 22 分钟前
    @pengtikui #50 如果是对一个初学小白,不应该像一楼那样讲话。

    但是对 OP 这类 ECS 、OSS 等各类云服务长期使用的人,还会搞阿里云 ECS 部署 minio 这样奇葩操作,我觉得一楼的反应没问题。把内心疑虑不加包装的发出来了而已
    wy315700
        60
    wy315700  
       10 小时 19 分钟前
    @heiya #38 云服务的 OSS 都是内网联通的。而且内网流量免费。访问文件无需外网
    kk2syc
        61
    kk2syc  
       10 小时 6 分钟前
    @chihuokobe 没看到过官方推荐,麻烦贴上官方地址让我学习一下
    heiya
        62
    heiya  
    OP
       9 小时 43 分钟前
    @Mithril 您说的非常有道理,这种没有拿到商业授权而产生的隐形风险让我产生了逐渐去除部署在公网 MinIO 的想法。对于私有化部署的方案,我在认真研究您给的指导意见后再决定是否继续使用 MinIo 还是再用别的。最后,再次表示感谢,作为一个后端之前只使用了 OSS ,对这方面了解的比较少,这些想法让我了解到了很多关于存储方面的知识。
    heiya
        64
    heiya  
    OP
       9 小时 31 分钟前
    @wy315700 好的,谢谢。我看到了,也去官网找到了相关的文档。
    @billbob 感谢给的思路,这个对我很有用。作为一个后端我对这方面确实了解的很少。
    kk2syc
        65
    kk2syc  
       8 小时 38 分钟前
    @heiya 为了支持 MinIO 而配置防火墙或负载均衡器不在此过程的范围内。Nginx 服务器反向代理 MinIO 配置 参考提供了一份基本配置,可将 NGINX 用作反向代理,并配置了基本的负载平衡。
    Karte
        66
    Karte  
       7 小时 33 分钟前
    @heiya 首先大文件会占用过大的磁盘 IO, 如果云磁盘容量过低则 IOPS 也会很低.

    在没有性能要求的情况下, 且数据库和 MINIO 不属于同台机器是可以使用 minio 的. 如果有性能要求, 那磁盘 IOPS 则会是瓶颈. 既然如此可以试试内网 OSS, 或者内网 S3. 内网的费用相对便宜实惠.


    对于大文件是否需要 CDN 这个问题, 你得先明白 `CDN (Content Delivery Network)` 是什么. CDN 是一个内容分发网络, 将你提供的资源尽可能的靠近用户侧 (实际请求的用户, 例如 B 站的视频资源), 同时提供海量带宽.
    如果你的文件不会频繁下载, 或者根本不会下载, 那 CDN 就不需要了. CDN 引入只会徒增成本 (资源成本 + 流量成本).
    bajitanglang
        67
    bajitanglang  
       6 小时 57 分钟前
    @chinanala 想请教下,这个服务器的配置是什么呢?几核几 G 的呢?我现在的项目也打算自建 OSS 方案,老板的理由是,相关数据不能用阿里云的产品,都是自己开源项目搭建
    clf
        68
    clf  
       6 小时 57 分钟前
    @heiya #47 文件在 OSS 里反正可以根据类型选择走 CDN 还是走服务器宽带,但我们这里大部分是全走 CDN ,因为服务器固定带宽更贵,且闲置浪费的更多。
    lucasdev
        69
    lucasdev  
       6 小时 52 分钟前
    看起来完全不需要自建 MinIO ,直接用 CDN + OSS 即可

    看到的几个问题:
    1. 部署到内网不需要公开源码,MinIO License 限制的是提供公网服务,主要针对云厂商那种的。
    2. 使用阿里云 CDN 可以内网回源 OSS ,大大减少带宽费用。“那如果一个文件几百 M 、上 G ,采用 CDN 是否合理呢?”,更适合了,CDN 支持的 Range 回源可以减少 OSS 的开销。
    3. 云服务器自建 MinIO 可能会存在很多问题,即便你带宽解决了,高并发下的 ECS 磁盘 IO 也可能会瓶颈。
    windyboy
        70
    windyboy  
       6 小时 11 分钟前
    minio 不是让你用物理硬盘吗?
    你从头到位的是虚拟机,虚拟硬盘
    chinanala
        71
    chinanala  
       4 小时 16 分钟前
    @bajitanglang 这种是阿里和腾讯今年新出的 200M 轻量共享大带宽服务器,主打不限流量不限速(但高峰期邻居多不保证网速),最低配 2C2G200M 每月 45 ,具体可以在腾讯云和阿里云轻量云控制台那里点击新建购买就能看到配置。我是只为了这个三网 BGP 而且宣称 200M 的大带宽作为入口,同地域下买别的机器做计算,两台机器走免费的内网互联,这样速率也有,计算也有。
    eephee
        72
    eephee  
       1 小时 4 分钟前
    @pengtikui #50 +1
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2520 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 39ms · UTC 15:52 · PVG 23:52 · LAX 08:52 · JFK 11:52
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.