在一个站点中，我们有带有 2 个 10G NIC 的 vSphere 主机。
- 两个 NIC 均位于一个 vSwitch 中
- 静态 LAG 的故障转移策略 IP 哈希（用于平衡/故障转移 VM 流量）
- 两个 NIC（HPE 534FLR-SFP+/QLogic 57810）均启用了硬件 iSCSI 启动器
- 每个启动器都与一个 vmkernel 端口一一绑定。
- 一个 iSCSI 子网
- 两个 HBA 均可访问交换机堆栈中的所有 SAN 目标
交换机是思科 C3850 系列，MPIO 运行良好——经过测试（路径级别的故障转移等...）。
几天前，我们在另一个站点部署了类似的配置。相同的 vSphere 配置，相同的 NIC。但是这次此配置无法正常工作。
启动器只能访问同一交换机（该启动器所连接的）端口中的目标，而不能访问另一交换机的端口中的目标。
使用 tcpdump，我可以看到 vmkernel 端口对所有目标进行发现（根据文档，由 vSphere 完成），静态发现目标确实出现（SAN 看到它已被戳破），但是从未创建路径，并且 esxcli 显示另一台交换机中的目标的 0x0004 错误（传输错误？）。这很难调查，因为我们无法直接看到 HBA 流量。但是软件 iSCSI 工作得很好（绑定到相同的 vmkernel 端口）。
这次的交换机是 Cisco Nexus（我会在了解型号后更新），堆叠是 VCP（？）而不是 C3850 原生（？）。其他网站基本相同，但恕我直言，差异很小，不会造成影响。仅指出几点：
- HPE Proliant Gen9 与 Gen10
- vSphere 6.5 与 6.7 - 由于我们的备份现在支持 6.7，我们将很快更新旧网站。
我搜索了 VMware 文档，没有发现任何内容表明融合网络不应该起作用。我们咨询了我们的网络合作伙伴，但他们不了解它目前的工作方式，并认为它根本不应该起作用。
这个配置正常吗？还是我们依赖 C3850 的某些实现怪癖，而其他交换机无法实现？或者交换机明显存在问题？
答案1
回答我自己的问题...不建议/不支持（“不应该”、“禁忌” - 措辞不当）使用 LAG 进行端口绑定：
LACP 支持与软件 iSCSI 多路径不兼容。iSCSI 多路径不应与普通静态以太通道或 LACP 绑定一起使用。
当 ESXi 主机上行链路到 pSwitch 上使用 LACP 或其他链路聚合时，软件 iSCSI 端口绑定也是禁忌的
显然，Catalyst 3850 Stackwise 的工作方式与 Nexus Virtual Port Channel 非常不同（它确实有效……）。在正常情况下，流量从不跨越交换机间通道，因此硬件 iSCSI 永远不会从其他交换机的 SAN 端口取回其数据包。解决方案是在 vSwitch 中切换回基于端口 ID 的平衡并禁用 LAG。流量平衡对于 10G 来说并不那么重要（IP 哈希有助于解决容易过载的 1G 链路）。
Google 有一些未经证实的薄弱说法，称 VCP 需要 LACP 才能正常工作。我们在 Switch --> vSphere 连接中丢失了一些数据包，当我们禁用 LAG 并切换回端口 ID 平衡时，这些数据包就消失了。我知道 vSwitch 会丢弃来自错误上行链路的流量（如果 VM 被哈希化到 vmnic0，但流量从 vmnic1 返回，则会被丢弃），但我不确定它是否适用于 IP 哈希平衡。另一方面，文档指出交换机端仅支持 IP-SRC-DST。如果 VPC 通过交换机本地接口而不是正确的基于 IP 哈希的接口将流量发送到 vSphere，则可能被视为“错误”上行链路并被丢弃。同样，禁用 LAG 可以正常工作。