整个环境并不复杂，但其中有几个细节，如果线缆、Lane 配置或者供电选错，系统很可能只能看到一路，甚至完全认不到盘。

一、先弄明白：Dual Port SSD 到底是什么？

普通 U.2 NVMe SSD 最常见的连接方式是：

PCIe x4。

也就是说，一块 SSD 通过 4 条 PCIe Lane 与 Host 连接：

Host → PCIe x4 → SSD

Dual-Port SSD 则不同。

同样是 4 条 PCIe Lane，它可以拆成两组：

Port A：PCIe x2Port B：PCIe x2

因此通常写成：

2×2

或者：

Dual Port x2 + x2

这两条 PCIe 路径最终进入的是同一块物理 SSD，并不是两块 SSD。

Dual Port 真正的价值主要出现在企业级存储、高可用存储系统和双控制器架构中。

正常情况下，可以让两个 Host 或者两个 Storage Controller 同时连接同一块 SSD。当其中一条路径、一个控制器甚至一台 Host 发生故障以后，另一条路径仍然有机会继续访问这块盘，从而降低单点故障带来的影响。

我们演示使用的 Intel DC D3700/D3600 就是比较典型的早期 Dual-Port NVMe SSD。

Intel 当年把 D3700 和 D3600 定义为其首批 Dual-Port PCIe SSD，采用 Active/Active 双端口设计，面向要求高可用和故障切换的数据中心场景。两条链路实际上就是 PCIe 3.0 x2 + PCIe 3.0 x2。

所以这里首先要建立一个概念：

Dual Port 不是“两块 SSD”，而是一块 SSD 通过两条相对独立的 PCIe 路径被访问。

后面我们在 Linux 里面看到“两个几乎一模一样的设备”，理解这一点就不会迷糊了。

二、第一种方案：一台普通 PC 就可以搭

我们今天演示的是最简单的一种方案。

测试平台并没有使用专门的存储服务器，而是一台开放式 PC。

整个环境大致可以画成：

AMD CPU

↓

PCIe Gen5 x16↓Serial Cables Gen5 PCIe Switch 卡 

↓

MCIO Gen5 x4 接口 

↓

MCIO x4 → U.2 SFF-8639 2×2 Cable

↓

Intel Dual-Port NVMe SSD

这样一套环境的好处是非常直观。

主板、Switch 卡、Cable 和 SSD 全部裸露在外面，工程师在做验证时换盘、换 Cable、观察 Link 状态都比较方便。

对于研发实验室来说，比把所有东西装进服务器机箱以后再排查要轻松很多。

三、第一步：从 CPU 附近的 PCIe Gen5 x16 插槽开始

这台测试 PC 使用 AMD 平台。

我们选择的是离 CPU 较近的一条 PCIe 5.0 x16 插槽，在里面插入 Serial Cables 的 PCIe Gen5 Switch Host Card。

演示中的这张卡对应 Serial Cables 的 Broadcom Atlas2 PCIe Gen5 平台，型号属于：

PCI5-AD-x16HI-48-BG5

官方规格显示，这张 Host Card 提供一个 PCIe Gen5 x16 Host 接口，并在板卡上提供 4 个 x4 MCIO 接口，Switch 采用 Broadcom Atlas II。

板卡中央可以看到 Switch 芯片区域以及散热风扇。

左侧则排列着：

4 个 MCIO Gen5 x4 接口。

这四个接口是后面扩展 NVMe SSD 最关键的地方。

值得注意的是，这张卡并不仅仅针对普通 Single-Port SSD 设计。

Serial Cables 的官方 User Manual 明确说明，MCIO 接口支持：

Single-Port U.2/U.3

以及：

Dual-Port U.2/U.3。

而且板卡本身能够识别 MCIO 端口是以 x4 方式 Link，还是以 2×2 的形式建立两条 PCIe 链路。

这正是我们搭建 Dual-Port 环境需要的能力。

四、真正容易搞错的是这根 Cable

接下来是整个环境中一个非常关键的部件：

MCIO → U.2 Cable。

从外表上看，它和普通 MCIO 转 U.2 Cable 很像。

