对象存储minio部署指南

1.1 存储架构

1.1.1 对象存储

对象存储也称为基于对象的存储，是一种将数据存储作为不同单元（称为对象）进行管理和操作的策略。这些对象保存在单个存储库中，不会与其他文件夹中的文件绑定到一起。相反，对象存储会将构成文件的数据片段合并到一起，将所有相关的元数据添加到该文件，并附加自定义标识符。

对象存储会为文件添加全面的元数据，消除了文件存储中使用的分层文件结构；它将所有内容放置在一个称为存储池的扁平地址空间中。此元数据是对象存储成功的关键，因为它可以对存储池中数据的使用和功能进行深入分析。

1.1.2 对比其它存储架构

对象存储将获取的每个数据片段指定为对象。数据保存在单独的存储库中，而不是以文件的形式保存在文件夹中，数据与关联的元数据和唯一标识符捆绑在一起，以形成存储池。

文件存储将数据作为一条信息存储在文件夹中，以便于区分其他数据进行组织。这也称为分层存储，模仿了纸质文件的存储方式。当您需要访问数据时，您的计算机系统需要知道数据的路径。

块存储将文件拆分为单个数据块，然后将这些块作为单独的数据片段来存储。每条数据都有不同的地址，因此无需将它们存储在文件结构中。

1.1.3 对象存储的优势

• 可扩展性高

  对象存储的扩展性很强，它是一种横向扩展的系统，数据会被存储到对象存储的各个节点，扩展容量甚至可以超过几百PB，对于有强烈存储非结构化数据的企业而言，这一点尤为重要。

• 效率高

  对象存储采用了扁平化的数据组织结构，不受复杂目录系统的影响，也无需维护庞大的目录数。

• 安全性高

  要想访问对象存储里的数据，必须凭借HTTP调用对象存储本身提供的认证密匙，从而保证存储数据的安全性。

• 访问便捷

  对象存储可以通过多种方式调用和检索数据，比如使用http、https、NFS、SMB等等。

• 成本较低

  与其他存储方式相比，对象存储的成本更低。

1.2 开源框架

目前开源对象存储框架已非常成熟，主流的框架有以下几种：MinIO, Ceph, FastDFS, GlusterFS 等。

MinIO集群采用去中心化无共享架构，各节点间为对等关系，连接至任一节点均可实现对集群的访问，并通过DNS轮询等方式实现节点间的负载均衡。这种节点间保持对等关系的设计并非最常见的分布式集群架构。当前大多数的分布式存储集群，其节点往往可划分为多类角色，例如负责连接并处理外部应用请求的访问节点、负责存储元数据的管理节点、实际的数据存储节点等。MinIO则与之不同，MinIO集群中的所有节点都同时承担了多种角色，集元数据存储、数据存储、应用访问等功能于一体，真正实现了去中心化和所有节点的完全对等。其优势在于有效地减少了集群内的复杂调度过程以及因中心节点带来的故障风险和性能瓶颈。

数据对象在MinIO集群中进行存储时，先进行纠删分片，后打散存储在各硬盘上。具体为：MinIO自动在集群内生成若干纠删组，每个纠删组包含一组硬盘，其数量通常为4至16块；对数据对象进行分片，默认策略是得到相同数量的数据分片和校验分片；而后通过哈希算法计算出该数据对象对应的纠删组，并将数据和校验分片存储至纠删组内的硬盘上。

MinIO提供简单轻便的部署及使用体验，无缝对接Amazon S3、数据纠错机制、对K8S友好，活跃的社区也保证了常见问题都可以很快的解决，不足之处在于不能动态扩容，但是官方也提供了通过增加新的独立集群的方式事项扩容的方式。

2. 物理部署与规划

2.1 软件版本

MinIO版本更新非常快，每隔几天就会发行一个新的release版本，在没有新的大版本更新的情况下（目前为3.x），可以使用latest release.

• minio：RELEASE.2021-11-24T23-19-33Z
• nginx：1.21
• etcd： 3.5.2

2.2 集群部署与规划

minio集群规划为三台存储服务器，一台nginx服务器，三台etcd服务器。

2.3 docker化部署

version: '3.9'

x-minio-common: &minio-common
  image: minio/minio:latest
  command: server --console-address ":9001" http://minio{1...4}/data{1...2}
  expose:
    - "9000"
    - "9001"
  environment:
    MINIO_ROOT_USER: minio
    MINIO_ROOT_PASSWORD: minio123
  healthcheck:
    test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/live"]
    interval: 30s
    timeout: 20s
    retries: 3

services:
  minio1:
    <<: *minio-common
    hostname: minio1
    volumes:
      - /data/minio/data/data1-1:/data1
      - /data/minio/data/data1-2:/data2

  minio2:
    <<: *minio-common
    hostname: minio2
    volumes:
      - /data/minio/data/data2-1:/data1
      - /data/minio/data/data2-2:/data2

  minio3:
    <<: *minio-common
    hostname: minio3
    volumes:
      - /data/minio/data/data3-1:/data1
      - /data/minio/data/data3-2:/data2


  nginx:
    image: nginx:1.19.2-alpine
    hostname: nginx
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    ports:
      - "19000:9000"
      - "19001:9001"
    depends_on:
      - minio1
      - minio2
      - minio3

3. 扩容方案

MinIO不支持横向扩容，但它提供了另外的解决方案，把高难度的动态扩展问题转化为了部署问题，简单来说就是如果需要扩容，只需部署新的独立集群，由业务方自行控制数据存储在哪个集群上。

一般来说有以下几种方案：

• 将集群信息动态添加到URL中，用域名或bucket或object id的编码识别集群号
• 在请求header中加入集群信息
• 使用中心KV服务，将每个资源的ID和集群映射起来，这样中心KV可能就会成为瓶颈点，可以使用一些高性能KV来实现。

4. 备份方案

由于预计数据量过大，可以使用rclone工具进行数据同步，把minio集群bucket的对象数据同步到备份服务器，备份服务器配置可以低一些，但是存储空间需要满足minio集群存储空间的一半(如果minio集群存储空间一共48T那备份服务器需要24T的空间来备份数据)。

留言：