通过最佳网络配置充分利用 MinIO — 方法如下

MinIO 可以以分布式方式部署，从而有效利用多个物理或虚拟机的计算和存储资源。这可以是在私有云或公共云环境中运行的 MinIO，例如 Amazon Web Services、Google Cloud Platform、Microsoft Azure 平台等。 MinIO 可以部署到多种类型的拓扑 - 在生产中我们建议使用多节点多驱动器(MNMD) 部署。 MinIO 建议使用站点复制来为您的单站点部署提供 BC/DR 级故障转移和恢复支持，您可以根据您的使用案例进行设计和优化。

在之前的博客文章中，我们已经讨论了为 MinIO 部署选择硬件时要使用的一些最佳实践。我们涉及硬件的各个方面，从选择最佳区域、正确的驱动器、CPU 和内存配置，甚至一些推荐的网络配置。虽然我们涉及了系统设计的各种不同最佳实践，但我们总是可以更深入，今天我们将深入探讨设计 MinIO 的一些要点，以获得驱动器和网络的最佳性能。

在这篇博文中，我们将深入探讨网络配置，您可以使用这些配置将 MinIO 配置为不同的复制策略和网络拓扑，这些策略和网络拓扑可用于确保跨多个 MinIO 部署高效存储和访问您的数据。您不需要进行任何复杂的配置，例如设置绑定/双网卡（这会增加额外的开销）。

简单的网络策略

MinIO 是用于云原生服务的 S3 兼容存储后端。一般来说，我们将网络流量视为应用程序和集群之间或集群中的节点之间的网络流量。由于节点间的流量，节点之间的联网速度尽可能快至关重要。每个池由一组具有自己的擦除集的独立节点组成。 MinIO 必须查询每个池以确定其将读取和写入操作定向到的正确擦除集，以便每个附加池增加最小但每次调用的节点间流量。然后，包含正确擦除集的池响应该操作，对应用程序保持完全透明。

企业使用 1 GbE 或 10 GbE NIC 的日子已经一去不复返了。现代企业工作负载理想地利用 100 GbE NIC。考虑到 TCP 协议的物理和开销限制，这些 NIC 预计将提供 80-90% 的可用带宽，对于 100 Gbps NIC 通常约为 10GB/s，在真正配置良好的网络上可达 12GB/s。 MinIO 不需要任何额外的开箱即用的网络配置来利用所有带宽，因为它侦听所有接口。 MinIO 开箱即用，支持侦听多个网络接口 (NIC)。

您不需要为 MinIO 网络进行任何其他特殊配置，但可以选择使用我们之前讨论的一些网络基础知识，通过特定接口路由 MinIO 流量。

在此示例中，我们将使用 Linux 操作系统进行演示，但无论您使用哪种操作系统，网络基础知识都是相同的。根据网络配置的不同，实现可能会略有不同，但这应该可以给您一个想法。

我们首先列出路由表

$ ip route 10.56.98.0/24 dev eth0 proto kernel scope link src 10.56.98.18

如果您已将 MinIO 服务器配置在 10.56.98.16/28 CIDR 范围内，假设 MinIO 节点的 IP 地址之一是 10.56.98.21，它将通过 eth0 接口进行路由，因为 /28 与 10.56 的路由表条目匹配.98.0/24。

但是，如果您想通过 eth1 而不是 eth0 路由 MinIO 流量，我们需要为 MinIO CIDR 添加特定路由，以便与该子网匹配的任何流量都通过该特定网络接口路由

$ ip route add 10.56.98.16/28 dev eth1

添加路由后，我们再次列出路由表，看看它是什么样子的

$ ip route 10.56.98.0/24 dev eth0 proto kernel scope link src 10.56.98.33.18 10.56.98.16/28 dev eth1 scope link

现在我们看到了 /28 CIDR 的路由。如果您 ping MinIO 节点 10.56.98.21，它现在将通过 eth1 接口进行路由。这是因为，当有两条路由 /24 与 /28 重叠时，通常会优先考虑具有最长前缀的路由（在本例中为 /28），并且在路由流量时将优先于任何其他较短前缀路由。这称为最长匹配前缀规则。

