运维

• 1: MinIO Kubernetes Operator
• 2: 安装 Silo Server
• 3: 安装与管理
• 4: 部署 Silo Tenant
• 5: 使用 cert-manager 管理 Operator 证书
• 6: 使用 Helm 部署 Operator
• 7: 在 Kubernetes 上部署 Silo
• 8: 在 RHEL 兼容 Linux 上部署 Silo
• 9: 升级 MinIO Operator
• 10: 升级 Silo 部署
• 11: 使用 Helm Charts 部署 Silo Tenant
• 12: 使用 MinIO Operator 的 Silo 租户
• 13: 在 Ubuntu Linux 上部署 Silo
• 14: 在裸机上部署 Silo
• 15: 站点复制概览
• 16: 租户的 cert-manager
• 17: 核心运维概念
  • 17.1: 部署架构
  • 17.2: 可用性与韧性
  • 17.3: 纠删码
  • 17.4: 对象自愈
  • 17.5: 对象扫描器
  • 17.6: 阈值与限制
• 18: 扩展分布式 Silo 部署
• 19: 修改 Silo Tenant
• 20: 以容器方式部署 Silo
• 21: 监控与告警
  • 21.1: 使用 Prometheus 进行监控与告警
  • 21.2: 指标与告警
  • 21.3: 将服务日志或审计日志发布到外部服务
  • 21.4: 使用 InfluxDB 进行监控与告警
  • 21.5: Metrics version 2
  • 21.6: 健康检查 API
  • 21.7: 使用 Grafana 监控 Silo 服务端
• 22: 升级 Silo Tenant
• 23: 退役 服务器池
• 24: 在 macOS 上部署 Silo
• 25: 从 Gateway 或 Filesystem 模式迁移
• 26: 扩展 Silo Tenant
• 27: 外部身份管理
  • 27.1: 配置 Silo 使用 Active Directory / LDAP 进行认证
  • 27.2: 配置 Silo 使用 Keycloak 进行认证
  • 27.3: 配置 Silo 使用 OpenID 进行认证
• 28: 在 Windows 上部署 Silo
• 29: 删除 Silo Tenant
• 30: 数据加密（SSE）
  • 30.1: 使用 KES 进行服务端对象加密
• 31: 网络加密（TLS）
  • 31.1: 为 Silo 启用 TLS
  • 31.2: 为 Silo 启用多域 TLS
  • 31.3: cert-manager
• 32: 部署检查清单
  • 32.1: 硬件检查清单
  • 32.2: 安全检查清单
  • 32.3: 软件检查清单
• 33: 硬件故障恢复
  • 33.1: 驱动器故障恢复
  • 33.2: 节点故障恢复
  • 33.3: 站点故障恢复
• 34: 故障排查
  • 34.1: 加密文件
• 35: 升级旧版 MinIO Operator

1 - MinIO Kubernetes Operator

Silo 是兼容 S3 的对象存储。MinIO Operator 是上游 Kubernetes 组件，其仓库已于 2026-03-20 归档并设为只读。最后一个版本 v7.1.1 可以通过 Tenant CRD 管理 Silo 服务端镜像。Operator 名称、API 组、CRD kind、资源名、镜像名和环境变量都属于上游契约，因此不在此改名。

MinIO Operator 会安装 Custom Resource Definition (CRD)，其中包括用于把托管对象存储工作负载描述为 Kubernetes object 的 Tenant kind。

固定的 v7.1.1 Kustomize 清单会在 minio-operator 命名空间部署一个 minio-operator Deployment，其中包含两个控制器副本；它不会部署独立的 Operator Console pod。

本站验证的是部署示例中的 Silo 镜像覆盖。归档后的 Operator 不再有持续的上游平台支持或商业支持承诺，本站也不会建立此类承诺。

上游 CRD 契约请参阅固定版本的 MinIO Operator v7.1.1 CRD Reference。

Operator 前提条件

Kubernetes 版本

归档的 v7.1.1 README 要求 Kubernetes 1.30.0 或更高版本。请选择仍在维护且 API 兼容的 Kubernetes 版本，并在自己的集群中验证精确组合。可参阅 受维护的 Kubernetes 版本 与 Operator v7.1.1 发布页；Silo 不另行声明更宽的平台支持矩阵。

如果 Kubernetes 基础设施运行的是生命周期已结束的 API 版本，在部署 Operator 时可能出现意料之外或不期望的行为。

Kustomize 和 kubectl

Kustomize 是一个基于 YAML 的模板工具，可让你以声明式、可重复的方式定义 Kubernetes 资源。 Kustomize 已内置在 kubectl 命令行工具中。

本步骤默认你的本地主机既安装了与 Kubernetes 集群版本匹配的 kubectl，也具备在该集群中创建新资源所需的访问权限。

固定版本的 MinIO Operator v7.1.1 Kustomize 模板 提供了可复现的起点。你可以修改该 Kustomization 文件，或应用自己的 patches 适配集群。不要推断还存在受支持的上游新版；任何分支或替代实现都必须独立审查。

Kubernetes TLS Certificate API

MinIO Operator 使用 Kubernetes certificates.k8s.io TLS certificate management API 管理 TLS Certificate Signing Requests (CSR)，并在以下场景中创建已签名的 TLS 证书：

• 当启用 autoCert 时。
• 当 MINIO_CONSOLE_TLS_ENABLE 环境变量设置为 on 时，用于 Tenant Console。
• 当 OPERATOR_STS_ENABLED 环境变量设置为 on 时，用于 STS service。
• 用于获取集群健康状态。

MinIO Operator 会读取 operator-ca-tls secret 中的证书，并在 tenant 命名空间内同步该 secret，以信任私有证书颁发机构，例如使用 cert-manager 时的场景。

在上述任一场景下，MinIO Operator 都 要求 Kubernetes kube-controller-manager 的配置中包含以下 配置项：

• --cluster-signing-key-file - 指定用于签发集群级证书的 PEM 编码 RSA 或 ECDSA 私钥。
• --cluster-signing-cert-file - 指定用于签发集群级证书的 PEM 编码 x.509 Certificate Authority 证书。

Kubernetes TLS API 会使用 CA 的签名算法生成新证书。与 RSA 相比，ECDSA（例如 NIST P-256 curve）或 EdDSA（例如 Curve25519）通常需要更少的计算资源。Silo 服务端支持的套件请参阅 支持的 TLS Cipher Suite。

如果 Kubernetes 集群未配置为对生成的 CSR 作出响应，Operator 将无法完成初始化。 某些 Kubernetes 提供方默认不会指定这些配置值。

若要检查 kube-controller-manager 是否指定了集群签名密钥和证书文件，请使用以下命令：

kubectl get pod kube-controller-manager-$CLUSTERNAME-control-plane \
  -n kube-system -o yaml

• 将 $CLUSTERNAME 替换为 Kubernetes 集群名称。

确认输出中包含高亮标出的行。 上例命令的输出可能与你终端中的实际输出不同：

 spec:
 containers:
 - command:
     - kube-controller-manager
     - --allocate-node-cidrs=true
     - --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf
     - --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf
     - --bind-address=127.0.0.1
     - --client-ca-file=/etc/kubernetes/pki/ca.crt
     - --cluster-cidr=10.244.0.0/16
     - --cluster-name=my-cluster-name
     - --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt
     - --cluster-signing-key-file=/etc/kubernetes/pki/ca.key
 ...

2 - 安装 Silo Server

请使用当前的 服务端制品 与本节的平台说明，在物理机或虚拟化主机上安装 Silo。可执行文件、服务、软件包与环境变量契约仍保留 MinIO 兼容名称。

3 - 安装与管理

本节介绍如何在 Kubernetes 和 裸机或虚拟化 基础设施上安装与管理采用 AGPLv3 许可的 Silo 对象存储服务端。

minio 可执行文件、MINIO_* 环境变量、S3 与 Admin API、盘上格式，以及 MinIO Operator 资源名都是兼容契约。叙述使用 Silo 品牌，命令和标识符则保留兼容名称。

Silo 是兼容 S3 的软件定义分布式对象存储服务端。下载页面 是当前已发布操作系统与架构制品的事实来源。

Silo 使用 纠删码 保护对象数据。你可以选择以下拓扑：

单机单盘 （SNSD，即”单机”模式）

适用于本地开发与评估，可靠性有限或无冗余

单机多盘 （SNMD，即”单机多盘”模式）

适用于对性能、规模和容量要求较低的工作负载

提供驱动器级可靠性，可配置为最多容忍 1/2 驱动器丢失

适合评估多驱动器拓扑和故障切换行为。

多机多盘 （MNMD，即”分布式”模式）

企业级高性能对象存储

提供节点/驱动器级可靠性，可配置为最多容忍 1/2 节点/驱动器丢失

可作为 AI/ML、分布式查询、分析及其他数据湖组件的主存储

可扩展到 PB+ 级工作负载，同时扩展存储容量与性能

Kubernetes

已经归档的 MinIO Kubernetes Operator v7.1.1 可以管理运行 Silo 服务端镜像的 Tenant 资源。Operator、Chart、CRD 与 Tenant Kind 保留上游名称；其上游发布周期现已冻结。

这些保留的 Operator 指南描述一份兼容快照。上游仓库已于 2026-03-20 归档，因此请根据 Kubernetes 发行版验证 v7.1.1，并将 Tenant 镜像覆盖为 pgsty/minio；Silo 项目不继承上游原厂商曾经的平台支持矩阵声明。

• 使用 Helm 部署 Silo Tenant
• 部署 MinIO Operator
• 查看 Kubernetes 部署说明

裸金属

Silo 可以运行在物理机、虚拟化主机或容器中。请查阅当前下载矩阵和各平台页面，确认已验证的制品与范围。

• 在 Red Hat Linux 上部署 Silo
• 在 Ubuntu Linux 上部署 Silo
• 以容器方式部署 Silo
• 在 macOS 上部署 Silo
• 在 Windows 上部署 Silo

4 - 部署 Silo Tenant

本步骤说明如何使用 MinIO Operator v7.1.1 管理运行 Silo 服务端镜像的 Tenant。上游 Operator 仓库已于 2026-03-20 归档并设为只读，因此这是一份冻结的兼容基线，而不是仍在维护的 Operator 路径。MinIO Operator、Tenant、minio.min.io API 组以及 CRD 字段名属于上游 Kubernetes 契约，因此保留原名。

下文验证过的基线会创建一个四服务端 Tenant。单节点拓扑适合本地测试，但其生产故障模型与存储布局不在本文档覆盖范围内。

本文档默认你已经熟悉所有被引用的 Kubernetes 概念、工具和操作流程。 虽然本文档 可能 会以 best-effort 方式提供 Kubernetes 相关资源的配置或部署指导，但它不能替代官方 Kubernetes Documentation。

使用 Kustomize 部署 Silo Tenant

以下步骤使用 MinIO Operator v7.1.1 仓库 中的 base Kustomization 模板，然后将其中默认的上游 MinIO 镜像替换为固定版本的 Silo 镜像。

你也可以从 v7.1.1 的其他 示例 中选择起点，或者依据 MinIO Custom Resource Documentation 自行构建资源。上游没有更晚的受支持版本；离开此固定快照前，应独立审查任何分支、替代实现或 CRD 变化。

本步骤并未穷尽 Tenant CRD 中的所有可配置项。 它只提供一个基线，你可以在此基础上按需修改和定制 Tenant。

1. 为 Tenant 创建 YAML 对象

   克隆固定版本的 Operator，并使用 kubectl kustomize 生成一个 YAML 文件，其中包含部署 base Tenant 所需的全部 Kubernetes 资源：

   git clone --branch v7.1.1 --depth 1 https://github.com/minio/operator.git
   kubectl kustomize operator/examples/kustomization/base > tenant-base.yaml

   该命令会创建一个单独的 YAML 文件，多个对象之间使用 --- 分隔。 请使用你偏好的编辑器打开此文件。

   上游模板默认使用 quay.io/minio/minio。应用前，请在 kind: Tenant 对象中把 spec.image 改为已验证的 Silo 版本，并关闭继承而来的原地更新器：

   spec:
     image: pgsty/minio:RELEASE.2026-08-04T00-00-00Z
     env:
       - name: MINIO_UPDATE
         value: "off"

   请按标签或摘要固定镜像。若选择更新的 Silo 镜像，应单独审查并测试该版本，而不是沿用 Operator 模板中的上游镜像。

   下文各步骤将根据对象的 kind 和 metadata.name 字段来引用这些对象：

2. 配置 Tenant 拓扑

   kind: Tenant 对象用于描述由 MinIO Operator 管理的 Silo 工作负载。

   以下字段都带有 spec.pools[0] 前缀，用于控制 Tenant 中所有 pod 的 server 数量、每个 server 的卷数量以及存储类：

   字段	描述
   servers	要在服务器池中部署的 Silo pod 数量。
   volumesPerServer	每个 Silo pod（servers）要挂载的持久卷数量。 Operator 会为该 Tenant 生成 volumesPerServer x servers 个 Persistent Volume Claim。
   volumeClaimTemplate.spec.storageClassName	与生成的 Persistent Volume Claim 关联的 Kubernetes 存储类。 如果不存在与指定值匹配的存储类，或者 指定的存储类无法满足所请求的 PVC 数量或存储容量，Tenant 可能无法启动。
   volumeClaimTemplate.spec.resources.requests.storage	为每个生成的 PVC 请求的存储容量。

3. 配置 Tenant Affinity 或 Anti-Affinity

   MinIO Operator 支持以下 Kubernetes Affinity 和 Anti-Affinity 配置：

   • Node Affinity (spec.pools[n].nodeAffinity)
   • Pod Affinity (spec.pools[n].podAffinity)
   • Pod Anti-Affinity (spec.pools[n].podAntiAffinity)

   生产环境应为 Tenant 配置 Pod Anti-Affinity，避免 Kubernetes 调度器将多个 Tenant pod 放到同一个 worker node 上。

   如果你希望将 Tenant 部署到特定 worker node 上，请将对应的 node label 或过滤条件传入 nodeAffinity 字段，以约束调度器仅在这些节点上放置 pod。

4. 配置网络加密

   MinIO Tenant CRD 提供以下字段，用于配置 Tenant 的 TLS 网络加密：

   字段	描述
   spec.requestAutoCert	启用或禁用 Silo 自动 TLS 证书生成。 若省略该字段，默认值为 true。
   spec.certConfig	在启用的情况下，自定义 自动 TLS 的行为。
   spec.externalCertSecret	通过 Server Name Indication (SNI) 为多个主机名启用 TLS 指定一个或多个类型为 kubernetes.io/tls 或 cert-manager 的 Kubernetes secret。
   spec.externalCaCertSecret	启用对由未知、第三方或内部 Certificate Authorities (CA) 签发的客户端 TLS 证书的校验。 指定一个或多个类型为 kubernetes.io/tls 的 Kubernetes secret，其中包含某个 CA 的完整证书链。

5. 配置 Silo 环境变量

   Silo 保留上游 MINIO_* 环境变量契约。你可以通过 Tenant CRD 的 spec.configuration 字段所引用的 Secret 提供这些变量，也可以使用 spec.env 设置 MINIO_UPDATE 等单项变量。

   字段	描述
   spec.configuration.name	指定一个 Kubernetes opaque Secret，其 config.env 键包含要设置的上游兼容环境变量。 按 v7.1.1 基础模板使用 stringData.config.env 时填写明文；若改用 data.config.env，其值必须经过 base64 编码。

   该 YAML 中包含一个 kind: Secret 且 metadata.name: storage-configuration 的对象，用于设置 root 用户名、密码、纠删码校验设置，以及启用 Tenant Console。

   请根据 Tenant 的实际需求修改这些值。

6. 检查命名空间

   YAML 对象 kind: Namespace 将 Tenant 的默认命名空间设置为 minio-tenant。

   你可以修改该值，为 Tenant 创建不同的命名空间。 你必须同时修改 YAML 文件中 所有 metadata.namespace 的值，使其与该命名空间保持一致。

7. 部署 Tenant

   使用 kubectl apply -f 命令部署 Tenant。

   kubectl apply -f tenant-base.yaml

   该命令会在配置好的命名空间中创建 YAML 对象里定义的每一项资源。

   你可以使用以下命令监控进度：

   watch kubectl get all -n minio-tenant

8. 暴露 Tenant 的 S3 API 端口

   若要在本地机器上测试 Silo 客户端 mc，请转发 S3 API 端口并创建别名。

   • 转发 Tenant 的 S3 API 端口：

   kubectl port-forward svc/MINIO_TENANT_NAME-hl 9000 -n MINIO_TENANT_NAMESPACE

   • 为 Tenant 服务创建别名：

   mc alias set myminio https://localhost:9000 minio minio123 --insecure

   你可以使用 mc mb 在 Tenant 上创建存储桶：

   mc mb myminio/mybucket --insecure

   如果你为 Tenant 部署的是由受信任 Certificate Authority (CA) 签发的 TLS 证书，则可以省略 --insecure 参数。

   具体说明请参阅 连接到 Tenant。

连接到 Tenant

MinIO Operator 会为 Silo Tenant 创建 Kubernetes Service；这些生成名称仍属于 Operator 契约。

使用 kubectl get svc -n NAMESPACE 命令查看已部署的服务。 如果你的 Kubernetes 环境使用自定义的 kubectl 替代程序，也可以替换为对应程序名。

kubectl get svc -n minio-tenant-1

NAME                               TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
minio                              LoadBalancer   10.97.114.60     <pending>     443:30979/TCP    2d3h
TENANT-NAMESPACE-console           LoadBalancer   10.106.103.247   <pending>     9443:32095/TCP   2d3h
TENANT-NAMESPACE-hl                ClusterIP      None             <none>        9000/TCP         2d3h

• minio 服务暴露 Tenant S3 API。应用程序应通过该服务对 Silo 执行 S3 操作。
• *-console 服务暴露 Silo Console。管理员可以通过该服务进行浏览器管理。

其余服务用于支撑 Tenant 内部操作，并不面向用户或管理员直接使用。

默认情况下，每个服务仅在 Kubernetes 集群内部可见。 部署在集群内部的应用可以通过 CLUSTER-IP 访问这些服务。

位于 Kubernetes 集群外部的应用可以通过 EXTERNAL-IP 访问这些服务。 该值只有在 Kubernetes 集群配置了 Ingress 或类似网络访问服务时才会被填充。 Kubernetes 提供了多种对 service 开放外部访问的方式。

有关如何配置 service 的外部访问，请参阅 Kubernetes 文档中的 Publishing Services (ServiceTypes) 和 Ingress。

对于 OpenShift、Rancher 等特定 Kubernetes 发行版，请以其服务文档中关于对内或对外暴露 Service 的首选或可用方式为准。

5 - 使用 cert-manager 管理 Operator 证书

MinIO Operator 负责管理 minio-operator 命名空间中各服务的 TLS 证书签发。

本页说明如何使用 cert-manager 管理 Operator 的 TLS 证书。

前提条件

• 使用受支持版本的 Kubernetes
• 已安装 kustomize
• 可以通过 kubectl 访问你的 k8s 集群
• 已完成 cert-manager 配置
• MinIO Operator 尚未安装

1) 为 minio-operator 命名空间创建 CA Issuer

本指南将 禁用 MinIO Operator 的自动证书生成功能，改为使用 cert-manager 签发证书。

minio-operator 命名空间必须拥有自己的证书颁发机构（CA），该 CA 派生自你在 配置 cert-manager 时创建的集群 ClusterIssuer 证书。 请使用 cert-manager 创建此 CA 证书。

