minio技术选型与部署测试

引言

MinIO号称是目前速度最快的对象存储服务器。在标准硬件上，对象存储的读/写速度最高可以高达183 GB/s和171 GB/s。对象存储可以作为主存储层，用来处理Spark、Presto、TensorFlow、H2O.ai等各种复杂工作负载以及成为Hadoop HDFS的替代品。即为机器学习、分析和应用程序数据工作负载构建高性能基础架构。

技术选型（为什么选择minio）

本节想探讨的是我为什么会选择minio，或者往更大一点的方向上讲，为什么要使用对象存储，根据我查到的资料以及个人理解，下面做一个初步的介绍。

对象存储与文件存储

这个问题，在知乎有个很详细的解析，很多大佬都写出了自己的理解，我在这里挑一部分表述：块存储、文件存储、对象存储这三者的本质差别是什么？

• 对象存储（键值数据库）：接口简单，一个对象我们可以看成一个文件，只能全写全读，通常以大文件为主，要求足够的 IO 带宽。
• 块存储（硬盘）：它的 IO 特点与传统的硬盘是一致的，一个硬盘应该是能面向通用需求的，即能应付大文件读写，也能处理好小文件读写。但是硬盘的特点是容量大，热点明显。因此块存储主要可以应付热点问题。另外，块存储要求的延迟是最低的。
• 文件存储（文件系统）：支持文件存储的接口的系统设计跟传统本地文件系统如 Ext4 这种的特点和难点是一致的，它比块存储具有更丰富的接口，需要考虑目录、文件属性等支持，实现一个支持并行化的文件存储应该是最困难的。但像 HDFS、GFS 这种自己定义标准的系统，可以通过根据实现来定义接口，会容易一点。

按我的理解，文件存储与对象存储的本质区别为分布式文件存储文件组织方式为目录树，即Linux中tree的格式，对象存储采用的是扁平的组织方式；这三者的本质差别是使用数据的“用户”不同：块存储的用户是可以读写块设备的软件系统，例如传统的文件系统、数据库；文件存储的用户是自然人；对象存储的用户则是其它计算机软件。

对于块存储来讲，虽然固然延迟很低，通过了Raid与LVM等手段，对数据提供了保护，并且并行写入的方式，延迟能达到10ms，但造价高，不利于不同操作系统主机间的数据共享等问题同样有所隐患。对于文件存储来讲，造价低，文件可以在不同主机间共享，并且使用FTP与NFS服务，可分布式，但是确有瓶颈，还是克服不了当文件变多后效率低的问题。

之所以出现了对象存储这种东西，是为了克服块存储与文件存储各自的缺点，发扬它俩各自的优点。简单来说块存储读写快，不利于共享，文件存储读写慢，利于共享。能否弄一个读写快，利于共享的出来呢。于是就有了对象存储。

对象存储可以理解为把文件分解成一个个对象进行存储，简单说就是存储文件会附加一段元数据，查询时寻找元数据然后定位到文件即可。打一个不准确但有助理解的比方，对象存储相当于在块存储的分块上加一个描述标签，增强了文件的可查询性便于管理。对象存储可以说结合了文件存储和块存储的优点，是存储的发展方向。是面向程序和系统的最优文件存储方式。

分布式存储对比

这里主要引用两篇博客，因为我并不可能对每个开源软件去进行尝试，当初也是对比着来，才进行选择。

盘点分布式文件存储系统

分布式存储系统对比之 Ceph VS MinIO

分布式存储对比：

