数据中心机架内互连新范式:为何PCIe正取代以太网与InfiniBand?

news2026/5/12 21:16:00
1. 数据中心互连的十字路口为什么是PCIe在数据中心这个庞大而精密的数字世界里服务器、存储和网络设备之间的“对话”效率直接决定了整个系统的性能上限。过去十几年我们习惯了用以太网Ethernet和InfiniBand来构建这张对话网络。前者凭借其无处不在的生态和成本优势成为连接机架与机架之间的“主干道”后者则以其极致的低延迟和高带宽在需要紧密协作的高性能计算HPC和人工智能训练集群中扮演着“高速公路”的角色。然而当我们把目光从机架之间收回到单个机箱内部也就是服务器刀片Blade与刀片之间、CPU与加速卡、NVMe存储之间时情况就变得微妙起来。传统的做法是“一刀切”机箱内部也走以太网或InfiniBand。这听起来很统一但实际用起来就像在自家客厅里用对讲机通话——能通但别扭、低效且昂贵。以太网协议栈的软件开销、数据在内存缓冲区间的反复拷贝会带来显著的延迟而为了获得足够的带宽10G甚至更高速率的以太网网卡和交换芯片其功耗和成本在机箱内部这个短距离、高密度的场景下显得不那么经济。InfiniBand虽然性能强悍但其生态相对封闭并非所有处理器、存储和I/O设备都原生支持强行接入往往需要额外的协议转换桥接芯片这又引入了新的延迟、功耗和成本。正是在这个背景下一个我们无比熟悉却又长期被低估的技术——PCI ExpressPCIe开始从主板上的扩展槽走向更广阔的舞台。PCIe自诞生以来其核心使命就是在极短的距离内通常是厘米级为CPU和外围设备提供一条超高速、低延迟的直连通道。几乎每一颗现代CPU、每一块GPU、每一组NVMe SSD都原生集成了PCIe控制器。它的价值在于“直接”数据从设备内存到主机内存无需经过复杂的网络协议封装和解封装实现了真正意义上的“零拷贝”和接近硬件的访问延迟。所以问题来了既然PCIe在板级互连上如此高效我们能否将它的能力“放大”让它成为连接整个服务器机架内部所有计算和存储资源的“通用互连织物General-Purpose Fabric”呢这正是过去几年里数据中心架构师和芯片厂商们积极探索的方向。我认为一个理想的数据中心互连架构应该是分层、异构的在机架内部使用PCIe作为高速、低延迟、低功耗的互连骨干在机架之间则根据成本与性能的权衡选择以太网或InfiniBand进行连接。这种“内外有别”的策略能让每种技术都在自己最擅长的领域发挥最大价值。2. 机架内互连的困局以太网与InfiniBand的“水土不服”要理解PCIe为何能成为机架内互连的破局者我们得先看清现有方案在机箱Rack这个特定场景下面临的根本性挑战。2.1 以太网优秀的“广域网”协议尴尬的“局域网”选手以太网的成功在于其无与伦比的普适性和可扩展性。但从技术本质看它最初是为连接地理上分散的设备而设计的局域网LAN协议其协议栈TCP/IP包含了复杂的流量控制、错误恢复和路由寻址机制。当它被用于机架内部这种极短距离、设备身份相对固定的环境时这些为广域不确定性设计的“豪华”功能就变成了负担。首先是软件开销与延迟瓶颈。在典型的机架内以太网通信中即使两个刀片服务器物理上紧挨着数据也需要经历完整的网络协议栈处理从应用层到传输层TCP/UDP再到网络层IP最后封装成以太网帧。接收方则需要反向解封装。这个过程涉及多次内核上下文切换和内存拷贝。一次简单的内存访问请求可能因此产生数十微秒甚至更高的延迟。对于追求纳秒级响应的高频交易、实时数据库或分布式内存池应用这是不可接受的。其次是成本与功耗的经济账。10G、25G、100G的以太网网卡NIC和交换机端口价格不菲。更重要的是实现高速SerDes串行器/解串器和复杂协议处理的芯片功耗很高。在一个高密度的机架内几十个这样的端口同时工作产生的热量和电费是惊人的。而机架内设备间的距离通常不超过几米为这种短距通信支付长距互联的“功率税”显然不划算。最后是功能与耦合度的错配。以太网将每个刀片视为独立的网络节点这提供了灵活的、松耦合的扩展能力。但对于需要紧密共享I/O资源如一块高性能GPU或NVMe存储池的机架来说这种松耦合反而是障碍。它无法像本地总线一样让多个主机处理器以近乎透明的、直接内存访问DMA的方式共享同一块物理硬件往往需要额外的软件抽象层如NVMe over Fabrics这又带来了性能损耗。2.2 InfiniBand性能王者生态“孤岛”InfiniBand从设计之初就是为高性能计算集群量身定制的它采用远程直接内存访问RDMA技术允许数据在网络中从一个节点的内存直接传输到另一个节点的内存完全绕过双方的操作系统和CPU实现了极低的延迟和极高的吞吐量。在延迟敏感型应用中它的表现无可挑剔。然而其问题在于生态系统的局限性。InfiniBand更像一个“贵族俱乐部”。除了少数高端服务器CPU和专门的高性能计算设备绝大多数商用现货COTS组件——从各种形态的加速卡AI、视频处理、到普遍使用的NVMe SSD再到各种网络和存储控制器——它们的原生接口都是PCIe而非InfiniBand。要将这些设备接入InfiniBand网络你必须添加一个“翻译官”即一块PCIe-to-InfiniBand的桥接卡或使用支持InfiniBand的专用设备。这个桥接步骤不仅增加了硬件成本桥接芯片、额外的PCB空间和功耗更关键的是它引入了额外的协议转换延迟破坏了InfiniBand引以为傲的端到端低延迟优势。此外构建一个异构的、包含多种处理器和I/O设备的机架如果强制统一到InfiniBand上会变得异常复杂和昂贵。你需要为每一种非InfiniBand原生设备寻找或定制桥接方案这大大降低了系统的灵活性和可维护性。注意这里并非全盘否定以太网和InfiniBand。恰恰相反在机架间互联、超大规模计算集群等场景它们依然是无可替代的王者。我们讨论的焦点是“机架内”这个特定战场需要的是最适合短兵相接的“匕首”而非用于长途奔袭的“长矛”。3. PCIe作为机架级互连织物的核心优势当我们将PCIe的视角从主板扩展到整个机架时会发现它的一系列特性恰好精准命中了机架内互连的痛点。3.1 原生性与生态统治力这是PCIe最无可比拟的优势。PCIe是现代计算系统的“母语”。x86、ARM服务器CPU NVIDIA、AMD的GPU Intel、三星的NVMe SSD 以及各种FPGA、智能网卡SmartNIC、数据处理器DPU它们的标准高速接口都是PCIe。这意味着当你选择PCIe作为机架内互连时你是在使用设备本身最自然、最直接的通信方式无需任何“翻译”。这带来了最简化的硬件设计设备可以直接通过PCIe链路连接到互连交换机或交换芯片上省去了所有额外的协议转换桥接硬件。庞大的生态系统也意味着充分的市场竞争和持续的技术迭代。从PCIe 3.0、4.0、5.0到如今的6.0每一代带宽几乎翻倍而由多家芯片供应商如Broadcom/Avago、Microchip、Astera Labs等提供的PCIe交换芯片和重定时器Retimer产品确保了供应链的稳定和价格的合理性。3.2 极致的低延迟与高效率PCIe协议在设计上就追求极致的效率。它运行在物理层、数据链路层和事务层。与网络协议相比它的包头开销极小并且其事务如内存读/写、消息是面向连接的、可靠的。在机架内互连的语境下通过使用非透明桥接NTB和多根共享MR-IOV等技术可以实现多个独立主机系统对同一PCIe端点设备如一块GPU或SSD的直接、低延迟共享。其核心机制是直接内存访问DMA和地址转换。主机A可以将设备D映射到自己的地址空间当它需要访问设备D时发出的就是普通的PCIe内存读写请求。PCIe交换和地址转换硬件通常集成在交换芯片或NTB中会透明地将这个请求路由到正确的主机B所属的设备D上并将数据直接写入主机A指定的内存地址或从设备D读取。整个过程数据在物理链路上只传输一次无需在主机内存中进行多次拷贝软件介入极少延迟可以做到微秒甚至亚微秒级。这种效率是以太网基于Socket的通信模型难以企及的。3.3 功耗与成本优化针对机架内米级甚至更短的互连距离PCIe物理层PHY可以进行优化降低发射功率同时保持信号完整性。专用的PCIe交换芯片其功能专注于PCIe协议的路由和交换复杂度远低于需要处理完整TCP/IP协议栈或复杂路由表的以太网交换机芯片。因此在提供相同聚合带宽的情况下PCIe交换方案的功耗和芯片成本通常更具优势。此外由于省去了每个设备端的以太网或InfiniBand适配器NIC或HCA以及相应的桥接芯片从整个机架系统角度看物料清单BOM成本得以降低系统设计也更为简洁。4. 构建基于PCIe的机架级互连架构与关键技术将PCIe扩展到机架级并非简单地将主板上的插槽用线缆拉远。它需要一套完整的系统架构和关键技术支持。4.1 分层互连架构设计理想的基于PCIe的数据中心互连是分层的机架内层PCIe Fabric使用PCIe交换技术如PCIe Switch将机架内所有服务器刀片、存储节点和加速资源连接成一个统一的、可共享的资源池。每个设备都像连接在本地PCIe总线上一样被访问。机架间层Ethernet/InfiniBand Fabric每个机架作为一个“超级节点”通过其头节点或专用的网关设备以更高速的以太网如100G/400G或InfiniBand连接到数据中心级的交换网络实现机架间的数据通信和资源调度。这种架构的关键在于两个层级之间的“网关”如何设计。网关需要实现PCIe协议与上层网络协议如RoCEv2/RDMA over Converged Ethernet 或 InfiniBand的高效转换同时管理好地址映射和资源发现。4.2 核心使能技术PCIe Switching与NVMe-oFPCIe交换芯片PCIe Switch 这是扩展PCIe拓扑的核心硬件。现代PCIe交换芯片支持多达数十甚至上百个端口可以配置为多种拓扑结构如胖树、网状。它们不仅负责数据包的路由还集成了高级功能如非透明桥接NTB允许两个独立的主机系统通过一个共享的PCIe交换结构进行通信同时保持各自地址空间的隔离和安全。这是实现多主机共享I/O的基础。多根I/O虚拟化MR-IOV是SR-IOV的扩展允许单个物理PCIe设备如网卡、GPU将其资源虚拟化并分配给多个位于不同根复合体Root Complex 即不同主机上的虚拟机VM直接使用实现硬件级的高效共享。NVMe over Fabrics (NVMe-oF) 这是推动PCIe机架互连落地的关键软件协议栈。NVMe-oF定义了如何通过网络Fabrics访问远程的NVMe SSD。虽然它最初支持以太网、InfiniBand等作为传输层但NVMe-oF over PCIe是一个天然且高效的选择。通过PCIe交换网络主机可以像访问本地NVMe SSD一样以极低的延迟访问机架内其他节点上的NVMe存储资源构建高性能的共享存储池。这避免了传统网络存储如iSCSI的协议开销是构建分解式存储Disaggregated Storage架构的理想技术。光互连与电缆技术 要将PCIe信号可靠地传输到机架尺度通常可达几米到十几米需要借助先进的电缆技术。有源光缆AOC和直连铜缆DAC是两种主流方案。对于更长距离如机架顶部到底部AOC在功耗和信号质量上更有优势。PCIe标准组织也在持续推动CXLCompute Express Link等新一代互连协议它在兼容PCIe的基础上增加了缓存一致性支持旨在更高效地连接CPU、内存和加速器这进一步强化了PCIe生态在异构计算中的核心地位。4.3 实操考量系统集成与软件栈在实际部署中除了硬件软件栈至关重要。资源发现与管理需要一个机架级的资源管理器来发现所有通过PCIe Fabric连接的设备GPU、SSD、智能网卡等并将其作为可池化的资源提供给上层应用或云管理平台如OpenStack, Kubernetes。设备虚拟化与分配通过MR-IOV和NTB配合Hypervisor或容器运行时可以将一个物理GPU灵活地分配给机架内不同服务器上的多个虚拟机或容器使用实现资源的秒级弹性分配和回收。故障隔离与高可用PCIe Fabric需要具备链路冗余和故障切换能力。当某个交换芯片或链路出现故障时系统应能自动重新路由保证服务的连续性。这需要在硬件交换拓扑和软件驱动层面共同设计。5. 挑战、现状与未来展望尽管前景广阔但PCIe作为机架级互连的普及仍面临一些挑战同时生态也在快速发展。5.1 当前面临的主要挑战生态成熟度虽然PCIe设备生态庞大但机架级PCIe交换和管理的整体解决方案生态相比成熟的以太网交换机市场仍处于早期阶段。可供选择的品牌、型号以及相关的网络管理、监控、诊断工具链还不够丰富。标准化与互操作性如何将多个供应商的PCIe交换芯片、重定时器、电缆以及不同服务器厂商的机架集成在一起并确保稳定工作需要更完善的系统级标准和互操作性认证。CXL协议的出现正在加速这一进程。软件栈复杂度实现跨主机的PCIe资源共享对操作系统内核、设备驱动、虚拟化层和集群管理软件都提出了新的要求。开发、调试和运维这套软件栈的复杂度高于传统的以太网网络。5.2 行业实践与发展动态正如原文评论中提到的早在2013年像Facebook这样的超大规模数据中心运营商就已经开始探索PCIe在机架内的应用。如今这已成为一个明确的趋势。超大规模云厂商Google、Microsoft Azure等都在其定制化服务器设计中广泛采用PCIe Switch来连接机箱内的多个计算模块和加速器实现资源池化。存储领域NVMe-oF over PCIe是构建超低延迟共享存储阵列如AFA和分解式存储的核心技术。许多全闪存存储厂商在其机箱背板中内置了PCIe交换网络。人工智能与高性能计算在AI训练集群中需要将成千上万的GPU高速互联。NVIDIA的NVLink技术本质上是其私有的、增强版的类PCIe互连。而在更开放的领域基于PCIe/CXL的异构计算平台正在兴起旨在更高效地连接CPU、GPU、FPGA和专用AI芯片。硅光Silicon Photonics互连正如评论中提及的Intel硅光技术光互连是突破电互连距离和带宽密度瓶颈的必然方向。将PCIe/CXL协议运行在硅光引擎上可以实现更长距离机房级、更低功耗、更高带宽的机架间甚至数据中心级互连模糊“机架内”与“机架间”的界限。5.3 给架构师与开发者的建议如果你正在设计新一代的数据中心硬件或规划资源池化方案以下是一些实操建议场景驱动选型不要为了技术而技术。首先明确你的工作负载特征。如果应用对延迟极其敏感微秒级且需要紧密共享硬件加速器或存储那么优先评估基于PCIe/CXL的机架内互连方案。如果应用是传统的分布式计算通信模式松散那么成熟的以太网可能仍是更稳妥的选择。关注CXL的演进CXL建立在PCIe物理层和电气层之上增加了缓存一致性内存语义。它正在迅速获得产业支持。在规划新系统时尤其是涉及内存池化Memory Pooling和异构计算时必须将CXL纳入考量。选择支持CXL的CPU、交换芯片和加速器能为未来留下更大的灵活性。从小规模概念验证PoC开始可以从一个简单的双节点共享一块NVMe SSD或GPU的PoC开始。使用支持NTB的PCIe交换板卡或设备尝试配置Linux下的多主机共享。这能帮助你快速理解软件栈的配置复杂度和实际能达到的性能收益。评估总拥有成本TCO不仅要计算硬件采购成本还要评估因性能提升带来的业务收益如更快的模型训练缩短产品上市时间、因功耗降低带来的电费和冷却成本节约以及因架构简化可能减少的运维成本。我个人在实际的异构计算平台设计中的体会是互连技术的选择没有银弹只有最适合特定场景的权衡。PCIe在机架内的崛起并不是要取代以太网或InfiniBand而是让互连技术栈变得更加层次化和专业化。它迫使我们去更精细地思考数据流动的路径将“远距通信”和“近距协作”区别对待从而在整体上构建出更高性能、更高效、更灵活的数据中心基础设施。这场始于机箱内部的变革正在重新定义数据中心资源池化的边界。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2607234.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