1. 如果 minio-operator 命名空间尚不存在，请先创建：

   kubectl create ns minio-operator

2. 申请一个新的 Certificate，并设置 spec.isCA: true。

   该证书将作为 minio-operator 命名空间的 CA 使用。

   创建一个名为 operator-ca-tls-secret.yaml 的文件，内容如下：

   # operator-ca-tls-secret.yaml
   apiVersion: cert-manager.io/v1
   kind: Certificate
   metadata:
     name: minio-operator-ca-certificate
     namespace: minio-operator
   spec:
     isCA: true
     commonName: operator
     secretName: operator-ca-tls
     duration: 70128h # 8y
     privateKey:
       algorithm: ECDSA
       size: 256
     issuerRef:
       name: selfsigned-root
       kind: ClusterIssuer
       group: cert-manager.io

   警告

   重要

   spec.issueRef.name 必须与 配置 cert-manager 时创建的 ClusterIssuer 名称一致。 如果你使用了不同的 ClusterIssuer 名称，或者使用了与本指南不同的 Issuer，请根据你的环境调整 issuerRef。

3. 应用该资源：

   kubectl apply -f operator-ca-tls-secret.yaml

Kubernetes 会在 minio-operator 命名空间中创建一个名为 operator-ca-tls 的新 Secret。

2) 使用该 Secret 创建 Issuer

使用 operator-ca-tls Secret 为 minio-operator 命名空间创建一个 Issuer 资源。

1. 创建一个名为 operator-ca-issuer.yaml 的文件，内容如下：

   # operator-ca-issuer.yaml
   apiVersion: cert-manager.io/v1
   kind: Issuer
   metadata:
     name: minio-operator-ca-issuer
     namespace: minio-operator
   spec:
     ca:
       secretName: operator-ca-tls

2. 应用该资源：

   kubectl apply -f operator-ca-issuer.yaml

3) 创建 TLS 证书

现在 Issuer 已存在于 minio-operator 命名空间中，cert-manager 可以开始签发证书。

cert-manager 签发的证书必须对以下 DNS 名称有效：

• sts

• sts.minio-operator.svc.

• sts.minio-operator.svc.<cluster domain>

  警告

  重要

  将 <cluster domain> 替换为你的环境实际使用的值。 cluster domain 是 Kubernetes 集群内部的根 DNS 域。 该值通常为 cluster.local，但你仍应检查 CoreDNS 配置，以确认 Kubernetes 集群实际使用的值。

  例如：

  kubectl get configmap coredns -n kube-system -o jsonpath="{.data}"

  不同 Kubernetes 发行版或托管平台对根域名的管理方式可能不同。 更多信息请参阅你的 Kubernetes 提供方文档。

1. 为上述 DNS 名称创建一个 Certificate：

   创建一个名为 sts-tls-certificate.yaml 的文件，内容如下：

   # sts-tls-certificate.yaml
   apiVersion: cert-manager.io/v1
   kind: Certificate
   metadata:
     name: sts-certmanager-cert
     namespace: minio-operator
   spec:
     dnsNames:
       - sts
       - sts.minio-operator.svc
       - sts.minio-operator.svc.cluster.local # Replace cluster.local with the value for your domain.
     secretName: sts-tls
     issuerRef:
       name: minio-operator-ca-issuer

   警告

   重要

   spec.secretName 不是可选项。

   Secret 名称 必须 为 sts-tls。 请确认在证书 YAML 中按照高亮所示设置 spec.secretName: sts-tls。

2. 应用该资源：

   kubectl apply -f sts-tls-certificate.yaml

这会在 minio-operator 命名空间中创建一个名为 sts-tls 的 Secret。

4) 在禁用 Auto TLS 的情况下安装 Operator

现在你可以 安装 MinIO Operator。

安装 Operator 时，请在 minio-operator 容器中将环境变量 OPERATOR_STS_AUTO_TLS_ENABLED 设置为 off。

禁用该环境变量后，MinIO Operator 将不再自行签发证书。 此时 Operator 将依赖 cert-manager 签发 TLS 证书。

环境变量的具体定义方式取决于你的 Operator 安装方式。 以下步骤演示如何使用 kustomize 配置该变量。

1. 创建一个名为 kustomization.yaml 的 kustomization patch 文件，内容如下：

   # minio-operator/kustomization.yaml
   apiVersion: kustomize.config.k8s.io/v1beta1
   kind: Kustomization
   
   resources:
   - github.com/minio/operator/resources
   
   patches:
   - patch: |-
       apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: minio-operator
         namespace: minio-operator
       spec:
         template:
           spec:
             containers:
               - name: minio-operator
                 env:
                   - name: OPERATOR_STS_AUTO_TLS_ENABLED
                     value: "off"
                   - name: OPERATOR_STS_ENABLED
                     value: "on"

2. 将该 kustomization 资源应用到集群：

   kubectl apply -k minio-operator

将现有 MinIO Operator 部署迁移到 cert-manager

如果要将现有 MinIO Operator 部署从 AutoCert 迁移到 cert-manager，请完成以下步骤：

1. 完成 安装 cert-manager 的步骤，并禁用 auto-cert。
2. 完成本页步骤 1 到 3，为 Operator 创建证书颁发机构。
3. 执行本页中的安装步骤时，不再使用原有的 Operator TLS 证书，而改用 cert-manager 签发的证书。
4. 参照 用于租户的 cert-manager 页面，为每个租户创建新的 cert-manager 证书。
5. 使用每个租户对应的 cert-manager 证书 Secret，替换 MinIO Operator 命名空间中租户正在使用的 Secret。

后续步骤

继续配置 用于 MinIO 租户的 cert-manager。

6 - 使用 Helm 部署 Operator

概览

Helm 是一个用于将应用自动部署到 Kubernetes 集群的工具。 Helm chart 是一组定义部署细节的 YAML 文件、模板和其他文件。 以下步骤使用 Helm Chart 将 MinIO Kubernetes Operator 安装到 Kubernetes 集群中。

前提条件

基础要求请参阅 Operator 前提条件。 使用 Helm 安装还需要满足以下额外要求：

• Helm 使用与你的 Kubernetes API 版本匹配的 Helm 版本。
• yq

有关 Operator 安装要求的更多信息，包括受支持的 Kubernetes 版本和 TLS 证书，请参阅 Operator 部署前提条件。

本步骤默认你已经熟悉相关 Kubernetes 概念和工具。 虽然本文档可能会以 best-effort 方式提供 Kubernetes 相关资源的配置或部署指导，但它不能替代官方 Kubernetes Documentation。

使用 Helm Charts 安装 MinIO Operator

以下步骤使用 MinIO Operator Chart Repository 安装 Operator。 与 本地 chart 安装 相比，这种方式的安装路径更简单。 安装完成后，你仍可继续修改 Operator 部署。

1. 将 MinIO Operator Repo 添加到 Helm

   已归档项目的仓库端点 https://operator.min.io 当前仍提供 v7.1.1 Chart。将该仓库添加到 Helm：

   helm repo add minio-operator https://operator.min.io

   你可以使用 helm search 验证仓库内容：

   helm search repo minio-operator

   返回结果应类似如下：

   NAME                            CHART VERSION   APP VERSION     DESCRIPTION
   minio-operator/minio-operator   4.3.7           v4.3.7          A Helm chart for MinIO Operator
   minio-operator/operator         7.1.1           v7.1.1          A Helm chart for MinIO Operator
   minio-operator/tenant           7.1.1           v7.1.1          A Helm chart for MinIO Operator

   minio-operator/minio-operator 是旧版 chart，正常情况下 不应 安装。

2. 安装 Operator

   运行 helm install 命令安装 Operator。 以下命令会指定并创建一个专用命名空间 minio-operator 用于安装。 MinIO 强烈建议为 Operator 使用专用命名空间。

   helm install \
     --namespace minio-operator \
     --create-namespace \
     --version 7.1.1 \
     operator minio-operator/operator

3. 验证 Operator 安装

   检查指定命名空间（minio-operator）中的内容，确保所有 pod 和 service 均已成功启动。

   kubectl get all -n minio-operator

   返回结果应类似如下：

   NAME                                  READY   STATUS    RESTARTS   AGE
   pod/minio-operator-699f797b8b-th5bk   1/1     Running   0          25h
   pod/minio-operator-699f797b8b-nkrn9   1/1     Running   0          25h
   
   NAME               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
   service/operator   ClusterIP   10.43.44.204    <none>        4221/TCP            25h
   service/sts        ClusterIP   10.43.70.4      <none>        4223/TCP            25h
   
   NAME                             READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/minio-operator   2/2     2            2           25h
   
   NAME                                        DESIRED   CURRENT   READY   AGE
   replicaset.apps/minio-operator-79f7bfc48    2         2         2       123m

现在你可以 使用 Helm Charts 部署租户。

使用本地 Helm Charts 安装 MinIO Operator

以下步骤使用 Helm Charts 的本地副本安装 Operator。 与 基于仓库的安装 相比，这种方式可能更便于在安装前完成 Operator 预配置。

1. 下载 Helm charts

   在本地主机上，将 Operator Helm charts 下载到一个合适的目录：

   curl -O https://operator.min.io/helm-releases/operator-7.1.1.tgz

2. （可选）修改 values.yaml

   该 chart 包含一个可按需定制的 values.yaml 文件。 有关 MinIO Operator values.yaml 可用选项的详细信息，请参阅 Operator Helm 图表。

   例如，你可以修改 operator.replicaCount 的副本数，以增加或减少部署中的 pod 可用性。 有关 Operator Helm Chart 和 Values 的更完整文档，请参阅 Operator Helm 图表。

   有关定制方式的更多信息，请参阅 Helm Charts。

3. 安装 Helm Chart

   使用 helm install 命令安装已下载的 Chart 归档文件。

   helm install \
   --namespace minio-operator \
   --create-namespace \
   minio-operator ./operator-7.1.1.tgz

4. 要验证安装，请运行以下命令：

   kubectl get all --namespace minio-operator

   如果你使用自定义命名空间初始化了 Operator，请将 minio-operator 替换为该命名空间。

   使用 Chart 默认值时，该命名空间中应包含一个具有两个就绪副本的 minio-operator Deployment、端口为 4221 的 operator ClusterIP Service，以及端口为 4223 的 sts ClusterIP Service。Pod 哈希、Cluster IP 与运行时长会因安装而异。

现在你可以 使用 Helm Charts 部署租户。

7 - 在 Kubernetes 上部署 Silo

Silo 是可在 Kubernetes 中运行的 S3 兼容对象存储服务端。MinIO Kubernetes Operator 的最后一个上游版本 v7.1.1 可以部署使用 Silo 镜像的 Tenant：将 tenant.image.repository 覆盖为 pgsty/minio，并固定经过测试的标签或摘要。

这些指南默认你熟悉所引用的 Kubernetes 概念、工具和操作流程。它们不能替代官方 Kubernetes Documentation；Silo 项目也不继承原 MinIO 厂商针对各 Kubernetes 发行版的支持矩阵。

MinIO Operator、Helm Chart、CRD 与 Tenant Kind 都是独立于 Silo 发布的上游契约。上游 minio/operator 仓库已于 2026-03-20 归档并设为只读，因此其发布周期已经冻结，这些指南只是一份兼容快照。

归档的 Operator 代码提供 MinIO 兼容的 Tenant 管理与配置功能。在部署或升级前，请针对实际集群验证固定的 Operator 与 Chart；上游不再提供持续的兼容性或支持承诺。

你可以通过 Operator 的 Custom Resource Definition (CRD) 与其交互。

CRD 为 Kustomize、Helm 和 kubectl 等工具部署与管理使用 Silo 镜像的 Tenant 提供可定制入口。

8 - 在 RHEL 兼容 Linux 上部署 Silo

本页介绍如何在 RHEL 及其二进制兼容 Linux 发行版上部署 Silo。

Silo 为 x86-64 与 ARM64 发布 RPM 软件包和独立 Linux 归档。项目没有单独发布 RHEL 支持生命周期矩阵，因此已删除继承文档中的时间点版本清单。请选择仍处于发行商支持期内的版本，保持内核与系统库更新，并在生产使用前验证精确的存储与工作负载配置。

本步骤重点介绍生产级 多机多盘 (MNMD)“Distributed”配置。 MNMD 部署可提供企业级性能、可用性和可扩展性，是所有生产工作负载的推荐拓扑。

本步骤也包含对 单机多盘 (SNMD) 和 单机单盘 (SNSD) 拓扑的指导，适用于早期开发和评估环境。

注意事项

检查清单

在执行本步骤前，请先阅读我们发布的硬件、软件和安全检查清单。

纠删码校验

MinIO 会根据拓扑中的节点和驱动器总数，自动为集群确定默认的 纠删码 配置。 你可以在设置集群时配置按对象生效的 parity，也可以让 MinIO 选择默认值（生产级集群默认为 EC:4）。

校验值决定了对象可用性与磁盘存储占用之间的关系。 可使用 MinIO 纠删码计算器 选择适合你集群的纠删码校验级别。

虽然你可以随时更改纠删码校验设置，但以既有校验值写入的对象 不会 自动更新为新的校验设置。

基于容量的规划

MinIO 建议在存储使用率达到 70% 之前，预先规划足以存放 至少 2 年数据的存储容量。 过于频繁地执行 服务器池 扩容，或按“just-in-time”方式扩容，通常说明架构或规划存在问题。

例如，假设某套应用每年预计至少生成 100 TiB 数据，并以 3 年后再扩容为目标。 若在部署初期就提供约 500 TiB 可用存储，集群即可在安全满足 70% 阈值的同时，为每年的数据增长预留额外缓冲。

建议使用 MinIO 纠删码计算器，围绕具体纠删码设置进行容量规划。

步骤

1. 下载 Silo RPM 包

从下载与安装获取 x86-64 或 ARM64 RPM，校验发布摘要后安装：

sudo dnf install ./minio-*.rpm

当前 Silo 发布不提供继承文档中提到的 ppc64le 或 s390x 软件包变体。

2. 查看 systemd 服务文件

.rpm 软件包会将以下 systemd 服务文件安装到 /usr/lib/systemd/system/minio.service：

[Unit]
Description=MinIO
Documentation=https://silo.pgsty.com/zh/docs/
Wants=network-online.target
After=network-online.target
AssertFileIsExecutable=/usr/local/bin/minio

[Service]
Type=notify

WorkingDirectory=/usr/local

User=minio-user
Group=minio-user
ProtectProc=invisible

EnvironmentFile=-/etc/default/minio
ExecStart=/usr/local/bin/minio server $MINIO_OPTS $MINIO_VOLUMES

# Let systemd restart this service always
Restart=always

# Specifies the maximum file descriptor number that can be opened by this process
LimitNOFILE=1048576

# Turn-off memory accounting by systemd, which is buggy.
MemoryAccounting=no

# Specifies the maximum number of threads this process can create
TasksMax=infinity

# Disable timeout logic and wait until process is stopped
TimeoutSec=infinity

# Disable killing of MinIO by the kernel's OOM killer
OOMScoreAdjust=-1000

SendSIGKILL=no

[Install]
WantedBy=multi-user.target

# Built for ${project.name}-${project.version} (${project.name})

3. 为 MinIO 创建用户和组

minio.service 文件默认以 minio-user 用户和组身份运行。 你可以使用 groupadd 和 useradd 命令创建该用户和组。 以下示例创建用户、组，并为计划供 MinIO 使用的文件夹路径设置访问权限。 这些命令通常需要 root（sudo）权限。

groupadd -r minio-user
useradd -M -r -g minio-user minio-user

以上命令创建的用户 不包含 主目录，这对系统服务账户来说是典型做法。

你 必须 对计划供 MinIO 使用的驱动器路径执行 chown。 如果 minio-user 用户或组无法读取、写入或列出任一驱动器的内容，MinIO 进程会在启动时返回错误。

例如，以下命令将 /mnt/drives-n 下所有驱动器的属主和属组设置为 minio-user:minio-user，其中 n 的范围为 1 到 16：

chown -R minio-user:minio-user /mnt/drives-{1...16}

4. 启用 TLS 连接

为 MinIO 创建或提供 传输层安全 (TLS) 证书，以自动启用 server 与客户端之间的 HTTPS 安全连接。

请将证书放置在 minio-user 用户/组可访问的目录中：

mkdir -p /opt/minio/certs
chown -R minio-user:minio-user /opt/minio/certs

cp private.key /opt/minio/certs
cp public.crt /opt/minio/certs

对于本地测试或开发环境，你可以使用 MinIO certgen 生成自签名证书。 例如，以下命令会生成一组带有 IP 和 DNS Subject Alternate Names (SANs) 的自签名证书，这些 SAN 与 MinIO 服务端 主机关联：

certgen -host "localhost,minio-*.example.net"

将生成的 public.crt 和 private.key 放入 /path/to/certs 目录，以为 MinIO 部署启用 TLS。 应用程序可以将 public.crt 作为受信任的证书颁发机构，从而在不禁用证书校验的情况下连接到 MinIO 部署。

当 MinIO 启用 TLS 运行时，它还会根据操作系统中的受信任证书颁发机构列表来验证连接客户端的证书。 若要启用对第三方证书或内部签发证书的验证，请将 CA 文件放入 /opt/minio/certs/CAs 目录。 CA 文件应包含从叶子证书到根证书的完整信任链，以确保验证成功。

有关为 MinIO 配置 TLS 的更具体指导，包括通过 Server Name Indication (SNI) 支持多域名，请参阅 网络加密（TLS）。 你也可以跳过此步骤，以在未启用 TLS 的情况下部署。MinIO 强烈 不建议 在早期开发之外的场景中进行非 TLS 部署。

5. 创建 MinIO 环境文件

在 /etc/default/minio 创建环境文件。 MinIO 服务将该文件作为 MinIO 以及 minio.service 文件所用全部 环境变量 的来源。

请根据你的部署拓扑修改示例。

# Set the hosts and volumes MinIO uses at startup
# The command uses MinIO expansion notation {x...y} to denote a
# sequential series.
#
# The following example covers four MinIO hosts
# with 4 drives each at the specified hostname and drive locations.
#
# The command includes the port that each MinIO server listens on
# (default 9000).
# If you run without TLS, change https -> http

MINIO_VOLUMES="https://minio{1...4}.example.net:9000/mnt/disk{1...4}/minio"

# Set all MinIO server command-line options
#
# The following explicitly sets the MinIO Console listen address to
# port 9001 on all network interfaces.
# The default behavior is dynamic port selection.

MINIO_OPTS="--console-address :9001 --certs-dir /opt/minio/certs"

# Set the root username.
# This user has unrestricted permissions to perform S3 and
# administrative API operations on any resource in the deployment.
#
# Defer to your organizations requirements for superadmin user name.

MINIO_ROOT_USER=minioadmin

# Set the root password
#
# Use a long, random, unique string that meets your organizations
# requirements for passwords.

MINIO_ROOT_PASSWORD=minio-secret-key-CHANGE-ME

# Set the volumes MinIO uses at startup
# The command uses MinIO expansion notation {x...y} to denote a
# sequential series.
#
# The following specifies a single host with 4 drives at the specified location
#
# The command includes the port that the MinIO server listens on
# (default 9000).
# If you run without TLS, change https -> http

MINIO_VOLUMES="https://minio1.example.net:9000/mnt/drive{1...4}/minio"

# Set all MinIO server command-line options
#
# The following explicitly sets the MinIO Console listen address to
# port 9001 on all network interfaces.
# The default behavior is dynamic port selection.

MINIO_OPTS="--console-address :9001 --certs-dir /opt/minio/certs"

