MinIO 第 2 天：扩展、硬件操作、管理

术语“第二天”指的是在初始规划和部署阶段之后维护集群所需的运营。此时需要升级集群，扩展存储空间，并监控资源。不仅如此，随着集群的不断发展，硬件故障是不可避免的。您不应该担心故障，而是应该假设它会在某个时间点发生，并从一开始就做好计划。 

在今天的文章中，我们将深入探讨一些需要考虑的长期管理 MinIO 的因素，这样，当第二天 48 小时后到来时，您就可以万事俱备。

集群硬件操作

扩展 MinIO 部署

我们 SUBNET 的工程师始终建议客户根据初始需求开始构建集群，并在需要更多存储空间时扩展他们的 MinIO 部署。我们构建 MinIO 的目的是使用 服务器池 使扩展变得更容易。  但工作不会随着扩展而结束，您仍然需要确保数据使用 存储桶 或 站点复制 进行复制，我们稍后会详细介绍。

您需要考虑一些先决条件，以确保添加池尽可能顺利。

需要启用防火墙，以允许双向通信，使其能够与同一集群中的所有其他 MinIO 节点进行通信。这意味着网络应该允许 MinIO 端口 9000 在所有相互通信的节点上运行。在 Linux 中，该命令看起来像这样。

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

除了防火墙，您还需要确保使用最少连接算法来路由请求，将流量分布到集群中的 MinIO 节点。我们在之前的 博客文章 中展示了如何使用 Nginx 来实现这一点。

池中的所有服务器必须具有相同的 CPU、内存和原始磁盘容量。MinIO 建议使用直接连接的 JBOD 驱动器，这意味着没有网络和没有 RAID。MinIO 使用 擦除编码 处理磁盘级数据保护，并使用 存储桶、站点 和 批量复制 方法处理硬件级复制。这样就不需要任何额外的硬件或网络开销来扩展集群。MinIO 需要使用扩展表示法 {x...y} 来表示创建新服务器池时的连续驱动器序列。MinIO 还要求物理驱动器的排序在重启后保持一致，以便挂载点始终指向相同的已格式化驱动器。我们建议使用 /etc/fstab 或类似的基于文件的挂载配置，以确保驱动器排序更可预测，并且无法在重新引导后更改。然后，您可以使用扩展表示法 /mnt/disk{1...4} 指定整个驱动器范围。如果要在每个驱动器上使用特定的子文件夹，请将其指定为 /mnt/disk{1...4}/minio。

如前所述，为新 MinIO 池中的所有节点选择类似的硬件配置至关重要。确保 CPU、内存、主板、驱动器存储适配器以及软件（如操作系统、内核设置和系统服务）在池中的所有节点上保持一致。如果节点具有异构硬件或软件配置，则新池可能会表现出不可预测的性能。从将陈旧数据存储在成本较低的硬件中获益的工作负载应该改为使用 ILM 部署专用“暖”或“冷” MinIO 部署，并将数据迁移到该层。我们将在本文后面讨论有关 ILM 的更多内容。

我们之前写了一篇关于 文章，介绍了升级 MinIO 是多么容易和顺利。在扩展池时，我们仍然推荐相同的做法。不要对 MinIO 进行滚动重启，我们建议同时重启所有节点上运行的 MinIO，因为操作是原子的并且严格一致。因此，扩展集群不会导致 MinIO 停机。

不用说，原始容量需要大于可用容量，以考虑校验数据的擦除编码存储和意外使用情况的缓冲空间。一般来说，我们建议在扩展之前计划至少 2 年以上，因为频繁扩展不建议，因为它们会增加管理集群的复杂性。事实上，我们的工程师建议您将初始集群部署的可用空间设置得尽可能大，比如接下来 5-6 年，这样可以将集群中的池数量降至最低。

要详细了解如何扩展集群，请参阅我们的 文档。

升级 MinIO

如前所述，MinIO 中的升级是非破坏性的。我们以一种促进 CI/CD 的方式设计了它，该方式可以定期以恒定的速度进行更新。您无需安排维护窗口或将集群脱机。我们建议选择流量最少的时间进行升级。更棒的是，无需对 MinIO 守护程序进行滚动重启。MinIO 工程师建议使用 Ansible 等工具同时重启所有节点上的所有 MinIO 守护程序，以便所有节点重新连接到更新的升级版二进制文件。

有关如何在生产环境中升级 MinIO 的详细步骤，请查看我们的 文章。

取消分配服务器池

您可能认为 取消分配池 的常见原因是为了回收未使用的空间，但事实并非如此。如前所述，我们不建议您继续向集群添加池，因为它可能会使管理变得很麻烦。但是，如果您已经有了几个池，您可以简化集群的管理吗？当然可以。这就是取消分配池发挥作用的地方。

