网络拓扑结构优化的后果

　　前面我们曾经介绍了基准测试的概念。基准测试会给出一个正常工作的网络的各个链路和通道的流量规律和时间特征，比如一个税务征管系统，每月的10号左右就是纳税数据流量的最高峰，其余时间均在高峰期流量的50%以下。依据这些规律和特征，网管人员可以了解网络的变化规律，以此预估网络流量的变化趋势，为升级网络设备和网上设备收集准确数据，也可为新的网络应用提供安装依据，还可以为网络成员的数量增删、结构调整提供精确的参考数据。最重要的一点是，可以为早期发现部分严重的网络问题提供诊断依据，从而避免造成不必要的严重损失。

　　由于局域网中的网络拓扑结构是相对稳定的，一般不会每天都去改动，这一点与路由节点的动态变化是不同的，因为路由器会根据选用的路由协议、网络互联的流量状况、网络设备及信道的工作质量动态地改变路由表和路由通道的实际方向。这种调整经常是依据选用的路由协议和设定的条件自动进行的。而局域网内由交换机构成的网络路径通常没有这样大的灵活性，一个原因是它们的功能主要还是用来提供低延迟的数据传输的快速通道，虽然建立局域网内的动态链路带宽分配一直是交换机试图完成的主要功能。另一个原因就是设备成本，如果所有交换机都具备带宽组合分配、交换节点选择和流量均衡的功能，那么整个网络的成本将会上升许多。第三个原因是虽然已经提出了不少带宽组合分配的协议，但还没有一个功能完备和完全标准的协议能实现这些功能。目前我们常用网管系统监测、设置端口Trunk、启动STP/HSRP协议、启动端口保护功能等初级手段来应付网络流量的变化、交换节点中断和异常流量的冲击。

　　最初在进行交换机、路由器的设计时为了降低成本，其设计体系中一般没有像传统的通信传输产品那样设计独立的管理通道，而是利用承载数据业务的通道兼作管理通道来传递网络管理和监测信息。这种体系的缺点很明显：一旦业务通道出现堵塞或中断，管理信息的获取通道也会随之中断，网管系统用来判断故障准确位置和程度的有效性及其真实性将大打折扣。遗憾的是这种状况在现在所谓的高档交换机中仍然没有改观。“网管网”的概念始终没有随着设备成本的大幅下降而得以实现，所以，高效的网络拓扑结构优化和流量均衡的问题没有顺利进入实用阶段。网管员们面临的仍然是需要人工参与网络状态的检测和网络拓扑结构的调整。由于获取的信息有限，即时性不高，加之没有很好的优化原则和算法，所以目前采用的方法主要是根据高峰期的发生时间和持续时间作为人工分析和调整拓扑结构的依据。

　　典型案例

　　这是一个拥有500台左右机器的公司办公和业务混合网，网络规模属于中等。网络中有三个路由器与其他异地制造部门实现广域连接，一台路由器与公网相连。本地有约300台机器，用三台核心交换机依线型结构构成三组楼群的用户本地网。分别是楼群A、楼群B和楼群C。楼群A居线型结构的中间，并设有信息中心和网管中心。三台核心业务服务器和与异地部门连接的路由器以及公网路由器都安装在此。楼群B和楼群C内分别安装有多台部门级服务器，服务器的内容管理由各部门负责，维护和故障诊断则由信息中心负责。各楼群下设工作组交换机和桌面交换机组成三级交换局域网，与各部分的终端用户相连，网管中心负责全面的网络规划和管理维护。终端用户基本上用的是台式机，少数用户使用笔记本电脑。

　　本示例所讲述的故障发生在位于A楼群中的几个部门之间。

