k8s 1.28.2 集群部署 MinIO 分布式集群

文章目录

• • @[toc]
  • MinIO 介绍
  • • MinIO 生产硬件要求
    • MinIO 存储要求
    • MinIO 内存要求
    • MinIO 网络要求
    • MinIO 部署架构
    • • 分布式 MinIO
      • 复制的 MinIO
  • 部署 MinIO
  • • 创建目录
    • 节点打标签
    • 创建 namespace
    • 创建 pv
    • 创建 MinIO
    • 配置 ingress
    • 问题记录
    • • 通过代理服务器访问 MinIO 的 `Object Browser` 界面一直显示 loading

MinIO 介绍

• MinIO 官网
• MinIO 官方 linux 的部署文档
• 以下内容从官方翻译

• MinIO 是一款软件定义的高性能分布式对象存储服务器
• 所有 MinIO 部署都实施纠删码后端
  • MinIO 有以下三种拓扑
    • SNSD 或者 Standalone：Single-Node Single-Drive，单节点驱动器
      • 除了底层存储卷实现的范围之外，它不会提供额外的可靠性或可用性。这些部署最适合本地测试和评估，或者没有可用性或性能要求的小型数据工作负载。
    • SNMD 或者 Standalone Multi-Drive：Single-Node Multi-Drive，单节点多驱动器
      • 性能、规模和容量要求较低的工作负载
      • 驱动器级可靠性，具有可配置的容差，可丢失高达 1/2 的所有驱动器
    • MNMD 或者 Distributed：Multi-Node Multi-Drive，多节点多驱动器或分布式
      • 提供企业级性能、可用性和可扩展性，是所有生产工作负载的推荐拓扑，该配置可容忍部署中最多丢失一半的节点或驱动器，同时继续提供读取操作
      • 多节点 / 驱动器级可靠性，可配置的容差，损失高达 1/2 所有节点 / 驱动器
      • AI/ML、分布式查询、分析和其他数据湖组件的主存储
      • 可针对 PB + 工作负载进行扩展 - 存储容量和性能
• 站点复制（Site Replication）
  • 站点复制扩展了存储桶复制的功能，包括在所有站点中都相同的 IAM、安全令牌、访问密钥和存储桶功能
  • 站点复制将多个 MinIO 部署链接在一起，并使存储桶、对象和 Identity and Access Management （IAM） 设置在所有连接的站点之间保持同步
  • 每个 MinIO 部署（“对等站点”）都会在其他对等站点之间同步以下更改：
    • 创建、修改和删除存储桶和对象
      • 存储桶和对象配置
      • Policies
      • mc tag set
      • Locks，锁定，包括保留和依法保留配置
      • 加密设置
  • 创建和删除 IAM 用户、组、策略以及到用户或组的策略映射（适用于 LDAP 用户或组）
  • 为可从本地 root 凭据验证的会话令牌创建安全令牌服务 （STS） 凭据
  • 创建和删除访问密钥（root 用户拥有的密钥除外）
  • 站点复制为所有复制站点上的所有新存储桶和现有存储桶启用存储桶版本控制
• Not Replicate
  • 并非所有内容都可以跨站点复制
    • 存储桶通知
    • 生命周期管理 （ILM） 配置
    • 站点配置设置

MinIO 生产硬件要求

• Production Hardware Recommendations

• 以下清单遵循 MinIO 的生产部署推荐配置。提供的指南旨在作为基准，不能取代 MinIO SUBNET 性能诊断、架构审查和直接工程支持
• 与任何分布式系统一样，MinIO 受益于为给定服务器池中的所有节点选择相同的配置。确保在池节点之间一致地选择硬件（CPU、内存、主板、存储适配器）和软件（操作系统、内核设置、系统服务）
• 如果节点具有不同的硬件或软件配置，则部署可能会表现出不可预测的性能。受益于在低成本硬件上存储过时数据的工作负载应部署专用的 “暖” 或 “冷” MinIO 部署，并将数据转换到该层

