简介
MinIO 对象存储系统是为海量数据存储、人工智能、大数据分析而设计,基于
Apache License v2.0 开源协议的对象存储系统,它完全兼容 Amazon S3 接口,单个对象的最大可达 5TB,适合存储海量图片、视频、日志文件、备份数据和容器/虚拟机镜像等。作为一个开源服务,MinIO 在设计上汲取了Glusterfs的相关经验不教训,系统复杂度上作了大量简化,目前大小只有40+M,部署只需要一个命令即可完成!另外,minio舍弃了传统分布式存储扩容所需要的迁移流程,采用联盟模式添加集群的方式,极大简化了扩容流程;除此之外,minio还具有纠删编码、比特位保护、单写多读(worm)、下面来依次简要解析一下Mioio的特点及具体实现:
底层存储方式
元数据和数据一起存放在磁盘上。元数据以明文形式存放在元数据文件里(xl.json)。假定对象名字为key_name, 它所在桶的名字是bucket_name, disk路径就是/disk,那么存储路径就是:/disk/bucket_name/key_name,windows下C盘存放桶名为test,对象名为minio.exe示例如图:
底层存储png.png
其中part.1是实际存储数据(单机模式为原生数据,分布式为纠删码分块),xl.json是如下所示的json字符串:
{
//版本号
"version":"1.0.1",
//对象的格式,MinIO 内部存储数据主要有两种数据格式:xl 和 fs。单机模式,也就是
底层数据没有做纠删分片存储格式是fs,主要做测试用,实际使用一般都是xl模式
"format":"xl",
//对象状态,大小和修改时间
"stat":{
"size":47261688,
"modTime":"2020-02-10T07:25:39.17335Z"
},
//纠删码相关信息
"erasure":{
// algorithm 指明了此对象采用的是 Klaus Post 实现纠删码, 生成矩阵是范德蒙矩阵。
"algorithm":"klauspost/reedsolomon/vandermonde",
// data,parity指明了纠删组中数据盘、校验盘的个数。
"data":3,
"parity":3,
// blockSize 是对象被分块的大小默认是5M
"blockSize":10485760,
// index指的是当前磁盘在纠删组中的序号
"index":2,
// distribution:每个纠删组的数据盘、校验盘的个数是固定的,但是不同的对象的分片
写入这个纠删组的顺序是不同的。这里记录了分布顺序。
"distribution":[1,3,2,4,5,6],
// checksum:下面的字段个数跟此对象的分片数量有关。在旧版本的 MinIO 对象存储 系统,
每一个分片经过 hash 函数计算出的 checksum 会记录在元数据文件的这个位置。
最新版的 MinIO 会把 checksum 直接计入分片文件(即 part.1 等文件)的前 32 个字节。
此字段下 algorithm 的值是”highwayhash256S”表明 checksum 值是写入分片文件的。
"checksum":[
{
"name":"part.1",
"algorithm":"highwayhash256S"
}
]
},
"minio":{
"release":"RELEASE.2020-01-25T02-50-51Z"
},
"meta":{
"content-type":"application/x-msdownload",
"etag":"b2591a1de87921e4d49c724fd3fbd5b2-1"
},
//记录各个分片的信息
"parts":[
{
"number":1,
"name":"part.1",
"etag":"",
"size":47261688,
"actualSize":47261688
}
]
}
纠删码
在同一集群内,MinIO 自己会自劢生成若干纠删组,用于分布存放桶数据。一个纠删组中的一定数量的磁盘发生的故障(故障磁盘的数量小于等于校验盘的数量),通过纠删码校验算法可以恢复出正确的数据。MinIO 集成了 Reed-Solomon 纠删码库,MinIO 存储对象数据时,首先把它分成若干等长的片段(对于大对象,默认按 5MB 切片),然后每一个片段会纠删算法分成若干分片,包括数据分片不校验分片,每个分片放置在一个纠删组的某个节点上。对象的每一个数据分片、校验分片都被“防比特位衰减”算法所保护。
一个对象,MinIO是如何定位它所在的纠删组呢?
假定所有的纠删组都有一个序号(从0 开始,直至纠删组个数减 1)。在每个磁盘的系统配置桶(.minio.sys,在linux默认是隐藏的)下的format.json文件记录了其所在纠删组的信息,如下图所示:我这边是使用二十四块盘,12个盘组成一个纠删组,所以是两组
{
"version":"1",
"format":"xl",
"id":"233caf85-4128-46f1-a50c-042b1c7d31cb",
"xl":{
"version":"3",
"this":"a38cbcc2-417f-467c-874a-64c4c10d5dee",
// 纠删组,我这边是使用二十四块盘,12个盘组成一个纠删组,所以是两组
"sets":[
[
"24ae8c79-3121-4f8f-ba53-98323e4f7b03",
"a38cbcc2-417f-467c-874a-64c4c10d5dee",
"f79dfdbf-621d-4ac7-82a8-951f711e5821",
"8d0433a5-ee66-46f0-adac-1b1f5ef9fb06",
"5e1ef3be-51eb-43e6-a130-8e25fea6e2f6",
"7015b6cf-74c1-4c58-8d29-562c70a15772",
"6f9aed7b-4326-4f49-93f6-7ab39e08c89b",
"edf0c685-662b-4f03-8757-418c9144a5c4",
"9111013d-6514-4a32-921c-422f84ec8261",
"f11a731a-1f8f-4835-8e05-60efe069e872",
"a37a8b68-b100-4490-bd28-dd5beec54dd5",
"79c95699-5f6c-40db-8ddf-3cdcba17f645"
],
[
"5c6b7926-8a56-47e7-88c1-edae52cb564b",
"692e6228-cc01-4a6f-add8-6867dff01c69",
"378c72a0-acaf-4897-8593-9d501edf74b8",
"d90195b0-e434-41c3-9b59-b966f652835d",
"cc915e46-5624-4b71-898f-2a8739bb3d13",
"83236511-7511-45b3-9287-f787c24b4fd2",
"7fd55744-bb89-4039-af59-5b63a10a0457",
"e165d009-039c-49ea-bdf3-8e683fdf96d8",
"bdbbc0c0-2daa-4a7b-8a3d-0d951724d71c",
"968db6f7-40cc-49f2-bb13-f56a6158c118",
"ec3fa7e3-58a6-4e50-9a4d-a7261f604f46",
"669af533-9818-4102-a0c9-8e9ca7f1c189"
]
],
"distributionAlgo":"CRCMOD"
}
}
MinIO 会根据对象名(类似于文件系统的全路径名),使用 crc32 哈希算法计算出一个整数。然后使用这个整数除以纠删组的个数,得到一个余数。这个余数,可以作为纠删组的序号,这样就确定了这个对象所在的纠删组。MinIO 采用 CRC32 哈希算法,不 glusterfs 的Davies Meyer哈希算法(性能、冲突概率不md4, md5相近)不一样的是,CRC32算法的哈希值分布较不均匀,但运算速度极快,高出 md4 数倍。相对于容量均衡,MinIO 更看重数据的写入速度。
纠删组如何配置?
官方文档说明如下:
- MinIO创建4、6、8、10、12、14或16个驱动器的擦除编码集。您提供的驱动器数量必须是这些数量之一的倍数。
- MinIO选择最大的纠删组大小,该大小将划分为给定的驱动器总数。例如,将8个驱动器用作大小为8的单个纠删组,而不是大小为4的两个纠删组。
也就是说纠删组的总大小只能从这7中情况中根据你提供的盘的个数(或者说路径个数)来自动选取最大值的,我们不能灵活地配置m+k纠删存储格式。但这样说又不是很准确,因为虽然不能配置任意的m+k,但是在系统已经选取好擦除编码集的的个数后(也就是m+k),可以使用storage class存储类来自定义m和k的数量,默认是1:1的。
存储类:
MinIO支持配置两种存储类别,精简冗余类别和标准类别,默认是标准类别(1:1),可以在启动MinIO服务器之前使用设置的环境变量来定义这些类。使用环境变量定义每个存储类别的数据和奇偶校验磁盘后,您可以在上传对象时通过请求元数据字段设置对象的存储类别x-amz-storage-class。然后,MinIO服务器通过将对象保存在特定数量的数据和奇偶校验磁盘中来兑现存储类。具体配置和使用可以参考官方文档https://github.com/minio/minio/tree/master/docs/erasure/storage-class
为什么MinIO单集群不支持扩展?
传统的扩展方式的劣势
通过增加节点来扩展单集群,一般需要进行数据均衡,否则群集内各存储节点会因负载不均而出现新的瓶颈。除了数据均衡操作的时机这个问题以外,在均衡过程中一般需要仍存储使用率高的节点吐使用率低的节点迁移数据。当集群扩容后,大量已经写入的文件落点会出现改变,文件需要迁移到真实的落点。当存储系统容量比较大时,则会发生大量的文件/对象进行迁移,迁移过程可能由于占用大量资源而导致上层应用性能下降。而且当文件/对象迁移过程中,机器故障可能会导致一些意想不到的情冴,尤其是有大量业务的时候。当然针对此类问题,Gluterfs之类的文件系统有一些比较复杂的处理办法。
不支持扩展优势
- 单集群不可扩展,也就是说系统不需要处理扩展和数据均衡,不仅有效降低系统复杂性,而且可以使得系统部署规划具有很好的可预测性。
- 不支持对单个集群进行扩展,MinIO 对象存储系统的这种设计,使得系统的很多模块更加简单(比如仍一个对象转换到它所在的纠删组,叧用简单的哈希即可。降低了整个系统出错的概率,使得MinIO对象存储系统更加可靠、稳定。
参考:
- 《MinIO技术白皮书》
ps:
有需要白皮书的同学可以私信获取;另外,Minio在探探后端的探索视频也可以look look,地址:https://www.bilibili.com/video/av56545173?p=9
网友评论