　　公司办公网和业务网没有分离，共同使用以前设计的以五类线铺设的以太网。原来安装的生产、采购、物料、库存、财务等软件模块已经使用近一年，效果还不错。最近两周新增加了销售软件模块，在软件单独调试时感觉软件表现也不错，决定正式切换到网络化的销售平台上来。销售部人员已经全部经过培训，在平台切换并接入的那天，全体销售人员扔掉了手工记录，做好了准备，以便正式进入网络化销售流程重组的实施进程。那天网络启动后一开始还正常，不久就出现问题，并网联调时销售模块的工作速度很慢，并且影响到财务模块、采购模块的工作速度，三个模块好像不能同时协调快速工作。

　　显然，新安装的销售模块有问题，它运行时速度比较慢，同时似乎也会影响采购模块、财务模块的正常工作。为了验证是否是服务器或软件本身的问题，调试时软件安装人员建议暂时停止公司各项业务两小时，重新检查了服务器和各种流程响应，没有发现明显的问题征兆。只好备份数据，重新安装服务器和软件模块。按先后顺序分别将销售模块、采购模块、财务结算模块安装并启动入网调试，观察各工作站和服务器的工作状态，一切正常。两小时后调试程序结束，一切过程均显示软件工作正常，遂决定重新启动整个系统进入日常工作状态。在开始后的前20分钟看起来还算不错，大家不由得都松了一口气。但20分钟后销售部首先报告业务响应又出现问题，速度变慢。几乎同时采购部和财务部也报告速度变慢。调试人员观察到速度降低的同时网络响应的速度也有所下降，不如先前Ping服务器响应均在1ms以内，此时部分Ping响应变成2ms～18ms，100组Ping测试丢失率在约30%左右，不知是何种原因。

　　为什么单个模块调试都没有问题而全部模块工作起来以后就会出现问题？临近中午十分，正在大家疑惑不解之际，销售部报告软件工作速度恢复正常，不久财务部和采购部也报告业务流程恢复正常速度。虽然不知道具体原因，但业务能恢复正常工作总是件好事，折腾了一上午，也该补充点能量了。大家随即变得“欢欣鼓舞起来”，纷纷结伴向附近的餐馆走去。

　　软件调试工程师心里一直在打鼓，午休时间他一个人又对服务器和工作站的软件设置进行了一番仔细检查，确认没有任何问题，随后将所有相关的服务器和工作站进行了重启。要知道，这套软件他已经成功安装近百套了，从来没有出现过处理不了的问题，对此他一直是信心十足的。上午虽然软件工作后期趋于正常，但由于没有最终查明引起故障的原因，此时心中只好暗暗“祈祷”了，希望将此好景保持下去——因为在以前的软件调试安装过程也遇到过类似的问题。然而好景实在不长，下午工作时间开始后约半个小时，故障又重新出现，症状跟上午的一模一样。

　　即刻重新投入战斗，经过半个小时的检查仍然未能查出原因所在。最后，他只得建议备份数据，格式化业务服务器，重新安装平台和业务软件，以便彻底排除是否是软件或服务器的问题。在场的人都知道，这也是不得已而为之的办法。为了不至于严重影响该公司的业务，计划把重装系统的时间安排在17:30以后。没有预料到的是，在下午的工作时段内，业务流程的速度又出现了两次波动，每次速度恢复正常的时间在20～30分钟左右。其中表现比较一致的是，故障发生时做Ping测试的丢失率基本上维持在30%～40%左右。

　　17:30公司下班，留下部分相关人员配合做业务流量仿真。如果有备份的服务器，也许可以先替换一下试一试。但目前手里只有备用的几块网卡，软件工程师首先试着更换了服务器的网卡，重新启动服务器，观察业务流程响应。结果，一切表现正常。软件已经检查过多次，此时不再作为重点检查对象。持续观察连续Ping的测试结果，100%响应在1ms以内。一直到晚上23:00，人困马乏，原先的故障现象仍然未出现，怀着忐忑不安的心情收工回营。期待着明天以及今后故障现象都不要再重现，弄不好就正好是网卡的问题也未必呢。

　　读者一定想象得到第二天发生的事情。