• 以下方面对 MinIO 性能的影响最大，按重要性顺序列出

• 以上最低建议反映了 MinIO 在协助企业客户在各种 IT 基础设施上部署同时保持所需 SLA/SLO 的经验。
• 虽然 MinIO 可能在低于建议的最低拓扑上运行，但任何潜在的成本节省都存在可靠性、性能或整体功能降低的风险

MinIO 存储要求

• storage

• 使用本地存储

  • 与网络存储（NAS、SAN、NFS）相比，直连存储 （DAS） 具有显著的性能和一致性优势。MinIO 强烈建议将闪存存储（NVMe、SSD）用于主数据或 “热” 数据

• 使用 XFS 文件系统

  • MinIO 强烈建议配置 XFS 格式的文件系统进行存储。MinIO 使用 XFS 作为内部测试和验证套件的一部分，为所有规模的性能和行为提供额外的信心

    • 将驱动器格式化为 XFS，并将它们作为 JBOD 阵列呈现给 MinIO，没有 RAID 或其他池配置。使用任何其他类型的后备存储（SAN/NAS、ext4、RAID、LVM）通常会导致性能、可靠性、可预测性和一致性降低

  • 禁用 XFS 出错时重试

    • MinIO 强烈建议对以下错误类使用 max_retries 配置禁用 retry-on-error 行为

      • EIO ：读取或写入时出错
      • ENOSPC ：device no space left on device
      • default ：所有其他错误

    • 默认的 max_retries 设置通常指示文件系统无限期地在出错时重试，而不是传播错误。MinIO 可以适当地处理 XFS 错误，因此 retry-on-error 行为最多会导致不必要的延迟或性能下降。

    • 下面是官方提供的脚本，遍历指定挂载路径上的所有驱动器，并将建议的错误类的 XFS max_retries 设置设置为 0 或 “fail immediately on error”。该脚本会忽略任何未挂载的驱动器，无论是手动挂载还是通过 /etc/fstab 挂载。修改 /mnt/drive 行以匹配用于 MinIO 驱动器的模式

      • 必须在所有 MinIO 节点上运行此脚本，并将脚本配置为在重新启动时重新运行，因为 Linux 操作系统通常不会保留这些更改

      • #!/bin/bash
        
        for i in $(df -h | grep /mnt/drive | awk '{ print $1 }'); do
              mountPath="$(df -h | grep $i | awk '{ print $6 }')"
              deviceName="$(basename $i)"
              echo "Modifying xfs max_retries and retry_timeout_seconds for drive $i mounted at $mountPath"
              echo 0 > /sys/fs/xfs/$deviceName/error/metadata/EIO/max_retries
              echo 0 > /sys/fs/xfs/$deviceName/error/metadata/ENOSPC/max_retries
              echo 0 > /sys/fs/xfs/$deviceName/error/metadata/default/max_retries
        done
        exit 0
        

• 使用一致类型的驱动器

  • MinIO 不区分驱动器类型，并且不会从混合存储类型中受益。每个池必须使用相同的类型（NVMe、SSD）
  • 例如，部署一个仅包含 NVMe 驱动器的池。如果您将某些驱动器部署为 SSD 或 HDD，则 MinIO 会将这些驱动器视为与 NVMe 驱动器相同。这可能会导致性能问题，因为某些驱动器具有不同或更差的读 / 写特性，并且无法以与 NVMe 驱动器相同的速率响应

• 使用一致大小的驱动器

  • MinIO 将每个驱动器使用的大小限制为部署中的最小驱动器
  • 例如，部署一个由相同数量的 NVMe 驱动器组成的池，这些驱动器具有相同的容量 7.68TiB。如果使用 3.84TiB 部署一个驱动器，则 MinIO 会将池中的所有驱动器视为具有较小的容量

• 在重新启动后保留驱动器挂载和映射

  • Linux 操作系统，需要确保在 /etc/fstab 配置了驱动器挂载
    • MinIO 强烈建议使用基于标签（mkfs.x