# Set the root username.
# This user has unrestricted permissions to perform S3 and
# administrative API operations on any resource in the deployment.
#
# Defer to your organizations requirements for superadmin user name.

MINIO_ROOT_USER=minioadmin

# Set the root password
#
# Use a long, random, unique string that meets your organizations
# requirements for passwords.

MINIO_ROOT_PASSWORD=minio-secret-key-CHANGE-ME

# Set the volume MinIO uses at startup
#
# The following specifies the drive or folder path

MINIO_VOLUMES="/mnt/drive1/minio"

# Set all MinIO server command-line options
#
# The following explicitly sets the MinIO Console listen address to
# port 9001 on all network interfaces.
# The default behavior is dynamic port selection.

MINIO_OPTS="--console-address :9001 --certs-dir /opt/minio/certs"

# Set the root username.
# This user has unrestricted permissions to perform S3 and
# administrative API operations on any resource in the deployment.
#
# Defer to your organizations requirements for superadmin user name.

MINIO_ROOT_USER=minioadmin

# Set the root password
#
# Use a long, random, unique string that meets your organizations
# requirements for passwords.

MINIO_ROOT_PASSWORD=minio-secret-key-CHANGE-ME

请根据部署需要，指定其他 环境变量 或 server 命令行选项。

对于分布式部署，所有节点的 /etc/default/minio 环境文件 必须 完全一致。 可在每个节点上使用 shasum -a 256 /etc/default/minio 等工具验证其是否完全匹配。

6. 启动 MinIO 部署

使用 systemctl start minio 启动部署中的每个节点。

你可以在每个节点上使用 journalctl -u minio 跟踪启动状态。

启动成功后，MinIO 进程会输出一段部署摘要，类似如下：

MinIO 对象存储服务端
Copyright: 2015-2024 MinIO, Inc.
License: GNU AGPLv3 - https://www.gnu.org/licenses/agpl-3.0.html
Version: RELEASE.2024-06-07T16-42-07Z (go1.22.4 linux/amd64)

API: https://minio-1.example.net:9000 https://203.0.113.10:9000 https://127.0.0.1:9000
   RootUser: minioadmin
   RootPass: minioadmin

WebUI: https://minio-1.example.net:9001 https://203.0.113.10:9001 https://127.0.0.1:9001
   RootUser: minioadmin
   RootPass: minioadmin

CLI: https://silo.pgsty.com/zh/reference/minio-mc/#quickstart
   $ mc alias set 'myminio' 'https://minio-1.example.net:9000' 'minioadmin' 'minioadmin'

Docs: https://silo.pgsty.com/zh/docs/
Status:         16 Online, 0 Offline.

在集群启动和同步期间，你可能会看到日志明显增多。

启动失败的常见原因包括：

• MinIO 进程对指定驱动器没有读、写、列出权限
• 驱动器不是空的，或其中包含非 MinIO 数据
• 驱动器未正确格式化或挂载
• 一个或多个主机无法通过网络访问

遵循我们的检查清单通常可以降低遇到这些或类似问题的风险。

7. 连接到部署

Console

打开浏览器，并通过任一 MinIO 主机名的 :9001 端口访问 MinIO Console 登录页。 例如：https://minio1.example.com:9001。

使用上一步中的 MINIO_ROOT_USER 和 MINIO_ROOT_PASSWORD 登录。

你可以使用 MinIO Console 执行常规管理任务，例如身份与访问管理、指标和日志监控，或 Server 配置。 每个 MinIO server 都包含自身内嵌的 MinIO Console。

CLI

请按照本地主机上的 mc 安装说明 完成安装。 运行 mc --version 验证安装结果。

如果你的 MinIO 部署使用第三方或自签名 TLS 证书，请将 CA 文件复制到 ~/.mc/certs/CAs，以便 mc 信任该证书链。

安装完成后，为该 MinIO 部署创建一个别名：

mc alias set myminio https://minio-1.example.net:9000 USERNAME PASSWORD

请根据你的部署修改主机名、用户名和密码。 主机名可以是部署中的任意一个 MinIO 节点。 你也可以指定负责处理部署连接的负载均衡器、反向代理或类似网络控制平面的主机名。

8. 后续步骤

• 在可信网络之外暴露服务前，先启用 TLS。
• 通过身份与访问管理创建最小权限用户和策略。
• 配置监控与告警，并在投入生产前实际测试磁盘、节点与站点恢复流程。

9 - 升级 MinIO Operator

你可以随时升级 MinIO Operator，而不会影响其管理的 MinIO Tenant。

在升级过程中，Operator 可能会更新并重启 Tenant，以支持 MinIO 自定义资源定义（CRD）的变更。 这些变更不需要操作员或管理员采取额外操作，也不会影响 Tenant 的运行。

本页说明如何将 Operator 从 5.0.15 升级到 7.1.1。 如果在开始本流程前需要先升级到 Operator 5.0.15，请参阅 将 MinIO Operator 4.5.8 及更高版本升级到 5.0.15。

将 MinIO Operator 从 5.0.15 升级到 7.1.1

10 - 升级 Silo 部署

升级 Silo 时，应先在每个节点安装经过校验的服务端制品，再把整个部署作为一次协调操作重启。全量集群重启会造成短暂不可用；应用应重试失败或中断的请求，对象操作的原子性并不能替代重试处理。

本页覆盖由 systemctl 管理和手工管理的裸机部署。若服务由 Ansible、Terraform、容器或其他编排器管理，请通过该工具落实同样的发布、校验与重启边界，不要手工修改其管理的文件。

升级前准备

1. 备份集群设置。 使用 mc admin cluster bucket export 与 mc admin cluster iam export 导出存储桶元数据和 IAM 配置。
2. 选择已经公开发布的 Silo 版本。 以下载与安装、Silo 发布说明和 GitHub Releases为准。本地标签、分支提交、草稿 Release 或上传到草稿中的制品都不等于公开发布。
3. 校验制品。 将 SHA-256 摘要与该精确版本随附的校验和核对；所有节点固定到同一个版本。
4. 阅读跨越的全部发布说明。 特别关注格式、身份认证、配置和降级限制。
5. 在低环境验证完全相同的升级。 上生产前覆盖代表性的读写、策略、生命周期、复制、通知与恢复流程。
6. 禁用继承的原地更新器。 在服务端环境中设置 MINIO_UPDATE=off，并重启服务让配置生效。
7. 检查桶级策略中的对象级资源。 在导出的 IAM 配置里，查找那些把十二个桶级写动作之一（或 s3:*）授在含 / 的资源模式上、且同一个桶没有裸桶 ARN 的语句。这些语句不再授权那些动作。请在对象模式旁边补上裸桶 ARN，参见存储桶资源与对象资源。内置策略以及任何使用 arn:aws:s3:::* 的语句都不受影响。

systemctl 管理的部署

1. 从下载与安装为每个节点下载同一个公开服务端版本，并校验其摘要。

2. 在 不单独重启部分集群 的前提下，在每个节点安装软件包或替换二进制：

   RPM（RHEL 系）

   sudo dnf install /path/to/minio.rpm

   DEB（Debian/Ubuntu）

   sudo dpkg -i /path/to/minio.deb

   二进制

   sha256sum ./minio
   sudo install -m 0755 ./minio /usr/local/bin/minio

   如果安装位置不同，请把 /usr/local/bin/minio 替换成 command -v minio 返回的路径。

3. 在每个节点运行 minio --version。只有所有节点都报告同一个预期版本时才能继续。

4. 把所有服务端进程作为一次协调操作重启。管理 API 可用时执行：

   mc admin service restart ALIAS

   否则通过自动化在所有节点协调执行 systemctl restart minio。除非目标发布明确支持混合版本，否则不要临时改成滚动升级。

5. 使用 mc admin info 验证部署，然后测试代表性的 S3 读写、控制台访问、身份登录以及已配置的复制或通知。

6. 从下载与安装单独升级客户端。独立制品使用 mcli，源码构建与容器保留 mc。

手工管理的部署

对于由用户脚本或其他 supervisor 管理的进程，请在每个节点下载并校验同一个 Silo 二进制，替换 supervisor 实际使用路径上的可执行文件，确认 minio --version，再把所有节点作为一次协调操作重启。服务账户必须能够执行新二进制，执行替换的运维用户必须能够写入安装路径。

重启后执行与上文相同的验证。验证完成前保留上一个经过校验的二进制，使任何回滚决定都能遵循目标版本发布说明中的降级限制。

11 - 使用 Helm Charts 部署 Silo Tenant

概览

Helm 是一个用于将应用自动部署到 Kubernetes 集群的工具。 Helm chart 是一组定义部署细节的 YAML 文件、模板和其他文件。 以下步骤使用 Helm Chart 部署由 MinIO Operator 管理的 Tenant。

本步骤要求 Kubernetes 集群中已存在一个有效的 Operator 部署。 你不能使用 MinIO Operator Tenant chart 在脱离 Operator 的情况下独立部署 Tenant。

前提条件

要使用 Helm 安装 MinIO Tenant，你必须满足以下要求：

• 一个现有的 Kubernetes 集群
• 本地主机上安装了与集群版本匹配的 kubectl CLI 工具
• Helm 3.8 或更高版本
• yq 4.18.1 或更高版本
• 一个现有的 MinIO Operator 安装

本步骤默认你对 Kubernetes 集群的访问权限具备较广泛的管理能力。

有关 Tenant 安装要求的更多信息，包括受支持的 Kubernetes 版本和 TLS 证书，请参阅 Tenant 部署前提条件。

本步骤默认你已经熟悉相关 Kubernetes 概念和工具。 虽然本文档可能会以 best-effort 方式提供 Kubernetes 相关资源的配置或部署指导，但它不能替代官方 Kubernetes Documentation。

命名空间

租户必须使用自己的命名空间，不能与其他租户共享命名空间。 此外，MinIO 强烈建议为租户使用专用命名空间，且该命名空间内不要运行其他应用。

使用 Helm Charts 部署 Silo Tenant

以下步骤使用 MinIO Operator Chart Repository 部署 MinIO Tenant。 与 本地 chart 安装 相比，这种方式的安装路径更简单。

以下步骤使用 Helm 通过已归档上游项目的 v7.1.1 Tenant Chart 部署 MinIO Tenant。

本步骤并未穷尽 Tenant Chart 中所有可能的配置项。 它只提供一个基线，你可以在此基础上按需修改和定制 Tenant。

1. 验证 MinIO Operator Repo 配置

   已归档项目的端点 https://operator.min.io 当前仍提供 v7.1.1 Chart。 如果该仓库尚未存在于本地 Helm 配置中，请先添加后再继续：

   helm repo add minio-operator https://operator.min.io

   你可以使用 helm search 验证仓库内容：

   helm search repo minio-operator

   返回结果应类似如下：

   NAME                            CHART VERSION   APP VERSION     DESCRIPTION
   minio-operator/minio-operator   4.3.7           v4.3.7          A Helm chart for MinIO Operator
   minio-operator/operator         7.1.1           v7.1.1          A Helm chart for MinIO Operator
   minio-operator/tenant           7.1.1           v7.1.1          A Helm chart for MinIO Operator

2. 创建 Helm values.yaml 的本地副本以供修改

   curl -sLo values.yaml https://raw.githubusercontent.com/minio/operator/v7.1.1/helm/tenant/values.yaml

   请使用文本编辑器打开 values.yaml。继续之前，替换上游服务端镜像默认值，并禁用继承的原地更新器：

   tenant:
     image:
       repository: pgsty/minio
       tag: RELEASE.2026-08-04T00-00-00Z
       pullPolicy: IfNotPresent
     env:
       - name: MINIO_UPDATE
         value: "off"

   仅当更新标签已在 Silo 下载页 发布，并通过你的部署验证后才应使用。Silo 生产环境的 values 文件不应保留 quay.io/minio/minio 或 latest。

3. 配置 Tenant 拓扑

   以下字段都带有 tenant.pools[0] 前缀，用于控制 Tenant 中所有 pod 的 server 数量、每个 server 的卷数量以及存储类：

   字段	描述
   servers	要在 服务器池 中部署的 MinIO pod 数量。
   volumesPerServer	每个 MinIO pod（servers）要挂载的持久卷数量。 Operator 会为该 Tenant 生成 volumesPerServer x servers 个 Persistent Volume Claim。
   storageClassName	与生成的 Persistent Volume Claim 关联的 Kubernetes 存储类。 如果不存在与指定值匹配的存储类，或者 指定的存储类无法满足所请求的 PVC 数量或存储容量，Tenant 可能无法启动。
   size	为每个生成的 PVC 请求的存储容量。

4. 配置 Tenant Affinity 或 Anti-Affinity

   Tenant Chart 支持以下 Kubernetes Selector、Affinity 和 Anti-Affinity 配置：

   • Node Selector (tenant.nodeSelector)
   • Node/Pod Affinity or Anti-Affinity (spec.pools[n].affinity)

   MinIO 建议为 Tenant 配置 Pod Anti-Affinity，以确保 Kubernetes 调度器不会将多个 pod 调度到同一个 worker node 上。

   如果你希望将租户部署到特定 worker node 上，请将对应的 node label 或过滤条件传入 nodeSelector 或 affinity 字段，以约束调度器仅在这些节点上放置 pod。

5. 配置网络加密

   MinIO Tenant CRD 提供了以下字段，你可以通过它们配置租户的 TLS 网络加密：

   字段	描述
   tenant.certificate.requestAutoCert	启用或禁用 MinIO 自动 TLS 证书生成。 若省略该字段，默认值为 true，即启用。
   tenant.certificate.certConfig	在启用的情况下，自定义 自动 TLS 的行为。
   tenant.certificate.externalCertSecret	通过 Server Name Indication (SNI) 为多个主机名启用 TLS。 指定一个或多个类型为 kubernetes.io/tls 或 cert-manager 的 Kubernetes secret。
   tenant.certificate.externalCACertSecret	启用对由未知、第三方或内部 Certificate Authorities (CA) 签发的客户端 TLS 证书的校验。 指定一个或多个类型为 kubernetes.io/tls 的 Kubernetes secret，其中包含某个 CA 的完整证书链。

6. 配置 Silo 环境变量

   你可以使用 tenant.configuration 字段设置服务端 MINIO_* 环境变量。这些名称属于 MinIO 兼容契约，不得改名。

   字段	描述
   tenant.configuration	指定一个 Kubernetes opaque secret，其数据负载 config.env 包含你希望设置的每一个 MinIO 环境变量。 config.env 数据负载 必须 是一个 base64 编码字符串。 你可以先创建一个本地文件，在其中设置环境变量，再通过 cat LOCALFILE | base64 生成该负载。

   该 YAML 中包含一个 kind: Secret 且 metadata.name: storage-configuration 的对象，用于设置 root 用户名、密码、纠删码校验设置，以及启用 Tenant Console。

   请根据 Tenant 的实际需求修改这些值。

7. 部署 Tenant

   使用 helm 安装 Tenant Chart，并将 values.yaml 作为覆盖配置：

   helm install \
   --namespace TENANT-NAMESPACE \
   --create-namespace \
   --version 7.1.1 \
   --values values.yaml \
   TENANT-NAME minio-operator/tenant

   你可以使用以下命令监控进度：

   watch kubectl get all -n TENANT-NAMESPACE

8. 暴露 Tenant 的 MinIO S3 API 端口

   若要在本地机器上测试 MinIO Client mc，请转发 MinIO 端口并创建别名。

   • 转发 Tenant 的 MinIO 端口：

   kubectl port-forward svc/TENANT-NAME-hl 9000 -n TENANT-NAMESPACE

   • 为 Tenant 服务创建别名：

   mc alias set myminio https://localhost:9000 minio minio123 --insecure

   你可以使用 mc mb 在 Tenant 上创建存储桶：

   mc mb myminio/mybucket --insecure

   如果你为 MinIO Tenant 部署的是由受信任 Certificate Authority (CA) 签发的 TLS 证书，则可以省略 --insecure 参数。

   有关连接 Tenant 的更多文档，请参阅 连接到 Tenant。

使用本地 Helm Chart 部署 Tenant

以下步骤使用 Helm Charts 的本地副本部署 Tenant。 与 基于仓库的安装 相比，这种方式可能更便于在安装前完成 Tenant 预配置。

1. 下载 Helm charts

   在本地主机上拉取已固定的 Tenant Chart，并将默认 values 提取为单独覆盖文件：

   helm pull minio-operator/tenant --version 7.1.1
   helm show values tenant-7.1.1.tgz > values.yaml

   每个 chart 都包含一个可按需定制的 values.yaml 文件。 有关 MinIO Tenant values.yaml 可用选项的详细信息，请参阅 租户 Helm Charts。

   请使用文本编辑器打开 values.yaml：将 tenant.image.repository 设为 pgsty/minio，将 tenant.image.tag 固定为已发布 Silo 版本，并在 tenant.env 中加入 MINIO_UPDATE=off，与 基于仓库的流程 中的示例一致。

2. 配置 Tenant 拓扑

   以下字段都带有 tenant.pools[0] 前缀，用于控制 Tenant 中所有 pod 的 server 数量、每个 server 的卷数量以及存储类：

   字段	描述
   servers	要在 服务器池 中部署的 MinIO pod 数量。
   volumesPerServer	每个 MinIO pod（servers）要挂载的持久卷数量。 Operator 会为该 Tenant 生成 volumesPerServer x servers 个 Persistent Volume Claim。
   storageClassName	与生成的 Persistent Volume Claim 关联的 Kubernetes 存储类。 如果不存在与指定值匹配的存储类，或者 指定的存储类无法满足所请求的 PVC 数量或存储容量，Tenant 可能无法启动。
   size	为每个生成的 PVC 请求的存储容量。

3. 配置 Tenant Affinity 或 Anti-Affinity

   Tenant Chart 支持以下 Kubernetes Selector、Affinity 和 Anti-Affinity 配置：

   • Node Selector (tenant.nodeSelector)
   • Node/Pod Affinity or Anti-Affinity (spec.pools[n].affinity)

   MinIO 建议为 Tenant 配置 Pod Anti-Affinity，以确保 Kubernetes 调度器不会将多个 pod 调度到同一个 worker node 上。

   如果你希望将租户部署到特定 worker node 上，请将对应的 node label 或过滤条件传入 nodeSelector 或 affinity 字段，以约束调度器仅在这些节点上放置 pod。

4. 配置网络加密

   MinIO Tenant CRD 提供了以下字段，你可以通过它们配置租户的 TLS 网络加密：

   字段	描述
   tenant.certificate.requestAutoCert	启用或禁用 MinIO 自动 TLS 证书生成
   tenant.certificate.certConfig	控制 自动 TLS 的设置。 需要 spec.requestAutoCert: true
   tenant.certificate.externalCertSecret	指定一个或多个类型为 kubernetes.io/tls 或 cert-manager 的 Kubernetes secret。 MinIO 会基于主机名（Server Name Indication）使用这些证书执行 TLS 握手。
   tenant.certificate.externalCACertSecret	指定一个或多个类型为 kubernetes.io/tls 的 Kubernetes secret，其中包含 Tenant 为允许客户端 TLS 连接而必须信任的 Certificate Authority (CA) 证书链。

5. 配置 Silo 环境变量

   你可以使用 tenant.configuration 字段设置服务端 MINIO_* 环境变量。这些名称仍属兼容契约。

   该字段必须指定一个 Kubernetes opaque secret，其数据负载 config.env 包含你希望设置的每一个 MinIO 环境变量。

   该 YAML 中包含一个 kind: Secret 且 metadata.name: storage-configuration 的对象，用于设置 root 用户名、密码、纠删码校验设置，以及启用 Tenant Console。

   请根据 Tenant 的实际需求修改这些值。

