创建高可用集群
1. 高可用集群介绍
集群是一组计算机一起完成单一任务。执行哪个人物以及如何执行该人物,在集群之间是不同的。
高可用性集群(也称为HA集群)的目标是通过消除瓶颈和单点故障来保持运行中的服务尽可能可用。这主要是通过让高可用集群的节点互相监视故障,并在服务或节点发生故障时将服务迁移到仍然被认为是“健康”的节点来实现的。这是一种不同于试图保持的单个机器的正常运行时间尽可能高的策略。运行服务的服务器的正常运行时间对使用者来说并不重要,但是服务的可用性很重要。
2. 高可用集群配置种类
Active-active 双活高可用性集群,其中服务在多个节点上运行,从而缩短故障转移时间。这类集群的主要 目标是执行负载平衡,因此它们可以扩展到处理更高负载的许多实例。但是,它们需要负载平衡器设备来执行此 负载平衡。双活HA集群可以小到只有两个节点。如果一个节点发生故障,则集群将所有工作负载重定向到其余 节点。当故障节点恢复后,集群会在可用节点之间重新分配工作负载。
Active-passive 高可用性集群,其中服务一次只在一个节点上运行。当一个节点出现故障时,集群才会启动 另一个节点上的服务来替换它。此配置需要fencing来限制无响应节点对集群资源的访问,从而避免集群上的损坏。Fencing将在本课程后面更详细地介绍。
高可用性集群通常用于支持企业中的关键任务服务。实现高可用性集群的软件示例有Pacemaker和Red Hat high availability Add-On。
系统管理员应该决定哪种集群配置最适合他们的需求。例如,许多常见的应用程序已经内置了服务冗余,因为它 们有特定的需求,最好通过内置来处理。示例包括具有主/从的LDAP,或具有多主分区和伸缩的数据库。因此, 这些应用程序不适合使用Red Hat High Availability Add-On提供业务冗余。但是,你仍然可以将这些 服务用作为其他服务设置资源组的资源。
3. 什么时候使用高可用集群
在规划高可用性集群时,有一个重要的问题需要回答:将服务放在HA集群上,服务的可用性时否会提高?
要回答这个问题,了解服务的功能以及如何配置服务的客户端是很重要的:
- 根据解决方案的不同,内置故障转移或负载平衡的DNS和LDAP等服务可能无法从将其放在HA集群中获益。例 如,DNS或LDAP服务可以使用多个具有主从关系或多主关系的服务器。这些服务可以配置为在主服务器和辅助 服务器之间进行数据复制。DNS和LDAP的客户端可以使用多个服务器。主/从或多主配置中涉及的故障转移延迟 较少,因此将服务放在HA集群上时,服务的可用性不会增加。然而,在OpenStack平台解决方案中,将 RabbitMQ和Galera等资源放在HA集群中可能是有利的。关于红帽OpenStack平台高可用性的进一步信息超 出了本课程的范围。
- 没有内置故障转移或负载平衡的服务可以从高可用性集群配置中受益。示例包括NFS和Samba等服务。
并非所有可用性问题都可以通过高可用性集群解决。通常,涉及应用程序崩溃或网络故障的问题无法通过高可用 性集群解决: - 如果一个错误导致应用程序在读取某些输入时崩溃,那么如果它是high availability集群的一部分,它仍然会崩溃。在这种情况下,集群将服务故障转移到不同的节点,但是如果再次读取相同的输入,应用程序将再 次失败。
- 高可用性集群不提供端到端冗余。尽管集群本身可能完全可操作,但如果基础设施中的网络错误导致集群不可访问,则客户机将无法访问服务,即使服务运行在高可用性集群上。因此,重要的是要考虑集群的体系结构并设计它以避免在整个部署过程中出现单点故障。这里有权衡,集群架构师需要考虑他们准备容忍集群的每个组件的风险级别。
4. 高可用集群组件
4.1 Resources和Resource Groups
在集群术语中,基本工作单位称为resource。单个IP地址、文件系统或数据库都被认为是resource。通常,定义这些resource之间的关系以创建面向用户的服务。定义这些关系的最常用方法之一是将一组resource组合成一个组。这指定组中的所有resource需要在同一节点上一起运行,并建立固定的(线性)开始和停止顺序。
例如,为了让集群提供web服务器服务,你需要设置web服务器守护进程、服务器必须共享的数据以及分配给服 务的IP地址。所有这些资源都需要在同一个集群节点上可用,因此你应该将它们组合到一个资源组中。
4.2 failover
当集群发现原来运行服务的节点没有响应时,高可用性集群试图通过将服务迁移到另一个节点来保持服务可用; 这被称为故障转移。
4.3 Fencing
Fencing是一种确保故障集群节点不会在集群上造成损坏的机制,因为该节点仍然可以访问集群资源。 Fencing还允许集群安全地在另一个节点上恢复其资源。这是必要的,因为你不能假设不可访问的节点实际上是关闭的。Fencing通常是通过关闭节点来完成的,因为死节点显然不能做任何事情。在其他情况下,使用组 合操作来切断节点与网络的连接(以停止集群在该节点上分配资源)或与存储的连接(以阻止节点向共享存储写入数据)。
4.4 Shared Storage
大多数高可用性集群还需要某种形式的共享存储,或者可以从多个节点访问的存储。共享存储向集群中的多个节 点提供相同的应用程序数据。运行在集群上的应用程序可以顺序或同时访问数据。高可用性集群需要保证共享存 储上数据的完整性。Fencing提高了数据的完整性。
4.5 Quorum
Quorum描述了维护集群完整性所需的投票系统。每个集群成员都有指定的票数;默认是一票。根据集群配置, 当至少有一半的投票存在时,集群获得法定人数。无法与其他集群成员通信并且无法发送其投票的集群成员将由 按预期运行的大多数集群成员隔离。集群通常需要仲裁才能运行。如果集群丢失或无法建立仲裁,则默认情况下 不会启动任何资源或资源组,并停止正在运行的资源组以确保数据完整性。
本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!