3主机S2D集群中VM与旧SAN设备通信的VLAN配置咨询

嘿，我来帮你捋捋这个配置思路，刚好之前在非生产环境里处理过类似的旧SAN复用场景～

首先得明确你的核心诉求：让S2D集群上的VM能访问VLAN50里的SAN目标，而且暂时没法给SAN配专用交换机，得复用现有核心和SAN交换机的链路，对吧？下面是具体的配置步骤和注意事项：

• 上联链路的端口配置

  • 核心交换机侧：把连接SAN交换机的端口配置为Trunk模式，并且明确允许VLAN50的流量通过。毕竟核心交换机肯定承载着S2D集群的管理、VM业务等其他VLAN，Trunk模式能同时透传这些既有VLAN和SAN的VLAN50流量，不用单独占端口。
  • SAN交换机侧：对应连接核心的那个端口，要配置成支持VLAN50的Tagged流量。因为你的SAN目标设备是接在SAN交换机的Untagged VLAN50端口上的，所以上联端口只需要接收来自核心的带VLAN50标签的流量，然后转发给SAN目标时自动去掉标签（SAN交换机本身会处理VLAN的转换）。如果你的旧SAN交换机不支持Trunk模式，那可以用Hybrid模式替代，只要确保这个上联端口允许VLAN50的Tagged流量通行就行。

• S2D集群与VM的配置调整

  • 给VM的虚拟网络配置VLAN50权限：如果是Hyper-V环境，你可以在VM的网络适配器设置里直接指定VLAN ID为50，或者在对应的虚拟交换机端口组里配置允许VLAN50。要是用了S2D的逻辑网络，记得把VLAN50添加到逻辑网络的定义中，确保集群能正确识别这个VLAN。
  • 端到端Jumbo Frames必须一致：既然SAN侧已经开了 jumbo frames（一般是9000字节MTU），那核心交换机的Trunk端口、S2D集群的物理网卡、VM的虚拟网卡，都要把MTU设置成9000。要是中间某段MTU不匹配，轻则存储性能暴跌，重则直接连不上。

• 验证流程（按顺序来，排障更高效）

  1. 先在核心交换机上ping SAN目标的IP（比如iSCSI目标的IP），确认核心能和SAN设备通。
  2. 接着在S2D集群的任意节点上，用集群节点的VLAN50接口去ping SAN目标，验证集群节点层面的连通性。
  3. 最后在VM里ping SAN目标，再测试存储挂载（比如iSCSI发起端连接目标），确认读写正常。

额外提个小提醒：因为这是非关键存储，复用核心链路没问题，但平时要多盯着点这个链路的带宽占用，别让SAN的备份或者大文件传输拖慢了S2D集群的生产业务流量。要是你的SAN交换机实在太老，连Trunk都不支持，那还有个临时折中方案：把核心交换机的上联端口直接设为Untagged VLAN50，不过这样这个端口就只能传SAN流量了，适合应急用。

备注：内容来源于stack exchange，提问作者Crimsonfox