架构框架极客-架构高可用架构模式
Source
Edit
History

undefined

如何设计计算高可用架构

计算高可用的本质是通过冗余来规避部分故障的风险，所以计算高可用的设计思想：通过增加更多服务器来达到计算高可用

计算高可用架构的设计复杂度主要体现在任务管理方面，即当任务在某台服务器上执行失败后，如何将任务重新分配到新的服务器进行执行

关键点：

  1. 哪些服务器可以执行任务。
    • 每个服务器都可以执行任务
    • 只有特定服务器可以执行任务，当执行任务的服务器故障后，系统需要挑选新的服务器来执行任务，例如 Zookeeper 的 Leader 才能处理写操作请求
  2. 任务如何重新执行
    • 对于已经分配的任务即使失败也不做任何处理，系统只需要保证新的任务能够分配到其他非故障服务器上执行即可
    • 设计一个任务管理器来管理需要执行的计算任务，服务器执行完任务后，需要向任务管理器反馈任务执行结果，任务管理器根据任务执行结果来决定是否需要将任务分配到另外的服务器上执行
      任务分配器是一个逻辑的概念，并不一定要求系统存在一个独立的任务分配器模块，比如：Zookeeper 中的 Follower 节点，当接收到写请求时会将请求转发给 Leader 节点处理，当接收到读请求时就自己处理，这里的 Follower 就相当于一个逻辑上的任务分配器

常见的计算高可用架构：主备、主从和集群

一、主备

计算高可用的主备架构无须数据复制，较为简单，设计如下：

  • 主机执行所有计算任务。例如，读写数据、执行操作等。
  • 当主机故障（例如，主机宕机）时，任务分配器不会自动将计算任务发送给备机，此时系统处于不可用状态。
  • 如果主机能够恢复（不管是人工恢复还是自动恢复），任务分配器继续将任务发送给主机。
  • 如果主机不能够恢复（例如，机器硬盘损坏，短时间内无法恢复），则需要人工操作，将备机升为主机，然后让任务分配器将任务发送给新的主机（即原来的备机）；同时，为了继续保持主备架构，需要人工增加新的机器作为备机。

主机架构分为 冷备 和 温备

  • 冷备：备机上的程序包和配置文件都准备好，但备机上的业务服务没有启动，主机故障后，需要人工手工将备机的业务服务启动，并将任务分配器的任务请求切换发送给备机
  • 温备：备机上的业务服务已经启动，但是不对外提供服务

主备需要人工操作，操作时间不可控，操作效率低，手工操作容易出错。比较适合于内部管理系统、后台管理系统这类使用人数不多、使用频率不高的业务，不太适合在线的业务

二、主从

计算高可用架构的从机也是要分配执行任务的，任务分配器需要将任务进行分类，确定哪些任务可以发送给主机执行，哪些任务可以发送给备机执行。设计如下：

  • 正常情况下，主机执行部分计算任务（如图中的“计算任务 A”），备机执行部分计算任务（如图中的“计算任务 B”）。
  • 当主机故障（例如，主机宕机）时，任务分配器不会自动将原本发送给主机的任务发送给从机，而是继续发送给主机，不管这些任务执行是否成功。
  • 如果主机能够恢复（不管是人工恢复还是自动恢复），任务分配器继续按照原有的设计策略分配任务，即计算任务 A 发送给主机，计算任务 B 发送给从机。
  • 如果主机不能够恢复（例如，机器硬盘损坏，短时间内无法恢复），则需要人工操作，将原来的从机升级为主机（一般只是修改配置即可），增加新的机器作为从机，新的从机准备就绪后，任务分配器继续按照原有的设计策略分配任务。

主从架构于主备架构相比，优缺点：

  • 优点：主从架构的从机也执行任务，发挥了从机的硬件性能
  • 缺点：主从架构需要将任务分类，任务分配器会复杂一些

三、集群

主备架构和主从架构通过冗余一台服务器来提升可用性，且需要人工来切换主备或者主从。这样的架构虽然简单，但存在一个主要的问题：人工操作效率低、容易出错、不能及时处理故障。因此在可用性要求更加严格的场景中，我们需要系统能够自动完成切换操作，这就是高可用集群方案。

根据集群中服务器节点角色的不同，可以分为两类：

注意：计算高可用集群，2 台服务器也算

1. 对称集群

即集群中每个服务器的角色都是一样的，都可以执行所有任务。也称为负载均衡集群，详细设计：

  • 正常情况下，任务分配器采取某种策略（随机、轮询等）将计算任务分配给集群中的不同服务器。
  • 当集群中的某台服务器故障后，任务分配器不再将任务分配给它，而是将任务分配给其他服务器执行。
  • 当故障的服务器恢复后，任务分配器重新将任务分配给它执行。

负载均衡集群的设计关键点在于：

  • 任务分配器需要选取分配策略。轮询或者随机
  • 任务分配器需要检测服务器状态。既要检测服务器的状态（服务器是否宕机、网络是否正常）；同时还要检测任务的执行状态（任务是否卡死、是否执行时间过长）。常见做法是任务分配器和服务器之间通过心跳来传递信息，包括服务器信息和任务信息，然后根据实际情况来确定状态判断条件

2. 非对称集群

集群中的服务器分为多个不同的角色，不同的角色执行不同的任务。例如：Master-Slave 角色。详解设计：

  • 集群会通过某种方式来区分不同服务器的角色。例如，通过 ZAB 算法选举，或者简单地取当前存活服务器中节点 ID 最小的服务器作为 Master 服务器。
  • 任务分配器将不同任务发送给不同服务器。例如，图中的计算任务 A 发送给 Master 服务器，计算任务 B 发送给 Slave 服务器。
  • 当指定类型的服务器故障时，需要重新分配角色。例如，Master 服务器故障后，需要将剩余的 Slave 服务器中的一个重新指定为 Master 服务器；如果是 Slave 服务器故障，则并不需要重新分配角色，只需要将故障服务器从集群剔除即可。

非对称集群相比负载均衡集群，设计复杂度：

  • 任务分配策略更加复杂，需要将任务划分为不同类型并分配给不同角色的集群节点。
  • 角色分配策略实现比较复杂，比如，可能需要使用 ZAB、Raft 这类复杂算法来实现 Leader 的选举

以 Zookeeper 为例：

  • 任务分配器：ZooKeeper 中不存在独立的任务分配器节点，每个 Server 都是任务分配器，Follower 收到请求后会进行判断，如果是写请求就转发给 Leader，如果是读请求就自己处理。
  • 角色指定：ZooKeeper 通过 ZAB 算法来选举 Leader，当 Leader 故障后，所有的 Follower 节点会暂停读写操作，开始进行选举，直到新的 Leader 选举出来后才继续对 Client 提供服务。

计算高可用和存储高可用对比

  • 计算高可用架构，主要解决当单点发生故障后，原本发送到故障节点的任务，任务如何分发给非故障节点，根据业务特点选择分发和重试机制即可，不存在数据一致性问题，只需要保证任务计算完成即可
  • 存储高可用架构，解决的问题是当单点发生故障了，任务如何分发给其他非故障节点，以及如何保障数据的一致性问题。
  • 所以存储的高可用比计算的高可用的设计更为复杂。