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的架构跟以太网的架构还是有区别的,所以个人认为第一种架构有些问题。
第二种方案:
这种方案从技术上来讲,没有问题。但是从线路的选择上来讲,还是要根据实际情况调整一下顺序。
可靠性上
第一种方案(改良版)比第二种方案的冗余性稍高,但依旧无法解决SAN-A、
SAN-B交换机对各故障一台、数据传输中断的问题。如果想完全杜绝这个问题,就和题主的图一样,第一种方案(全级联),可靠性更高,但可管理性大幅下降,管理出问题的几率远比其他两种方案更大。
负载均衡上
第一种方案(改良版)和第一种方案(全级联)方案都能从两对DWDM走,对链路的利用率更高、压力更小,但第一种方案(全级联)的流量管理更麻烦,要做好细致的策略,也间接增加了运维成本。第二种方案也能够实现链路的负载,只是负载的实现更依赖双活软件,链路上只做好链路该做的事,取得了管理难度和性能的平衡。
管理难度
在管理难度上,第一种方案(全级联)最难,运维管理出错可能性极大,生产环境不推荐这种方案;第一种方案(改良版)管理难度合理,运维中注意规范操作,一般没啥问题。第二种方案,架构简洁,链路清晰,是不错的设计,生产上也有采用这种部署模式的。
续建难度
第一种方案的两种模式扩容都会相对复杂一些,全级联的方式扩容、配置最为复杂,实际中诸多此类
出现故障的案例也不少,随着体量的扩展,管理成本运维成本以及人为操作风险大幅提升。相对而言,改良版的方案,和第二种方案思路会清晰一些,细看之后也会发现改良版方案和第二种方案的设计思想也不谋而合,只是对链路的设计实现方式不一样,一个讲究冗余高效,另一个追求独立简化。
对于双活软件侧,如果链路架构确定了,考虑的事情就相对清晰的多。双活软件上主要的是做好策略控制,包括单点故障应对策略。因此,对于双活层,策略越清晰,越可控可管理,实际运用效果越好。最符合这一点的是第二种方案,链路做好冗余,策略依靠双活软件控制,泾渭分明。
1,如果运维人员实力足够,预算也充足,个人会推荐第一种方案的改良版,无论是可靠性还是可管理性都有不错的实现。
2,如果运维人员较少,对双活的维护倾注不了太多人力物力,第二种方案会是不错的选择,架构清晰,管理简化。
3,即使有人有钱有预算,也不推荐第一种方案(全级联)。在实际项目中,一旦进行全级联,随着体量的增长,管理和成本都是不小的问题,越大越不可控。双活容灾是DC的重要系统,一旦落地,想改架构,难上加难。
收起之前在做某银行灾备时,测试过这两种网络,使用的是IBM DS8000存储,方案一,一路DWDM中断会导致两路复制链路降级;而方案二,一路DWDM中断,只会影响一路,对应用层来说,希望看到的是链路要么是好的,要么是坏的,而不是性能下降或性能反复震荡,所以最后选择的是方案二。
收起从实践来说,两种方案都需要优化和调整。
1.两机房之间通过dwdm进行互联,建议单路dwdm使用单一运营商线路,将电信和联通分别集中在一套dwdm上。
观点:总体带宽一样,线路更加简洁明了,单一运营商线路故障的影响降低,必要时候可以实现快速隔离。双活和实时容灾怕抖不怕断,如果每条trunking都是双运营商,看似冗余,实则增加了故障点,更容易对数据传输造成影响。以下的个人观点都是基于运营商线路调整完成后的。
2.第一种方案:理论上可行,实际上可操作性很低,运维难度超大,单点故障对全网造成影响,产生“抖动”的可能性最高,强烈不推荐,目前应该没有人使用。
3.刚才看到有朋友说了第一种方案的改进方案:存在可操作性,运维难度较第一种方案有所降低,但是依旧存在一些问题。双活和实时容灾的磁盘,对应关系一般为一对一,偶尔出现二(生产盘)对一(灾备盘),磁盘对应关系固定的,磁盘端口也是固定的。如果中间出现链路故障或者交换机单点故障,如何去实现理论上的冗余切换?修改端口映射关系么?(由于个人经验有限,目前也只能想到这个办法)可能端口映射还没改,这边链路已经恢复.........
➡️第一种方法(含改进)总结:看似实现了冗余架构,实则单点故障仍会对全网有所影响,对故障点隔离也会存在操作上的困难,同时也存在网络架构复杂,产生慢速设备后排查困难的情况。
4.第二种方案:从最基本的架构上来看,运维难度降低,网络简单、明了;每个点都可以在发生故障后迅速隔离,减少网络抖动对磁盘传输的影响;出现慢速设备排查难度降低,网络安全性和可靠性较高。
个人认为,在同城双活或者实时备份网络上,单条链路都应该能承载全部的传输流量。也就是说,平时的单条链路传输流量不能超过50%,这样才能在出现问题的时候,不影响生产,不会造成网络拥塞。不然,我们的双路冗余还有什么意义?
综上,个人推荐第二个方案(运营商线路调整后的),网络的安全性、可维护性等方面都是最适合做双活和实时容灾的。
还有一点,两家运营商的线路总长度差距不能太大,不然影响传输效率。
个人愚见,请各位多多指正!
收起