　　是的，第二天早上上班后约20分钟，销售部首先报告问题出现，接着财务部和采购部报告速度变慢，一切有如昨天的表现一模一样——看起来故障有一定的周期性或时间性！会不会是病毒或黑客软件在捣乱作怪？好吧，先杀杀毒看看。搬来了几个杀毒软件，花了一上午时间把所有的服务器和工作站都查杀了一遍病毒，结果一无所获，网络倒是出奇的干净。是不是感染了新病毒？杀毒软件不起作用了？好吧，上网下载升级软件，重新进行查杀病毒操作，一直折腾到下班时间，网络又恢复了正常。这下没辙了，该做的和能做的都做了，剩下的就只有听天由命碰运气了。可问题不解决，运气恐怕是好不起来了。

　　故障排除

　　我们接到报告是在软件开始运行第三天的上午，焦头烂额的软件安装调试工程师乔先生向我们描述了他这3天“炼狱”般的生活。我们随即同他一起赶到“工地”。此时业务软件正处在正常“周期”，工作状况良好。从乔先生介绍的情况看，我们分析问题出在网络而不是软件，出现在服务器或工作站的可能性要大得多。用网络综合分析仪“OptiView”接入网络作自动搜索，结果显示一切正常。查看各个服务器的端口工作状态和网络中各交换链路的端口状态，显示正常。约10分钟后，故障现象出现，Ping测试丢失率确实在35%左右。为了查清丢失的位置，我们先用“网络听诊器”软件NI画了一份拓扑图。同时使用“Trace Switch Route“功能查找交换节点的路由图，对比正常工作状态时NI画出的拓扑图和故障时使用“Trace Switch Route”功能查出的交换节点图，发现两个节点路径完全不同。这说明，故障时的交换节点路径发生了变化。要求暂停业务30分钟，用OptiView的流量生成功能对该交换节点路径做通道性能检查，结果发现，流量增加到20%的时候通道突然改变路径，依据路径提示，我们找到了改变了路径的交换机，观察其端口在流量递增的过程中是如何”切换“路径的。用Telnet命令登录第一个切换位置的交换机相关端口，发现其配置的端口保护流量的阀值为20%，被切换后连通的另一台交换机其对应的通道被设置成自适应状态。用OptiView自带的移动网管查看故障时此通道的工作状态，显示为全双工10Mbps状态，而正常时根据设计应该是全双工100Mbps状态。

　　我们重新检查了此交换机级联通道的跳线，发现其跳线有误(使用了一根串扰线作跳线)，由于跳线是直接连接到交换机级联口上的，所以自适应的结果就是全双工10Mbps状态。更换跳线，重新进入正式业务状态，连续实时监测交换机的端口的工作状态，结果发现当平均流量超过20%时交换机按原定设置启动路径保护性切换。由于切换后的链路不再是以前因为用错跳线时的10Mbps状态，用OptiView观察实际状态是100Mbps全双工，所以对访问流量的10Mbps瓶颈限制取消。超过20%流量的业务数据流仍然可以顺利通过切换路径后的交换机通道顺利访问服务器的资源，而且带宽基本不受影响(响应时间会稍微延长一点—测试结果增加约150us)。

　　由于该交换机设置的流量保护阀值设置较低，目前也看不出这样设置通道流量保护有何意义，所以我们建议他们取消该设置(乔先生也不知道是谁配置的交换机以及为什么要这样配置)。由于财务模块、销售模块、采购模块的流量均通过此交换机，所以三个部门同时有多项操作执行时流量有可能超过原来的20%从而引发保护动作。这中间因为流量已经受到限制，被保护的端口在一段时间后会试着重新打开，业务流量又会以为打开时流量正好没有超过20%的阀值，致使短时内业务能恢复正常。午饭前的业务流量和下班后仿真流量均达不到20%，不能引发保护动作，所以等了一夜故障也不会出现。