SpringBoot-17-MyBatis动态SQL标签之常用标签

文章目录 1 代码1.1 实体User.java1.2 接口UserMapper.java1.3 映射UserMapper.xml1.3.1 标签if1.3.2 标签if和where1.3.3 标签choose和when和otherwise1.4 UserController.java2 常用动态SQL标签2.1 标签set2.1.1 UserMapper.java2.1.2 UserMapper.xml2.1.3 UserController.ja…

wordpress后台更新后 前端没变化的解决方法

使用siteground主机的wordpress网站,会出现更新了网站内容和修改了php模板文件、js文件、css文件、图片文件后,网站没有变化的情况。 不熟悉siteground主机的新手,遇到这个问题,就很抓狂,明明是哪都没操作错误&#x…

网络编程(Modbus进阶)

思维导图 Modbus RTU(先学一点理论) 概念 Modbus RTU 是工业自动化领域 最广泛应用的串行通信协议,由 Modicon 公司(现施耐德电气)于 1979 年推出。它以 高效率、强健性、易实现的特点成为工业控制系统的通信标准。 包…

UE5 学习系列(二)用户操作界面及介绍

这篇博客是 UE5 学习系列博客的第二篇,在第一篇的基础上展开这篇内容。博客参考的 B 站视频资料和第一篇的链接如下: 【Note】:如果你已经完成安装等操作,可以只执行第一篇博客中 2. 新建一个空白游戏项目 章节操作,重…

