MinIO分布式存储服务_minio分布式存储现在已弃用

一、前言

最近项目中使用到了MinIO的分布式存储系统，记录一下Minio服务的相关概念以及使用方法。

二、基本概念

MinIO 对象存储系统是为海量数据存储、人工智能、大数据分析而设计，基于Apache License v2.0 开源协议的对象存储系统，它完全兼容 Amazon S3 接口，单个对象的最大可达 5TB，适合存储海量图片、视频、日志文件、备份数据和容器/虚拟机镜像等。作为一个开源服务，MinIO 在设计上汲取了Glusterfs的相关经验不教训，系统复杂度上作了大量简化，目前大小只有40+M，部署只需要一个命令即可完成！另外，minio舍弃了传统分布式存储扩容所需要的迁移流程，采用联盟模式添加集群的方式，极大简化了扩容流程；除此之外，minio还具有纠删编码、比特位保护、单写多读（worm)、下面来依次简要解析一下Mioio的特点及具体实现。

• Object:存储到Minio的基本对象，如文件字节流，Anything。
• Bucket:用来存储Object的逻辑空间。每个Bucket之间的数据是相互隔离的。对于客户端而言，就相当于一个存放文件的顶层文件夹。
• Drive:即存储数据的磁盘，在MinlO启动时，以参数的方式传入。Minio中所有的对象数据都会存储在Drive里。
• Set:即-组Drive的集合，分布式部署根据集群规模自动划分一个或多个Set，每个Set中的Drive分布在不同位置。一个对象存
  储在一个Set上。(For example:{1…64} is divided into 4sets each of size16)

三、特点及实现

1. 底层存储方式
元数据和数据一起存放在磁盘上。元数据以明文形式存放在元数据文件里（xl.json）。假定对象名字为key_name, 它所在桶的名字是bucket_name, disk路径就是/disk，那么存储路径就是：/disk/bucket_name/key_name，windows下C盘存放桶名为test，对象名为minio.exe，其中有两个文件part.1和xl.json。
其中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
        }
    ]
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

2.纠错码
在同一集群内，MinIO 自己会自劢生成若干纠删组，用于分布存放桶数据。一个纠删组中的一定数量的磁盘发生的故障（故障磁盘的数量小于等于校验盘的数量），通过纠删码校验算法可以恢复出正确的数据。MinIO 集成了 Reed-Solomon 纠删码库，MinIO 存储对象数据时，首先把它分成若干等长的片段（对于大对象，默认按 5MB 切片)，然后每一个片段会纠删算法分成若干分片，包括数据分片不校验分片，每个分片放置在一个纠删组的某个节点上。对象的每一个数据分片、校验分片都被“防比特位衰减”算法所保护。

四、总结

1.传统的扩展方式的劣势
通过增加节点来扩展单集群，一般需要进行数据均衡，否则群集内各存储节点会因负载不均而出现新的瓶颈。除了数据均衡操作的时机这个问题以外，在均衡过程中一般需要仍存储使用率高的节点吐使用率低的节点迁移数据。当集群扩容后，大量已经写入的文件落点会出现改变，文件需要迁移到真实的落点。当存储系统容量比较大时，则会发生大量的文件/对象进行迁移,迁移过程可能由于占用大量资源而导致上层应用性能下降。而且当文件/对象迁移过程中，机器故障可能会导致一些意想不到的情冴,尤其是有大量业务的时候。当然针对此类问题，Gluterfs之类的文件系统有一些比较复杂的处理办法。
2.不支持扩展优势

• 单集群不可扩展，也就是说系统不需要处理扩展和数据均衡，不仅有效降低系统复杂性，而且可以使得系统部署规划具有很好的可预测性。
• 不支持对单个集群进行扩展，MinIO 对象存储系统的这种设计，使得系统的很多模块更加简单（比如仍一个对象转换到它所在的纠删组，叧用简单的哈希即可。降低了整个系统出错的概率，使得MinIO对象存储系统更加可靠、稳定。
• 资料参考:《MinIO技术白皮书》