同城双活容灾体系中，SAN网络配置，应该采用哪种方案？

SAN交换机用了Trunking模式，有一个原则是跨数据中心级联路径距离要一致，方案一、方案二都不对，同一交换机出来的路径距离都不一致，因此，按照这种原则，将方案二DWDM1间的运营商都改成联通/电信，DWDM2间的运营商都改成电信/联通，这样SAN-A间的两条级联路径距离一致，SAN-B间的两条级联路径距离一致。

既然每对dwdm之间都是联通电信双线，那我个人就更倾向方案二，结构简单便于维护和问题排查。
楼上说的方案一的生产机房san-a和灾备机房san-b同时故障不影响数据传输，这必须在图中四台交换机全部做级联的前提下。但是一般都是两两级联，四台做级联的话风险太大。

咨询了一下dwdm厂商，建议改良方案一。
建议如下：dwdm1对之间使用电信线路，dwdm2对之间使用联通线路，san-a对做级联，san-b对做级联。
总结：不计成本可以直接上方案二，综合考虑成本的话可以使用改良后的方案一。

第一种方案：

H1当中的SAN-A与H2当中的哪个设备做级联？
如果与H2当中的SAN-A级联，那么与SAN-B的这条链路有什么意义？ZONE的划分总不能同一个WWN既通过H2-SAN-A的端口映射过来，又通过H2-SAN-B的端口映射过来吧。SAN的架构跟以太网的架构还是有区别的，所以个人认为第一种架构有些问题。

第二种方案：

这种方案从技术上来讲，没有问题。但是从线路的选择上来讲，还是要根据实际情况调整一下顺序。

从实践来说，两种方案都需要优化和调整。
1.两机房之间通过dwdm进行互联，建议单路dwdm使用单一运营商线路，将电信和联通分别集中在一套dwdm上。
观点：总体带宽一样，线路更加简洁明了，单一运营商线路故障的影响降低，必要时候可以实现快速隔离。双活和实时容灾怕抖不怕断，如果每条trunking都是双运营商，看似冗余，实则增加了故障点，更容易对数据传输造成影响。以下的个人观点都是基于运营商线路调整完成后的。
2.第一种方案：理论上可行，实际上可操作性很低，运维难度超大，单点故障对全网造成影响，产生“抖动”的可能性最高，强烈不推荐，目前应该没有人使用。
3.刚才看到有朋友说了第一种方案的改进方案：存在可操作性，运维难度较第一种方案有所降低，但是依旧存在一些问题。双活和实时容灾的磁盘，对应关系一般为一对一，偶尔出现二（生产盘）对一（灾备盘），磁盘对应关系固定的，磁盘端口也是固定的。如果中间出现链路故障或者交换机单点故障，如何去实现理论上的冗余切换？修改端口映射关系么？（由于个人经验有限，目前也只能想到这个办法）可能端口映射还没改，这边链路已经恢复.........
➡️第一种方法（含改进）总结：看似实现了冗余架构，实则单点故障仍会对全网有所影响，对故障点隔离也会存在操作上的困难，同时也存在网络架构复杂，产生慢速设备后排查困难的情况。
4.第二种方案：从最基本的架构上来看，运维难度降低，网络简单、明了；每个点都可以在发生故障后迅速隔离，减少网络抖动对磁盘传输的影响；出现慢速设备排查难度降低，网络安全性和可靠性较高。

个人认为，在同城双活或者实时备份网络上，单条链路都应该能承载全部的传输流量。也就是说，平时的单条链路传输流量不能超过50%，这样才能在出现问题的时候，不影响生产，不会造成网络拥塞。不然，我们的双路冗余还有什么意义？

综上，个人推荐第二个方案（运营商线路调整后的），网络的安全性、可维护性等方面都是最适合做双活和实时容灾的。

还有一点，两家运营商的线路总长度差距不能太大，不然影响传输效率。

个人愚见，请各位多多指正！

既然是双活，从IT基础架构上看两边的设备足够冗余了，出现问题概率比运营商的链路不可控性小多了，市政施工一个大铲子下去，结果可想而知。我更关注的中间的链路稳定和冗余性，其实这两种组网方式中间链路是一样的，联通和电信，随便一个厂商的链路故障，最终的结果都是一样的。