典型的高可用设计（一）：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被认为是实验性的。请谨慎行事。