网络分段对AI工厂的重要性

F5生态系统 | 2024年12月31日

多年来，网络分段一直是实现威胁隔离、服务质量差异化、事件响应与分析、合规审计以及许多其他关键互操作功能的核心。然而，当我们推崇零信任原则并争相部署AI时，是否忽视了这一网络基础设施的核心要素？它是现代网络安全和服务运营的基石。

在此前的AI工厂系列文章中，我们将AI工厂定义为一项对存储、网络和计算的大规模投资，用于满足大规模、高性能的训练和推理需求。为实现这项投资的回报，AI工厂会动态调度高价值图形处理器（GPU）和计算资源，以执行训练和推理。调度GPU需要在每个AI集群中构建多个AI服务“租户”。这会带来一个问题，而许多运维团队往往等到为时已晚才意识到这一点。

使AI工厂集群资源与网络分段保持一致

在AI集群中，可以根据租户上下文对资源进行逻辑分段，从而支持租户配额、资源消耗限制、主机系统安全以及基于管理角色的访问控制（RBAC）。然而，为AI集群与AI工厂网络其他部分之间的流量提供入口和出口的基础网络服务并不会公开租户上下文。缺少这一上下文，作为数据中心网络安全基石的网络分段便无法识别租户边界。公开必要租户上下文的常见方法，要么会大量占用AI工厂宝贵的计算资源，要么会降低网络路径性能，使服务延迟、带宽或并发能力无法达到要求。因此，我们似乎只能在高效利用宝贵的AI工厂资源与将租户正确集成到网络之间二选一。

在公有云基础设施中，经过编排的多租户网络设计是云区域内所有服务的基础，并通过虚拟私有云（VPC）实现。这种虚拟化网络分段对于安全和资源计量至关重要。公有云提供商依靠网络软件开发团队和专用网络硬件来维持此功能，包括SmartNIC和数据处理单元（DPU）。公有云中的AI工厂集群旨在利用底层基础设施的VPC网络编排。维护VPC的成本相当高，但这是公有云业务模式的核心。

问题随之而来：组织如何在无需像公有云提供商那样投入大量资金的情况下，充分发挥AI工厂投资的价值，并动态调度GPU和计算资源？

在这一发展过程中，业界首先采用服务器虚拟化来创建虚拟机（VM）。虚拟机利用硬件直通连接到分段的数据中心网络。如果只需考虑单个AI集群中的单个租户，只需将所有虚拟机置于相同的VLAN中，即可照常运行。

虚拟机还可以解决GPU分段问题，因为GPU供应商支持将GPU设备细分为多组核心和内存，然后分配给特定虚拟机。不过，GPU设备分段无法动态进行，并且需要重启虚拟机。此外，这种设计限制了创建可供多个租户计量使用的GPU资源池的能力。这些都是该解决方案的显著缺点。

使网络分段与多租户AI工厂集群保持一致

当AI工厂集群不再只为单个租户提供服务时，会发生什么？问题随之转移到数据中心。默认情况下，在AI工厂集群中，所有传出至数据中心的网络流量都会经过源网络地址转换（SNAT），其源地址会被转换为发起网络请求的容器化工作负载所在的某个集群节点的IP地址，从而掩盖真实来源。随后，这些流量会显示为来自部署该节点的网段。对于多租户集群，这意味着租户上下文会丢失，多个租户的出站流量混杂在一起，无法区分、保护、排查问题或审计。

默认情况下，流量出站时会丢失集群租户上下文。

纳入入站流量后，这一问题会更加突出。由于入站流量来自已完成分段的数据中心，管理起来可能更容易，但如何将单个租户的入站流量与其出站流量关联起来？答案与检索增强生成（RAG）和智能体服务密切相关。这些服务需要频繁通信，以获取外部数据并使用外部服务。平台工程师和网络运维团队需要跨团队协作，为客户排查问题或设法通过安全审计。

企业可能会问：“为什么不能直接使用软件定义网络（SDN）叠加技术，像超大规模云服务提供商那样构建VPC网络？”这当然可行，但会将成本转移到在现有数据中心基础设施上维护SDN VPC网络。如果需要第2层（例如VxLAN）分段，问题就变成如何编排隧道与机架顶部交换机，并对这些交换机进行配置，使其与网络分段保持一致。因此，超大规模云服务提供商选择了SmartNIC，并转向主机到主机级编排，让数据中心网络保持高速运行，同时不承担智能处理功能。

