QuXiao's Blog

Life && Tech && Thoughts

File Server 调研 —— minio

Written on

在最近的私有化部署中,特别是有上层业务的系统,会有很多将图片、视频截帧保存之再进行访问的需求。在公有云中,这其实就是各个对象存储系统的功能,例如阿里云的 OSS、七牛云的 Kodo。但是在私有云环境下,网络环境一般是比较苛刻的,甚至会由于项目的背景,导致私有化服务是需要部署在一个完全隔离外网的环境中,使用公有云的服务是比较困难的。那么,如果把自己的公有云存储系统进行私有化部署呢?通常也是不实际的。因为绝大多数情况下,私有化部署一套 Kodo,已经超出了本身部署私有化服务的代价,无论是前期的机器成本、还是后期的运维维护成本。所以,需要寻找一个可私有化部署的对象存储系统,需要满足:

  • 部署维护简单,最好是开箱即用
    • 不希望部署这个对象存储系统比部署本身要交付的服务困难
  • 服务对于资源的占用要尽量少

  • 即支持前期的单节点部署,也支持集群部署
    • 前期 POC 阶段,主要是快速展现服务的能力
    • 后期系统规模扩大,需要考虑服务的稳定性和容灾能力
  • 有一定的二次开发的机制,方便接入其他公有云的接口
    • 可能是客户(或者集成商)的需求,因为他们的研发之前就是按照某个对象存储系统的接口开发的
    • 可能会和其他厂商服务,由对方提供存储系统,我们需要能够尽快适配

最后经过一番搜寻,发现了一个开源项目—— minio,看起来比较符合上述的需求。

介绍

优点

  • 对象存储,兼容 Amazon S3 协议
  • 安装运维相对简单,开箱即用
  • 后端除了本地文件系统,还支持多种存储系统,目前已经包括 OSS,可以参考支持七牛 Kodo (参考1
  • 原生支持 bucket 事件通知机制 (参考2
  • 可通过多节点集群方式,支持一定的高可用和数据容灾
  • 有 web 管理界面和 cli,可以用于测试或者管理
  • 公开 bucket 中的数据可以直接通过 HTTP 获取

缺点

  • 没有经过长时间的使用和验证,稳定性不确定
  • 没有官方的 HTTP 协议 API,只能使用 SDK
  • 不支持动态增加节点 (不过对于目前私有化部署场景,需求也不强)

启动样例

docker run --rm -d -p 9888:9000 --name minio \
        -e "MINIO_ACCESS_KEY=xxxx"   -e "MINIO_SECRET_KEY=xxxx" \
        -v /disk1/data:/data   -v /mnt/config:/root/.minio \
        minio/minio server /data

web 管理界面

之后就可以添加 bucket 、设置访问权限、上传文件等操作了,你如果用过市面上的对象存储系统的话,基本上是不需要什么学习成本的。

性能测试

采用了 intel 开源的测试对象存储系统的性能测试工具对 minio 进行测试

性能测试工具界面:

这个工具采用 master-worker 模式,通过配置文件去定义测试的步骤,例如用多大的并发读取/写入多少份数据,每个数据的大小的规则是什么。

测试结论

测试环境

  • CPU: Intel(R) Xeon(R) CPU E5-2650 * 48 核
  • 内存:125 GB
  • 磁盘:SSD 盘 / SATA 盘
  • 网卡:千兆网卡

测试项

写入

256 KB 数据 * 128 并发写入

256 KB 数据 * 512 并发写入

读取

256 KB 数据 * 128 并发读取

256 KB 数据 * 1024 并发读取

从直接测试的结果来看,在跨网络的情况下,基本上是打满网卡的节奏;在本地环境下,也是基本上和直接磁盘操作的性能持平。当然,目前测试的环境还是单节点的数据存储,所以多节点分部署部署的情况下,应该不会有这么高的性能,不过至少从目前私有化部署的规模和部署节奏来看,还是可以满足需求的。

comments powered by Disqus