Tal*_*ero 2 linux cluster failover high-availability failovercluster
我正在考虑为我客户的网站创建一个 HA Linux 机器。我有哪些主要选择，或者我可以找到更多信息的地方/文章是什么？
如果它也是单个图像，我会很高兴，这样现有的软件就可以正常工作。
任何帮助表示赞赏。
谢谢！
你有很多选择。您可以使用哪些取决于您的网站的编码方式。
紧密耦合，单一状态
由于……原因，该网站只能运行一个实例。出于某种原因，并行运行两个将是一个非常糟糕的主意。这种网站很少见。
CAP 定理：整个系统的一致性是最重要的，根本不是分区容忍的，这使得可用性成为主要的工程目标。
紧密耦合，每个会话单一状态
该网站仅在用户一直与同一个网站交互时才能正常运行。如果他们打错了服务器，事情可能会出错。
CAP定理：用户会话需要严格的一致性，但系统不需要。由于在故障期间丢失会话，因此具有一定的分区容忍度仍然是服务的降级，但整个系统将继续存在。
松散耦合，状态无关紧要
最具可扩展性的选项是，如果完全保留状态，这种类型的站点会将会话状态保留在数据库层中。打错了服务器，没关系，因为网络服务器只是打到数据库的状态。
CAP 定理：用户会话对松散一致性感到满意，分区容忍度非常高，这意味着可用性是最重要的。
单状态是迄今为止最难实现 HA 的，这就是为什么站点几乎从不为此编码的原因。它需要一个且仅一个数据库或文件集和一个且仅一个网络服务器，在 HA 服务器成员之间进行复制或卷传递，因此一旦第一台服务器死机，另一个可以拿起它。工程很棘手，通常更容易将站点重新编码为单状态 Per Session 应用程序，其中问题要容易得多。
但是如果你别无选择，你的唯一主要选择是像heartbeat那样聚类。将一组服务器放在一起，配置文件和数据库复制，并设置故障转移规则。不容易。
单一系统映像对于网站来说是不可行的，因为创建一个高性能和可用的系统的难度非常高。SSI 系统背后有很多工程来确保单个 IPC 空间和严格的系统级一致性，这往往会使 Web 服务变得非常非常缓慢。它最适用于需要在物理节点之间进行该级别集成的系统，而 Web 服务不是这样的系统。它的分区容错性非常非常糟糕，这使得 SSI 成为一个糟糕的 HA 解决方案。这不是 HA 的捷径。使用集群会更好地为您服务。
每个会话的单个状态通常通过创建多个 Web 服务器并在它们前面使用负载均衡器（例如haproxy、AWS Elastic Load Balancer ( elb ) 或硬件系统（例如 F5 BigIP））来处理。它们配置了粘性会话，其中每个用户会话都被馈送到单个服务器。当一个人死了，其他人接手；任何在下拉框中有会话的用户都会重新启动，这就是生活。对您的网站进行编码，以便此类会话中断不会破坏事物。
状态无关紧要的处理方式与每会话单个状态的处理方式相同，但主要区别在于没有粘性会话。负载平衡器被配置为将每个请求提供给池中的任何服务器，网络服务器根据请求从数据库提供状态。当一台服务器死亡时，没有人注意到。