分布式MinIO故障场景

问题描述

我们想在分布式/高可用性设置中运行MinIO，但想了解更多有关MinIO在不同故障场景下的行为的信息。特别是考虑到写入后读取的一致性，我假设节点需要进行通信。

那么，如果一个节点掉线怎么办？其他节点是否会有超时，在此期间不会确认写入？在网络分区（我猜有仲裁的分区将继续运行），或者网络连接不稳定或拥挤时会发生什么？如果某个节点上的磁盘开始变得不稳定，并且一次会挂起10秒钟，该怎么办？网络会暂停并等待吗？

是否有有关MinIO如何处理故障的文档？

解决方法

Minio具有运行状况检查探针

可通过/ minio / health / live
“准备就绪”探针可在/ minio / health / ready

在分布式minio环境中，您可以在minio节点之前使用反向代理服务。例如Caddy代理，它支持每个后端节点的运行状况检查。

这是我正在使用的球童代理配置的示例。

如果您想要tls修饰符/ etc / caddy / Caddyfile看起来像这样

 http://yuourminio.examlple.com:80 {
  redir https://{host}{uri}
}

yuourminio.examlple.com:443 {
tls /etc/ssl/certs/certbundle.pem  /etc/ssl/certs/private.key
proxy / minio01-ip:9000 minio02-ip:9000 minio03-ip:9000 minio04-ip:9000 {
    header_upstream X-Forwarded-Proto {scheme}
    header_upstream X-Forwarded-Host {host}
    header_upstream Host {host}
    health_check /minio/health/ready
    health_check_interval 3s
}

没有tls

     yuourminio.examlple.com:80 { 
     proxy / minio01-ip:9000 minio02-ip:9000 minio03-ip:9000 minio04-ip:9000 {
        header_upstream X-Forwarded-Proto {scheme}
        header_upstream X-Forwarded-Host {host}
        header_upstream Host {host}
        health_check /minio/health/ready
        health_check_interval 3s 
     }

Minio节点还可以将指标发送给Prometheus，因此您可以构建grafana Deshboard并监视Minio Cluster节点。（微型磁盘，CPU，内存，网络）

有关更多信息，请检查文档：
https://docs.min.io/docs/minio-monitoring-guide.html

https://docs.min.io/docs/setup-caddy-proxy-with-minio.html

由于MinIO保证写后读取的一致性，所以我想知道底层节点或网络的各种故障模式下的行为。

MinIO文档（https://docs.min.io/docs/distributed-minio-quickstart-guide.html）很好地解释了如何设置它以及如何保持数据安全，但是当节点关闭或（特别是）发生故障时，群集的行为方式没有任何意义/网络连接速度慢，磁盘导致I / O超时等。

此问题（https://github.com/minio/minio/issues/3536）指出MinIO在内部将https://github.com/minio/dsync用于分布式锁。

从文档中：

如果n / 2 + 1个节点（无论是否包括自身）做出积极响应，则一个节点将成功获得锁。

我认为这是一个非常不错的模型：

只要有n / 2个节点和磁盘可用，读取就会成功。
要执行写入和修改，节点要等到收到至少一半以上（n / 2 + 1）个节点的确认。
没有真正的节点向上跟踪/投票/主选举或任何此类复杂性。节点几乎是独立的。
如果我们有足够的节点，那么发生故障的节点将不会有太大影响。
即使节点缓慢/不稳定，也不会对集群的其余部分产生太大影响；不会在节点的前一半+1之中响应锁，但是没有人会等待它。
对于不相等的网络分区，最大的分区将继续运行。
对于偶数个节点的完全相等的网络分区，写入可能会完全停止工作。

请注意，如果我们直接将客户端连接到MinIO节点，则MinIO本身不会为该节点关闭提供任何保护。对于HA设置，我们仍然需要某种HTTP负载平衡前端。（无论如何，对于星号/身份验证来说可能还是不错的。）

注释2；基于MinIO和dsync的文档，这有点猜测，并说明了问题和懈怠。如果尚未真正测试过这些失败方案，那么如果要在生产环境中运行此故障方案，肯定应该这样做。

distributed high-availability minio