这是一个创建于 49 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题所述，目前正在了解对象存储（ S3 ），看了很多相关开源软件，最后剩下 SeaweedFS 和 CubeFS 。
虽然两者都支持 K8S 部署，但是我不会使用 K8S ，毕竟就我一个人维护，普通的二进制可执行程序就可以。总体感觉部署 SeaweedFS 要比 CubeFS 简单些，而一个人维护 CubeFS 要复杂不少。
有在生产环境用过 SeaweedFS 和 CubeFS 的小伙伴吗？
这两者部署、维护、稳定性如何？
又或者还有其他推荐的？
想听听大家的想法。
 |
1
ala2008 49 天前
最省事的就是上云，阿里 oss 腾讯 tos 这些。自建和维护麻烦的很，用过 minio
|
 |
2
freebugnj 49 天前
我用 ceph 还可以，用成熟版本配置成熟硬件，维护量不大
|
 |
3
xjh1024 49 天前
七牛云、阿里 OSS 、自建 minio
别搞那些，一个人维护，集群 minio 就行 |
 |
4
defunct9 49 天前
必须是 minio ，没别的选择
|
 |
5
sundev 49 天前
minio 最近开源功能收紧，需注意
|
 |
6
clf 49 天前
minio 老版本的？
|
 |
7
carmark 49 天前
SeaweedFS 主要还是图片或其他非经常修改的对象，如果经常更改，可能并不如 minio 功能完善。
|
 |
8
guanyujia5444 49 天前
生产环境，存储这种底层的东西，最好用公有云，如果不行就采用多服务器集群部署，千万别弄容器化、k8s 部署，到时死都不知道咋死的
|
 |
9
niz OP  1
各位的建议已收到，感谢。目前基于数据安全的考虑，不会使用公有云 oss 这种的服务。所以更倾向于自建多服务器集群部署。
minio 最开始就看过了，软件协议商用不友好、许可证又太贵了（年费估计七十万）。另据说前几天 minio 删减了 WebUI 的相关功能。 所以目光才转向 SeaweedFS 。刚才看了同程旅行对象存储使用 SeaweedFS 的案例，感觉还不错。 https://mp.weixin.qq.com/s?src=11×tamp=1749694141&ver=6047&signature=ZKsRdZox-D96YFSr3Frsk5mdgStIKdJYSIR2sN95uLxgseB1CnAx8ZlGzjjI3SHGOv5FUkgtMzuF1INJn48vNVQGFEaZOOpOSWGfhBV-tZEZlFl*Vv-BJdJoE4j6*5GG&new=1 |
 |
10
chocotan 48 天前
seaweedfs 适合大量小文件，性能是 minio 的几十倍。
minio 适合大文件。它是个黑盒，一旦量大了就懵逼，没任何流量的情况下都能给你磁盘 io 打满。 |
 |
11
linuxsir2020 48 天前
OpenStack Swift 对象存储用了挺久一段时间, 种种原因最终迁移到 AWS S3
|
 |
12
wjx0912 48 天前
seaweedfs 唯一的缺点是不支持版本管理
|
 |
13
knives 48 天前
如果需要使用 swaweedfs 纠删码功能，建议先仔细测试一轮。几年前做过一轮测试，功能不是太稳定，容易产生冗余的脏数据，需要做额外的监视和维护工作。不过这个模块最近已经被大改了一轮，看日志应该是比之前好些了。
|
|
14
niz OP 下午又写了个简单的测试页面，用来测试 seaweedfs 。
https://github.com/luminecs/seaweedfs-uppy-manager https://github.com/luminecs/seaweedfs-script |
|
15
niz OP |
|
16
chocotan 48 天前
@niz
我们用 seaweedfs 的一些坑： 1. seaweedfs 的 EC 坑很多——比如不支持 ttl （提了 pr 现在支持了），并且如果用机械盘的话，EC 速度是赶不上文件上传的速度的。我们后来参考 go 源码另外开发了 java 的 ec 任务。还有诸如 EC 后文件删除无法释放空间等问题。 2. 内部大量用到了锁，有几个地方有性能问题，还有并发读写 map 导致 panic 崩溃的问题。 3. 在大量文件写入的情况下，master 节点会突然触发选举，且其选举非常慢——超过 30 秒，且保证可用性的话需要准备两个集群 4. 有大量文件写入、新 volume 生成频繁的时候，创建 volume 的速度赶不上文件写入的速度。 |
|
17
niz OP @chocotan 感谢分享这些有价值的经验，接下来可以带着这些问题看文档+实践了。另外有几个问题需要咨询下：
1. 这些坑大概是在 seaweedfs 哪些版本上出现的？不知道最新版本是否已经解决其中某些问题。 2. 针对 EC 速度是赶不上文件上传的速度，你们开发了 java 的 ec 任务，把 seaweedfs 默认的 ec 接管了？这部分 java 代码有开源吗？ 3. 针对 EC 后文件删除无法释放空间，请问你们是如何处理的？ 4. 既然 EC 有这么多潜在问题，是否可以用副本复制代替 EC ？你们有测试过副本复制吗？ 5. 锁的问题估计需要作者来处理了，短期内很难了解源码 6. master 选举慢的问题，需要准备两个集群指的是两个 master 集群？这两个 master 集群后面还是使用相同的 volume server 、filer server 、s3 server? 7. 针对创建 volume 的速度赶不上文件写入的速度，不知道 weed 有没有预创建 volume 的配置。 目前文档还没有看一遍，理解比较浅，还请不吝赐教啊。 |
|
18
chocotan 48 天前
* 坑主要与 EC 有关，其中一部分功能提交 pr 给官方了。我们是从去年这个时候 fork 出来做的二次开发，期间经历了多次集群突然崩溃、突然选举导致服务中断等问题，直到现在才勉强稳定运行。后来我们试图合并官方的代码，发现创建新 volume 的功能疑似被其他人负优化了，就没继续合并了。
* EC 后文件被删除了空间无法释放的问题，我们目前是简单的做了判断——判断 volume 里所有文件都被删除后再删除该 volume 的文件 * Java 版的 EC 我们目前暂时没有精力单独开源出来，等集群稳定后再考虑。 * 一个集群的 master 节点数量设置成 3 个，5 个会增加超时概率，超时了就会触发选举。我们是搭建了两个完全独立的集群，一个无法提供服务的时候会自动切换到另一个 * weed 有预创建 volume 的，但是当 collection 数量过多+高并发的时候，由于它创建 volume 是串行处理、且每创建一个 volume 耗时在百毫秒左右，会导致一部分请求超时（ 10 秒超时）。业务应用需要做重试。 * 副本复制可以，如果空间足够的话建议不要做 EC 。 ========= 就在刚刚，我们又发现了一个极端情况下返回上传成功实际文件上传失败的 BUG （与 EC 有关），造成一集群近几个月约 10%共上百 TB 的文件丢失了，这个 BUG 仍然存在于官方的最新版里。 @niz |
 |
19
followad 48 天前 via iPhone
我都是 webdav
|
Select Language