文件系统	开发者	开发语言	开源协议	易用性	适用场景	特性	缺点
GFS	Google		不开源
HDFS	Apache	Java	Apache	安装简单，官方文档专业化	存储非常大的文件	大数据批量读写，吞吐量高；一次写入，多次读取，顺序读写	难以满足毫秒级别的低延时数据访问；不支持多用户并发写相同文件；不适用于大量小文件
Ceph	加州大学圣克鲁兹分校Sage Weil	C++	LGPL	安装简单，官方文档专业化	单集群的大中小文件	分布式，没有单点依赖，用C编写，性能较好	基于不成熟的btrfs，自身也不够成熟稳定，不推荐在生产环境使用
TFS	Alibaba	C++	GPL V2	安装复杂，官方文档少	跨集群的小文件	针对小文件量身定做，随机IO性能比较高；实现了软RAID，增强系统的并发处理能力及数据容错恢复能力；支持主备热倒换，提升系统的可用性；支持主从集群部署，从集群主要提供读/备功能	不适合大文件的存储；不支持POSIX，通用性较低；不支持自定义目录结构与文件权限控制；通过API下载，存在单点的性能瓶颈；官方文档少，学习成本高
Lustre	SUN	C	GPL	复杂，而且严重依赖内核，需要重新编译内核	大文件读写	企业级产品，非常庞大，对内核和ext3深度依赖
MooseFS	Core Sp. z o.o.	C	GPL V3	安装简单，官方文档多，且提供Web界面的方式进行管理与监控	大量小文件读写	比较轻量级，用perl编写，国内用的人比较多	对master服务器有单点依赖，性能相对较差
MogileFS	Danga Interactive	Perl	GPL		主要用在web领域处理海量小图片	key-value型元文件系统；效率相比mooseFS高很多	不支持FUSE
FastDFS	国内开发者余庆	C	GPL V3	安装简单，社区相对活跃	单集群的中小文件	系统无需支持POSIX，降低了系统的复杂度，处理效率更高；实现了软RAID，增强系统的并发处理能力及数据容错恢复能力；支持主从文件，支持自定义扩展名；主备Tracker服务，增强系统的可用性	不支持断点续传，不适合大文件存储；不支持POSIX，通用性较低；对跨公网的文件同步，存在较大延迟，需要应用做相应的容错策略；同步机制不支持文件正确性校验；通过API下载，存在单点的性能瓶颈
GlusterFS	Z RESEARCH	C	GPL V3	安装简单，官方文档专业化	适合大文件，小文件性能还存在很大优化空间	无元数据服务器，堆栈式架构(基本功能模块可以进行堆栈式组合，实现强大功能)，具有线性横向扩展能力；比mooseFS庞大	由于没有元数据服务器，因此增加了客户端的负载，占用相当的CPU和内存；但遍历文件目录时，则实现较为复杂和低效，需要搜索所有的存储节点，不建议使用较深的路径
GridFS	MongoDB	C++		安装简单	通常用来处理大文件（超过16M）	可以访问部分文件，而不用向内存中加载全部文件，从而保持高性能；文件和元数据自动同步

分布式存储系统对比之 Ceph VS MinIO：

	Ceph	MinIO
优点	· 成熟 · 红帽继子，Ceph创始人已经加入红帽 · 功能强大 · 支持数千节点 · 支持动态增加节点，自动平衡数据分布。 · 可配置性强，可针对不同场景进行调优	· 学习成本低，安装运维简单，开箱即用 · 目前MinIO论坛推广给力，有问必答 · 有java客户端、js客户端 · 数据保护：分布式MinIO采用 纠删码来防范多个节点宕机和位衰减bit rot。分布式MinIO至少需要4个硬盘，使用分布式MinIO自动引入了纠删码功能。 · 一致性：MinIO在分布式和单机模式下，所有读写操作都严格遵守read-after-write一致性模型。 · 支持联盟模式扩展集群
缺点	· 学习成本高，安装运维复杂。 · 国内有所谓的Ceph中国社区，私人机构，不活跃，文档有滞后，而且没有更新的迹象。	· 不支持动态增加节点，MinIO创始人的设计理念就是动态增加节点太复杂，后续会采用其它方案来支持扩容。
开发语言	· C	· Go
数据冗余	· 副本，纠删码	· Reed-Solomon code
一致性	· 强一致性	· 强一致性
动态扩展	· HASH	· 不支持动态加节点
中心节点	· 对象存储无中心	· CephFS有元数据服务中心点
存储方式	· 块、文件、对象	· 对象存储
活跃度	· 高，中文社区不算活跃	· 高，没有中文社区
成熟度	· 高	· 中
文件系统	· EXT4,XFS	· EXT4,XFS
客户端	· c、python,S3	· java,s3
断点续传	· 兼容S3，分段上传，断点下载	· 兼容S3，分段上传，断点下载
学习成本	· 高	· 中
开源协议	· LGPL version 2.1	· Apache v2.0
管理工具	· Ceph-admin,Ceph-mgr,zabbix插件	· web管理工具 命令行工具 mc

