Docker Swarm故障切换行为似乎有点令人失望

我目前正在尝试使用Docker Swarm在三节点集群上以高可用性的方式设置我们的应用程序（包括无状态和有状态服务）。对于“高可用性”，我的意思是“可以承受三个节点中一个节点的故障”

我们已经进行此类安装（使用其他方法，而不是Docker，更不用说Docker Swarm）相当长一段时间了，并且取得了良好的成功，包括可接受的故障切换行为，因此我们的应用程序本身（以及构成它的服务）已经证明，在这样的三节点设置中，它/它们可以实现高可用性

有了Swarm，我成功地启动并运行了应用程序（所有三个节点都启动了），并且注意到我对每个服务都进行了冗余配置，即，每个服务都有多个实例，它们为HA进行了正确配置，并且不是所有服务实例都位于同一Swarm节点上。当然，我还注意到，我的所有群节点都作为管理节点加入了群，这样，如果最初的领头节点出现故障，其中任何一个都可以成为群的领头节点

在这种“良好”状态下，得益于Swarm的入口网络，我可以访问任何节点上暴露端口上的服务。 很酷。 在生产环境中，我们现在可以在swarm worker节点前面放置一个高可用性负载平衡器，这样客户端就可以连接到一个IP地址，甚至不会注意到其中一个节点是否出现故障

所以现在是测试故障转移行为的时候了。。。 我希望杀死一个Swarm节点（即，虚拟机的硬关闭）会让我的应用程序继续运行，当然是在“降级”模式下。 唉，在关闭之后，我在相当长的一段时间内无法再通过暴露（通过入口）端口访问我的任何服务。有些确实可以再次访问，并且确实已成功恢复（例如，可以再次访问三节点Elasticsearch群集，当然现在缺少一个节点，但返回“绿色”状态）。但其他人（唉，这包括我们的内部LB…）仍然无法通过其发布的端口访问

“docker node ls”将一个节点显示为无法访问

$ docker node ls
ID                           HOSTNAME  STATUS  AVAILABILITY  MANAGER 
STATUS
kma44tewzpya80a58boxn9k4s *  manager1  Ready   Active        Reachable
uhz0y2xkd7fkztfuofq3uqufp    manager2  Ready   Active        Leader
x4bggf8cu371qhi0fva5ucpxo    manager3  Down    Active        Unreachable

正如所料

---

关于导致这些影响的Swarm设置，我可能做错了什么？我是不是期望太高了？

LB是否正在尝试向关闭的节点发送请求？LB什么时候取？您是否签入了非Swarm/非Docker部署，这就像解决问题一样有效。我们的LB（Apache+mod_jk）将很快注意到一个实例已关闭，并选择剩余的一个（我每个实例有两个）。但我甚至无法访问LB的状态页面（jkmanager应用程序），无论工作应用程序的状态如何，该页面“总是”工作。所以我们的LB不是这里的问题，我想说。我重温了这个主题，故障转移行为充其量也不是最理想的。LB是否正在尝试向关闭的节点发送请求？LB什么时候取？您是否签入了非Swarm/非Docker部署，这就像解决问题一样有效。我们的LB（Apache+mod_jk）将很快注意到一个实例已关闭，并选择剩余的一个（我每个实例有两个）。但我甚至无法访问LB的状态页面（jkmanager应用程序），无论工作应用程序的状态如何，该页面“总是”工作。所以我们的LB不是这里的问题，我想说。我重温了这个主题，故障转移行为充其量仍然是次优的。