充分利用 AIStor 的网络配置
gQlNx-1734678799577)
AIStor 可以以分布式方式部署，从而有效利用多个物理机或虚拟机的计算和存储资源。这可以是在私有云或公共云环境中运行的 AIStor，例如使用 Amazon Web Services、Google Cloud Platform、Microsoft 的 Azure 平台等。AIStor 可以部署到多种类型的拓扑 – 在生产环境中，我们建议使用多节点多驱动器 （MNMD） 部署。AIStor 建议站点复制为您的单站点部署提供 BC/DR 级故障转移和恢复支持，您可以针对您的使用案例进行设计和优化。在之前的博客文章中，我们已经讨论了为 AIStor 部署选择硬件时要使用的一些最佳实践。我们谈到了硬件的各个方面，从选择最佳区域、正确的驱动器、CPU 和内存配置，甚至一些推荐的网络配置。虽然我们触及了系统设计的广泛不同最佳实践，但我们总是可以更深入地探讨，今天我们将深入探讨设计 AIStor 的一些细节，以充分利用驱动器和网络。在这篇博文中，我们将深入探讨网络配置，您可以使用这些配置将 AIStor 配置为不同的复制策略和网络拓扑，这些策略和拓扑可用于确保在多个 AIStor 部署中高效存储和访问数据。您无需执行任何复杂的配置，例如设置绑定/双 NIC（这会增加额外的开销）。
简单的网络策略
AIStor 是用于云原生服务的 S3 兼容存储后端。通常，我们认为网络流量是应用程序与集群之间或集群中节点之间的网络流量。由于节点间流量，节点之间的联网速度必须尽可能快。每个池都由一组独立的节点组成，这些节点具有自己的纠删集。AIStor 必须查询每个池以确定它将读取和写入操作定向到的正确擦除集，以便每个额外的池每次调用增加的节点间流量最小，但会增加。然后，包含正确纠删集的池将响应该操作，对应用程序保持完全透明。企业可以使用 1 GbE 或 10 GbE NIC 的日子已经一去不复返了。现代企业工作负载理想情况下利用 100 GbE NIC。考虑到 TCP 协议的物理特性和开销的限制，这些 NIC 预计将提供 80-90% 的可用带宽，对于 100 Gbps NIC，通常约为 10GB/s，在真正配置良好的网络上最高可达 12GB/s。AIStor 不需要任何开箱即用的额外网络配置即可利用所有带宽，因为它侦听所有接口。开箱即用的 AIStor 支持侦听多个网络接口 （NIC）。您不需要任何其他特殊配置 AIStor 网络，但可以选择使用我们之前讨论的一些网络基础知识，您可以通过特定接口路由 AIStor 流量。在此示例中，我们将使用 Linux 操作系统进行演示，但无论您使用哪种操作系统，网络基础知识都是相同的。根据网络配置的不同，实现可能略有不同，但这应该会给您一个概念。
我们首先列出路由表
…
$ IP 路由
10.56.98.0/24 dev eth0 proto 内核范围 link src 10.56.98.18
…
如果您已将 AIStor 服务器配置为在 10.56.98.16/28 CIDR 范围内，则假设 AIStor 节点的 IP 地址之一是 10.56.98.21，该地址将通过 eth0 接口路由，因为 /28 与 10.56.98.0/24 的路由表条目匹配。但是，如果您想通过 eth1 而不是 eth0 路由 AIStor 流量，我们需要为 AIStor CIDR 添加特定路由，以便与该子网匹配的任何流量都通过该特定网络接口路由
…
$ ip 路由添加 10.56.98.16/28 dev eth1
…
添加路由后，让我们再次列出路由表，看看它是什么样子的
…
$ IP 路由
10.56.98.0/24 dev eth0 proto kernel scope link src 10.56.98.33.18
10.56.98.16/28 dev eth1 范围 link
…
现在，我们看到 /28 CIDR 的路由。如果您 ping AIStor 节点 10.56.98.21，它现在将通过 eth1 接口路由。这是因为当有两条路由的 /24 与 /28 重叠时，通常优先考虑前缀最长的路由（在本例中为 /28），并且在路由流量时将优先于任何其他较短的前缀路由。这称为 longest-matching prefix rule（最长匹配前缀规则）。如果您 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 回显请求，ID 8416，序列 123，长度 64
15：55：44.410471 IP 10.56.98.21 > 10.56.98.18：ICMP 回显回复，ID 8416，序列 123，长度 64
15：55：45.434489 IP 10.56.98.18 > 10.56.98.21：ICMP 回显请求，ID 8416，序列 124，长度 64
15：55：45.434518 IP 10.56.98.21 > 10.56.98.18：ICMP 回显回复，ID 8416，序列 124，长度 64
15：55：46.458490 IP 10.56.98.18 > 10.56.98.21：ICMP 回显请求，ID 8416，序列 125，长度 64
15：55：46.458520 IP 10.56.98.21 > 10.56.98.18：ICMP 回显回复，ID 8416，序列 125，长度 64
正如您所看到的，使用 AIStor 不需要额外的特殊端口或服务来实现流量分离。AIStor 在设计时考虑到了简单性，在这种情况下，我们一直在考虑构建与购买，而不是构建像网关服务这样复杂的东西，AIStor 利用操作系统层已经可用的网络基础，以尽可能少的开销实现相同的结果。我们可以将这个想法更进一步。如今，服务器至少有 2 个接口，可以选择添加更多接口。因此，您可以让您的应用程序也在单独的 CIDR 块上运行（选择适合您的应用程序大小的块），而不是让应用程序流量通过与 AIStor 相同的接口。这种分离可确保用于复制和再平衡的 AIStor 流量不会影响应用程序的性能，反之亦然。它还使您能够监控和跟踪流量，以确保 AIStor 始终拥有执行操作所需的容量和带宽，而不会影响其性能。但是，如果您在不同的站点或地区拥有 AIStor，该怎么办？如何有效地配置它以确保没有性能瓶颈？AIStor 为一些最严格的使用案例提供了几种不同类型的复制配置。最多产的复制策略之一是站点到站点复制。这允许您使用单个集群启动 AIStor，并随着需求的增加扩展到 N 个数字。假设您有一个在 3 个不同站点上运行的 ETL/ELT 应用程序。通常，数据仅在其中一个区域可用，而其他区域需要跨区域提取大量数据才能运行其进程。毋庸置疑，这不仅效率非常低下，而且会给网络基础设施带来巨大压力，并可能给共享 WAN 的其他应用程序带来瓶颈。
在站点到站点复制配置中，您只需将数据写入第一个站点中的 AIStor 集群。复制过程会自动将数据复制到其他站点。无需对 ETL/ELT 应用程序进行其他更改。您只需将每个站点中的作业指向其各自的 AIStor 集群，该集群由反向代理（如 Nginx）提供支持，读取速度将比跨区域 WAN 读取快得多，如下所示。
但这就引出了一个问题，是否有可能进一步微调流量？假设您将数据文件添加到站点 1，则无论一天中的什么时间，它都会立即将其复制到其他站点。可能是在高峰期，此时其他 ETL/ELT 作业可能正在运行，同时网络资源被用于复制数据，这些数据可能要到第二天下一批应该运行时才会使用。在这种情况下，我们能做些什么呢？这就是 AIStor 的批量复制派上用场的地方。批量复制允许您选择要在特定时间复制的数据类型，它是完全可配置的。在这种情况下，可以将批量复制作业设置为在流量最低的空闲时间运行。由于应用程序访问时间在一天、一周甚至一个月中都可能有所不同，因此监控 AIStor 网络流量就派上用场了，因此您可以配置批处理作业以在正确的时间运行。您可以在不同的机架、数据中心或地理区域中部署对等站点，以支持全球分布式 AIStor 对象存储中的 BC/DR 或地理本地读/写性能等功能。
最后的思考
回顾一下，AIStor 的网络架构是目前最简单明了的网络架构之一。AIStor 没有重新发明轮子，而是使用网络基础知识来实现与其他一些数据存储的奇偶校验，这些数据存储具有复杂的网络和网关设置，几乎不可能调试。无论您调试同一问题多少次，由于架构的混淆性质，您都会感觉这是您第一次遇到它。相反，AIStor 专注于更高级别的抽象，这些抽象减轻了应用程序开发人员的负担，使其不必维护数据复制，而是专注于存储和处理数据。