本质上，您构建一个新的更大集群，该集群具有能够包含当前集群中一个或多个池的容量。新池设置完毕后，您可以通过简单地取消分配旧池来将数据迁移到新池。因此，您已经从 5-6 个池减少到 2 个，但您的总容量也增加了。这就是为什么与 SUBNET 的工程师沟通以帮助您设计初始集群设置至关重要的原因。他们可以正确地指导您如何构建初始集群，甚至不需要在将来添加池，但仍然以一种能够在未来因不可预见的需求而需要扩展时添加更多池的方式进行设计。

通常，取消分配功能旨在删除旧的服务器池，这些池的硬件性能不再足以满足部署中的池。MinIO 会根据每个池中可用空闲空间的比例，将数据从取消分配的池自动迁移到部署中的剩余池。

非破坏性硬件故障

认为最好的硬件很少会发生故障的想法很天真。这就是为什么最好预测和规划故障，而不是假设它们不会发生。故障类型多种多样，但最常见的三个类型是驱动器故障、节点故障和站点故障。

如前所述，我们建议对与 MinIO 一起使用的服务器使用 JBOD。原因之一是在故障期间，这使得热插拔一个或多个驱动器变得更加容易。您无需重新配置 RAID 控制器即可删除故障驱动器。MinIO 会检测到新驱动器的添加，并进行修复，而无需任何节点或部署级重启。MinIO 修复只发生在替换的驱动器上，不会影响集群性能。MinIO 修复确保所有恢复到驱动器上的数据的完整性和一致性。

MinIO 集群中可能会发生两种类型的节点故障。与所有分布式软件一样，节点可能会由于短暂的网络故障而失去与集群的连接，或者可能是它崩溃并且必须重启。无论原因如何，一旦节点连接到集群的其余部分，它将开始修复操作，而不会影响集群的性能。第二种类型的故障是节点完全发生故障，并且必须替换新的节点，而不会保留任何现有数据。务必确保新的替换节点与取消分配的服务器具有相同的规格，如果无法获得具有相同规格的节点，则获得与集群中具有最小原始磁盘空间的节点具有相同规格的节点。

最后但并非最不重要的一点是，整个站点可能会脱机，就像世界上许多数据中心多次发生的那样。站点复制使两个或多个 MinIO 集群与 IAM 策略、存储桶、存储桶配置、对象和对象元数据保持同步。如果对等站点发生故障，例如由于重大灾难或长时间停电，您可以使用剩余的正常站点将可复制的数据恢复到另一个站点。添加新站点后，或者如果现有站点恢复联机，您无需手动干预即可重新同步数据。当站点再次相互通信时，它们将复制在停机期间未复制的增量，因此在任何情况下都不会丢失数据。

管理集群

对象生命周期管理

有助于使集群保持精简，而无需可能添加额外硬件的核心概念之一是 ILM 规则。在我们之前的 文章 中，我们深入探讨了各种 ILM 规则和策略，以展示对象的生命周期以及如何计划可能将旧数据分流到可能只有主轴磁盘而不是快速 NVMe 驱动器的更实惠的硬件中。

这意味着你可以保持高性能 NVMe 配置的 MinIO 集群（热层）精简，而高容量的 spindle HDD 配置的 MinIO 集群（冷层）可以保存归档数据。MinIO 使得使用 ILM 规则变得非常容易，因为我们根据 S3 语法设计了它们 - 实际上，你可以复制来自 S3 存储桶的规则并在 MinIO 中使用它。

版本控制和对象锁定

在处理各种合规机构和法律保留时，会出现 WORM 模式，即“一次写入，多次读取”。在 MinIO 中，一旦对象被写入，它就不可变。你可以在创建存储桶时启用对象锁定，根据 S3 行为，你可以在任何时候配置对象保留规则。你不能在没有启用版本控制的情况下创建的存储桶上启用对象锁定。对象锁定需要版本控制并隐式启用该功能。版本控制和对象锁定交织在一起的原因是，在 WORM 锁定下保存的对象在锁定过期或被明确解除之前是不可变的。锁定是针对每个对象版本的，每个版本都是独立不可变的。

如果应用程序对锁定对象执行非版本化删除操作，该操作将生成一个删除标记。尝试显式删除任何 WORM 锁定的对象都将失败并出现错误。我们根据合规性要求支持各种模式，其中一个例子是GOVERNANCE 模式，它默认启用对象锁定。

对象分层

MinIO 可以通过编程方式配置对象存储分层，以便对象根据任意数量的变量从一种状态或类别转换到另一种状态或类别 - 尽管最常用的变量是访问时间和频率。在分层环境中，这种功能最容易理解。分层允许用户优化存储成本或功能，以解决不断变化的数据访问模式。分层数据存储通常用于以下场景：

