标签：电脑网络知识,网络基础知识,计算机网络知识,http://www.quxue6.com
掌握网络设计 轻松排除网络故障(一),
其次，线性系统与具有很多混合连接的系统相比，出现系统故障的几率更低。具有许多交叉连接的系统有许多组件间交互作用的方式。在具体的交叉连接当中，那些隐性的交叉连接最可能导致系统故障难以诊断。
与线性密切相关的是系统各部分之间的结合度。结合度比较松散，线性系统出错概率就小，结合度紧密，相互影响就发生频繁而且不容易消除。
如果你停下来去想，这些特性都是在意料之中的。但是除非当你停下来并去考虑他们，否则非常容易忽视掉。粗略地说，我把大多数网络归为复杂但相对线性系统一类。（确切地说大多数网络都是树状结构，但是这里指的是设备之间简单明显的线性路径。）大多数硬件往往是相当紧密地连接在一起的，但是使用硬件的协议可能会提供松散连接。但是如果你不这样认为，也没有关系。把系统归为线性还是非线性，紧密连接还是松散连接，简单还是复杂主要还是个人判断。这些都是真正的相关归类。更重要的是能够从这个角度比较不同的网络设计而不是给一种设计归为那一类。
故障诊断
很不幸的是，当你开始故障诊断时，故障类型往往十分模糊。尽管说把所有可能都考虑到会对问题解决有所帮助，但是通常的情况是你没办法把故障归结为哪一类，直到你解决了故障为止。
人们在深入了解情况之前总是在一开始的时候就认为所有的故障都是简单故障。首先从故障的表面现象开始，然后再深入下去。在前一个DNS服务器连接故障中，你可能会从电子邮件软件所报告的DNS故障信息开始，然后开始查找DNS信息。这样你就会发现DNS服务无法实现，随之你就会发现无法连通DNS服务器。这样你就离故障的根源越来越近了。在机械系统中，顺藤摸瓜通常是一个很重要的方法。在网络中，逻辑上的顺藤摸瓜取代了它的位置。
了解不同的故障类型是有帮助的。在诊断一个简单故障时，通常的做法是采用分段解决的方法。在刚刚的例子中，主动将你的注意力转移而不是集中到症状本身可以少走很多弯路。花费时间在检查电子邮件配置文件上或查询DNS会白白浪费大量的时间。在两个或多个设备几乎同时出现故障时，故障诊断会更加困难，因为解决了一个问题并不能使系统恢复正常。因此，能够想到可能会出现多个故障并能想象出多个故障的综合症状对解决问题是很重要的。对于多个故障，当你向解决其中一个问题迈进时，你可能却在离解决另一个问题更远。通常是你排除了一个故障，系统的故障现象就变了。这也是发现多个故障的一个基本线索，尤其是在系统故障中。
www.quxue6.com
网络设计
可能导致故障的网络特性时会大有帮助。但是这个方法并不是万能的。在网络设计中，你的目标自然会首先包括避免故障，并减小故障所产生的影响，简化故障的排除。不幸的是，这两个目标是矛盾的。例如，考虑了故障影响的设计必然会使远程故障信息收集更为困难。
简单故障：
一般的建议适用于避免简单故障,采用可靠的设备，经常维护和检测设备,每天更新系统日志，通过使用几个相同的协议和选择几个相同的设备厂商来尽可能简化所用的东西。不幸的是，仅仅使用几个协议限制了你的网络功能；而标准化配置设备意味着你可能会在这些设备上花费更多的钱。并不是所有的情况下采用同一个厂商的产品都是最经济的方案。而特别的需要会浪费许多钱去购买不必要的设备。这在这些里些建议中是毫无疑问的。
多重故障和连续故障：
当然, 尽量减少简单故障是防止多重故障的基础，不管是独立故障，连续故障还是系统故障。下一步是分开以减少网络组件的互相影响。分开可以通过分开数据连接层或通过采用子网分开网络级别来实现。尽管有时候被忽视，出于安全的考虑，防火墙不应该受到限制。它们可以作为一种一般性工具来控制子网之间的数据交换。但是由于分开限制了交互，数据收集就变的更加困难了。 如果你确实划分了网络，（而且你当然应该考虑划分到最小网络单位），内建检查点是很重要的。
最简单的就是每个区内的一些你可以远程登录并安装了数据收集工具的计算机。我Network Troubleshooting Tools一书中介绍了许多有用的工具。你还可以通过配置网络设备如路由器来收集这方面的信息。如果预算允许，你还可以考据增加RMON类似的设备。当然，你应该会想到，这么做会增加网络的复杂性。比如，你可能需要重新配置路由器或者防火墙使SNMP数据能够通过，至少能到达相应的主机。
www.quxue6.com
系统故障：
由于系统故障是最难诊断的故障（而且，其后果也可能是惨重的损失），你可能需要在构建你的网络时要特别注意避免或减少这类故障。上面所说的都会有帮助。下一步就是考虑哪些系统特性可能会导致系统故障。
首先, 尽量使你的网络成为线性布局。树状结构的网络相对来说比较好。总的来说，除了偶尔有冗余连接之外大多数网络都是线性的（或者说是树状的）。具有讽刺意味的是，添加冗余路径可能反而会有相反的效果。因为潜在的问题，这是网络需要仔细测试的一个方面。当你添加了额外的路径，你需要知道有产生问题的潜在可能。尽量选择能完成任务的最简单的结构。
大多数网络中单个设备都是相对紧密联合的，尽管使用他们的许多协议和服务可能会连接松散，缓冲和冗余需要在设计时明确考虑到。这可以由某些协议办到，但不是所有的协议都可以。可能的话，根据情况进行选择。
复杂性和效率通常都是和系统紧密相关的。具有讽刺意味的是，最简单的解决方案反而很少有效率高的。因此，有时候需要某种程度的复杂性来实现所要求的功能。复杂性在许多情况下也提高了可靠性。总的来说，如果能满足要求，还是简单些为好，但是前提是它能胜任工作。最后，正如前面所提到的，对于系统故障来说，关键因素是相互影响是隐性的而且不可预知。为了避免出现这种问题，你需要尽可能多地知道你的网络发生了什么事情。不幸的是，这同网络设计的基本原理直接冲突：透明度。从用户的角度来看，网络如何工作的详细内容跟他们无关。因此，网络的设计向用户隐藏了这些细节。如果一个网络在TCP过程中发生了丢包现象，协议会安排在用户不知情的情况下重新发送。也许网络速度会显得很慢，但是这就是顾客所唯一会注意到的事情。从故障分析者的角度来说，隐藏的信息才是你最终需要的东西。解决问题需要你对网络运行的原理有透彻的了解和一系列优秀的收集信息的工具。
结论
工程似乎总是要涉及到均衡：线性对冗余性，简单性对效率，透明度对信息收集。这需要在组建网络时仔细平衡。没有万能的解决方案。可靠性的改进或者易诊断性将会始终是需要花费力气去做的事。但是诊断任何问题的第一步都应该是了解究竟发生了什么事。比较一下你的备选方案的复杂程度并尽量推断出可能在什么地方发生问题。
上一页 [1] [2]
，掌握网络设计 轻松排除网络故障(一)
