4节点是minio高可用最小可行规模，需统一启动命令启用纠删码、nginx四层代理负载均衡、mc定期健康检查与prometheus告警监控。
在 Linux 环境中用 MinIO 实现高可用对象存储，核心不是堆节点数量，而是让纠删码、分布式启动、负载均衡和健康闭环四者协同工作。4 节点是最小可行规模，能容忍 1 个节点故障，且无需额外副本开销。
确保集群启动即启用纠删码
MinIO 的高可用能力完全依赖于分布式模式下的纠删码（EC），它不是可选功能，而是启动方式决定的。必须用统一命令在所有节点上启动，显式列出全部节点地址：
- 每台服务器准备相同结构的数据目录（如 /data），挂载到独立物理盘或 LVM 卷，不能共用同一块系统盘
- 所有节点使用相同的 MINIO_ROOT_USER 和 MINIO_ROOT_PASSWORD 环境变量（密钥强度建议 12 位以上，含大小写字母+数字+符号）
- 在每个节点执行完全一致的启动命令（以 4 节点为例）：
minio server http://192.168.1.101/data http://192.168.1.102/data http://192.168.1.103/data http://192.168.1.104/data - 启动后检查日志是否出现 All minio nodes online；若某节点显示 offline，优先排查 DNS 解析、防火墙（开放 9000 端口）、SELinux 或磁盘权限问题
Nginx 做 TCP 层代理更稳定
MinIO 官方推荐 Nginx 在 4 层（stream 模块）做负载均衡，而非 7 层 HTTP 代理。因为 S3 协议大量使用长连接与分块上传，HTTP 层代理易引发 header 丢失、超时中断等问题。
- 确认 Nginx 已编译 stream 模块：nginx -V 2>&1 | grep -o with-stream
- 在 /etc/nginx/nginx.conf 的顶层添加 stream 区块（不在 http 内）：
stream {
upstream minio_cluster {
server 192.168.1.101:9000;
server 192.168.1.102:9000;
server 192.168.1.103:9000;
server 192.168.1.104:9000;
}
server {
listen 9000;
proxy_pass minio_cluster;
proxy_timeout 1h;
proxy_responses 1;
}
} - 重启 Nginx：sudo systemctl reload nginx，客户端直接访问 Nginx 所在 IP 的 9000 端口即可
验证与维持真实高可用状态
部署完成不等于持续高可用。需建立轻量但有效的验证机制：
- 用 mc admin info myminio（需先用 mc alias set 配置别名）查看各节点状态、磁盘健康、EC 配置（如显示 Erasure: 4 data + 2 parity 表示当前为 6 节点等效容错，4 节点默认是 2+2）
- 手动模拟节点宕机：关闭一台 MinIO 进程（pkill minio），观察剩余节点是否仍能正常上传/下载对象，并确认控制台（任一节点 :9001）中该节点变为 down 但 bucket 列表和对象列表完整
- 定时检查磁盘空间与 inode 使用率：df -h /data && df -i /data，MinIO 对 inode 敏感，满会导致写入失败
- 将 mc admin heal 加入 cron，每周自动扫描并修复静默损坏（silent corruption）
监控与备份不能只靠“能看”
Prometheus 抓取 MinIO metrics 是基础，但关键在于设置有效告警：
- MinIO 自带指标端点：http://node-ip:9000/minio/v2/metrics/cluster（需配置 Prometheus job 抓取）
- 必设告警规则：minio_cluster_nodes_down > 0（节点离线）、minio_disk_usage_percent > 85（磁盘预警）、minio_health_status == 0（整体健康异常）
- 备份不是复制数据目录，而是用 mc mirror 将生产 bucket 同步到另一套 MinIO 集群或云 S3，保留 7 天版本，启用 --watch 实现实时增量同步
