> 文章列表 > 典型的高可用设计(一):MinIO

典型的高可用设计(一):MinIO

典型的高可用设计(一):MinIO

        为了更好的了解高可用设计,将各类常用服务关于高可用的设计原理汇总到一起,通过横向对比的方式去发现这些典型设计的共同之处和差异点。

一、部署方式

        MinIO 有单机单硬盘、单机多硬盘、多机多硬盘三种部署模式。单机单硬盘存在单点风险,数据没有安全保障,一般只用于测试环境、开发环境。单机多硬盘同样有单点风险,但数据有安全保障。多机多硬盘是最常用的部署方式,在多台(2-32)服务器上搭建服务,且数据分散在多块(最少4块,无上限)磁盘上,提供了较为强大的数据冗余机制(Reed-Solomon纠删码),规避了单点风险。

二、分布式部署

        MinIO 采用多机多硬盘的分布式部署方式保证系统的高可用。下图是MinIO的存储示意图。一行是一个MinIO的服务,一个MinIO服务可以有多个Drive(本地硬盘),Set是一组 Drive 的集合。

        看几个MinIO的概念:

        Object:存储到 MinIO 的基本对象,如文件、字节流,Anything...

        Bucket:用来存储 Object 的逻辑空间。每个 Bucket 之间的数据是相互隔离的。对于客户端而言,就相当于一个存放文件的顶层文件夹。

        Drive:部署 MinIO 时设置的磁盘,MinIO 中所有的对象数据都会存储在 Drive 里。

        Set:在同一集群内,MinIO 自己会自动生成若干Set(纠删组),用于分布存放桶数据。是一组 Drive 的集合,每个 Set 中的 Drive 分布在不同位置。一个对象存储在一个 Set 上。(For example: {1…64} is divided into 4 sets each of size 16.)。

        DataDrives :纠删码中的数据盘,用来存储 Object 原始数据。

        ParityDrives:纠删码中的冗余盘,用来存储 Object 计算出来的冗余数据。

三、对象存储

        MinIO 是通过数据编码,将原来的对象编码成 N 份,N 就是一个 Set 上面 Drive 的数量。对象被编码成N份之后,把每一份,写到对应的 Drive 上面,这就是把一个对象存储在整个 Set 上。

         一个集群包含多个 Set,每个对象最终存储在哪个 Set 上是根据对象的名称进行哈希,然后影射到唯一的 Set 上面,这个方式从理论上保证数据可以均匀的分布到所有的 Set 上。

        根据的观测,数据分布的也非常均匀,一个 Set 上包含多少个 Drive 是由系统自动根据集群规模算出来的,当然,也可以自己去配置。

        一个 Set 的 Drive 系统会考虑尽可能把它放在更多的节点上面,保证它的可靠性。

        对于上传的 Object,Minio 会将其划分为多个 Block 来计算纠删码。如果 Object Size > 10 MB,那么每个 block 的大小就是 10 MB。如果 Object Size < 10 MB,如果也划分一个 10 MB 的 block 就太浪费空间了,所以分配一个大小刚好为 Object Size 的 block 就够了。

        一个 Set 中有多个 Drive(DataDrives + ParityDrives),所以 Minio 会先将一块 Block 按照 Drive 数量,划分为多个小块,这些小块在 Minio 中叫做 Shards。比如一个 Block 是 10MB, 而 Set 里有 6 个 Drive(3 DataDrives + 3 ParityDrives),此时 Minio 会将 Block 按照 10 MB / 3 DataDrives 的方式,将数据划分到 3 个 Data Shards,并额外再创建 3 个 空 Shards,用来存储编码后的冗余数据。

四、高可用

        对于用户来说,直观的感觉是把某个Object存到了某个Bucket中,而不用关心这个对象具体放到了哪些服务的那些磁盘中。

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

        多节点组成的分布式Minio集群可保证服务的高可用,一个N节点的分布式Minio,只要有N/2节点在线,数据就是安全的。不过需要至少有N/2+1个节点才能创建新的对象。

        例如,一个16节点的Minio集群,每个节点16块硬盘,就算8台服务器宕机,这个集群仍然是可读的,不过需要9台服务器才能写数据。

        分布式Minio自动引入了纠删码功能来保证数据安全,防范多个节点宕机和位衰减bit rot。分布式Minio至少需要4个硬盘。一个Set中的一定数量的硬盘发生的故障(故障硬盘的数量小于等于校验盘的数量),通过纠删码校验算法可以恢复出正确的数据。

        只要遵守分布式Minio的限制,可以组合不同的节点和每个节点几块硬盘。比如,可以使用2个节点,每个节点4块硬盘;可以3个节点,每个节点2块硬盘;也可以使用4个节点,每个节点1块硬盘,诸如此类。在这些集群配置下,至少能保证1个节点宕机或者1块磁盘损坏的情况下不丢数据,能读数据,能恢复服务。节点越多、每个节点的硬盘越多可用性越高。

五、注意事项

  1. 所有运行分布式 MinIO 的节点都应该共享一个共同的根凭证,以便节点相互连接和信任。为此,建议在执行 MinIO 服务器命令之前,将 root 用户和 root 密码导出为环境变量,MINIO_ROOT_USER并在所有节点上导出。MINIO_ROOT_PASSWORD如果未导出,minioadmin/minioadmin则应使用默认凭据。
  2. MinIO 创建每组2到16 个驱动器的纠删码集。提供的驱动器总数必须是这些数字之一的倍数。
  3. MinIO 选择最大的 EC 集大小,将其划分为给定的驱动器总数或节点总数,确保保持均匀分布,即每个节点参与每组相同数量的驱动器。
  4. 每个对象都写入单个 EC 集,因此分布在不超过 16 个驱动器上。
  5. 建议运行分布式 MinIO 设置的所有节点是同质的,即相同的操作系统、相同数量的磁盘和相同的网络互连。
  6. 分布式Minio使用干净的目录,里面没有数据。也可以与其他程序共享磁盘,这时候只需要把一个子目录单独给MinIO使用即可。例如,可以把磁盘挂在到/export下, 然后把/export/data作为参数传给MinIO server即可。
  7. 运行分布式 MinIO 实例的服务器之间的间隔应小于 15 分钟(之前是3s)。可以启用NTP服务作为最佳实践,以确保跨服务器的时间相同。
  8. 在Windows操作系统上运行分布式 MinIO被认为是实验性的。请谨慎行事。