【分布式技术专题】「OSS中间件系列」从0到1的介绍一下开源对象存储MinIO技术架构

MinIO背景介绍

  • MinIO创始者是Anand Babu Periasamy, Harshavardhana(戒日王)等人, Anand是GlusterFS的初始开发者、Gluster公司的创始人与CTO,Harshavardhana曾经是GlusterFS的开发人员,直到2011年红帽收购了Gluster公司。

  • MinIO在设计上汲取了GlusterFS的相关经验与教训,系统复杂度上作了大量简化。

MinIO简介

概述

  • MinIO对象存储系统是为海量数据存储、人工智能、大数据分析而设计,基于Apache License v2.0开源协议的对象存储系统,它完全兼容Amazon S3接口,单个对象最大可达5TB,适合存储海量图片、视频、日志文件、备份数据和容器/虚拟机镜像等。

  • MinIO主要采用Golang语言实现,整个系统都运行在操作系统的用户态空间,客户端与存储服务器之间采用http/https通信协议。

Glusterfs

Glusterfs是一个开源分布式文件系统,具有强大的横向扩展能力,可支持数PB存储容量和数千客户端,通过Infiniband RDMA 或Tcp/Ip 方式将许多廉价的x86 主机,通过网络互联成一个并行的网络文件系统。具有可扩展性、高性能、高可用性等特点。

设计哲学

  • 极简理念——采用尽可以简单可靠的集群管理方案,摒弃复杂的大规模集群调度管理,减少风险因素与性能瓶颈,聚焦产品的核心功能,打造高可靠的集群、灵活的扩展能力以及超高的性能;

  • 积木式扩展——建立众多的中小规模、易管理的集群,支持跨数据中心将多个集群聚合成超大资源池,而非直接采用大规模、统一管理的分布式集群。

设计原则

【分布式技术专题】「OSS中间件系列」从0到1的介绍一下开源对象存储MinIO技术架构_第1张图片

产品特点

【分布式技术专题】「OSS中间件系列」从0到1的介绍一下开源对象存储MinIO技术架构_第2张图片

高级特性

【分布式技术专题】「OSS中间件系列」从0到1的介绍一下开源对象存储MinIO技术架构_第3张图片

官方资源

官方网站

技术架构

数据组织结构

NAS系统把整个存储资源组织为目录树的形式,与此不同,对象存储系统把存储资源组织为租户-桶-对象的形式。数据结构组织见下图:

【分布式技术专题】「OSS中间件系列」从0到1的介绍一下开源对象存储MinIO技术架构_第4张图片

  • 对象:类似于hash表中的表项:它的名字相当于关键字,它的内容相当于“值”。

  • 桶:是若干个对象的逻辑抽象,是盛装对象的容器。

  • 租户:用于隔离存储资源。在租户之下可以建立桶、存储对象。

  • 用户:在租户下面创建的用于访问不同桶的账号。可以使用MinIO提供的mc命令设置不用用户访问各个桶的权限。

数据分布与均衡

去中心化架构

【分布式技术专题】「OSS中间件系列」从0到1的介绍一下开源对象存储MinIO技术架构_第5张图片

MinIO采用去中心化的无共享架构,对象数据被打散存放在不同节点的多块硬盘,对外提供统一命名空间访问,并通过Web负载均衡器或DNS轮询(DNS round-robin)在各服务器之间实现负载均衡。

【分布式技术专题】「OSS中间件系列」从0到1的介绍一下开源对象存储MinIO技术架构_第6张图片

统一命名空间

MinIO对象存储系统主要有两种部署方式,一种是常见的本地分布式集群部署,一种是联盟模式部署。

  • 本地分布式集群部署方式即在多个本地服务器节点部署MinIO软件,并将其组件成单套分布式存储集群,并提供统一命名空间和标准S3访问接口。

  • 联盟部署模式即将多个MinIO集群在逻辑上组成了统一命名空间,实现近乎无限的扩展与海量的数据规模管理,这些集群可以都在本地,或分布在不同地域的数据中心。

如下图所示,4个服务器节点组成一个MinIO集群,每个服务器节点中会选择相同数据的硬盘创建一个纠删组,某个桶的数据会根据MinIO的分布式算法,切片分散存储到对应的纠删组中(详见纠删码相关内容)。

【分布式技术专题】「OSS中间件系列」从0到1的介绍一下开源对象存储MinIO技术架构_第7张图片

分布式锁管理

与分布式数据库相类似,MinIO对象存储系统也面临数据一致性问题:一个客户端程序在读取一个对象的同时,另一个客户端程序可能正在修改或者删除这个对象。为了避免出现数据不一致情况,MinIO相关开发人员为MinIO对象存储专门设计并实现了dsync分布式锁管理器。

它采用如下分布式锁管理机制:

  • 任何一个节点的锁请求都会广播给集群内所有在线节点;

  • 如果n/2 + 1个节点回应“是”,则成功获得锁;

  • 客户端获得锁以后可保留任意时间,不需要时自己释放即可。释放操作也会广播给所有的节点,从而恢复锁的可用状态。写锁仅能被一个写入者获得。

设计目标

  • 要求设计简单,因为简单的设计,可以避免程序中很多非常棘手的条件分支的支持。

  • 不存在主节点,因为一旦在设计上引入主节点,那么如果主节点宕机,整个锁管理器机制即将失效,这对MinIO对象存储系统影响非常严重,是不可接受的。

  • 系统必须是弹性的,即使存在多个失效的节点,只要它们的个数小于n/2, 整个锁管理系统是可以正常工作的。

  • 完全可以替代Golang标准库中的sync.RWMutex互斥锁。这样可以简化MinIO对象存储系统的编程。

  • 当失效节点重启以后,其它节点重新连接。

不使用zookeeper/raft等技术的原因

zookeeper/raft功能丰富,而MinIO对象储存的使用用例其实很有限。在MinIO中使用zookeeper/raft,会使整个系统增加不必要的复杂性。

优势

  • 实际操作极其简单,有效代码不足一千行,易理解,易维护。

  • 超高的性能。

云网关模式

  • MinIO存储系统的后端可以是磁盘,也可以作为云网关,对接第三方的NAS系统、分布式文件系统或公有云存储资源,并为业务系统转换提供标准的对象访问接口。

  • 目前MinIO支持Google 云存储、HDFS、阿里巴巴OSS、亚马逊S3, 微软Azure Blob 存储等第三方存储资源。

【分布式技术专题】「OSS中间件系列」从0到1的介绍一下开源对象存储MinIO技术架构_第8张图片

与Kubernetes的整合部署

【分布式技术专题】「OSS中间件系列」从0到1的介绍一下开源对象存储MinIO技术架构_第9张图片

你可能感兴趣的:(实战指南之分布式/微服务,分布式,中间件,开源)