跨存储介质的分层是最为人所知且最直接的分层用例。在这里，MinIO 抽象了底层介质，并共同优化了性能和成本。例如，数据可以存储在 NVMe 或 SSD 上以实现性能或近线工作负载，但在一段时间后或对于重视规模而不是性能的工作负载，可以分层到 HDD 介质。随着时间的推移，这些数据可以进一步迁移到长期存储（如果合适）。

监控和故障排除

我们已经撰写了几篇关于监控 MinIO 的多种方法的文章。当然，你可以使用Prometheus，但你也可以使用其他开源工具，例如OpenTelemetry、OpenObserve 和Jaeger 来监控集群运行状况，例如可用磁盘、网络吞吐量、CPU/内存使用情况，以及其他关键系统组件。在 MinIO，我们始终建议不仅监控你的集群，还要全面理解图表。换句话说，如果你正在监控集群的总体容量（你应该这样做），你可能希望查看过去几个月的图表，以了解数据使用情况是如何增长的。图表中的线是否在应用程序使用期间以每几个 TB 的速度稳步上升，或者你是否看到突然的峰值 - 如果峰值成为新的增长率，那么你可能需要尽快添加新的池。有时，数据流入可能是不需要的垃圾数据，可以清理掉。但有时它可能意味着意想不到的使用案例，并且使用了更多的磁盘空间。无论哪种情况，密切关注集群都很重要。

一旦监控检测到问题，下一步就是对问题进行故障排除。如何找到图表中峰值的根本原因？它可能是任何东西：磁盘、网络、内存。这就是 SUBNET 门户派上用场的地方。为了全面了解客户端系统，MinIO 开发了一种名为 HealthCheck 的功能，该功能仅对商业客户通过SUBNET 提供。

HealthCheck 为支持的组件提供了一个图形用户界面，并持续运行诊断检查，以确保你的环境能够最佳运行。它还会编目每个硬件和软件组件，以确保整个环境的一致性，同时发现任何差异。这通过快速识别性能和集成问题来加快根本原因分析和问题修复。

对象加密

存储在对象存储解决方案中的数据可能需要满足合规性要求并得到保护，每个对象都需要加密并存储，并在需要时解密。出于这些原因，基础设施和安全团队需要一个可靠的保管库解决方案。

产品/应用程序需要加密数据：产品/应用程序不需要用密码学来复杂化其实现，因为它们可以依赖 HashiCorp 的 Vault 来提供此功能。Vault 专注于对数据进行签名和验证，而不是存储数据。MinIO 和 Vault 等应用程序的组合将确保满足数据静止安全要求。

保护数据库和 Web 服务凭据：具有多种语言数据库的多语言服务架构以及与多个 Web 服务或微服务的集成已变得司空见惯。此外，总是有多个环境。使用基础设施即代码和自动化，管理凭据和访问密钥变得至关重要，因此需要一个高性能的密钥管理和存储解决方案，例如 Vault 和 KES。

用于传输中数据的证书：无论是从浏览器访问的网站、应用程序和数据库之间的通信、从应用程序到 Web 服务或从微服务到微服务之间的通信，每个通信通道之间的通信都必须加密。Vault 可以生成可以用来保护这些通道中传输中数据的 PKI 证书。

为了提供围绕安全锁定和擦除的监管合规性功能，MinIO 对对象进行加密，在存储层使用服务器端加密 (SSE) 来保护作为写入操作的一部分的对象。MinIO 以极高的效率执行此操作 - 基准测试表明，MinIO 能够以接近线速的速度进行加密/解密。

日志记录

使用 MinIO，你可以将日志发送到多个目标以进行分析。你可以将日志发送到远程目标，例如 ElasticSearch 提供的 Webhook，你也可以直接将它们发送到 SUBNET 支持门户 - 无需手动上传。通过共享日志，你可以为协助你解决问题的 MinIO 工程团队提供有关集群操作的更详细的信息。你可以使用以下命令启用集群的“呼叫主页”日志来自动将日志发送到 SUBNET：

启用后，日志可能需要几分钟才能发送到 SUBNET 门户，请等待 30 分钟以确保，然后刷新以检查。

令人愉快的第 2 天

我们在设计 MinIO 时就考虑到了第 2 天。这就是为什么我们设计升级为一项非中断的例行任务。这使你的工程和 DevOps 团队能够专注于编写有价值的代码，而不是花时间管理存储基础设施。虽然新客户通常关注第 0 天和第 1 天，但在这些讨论中规划第 2 天至关重要，以便一帆风顺。

如果你想了解更多关于第 2 天操作的信息，或者有任何问题，请务必通过Slack 与我们联系！