我开发了一个Web应用程序。 它将在一个由五台IIS服务器组成的场中运行。 一旦与服务器场中的服务器build立会话，绝对必要的是，该会话内的进一步的HTTP请求将被导向到该会话剩余部分的同一服务器。
今天，我发现了F5的网站，并了解到“粘性会话”。 由于我的大部分用户都是移动设备（例如iPhone），所以他们的IP地址可能会在一个会话中发生变化。 这意味着源IP不能用于识别唯一的会话。 白皮书指出，F5 LTM设备为此提供了一个解决scheme，使我可以使用HTTP请求本身（或cookie）中的内容来确定会话身份。
到现在为止还挺好。 但是后来我开始想… F5设备是单点故障。 而且，如果我大幅增加容量并想增加更多的F5设备呢？ build立一个集群是有道理的。 但是，尽pipe我可以做到最好的谷歌search，但我找不到一份白皮书来描述集群如何“引擎盖”的基本概念。
考虑…假设我购买了两台F5设备。 他们在我的networking的外部（面向互联网）接口上共享一个共同的“虚拟”IP。 一个HTTP连接进来，不知何故这两个设备确定F5＃1应该接听电话。 F5＃1现在有一个内存映射，将会话的身份[通过cookie，比方说]连接到内部Web服务器＃4。 两分钟后，同一客户启动一个新的HTTP连接作为同一会话的一部分。 目的地“虚拟”IP是相同的，但他的源IP地址已经改变。 如何在世界上我能保证F5＃1将接收连接，而不是F5＃2？ 如果前者接收到它，我们状态良好，因为它有一个内存映射来识别会话。 但是，如果后者接收到它，则不会意识到该会话与Web服务器＃4相关联。
两台F5设备是否以某种方式彼此共享信息，以使其工作？ 或者是我所描述的configuration不是一种实用/常用的方法？
对不起新问题…这东西对我来说都是新鲜事物。
大多数F5都是HA对，所以这些都会聚集在一起。 一旦F5发生故障，IP中的其他F5就会假设IP地址，所以不会出现停机时间。 对于您的问题，每个IP一次只能分配给一个F5，并且两者都不是真正的主动/主动。
这是你的解决scheme，现在你应该问的下一个问题是，如果整个网站在两个F5都托pipe的地方发生了什么？（然后看看全局负载平衡）。
我不相信你可以真正地“聚合”两个F5内容交换机，但我相信他们正在研究这个function，但我可能是错的。 群集负载平衡器是一个巨大的工程挑战 – 它们如何在第4层或第7层共享信息，它们如何在第2层或第3层进行通信，以及如何在不影响性能的情况下启用群集和信息共享，因为负载均衡器必须运行在线速度基本上。
以前认为防火墙，基于代理的防火墙始终是独立节点，因为他们在第7层做了太多的事情，而且基本上不可能在节点之间共享这些信息而不会影响性能，而有状态数据包filter只需要传输第4层信息，甚至是一个开销。 负载平衡器通常会configuration大部分的configuration，就像贵方那样充当端点，所以整个TCP会话被重写，负载平衡器成为服务器的客户端（即基本上有两个stream程，这是实际客户端无法直接向后端服务器执行httpstream水线的一个原因）。
有了HA，你不能达到你想要的规模，所以你将不得不扩大你的负载平衡器来处理负载等供应商喜欢这样的扩大，它通常（并不总是有时你可以通过许可证升级启用额外的CPU）意味着一个新的，更大的盒式HA确实提供了弹性和可靠性。 使用HA，通常会有命令传播，configuration同步和会话交换的某些元素（可以configuration一定程度的负载）。
你可以通过负载平衡来衡量你的负载平衡器（即LB – > LB – > Web Farm），但这不是很好，可以引入延迟，（非常）昂贵，而且我的基础架构还有另一个失败点成功实施。
你可以使用像VRRP那样的东西，就像准群集一样。在这个实现中，你可以在Web场前有两组负载均衡器，称之为HA1和HA2。 使用VRRP，可以创build两个VIP，一个在HA1（vip1）上，另一个在HA2（vip2）上，由于VRRP优先级configuration较高。 vip1和vip2都可以通过VRRP自动（基于监视器等）故障切换到另一个HA对，或者通过降低VRRP优先级手动故障切换到另一个HA对。
大多数供应商在上述configuration上都有知识库文章。 我相信有一个供应商在他们的产品中有真正的集群，但我会让你的谷歌。
所有负载均衡器都有各种forms的持久性，您将其应用于后端服务器关联。 当今stream行的forms是cookies和哈希（基于4元组和一两个其他的东西）。 当负载平衡器像你的情况一样充当端点时，一旦TCP连接完全build立，它将基本上创build一个协议控制缓冲区，它将包含有关连接的信息（基本上是4元组和其他一些事情再次）。 有两个这样的缓冲区，一个代表连接的每一边，这个缓冲区驻留在负载平衡器的内存中，直到会话结束，当它们被清除以释放内存以供再次使用时。
Citrix NetScaler似乎是最先进的负载均衡解决scheme，特别是在集群领域。 您不需要安装HA对，只需使用两个盒子群集即可。 然后，随着您的增长，只需在群集中添加更多的框。 他们也可以群集运行在虚拟机中的负载均衡器。
对于所有负载平衡器，可以设置HA对以防止单点故障。 这一直是这样的。 大知识产权是昂贵的。 你考虑过Citrix NetScaler吗？ 有一个非常便宜的虚拟机版本。 实际上有一个免费的版本，你可以在生产量有限的吞吐量中使用。 不仅如此，您还可以根据需要将NetScaler VPX部署在与应用程序相同的服务器上。 只是一个想法。 给我发电子邮件，如果你想了解更多细节
在F5平台上，您基本上有两种select，具体取决于您正在configuration的VIP的types。 在第4层VIP（实际上是NAT）上，您可以configuration连接镜像，从而在HA事件期间不会中断TCP会话。 对于第7层VIP来说，这是不可能的 – 只有太多的状态可以实时备份到备用服务器上，但是您可以镜像cookie持久性logging，这将确保在HA故障切换之后客户端重新连接时，它将被redirect到相同的后端服务器。
我没有第一手的知识，但是我相信网队也有类似的能力。
也就是说，一个完全依赖于这种持久性的scheme将会遇到问题，特别是如果你有后端服务器在任何定期的基础上进出VIP轮换。 我鼓励你调查站起来共享caching（memcached是伟大的），您的服务器池的任何成员可以查询来validation传入的请求上的cookie。 这比你想象的更容易:)