隔离部署 MinIO

AJ AJ 于 DevOps 2023 年 12 月 14 日

网络的不同部分，例如 DMZ、公共网络、私有网络、堡垒机等。这实际上取决于您的组织和网络需求。在部署应用程序（任何应用程序）时，我们需要考虑其类型以及它是否需要位于网络的特定部分。

例如，如果您要部署数据库，您不希望它位于公共网络上，您可能希望它位于私有网络中，从外部互联网无法访问它。为什么？简单来说，数据库中包含大量更敏感的信息，并且某些数据库中的访问控制列表不够严格，无法应对直接访问时被入侵的可能性。此外，最终用户很少直接访问数据库，他们通常通过前端应用程序访问它，然后该应用程序对数据库执行结构化查询。

在这篇文章中，我们将讨论什么是隔离网络，在这样的环境中部署 MinIO 时需要考虑哪些因素，以及之后如何与其他隔离站点复制和扩展它。

什么是隔离网络？

通常在私有网络中，以下 CIDR 中的 IP（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16），除非您使用具有公共 IP 的代理（您必须先连接到该代理，例如 VPN 或反向代理），否则您无法从互联网入站连接到节点。通常，节点可以与外部世界通信，因为数据中心通常使用某种 NAT 或互联网网关 (IGW) 来路由来自此 NAT/IGW 设备的公共请求，以便能够下载软件包以进行上传以及其他操作。

顾名思义，隔离网络更进一步，不仅您无法从互联网访问它，而且您也无法从节点连接到互联网。这些节点在这个网络中完全被锁定。您可能仍然可以通过 VPN 访问它们，但通常建议连接到堡垒机，然后仅允许从堡垒机节点的私有 IP 访问隔离网络。

在隔离网络中部署 MinIO

那么为什么需要这种级别的安全性呢？出于很多目的。我们提到了数据库，但这尤其适用于诸如 MinIO 之类的关键基础设施组件，您无法承受将其中的数据暴露给外部世界，但您需要存储它们并使其能够访问生态系统中的其他应用程序。

在设计隔离网络时，您必须确保所有需要的公共资源（用于该节点的操作）都可供隔离网络访问。这意味着操作系统软件包、RPM/APT 软件包、MinIO 二进制文件以及节点需要从互联网提取的任何其他依赖项都必须已可供隔离网络使用。这可以通过在您的数据中心中一个名为 Ops 网络的特殊网络中本地同步所有这些依赖项的存储库来实现。Ops 网络的特殊之处在于，在此网络中运行的任何服务都可以与互联网通信（反之则不行），并且数据中心内私有网络中的任何应用程序（即使是隔离的）都可以与 Ops 网络中的服务通信。通过这种方法，您一次性解决了许多问题。

您可以清理从互联网下载的软件包，以确保它们没有被篡改。您可以放心，所有应用程序都将使用经过验证的软件包，这些软件包可以安全地从隔离环境中的受信任存储库镜像中安装。
节点构建所需的所有软件包都可以在本地获得，如果上游存储库出现中断，则不会影响隔离环境的操作。
如果发生完全的节点故障，时间至关重要。您更换节点的速度越快，如果更多节点发生故障，集群失去仲裁的可能性就越小。通过更快地重建节点，您可以缩短 MTR（平均解决时间）。

一旦所有必需的资源都可以在隔离网络内部访问，那么在隔离网络中部署 MinIO 就和其他任何情况一样。我们建议在一个站点上至少执行多节点多驱动器部署，以便在发生驱动器故障甚至整个节点故障时，擦除编码可以确保数据复制到其他磁盘和节点。您只需要确保 MinIO 正在运行的端口在所有节点上都已打开，并且可以在隔离网络内部双向访问。

到目前为止一切顺利。我们设计了一个隔离网络。找到了一种方法，可以使用本地镜像的上游资源在其中部署 MinIO。但是我们如何实际使用集群？如果它无法访问外部，我们如何向其中添加数据？实际上这很简单，我们可以使用与传统数据库类似的技术。网络应设计为仅允许通过其前面的应用程序访问 MinIO。它可能是一个完整的完整前端应用程序，可能充当 CDN，或者是一个简单的 ETL 工作流程，使用 MinIO 检索原始数据并存储最终处理的结果。

MinIO 将永远不会直接供最终用户访问，因此，如果公共子网或 DMZ 中的网络遭到入侵，他们将永远无法访问隔离网络中的服务（如 MinIO），因此您的数据和模型是安全的。此外，您会注意到您的整个集群比以前运行得更加稳定，但为什么呢？其他一切都是一样的吗？