如果您 ping 10.56.98.21，然后检查 tcpdump，则可以验证来自 10.56.98.16/28 的流量是否已正确路由，如下所示。您会注意到来自源 10.56.98.18 的流量正在通过 eth1 路由到 10.56.98.21。

 $ tcpdump -n -i eth1 icmp … 15:55:44.410450 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 123, length 64 15:55:44.410471 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 123, length 64 15:55:45.434489 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 124, length 64 15:55:45.434518 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 124, length 64 15:55:46.458490 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 125, length 64 15:55:46.458520 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 125, length 64

正如您所看到的，MinIO 不需要额外的特殊端口或服务来实现流量分离。 MinIO 的设计考虑到了简单性，在这种情况下，我们总是考虑构建还是购买，而不是构建像网关服务这样复杂的东西，MinIO 利用操作系统层已有的网络基础知识，以尽可能少的开销实现相同的结果可能的。

我们可以将这个想法更进一步。如今，服务器至少有 2 个接口，并且可以选择添加更多接口。因此，您可以让应用程序也运行在单独的 CIDR 块上（选择适合您的应用程序大小的块），而不是让应用程序流量通过与 MinIO 相同的接口。这种分离可确保用于复制和重新平衡的 MinIO 流量不会影响应用程序的性能，反之亦然。它还使您能够监控和跟踪流量，以确保 MinIO 始终拥有执行操作所需的容量和带宽，而不影响其性能。

但是，如果您的 MinIO 跨不同站点或区域怎么办？如何有效配置它以确保不存在性能瓶颈？嗯，MinIO 为一些最严格的用例提供了几种不同类型的复制配置。

最丰富的复制策略之一是站点到站点复制。这允许您从单个集群启动 MinIO，并随着需求的增加扩展到 N 个集群。假设您有一个在 3 个不同站点上运行的 ETL/ELT 应用程序。一般来说，数据仅在其中一个区域可用，其他区域需要跨区域拉取大量数据才能运行其流程。不用说，这不仅效率极低，而且给网络基础设施带来巨大压力，并可能导致共享 WAN 的其他应用程序出现瓶颈。

在站点到站点复制配置中，您仅将数据写入第一个站点中的 MinIO 集群。复制过程会自动将数据复制到其他站点。无需对 ETL/ELT 应用程序进行任何其他更改。您只需将每个站点中的作业指向由 Nginx 等反向代理支持的各自 MinIO 集群，读取速度将比跨区域的 WAN 快得多，如下所示。

但这引出了一个问题，是否有可能进一步微调流量？假设您将数据文件添加到站点 1，无论一天中的什么时间，它都会立即将其复制到其他站点。可能是在高峰期间，其他 ETL/ELT 作业可能正在运行，同时网络资源正在用于复制数据，而这些数据可能要等到第二天下一批应该运行时才会使用。这种情况下可以做什么呢？这就是 MinIO 的批量复制派上用场的地方。批量复制允许您选择要在特定时间复制的数据类型，它是完全可配置的。在这种情况下，可以将批量复制作业设置为在流量最低的非工作时间运行。由于应用程序访问时间可能会在一天、一周甚至一个月内发生变化，因此监控 MinIO 网络流量就派上用场了，这样您就可以将批处理作业配置为在正确的时间运行。您可以在不同的机架、数据中心或地理区域中部署对等站点，以支持全球分布式 MinIO 对象存储中的 BC/DR 或地理本地读/写性能等功能。

最后的想法

回顾一下，MinIO 的网络架构是最简单、最直接的网络架构之一。 MinIO 没有重新发明轮子，而是使用网络基础知识来实现与其他一些数据存储的同等性，这些数据存储具有复杂的网络和网关设置，几乎无法调试。无论您调试同一问题多少次，由于架构的混淆性质，您都会感觉这是第一次遇到它。相反，MinIO 专注于更高级别的抽象，从而减轻应用程序开发人员维护数据复制的负担，而专注于存储和处理数据。

与往常一样，如果您对 MinIO 网络配置或如何设置有任何疑问，请务必通过Slack联系我们，或者最好注册SUBNET订阅！