个人理解

第一张表中，针对中小文件作为主要区分分布式存储的特征，以及还有具有web界面与便于安装这两者具有简化操作的功能能判断是否足够友好，相对而言我觉得简单易用的是MooseFS，MogileFS，FastDFS，GlusterFS；除了fastdfs，其它三款我好像了解也不是很多，但单说fastdfs，可能作为单节点来说，确实很不错，操作用其它语言api来讲也还行，反正根据我之前搭建的过程来讲，没有编译C++的东西复杂，但多节点听说就很复杂了，而且我看B站上的视频讲得也很长，顿时就有了种不想看的感觉，emmm。

第二张表中，可以很明显的看到，ceph各方面都比minio优秀，但是它的缺点尤其明显，太过于复杂和难于管理，我也有针对ceph看过相关资料，ceph是一款面向团队的产品，它的高度自动化带来遍历的同时，系统的运行状态不完全在管理员控制之下，系统中会有若干自动触发而不是管理员触发的操作，这需要运维团队针对这些可能出现的情况进行预案以及适应。但我仅仅一个人，别说运行起这个东西，就算真运行起来了，我感觉也会自己把自己坑死，emmm。。

所以minio毫不意外的成为了我的选择，即最开头引言的最后一句话，“为机器学习、分析和应用程序数据工作负载构建高性能基础架构”。因为我本身工作涉及视频图像算法，上面这句话是在GitHub中作为minio的第一段介绍中强调，我感觉如果对业务足够敏感，对于身兼PPT技术的大佬来讲，这一句话瞬间能醍醐灌顶。为啥？这star量，加上开头这句话，这不就是PPT素材嘛，甚至都不用考虑能不能用。别给我扯什么分布式，高可用，云原生，老夫敲代码就是一把梭（滑稽），最主要呢，还是得老板开心，老板开心我就很开心，虽然疫情挺严重，还是得过个好年的，emmm。。。

minio部署与测试

minio的单节点部署

关于部署这一块，作为用go语言所写的底层，minio展现出了非常强大的跨系统以及兼容性，我之前是用了两台非docker下部署了集群，还不错，操作很简单。但因为写本篇的时候是在家，刚好试试在之前买的腾讯云部署。

docker pull minio/minio
mkdir -p /data/minio/config
mkdir -p /data/minio/data

docker run -p 9000:9000 -p 9090:9090 --net=host --name minio -d --restart=always -e "MINIO_ACCESS_KEY=minioadmin" -e "MINIO_SECRET_KEY=xxx" -v /data/minio/data:/data -v /data/minio/config:/root/.minio minio/minio server /data --console-address ":9090" -address ":9000"

minio的本地部署与docker部署都很简单，上面secret_key是密码，填写完运行即启动了minio，不过上面命令需要注意的是docker安装完后会有三种网络模式，-p使用的是bridge模式，而–net=host使用的是host模式，并且host模式优先级强于前者，所以上面-p指定的端口是无效的，因为网络默认绑定宿主机了。我也是去看了下别人运行的命令，不过有些确实没啥必要。

没报错启动后，我们就能输入localhost:9090进入登录界面，登录成功后如下图：

我这里因为刚部署上去，加了一个bucket，并丢了几张图上去，bucket应该不用多说，对象存储s3存储单元都叫这个。minio的操作界面非常友好了，基本小白都能懂，然后我原先还没发现，它能显示的格式是真的多，连webp这种小众格式还有PDF都能看：

