使用WAN优化进行带宽管理和监控

　　随着企业往WAN流量中增加越来越多的应用程序，带宽需要也在不断地以指数方式增长。而虽然带宽管理并不像之前那样昂贵，但是在预算削减时期增加带宽将是企业的最后选择。在许多情况下，增加带宽并不能改善应用程序的性能，所以实现主动的WAN管理，然后再运行应用程序，这才是更好的方法。在服务器整合过程中仔细规划并进行优化级划分将保证WAN以最优方式运行，并且实现最大的容量。

　　带宽管理

　　很少有公司希望完全禁止员工访问诸如YouTube等网站或使用P2P协议工具。如果员工访问这些网站占用的带宽较少，那么最佳的策略是允许他们使用。带宽管理允许WAN管理人员将它设置为符合现实的策略。当带宽紧张时，带宽管理能够限制或阻挡娱乐流量，以防止它对业务流量产生不良影响。通过与QoS一起使用，这些策略能够保证即使在允许娱乐流量通过时，网络仍然能够满足最低质量要求。

　　实现有效的带宽管理涉及几个方面的问题。首先是WOC必须能够在应用层对流量进行分类。业务和客户Web流量都使用相同的端口，而有一些与业务无关的应用程序会不停地改变端口以隐藏它们的身份。因此，带宽管理必须应该能够通过端口以外的方式理解应用程序。这要求具备高效的深度数据包检测（DPI）以及处理检测结果以确定应用程序的能力。这个功能也必须不断地更新。新的应用程序会不停地出现，特别是在客户领域。如果WOC不更新，它就无法知道如何限制或阻挡新的吞食带宽的与业务无关的应用程序。

　　缺乏策略的分类是没有意义的。如果WOC不知道如何处理流量，那么仅仅知道是什么样的应用程序是没有用的。WAN管理器应该寻找一种优化解决方案，其中应包含一组通用的管理流量的规则。此外，简化这些规则和策略的管理也是非常重要的。

　　WAN可见性

　　管理WAN通常是很重要的，但随着流量增加和预算缩减它变得更加的重要了。非常重要的是，管理人员要理解有哪些应用程序在使用WAN。如果不知道，那就意味着这个管理人员无法应用正确的带宽管理或QoS规则。WAN监控不能够停留在原来简单的按端口实现的简单地报告哪些应用程序在使用某个端口。知道通过端口80（HTTP）的流量有多少对于管理人员而言用处并不大。这个流量是与业务有关还是无关的？这些业务应用程序是什么？甚至知道了它是SAP或Oracle流量也还是不够的。管理人员必须知道具体的SAP应用程序，以及很多时候需要知道应用程序中发生的事务的类型，这样才能够保证最重的事务能获得较高的优先级。现有的监控和报告模式必须进行升级，以满足这个要求。

　　关注应用程序并不是WAN管理人员在监控时需要的唯一改变。面向服务的架构（SOA）和网关及安全设备的增加都会使现有的监控架构变得更复杂。这个变化可以应用时间监控方面得到最好的体现。

　　在过去，理解响应时间在概念上是很简单的。将一个监控器部署在WAN路由器上。当发生响应时间问题时，WAN管理人员就能够确定它位于路由器哪一端。如果它位于WAN端，那么问题就发生在WAN上；如果它位于服务器端，那么就应该请求应用程序小组进行处理。虽然这个方法并不是100%精准，但是在大多数情况下它都能够确定主要的问题所在。

　　目前，这个方面有许多复杂的问题。首先是设备与网关数量的增加。数据必须通过的安全服务和设备清单越来越大。其中安全性清单包括Web防火墙、应用防火墙、XML防火墙、防数据丢失设备、反病毒设备和入侵检测系统（IPS）。除此之外还有XML应用网关、电子邮件和其他网关，以及网络方面的WOC。如果所有这些设备都影响到应用程序的运行，而且其中许多设备都是由服务器和应用程序小组以外的团队管理的，那么确定响应时间问题需要知道这些设备是否出现问题，并且通常要求应用程序、安全性和网络团队共同交流才能够确定问题所在。

　　管理SOA

　　更加复杂的监控由是采用SOA架构开发的应用程序。SOA的其中一个重要的特点是一个响应的产生过程并不是由一个应用程序独自完成的。有一个例子可以很好地说明这个概念。一个用户向应用服务器发起一个请求。开发的这个主应用程序会调用其他三个应用程序，它们所产生的信息就在主应用程序中进行组合。

　　由于是通过SOA实现的，主应用程序并不需要知道其它应用程序是否正在执行，它只负责发出请求。其他应用程序可能位于同一个服务器上，也可以在同一个数据库中心的另一个服务器上，或者是在世界另一端的数据中心的服务器上。在这里，我们假设其中一个应用程序位于相同的主机上，但是其他两个应用程序位于通过WAN连接的其他数据中心的服务器上。当主应用程序发出请求之后，SOA会向其他两个服务器发出消息。当它们产生响应时，主应用程序会将响应组合成为一个响应。

　　这个例子中的用户呼叫业务操作人员，向他们报告了响应时间问题。业务操作人员可以检查WAN链路，以及主应用程序所在的数据中心服务器，并处理他们发现的所有问题。如果没有发现问题，那么问题可能是在中间服务器或者这些服务器与主应用程序之间的WAN链路上。

　　因为主应用程序只有在所有信息返回后才能够响应用户，数据中心或服务器之间WAN响应过慢都可能导致整个事务变慢。问题是业务操作人员并不知道中间事务。解决这个问题需要网络操作人员和应用程序小组之间更紧密的协作，此外还需要使用监控工具整合所有结果。