IDEA运行Tomcat出现乱码问题解决汇总

最近正值期末周,有很多同学在写期末Java web作业时,运行tomcat出现乱码问题,经过多次解决与研究,我做了如下整理: 原因: IDEA本身编码与tomcat的编码与Windows编码不同导致,Windows 系统控制台…

利用最小二乘法找圆心和半径

#include <iostream> #include <vector> #include <cmath> #include <Eigen/Dense> // 需安装Eigen库用于矩阵运算 // 定义点结构 struct Point { double x, y; Point(double x_, double y_) : x(x_), y(y_) {} }; // 最小二乘法求圆心和半径 …

使用docker在3台服务器上搭建基于redis 6.x的一主两从三台均是哨兵模式

一、环境及版本说明 如果服务器已经安装了docker,则忽略此步骤,如果没有安装,则可以按照一下方式安装: 1. 在线安装(有互联网环境): 请看我这篇文章 传送阵>> 点我查看 2. 离线安装(内网环境):请看我这篇文章 传送阵>> 点我查看 说明&#xff1a;假设每台服务器已…

XML Group端口详解

在XML数据映射过程中&#xff0c;经常需要对数据进行分组聚合操作。例如&#xff0c;当处理包含多个物料明细的XML文件时&#xff0c;可能需要将相同物料号的明细归为一组&#xff0c;或对相同物料号的数量进行求和计算。传统实现方式通常需要编写脚本代码&#xff0c;增加了开…

