我开发了一个网络应用程序。它将在五台 IIS 服务器的场上运行。一旦与服务器场中的服务器建立了会话，该会话中的更多 HTTP 请求将被定向到同一服务器以用于会话的剩余部分，这一点是绝对必要的。
今天我发现了 F5 的网站并了解了“粘性会话”。由于我的大多数用户将使用移动设备（例如 iPhone），因此他们的 IP 地址可能会在单个会话期间发生变化。这意味着源 IP 不能用于识别唯一会话。白皮书建议 F5 LTM 设备为此提供了一个解决方案，允许我使用 HTTP 请求本身 [或 cookie] 中的内容来确定会话身份。
到现在为止还挺好。但后来我开始思考…… F5 设备是单点故障。此外，如果我大幅增加容量并想要添加更多 F5 设备怎么办？建立一个集群是有道理的。但是，尽管尽我所能在谷歌上搜索，我还是找不到描述集群如何在“幕后”运作的基本概念的白皮书。
考虑... 假设我购买了两台 F5 设备。它们在我的网络的外部（面向 Internet 的）接口上共享一个通用的“虚拟”IP。一个 HTTP 连接进来，两个设备以某种方式确定 F5 #1 应该应答呼叫。F5 #1 现在有一个内存映射，该映射将该会话的身份 [通过 cookie，比方说] 与内部 Web 服务器 #4 相关联。两分钟后，同一客户在同一会话中发起了一个新的 HTTP 连接。目标“虚拟”IP 是相同的，但他的源 IP 地址已更改。我怎么能保证 F5#1 会收到那个连接而不是 F5#2？如果前者收到它，我们就处于良好状态，因为它有一个内存映射来识别会话。但如果后者收到它，它就不会
两个 F5 设备是否以某种方式相互共享信息以使其工作？还是我所描述的配置不是一种实用/常见的做事方式？
对不起，新问题......这些东西对我来说都是新的。
小智 6
大多数 F5 以 HA 对的形式出现，因此这些将被聚集在一起。一旦一个 F5 发生故障，IP 就会由该对中的另一个 F5 承担，因此没有停机时间。对于您的问题，每个 IP 一次仅分配给一个 F5，并且在两者上都不是真正处于活动状态/活动状态。
这就是您的解决方案，现在您应该问的下一个问题是，如果整个站点在 F5 托管的地方出现故障会发生什么？（然后查看全局负载平衡）。