当一个客户端请求SAP服务时，路由器将其发布到单点部署的一台Web Dispatcher的虚拟地址（VIP）上。Web Dispatcher这个时候会和另一台服务器Message Server进行通信，让Message Server对SAP服务器集群实现健康状况检查。Web Dispatcher只有在知晓服务器集群的健康状况后，才能进行负载均衡的工作。这样的实现方式存在诸多弊端：

　　1、Web Dispatcher没有健康探测功能，只能实现负载分发，健康探测功能由另一台服务器Message Server去实现。如此一来，整改负载均衡的实现过程就由两个不同的组件完成，它们之间的通讯并非实时，导致应用故障报告到Web Dispatcher的传递时间延长，可能产生网络延时、丢包、抖动，进而影响真正负载均衡的计算准确性和效率。

　　2、Web Dispatcher和Message Server都只能单点部署，不能部署为集群模式。这样会带来不可靠性，没有冗余和保护机制。

　　3、Web Dispatcher没有基于硬件的SSL卸载芯片，只能依靠服务器CPU处理，对服务器性能消耗极大，且无法集群部署。这样一来会使Web Dispatcher在SSL流量较大时成为性能瓶颈。

　　4、负载均衡策略简单，只能支持基于静态策略的负载均衡。

　　而使用负载均衡设备来处理SAP应用的负载均衡，则能规避以上的所有问题。我们可以使用负载均衡设备设备替换路由设备、负载均衡设备、健康状况检查设备——三合一之后，负载分发就可以更加高效和灵活，还可以针对各个数据包的特征，通过iRules书写复杂场景下的各种策略以实现流量控制。负载均衡设备设备还支持各种会话保持技术，如针对Session、Cookie。此外，SSL加解密、基于N+M的高可用和秒级切换、连接复用机制等（如下图）。如此一来，只需要最少一对负载均衡设备设备，就能帮助用户解决使用原生SAP负载均衡功能带来的诸多弊端。

　　负载均衡设备在SAP解决方案中的价值并不局限于此。由于SAP的Web Server是一种标准的Web-App-DB架构，负载均衡设备系统中内置了SAP应用的各种iApp模版，可以针对SAP的Web和App服务器便捷、快速地进行一键式部署。

　　此外，对于SAP应用的卸载和加速，也是很多用户所非常关心的。SAP应用组件多，部署复杂，产生的连接数也会比较多，延时可能很大，且访问源又可能在全国或全球的各个角落，或是运营商的3G/4G线路，客户端的网络状况就不一定很好。NetWeaver可以由第三方公司帮助其实现一定的应用加速功能，但用户体验并不好，因为这种第三方的加速，只能支持对称加速，且实现的是针对TCP请求的加速，而不是真正的数据库同步解决方案，这样一来HANA数据库在访问时往往会变得非常慢。负载均衡设备的LTM和AAM相结合，可以实现深度应用加速。在它们之上同样内置了诸多针对SAP应用的加速iApp模版，实现各种TCP优化、HTTP压缩、缓存等，无论是基于B/S还是C/S的SAP应用都能从中受益。负载均衡设备的APM还可以与SAP IDM的认证组件相结合，获取用户信息，实现更高级的终端接入安全功能。

　　典型部署模式

　　负载均衡设备针对SAP应用的应用交付典型部署方式有两种：

　　第一种为单一数据中心SAP前端应用交付、优化和防护

　　由于很多基于Web的SAP应用，需要部署在DMZ区域，交付给互联网，最终用户与合作伙伴可以直接通过互联网接入；而分支机构员工可以通过SSL VPN接入，这时候我们需要将APM放置在前端，用户可以在SAP Portal接入的认证过程中实现授权、安全策略检查和过滤。APM可以独立部署，也可以内嵌在LTM内；如部署在数据中心出口可与LTM、DNS结合使用，对出口链路实现负载均衡和优化的同时进行SAP业务的SSL VPN接入。对于内部的SAP应用，则可以使用负载均衡设备 LTM实现基本应用交付功能，并结合AAM、ASM实现应用加速和安全防护。

　　第二种部署方式为多数据中心部署模式

　　在双数据中心部署模式下，负载均衡设备的智能DNS功能负责跨越双中心多节点的流量负载分发，并且可以加入AFM功能实现多数据中心的DDoS防御。对于部署在HANA Cloud或其他公有云中的SAP业务（用户可以直接租用AWS或Azure中的SAP业务，实现更高的冗余性，或者在云爆发模式下处理激增的业务流量），也可以实现智能的调度。