LBE-LEX系列工业语音播放器|预警播报器|喇叭蜂鸣器的上位机配置操作说明

LBE-LEX系列工业语音播放器|预警播报器|喇叭蜂鸣器专为工业环境精心打造&#xff0c;完美适配AGV和无人叉车。同时&#xff0c;集成以太网与语音合成技术&#xff0c;为各类高级系统&#xff08;如MES、调度系统、库位管理、立库等&#xff09;提供高效便捷的语音交互体验。 L…

(LeetCode 每日一题) 3442. 奇偶频次间的最大差值 I (哈希、字符串)

题目&#xff1a;3442. 奇偶频次间的最大差值 I 思路 &#xff1a;哈希&#xff0c;时间复杂度0(n)。 用哈希表来记录每个字符串中字符的分布情况&#xff0c;哈希表这里用数组即可实现。 C版本&#xff1a; class Solution { public:int maxDifference(string s) {int a[26]…

【大模型RAG】拍照搜题技术架构速览:三层管道、两级检索、兜底大模型

摘要 拍照搜题系统采用“三层管道&#xff08;多模态 OCR → 语义检索 → 答案渲染&#xff09;、两级检索&#xff08;倒排 BM25 向量 HNSW&#xff09;并以大语言模型兜底”的整体框架&#xff1a; 多模态 OCR 层 将题目图片经过超分、去噪、倾斜校正后&#xff0c;分别用…