但这里一定不能随便拿一根 Single-Port Cable。

我们使用的是：

MCIO Gen5 x4 → U.2 SFF-8639 2×2

Dual-Port Cable。

演示使用的线长大约 0.5 米。

Serial Cables 对应产品型号为：

MCIO5-4X-39U2-2X2

其中：

MCIO5：Gen5 MCIO；

4X：MCIO 侧一共 4 条 PCIe Lane；

39U2：另一端为 SFF-8639 U.2；

2X2：4 条 Lane 在 U.2 一侧被组织成两组 x2，用于 Dual-Port。

Serial Cables 官方目前仍然把这条线定义为“MCIO x4 to U.2 2x2 Cable”。

所以：

x4 Cable

和

2×2 Dual-Port Cable

虽然总 Lane 数量都是 4 条，但逻辑意义并不一样。

普通 Single-Port：

Lane 0 + Lane 1 + Lane 2 + Lane 3 → 一个 x4 Link

Dual Port：

Lane 0 + Lane 1 → Port A x2

Lane 2 + Lane 3 → Port B x2

这也是很多人在第一次搭 Dual-Port 环境时最容易踩的坑。

Cable 买错以后，即使接口能够物理插进去，也不代表 Dual-Port 能够按照预期工作。

五、这块 Intel SSD 为什么适合演示 Dual Port？

我们这里使用的是 Intel D 系列 Dual-Port SSD。

字幕里提到 D3700、D3600。

Intel 在 2016 年推出这两款产品时，把它们定位为面向高可用企业存储的 Dual-Port NVMe SSD。

它们支持 Active/Active Dual Port，并采用：

PCIe 3.0 x2 + PCIe 3.0 x2

结构。

也就是说，整块 SSD 虽然仍然占用 4 条 PCIe Lane，但是并不是一个 PCIe x4 Endpoint，而是可以通过两条 x2 路径进行访问。

这里顺便提醒一下。

演示中使用的是一张 Gen5 Switch 卡和 Gen5 Cable，但 SSD 本身属于较早的 PCIe Gen3 产品。

这完全没有问题。

PCIe 具有向下兼容能力。

最终 Link Speed 按照链路两端共同支持的最高速率协商，因此：

Gen5 Switch + Gen5 Cable + Gen3 SSD

最终 SSD 这一侧仍然只会运行在：

Gen3 x2 + Gen3 x2

而不会因为前面的 Switch 是 Gen5，就把一块 Gen3 SSD 变成 Gen5 SSD。

我们这里关注的主要是：

双端口拓扑是否正确建立。

而不是 SSD 本身的最高带宽。

六、接好以后，预期应该看到什么？

物理连接完成以后开机。

测试系统运行 Linux。

这里我们先做一个非常重要的预期判断。

既然这是一块 Dual-Port SSD，那么系统应该看到：

Path A

和

Path B

两条 PCIe 路径。

对于这块 Intel SSD 来说，两条路径最终指向的是同一块物理 SSD。

因此演示中执行：

nvme list

可以看到两个几乎完全一样的 NVMe 设备信息。

包括：

Serial Number 相同

Firmware 相同

以及其他相同的设备属性。

第一次看到这里时，很容易误以为：

“Linux 怎么突然发现了两块完全一样的 SSD？”

其实不是。

它们对应的是：

同一块物理 Dual-Port SSD 的两条访问路径。

这一点非常重要。

七、再用 lspci 往 PCIe 层看

接着执行：

lspci

这时可以看到两个 PCIe Device。

演示环境里面可以看到类似：

0D

以及：

0F

这样的两个 PCIe 设备位置。

这一步比单纯看 nvme list 更有意义。

因为它说明从 PCIe 拓扑层面看，Switch 已经和 Dual-Port SSD 成功建立了两条独立 PCIe Link。

对于 Dual-Port 测试环境而言，我们真正希望看到的是：

Port A → PCIe x2

Port B → PCIe x2

Serial Cables 这张 Atlas2 Switch 卡的官方手册里面其实还直接给出了一个类似例子：