原因是稳定性很重要。隔离网络中的任何内容都不会更新，除非您明确希望它更新。让我快速讲一个故事。十年前，当我在一个 SRE 团队时，有一天我们的任务是升级 260 台 Redis 服务器。当我们进行例行维护，准备为新版本准备二进制文件时，我们注意到所有页面加载时间都在增加，并且某些功能根本无法加载。不幸的是，所有这些都是由 Redis 支持的服务。我们感到困惑，我们只准备了二进制文件，为什么所有东西都离线了？5 分钟后，我们立即注意到所有 Redis 服务器都自动升级到了我们仅准备（未部署）的新版本二进制文件。事实证明，在我们的基础设施自动化系统（Puppet）中，我们将其设置为在注意到新软件包准备就绪后立即升级 Redis。因此，它按预期执行并升级了所有服务器，随后一次关闭了多个 Redis 集群。因此错误是我们造成的，我们迅速纠正了它。即使我们的 Redis 服务器是隔离的，我们仍然设法将其关闭，所以想象一下，如果它直接从上游提取，您的服务将在软件包维护人员的意愿下更新。

虽然 MinIO 更新是向后兼容的，并且我们强烈建议您尽可能定期使用我们的零停机原子升级来跟上新版本，但我们仍然不希望您在发布二进制文件时升级您的集群，这只是糟糕的 DevOps 实践，您至少应该知道系统上正在升级什么。有些团队会更进一步，使整个节点不可变，这意味着，无论何时需要升级甚至修改任何内容，他们都必须重建整个节点，这样他们可以确保没有配置漂移。但这在大多数情况下可能比所需的要大，因此在这种情况下，拥有一个隔离的环境是一个不错的选择。

隔离站点复制和安全性

我们讨论了单个区域中的单个集群，但多站点呢？我们的隔离网络现在是否必须通过互联网才能到达其他站点？这难道不会违背隔离环境的目的吗？

与互联网通过物理光纤连接的方式类似，数据中心在大多数情况下通过互联网交换设施相互连接。这些设施提供暗光纤 WAN 链路（广域网），您可以用它做任何事情。您可以启动自己的 ISP 或使用它来连接您位于世界各地的两个不同位置的数据中心。在这些 WAN 链路上运行的协议可以是任何东西，您不需要在它之上运行 VPN。虽然我们仍然建议加密 MinIO 流量，但 WAN 链路也应该有自己的加密，以便数据不会被邻近流量嗅探，因为本质上所有这些链路都是共享的。

一旦 WAN 链路启动并运行，您将能够像站点到站点复制在常规互联网上运行一样，与隔离网络上的其他 MinIO 集群通信。这里唯一的区别在于

流量完全私密，提供了额外的安全层
因为您没有与任何人共享管道，所以您将能够访问管道的全部吞吐量，通常对于关键和时间敏感的应用程序，首选专用分配的 WAN 链路。

请花点时间阅读这篇博文，其中我们讨论了站点到站点复制的最佳实践。

监控隔离中的 MinIO

所以如果一切都是隔离的，您如何发送 MinIO 集群指标并使用诊断分析SUBNET？

这是一个很好的问题。这正是我们提供带有隔离标志的mc diag命令的原因。不仅如此，您还可以匿名化您的数据，以便在发送诊断包之前，对主机名和 IP 等敏感信息进行模糊处理。

要在隔离中创建诊断包，请运行以下命令，该命令还会匿名化数据

mc support diag myminio --airgap --anonymize=strict

● CPU Info ... ✔
● Disk Info ... ✔
● Net Info ... ✔
● Os Info ... ✔
● Mem Info ... ✔
● Process Info ... ✔
● Server Config ... ✔
● System Errors ... ✔
● System Services ... ✔
● System Config ... ✔
● Admin Info ... ✔

mc: MinIO diagnostics report saved to myminio-health_20231111053323.json.gz

登录 https://subnet.min.io/ 并将上面生成的 gzip 文件上传到部署部分。选择要为此报告分析的部署并上传 gzip 文件。文件上传后，SUBNET 中的工程师可以帮助您诊断集群中的任何问题，有时甚至是一些您可能没有意识到的问题。

ET 打电话回家

在隔离环境中运行 MinIO 几乎总是很有意义的。因为存储的数据几乎总是非常敏感的，您不希望 MinIO 端口监听公共网络，从而可能被外部世界入侵。我们构建 MinIO 的首要目标是安全性，但最终您是在 MinIO 无法控制的网络和硬件上运行，因此最好谨慎行事，在隔离环境中确保数据安全。

如果您对隔离环境下的 MinIO 安装有任何疑问，请务必通过 Slack 联系我们！