6. 以下 Helm 命令使用已固定的本地 Chart 与经审查 values 创建 Silo Tenant：

   helm install \
   --namespace TENANT-NAMESPACE \
   --create-namespace \
   --values values.yaml \
   TENANT-NAME tenant-7.1.1.tgz

   若要部署多个 Tenant，请创建一个包含新 Tenant 详细配置的 Helm chart，并重复上述部署步骤。 重新部署同一个 chart 会更新此前已部署的 Tenant。

7. 暴露 Tenant 的 MinIO 端口

   若要在本地机器上测试 MinIO Client mc，请转发 MinIO 端口并创建别名。

   • 转发 Tenant 的 MinIO 端口：

     kubectl port-forward svc/TENANT-NAME-hl 9000 -n TENANT-NAMESPACE

   • 为 Tenant 服务创建别名：

     mc alias set myminio https://localhost:9000 minio minio123 --insecure

     该示例使用 HTTPS，但本地客户端可能不信任 Tenant 提供的证书，因此包含 --insecure。如果 Tenant 提供客户端信任的证书，请省略该参数。应确认当前 Tenant 实际生成的服务名，而不要假定固定为 svc/minio。

   你可以使用 mc mb 在 Tenant 上创建存储桶：

   mc mb myminio/mybucket --insecure

有关连接 Tenant 的更多文档，请参阅 连接到 Tenant。

12 - 使用 MinIO Operator 的 Silo 租户

一个 MinIO 租户由部署在单个命名空间中的一整组 Kubernetes 资源组成，用于支撑 MinIO 对象存储服务。

本文默认目标 Kubernetes 基础设施上已经完成 MinIO Operator 安装。

前提条件

你的 Kubernetes 基础设施必须满足以下前提，才能部署 MinIO 租户。

MinIO Kubernetes Operator

本页步骤 要求 已有一个有效的 MinIO Kubernetes Operator 安装，并默认本地主机也安装了与之匹配的 Operator。本页使用仓库归档前的最终上游版本 v7.1.1，仅作为冻结的兼容基线。

有关部署 MinIO Operator 的完整文档，请参阅 在 Kubernetes 上部署 MinIO。

带本地存储的 Worker Node

MinIO 强烈建议 将租户部署到带有本地直连存储的 Kubernetes worker node 上。

这些 Worker Node 应满足 MinIO 面向生产环境的 硬件检查清单。

应避免将 MinIO 租户与其他高性能软件部署在同一 worker node 上；如果确有必要，则必须配置合适的限制和约束，以保证 MinIO 获得所需的计算与存储资源。

持久卷

MinIO 通常可以使用任何支持 ReadWriteOnce 访问模式的 Kubernetes Persistent Volume (PV)。 MinIO 的一致性保证依赖于 ReadWriteOnce 提供的独占存储访问。 此外，MinIO 建议将 PVC StorageClass 的回收策略设置为 Retain。 在条件允许的情况下，应配置 PV 底层的 Storage Class、CSI 或其他 provisioner 使用 XFS 格式化卷，以确保最佳性能。

对于节点具有 Direct Attached Storage 的 Kubernetes 集群，MinIO 强烈建议使用 DirectPV CSI driver。 DirectPV 提供了一个分布式持久卷管理器，可在 Kubernetes 节点之间发现、格式化、挂载、调度和监控驱动器。 DirectPV 解决了手动配置和监控 local persistent volumes 的局限性。

对于部署到 Amazon Elastic、Azure 或 Google Kubernetes 上的租户，请选择下方标签页查看针对 PV 配置的具体建议：

租户命名空间

当你使用 Operator 创建租户时，该租户 必须 拥有自己的命名空间。 在该命名空间内，Operator 会根据租户配置生成所需的 pod。

每个租户 pod 运行三个容器：

• MinIO Container：运行所有标准 MinIO 功能，等价于裸机场景下的基础 MinIO 安装。 该容器在提供的挂载点（持久卷）上存储和读取对象。
• InitContainer：仅在 pod 启动期间存在，用于在启动过程中管理配置 secret。 启动完成后，该容器会终止。
• SideCar container：监控租户的配置 secret，并在其发生变化时进行更新。 该容器还会检查 root 凭证，如果未找到 root 凭证则会产生错误。

从 v5.0.6 起，MinIO Operator 支持自定义 init containers，以满足特定环境所需的额外 pod 初始化逻辑。

租户通过 Persistent Volume Claim 与实际存储对象的 Persistent Volume 交互。

13 - 在 Ubuntu Linux 上部署 Silo

• Object Storage Essentials
• How to Connect to MinIO with JavaScript

本页介绍如何在 Ubuntu Linux 上部署 Silo。

Silo 为 x86-64 与 ARM64 发布 DEB 软件包和独立 Linux 归档。项目没有单独发布 Ubuntu 支持生命周期矩阵，因此已删除继承文档中的时间点版本清单。请选择仍处于发行商支持期内的 Ubuntu 版本，保持内核与系统库更新，并在生产使用前验证精确的存储与工作负载配置。

本步骤重点介绍生产级 多机多盘 (MNMD)“Distributed”配置。 MNMD 部署可提供企业级性能、可用性和可扩展性，是所有生产工作负载的推荐拓扑。

本步骤也包含对 单机多盘 (SNMD) 和 单机单盘 (SNSD) 拓扑的指导，适用于早期开发和评估环境。

注意事项

检查清单

在执行本步骤前，请先阅读我们发布的硬件、软件和安全检查清单。

纠删码校验

MinIO 会根据拓扑中的节点和驱动器总数，自动为集群确定默认的 纠删码 配置。 你可以在设置集群时配置按对象生效的 parity，也可以让 MinIO 选择默认值（生产级集群默认为 EC:4）。

校验值决定了对象可用性与磁盘存储占用之间的关系。 可使用 MinIO 纠删码计算器 选择适合你集群的纠删码校验级别。

虽然你可以随时更改纠删码校验设置，但以既有校验值写入的对象 不会 自动更新为新的校验设置。

基于容量的规划

MinIO 建议在存储使用率达到 70% 之前，预先规划足以存放 至少 2 年数据的存储容量。 过于频繁地执行 服务器池 扩容，或按“just-in-time”方式扩容，通常说明架构或规划存在问题。

例如，假设某套应用每年预计至少生成 100 TiB 数据，并以 3 年后再扩容为目标。 若在部署初期就提供约 500 TiB 可用存储，集群即可在安全满足 70% 阈值的同时，为每年的数据增长预留额外缓冲。

建议使用 MinIO 纠删码计算器，围绕具体纠删码设置进行容量规划。

步骤

1. 下载 Silo DEB 包

从下载与安装获取对应架构的 DEB，校验发布摘要后安装。ARM64 主机请使用名称中带 arm64 的文件。

sudo dpkg -i ./minio_*_amd64.deb

2. 查看 systemd 服务文件

.deb 软件包会将以下 systemd 服务文件安装到 /usr/lib/systemd/system/minio.service：

[Unit]
Description=MinIO
Documentation=https://silo.pgsty.com/zh/docs/
Wants=network-online.target
After=network-online.target
AssertFileIsExecutable=/usr/local/bin/minio

[Service]
Type=notify

WorkingDirectory=/usr/local

User=minio-user
Group=minio-user
ProtectProc=invisible

EnvironmentFile=-/etc/default/minio
ExecStart=/usr/local/bin/minio server $MINIO_OPTS $MINIO_VOLUMES

# Let systemd restart this service always
Restart=always

# Specifies the maximum file descriptor number that can be opened by this process
LimitNOFILE=1048576

# Turn-off memory accounting by systemd, which is buggy.
MemoryAccounting=no

# Specifies the maximum number of threads this process can create
TasksMax=infinity

# Disable timeout logic and wait until process is stopped
TimeoutSec=infinity

# Disable killing of MinIO by the kernel's OOM killer
OOMScoreAdjust=-1000

SendSIGKILL=no

[Install]
WantedBy=multi-user.target

# Built for ${project.name}-${project.version} (${project.name})

3. 为 MinIO 创建用户和组

minio.service 文件默认以 minio-user 用户和组身份运行。 你可以使用 groupadd 和 useradd 命令创建该用户和组。 以下示例创建用户、组，并为计划供 MinIO 使用的文件夹路径设置访问权限。 这些命令通常需要 root（sudo）权限。

groupadd -r minio-user
useradd -M -r -g minio-user minio-user

以上命令创建的用户 不包含 主目录，这对系统服务账户来说是典型做法。

你 必须 对计划供 MinIO 使用的驱动器路径执行 chown。 如果 minio-user 用户或组无法读取、写入或列出任一驱动器的内容，MinIO 进程会在启动时返回错误。

例如，以下命令将 /mnt/drives-n 下所有驱动器的属主和属组设置为 minio-user:minio-user，其中 n 的范围为 1 到 16：

chown -R minio-user:minio-user /mnt/drives-{1...16}

4. 启用 TLS 连接

你可以跳过此步骤，以在未启用 TLS 的情况下部署。 MinIO 强烈 不建议 在早期开发之外的场景中进行非 TLS 部署。

为 MinIO 创建或提供 传输层安全 (TLS) 证书，以自动启用服务端与客户端之间的 HTTPS 安全连接。

MinIO 要求私钥和公钥证书的默认文件名分别为 private.key 和 public.crt。 请将证书放置在 minio-user 用户/组可访问的目录中：

mkdir -p /opt/minio/certs
chown -R minio-user:minio-user /opt/minio/certs

cp private.key /opt/minio/certs
cp public.crt /opt/minio/certs

MinIO 会根据操作系统/系统默认的受信任证书颁发机构列表来验证客户端证书。 若要启用对第三方证书或内部签发证书的验证，请将 CA 文件放入 /opt/minio/certs/CAs 目录。 CA 文件应包含从叶子证书到根证书的完整信任链，以确保验证成功。

有关为 MinIO 配置 TLS 的更具体指导，包括通过 Server Name Indication (SNI) 支持多域名，请参阅 网络加密（TLS）。

certgen -host "localhost,minio-*.example.net"

5. 创建 MinIO 环境文件

在 /etc/default/minio 创建环境文件。 MinIO 服务将该文件作为 MinIO 以及 minio.service 文件所用全部 环境变量 的来源。

请根据你的部署拓扑修改示例。

# Set the hosts and volumes MinIO uses at startup
# The command uses MinIO expansion notation {x...y} to denote a
# sequential series.
#
# The following example covers four MinIO hosts
# with 4 drives each at the specified hostname and drive locations.
#
# The command includes the port that each MinIO server listens on
# (default 9000).
# If you run without TLS, change https -> http

MINIO_VOLUMES="https://minio{1...4}.example.net:9000/mnt/disk{1...4}/minio"

# Set all MinIO server command-line options
#
# The following explicitly sets the MinIO Console listen address to
# port 9001 on all network interfaces.
# The default behavior is dynamic port selection.

MINIO_OPTS="--console-address :9001 --certs-dir /opt/minio/certs"

# Set the root username.
# This user has unrestricted permissions to perform S3 and
# administrative API operations on any resource in the deployment.
#
# Defer to your organizations requirements for superadmin user name.

MINIO_ROOT_USER=minioadmin

# Set the root password
#
# Use a long, random, unique string that meets your organizations
# requirements for passwords.

MINIO_ROOT_PASSWORD=minio-secret-key-CHANGE-ME

# Set the volumes MinIO uses at startup
# The command uses MinIO expansion notation {x...y} to denote a
# sequential series.
#
# The following specifies a single host with 4 drives at the specified location
#
# The command includes the port that the MinIO server listens on
# (default 9000).
# If you run without TLS, change https -> http

MINIO_VOLUMES="https://minio1.example.net:9000/mnt/drive{1...4}/minio"

# Set all MinIO server command-line options
#
# The following explicitly sets the MinIO Console listen address to
# port 9001 on all network interfaces.
# The default behavior is dynamic port selection.

MINIO_OPTS="--console-address :9001 --certs-dir /opt/minio/certs"

# Set the root username.
# This user has unrestricted permissions to perform S3 and
# administrative API operations on any resource in the deployment.
#
# Defer to your organizations requirements for superadmin user name.

MINIO_ROOT_USER=minioadmin

# Set the root password
#
# Use a long, random, unique string that meets your organizations
# requirements for passwords.

MINIO_ROOT_PASSWORD=minio-secret-key-CHANGE-ME

# Set the volume MinIO uses at startup
#
# The following specifies the drive or folder path

MINIO_VOLUMES="/mnt/drive1/minio"

# Set all MinIO server command-line options
#
# The following explicitly sets the MinIO Console listen address to
# port 9001 on all network interfaces.
# The default behavior is dynamic port selection.

MINIO_OPTS="--console-address :9001 --certs-dir /opt/minio/certs"

# Set the root username.
# This user has unrestricted permissions to perform S3 and
# administrative API operations on any resource in the deployment.
#
# Defer to your organizations requirements for superadmin user name.

MINIO_ROOT_USER=minioadmin

# Set the root password
#
# Use a long, random, unique string that meets your organizations
# requirements for passwords.

MINIO_ROOT_PASSWORD=minio-secret-key-CHANGE-ME

请根据部署需要，指定其他 环境变量 或 server 命令行选项。

对于分布式部署，所有节点的 /etc/default/minio 环境文件 必须 完全一致。 可在每个节点上使用 shasum -a 256 /etc/default/minio 等工具验证其是否完全匹配。

6. 启动 MinIO 部署

使用 systemctl start minio 启动部署中的每个节点。

你可以在每个节点上使用 journalctl -u minio 跟踪启动状态。

启动成功后，MinIO 进程会输出一段部署摘要，类似如下：

MinIO 对象存储服务端
Copyright: 2015-2024 MinIO, Inc.
License: GNU AGPLv3 - https://www.gnu.org/licenses/agpl-3.0.html
Version: RELEASE.2024-06-07T16-42-07Z (go1.22.4 linux/amd64)

API: https://minio-1.example.net:9000 https://203.0.113.10:9000 https://127.0.0.1:9000
   RootUser: minioadmin
   RootPass: minioadmin

WebUI: https://minio-1.example.net:9001 https://203.0.113.10:9001 https://127.0.0.1:9001
   RootUser: minioadmin
   RootPass: minioadmin

CLI: https://silo.pgsty.com/zh/reference/minio-mc/#quickstart
   $ mc alias set 'myminio' 'https://minio-1.example.net:9000' 'minioadmin' 'minioadmin'

Docs: https://silo.pgsty.com/zh/docs/
Status:         16 Online, 0 Offline.

在集群启动和同步期间，你可能会看到日志明显增多。

启动失败的常见原因包括：

• MinIO 进程对指定驱动器没有读、写、列出权限
• 驱动器不是空的，或其中包含非 MinIO 数据
• 驱动器未正确格式化或挂载
• 一个或多个主机无法通过网络访问

遵循我们的检查清单通常可以降低遇到这些或类似问题的风险。

7. 连接到部署

Console

打开浏览器，并通过任一 MinIO 主机名的 :9001 端口访问 MinIO Console 登录页。 例如：https://minio1.example.com:9001。

使用上一步中的 MINIO_ROOT_USER 和 MINIO_ROOT_PASSWORD 登录。

你可以使用 MinIO Console 执行常规管理任务，例如身份与访问管理、指标和日志监控，或 Server 配置。 每个 MinIO Server 都包含自身内嵌的 MinIO Console。

CLI

请按照本地主机上的 mc 安装说明 完成安装。 运行 mc --version 验证安装结果。

如果你的 MinIO 部署使用第三方或自签名 TLS 证书，请将 CA 文件复制到 ~/.mc/certs/CAs，以便 mc 信任该证书链。

安装完成后，为该 MinIO 部署创建一个别名：

mc alias set myminio https://minio-1.example.net:9000 USERNAME PASSWORD

请根据你的部署修改主机名、用户名和密码。 主机名可以是部署中的任意一个 MinIO 节点。 你也可以指定负责处理部署连接的负载均衡器、反向代理或类似网络控制平面的主机名。

8. 后续步骤

• 在可信网络之外暴露服务前，先启用 TLS。
• 通过身份与访问管理创建最小权限用户和策略。
• 配置监控与告警，并在投入生产前实际测试磁盘、节点与站点恢复流程。

14 - 在裸机上部署 Silo

Silo 可以运行在物理机、虚拟化主机或容器中。当前下载页面提供 Linux、macOS 和 Windows 的 x86-64 与 ARM64 服务端制品；请遵循各平台页面的说明，不要假定所有操作系统拥有相同的生产验证范围。

• 在 Red Hat Linux 上部署 Silo
• 在 Ubuntu Linux 上部署 Silo
• 在 Apple macOS 上部署 Silo
• 以容器方式部署 Silo
• 在 Microsoft Windows 上部署 Silo

15 - 站点复制概览

站点复制将多个相互独立的 MinIO 部署配置为一个由副本组成的集群，这些副本称为对等站点。

站点复制要求使用内置的 MinIO Identity Provider (IDP) 或 外部 IDP。 所有已配置的部署都必须使用同一个 IDP。 使用外部 IDP 的部署必须在各站点之间使用相同的配置。

有关站点复制架构和部署概念的更多信息，请参阅 Deployment Architecture: Replicated MinIO Deployments。

除早期开发、评估或一般性实验外，MinIO 不建议在站点复制中使用 macOS、Windows 或未编排的容器部署。生产环境请使用受支持的 Linux 或 Kubernetes 部署，并按照本页的站点复制流程操作。

概览

所有站点之间会复制哪些内容

每个 MinIO 部署（“对等站点”）都会将以下变更同步到其他对等站点：

• 存储桶和对象的创建、修改与删除，包括

  • 存储桶与对象配置
  • 策略
  • mc tag set
  • 锁定，包括保留和 legal hold 配置
  • 加密设置

• IAM 用户、组、策略以及策略到用户或组的映射（针对 LDAP 用户或组）的创建与删除

• 为可由本地 root 凭证验证的会话令牌创建 Security Token Service (STS) 凭证

• 访问密钥 的创建与删除 （不包括 root 用户拥有的访问密钥）

站点复制会在所有复制站点上，为所有新建和现有存储桶启用 存储桶版本控制。

你可以选择在对等站点之间复制 ILM 过期规则。 对于新的站点复制配置，可使用带有 --replicate-ilm-expiry 标志的 mc admin replicate add。 对于现有站点复制配置，则可根据需要使用 mc admin replicate update 配合 --enable-ilm-expiry-replication 或 --disable-ilm-expiry-replication 标志启用或禁用该行为。

哪些内容不会在站点之间复制

处于站点复制配置中的 MinIO 部署 不会 复制以下项目的创建或修改：

• 存储桶通知
• 生命周期管理（ILM）配置
• 站点配置设置

站点复制的初始流程

启用站点复制后，身份与访问管理（IAM）设置会按以下顺序同步：

在对等站点之间完成初始数据同步后，MinIO 会持续在所有站点之间复制并同步任何站点上新发生的 可复制数据。

站点自愈

站点复制配置中的任意 MinIO 部署，都可以从拥有该数据最新版本的对等站点重新同步受损的 可复制数据。

你可以使用 MINIO_SCANNER_SPEED 环境变量或 scanner speed 配置项， 调整 MinIO 在扫描器性能与读写操作之间的平衡方式。

同步复制与异步复制

对于给定的远端目标，MinIO 支持指定异步复制（默认）或同步复制。