当一块 Gen4 Dual-Port SSD 连接到 MCIO 端口以后，Switch 能够显示为：

Gen4 x2

以及：

Gen4 x2

两条链路。

也就是说，这并不是简单地把一个 x4 Link 软件上“切成两个盘”，而是在 PCIe Link 层面真正存在两条 x2 链路。

八、Linux 下面“两个路径”和“两个盘”还要再区分一下

这里值得再多讲一步。

在不同 Linux 版本以及不同 NVMe Multipath 配置下，最终看到的块设备形式可能并不完全相同。

Linux 原生 NVMe Multipath 支持把具有相同 Namespace Identifier 的多条路径整合到一个逻辑 Block Device 下面，然后由系统根据 NUMA、Round-Robin 或者 Queue Depth 等策略选择实际 I/O 路径。

所以在实验室里面，我们需要区分三个层次：

第一层：PCIe 层

看：

lspci

确认两条 PCIe Endpoint/Link 是否都起来。

第二层：NVMe Controller 层

可以进一步查看：

nvme list

以及 NVMe Controller 信息。

第三层：Multipath 层

确认操作系统是否把两条访问路径正确组织到同一个 Namespace 下面。

因此：

看到两个 PCI Device，是 Dual Port 环境建立成功的重要基础，但并不等于系统真的存在两块物理 SSD。

九、Serial Cables 这张 Switch 卡其实还能进一步看 Link 状态

视频里主要通过 Linux 命令验证。

实际上这张 Atlas2 Host Card 自己还有一套 MCU CLI。

例如官方手册提供：

showport

可以直接显示：

Upstream Port

以及各个：

Downstream Port

当前实际协商出来的：

Link Speed

和：

Link Width。

因此做 Dual-Port 验证的时候，我们除了在 Linux 里面执行 lspci，还可以直接从 Switch 一侧确认：

是不是两个 x2 Link。

它甚至支持：

ssdrst

对 MCIO 端口上的 SSD 发送 PERST#。

对于 Dual-Port 环境，还可以指定：

Channel A

或者：

Channel B

单独进行 Reset。

对于后面做：

单 Port Reset

Link Recovery

故障注入

等测试，这个功能就比较有用了。

十、一个 Switch 卡最多可以怎么接？

这张 Host Card 有：

4 个 MCIO x4 接口。

因此最简单的扩展方式就是：

每个 MCIO 口接一根：

MCIO x4 → U.2 2×2

Dual-Port Cable。

理论上就可以连接：

4 块 Dual-Port U.2 SSD。

每块盘占用：

2×2 PCIe Lane。

也就是说：

MCIO Port 0
  └─ Dual-Port SSD 1
       ├─ x2 Port A
       └─ x2 Port B

MCIO Port 1
  └─ Dual-Port SSD 2
       ├─ x2 Port A
       └─ x2 Port B

MCIO Port 2
  └─ Dual-Port SSD 3
       ├─ x2 Port A
       └─ x2 Port B

MCIO Port 3
  └─ Dual-Port SSD 4
       ├─ x2 Port A
       └─ x2 Port B

当然，也没有要求 4 个接口一定全部采用 Dual Port。

可以混合使用。

例如：

Port 0：Single-Port U.2 x4

Port 1：Dual-Port U.2 2×2

Port 2：Dual-Port U.2 2×2

Port 3：Single-Port U.2 x4

关键只是：

对应的 Cable 必须选对。

Single-Port 盘使用：

1×4 Cable

Dual-Port 盘使用：

2×2 Cable。

十一、还有一个很容易忘记的地方：供电

PCIe 链路接好了，还不代表 SSD 就能够工作。

视频里面特别提醒了这个细节。

这套 MCIO 转 U.2 的 Cable 本身需要另外解决 SSD 供电问题。

在线缆 U.2 一侧提供有电源接口，需要从开放式平台的电源模块另外引出一根 SATA Power Cable，给 SSD 提供工作电源。

因此完整连接实际上是：

PCIe Data
CPU
 │
PCIe x16
 │
Gen5 Switch
 │
MCIO x4
 │
2×2 Cable
 │
