硬件方式的负载均衡       要在池中多台机器间实现请求负载均衡，最直接的方式是使用硬件设备。只要接上硬件，打开它，完成一些基本的（或更常见的， 非常复杂的）配置，就可以开始分担流量。但使用硬件设备有一些缺点。它在可配置性方面很差，尤其是管理大型的VIP（带有很多实际服务器）时，因为配置界 面往往是复杂的基于telnet的命令行，或者20世纪90年代初期的Web界面。任何对配置的改动或检查都是手工的过程，或者是编写一套脚本，通过调用 底层自身接口，进行远程操的过程。具体要看程序的规模，这一点有可能不是什么大问题，尤其是在你打算配置好设备之后就很长时间不去管它，让它自己运作的情 况下。
    但是，这种方案在价格方面不如人意。硬件负载均衡设备总是非常昂贵，从上万美元到数十万美元。还要记得我们至少需要两台用 于灾难时实现故障转移，成本就更加昂贵了。有有很多公司制造负载平衡产品，通常还捆绑有其他特性，比如Web缓存、GSLB、HTTPS加速和DOS保护 等。这类设备中比较上规模的有Alteon’s AS 系列（应用交换机）、Citrix Netscalers、Cisco的CSS系列（内容交换服务器），以及Foundry Network的ServerIron家族。初期要找到这些产品可不容易，因为公司之间命名习惯各不相同，容易互相混淆。除了打上负载平衡器的标签之外， 这些设备也叫Web交换机、内容交换机和内容路由器等。
    和早先提到的DNS方式的负载均衡方法相比，使用硬件设备有一些主要的优点。向VIP添加真实的服务器和从VIP中移除真 实的服务器都是即刻发生的。只要添加了一台新的服务器，流量就会流向它，移除它时，流量也立即停止流向它（尽管对于粘滞会话而言，情况可能不是那么简 单）。这里没有DNS方式中需要等待传播的问题，因为需要知道配置的唯一一台机器就是负载均衡器自己（和它的备用机器，但配置变化往往通过专有连接在这两 者之间共享）。当三台真实的服务器被放置到VIP中，就可以确认它们会享有相同流量。和DNS负载平衡不同，这种方式并不依赖于客户端从服务处得到不同 的答案，所有客户端都访问相同的地址。对于每一个客户端，都只有一台服务器——虚拟服务器。因为这种方法是在单一位置基于每个请求（对于粘滞会话则是基于 会话）来处理负载平衡的，它可以公平地均衡负载。而实际上这种方式是可以根据任意需求来均衡负载的。如果手中有一台Web服务器，由于某些原因（有更多的 RAM或者更强的处理器），它有额外的容量或性能，那么可以对它进行不平均分配，给予它更多的流量，这样可以充分地使用手中的资源，而不是白白地浪费额外 的性能。
    硬件设备这种方式和基于DNS的方式相比，最大的优点在于能很好地处理故障问题。当在VIP池中，有一台真实的服务器当机 了，负载均衡器可以自动检测到这一点，并且不再向它发送流量。这样就可以完全自动化Web服务的故障转移。向VIP中添加比所需更多的服务器之后，如果有 一台或者两台当机了，处于其他节点之上的空闲的性能会继而为我们服务，就好像没发生什么事一样——至少从用户角度考虑没什么事发生。接下来的问题就是，设 备怎么知道哪一台真实服务器出故障了呢？各种设备支持不同的自定义的方式，但基本上都基于同一个理念，设备周期性地检测每台真实服务器，看它是否仍然给出 回复。具体操作可能包含简单的网络可用性检测、使用ping或者协议级别的检测，比如对于给定的HTTP请求，会返回一个特定的字符串或者复杂的自定义的 通知机制，检查内部应用程序的健康状态