【Axure高保真原型】引导弹窗

今天和大家中分享引导弹窗的原型模板&#xff0c;载入页面后&#xff0c;会显示引导弹窗&#xff0c;适用于引导用户使用页面&#xff0c;点击完成后&#xff0c;会显示下一个引导弹窗&#xff0c;直至最后一个引导弹窗完成后进入首页。具体效果可以点击下方视频观看或打开下方…

接口测试中缓存处理策略

在接口测试中&#xff0c;缓存处理策略是一个关键环节&#xff0c;直接影响测试结果的准确性和可靠性。合理的缓存处理策略能够确保测试环境的一致性&#xff0c;避免因缓存数据导致的测试偏差。以下是接口测试中常见的缓存处理策略及其详细说明&#xff1a; 一、缓存处理的核…

龙虎榜——20250610

上证指数放量收阴线&#xff0c;个股多数下跌&#xff0c;盘中受消息影响大幅波动。 深证指数放量收阴线形成顶分型&#xff0c;指数短线有调整的需求&#xff0c;大概需要一两天。 2025年6月10日龙虎榜行业方向分析 1. 金融科技 代表标的&#xff1a;御银股份、雄帝科技 驱动…

观成科技:隐蔽隧道工具Ligolo-ng加密流量分析

1.工具介绍 Ligolo-ng是一款由go编写的高效隧道工具&#xff0c;该工具基于TUN接口实现其功能&#xff0c;利用反向TCP/TLS连接建立一条隐蔽的通信信道&#xff0c;支持使用Let’s Encrypt自动生成证书。Ligolo-ng的通信隐蔽性体现在其支持多种连接方式&#xff0c;适应复杂网…

