Minio架构简介
简介
Minio是一个go编写基于Apache License v2.0开源协议的对象存储系统,是为海量数据存储、人工智能、大数据分析而设计,它完全兼容Amazon S3接口,十分符合存储大容量的非结构化数据从几十kb到最大5T不等。是一个小而美的开源分布式存储软件。
特点
简单、可靠:Minio采用简单可靠的集群方案,摒弃复杂的大规模的集群调度管理,减少风险与性能瓶颈,聚焦产品的核心功能,打造高可用的集群、灵活的扩展能力以及超过的性能。建立众多的中小规模、易管理的集群,支持跨数据中心将多个集群聚合成超大资源池,而非直接采用大规模、统一管理的分布式集群。
功能完善:Minio支持云原生,能与Kubernetes、Docker、Swarm编排系统良好对接,实现灵活部署。且部署简单,只有一个可执行文件,参数极少,一条命令即可启动一个Minio系统。Minio为了高性能采取无元数据数据库设计,避免元数据库成为整个系统的性能瓶颈,并将故障限制在单个集群之内,从而不会涉及其他集群。Minio同时完全兼容S3接口,因此也可以作为网关使用,对外提供S3访问。同时使用Minio Erasure code和checksum 来防止硬件故障。即使损失一半以上的硬盘,但是仍然可以从中恢复。分布式中也允许(N/2)-1个节点故障。
架构
去中心化架构
Minio采用去中心化的无共享架构,对象数据被打散存放在不同节点的多块硬盘,对外提供统一命名空间访问,并通过负载均衡或者DNS轮询在各个服务器之间实现负载均衡
统一的命名空间
Minio有两种集群部署方式,一种是常见的本地分布式集群部署,一种是联盟模式部署。本地分布式集群部署即在多个本地服务器节点部署Minio服务,并将其组成单套分布式存储集群,并提供统一命名空间和标注的S3访问接口。联盟部署则是将多个本地Minio集群在逻辑上组成了统一命名空间,实现近乎无线的扩展与海量的数据规模管理,这些集群都可以在本地或者分布在不同地域的数据中心。
分布式锁管理
与分布式数据库类似,Minio也会存在面临数据一致性的问题:一个客户端在读取一个对象的同时,另一个客户端可能正在修改或者删除这个对象。为了避免出现不一致的情况。Minio专门设计并实现了dsync分布式锁管理器,来控制数据一致性。
- 任何一个节点的锁请求都会广播给集群内的所有在线节点
- 如果收到N/2+1个节点的同意,则获取所成功
- 没有主节点,每个节点互相对等,节点间通过stale lock检测机制,判断节点的状态及持有锁情况
- 由于设计简单,比较粗糙。有一定的缺陷性,最多支持32个节点。无法避免锁丢失的场景。不过基本满足可用需求。
EC2 Instance Type | Nodes | Locks/server/sec | Total Locks/sec | CPU Usage |
---|---|---|---|---|
c3.8xlarge(32 vCPU) | 8 | (min=2601, max=2898) | 21996 | 10% |
c3.8xlarge(32 vCPU) | 8 | (min=4756, max=5227) | 39932 | 20% |
c3.8xlarge(32 vCPU) | 8 | (min=7979, max=8517) | 65984 | 40% |
c3.8xlarge(32 vCPU) | 8 | (min=9267, max=9469) | 74944 | 50% |
数据结构
Minio对象存储系统把存储资源组织为租户-桶-对象的形式
- 对象:类似于hash表中的表xiang表项,名字是关键字,内容相当于值
- 桶:是若干个对象的逻辑抽象,是盛装对象的容器
- 租户:用于隔离存储资源。在租户下可以建立桶、存储对象
- 用户:在租户下面创建的用于访问不同桶的账号。可以使用minio提供的mc命令设置不同用户访问各个桶的权限
统一域名访问
Minio集群扩展加入了新的集群或者桶后,对象存储的客户端程序需要通过统一的域名/url来访问数据对象,这个过程涉及了etcd与CoreDns
存储机制
Minio使用纠删码erasure code和checksum来保护数据免受硬件故障和无声数据损坏。即使丢失一半数量(N/2)的硬盘,仍然可以恢复数据。
纠删码是一种恢复丢失和损坏数据的数学算法,目前纠删码技术在分布式存储系统中的应用分为三类,阵列纠删码(Array code:RAID5、RAID6等)、RS(Reed-solomon)里德-所罗门类纠删码和LDPC(LowDensity Parity Check Code)低密度奇偶检验纠删码。ErasureCode是一种编码技术,它可以将份原始数据,增加M份数据,并能通过N+M份中的任意N分数据,还原原始数据。即如果有任意小于等于M份的数据丢失,仍然能通过剩下的数据还原。
Minio采用Reed-solomon code将对象拆分成N/2数据和N/2奇偶检验快,这就意味着如果是12块盘,一个对象将会被分成6个数据块、6个奇偶检验快,可以丢失任意6块盘(不管存放的数据快还是奇偶检验快),让然可以从剩下的盘中的数据恢复。
在一个N节点的分布式Minio中,只要有N/2个节点在线,你的数据就是安全的。不过至少需要N/2+1个节点才能进行写操作。
将一个文件上传至Minio后,对应磁盘上的信息如下:
其中xl.json为此对象的元数据文件。part.1为此对象的第一个数据分片。(分布式中每一个节点都会存在这两个文件分别是数据块和奇偶检验快)在读取数据时Minio会对编码快进行HighwayHash编码,然后进行校验,以确保每个编码的正确性。基于Erasure Code和Bit Rot Protection的HighwayHash这两个特性,所以Minio的数据可靠性很高。
lambda计算与持续备份
Minio支持lambda计算通知机制,即桶中的对象支持事件通知机制。当前支持的事件类型有:对象上传、对象下载、对象删除、对象复制等。当前支持事件接受系统有:redis、NATS、AMQP、Kafka、mysql、elasticsearch等。
对象通知机制增强了Minio的扩展性,可以让用户通过自行开发来实现某些Minio未实现的功能。比如基于元数据的检索、与用户业务相关的计算等。同时也可以通过这个机制进行快速有效的增量备份。
对象存储网关
Minio除了可以作为存储系统服务外,还可以作为网关,后端可以与NAS系统、HDFS系统等分布式文件系统或者S3、OSS这样的第三方存储系统。有了Minio网关,就可以为这些后端系统添加S3兼容的API,便于管理和移植,因为S3API已经是对象存储界事实的标注。
用户通过统一的S3 API请求存储资源,通过S3 API Router将各个请求路由到对应的ObjectLayer,每个ObjectLayer对应实现了各个存储系统的对象操作的所有API。例如GCS(Google cloud storage)实现了ObjectLayer接口后,它对于后端存储的操作就是通过GCS的SDK实现。当终端通过S3 API获取存储桶列表,那么最终的实现会通过GCS的SDK访问GCS服务获取存储桶列表,然后包装成S3标准的结构返回给终端。