在异步复制模式下，MinIO 会在将对象放入 复制队列 之前 完成发起的 PUT 操作。 因此，发起请求的客户端可能会在对象完成复制 之前 就看到 PUT 操作成功。 虽然这可能导致远端对象陈旧或缺失，但它降低了因复制负载而导致写入变慢的风险。

在同步复制模式下，MinIO 会在完成发起的 PUT 操作 之前 尝试复制对象。 无论复制尝试是否成功，MinIO 都会返回一个成功的 PUT 操作结果。 这降低了写入变慢的风险，但代价是远端位置可能出现陈旧或缺失对象。

MinIO 强烈建议使用默认的异步站点复制。 同步站点复制的性能高度依赖站点之间的延迟，较高的延迟可能导致更低的 PUT 性能和复制滞后。 要配置同步站点复制，请使用 mc admin replicate update 并带上 --mode 选项。

代理到其他站点

MinIO 对等站点可以将对象的 GET/HEAD 请求代理到其他对等站点，以检查该对象是否存在。 这样一来，即使某个站点正在自愈或落后于其他对等站点，仍然可以返回已持久化到其他站点的对象。

例如：

1. 客户端向 Site1 发起 GET("data/invoices/january.xls")
2. Site1 无法定位该对象
3. Site1 将请求代理到 Site2
4. Site2 返回请求对象的最新版本
5. Site1 将代理返回的对象响应给客户端

对于 不 包含唯一版本 ID 的 GET/HEAD 请求，代理请求会返回该对象在对等站点上的 最新 版本。 这可能导致取回对象的非当前版本，例如响应请求的对等站点本身也存在复制滞后时。

MinIO 不会代理 LIST、DELETE 和 PUT 操作。

前提条件

先备份集群设置

在配置站点复制之前，使用 mc admin cluster bucket export 和 mc admin cluster iam export 命令分别对存储桶元数据和 IAM 配置进行快照。 如果在配置站点复制过程中发生误配置，可以使用这些快照恢复存储桶/IAM 设置。

初始化时仅允许一个站点包含数据

在初始化时，只允许 一个 站点包含数据。 其他站点必须不包含任何存储桶和对象。

配置站点复制后，第一个部署上的所有数据都会复制到其他站点。

所有站点必须使用相同的 IDP

所有站点都必须使用相同的 Identity Provider。 站点复制支持内置的 MinIO IDP、OIDC 或 LDAP。

所有站点必须使用相同的 MinIO 服务端版本

所有站点都必须使用一致且匹配的 MinIO 服务端版本。 在 MinIO 服务端版本不匹配的站点之间配置复制，可能导致意外或不符合预期的复制行为。

还应确保用于配置复制的 mc 版本尽量与服务器版本保持接近。

访问同一个加密服务

如果通过 Key Management Service (KMS) 使用 SSE-S3 或 SSE-KMS 加密，则所有站点都必须能够访问同一个中心化 KMS 部署。

可以通过一个中心化 KES 服务器，或多个 KES 服务器（例如每个站点一个）连接到同一个受支持的中心化 key vault server 来实现。

复制要求启用版本控制

站点复制 要求 启用 存储桶版本控制，并会自动为所有新建存储桶启用该功能。 在站点复制部署中，不能禁用版本控制。

对于存储桶中被排除在版本控制之外的前缀，MinIO 无法复制其中的对象。

每个站点都应部署负载均衡器

指定该站点的负载均衡器、反向代理或类似网络控制平面组件的 URL 或 IP 地址。 请求会自动路由到部署中的各个节点。

MinIO 不建议为对等站点使用单个节点主机名。 这会形成单点故障：如果该节点离线，复制就会失败。

从存储桶复制切换到站点复制

存储桶复制 与多站点复制是互斥的。 不能在同一组部署上同时使用这两种复制方式。

如果此前已经配置了存储桶复制，而现在希望改用站点复制，则在初始化站点复制时，必须先删除包含数据的那个部署上的全部存储桶复制规则。 可在命令行中使用 mc replicate rm 删除存储桶复制规则。

设置站点复制时，只允许一个站点包含数据。 其他所有站点都必须为空。

教程

配置站点复制

以下步骤将为三个 分布式部署 创建一个新的站点复制配置。 其中一个站点包含 可复制数据。

这三个站点分别使用别名 minio1、minio2 和 minio3，且仅 minio1 包含数据。

1. 使用相同的 IDP，部署 三个或更多彼此独立的 MinIO 站点

   从空站点开始，或 确保最多只有一个站点包含任何 可复制数据。

2. 为每个站点配置别名

   指定该站点的负载均衡器、反向代理或类似网络控制平面组件的 URL 或 IP 地址。 请求会自动路由到部署中的各个节点。

   MinIO 不建议为对等站点使用单个节点主机名。 这会形成单点故障：如果该节点离线，复制就会失败。

   例如，对于三个 MinIO 站点，可以创建别名 minio1、minio2 和 minio3。

   使用 mc alias set 定义管理该站点连接的负载均衡器主机名或 IP。

   mc alias set minio1 https://minio1.example.com:9000 adminuser adminpassword
   mc alias set minio2 https://minio2.example.com:9000 adminuser adminpassword
   mc alias set minio3 https://minio3.example.com:9000 adminuser adminpassword

   或定义环境变量

   export MC_HOST_minio1=https://adminuser:[email protected]
   export MC_HOST_minio2=https://adminuser:[email protected]
   export MC_HOST_minio3=https://adminuser:[email protected]

3. 添加站点复制配置

   mc admin replicate add minio1 minio2 minio3

   如果所有站点均为空，则别名顺序无关紧要。 如果其中一个站点包含任何 可复制数据，则必须将其列在第一位。

   最多只能有一个站点包含可复制数据。

4. 查询站点复制配置进行验证

   mc admin replicate info minio1

   可以使用站点复制配置中任意对等站点的别名。

5. 查询站点复制状态，确认初始数据已复制到所有对等站点。

   mc admin replicate status minio1

   可以使用站点复制配置中任意对等站点的别名。 输出应表明所有 可复制数据 均已同步。

   输出可能类似如下：

   Bucket replication status:
   ●  1/1 Buckets in sync
   
   Policy replication status:
   ●  5/5 Policies in sync
   
   User replication status:
   No Users present
   
   Group replication status:
   No Groups present

   有关检查站点复制的更多信息，请参阅 站点复制状态教程。

扩展站点复制

可以向现有站点复制配置中添加更多站点。

新站点必须满足以下要求：

• 站点已完成部署，并可通过主机名或 IP 访问
• 与配置中的其他站点共享相同的 IDP 配置
• 使用与其他已配置站点相同的 root 用户凭证
• 不包含任何存储桶或对象数据

1. 按照上述要求部署新的 MinIO 对等站点

2. 为新站点配置别名

   指定该站点的负载均衡器、反向代理或类似网络控制平面组件的 URL 或 IP 地址。 请求会自动路由到部署中的各个节点。

   MinIO 不建议为对等站点使用单个节点主机名。 这会形成单点故障：如果该节点离线，复制就会失败。

   要检查现有别名，请使用 mc alias list。

   使用 mc alias set 定义管理新站点连接的负载均衡器主机名或 IP。

   mc alias set minio4 https://minio4.example.com:9000 adminuser adminpassword

   或定义环境变量

   export MC_HOST_minio4=https://adminuser:[email protected]

3. 添加站点复制配置

   使用 mc admin replicate add 命令，将新的对等站点加入站点复制配置中。 先指定 所有 现有对等站点的别名，再指定要添加的新站点别名。

   例如，以下命令将新的对等站点 minio4 添加到现有站点复制配置中，该配置已包含 minio1、minio2 和 minio3 三个站点。

   mc admin replicate add minio1 minio2 minio3 minio4

   说明

   说明

   如果任一站点不可达或已永久丢失，则在使用新站点进行扩展前，必须先使用 mc admin replicate rm 移除不可达站点。

4. 查询站点复制配置进行验证

   mc admin replicate info minio1

修改站点的端点

如果某个对等站点变更了主机名，可以修改复制配置以反映新的主机名。

1. 使用 mc admin replicate info 获取站点的 Deployment ID

   mc admin replicate info <ALIAS>

2. 使用 mc admin replicate update 更新站点的端点

   mc admin replicate update ALIAS --deployment-id [DEPLOYMENT-ID] --endpoint [NEW-ENDPOINT]

   将 [DEPLOYMENT-ID] 替换为要更新站点的 deployment ID。

   将 [NEW-ENDPOINT] 替换为该站点的新端点。

   指定该站点的负载均衡器、反向代理或类似网络控制平面组件的 URL 或 IP 地址。 请求会自动路由到部署中的各个节点。

   MinIO 不建议为对等站点使用单个节点主机名。 这会形成单点故障：如果该节点离线，复制就会失败。

从复制中移除站点

可以随时将某个站点从复制中移除。 后续也可以重新添加该站点，但必须先彻底清除该站点上的存储桶和对象数据。

使用 mc admin replicate rm：

mc admin replicate rm ALIAS PEER_TO_REMOVE --force

• 将 ALIAS 替换为复制配置中任意对等站点的 alias。
• 将 PEER_TO_REMOVE 替换为要移除的对等站点别名。

站点复制配置中的所有健康对等站点都会自动更新，以移除指定的对等站点。

MinIO 要求使用 --force 标志，才能将该对等站点从站点复制配置中移除。

查看复制状态

MinIO 提供跨站点的用户、组、策略或存储桶复制信息。

汇总信息包括各类别中 Synced 和 Failed 项目的数量。

使用 mc admin replicate status：

mc admin replicate status <ALIAS> --<flag> <value>

例如：

• mc admin replicate status minio3 --bucket images

  显示 minio3 站点上 images 存储桶的复制状态。

  输出类似如下：

  ●  Bucket config replication summary for: images
  
  Bucket          | MINIO2          | MINIO3          | MINIO4
  Tags            |                 |                 |
  Policy          |                 |                 |
  Quota           |                 |                 |
  Retention       |                 |                 |
  Encryption      |                 |                 |
  Replication     | ✔               | ✔               | ✔

• mc admin replicate status minio3 --all

  显示 minio3 所属全部复制站点的复制状态摘要。

  输出类似如下：

  Bucket replication status:
  ●  1/1 Buckets in sync
  
  Policy replication status:
  ●  5/5 Policies in sync
  
  User replication status:
  ●  1/1 Users in sync
  
  Group replication status:
  ●  0/2 Groups in sync
  
  Group           | MINIO2          | MINIO3          | MINIO4
  ittechs         | ✗  in-sync      |                 | ✗  in-sync
  managers        | ✗  in-sync      |                 | ✗  in-sync

16 - 租户的 cert-manager

以下过程用于创建并应用在租户内使用 cert-manager 管理 TLS 证书所需的资源。

前提条件

• 已安装 kustomize
• 可通过 kubectl 访问你的 k8s 集群
• 已完成 cert-manager 的设置
• 已安装 MinIO Operator，并已 完成 cert-manager 设置

1) 创建租户命名空间的 CA Issuer

在部署新租户之前，先为该租户的命名空间创建 Certificate Authority 和 Issuer。

1. 如有必要，先创建租户命名空间。

   kubectl create ns tenant-1

   该值必须与租户 YAML 中 metadata.namespace 字段的值一致。

2. 为新的 Certificate Authority 申请一个 Certificate，并将 spec.isCA 设为 true。

   创建一个名为 tenant-1-ca-certificate.yaml 的文件，内容如下：

   # tenant-1-ca-certificate.yaml
   apiVersion: cert-manager.io/v1
   kind: Certificate
   metadata:
     name: tenant-1-ca-certificate
     namespace: tenant-1
   spec:
     isCA: true
     commonName: tenant-1-ca
     secretName: tenant-1-ca-tls
     duration: 70128h # 8y
     privateKey:
       algorithm: ECDSA
       size: 256
     issuerRef:
       name: selfsigned-root
       kind: ClusterIssuer
       group: cert-manager.io

   警告

   重要

   spec.issueRef.name 必须与 设置 cert-manager 时创建的 ClusterIssuer 名称一致。 如果你使用了不同的 ClusterIssuer 名称，或者采用了与本指南不同的 Issuer，请按你的环境修改 issuerRef。

3. 应用该资源：

   kubectl apply -f tenant-1-ca-certificate.yaml

2) 创建 Issuer

Issuer 负责在租户命名空间内签发证书。

1. 生成一个 Issuer 的资源定义。

   创建一个名为 tenant-1-ca-issuer.yaml 的文件，内容如下：

   # tenant-1-ca-issuer.yaml
   apiVersion: cert-manager.io/v1
   kind: Issuer
   metadata:
     name: tenant-1-ca-issuer
     namespace: tenant-1
   spec:
     ca:
       secretName: tenant-1-ca-tls

2. 应用该 Issuer 资源定义：

   kubectl apply -f tenant-1-ca-issuer.yaml

3) 为租户创建证书

请求 cert-manager 为 MinIO 签发新的 TLS server 证书。 该证书必须对以下 DNS 域名有效：

• minio.<namespace>
• minio.<namespace>.svc
• minio.<namespace>.svc.<cluster domain>
• *.<tenant-name>-hl.<namespace>.svc.<cluster domain>
• *.<namespace>.svc.<cluster domain>
• *.<tenant-name>.minio.<namespace>.svc.<cluster domain>'

1. 为指定域名申请一个 Certificate

   创建一个名为 tenant-1-minio-certificate.yaml 的文件。 文件内容应类似如下，并根据你的集群和租户配置进行调整：

   # tenant-1-minio-certificate.yaml
   apiVersion: cert-manager.io/v1
   kind: Certificate
   metadata:
     name: tenant-certmanager-cert
     namespace: tenant-1
   spec:
     dnsNames:
       - "minio.tenant-1"
       - "minio.tenant-1.svc"
       - 'minio.tenant-1.svc.cluster.local'
       - '*.minio.tenant-1.svc.cluster.local'
       - '*.myminio-hl.tenant-1.svc.cluster.local'
       - '*.myminio.minio.tenant-1.svc.cluster.local'
     secretName: myminio-tls
     issuerRef:
       name: tenant-1-ca-issuer

   说明

   提示

   在本例中，Tenant 名称为 myminio。 作为命名约定，建议将 spec.secretName 字段中的 secret 命名为 <tenant-name>-tls。

2. 应用该证书资源：

   kubectl apply -f tenant-1-minio-certificate.yaml

3. 验证变更是否已生效：

   kubectl describe secret/myminio-tls -n tenant-1

   说明

   说明

   • 将 tenant-1 替换为你的租户命名空间。
   • 如果 secret 名称不同，请将 myminio-tls 替换为实际值。

4) 使用 cert-manager 部署租户并管理 TLS 证书

部署 Tenant 时，必须将 TLS 配置设置为以下状态：

• Tenant 不会自动生成自己的证书（spec.requestAutoCert: false）并且
• Tenant 具有有效的 cert-manager 引用（spec.externalCertSecret）

这会指示 Operator 在部署 Tenant 时仅使用 cert-manager 管理的证书。

以下 YAML spec 提供了满足这些要求的基线配置：

apiVersion: minio.min.io/v2
kind: Tenant
metadata:
  name: myminio
  namespace: tenant-1
spec:
...
  ## Disable default tls certificates.
  requestAutoCert: false
  ## Use certificates generated by cert-manager.
  externalCertSecret:
    - name: myminio-tls
      type: cert-manager.io/v1
...

5) 在 MinIO Operator 中信任租户 CA

默认情况下，MinIO Operator 不信任租户的 CA。 若要让 Operator 信任该 CA，你必须将该证书作为 secret 传递给 Operator。

为此，请在 minio-operator 命名空间中创建一个以 operator-ca-tls- 为前缀、后接唯一标识符命名的 secret。

MinIO Operator 会挂载并信任由所提供的 Certificate Authority 签发的 所有 证书。 这是必需的，因为 MinIO Operator 会通过 /minio/health/cluster 端点执行健康检查。

创建 operator-ca-tls-tenant-1 secret

将租户中由 cert-manager 生成的 CA 公钥（ca.crt）复制到 minio-operator 命名空间中。 这样 Operator 就能信任该 cert-manager 颁发的 CA 及其派生的所有证书。

1. 创建一个包含该 CA 的 ca.crt 文件：

   kubectl get secrets -n tenant-1 tenant-1-ca-tls -o=jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt

2. 创建 secret：

   kubectl create secret generic operator-ca-tls-tenant-1 --from-file=ca.crt -n minio-operator

6) 部署租户

租户命名空间中的 Certificate Authority 和 Issuer 就绪后，你现在可以 部署对象存储租户。

请使用修改后的基线 Tenant YAML，禁用 AutoCert 并引用刚刚生成的 secret。

17 - 核心运维概念

MinIO 部署由哪些组件构成？

一个 MinIO 部署由一组存储和计算资源构成，这些资源运行一个或多个 minio server 节点，并共同作为单一对象存储库。

一个单机 MinIO 实例由单个 服务器池 和单个 minio server 节点组成。 单机实例最适合初期开发和评估。

MinIO 部署既可以直接运行在 裸金属 或非虚拟化基础设施中的物理设备上。 MinIO 也可以运行在云服务中的虚拟机上，例如使用 Docker、Podman 或 Kubernetes。 MinIO 可以运行在本地、私有云或市场上的众多公有云中。

你设计、架构和构建系统的具体方式称为系统的 拓扑。

MinIO 支持哪些系统拓扑？

MinIO 可以部署到以下三种拓扑：

1. 单机单盘，单个 MinIO server，使用单个驱动器或文件夹存储数据

   例如，在本地 PC 上使用硬盘中的一个文件夹进行测试。

2. 单机多盘，单个 MinIO server，使用多个挂载驱动器或文件夹存储数据

   例如，一个挂载了两个或更多卷的单容器。

3. 多机多盘，多个 MinIO server，使用多个挂载驱动器或卷存储数据

   对于裸金属 基础设施，你可以使用 Ansible、Terraform 或手动流程安装并管理分布式 MinIO 部署。

   对于 Kubernetes 基础设施，请使用 MinIO Operator 来管理和部署分布式 MinIO Tenant。

分布式 MinIO 部署如何工作？

分布式部署会利用多台物理机或虚拟机的计算和存储资源。 在现代场景中，这通常意味着在私有云或公有云环境中运行 MinIO，例如 Amazon Web Services、Google Cloud Platform、Microsoft Azure 等。

MinIO 如何管理多个虚拟或物理服务器？

虽然测试 MinIO 可能只涉及一台计算机上的单个驱动器，但大多数生产级 MinIO 部署都会使用多个计算和存储设备来构建高可用环境。 服务器池 是一组 minio server 节点，它们汇聚各自的驱动器和资源，以支持对象存储写入和读取请求。

MinIO 支持向现有部署中添加一个或多个 服务器池，以实现横向扩容。 当 MinIO 拥有多个可用 服务器池 时，单个对象始终会写入同一个 服务器池 中的同一个纠删码集合。

如果某个 服务器池 发生故障，MinIO 会停止所有服务器池的 I/O，直到集群恢复正常运行。 你必须将该服务器池恢复到可工作状态，部署的 I/O 才能恢复。 在执行修复操作期间，写入其他服务器池的对象仍会安全保留在磁盘上。

传递给 minio server 命令的 HOSTNAME 参数表示一个 服务器池：

请看下面的启动命令示例。该命令会创建一个单独的 服务器池，其中包含 4 个 minio server 节点，每个节点有 4 块驱动器，总计 16 块驱动器。

minio server https://minio{1...4}.example.net/mnt/disk{1...4}

             |                    服务器池                |

在同一条 minio server 启动命令中启动多个 服务器池，可使各个 服务器池 对等节点彼此可感知。