铭豹扩展坞 USB转网口 突然无法识别解决方法

当 USB 转网口扩展坞在一台笔记本上无法识别,但在其他电脑上正常工作时,问题通常出在笔记本自身或其与扩展坞的兼容性上。以下是系统化的定位思路和排查步骤,帮助你快速找到故障原因: 背景: 一个M-pard(铭豹)扩展坞的网卡突然无法识别了,扩展出来的三个USB接口正常。…

未来机器人的大脑:如何用神经网络模拟器实现更智能的决策?

编辑&#xff1a;陈萍萍的公主一点人工一点智能 未来机器人的大脑&#xff1a;如何用神经网络模拟器实现更智能的决策&#xff1f;RWM通过双自回归机制有效解决了复合误差、部分可观测性和随机动力学等关键挑战&#xff0c;在不依赖领域特定归纳偏见的条件下实现了卓越的预测准…

Linux应用开发之网络套接字编程(实例篇)

服务端与客户端单连接 服务端代码 #include <sys/socket.h> #include <sys/types.h> #include <netinet/in.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <arpa/inet.h> #include <pthread.h> …

华为云AI开发平台ModelArts

华为云ModelArts&#xff1a;重塑AI开发流程的“智能引擎”与“创新加速器”&#xff01; 在人工智能浪潮席卷全球的2025年&#xff0c;企业拥抱AI的意愿空前高涨&#xff0c;但技术门槛高、流程复杂、资源投入巨大的现实&#xff0c;却让许多创新构想止步于实验室。数据科学家…

深度学习在微纳光子学中的应用

深度学习在微纳光子学中的主要应用方向 深度学习与微纳光子学的结合主要集中在以下几个方向&#xff1a; 逆向设计 通过神经网络快速预测微纳结构的光学响应&#xff0c;替代传统耗时的数值模拟方法。例如设计超表面、光子晶体等结构。 特征提取与优化 从复杂的光学数据中自…