U.2 Dual-Port SSD
 │
 └──── SATA Power ──── PSU

实验室里面有时候会出现一种很典型的排错场景：

Cable 接好了；

Switch 也正常；

Linux 就是看不到盘。

最后检查半天才发现：

SSD 根本没有上电。

所以搭环境时，建议把：

PCIe 数据连接

和：

SSD 供电

作为两条独立路径分别确认。

十二、这套环境到底能测什么？

到这里，一套最基础的 Dual-Port SSD 环境其实已经建立完成了。

利用这套环境，我们至少可以进行：

Dual-Port PCIe Link 建立验证；

x2 + x2 Lane 配置验证；

PCIe 设备枚举；

NVMe Controller 枚举；

两条 Path 识别；

基本 NVMe 读写；

Single-Port Reset；

Link Down / Recovery；

以及进一步的：

NVMe Multipath 验证。

对于 SSD 研发、Firmware 调试以及 Dual-Port 基本功能验证来说，这种开放式环境最大的优势就是：

简单、直观，而且换盘和改拓扑很方便。

十三、但是要注意：这还不是真正的“双 Host 高可用环境”

这里需要特别说明一个容易产生误解的地方。

目前这个演示环境是：

一颗 CPU

通过：

同一个 PCIe Switch

连接 Dual-Port SSD 的两条路径。

因此它非常适合验证：

Dual-Port 是否能够建链

以及：

两条 PCIe Path 是否能够被系统正确识别。

但真正的数据中心 Dual-Port SSD，其最终应用往往是：

Host / Controller A
        │
      PCIe x2
        │
        SSD
        │
      PCIe x2
        │
Host / Controller B

也就是说，两条路径来自两个独立 Host 或者两个独立 Storage Controller。

Intel 当年设计 D3700/D3600 Dual Port 的核心目标，本身就是允许两个 Host 同时连接，用于 High Availability 和 Failover。

因此，如果我们真正要验证：

Host A 突然掉电

Root Complex A 宕机

整个 Controller A 消失

以后：

Host B 是否还能无缝访问 SSD

那么还需要进一步搭建真正的：

Dual Host / Dual Controller 环境。

这和今天演示的单 PC + Switch 实验环境，是两个不同层级的测试。

这一点搞清楚以后，Dual-Port SSD 的很多概念也就顺了。

十四、最后总结一下

今天这套最基础的 PCIe Dual-Port SSD 测试环境，其实可以浓缩成几个部件：

• 一台普通 PC

• 一个 PCIe Gen5 x16 插槽

• 一张 Serial Cables Broadcom Atlas2 Gen5 Switch Host Card

• 一根 MCIO Gen5 x4 → U.2 SFF-8639 2×2 Dual-Port Cable

• 一块 Dual-Port NVMe SSD

• Linux

连接完成以后，我们首先不要急着跑性能。

先确认三件事：

1. PCIe 层

是不是起来了两个：

x2 Link。

2. NVMe 层

两条 Path 是不是都能正确识别到同一块 SSD。

3. Multipath 层

操作系统是不是按照预期管理这两条路径。

如果这三层都正常，最基本的 Dual-Port 环境就算真正搭起来了。

后面无论继续做：

Failover

Reset

Path 切换

异常掉电

还是更复杂的企业级 SSD 高可用测试，都有了一个可以继续往上搭的基础。

这也是 Dual-Port 测试最容易被忽略的一点：

先不要急着测 SSD 性能，第一步永远是先把“两条路”真正搭对。

免费下载Saniffer公司白皮书

希望获得更多关于PCIe5.0&6.0, CXL, NVMe SSD, SAS/SATA, NVMe over Fabric (NVMoF), NAND,新型存储技术NVM（RRAM/ReRAM, FRAM/FeRAM, MRAM, PCM, 3D-NOR, SRAM/DRAM等） DDR5/LPDDR5以及UFS测试技术和产品，可以查看Saniffer公司2026.2.24最新更新的测试工具白皮书15.1版本，我们已经整理收录在Saniffer公众号的【白皮书】菜单中。

欢迎关注Saniffer公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。