ZT 如何选择解决方案－单功能设备还是多功能设备？

deyizl

<br/>转帖：<br/><br/>关于网络设计，更常见的问题之一是：“应该选择将所需功能集于一身的设备，还是将网络的功能分配到多个设备上？” 当购买设备的时候，这个问题变得尤为重要。因为上述两种解决方案的两种极端之间有太多的选择。可以选择名副其实的“瑞士军刀”——即集成了L2和L3交换、防火墙、入侵检测、应用负载均衡，甚至如语音网关等更为专业的功能的设备；也可以选择非常集中、专用、声称其所能实现的功能比市场上的任何一款都要强的设备。<br/><br/>让我坦率地告诉你吧。作为网络设计人员，我通常在水平分隔方面出差错。也就是说，我对网络设计的个人观点与《网络领域的12条真理》(RFC1925)中第5条信奉的观点很相近。尽管这个标准早在1996年4月1日发布，但作为一个轻松的文档，其所蕴含的智慧却多得令人吃惊。看重网络架构艺术的人可能也愿意阅读RFC3439——《一些网络架构指南和理念》，这个标准发布于2002年，但时间并不是在4月前后。第5条“真理”中阵述了以下内容：“对于多个不同的问题，总可以将其合并为一个复杂的独立解决方案。但大多数情况下，这种主意很糟糕。”换言之，应使问题的解决方案保持独立性，使它们之间的联系不要过于紧密。<br/><br/>我个人的偏见已谈了很多。选择应在每个设计的基础上进行，但选择融合解决方案也有正当的理由。下次您在设计问题上举棋不定的时候，希翼我能够提供帮助。建议您可以对于每个特定情形问自己几个问题。<br/><br/>    * 如果我将这些功能合并到一个单独的设备中，我能节省出什么？能节省出多少？<br/>      在将多个功能融合到一个单独设备的时候，您可能节省出时间、空间、操作费用等等。如果不能在这些方面的任意一点上节省很多，融合方案可能不是个好主意。<br/>    * 如果采用融合的方案，必须要进行哪些方面的妥协？这要紧吗？<br/>      在将多种功能融合到一个单一平台的过程中，总是会有危险——您最后选择的设备可以实施多种功能，但每个功能都不怎么出众。如果需要或想要将同类解决方案中最佳的那一个部署到所有功能需求，您会发现，这些最佳方案往往是由单个平台完成的。<br/>    * 将这些功能合而为一是否有意义——它们合并后是否达到了1+1 &gt; 2的效果？<br/>      有的时候，两种不同功能的元素可在两种功能间共享。如果它们合并到一个单独的平台，这些元素就无需实行两次，这样做就很有意义。例如，防火墙设备和入侵检测设备都需要深层数据包检测，对于两种类型的设备，有些功能是共通的。因此将两个功能结合到一个设备中似乎是有意义的——至少第一眼看上去是这样。另一个例子是路由和记帐功能——多数路由器在转发数据包的时候能够很容易地计算数据包的数量。<br/>    * 如果将多种功能集于一身，性能是否会降低？这要紧吗？<br/>      大家常常发现，对于一个只用来单纯进行包发送、具有 100Mbps吞吐量的设备，如果大家为其添加了如防火墙或内容安全等功能，则其吞吐量会降至50 Mbps甚至是20 Mbps。如果大家一定需要100Mbps的吞吐量，这样做会很有影响；但如果将该设备放在网络边缘，吞吐量只需要10Mbps的时候，这样做则没什么妨碍。(当然，在您可能只需要10Mbps的时候，您却已支付了100Mbps路由能力的费用!)这里最重要的一点是，在购买前一定要确定需要什么样的性能，可以牺牲什么样的性能。或者尽量了解当启用所有特性的时候，吞吐量的情况如何——让商家符合这些规范，或者自己进行测试。<br/>    * 如果将多种功能融于一身，是否会给运营带来问题？<br/>      如果这些功能的运营责任归于不同的群组，那么组合功能不是一个好主意。<br/>    * 如果组合了功能，还能否灵活地进行升级？<br/>      我曾经负责过一个网络，网络记帐和路由都在我的职责范围内。尽管可以将两种功能结合在一起，但最后我还是放弃了这么做。因为记帐功能是可审计的，而记帐设备上App的每次更改都要经过审计的同意。这潜在地限制了将错误修改应用和新特性添加到将功能分离的路由器。当把越来越多的功能添加到一个平台上时，您会发现在一处修复了一个错误，在另一处会出现一个新的错误。这就成了总也解决不掉的问题! <br/><br/>其实我还能列出更多需要考虑的事项。但我认为它们都不如上述几条重要。如果您有其它设计考虑，或者认为我说得不对——我非常乐意听取您的意见，下面是我的电子邮件地址。如果你们中的一些人面临“部署‘单功能设备’还是‘多功能设备’”解决方案的问题，我希翼列出这短短几条能有帮助。