PDF还内置双页打开，如果不是窗口太小，都能拿来划水了。。同样，之前用公司搭的上传了部分视频，如果玩过音视频的可能知道，视频编码格式有非常多种，web端最能接受的是avc1，而其它格式在网页端很难直接播放，但minio就我测试来看，似乎很强。这里就不再演示了，更多的可以去官网直接看它对此做的改进。

minio上传与下载

minio上传测试：

import logging
from minio import Minio
from minio.error import S3Error

logging.basicConfig(
    level=logging.INFO,
    filename='test.log',
    filemode='a',
    format='%(asctime)s %(name)s %(levelname)s--%(message)s'
)

# 确定要上传的文件
file_name = "self_introduction.m4a"
file_path = "/home/video/{}".format(file_name)


def upload_file():
    # 创建一个客户端
    minioClient = Minio(
        'IP:Port',
        access_key='xxxx',
        secret_key='xxxx',
        secure=False
    )

    # 判断桶是否存在
    check_bucket = minioClient.bucket_exists("pdf")
    if not check_bucket:
        minioClient.make_bucket("pdf")
    try:
        # logging.info("start upload file")
        print("start upload file")
        minioClient.fput_object(bucket_name="pdf", object_name="data/{}".format(file_name),
                                file_path=file_path)
        # logging.info("file {0} is successfully uploaded".format(file_name))
        print("file {0} is successfully uploaded".format(file_name))
    except FileNotFoundError as err:
        logging.error('upload_failed: '+ str(err))
    except S3Error as err:
        logging.error("upload_failed:", err)


if __name__ == '__main__':
    upload_file()

网页上可以看到为：

minio下载测试：

import logging
from minio import Minio
from minio.error import S3Error

logging.basicConfig(
    level=logging.INFO,
    filename='test.log',
    filemode='a',
    format='%(asctime)s %(name)s %(levelname)s--%(message)s'
)

# 要下载文件
file_name = "self_introduction.m4a"
file_path = "G:\\360Downloads\\img\\{}".format(file_name)


def download_file():
    # 创建一个客户端
    minioClient = Minio(
        'IP:Port',
        access_key='xxxx',
        secret_key='xxxx',
        secure=False
    )
	
    try:
        minioClient.fget_object(
            bucket_name="pdf",
            object_name="data/{}".format(file_name),
            file_path=file_path
        )
        logging.info("file '{0}' is successfully download".format(file_name))
    except S3Error as err:
        logging.error("download_failed:", err)

if __name__ == '__main__':
    download_file()

这里就不再举例，关于批量上传 or 下载，可以加个for循环，以及去官网查看更多的api，GitHub地址为：

https://github.com/minio/minio-py

当然官网也有api的介绍，这里推荐的官网也英文版本的，虽然它有中文，不过毕竟不是官方在维护，有所滞后，所以能看懂英文还是推荐英文。

minio纠删码技术

这里算是分布式的高可用应用场景，这里我了解不深，根据官网的说法来讲，docker是按如下方式启动：

docker run -p 9000:9000 --name minio \
  -v /mnt/data1:/data1 \
  -v /mnt/data2:/data2 \
  -v /mnt/data3:/data3 \
  -v /mnt/data4:/data4 \
  -v /mnt/data5:/data5 \
  -v /mnt/data6:/data6 \
  -v /mnt/data7:/data7 \
  -v /mnt/data8:/data8 \
  minio/minio server /data1 /data2 /data3 /data4 /data5 /data6 /data7 /data8

然后就能随意插拔小于等于一半阵列数量的硬盘，它会采用Reed-Solomon code将对象拆分成N/2数据和N/2 奇偶校验块，来保证数据安全。关于里面是啥逻辑我不知道，但就我试验情况，我两台使用此方式启动，其中一台reboot，另一台开始错误日志起飞，可能这算是一种预警，然后恢复数据倒没观察，因为本身玩也没多久，还算一个预案，只能说还行。未完待续，后续如果有测试出其它问题会进行补充。