大多数组织既缺乏网络编程人才，也不愿自行负责如此复杂的主机级编排；或者，它们根本无法舍弃保障服务质量所需的骨干网络可见性。针对这些问题提出的第3层（例如IP）路由解决方案，促使网络团队将AI集群中的每个节点都设为与数据中心建立动态路由的BGP对等体，并尝试通过多个路由反射器提供基本的IP子网租户隔离。这同样会使运维人员面临极其复杂的路由问题和安全审计，并已导致整个区域发生中断。

面向AI工厂的集群感知型编排网络分段

AI工厂必须规划一种功能丰富、可编程、安全且低延迟的网络解决方案，并确保其带宽和并发能力均可扩展。必须将集群内第2层（例如VLAN、VxLAN）和第3层（例如子网、IPSEC接口）的租户上下文扩展至AI工厂网络。网络运维团队必须能够使用可观测性指标、日志和调试工具。

传统上，许多此类应用租户隔离和可见性解决方案由F5 BIG-IP提供。F5 BIG-IP Container Ingress Services (CIS)可动态发现Kubernetes服务，并将其作为虚拟服务器向数据中心公开。虚拟服务器是一种配置对象，BIG-IP管理员对此并不陌生，因为他们在配置物理服务器和虚拟机的对外服务时也会使用这种对象。虽然BIG-IP确实满足了我们对解决方案的许多要求，但它无法管理从AI集群流向AI工厂网络的出站流量，而这对于维持网络分段至关重要。

为解决这一问题，我们设计了F5 BIG-IP Next for Kubernetes。该解决方案基于新一代平台BIG-IP Next构建，适用于多租户计算集群。

BIG-IP Next for Kubernetes支持NetOps将集群租户与网段关联。

BIG-IP Next for Kubernetes完全通过Kubernetes控制平面进行管理，支持Kubernetes管理身份验证和针对所有已声明资源的RBAC，并可通过命名空间识别Kubernetes租户，以支持入站和出站流量所需的网络分段。这对于AI工厂等以编排为先的架构至关重要。

BIG-IP Next for Kubernetes简化了NetOps声明Kubernetes命名空间与网段之间映射关系的方式。AI工厂网络与BIG-IP Next实例之间的动态路由对等互联采用熟悉的路由配置语法。NetOps团队能够以独特的方式安全排查集群入口和出口实时网络流的问题。SecOps团队可获得针对每个集群租户的入口和出口防火墙访问控制列表（ACL）、分布式拒绝服务（DDoS）防护和IPS功能。

对于平台工程团队，BIG-IP Next for Kubernetes可卸载数据入口和出口流量处理、源网络地址转换（Source NAT）及防火墙等网络功能，从而减轻计算资源负担。这有助于降低运营成本，同时保持服务可用性和效率。

BIG-IP Next for Kubernetes还支持Kubernetes Gateway API，这是首个针对网络运维、平台工程、DevOps和MLOps中特定组织角色设计的社区入口API。通过Gateway API，BIG-IP Next for Kubernetes将常见的基于第4层端口或第7层HTTP(S)路由的入口服务扩展为面向DevOps/MLOps的一套服务，包括TCPRoute、UDPRoute、HTTPRoute、TLSRoute和GRPCRoute；这些服务均通过主流AI框架中的同一套CI/CD自动化机制进行控制。

从管理角度来看，BIG-IP Next for Kubernetes通过Kubernetes API声明，帮助NetOps、SecOps、平台工程、DevOps和MLOps团队高效协作。它以Kubernetes的方式提供您对BIG-IP所期待的一切，同时支持网络分段。

DPU的兴起

数据处理单元（DPU）在AI工厂中迅速普及。我们此前在AI工厂系列的一篇博客文章中介绍过，DPU是一种可编程处理器，旨在通过硬件加速，以网络线速处理海量数据传输和数据处理任务。通过F5的产品创新以及与NVIDIA的合作，我们发布了BIG-IP Next for Kubernetes。该产品部署在NVIDIA BlueField-3 DPU上，并使用NVIDIA的DOCA API卸载入站和出站流量的数据流，同时支持网络分段和安全功能。这可确保AI集群获得充足的数据供给，从而充分发挥AI工厂投资的价值。

由F5赋能的AI工厂

投资AI工厂时，必须确保基础设施经过优化、高效且可扩展。部署在NVIDIA BlueField-3 DPU上的F5 BIG-IP Next for Kubernetes可提供动态GPU和计算调度所需的网络分段，同时实现高性能扩展，帮助提升AI投资回报。如需了解详情，联系F5，与您的F5客户经理及解决方案工程师或架构师沟通。

想进一步了解AI工厂？欢迎阅读AI工厂博客系列中的其他文章：