有关完整语法和用法，请参阅 minio server。

MinIO 如何将多个 服务器池 连接为单一 MinIO 集群？

cluster 指由一个或多个 服务器池 组成的完整 MinIO 部署。

请看下面的命令。它创建了一个由两个 服务器池 组成的 cluster，每个服务器池都包含 4 个 minio server 节点，且每个节点有 4 块驱动器，总计 32 块驱动器。

minio server https://minio{1...4}.example.net/mnt/disk{1...4} \
             https://minio{5...8}.example.net/mnt/disk{1...4}

             |                    服务器池                |

每个 服务器池 根据其中的驱动器和节点数量，包含一个或多个 纠删码集合。

MinIO 强烈建议生产集群中的每个 服务器池 至少包含 4 个 minio server 节点，以获得恰当的高可用性和持久性保障。

我可以更改现有 MinIO 部署的大小吗？

MinIO 分布式部署 支持通过扩容和退役来增加或减少可用存储。

扩容是指向现有部署中添加一个或多个 服务器池。 每个 服务器池 都由专用节点和存储组成，并为部署的总体容量作出贡献。 服务器池 一旦创建，其大小便无法更改，但你可以随时通过添加或退役服务器池 来增加或移除容量。

有关在裸金属 和 Kubernetes 基础设施上进行扩容的更多信息，请分别参阅 裸金属：扩展 MinIO 部署 和 Kubernetes：扩展 MinIO Tenant。

对于包含多个 服务器池 的部署，你可以 退役 较旧的 pool，并将其中的数据迁移到部署中的较新 pool。 退役一旦开始就无法停止。 MinIO 将退役功能设计为移除硬件老旧的 pool，而不是在任何部署中定期执行的操作。

https://minio-{1...4}.example.net/mnt/drive-{1...4}
https://minio-{5...8}.example.net/mnt/drive-{1...4}
https://minio-{9...12}.example.net/mnt/drive-{1...4}

https://minio-{1...4}.example.net/mnt/drive-{1...4}
https://minio-{9...12}.example.net/mnt/drive-{1...4}
https://minio-{13...16}.example.net/mnt/drive-{1...4}

如何管理一个或多个 MinIO 实例或集群？

你可以通过多种方式管理 MinIO 部署和集群：

• 使用命令行工具 mc 和 mc admin
• 使用 MinIO Console 图形用户界面管理单个实例

MinIO 如何管理对象在部署中的分布？

MinIO 会根据各个服务器池 的空闲空间占所有可用 服务器池 总空闲空间的比例，将新对象（即没有现有版本的对象）写入空闲空间最多的 服务器池。 MinIO 不会执行将对象从旧服务器池重新平衡到新服务器池 这类成本高昂的操作。 相反，新对象通常会首先路由到新 pool，因为它拥有最多空闲空间。 随着该服务器池逐渐填满，新的写操作最终会在部署中的所有服务器池之间趋于平衡。 有关写入偏好计算逻辑的更多信息，请参阅下文 写入文件。

扩容后在所有服务器池之间重新平衡数据是一项昂贵操作，需要扫描整个部署并在服务器池之间移动对象。 完成所需时间取决于需要移动的数据量。

从 MinIO 客户端版本 RELEASE.2022-11-07T23-47-39Z 开始，你可以使用 mc admin rebalance 手动在所有 服务器池 之间发起重新平衡操作。

重新平衡不会阻塞现有操作，而是与其他 I/O 并行运行。 这可能导致常规操作性能下降。 建议在非高峰时段安排重新平衡操作，以避免影响生产工作负载。 你可以随时启动和停止重新平衡。

如何向 MinIO 上传对象？

你可以使用任何兼容 S3 的 SDK 向 MinIO 部署上传对象。 每个 SDK 都会执行等价于 PUT 的操作，将对象传输到 MinIO 进行存储。

MinIO 还支持 multipart uploads。 借助该机制，客户端可以将对象拆分为多个 part，以提高吞吐量和传输可靠性。 MinIO 会重组这些 part，直到对象完整，然后将其存储到指定路径。

MinIO 如何提供可用性、冗余性和可靠性？

MinIO 使用 纠删码 提供数据冗余和可靠性

MinIO 纠删码是一项数据冗余和可用性特性，可让具有多块驱动器的 MinIO 部署在集群中丢失多个驱动器或节点的情况下，仍然自动实时重建对象。 与 RAID 或复制等同类技术相比，纠删码以显著更低的开销提供对象级 自愈。

MinIO 通过 bit rot 自愈保护静态数据

bit rot 是一种可能发生在任何存储设备上的随机、静默数据损坏。 bit rot 损坏并非由用户活动触发，系统本身的操作系统通常也无法感知该损坏，因此无法通知用户或管理员数据已发生变化。

bit rot 的常见原因包括：

• 驱动器老化
• 电流尖峰
• 驱动器固件 bug
• 幻写
• 错误定向的读写
• 驱动程序错误
• 意外覆写

MinIO 使用哈希算法确认对象完整性。 该算法会在对象执行任何 GET 和 HEAD 操作时自动生效。 对于启用了版本控制的存储桶，如果 MinIO 识别到版本不一致，PUT 操作也可能触发自愈。 如果对象因 bit rot 而损坏，MinIO 可根据该对象校验分片的可用性，自动 自愈 该对象。

MinIO 还可以使用 MinIO 扫描器 执行 bit rot 检查和自愈。 不过，扫描器的 bit rot 检查默认 关闭。 与 bit rot 同时影响分布在多个驱动器和节点上的多个对象分片这一低概率事件相比，扫描期间主动执行 bit rot 自愈的性能影响较高。 正常操作期间的自动检查通常已足够应对 bit rot，MinIO 不建议将扫描器用于这类健康检查。

MinIO 将数据分布到 纠删码集合 中，以实现高可用性和韧性

纠删码集合是一组支持 MinIO 纠删码 的驱动器。 纠删码为存储在 MinIO 部署上的数据提供高可用性、可靠性和冗余性。

MinIO 会将对象拆分为称作 shards 的块，并将其均匀分布到纠删码集合中的各块驱动器上。 即使任意单块驱动器丢失，MinIO 也可以继续无缝响应读写请求。 在最高冗余级别下，即使部署中最多有一半 ($N / 2$) 驱动器丢失，MinIO 仍能以很小的性能影响继续提供读取请求。

MinIO 会根据集合中的驱动器总数以及集合中的 minio server 数量，计算 服务器池 中纠删码集合的大小和数量。 更多信息请参阅 纠删码基础。

MinIO 自动实时自愈损坏或丢失的数据

自愈 是 MinIO 在某些事件导致数据丢失后恢复数据的能力。 数据丢失可能来自 bit rot、驱动器丢失或节点丢失。

如果对象只是部分丢失，纠删码 可继续提供读写访问。

MinIO 使用校验在对象级提供数据保护

包含多块驱动器的 MinIO 部署会将可用驱动器划分为数据驱动器和校验驱动器。 MinIO 纠删码会在写入对象时，将关于对象内容的附加哈希信息写入校验驱动器。 MinIO 使用这些校验信息确认对象完整性，并在必要时恢复某个驱动器或某组驱动器上丢失、缺失或损坏的对象分片。

即使丢失的驱动器总数达到纠删码集合中可用校验设备的数量，MinIO 仍可以继续提供对象的完整访问能力。

通过仲裁提供读写能力

仲裁指执行某项任务所必须可用的最少驱动器数量。 MinIO 为读取数据和写入数据分别定义了不同的仲裁值。

通常，为保持写入对象的能力，MinIO 所需的可用驱动器数量会高于读取对象所需的数量。

17.1 - 部署架构

本页从生产视角概述 MinIO 的部署架构。 有关具体硬件或软件配置的信息，请参阅：

• 硬件检查清单
• 安全检查清单
• 软件检查清单
• 阈值与限制

分布式 MinIO 部署

生产级 MinIO 部署至少由 4 台具有同构存储和计算资源的 MinIO 主机构成。

MinIO 会将这些资源聚合为一个 pool，并以单一对象存储服务的形式对外提供。

使用本地直连存储时，MinIO 可提供最佳性能，例如连接到主机 PCI-E 控制器板上的 NVMe 或 SSD 驱动器。

存储控制器应以 XFS 格式化驱动器并采用 “Just a Bunch of Drives” (JBOD) 配置呈现，不使用 RAID、池化或其他硬件/软件韧性层。 MinIO 不建议使用缓存，无论是在驱动器层还是控制器层。 任意一种缓存都会在填充和清空时导致 I/O 尖峰，从而带来不可预测的性能。

MinIO 会自动将 服务器池中的驱动器分组为 纠删码集合。

纠删码集合是 MinIO 可用性与韧性 的基础组件。 MinIO 会在 服务器池的各节点间对纠删码集合进行对称条带化，以保持纠删码集合驱动器分布均匀。 随后，MinIO 会根据部署的 校验 将对象拆分为数据分片和校验分片，并将其分布到纠删码集合中。

如需更完整地了解 MinIO 的冗余和自愈机制，请参阅 纠删码 和 对象自愈。

MinIO 使用基于对象名称和路径的确定性哈希算法，为给定对象选择纠删码集合。

对于每个唯一对象命名空间 BUCKET/PREFIX/[PREFIX/...]/OBJECT.EXTENSION，MinIO 在读写操作中始终会选择相同的纠删码集合。 MinIO 会处理 服务器池和纠删码集合内部的所有路由，使选择、读取和写入过程对应用完全透明。

每个 MinIO server 都完整掌握分布式拓扑，因此应用可以连接到部署中的任意节点并对其发起操作。

响应请求的 MinIO 节点会自动处理对部署中其他节点的内部路由，并将最终响应返回给客户端。

应用通常不应自行管理这些连接，因为部署拓扑的任何变化都可能要求应用随之更新。 生产环境应部署负载均衡器或类似网络控制平面组件，以管理到 MinIO 部署的连接。 例如，你可以部署 NGINX 负载均衡器，对部署中的可用节点执行 “least connections” 或 “round robin” 负载均衡。

你可以通过 pool 扩容 增加 MinIO 部署的可用存储。

每个 服务器池都是由自身纠删码集合组成的独立节点组。 MinIO 必须查询每个 服务器池，才能确定读写操作应定向到哪个纠删码集合，因此每增加一个 服务器池，每次调用的节点间流量都会相应增加。 包含目标纠删码集合的 服务器池随后会响应该操作，而这一过程对应用完全透明。

如果你通过 服务器池扩容修改了 MinIO 拓扑，可以通过更新负载均衡器，将新 服务器池的节点纳入应用流量。 应用仍可继续使用该 MinIO 部署的负载均衡器地址，而无需更新或修改。 这样既能保证请求在所有 服务器池之间均匀分布，又能让应用继续使用单一负载均衡器 URL 访问 MinIO。

客户端应用可以使用任意兼容 S3 的 SDK 或库与 MinIO 部署交互。

MinIO 也发布了专门面向兼容 S3 部署使用的 SDK。

MinIO 严格实现 S3 API，包括要求客户端对所有操作使用 AWS Signature V4 或 legacy Signature V2 进行签名。 AWS 签名计算依赖客户端提供的 header，因此负载均衡器、代理、安全程序或其他组件若修改这些 header，就会导致签名不匹配错误并使请求失败。 请确保任何此类中间组件都支持将 header 从客户端到服务器原样透传。

虽然 S3 API 的所有操作都使用 GET 和 POST 等 HTTP 方法，应用通常仍会使用 SDK 来执行 S3 操作。 特别是签名计算的复杂性，通常使通过 curl 或类似 REST 客户端直接交互变得不切实际。 MinIO 建议使用能够自动完成签名计算的兼容 S3 SDK 或库。

复制型 MinIO 部署

MinIO 站点复制 支持在彼此独立的部署之间进行同步。

你可以将对等站点部署在不同机架、数据中心或地理区域，以支持 BC/DR，或为全球分布式 MinIO 对象存储提供地理就近的读写性能。

复制性能主要取决于各对等站点之间的网络延迟。

当对等站点跨地理区域分布时，站点间的高延迟可能导致显著复制滞后。 如果工作负载已经接近或达到部署的总体性能上限，这一问题会进一步放大，因为复制过程本身也需要足够的空闲 I/O 来同步对象。

部署支持站点间故障切换协议的全局负载均衡器或类似网络设备，是多站点部署正常工作的关键。

负载均衡器应支持 health probe/check 设置，以检测某个站点故障，并自动将应用重定向到其他健康对等站点。

在连接均衡和 header 保留方面，负载均衡器应满足与单站点部署相同的要求。 MinIO 复制会通过排队对象来处理瞬时故障。

17.2 - 可用性与韧性

本页从生产视角概述 MinIO 在可用性与韧性方面的设计和特性。

分布式 MinIO 部署

MinIO 将 纠删码 作为在驱动器级或节点级故障期间提供可用性与韧性的核心组件。

MinIO 会将每个对象拆分为数据分片和 校验 分片，并将这些分片分布到单个 纠删码集合 中。

MinIO 使用确定性算法为给定对象选择纠删码集合。

对于每个唯一对象命名空间 BUCKET/PREFIX/[PREFIX/...]/OBJECT.EXTENSION，MinIO 在读写操作中始终会选择相同的纠删码集合。 这也包括同一对象的所有 版本。

MinIO 需要满足 读写仲裁 才能对纠删码集合执行读写操作。

仲裁取决于部署配置的校验值。 读仲裁始终等于配置的校验值，因此只要某个纠删码集合丢失的驱动器数不超过校验值，MinIO 就可以对其执行读操作。

当默认校验值为 EC:4 时，部署中的每个纠删码集合最多可容忍 4 块驱动器丢失，同时仍能继续提供读操作。

写仲裁取决于配置的校验值和纠删码集合大小。

如果校验值小于纠删码集合驱动器数量的 1/2，则写仲裁等于校验值，其行为与读仲裁相似。

MinIO 会自动提高写入降级纠删码集合的对象校验值，以确保该对象能够满足与健康纠删码集合中对象相同的 SLA。 这种校验升级行为提供了额外的风险缓解层，但无法替代修复或更换损坏驱动器这一长期解决方案，后者才是让纠删码集合恢复到完全健康状态的根本方法。

当默认校验值为 EC:4 时，部署中的每个纠删码集合最多可容忍 4 块驱动器丢失，同时仍能继续提供写操作。

如果校验值等于纠删码集合驱动器数量的 1/2，则写仲裁等于校验值加 1，以避免因 “split brain” 场景导致数据不一致。

例如，如果纠删码集合中恰好一半驱动器因网络故障而被隔离，MinIO 会认为仲裁丢失，因为它无法为写操作建立一个 N+1 驱动器组。

纠删码集合如果永久丢失的驱动器数量超过配置校验值，就意味着已经发生数据丢失。

对于最高校验配置，如果驱动器丢失数量等于校验值，纠删码集合就会进入 read only 模式。 对于最大纠删码集合大小 16 和最大校验值 8 的情况，需要丢失 9 块驱动器才会发生数据丢失。

某些瞬时或临时驱动器故障，例如由存储控制器或连接硬件故障引起的情况，仍可能在该纠删码集合内恢复到正常运行状态。

MinIO 还会通过在 pool 的每个节点间对纠删码集合驱动器进行对称条带化，进一步降低纠删码集合故障风险。

MinIO 会根据节点数和驱动器数自动计算最佳纠删码集合大小，其中最大集合大小为 16。 随后，它会跨 pool 为每个纠删码集合从每个节点选择一块驱动器；如果纠删码集合条带大小大于节点数，则会循环选择。 这种拓扑可对单节点故障，甚至该节点上的单个存储控制器故障提供韧性。

在上述拓扑中，该 pool 具有 8 个跨 16 个节点条带化的 16 驱动器纠删码集合。 每个节点都会为每个纠删码集合分配 1 块驱动器。 虽然丢失一个节点在技术上意味着丢失 8 块驱动器，但每个纠删码集合实际上只会各丢失 1 块驱动器。 这使得即使节点停机，系统仍能保持仲裁。

同一 pool 中的每个纠删码集合彼此独立。

即使一个纠删码集合完全降级，MinIO 仍可对其他纠删码集合执行读写操作。

不过，丢失的数据仍可能影响依赖 100% 数据可用性假设的工作负载。 此外，每个纠删码集合都与其他集合完全独立，因此你不能使用其他纠删码集合来恢复一个完全降级的纠删码集合中的数据。 你必须使用 站点 或 存储桶 复制，创建一个具备 BC/DR 能力的远端部署，用于恢复丢失的数据。

对于多 pool MinIO 部署，每个 pool 都至少需要有一个纠删码集合保持读写仲裁，才能继续提供操作能力。

如果某个 pool 丢失了全部纠删码集合，MinIO 就无法再判断某次读写操作原本是否应被路由到该 pool。 因此，即使其他 pool 仍然可用，MinIO 也会停止整个部署中的所有 I/O。

要恢复对该部署的访问，管理员必须将该 pool 恢复到正常运行状态。 这可能需要根据故障严重程度执行磁盘格式化、硬件更换或节点更换。 更完整的文档请参阅 硬件故障恢复。

你可以使用复制远端将丢失数据恢复回该部署。 存储在健康 pool 中的所有数据仍会安全保留在磁盘上。

复制型 MinIO 部署

对于 MinIO 部署中发生的小规模或大规模数据丢失，MinIO 将 站点复制 作为保证业务连续性和灾难恢复 (BC/DR) 的主要手段。

MinIO 复制可以在站点因瞬时或持续停机而发生部分或全部数据丢失时，自动 自愈 该站点。

一旦所有数据同步完成，你就可以恢复对该站点的正常连接。 根据复制滞后量、站点间延迟以及整体工作负载的 I/O 情况，你可能需要临时停止写操作，让各站点完全追平。

如果某个对等站点彻底故障，你可以将其从配置中完全移除。 负载均衡器配置也应移除该站点，以避免将客户端请求路由到离线站点。

然后，你可以在修复原始硬件或完全更换硬件后，通过 将其重新加入站点复制配置 来恢复该对等站点。 MinIO 会在持续复制新数据的同时，自动开始重同步已有数据。

站点在重同步期间仍可通过将 GET/HEAD 请求代理到健康对等站点来继续处理操作

客户端会收到首个返回所请求对象任意版本的对等站点结果。

PUT 和 DELETE 操作通过常规复制流程进行同步。 LIST 操作不会代理，客户端必须只对健康对等站点发起这类请求。

17.3 - 纠删码

• MinIO 纠删码概览

MinIO 将纠删码作为提供数据冗余和可用性的核心组件。 本页介绍 MinIO 的纠删码机制。

有关 MinIO 如何在生产部署中使用纠删码的更多信息，请参阅 可用性与韧性 和 部署架构。

纠删码基础

MinIO 会将每个 服务器池 中的驱动器分组为一个或多个相同大小的纠删码集合。

MinIO 会在初始化 服务器池 时确定纠删码集合的最佳数量和大小。 初次设置完成后，便无法再修改这些参数。

对于每次写操作，MinIO 都会将对象切分为数据和校验分片。

纠删码集合的条带大小决定了部署可用的最大 校验 值。 生成数据分片和校验分片数量的公式如下：

N (ERASURE SET SIZE) = K (DATA) + M (PARITY)

你可以将校验值设置在 0 到纠删码集合大小的 1/2 之间。

对象一旦按某个校验设置写入，即使之后修改校验值，也不会自动更新。

MinIO 至少需要 K 个任意类型的分片才能读取对象。

这里的 K 构成部署的读仲裁。 因此，纠删码集合中至少要有 K 块健康驱动器，才能支持读操作。

