《27 - 如何设计计算高可用架构？.docx》由会员分享，可在线阅读，更多相关《27 - 如何设计计算高可用架构？.docx（9页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、27 | 如何设计计算高可用架构？ 计算高可用的主要设计目标是当出现部分硬件损坏时，计算任务能够接着正常运行。因此计算高可用的本质是通过冗余来规避部分故障的风险，单台服务器是无论如何都达不到这个目标的。所以计算高可用的设计思想很简洁：通过增加更多服务器来达到计算高可用。 计算高可用架构的设计困难度主要体现在任务管理方面，即当任务在某台服务器上执行失败后，如何将任务重新安排到新的服务器进行执行。因此，计算高可用架构设计的关键点有下面两点。 1. 哪些服务器可以执行任务 第一种方式和计算高性能中的集群类似，每个服务器都可以执行任务。例如，常见的访问网站的某个页面。 其次种方式和存储高可用中的集群类
2、似，只有特定服务器（通常叫主机）可以执行任务。当执行任务的服务器故障后，系统须要选择新的服务器来执行任务。例如，ZooKeeper 的 Leader 才能处理写操作恳求。 2. 任务如何重新执行 第一种策略是对于已经安排的任务即使执行失败也不做任何处理，系统只须要保证新的任务能够安排到其他非故障服务器上执行即可。 其次种策略是设计一个任务管理器来管理须要执行的计算任务，服务器执行完任务后，须要向任务管理器反馈任务执行结果，任务管理器依据任务执行结果来确定是否须要将任务重新安排到另外的服务器上执行。 须要留意的是：任务安排器是一个逻辑的概念，并不肯定要求系统存在一个独立的任务安排器模块。例如：
3、Nginx 将页面恳求发送给 Web 服务器，而 CSS/JS 等静态文件干脆读取本地缓存。这里的 Nginx 角色是反向代理系统，但是担当了任务安排器的职责，而不须要 Nginx 做反向代理，后面再来一个任务安排器。 对于一些后台批量运算的任务，可以设计一个独立的任务安排系统来管理这些批处理任务的执行和安排。 ZooKeeper 中的 Follower 节点，当接收到写恳求时会将恳求转发给 Leader 节点处理，当接收到读恳求时就自己处理，这里的 Follower 就相当于一个逻辑上的任务安排器。 接下来，我将具体阐述常见的计算高可用架构：主备、主从和集群。 主备 主备架构是计算高可用最简
4、洁的架构，和存储高可用的主备复制架构类似，但是要更简洁一些，因为计算高可用的主备架构无须数据复制，其基本的架构示意图如下： 主备方案的具体设计： 主机执行全部计算任务。例如，读写数据、执行操作等。 当主机故障（例如，主机宕机）时，任务安排器不会自动将计算任务发送给备机，此时系统处于不行用状态。 假如主机能够复原（不管是人工复原还是自动复原），任务安排器接着将任务发送给主机。 假如主机不能够复原（例如，机器硬盘损坏，短时间内无法复原），则须要人工操作，将备机升为主机，然后让任务安排器将任务发送给新的主机（即原来的备机）；同时，为了接着保持主备架构，须要人工增加新的机器作为备机。 依据备机状态的不
5、同，主备架构又可以细分为冷备架构和温备架构。 冷备：备机上的程序包和配置文件都打算好，但备机上的业务系统没有启动（留意：备机的服务器是启动的），主机故障后，须要人工手工将备机的业务系统启动，并将任务安排器的任务恳求切换发送给备机。 温备：备机上的业务系统已经启动，只是不对外供应服务，主机故障后，人工只须要将任务安排器的任务恳求切换发送到备机即可。冷备可以节约肯定的能源，但温备能够大大削减手工操作时间，因此一般状况下举荐用温备的方式。 主备架构的优点就是简洁，主备机之间不须要进行交互，状态推断和切换操作由人工执行，系统实现很简洁。而缺点正好也体现在人工操作这点上，因为人工操作的时间不行控，可能系
6、统已经发生问题了，但维护人员还没发觉，等了 1 个小时才发觉。发觉后人工切换的操作效率也比较低，可能须要半个小时才完成切换操作，而且手工操作过程中简单出错。例如，修改配置文件改错了、启动了错误的程序等。 和存储高可用中的主备复制架构类似，计算高可用的主备架构也比较适合与内部管理系统、后台管理系统这类运用人数不多、运用频率不高的业务，不太适合在线的业务。 主从 和存储高可用中的主从复制架构类似，计算高可用的主从架构中的从机也是要执行任务的。任务安排器须要将任务进行分类，确定哪些任务可以发送给主机执行，哪些任务可以发送给备机执行，其基本的架构示意图如下： 主从方案具体设计： 正常状况下，主机执行部
7、分计算任务（如图中的计算任务 A），备机执行部分计算任务（如图中的计算任务 B）。 当主机故障（例如，主机宕机）时，任务安排器不会自动将原本发送给主机的任务发送给从机，而是接着发送给主机，不管这些任务执行是否胜利。 假如主机能够复原（不管是人工复原还是自动复原），任务安排器接着根据原有的设计策略安排任务，即计算任务 A 发送给主机，计算任务 B 发送给从机。 假如主机不能够复原（例如，机器硬盘损坏，短时间内无法复原），则须要人工操作，将原来的从机升级为主机（一般只是修改配置即可），增加新的机器作为从机，新的从机打算就绪后，任务安排器接着根据原有的设计策略安排任务。 主从架构与主备架构相比，优缺
8、点有： 优点：主从架构的从机也执行任务，发挥了从机的硬件性能。 缺点：主从架构须要将任务分类，任务安排器会困难一些。 集群 主备架构和主从架构通过冗余一台服务器来提升可用性，且须要人工来切换主备或者主从。这样的架构虽然简洁，但存在一个主要的问题：人工操作效率低、简单出错、不能刚好处理故障。因此在可用性要求更加严格的场景中，我们须要系统能够自动完成切换操作，这就是高可用集群方案。 高可用计算的集群方案依据集群中服务器节点角色的不同，可以分为两类：一类是对称集群，即集群中每个服务器的角色都是一样的，都可以执行全部任务；另一类是非对称集群，集群中的服务器分为多个不同的角色，不同的角色执行不同的任务，
9、例如最常见的 Master-Slave 角色。 须要留意的是，计算高可用集群包含 2 台服务器的集群，这点和存储高可用集群不太一样。存储高可用集群把双机架构和集群架构进行了区分；而在计算高可用集群架构中，2 台服务器的集群和多台服务器的集群，在设计上没有本质区分，因此不须要进行区分。 对称集群 对称集群更通俗的叫法是负载均衡集群，因此接下来我运用负载均衡集群这个通俗的说法，架构示意图如下： 负载均衡集群具体设计： 正常状况下，任务安排器实行某种策略（随机、轮询等）将计算任务安排给集群中的不同服务器。 当集群中的某台服务器故障后，任务安排器不再将任务安排给它，而是将任务安排给其他服务器执行。 当
10、故障的服务器复原后，任务安排器重新将任务安排给它执行。 负载均衡集群的设计关键点在于两点： 任务安排器须要选取安排策略。 任务安排器须要检测服务器状态。 任务安排策略比较简洁，轮询和随机基本就够了。状态检测略微困难一些，既要检测服务器的状态，例如服务器是否宕机、网络是否正常等；同时还要检测任务的执行状态，例如任务是否卡死、是否执行时间过长等。常用的做法是任务安排器和服务器之间通过心跳来传递信息，包括服务器信息和任务信息，然后依据实际状况来确定状态推断条件。 例如，一个在线页面访问系统，正常状况下页面平均会在 500 毫秒内返回，那么状态推断条件可以设计为：1 分钟内响应时间超过 1 秒（包括超
11、时）的页面数量占了 80% 时，就认为服务器有故障。 例如，一个后台统计任务系统，正常状况下任务会在 5 分钟内执行完成，那么状态推断条件可以设计为：单个任务执行时间超过 10 分钟还没有结束，就认为服务器有故障。 通过上面两个案例可以看出，不同业务场景的状态推断条件差异很大，实际设计时要依据业务需求来进行设计和调优。 非对称集群 非对称集群中不同服务器的角色是不同的，不同角色的服务器担当不同的职责。以 Master-Slave 为例，部分任务是 Master 服务器才能执行，部分任务是 Slave 服务器才能执行。非对称集群的基本架构示意图如下： 非对称集群架构具体设计： 集群会通过某种方式
12、来区分不同服务器的角色。例如，通过 ZAB 算法选举，或者简洁地取当前存活服务器中节点 ID 最小的服务器作为 Master 服务器。 任务安排器将不同任务发送给不同服务器。例如，图中的计算任务 A 发送给 Master 服务器，计算任务 B 发送给 Slave 服务器。 当指定类型的服务器故障时，须要重新安排角色。例如，Master 服务器故障后，须要将剩余的 Slave 服务器中的一个重新指定为 Master 服务器；假如是 Slave 服务器故障，则并不须要重新安排角色，只须要将故障服务器从集群剔除即可。 非对称集群相比负载均衡集群，设计困难度主要体现在两个方面： 任务安排策略更加困难：
13、须要将任务划分为不同类型并安排给不同角色的集群节点。 角色安排策略实现比较困难：例如，可能须要运用 ZAB、Raft 这类困难的算法来实现 Leader 的选举。 我以 ZooKeeper 为例： 任务安排器：ZooKeeper 中不存在独立的任务安排器节点，每个 Server 都是任务安排器，Follower 收到恳求后会进行推断，假如是写恳求就转发给 Leader，假如是读恳求就自己处理。 角色指定：ZooKeeper 通过 ZAB 算法来选举 Leader，当 Leader 故障后，全部的 Follower 节点会暂停读写操作，起先进行选举，直到新的 Leader 选举出来后才接着对 Client 供应服务。 小结 今日我为你讲了几种常见的计算高可用架构，并分析了不同方案的具体设计，希望对你有所帮助。 这就是今日的全部内容，留一道思索题给你吧，计算高可用架构从形式上和存储高可用架构看上去几乎一样，它们的困难度是一样的么？谈谈你的理解。 欢迎你把答案写到留言区，和我一起探讨。信任经过深度思索的回答，也会让你对学问的理解更加深刻。（编辑乱入：精彩的留言有机会获得丰厚福利哦！）