对象储存选型

需求

1.很多对象存储无法指定对象名称, 只能由系统生成. 为了便于使用和理解, 需要对象存储 支持 自定义对象名
2.对象存储 需要权限管理,
3.需要有扩容方案
4.需要由备份能力
5.需要支持 HTTP 下载
6.有web 管理界面
7.接入完善, SDK 生态完善
8.开源
9.使用广泛, 社区活跃
10.产品成熟
11.文档完整丰富
12.开发团队有丰富经验
13.安装维护简单, 最好能对接k8s 云原生的方式

可选方案对比

经过以上条件过滤, 部分符合条件的知名方案为

其中 ambry 无法自定义对象名, 排除
swift 生态, 云原生对接, 接入sdk等不够成熟, 排除
StorageGRID 经过咨询 netapp , 无法使用目前装在上海机房里的netapp, 需要购买新设备, 机房已无空间, 故排除

推荐方案对比

minio:
集群搭建成功后, 不支持横向扩容, 不能改变集群规模, hash 是固定的, 以简化集群维护成本
扩容方案有两种:
对等扩容: 如果原集群4台机器, 扩容时必须增加4台, 集群最大32台机器
federation扩容: 创建新集群, 引入etcd, 将多个集群 组成一个逻辑上的大集群

NAS网关功能 可以直接使用NetApp 最为后端存储, 转换为对象存储的协议, 可靠性靠NetApp保证,

Ceph:
可以在一个集群内增加节点, 增加节点后 需要rehash , 以及数据迁移到新硬盘, 带来维护成本较高