对于已经失去读仲裁的对象，MinIO 无法进行重建。 这类对象可能需要通过其他方式恢复，例如 复制重同步。

MinIO 至少需要 K 块纠删码集合驱动器才能写入对象。

这里的 K 构成部署的写仲裁。 因此，纠删码集合中至少要有 K 块可用驱动器在线，才能支持写操作。

当校验 EC:M 恰好等于纠删码集合大小的 1/2 时，写仲裁为 K+1。

这样可以防止 split-brain 场景，例如网络故障导致纠删码集合中的一半驱动器与另一半完全隔离。

K+1 逻辑可确保客户端不会把同一个对象分别写入纠删码集合的两个“半边”，从而避免潜在的不一致。

对于仍满足读仲裁的对象，MinIO 可以使用任意数据分片或校验分片来 自愈 受损分片。

你可以使用 MinIO 纠删码计算器，为计划中的拓扑探索可能的纠删码集合大小和分布方式。 如无特殊原因，建议使用偶数个节点和每节点偶数块驱动器，以简化拓扑规划以及驱动器和纠删码集合分布的理解。

纠删码校验与存储效率

为部署设置校验值，本质上是在可用性与总可用存储之间做平衡。 更高的校验值会提高对驱动器或节点故障的容忍度，但会减少可用存储；更低的校验值则提供更高的可用存储，但对驱动器或节点故障的容忍度也更低。 你可以使用 MinIO 纠删码计算器，查看不同校验值对计划中集群部署的影响。

下表列出了由 1 个节点和 16 块 1TB 驱动器组成的 MinIO 部署在不同纠删码校验级别下的结果：

位腐化防护

Bit rot 是一种静默数据损坏，由存储介质层面的随机变化引起。 对于数据驱动器而言，它通常来自表示数据的电荷衰减或磁取向变化。 成因可以从停电时的微小电流尖峰，到导致比特翻转的随机宇宙射线。 这种“bit rot”会在不触发监控工具或硬件告警的情况下，对数据介质造成细微错误或损坏。

MinIO 对 HighwayHash algorithm 的优化实现，确保其能够在运行时捕获并自愈受损对象。 它通过在 READ 时计算哈希并在 WRITE 时进行校验，确保从应用、网络到内存或驱动器的端到端完整性。 该实现专为速度设计，在 Intel CPU 上单核即可达到超过 10 GB/sec 的哈希速度。

17.4 - 对象自愈

什么是自愈？

自愈是 MinIO 恢复受损、损坏或部分丢失对象的能力。 这类丢失或损坏可能来自多种情况，包括但不限于：

• 驱动器级错误或故障
• 操作系统或文件系统错误或故障
• bit rot

自愈与纠删码

MinIO 恢复受损对象的能力，直接取决于以下因素：

• 对象所在 纠删码集合 的驱动器总数

• 保留对象完整分片的可用驱动器数量

• 该纠删码集合的 校验设置

  Parity 指 MinIO 在写入对象时创建的专用恢复分片数量。 例如，一个纠删码集合可能总共有 8 块驱动器，其中 3 块用于校验。 在这种情况下，MinIO 会把对象拆分为 5 个数据分片和 3 个校验分片。 MinIO 会将这 8 个分片分布到纠删码集合中的各块驱动器上。 不会有某一块驱动器只包含校验分片或只包含数据分片。 相反，MinIO 会以随机化方式写入每个对象的分片，以便将读取均匀分散到各块驱动器上。

  当 MinIO 需要返回该对象时，它会查找对象对应的数据分片。 如果某些数据分片丢失或损坏，MinIO 会使用一个或多个校验分片来恢复对象。 如果在查找校验分片时发现某些校验分片也丢失或损坏，只要仍有足够的其他分片可供返回对象，MinIO 也会一并恢复这些校验分片。 在上述场景中，即使最多有 3 个数据分片丢失或损坏，MinIO 仍然可以成功恢复并返回该对象。

  保留对象完整数据分片或校验分片的可用驱动器数量，必须大于或等于该纠删码集合中用于数据分片的驱动器数量。 在上述场景中，至少需要 5 块保留完整分片的驱动器在线且可用，MinIO 才能成功返回该对象。

MinIO 何时对对象执行自愈？

MinIO 提供了一套健壮的对象自愈机制。

在 GET 请求期间自愈

每当你通过 GET 或 HEAD 请求对象时，MinIO 都会自动检查该对象数据分片的一致性。 对于启用了版本控制的存储桶，MinIO 在 PUT 操作期间也会执行一致性检查。

如果所有数据分片都完好无损，MinIO 会直接从数据分片返回对象，而不会检查对应的校验分片。

如果对象存在丢失或损坏的数据分片，MinIO 会先使用可用的校验分片对对象执行自愈，然后再作为本次操作的一部分返回。 每个丢失或损坏的数据分片都 必须 有一个完好的校验分片可用，否则对象无法恢复。 如果某些校验分片丢失或损坏，只要仍有足够的其他校验分片可用于返回对象，MinIO 也会恢复这些校验分片。

通过对象扫描器自愈

MinIO 使用 对象扫描器 执行多项与对象相关的任务。 其中一项任务就是检查对象完整性，并在发现损坏或损毁时执行自愈。

在每一轮扫描中，MinIO 会根据对象名称的哈希值，从每 1,024 个对象中选择 1 个进行检查。

如果发现对象存在分片丢失，MinIO 会使用可用分片对对象执行自愈。 默认情况下，MinIO 不会 使用扫描器检查 bit rot 损坏。 这类操作的成本较高，而多个磁盘同时发生 bit rot 的概率较低。

通过手动请求自愈

管理员可以使用 mc admin heal 发起一次全系统自愈。 该过程会大量消耗资源，通常并非必需。

在部署上手动启动自愈流程之前，请先与 MinIO 工程师沟通。

自愈指标

MinIO 提供了若干自愈指标（英文），用于监控部署中的自愈过程状态。

有关可用 endpoint 和配置的更多信息，请参阅 指标与告警。

17.5 - 对象扫描器

概览

MinIO 使用内置扫描器检查对象是否需要自愈，并执行任何已计划的对象操作。 这类操作可能包括：

• 计算驱动器上的数据使用量
• 评估并应用已配置的 生命周期管理 或 对象保留 规则
• 执行 存储桶 或 站点 复制
• 检查对象是否存在丢失或损坏的数据分片或校验分片，并执行 自愈

扫描器在两个层级执行这些功能：集群层级和存储桶层级。 在集群层级，扫描器会将所有存储桶划分为多个组，并一次扫描其中一组。 扫描器会先处理自上次扫描以来新增的存储桶，然后再以随机顺序扫描其他存储桶。 在完成所有存储桶组的检查后，扫描器会重新开始新一轮扫描。

在存储桶层级，扫描器会对存储桶内条目分组，并从该存储桶中选择部分条目进行扫描。 扫描器会根据对象名称的哈希值来选择要扫描的对象。 在 16 轮扫描的周期内，MinIO 会检查命名空间中的每个对象。 对于自上次扫描以来确认新增的任何前缀，MinIO 会执行完整扫描。

扫描时长

影响一次扫描完成时间的因素有很多。

其中包括：

• 提供给 MinIO 的驱动器类型
• 可用吞吐量和 iops
• 对象数量和大小
• MinIO Server 上的其他活动

例如，默认情况下，MinIO 会暂停扫描器，以便将 I/O 资源让给读写请求。 这会拉长扫描完成所需的时间。

MinIO 在每次扫描之间的等待时间，会按本次扫描操作耗时乘以一个系数来计算。 默认情况下，该系数为 10.0，表示 MinIO 会在一次扫描完成后等待相当于该操作耗时 10 倍的时间，再开始下一次扫描。 这个系数会根据配置的 扫描器速度设置 发生变化。

扫描器性能

影响扫描器性能的因素有很多。 其中包括：

• 可用节点资源
• 集群规模
• 纠删码集合数量相对于驱动器数量的关系
• 存储桶层级结构的复杂度（对象和前缀）

例如，在相同硬件和工作负载条件下，一个从 100TB 数据增长到 200TB 数据的集群，扫描完整个存储桶和对象命名空间所需的时间会更长。 同样地，单个包含 16 块驱动器的纠删码集合，其扫描耗时会长于把相同数量驱动器拆分为两个 8 驱动器纠删码集合的情况。

MinIO 将扫描器视为后台任务，并会暂停它以优先完成集群中的读写请求。 随着集群规模或工作负载增长，为保证普通 S3 操作的优先级，扫描器会更频繁地让出资源，因此其性能会下降。

你可以使用 MINIO_SCANNER_SPEED 环境变量或 scanner speed 配置项， 调整 MinIO 在扫描器性能与读写操作之间的平衡方式。

扫描器指标

MinIO 提供了若干与扫描器相关的指标（英文）。

使用 mc admin scanner info 可以查看扫描器当前状态，以及距离上次完整扫描所经过的时间。 这有助于理解扫描器操作提供的各项指标。

扫描器指标（包括 usage 指标）反映的是最近一次完成的扫描结果。 自上次扫描以来发生的 PUT 或 DELETE 操作，不会在 usage 中体现，直到受影响的存储桶完成下一次扫描。

输出类似如下：

Overall Statistics
------------------
Last full scan time:   0d0h14m; Estimated 2885.28/month
Current cycle:         70464; Started: 2024-04-19 20:02:34.568479139 +0000 UTC
Active drives:         2

Last Minute Statistics
----------------------
Objects Scanned:       620 objects; Avg: 124.929µs; Rate: 892800/day
Versions Scanned:      620 versions; Avg: 2.801µs; Rate: 892800/day
Versions Heal Checked: 0 versions; Avg: 0ms
Read Metadata:         621 objects; Avg: 88.416µs, Size:
ILM checks:            656 versions; Avg: 663ns
Check Replication:     656 versions; Avg: 1.061µs
Verify Deleted:        0 folders; Avg: 0ms
Yield:                 3.086s total; Avg: 4.705ms/obj

17.6 - 阈值与限制

本页列出了适用于 MinIO 的阈值与限制。

有关相关建议和要求，请参阅 hardware 和 software。

S3 API 限制

纠删码限制

对象名称限制

文件系统和操作系统限制

MinIO 中的对象名称主要受本地操作系统和文件系统限制。 Windows 和某些其他操作系统会限制包含特定特殊字符的文件系统名称，例如 ^、*、|、\、/、&、" 或 ;。

此列表并不完整，也不一定适用于你的操作系统和文件系统组合。

在类 Unix 操作系统上，路径名为 .、.. 或 / 的对象会返回 file access denied 错误。

请查阅你的操作系统供应商或文件系统文档，以获得适用于当前环境的完整列表。

MinIO 建议生产工作负载使用基于 XFS 文件系统的 Linux 操作系统。

冲突对象

应用必须为所有对象分配不冲突的唯一键。 这包括避免创建与父对象或同级对象名称发生冲突的对象。 当名称发生冲突时，MinIO 在该位置的 LIST 操作会返回空结果集。

例如，以下操作会创建命名空间冲突：

PUT data/invoices/2024/january/vendors.csv
PUT data/invoices/2024/january <- collides with existing object prefix

PUT data/invoices/2024/january
PUT data/invoices/2024/january/vendors.csv <- collides with existing object

虽然你仍然可以对这些对象执行 GET 或 HEAD 操作，但名称冲突会导致在 /invoices/2024/january 路径上的 LIST 操作返回空结果集。

18 - 扩展分布式 Silo 部署

Silo 支持通过添加新的服务器池扩展现有分布式部署。每个 pool 都会增加集群的总可用存储容量。

扩容并不能提供 Business Continuity/Disaster Recovery (BC/DR) 级别的保护。 虽然每个 pool 都是一组相互独立的服务器，并通过各自的 纠删码集合 提供可用性，但只要其中一个 pool 完全丢失，MinIO 就会停止该部署中所有 pool 的 I/O。 同样地，只要某个 pool 中的某个纠删码集合失去 quorum，该集合中存储的对象就会发生数据丢失，而不受其他纠删码集合或 pool 数量的影响。

新的 服务器池 不必 与现有任一 服务器池 使用相同类型或规格的硬件和软件配置，不过保持一致通常有助于简化集群管理，并让各 pool 间的性能表现更可预测。 新 pool 内的所有驱动器 应当 保持相同类型和容量。 有关如何选择合适配置的完整建议，请参阅 MinIO 的 硬件建议。

若要为单 pool 或多 pool 的 MinIO 部署提供 BC/DR 级别的故障切换与恢复支持，请使用 站点复制。

本页步骤用于为现有 分布式 MinIO 部署增加一个额外的 服务器池。

前提条件

网络与防火墙

部署中的每个节点都应当与其他所有节点具备完整的双向网络访问能力。 对于容器化或编排式基础设施，这可能需要针对 Ingress、负载均衡器等网络和路由组件进行专门配置。 某些操作系统还可能需要设置防火墙规则。 例如，以下命令会在使用 firewalld 的服务器上显式开放 MinIO server 默认 API 端口 9000：

firewall-cmd --permanent --zone=public --add-port=9000/tcp
firewall-cmd --reload

部署中的所有 MinIO server 必须 使用相同的监听端口。

如果你为 MinIO Console 设置了静态端口（例如 :9001）， 则还必须允许外部客户端访问该端口，以确保连接可用。

MinIO 强烈建议 使用负载均衡器管理到集群的连接。 由于部署中的任意 MinIO 节点都可以接收、转发或处理客户端请求，因此负载均衡器应采用 “Least Connections” 算法将请求路由到 MinIO 部署。

以下负载均衡器已知可与 MinIO 良好配合：

• NGINX
• HAProxy

如何配置防火墙或负载均衡器以支持 MinIO 不在本步骤范围内。 为 MinIO Server 配置 NGINX 代理 参考页提供了一个将 NGINX 作为反向代理并启用基础负载均衡的基线配置。

连续主机名

MinIO 在创建 服务器池 时，要求 使用扩展表示法 {x...y} 来表示一组连续的 MinIO 主机。 因此，MinIO 要求 使用连续编号的主机名来表示 pool 中的每个 minio server 进程。

在开始本步骤之前，请先创建所需的 DNS 主机名映射。 例如，以下主机名可用于一个 4 节点分布式 服务器池：

• minio5.example.com
• minio6.example.com
• minio7.example.com
• minio8.example.com

你可以使用扩展表示法 minio{5...8}.example.com 来指定完整的主机名范围。

如何配置 DNS 以支持 MinIO 不在本步骤范围内。

存储要求

以下要求概括了 MinIO 硬件建议中的 存储 一节：

使用本地存储

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

磁盘使用 XFS 格式

MinIO 强烈建议为存储配置使用 XFS 格式化的磁盘。 MinIO 在内部测试和验证套件中使用 XFS，因此对其在各种规模下的性能和行为更有信心。

对于 EXT4、BTRFS 或 ZFS 等其他文件系统，MinIO 既不 测试，也不推荐。

使用一致的磁盘类型

MinIO 不区分磁盘类型，也无法从混合存储类型中获益。 每个 pool 都必须使用相同类型的磁盘（NVMe、SSD）

例如，部署一个仅由 NVMe 磁盘组成的 pool。 如果你在其中混用 SSD 或 HDD，MinIO 会将这些磁盘与 NVMe 磁盘一视同仁。 这可能导致性能问题，因为某些磁盘的读写特性不同或更差，无法以与 NVMe 磁盘相同 的速率响应。

使用一致的磁盘容量

MinIO 会将每块磁盘的可用容量限制为 pool 中最小磁盘的容量。

例如，部署一个由相同数量、容量均为 7.68TiB 的 NVMe 磁盘组成的 pool。 如果其中有一块磁盘容量为 3.84TiB，MinIO 会将 pool 中所有磁盘都视为只有 该较小容量。

配置顺序编号的磁盘挂载

MinIO 在创建新的 服务器池 时使用 Go 扩展表示法 {x...y} 表示顺序连续的 磁盘序列，其中 服务器池 中所有节点都挂载了完全相同的一组磁盘。 最好将磁盘挂载路径也配置成顺序序列，以便支持这种表示法。 例如，可按 /mnt/drive-n 的模式挂载磁盘，其中 n 从 1 开始，并随每块 磁盘按 1 递增。

在重启后保持磁盘挂载与映射一致

使用 /etc/fstab 确保节点重启前后磁盘到挂载点的映射保持一致。

非 Linux 操作系统应使用等效的磁盘挂载管理工具。

满足纠删码校验的最小驱动器数量

MinIO 要求每个 pool 都满足部署的 纠删码 设置。 具体来说，新 pool 的拓扑必须为每个 纠删码集合 提供至少 2 x EC:N 个驱动器，其中 EC:N 是该部署的 Standard 校验存储类。 这一要求可确保新的 服务器池 满足该部署预期的 SLA。

你可以使用 MinIO Erasure Code Calculator 检查新 pool 的 Erasure Code Stripe Size (K+M)。 如果列出的最大值至少为 2 x EC:N，则该 pool 支持部署当前的纠删码校验设置。

时间同步

多节点系统必须保持时间和日期同步，才能维持稳定的节点间操作与交互。 请确保所有节点都定期同步到同一时间服务器。 不同操作系统可采用不同方式同步时间和日期，例如 ntp、timedatectl 或 timesyncd。

请查阅所用操作系统的文档，了解如何在各节点之间建立并维护准确且一致的系统时钟。

先备份集群设置

在开始扩容前，使用 mc admin cluster bucket export 和 mc admin cluster iam export 命令分别为存储桶元数据和 IAM 配置创建快照。 必要时，你可以使用这些快照恢复 存储桶 和 IAM 设置，以从用户错误或流程错误中恢复。

注意事项

写入文件

MinIO 不会自动在新的 服务器池 之间重新平衡对象。 相反，MinIO 会根据某个 pool 的空闲空间占所有可用 pool 总空闲空间的比例，将新的写入操作分配到空闲空间最多的 pool。

用于计算某个 pool 被选中执行写操作概率的公式如下：

$FreeSpaceOnPoolA / FreeSpaceOnAllPools$

假设有一个由三个 pool 组成的部署，总空闲空间为 10 TiB，分布如下：

• Pool A 有 3 TiB 空闲空间
• Pool B 有 2 TiB 空闲空间
• Pool C 有 5 TiB 空闲空间

MinIO 计算各 pool 被用于写入操作的概率如下：

• Pool A：30% ($3TiB / 10TiB$)
• Pool B：20% ($2TiB / 10TiB$)
• Pool C：50% ($5TiB / 10TiB$)

除空闲空间计算外，如果某次写入（含校验）会导致驱动器使用率超过 99%，或已知剩余 inode 数量低于 1000，MinIO 也不会写入该 pool。

如有需要，你可以使用 mc admin rebalance 手动启动重平衡过程。 有关重平衡工作方式的更多信息，请参阅 跨部署管理对象。

同样地，MinIO 不会向正在退役中的 pool 执行写入。

扩容是无中断的

新增 服务器池 需要在大致同一时间重启部署中的 所有 MinIO server 进程。

MinIO 强烈建议同时重启一个部署中的所有 MinIO 服务端进程。 MinIO 操作具有原子性并保持严格一致。 因此，该重启过程不会中断应用或正在进行的操作。

不要 执行“滚动”重启（例如一次只重启一个节点）。

基于容量的规划

MinIO 建议预先规划足以存放 至少 2 年数据的存储容量，并在使用率达到 70% 之前完成准备。 如果过于频繁地执行 服务器池 扩容，或按“just-in-time”方式扩容，通常意味着架构或规划存在问题。

例如，假设某套应用每年预计至少产生 100 TiB 数据，并计划在 3 年后再扩容。 初始 服务器池 为该部署提供了约 500 TiB 的可用存储，使集群能够在安全满足 70% 阈值的同时，为数据增长保留一定缓冲。 理想情况下，新 服务器池 至少 也应提供 500 TiB 的额外存储，以便在下次扩容前维持类似的生命周期。

由于 MinIO 纠删码 需要预留部分存储用于校验，因此总 原始 存储容量必须高于计划中的 可用 容量。 建议使用 MinIO 纠删码计算器，围绕具体纠删码设置进行容量规划。

推荐的操作系统

本教程默认所有运行 MinIO 的主机都使用 推荐的 Linux 操作系统。

部署中的所有主机都应采用一致的 软件配置。

扩展分布式 MinIO 部署

以下步骤将向现有 MinIO 部署中添加一个 服务器池。 每个 Pool 都会在保持集群整体 可用性 的同时，扩展集群的总可用存储容量。

以下所有命令都使用示例值。 请将这些值替换为适用于你部署的实际值。

开始本步骤前，请先阅读 前提条件。

在 退役旧硬件 pool 之前，请先完成所有计划中的硬件扩容。

1) 在新服务器池的每个节点上安装 Silo 二进制

安装与现有 pool 完全相同的公开 Silo 版本。从下载与安装获取 x86-64 或 ARM64 的 RPM、DEB 或独立归档，并在安装前校验摘要。当前 Silo 发布只提供这两种 Linux 架构，因此已删除继承文档中指向未发布 ppc64le 与 s390x 制品的说明。

sudo dnf install ./minio-*.rpm

sudo dpkg -i ./minio_*_amd64.deb

tar -xzf minio_*_linux_*.tar.gz
sudo install -m 0755 ./minio /usr/local/bin/minio
minio --version

在每个新节点运行 minio --version 并与现有 pool 比对；不要把版本不同的节点加入集群。需要升级时，请遵循systemctl 管理的 Silo 升级流程。

2) 添加 TLS/SSL 证书

当 MinIO 检测到 ${HOME}/.minio/certs 目录中存在有效的 x.509 证书 （.crt）和私钥（.key）时，会自动启用 传输层安全（TLS） 1.2+。

对于由 systemd 管理的部署，请使用运行 MinIO server 进程的用户对应的 $HOME 目录。提供的 minio.service 文件会以 minio-user 身份运行 该进程。前一步已经包含了如何创建该用户及其主目录 /home/minio-user 的说明。

• 在每个主机上将 TLS 证书放置到 /home/minio-user/.minio/certs 中。
• 如果 任何 MinIO server 或客户端使用了由未知证书颁发机构签名的证书 （自签或内部 CA），你 必须 将 CA 证书放到该部署中所有 MinIO 主机的 /home/minio-user/.minio/certs/CAs 下。MinIO 会拒绝无效证书 （不受信任、已过期或格式错误）。

如果 minio.service 文件指定了其他用户账户，请改用该账户对应的 $HOME 目录。或者，也可以通过 minio server --certs-dir 命令行参数指定 自定义证书目录。修改 /etc/default/minio 中的 MINIO_OPTS 变量即可设置 此选项。运行 MinIO server 进程的 systemd 用户 必须 对指定目录具有读取和 列目录权限。

有关为 MinIO 配置 TLS 的更具体指导，包括通过 Server Name Indication (SNI) 支持多域名，请参见 网络加密（TLS）。你也可以跳过这一步，以不启用 TLS 的方式 部署。除了早期开发阶段以外，MinIO 强烈 不建议 使用非 TLS 部署。

3) 创建 systemd 服务文件

.deb 或 .rpm 软件包会将以下 systemd 服务文件 安装到 /usr/lib/systemd/system/minio.service。 对于二进制安装方式，请在所有 MinIO 主机上手动创建该文件。

[Unit]
Description=MinIO
Documentation=https://silo.pgsty.com/zh/docs/
Wants=network-online.target
After=network-online.target
AssertFileIsExecutable=/usr/local/bin/minio

[Service]
Type=notify

WorkingDirectory=/usr/local

User=minio-user
Group=minio-user
ProtectProc=invisible

EnvironmentFile=-/etc/default/minio
ExecStart=/usr/local/bin/minio server $MINIO_OPTS $MINIO_VOLUMES

# Let systemd restart this service always
Restart=always

# Specifies the maximum file descriptor number that can be opened by this process
LimitNOFILE=1048576

# Turn-off memory accounting by systemd, which is buggy.
MemoryAccounting=no

# Specifies the maximum number of threads this process can create
TasksMax=infinity

# Disable timeout logic and wait until process is stopped
TimeoutSec=infinity

# Disable killing of MinIO by the kernel's OOM killer
OOMScoreAdjust=-1000

SendSIGKILL=no

[Install]
WantedBy=multi-user.target

# Built for ${project.name}-${project.version} (${project.name})

The minio.service file runs as the minio-user User and Group by default. You can create the user and group using the groupadd and useradd commands. The following example creates the user, group, and sets permissions to access the folder paths intended for use by MinIO. These commands typically require root (sudo) permissions.

groupadd -r minio-user
useradd -M -r -g minio-user minio-user
chown minio-user:minio-user /mnt/disk1 /mnt/disk2 /mnt/disk3 /mnt/disk4

The specified drive paths are provided as an example. Change them to match the path to those drives intended for use by MinIO.

Alternatively, change the User and Group values to another user and group on the system host with the necessary access and permissions.

MinIO publishes additional startup script examples on github.com/minio/minio-service.

To update deployments managed using systemctl, see 升级由 systemctl 管理的 MinIO 部署.

4) 创建服务环境文件

在 /etc/default/minio 创建环境文件。 MinIO 服务会将该文件作为 MinIO 以及 minio.service 文件所用全部 环境变量 的来源。

以下示例假设：

• 该部署当前只有一个 服务器池，由四台使用连续主机名的 MinIO server 主机构成。

  minio1.example.com   minio3.example.com
  minio2.example.com   minio4.example.com

  每台主机都有 4 块本地直连驱动器，挂载点连续：

  /mnt/disk1/minio   /mnt/disk3/minio
  /mnt/disk2/minio   /mnt/disk4/minio

• 新的 服务器池 由八台使用连续主机名的新 MinIO 主机构成：

  minio5.example.com   minio9.example.com
  minio6.example.com   minio10.example.com
  minio7.example.com   minio11.example.com
  minio8.example.com   minio12.example.com

• 所有主机都具有八块本地直连驱动器，挂载点连续：

  /mnt/disk1/minio  /mnt/disk5/minio
  /mnt/disk2/minio  /mnt/disk6/minio
  /mnt/disk3/minio  /mnt/disk7/minio
  /mnt/disk4/minio  /mnt/disk8/minio

• 该部署有一个运行在 https://minio.example.net 的负载均衡器，用于管理到所有 MinIO 主机的连接。 在此步骤中，负载均衡器不应将请求路由到新主机，但应已准备好所需的配置更新计划。

请根据你的部署拓扑修改示例：

# Set the hosts and volumes MinIO uses at startup
# The command uses MinIO expansion notation {x...y} to denote a
# sequential series.
#
# The following example starts the MinIO server with two 服务器池s.
#
# The space delimiter indicates a seperate 服务器池
#
# The second set of hostnames and volumes is the newly added pool.
# The pool has sufficient stripe size to meet the existing erasure code
# parity of the deployment (2 x EC:4)
#
# The command includes the port on which the MinIO servers listen for each
# 服务器池.

MINIO_VOLUMES="https://minio{1...4}.example.net:9000/mnt/disk{1...4}/minio https://minio{5...12}.example.net:9000/mnt/disk{1...8}/minio"

# Set all MinIO server options
#
# The following explicitly sets the MinIO Console listen address to
# port 9001 on all network interfaces. The default behavior is dynamic
# port selection.

MINIO_OPTS="--console-address :9001"

# Set the root username. This user has unrestricted permissions to
# perform S3 and administrative API operations on any resource in the
# deployment.
#
# Defer to your organizations requirements for superadmin user name.

MINIO_ROOT_USER=minioadmin

# Set the root password
#
# Use a long, random, unique string that meets your organizations
# requirements for passwords.

MINIO_ROOT_PASSWORD=minio-secret-key-CHANGE-ME

你可以根据部署需要指定其他 环境变量 或 server 命令行选项。 部署中的所有 MinIO 节点都应包含相同且取值一致的环境变量。

5) 使用扩展后的配置重启 MinIO 部署

在部署中的每个节点上 同时 执行以下命令，以重启 MinIO 服务：

sudo systemctl restart minio.service

Use the following commands to confirm the service is online and functional:

sudo systemctl status minio.service
journalctl -f -u minio.service

MinIO may log an increased number of non-critical warnings while the server processes connect and synchronize. These warnings are typically transient and should resolve as the deployment comes online.

MinIO 强烈建议同时重启一个部署中的所有 MinIO 服务端进程。 MinIO 操作具有原子性并保持严格一致。 因此，该重启过程不会中断应用或正在进行的操作。

不要 执行“滚动”重启（例如一次只重启一个节点）。

6) 后续步骤

• 更新所有负载均衡器、反向代理或其他网络控制平面，使客户端请求能够路由到 MinIO 分布式部署中的新主机。 虽然 MinIO 会在内部自动管理路由，但由控制平面处理初始连接通常可以减少网络跳数并提升效率。
• 查看 MinIO Console，确认更新后的集群拓扑并监控性能。

19 - 修改 Silo Tenant

部署完成后，你可以修改租户以调整可变配置项。 有关 MinIO Custom Resource Definition 中可用设置的完整说明，请参阅 MinIO 自定义资源定义。

修改租户的方法取决于你最初如何部署该租户：

kubectl apply -k ~/kustomization/TENANT-NAME/

helm upgrade TENANT-NAME minio-operator/tenant -f values.yaml -n TENANT-NAMESPACE

添加受信任的证书颁发机构

MinIO 租户会使用主机系统的受信任根证书存储，校验每个连接客户端提供的 TLS 证书。 MinIO Operator 可以为租户挂载额外的第三方 Certificate Authorities (CA)，以便校验由这些 CA 签发的客户端 TLS 证书。

若要自定义挂载到每个租户 MinIO pod 的受信任 CA，请启用 Custom Certificates 开关。 点击 Add CA Certificate + 按钮即可添加第三方 CA 证书。

如果 MinIO 租户无法在容器操作系统的信任库 或 显式挂载的 CA 中匹配到传入客户端 TLS 证书的签发者，MinIO 会将该连接视为无效并拒绝。

管理租户 Pool

指定 Runtime Class

在为租户添加新 pool 或修改现有 pool 时，你可以为这些 pool 指定 Runtime Class Name。

退役租户 服务器池

MinIO Operator 4.4.13 及更高版本支持退役租户中的 服务器池。 具体而言，你可以遵循 Decommission a Server pool 步骤先从租户中移除该 pool，然后编辑租户 YAML，将该 pool 从 StatefulSet 中移除。 移除租户 pool 时，请确保所有剩余 pool 的 spec.pools.[n].name 字段都具有明确取值。

https://minio-{1...4}.example.net/mnt/drive-{1...4}
https://minio-{5...8}.example.net/mnt/drive-{1...4}
https://minio-{9...12}.example.net/mnt/drive-{1...4}

https://minio-{1...4}.example.net/mnt/drive-{1...4}
https://minio-{9...12}.example.net/mnt/drive-{1...4}
https://minio-{13...16}.example.net/mnt/drive-{1...4}

20 - 以容器方式部署 Silo

本页说明如何在支持容器化进程的操作系统上以容器方式部署 Silo。

本文档假定已安装 Docker、Podman 或其他支持标准容器镜像格式的类似 runtime。已发布的 pgsty/minio 发行镜像使用 Red Hat Universal Base Image 9 Micro。

Silo 容器的功能和性能可能会受到基础操作系统的限制。

本步骤包含对 单机多盘 (SNMD) 和 单机单盘 (SNSD) 拓扑的指导，适用于早期开发和评估环境。

注意事项

检查清单

在执行本步骤前，请先阅读我们发布的硬件、软件和安全检查清单。

纠删码校验

Silo 会根据拓扑中的节点和驱动器总数，自动为集群确定默认的 纠删码 配置。你可以在设置集群时配置按对象生效的 parity，也可以让 Silo 选择默认值（生产级集群默认为 EC:4）。

校验值决定了对象可用性与磁盘存储占用之间的关系。可使用上游 MinIO 纠删码计算器 比较校验级别，但应将它视为上游规划工具，而不是 Silo 支持契约。

虽然你可以随时更改纠删码校验设置，但以既有校验值写入的对象 不会 自动更新为新的校验设置。

容器存储

本步骤假定你会将一个或多个专用存储设备挂载到容器中，作为 Silo 的持久化存储。

存储在容器临时路径上的数据会在容器重启或删除时丢失。 使用此类路径的风险需自行承担。

步骤

1. 启动容器

本步骤提供 Podman 和 Docker 在 rootfull 模式下的说明。 对于 rootless 部署，请参考各 runtime 自身的文档完成配置和容器启动。

对于其他容器 runtime，请参阅对应文档，并使用等效的选项、参数或配置。

mkdir -p ~/silo/data

podman run \
   -p 9000:9000 \
   -p 9001:9001 \
   --name silo \
   -v ~/silo/data:/data \
   -e "MINIO_UPDATE=off" \
   -e "MINIO_ROOT_USER=ROOTNAME" \
   -e "MINIO_ROOT_PASSWORD=CHANGEME123" \
   pgsty/minio:latest server /data --console-address ":9001"

mkdir -p ~/minio/data-{1..4}

podman run \
   -p 9000:9000 \
   -p 9001:9001 \
   --name silo \
   -v /mnt/drive-1:/mnt/drive-1 \
   -v /mnt/drive-2:/mnt/drive-2 \
   -v /mnt/drive-3:/mnt/drive-3 \
   -v /mnt/drive-4:/mnt/drive-4 \
   -e "MINIO_UPDATE=off" \
   -e "MINIO_ROOT_USER=ROOTNAME" \
   -e "MINIO_ROOT_PASSWORD=CHANGEME123" \
   pgsty/minio:latest server /mnt/drive-{1...4} --console-address ":9001"

mkdir -p ~/silo/data

docker run \
   -p 9000:9000 \
   -p 9001:9001 \
   --name silo \
   -v ~/silo/data:/data \
   -e "MINIO_UPDATE=off" \
   -e "MINIO_ROOT_USER=ROOTNAME" \
   -e "MINIO_ROOT_PASSWORD=CHANGEME123" \
   pgsty/minio:latest server /data --console-address ":9001"

mkdir -p ~/minio/data-{1..4}

docker run \
   -p 9000:9000 \
   -p 9001:9001 \
   --name silo \
   -v /mnt/drive-1:/mnt/drive-1 \
   -v /mnt/drive-2:/mnt/drive-2 \
   -v /mnt/drive-3:/mnt/drive-3 \
   -v /mnt/drive-4:/mnt/drive-4 \
   -e "MINIO_UPDATE=off" \
   -e "MINIO_ROOT_USER=ROOTNAME" \
   -e "MINIO_ROOT_PASSWORD=CHANGEME123" \
   pgsty/minio:latest server /mnt/drive-{1...4} --console-address ":9001"

2. 连接到部署

控制台

在浏览器中打开 http://localhost:9001 以访问 Silo Console 登录页。

使用上一步中的 MINIO_ROOT_USER 和 MINIO_ROOT_PASSWORD 进行登录。

你可以使用内嵌 Console 执行常规管理任务，例如身份与访问管理、指标和日志监控，或 Server 配置。

CLI

请按照 Silo 客户端安装说明 安装 mcli，并运行 mcli --version 验证。已发布的独立归档与 Linux 软件包安装 mcli；源码构建和客户端容器则保留 mc 可执行文件名。

安装完成后，为该 Silo 部署创建一个别名：

mcli alias set silo http://localhost:9000 USERNAME PASSWORD

请根据你的部署修改主机名、用户名和密码。

21 - 监控与告警

• 使用 MinIO 和 Prometheus 进行监控：概览
• 使用 MinIO 和 Prometheus 进行监控：实验

指标与告警

MinIO 使用 Prometheus 数据模型 发布时点指标。 你可以使用任何支持该数据模型的抓取工具，将这些指标拉取到数据库中，以生成历史视图、执行指标查询与分析，或基于关注的数据点创建告警。

下表列出了将 MinIO 指标接入部分第三方监控软件的教程。

其他支持 Prometheus 数据模型的指标与分析软件套件，即使未出现在上表中，也可能同样可用。

日志

MinIO 会将所有 minio server 操作输出到系统控制台。 MinIO 还支持将服务日志和审计日志发布到 HTTP Webhook。

• 服务日志 包含与系统控制台中相同的 minio server 操作日志。 服务日志适用于常规监控与运维排障。
• 审计日志 会以更细粒度描述 MinIO 部署上的每一次操作。 审计日志适用于需要对操作进行详细追踪的安全标准与合规要求。

MinIO 会将日志作为 JSON 文档，通过 PUT 请求发送到每个已配置的端点。 端点服务器负责处理这些 JSON 文档。 MinIO 要求显式配置每个 Webhook 端点，默认情况下 不会 向 Webhook 发布日志。

更完整的文档请参见 将服务日志或审计日志发布到外部服务。

健康检查

MinIO 提供无需身份验证的端点，用于探测节点在线状态以及集群 高可用性，从而执行简单健康检查。 这些端点只返回 HTTP 状态码。 更多信息请参见 健康检查 API。

21.1 - 使用 Prometheus 进行监控与告警

• 使用 MinIO 和 Prometheus 进行监控：概览
• 使用 MinIO 和 Prometheus 进行监控：实验

MinIO 使用 Prometheus 数据模型 发布集群、节点、存储桶和资源指标。 本页过程说明了以下内容：

• 配置 Prometheus 服务，抓取并展示 MinIO 部署的指标
• 基于某个 MinIO 指标配置 Alert Rule，以触发 AlertManager 动作

本文说明使用 version 2 指标。 关于指标 API 版本的更多信息，请参见 指标与告警。

配置 Prometheus 收集 MinIO 指标并触发告警

1) 生成抓取配置

使用 mc admin prometheus generate 命令生成 Prometheus 执行抓取请求所需的 scrape 配置：

mc admin prometheus generate ALIAS

global:
   scrape_interval: 60s

scrape_configs:
   - job_name: minio-job
     bearer_token: TOKEN
     metrics_path: /minio/v2/metrics/cluster
     scheme: https
     static_configs:
     - targets: [minio.example.net]

mc admin prometheus generate ALIAS node

global:
   scrape_interval: 60s

scrape_configs:
   - job_name: minio-job-node
     bearer_token: TOKEN
     metrics_path: /minio/v2/metrics/node
     scheme: https
     static_configs:
     - targets: [minio-1.example.net, minio-2.example.net, minio-N.example.net]

mc admin prometheus generate ALIAS bucket

global:
   scrape_interval: 60s

scrape_configs:
   - job_name: minio-job-bucket
     bearer_token: TOKEN
     metrics_path: /minio/v2/metrics/bucket
     scheme: https
     static_configs:
     - targets: [minio.example.net]

mc admin prometheus generate ALIAS resource

global:
   scrape_interval: 60s

scrape_configs:
   - job_name: minio-job-resource
     bearer_token: TOKEN
     metrics_path: /minio/v2/metrics/resource
     scheme: https
     static_configs:
     - targets: [minio.example.net]