| 中国 |
|
|
|
![]() |
管理 Serviceguard 第 14 版 > 第 3 章 了解
Serviceguard 的软件组件群集管理器如何工作 |
|
群集管理器用于初始化群集、监视群集的运行状况、识别出现的节点故障以及当有节点加入或脱离群集时管理群集的重组。群集管理器作为守护程序运行在每个节点上。在群集启动和重组期间,会选出一个节点作为群集协调器。尽管所有节点都执行某些群集管理功能,但群集协调器是节点内通信的中枢点。 系统管理员设置群集配置参数,并进行初始群集启动。此后在正常运行过程中,群集就可管理其自身,而无须手动进行干预。群集的配置参数包括群集名称和节点、群集心跳线的联网参数、群集锁信息和定时参数(在第 4 章“规划和记录 HA 群集 ”一章中进行介绍)。可以通过使用 Serviceguard Manager 或编辑群集配置文件设置群集参数(请参阅第 5 章“建立 HA 群集配置”)。输入的参数用于建立二进制配置文件,该文件将传送到群集的所有节点中。 群集中的所有节点必须使用相同的二进制群集配置文件。 群集管理器操作的核心是在群集中的各个节点之间发送和接收心跳线消息。群集中的每个节点使用群集协调器,跨越各自所监视的配置为心跳线设备的 TCP/IP 网络交换心跳线信息(在下面的“监视 LAN 接口和检测故障 ”一节中将进一步介绍了 LAN 监视)。 如果某个群集节点未在规定时间内从其他节点收到心跳线消息,则将启动群集重组。重组结束时,如果一组新的节点组成了群集,则将该信息传递给程序包协调器(在本章的“程序包管理器如何工作”中将进一步说明)。在已经不属于新群集的节点上运行的故障切换程序包将被转移到它们的代管节点。请注意,如果暂时没有心跳线,群集可能会使用与以前相同的节点来进行重组。在这种情况下,程序包既不会暂停也不会切换,不过在重组过程中应用程序的性能可能会略受影响。 如果心跳线和数据通过同一 LAN 子网发送,那么数据拥塞可能会导致 Serviceguard 在心跳线超时期间失去心跳线并启动群集重组,但如果未发生拥塞,则此重组是不必要的。为防止此类情况发生,HP 建议您除了通过数据网络配置心跳线之外,还应针对心跳线使用专用 LAN。
每个节点都以群集心跳线间隔指定的速率发送各自的心跳线消息。群集心跳线间隔在群集配置文件中设置,该文件是作为群集配置的一部分创建的,这在第 5 章“建立 HA 群集配置”中进行了全面介绍。 手动启动可构成一个由群集配置中所有节点组成的群集。手动启动通常在第一次启动群集之时、在进行整个群集范围的维护或升级之后或在重新配置之后进行。 群集启动前,其中的所有节点上必须有相同的二进制群集配置文件。系统管理员可以在 Serviceguard Manager 中启动群集,或从某个节点执行 cmruncl 命令。仅在未运行群集时,即所有节点都未运行 cmcld 守护程序的时候,才能使用 cmruncl 命令。 在启动过程中,群集管理器将检查并确认启动命令中指定的所有节点是否都是群集的有效成员,是否都已启动并在运行,是否试图构成群集以及是否可以相互通信。如果它们满足这些条件,则群集管理器将构成群集。 只要有节点重新引导并加入群集,就会自动启动群集。在个别节点重新引导之后,或者在群集中的所有节点出现故障时,以及在出现大范围电源故障并且所有 SPU 都停止运行时,此功能就会启动。 如果在 /etc/rc.config.d/cmcluster 文件中将 AUTOSTART_CMCLD 标记设置为 1,则将发生自动群集启动。在此参数设置为 1 时,只要有任何节点重新引导,它都将重新加入现有的群集,或者如果没有群集时,它将尝试构成新的群集。 动态重组是群集成员的一种临时变化,它在有节点加入或脱离正在运行的群集时发生。重组不同于重新配置,后者是配置文件的一种永久改变。出现下列情况时会发生群集重组(但不限于以下情况):
重组通常导致群集的成员发生变化。新群集包含的节点可能会与以前的群集不同。 群集重组的算法通常要求一个群集定额,即此前运行的节点在严格意义上的多数(也就是说,超过 50%)。如果此前运行的群集的两半(各占 50%)都可以重组,则将出现脑分裂情形,即同一个群集的两个实例都在运行。在脑分裂情形下,应用程序的不同部分最后可能会同时访问同一磁盘。当一部分正在修改磁盘的状态时,另一部分完全可能正在启动恢复活动。设计 Serviceguard 的定额就是为了避免发生脑分裂情形。 尽管通常要求超过 50% 的群集定额,但恰好 50% 的此前运行的节点也可以重组为一个新的群集,前提是另外 50% 此前运行的节点不进行重组。这一点可通过使用仲裁器来保证,以便在两个大小相等的节点组之间做出选择,使其中一个组形成群集,而强制另一个组关闭。此仲裁器称为群集锁。群集锁是通过锁磁盘、锁定 LUN 或 Quorum Server 来实现的。 只有发生以下情况时,才会将群集锁用作仲裁器:正在运行的群集出现故障,并且在 Serviceguard 试图构成新的群集时会将群集分割为两个同等大小的子群集。这时,每个子群集都将试图获得群集锁。获得群集锁的子群集将构成新的群集,这样就防止了两个子群集同时运行的可能。如果两个子群集的大小不等,则节点多于 50% 的子群集将构成新的群集,此时不会用到群集锁。 如果有一个双节点群集,则需要配置群集锁。如果这两个节点间失去通信,则获得群集锁的节点将接管群集,另一个节点将暂停(系统复位)。如果没有群集锁,则群集中任何一个节点出现故障都会导致另一个节点乃至群集暂停。另请注意,如果在试图获得群集锁的过程中群集锁出现故障,则群集将暂停。 可以使用锁磁盘或锁定 LUN 的群集最多可包含四个节点(含四个节点)。 群集锁磁盘是 LVM 磁盘上的一个特殊区域,它位于一个卷组中,可为群集中的所有节点所共享。与此类似,群集锁定 LUN 是较小的专用 LUN,它连接到包含锁信息的群集中的所有节点。 在 LVM 配置中,用作锁磁盘的磁盘不单用作群集锁,它还可用作普通卷组的一部分,以存储用户数据。另一方面,锁定 LUN 则专用作群集锁,无法在其上存储任何其他数据。 可以在配置文件中指定群集锁卷组和物理卷,或者群集锁定 LUN。 当某个节点获得群集锁时,此区域将会加上标记,从而告诉其他节点此锁已“占用”。 有关锁磁盘或锁定 LUN 的操作如图 3-2 “锁磁盘或锁定 LUN 的操作” 中所示。 Serviceguard 定期对锁磁盘或 LUN 的运行情况进行检查,并在这些设备未通过运行情况检查时向 syslog 文件写入消息。应该监视此文件以便能尽早发现锁磁盘问题。 如果您正在使用锁磁盘,可以根据将要建立的高可用性配置类型在两个锁磁盘选项(单锁磁盘和双锁磁盘)之间进行选择。建议尽可能使用单锁磁盘。然而无论是单锁磁盘还是双锁磁盘,重要的是即使一个节点掉电,群集锁也应该可用。因此,锁配置的选择一定程度上取决于可用供电电路的数量。为维持高可用性,不管作何种选择,群集中的所有节点都必须可以访问群集锁。
单锁磁盘或锁定 LUN 的供电电路应配置为独立于群集中任何节点的供电电路。例如,强烈建议双节点群集使用三个供电电路,为群集锁提供一个独立供电的磁盘或 LUN。在双节点群集中,此单锁设备不得与任何节点共享供电电路,而且锁磁盘必须是一个外部磁盘。对于三节点或四节点群集,该磁盘不能与 50% 或超过 50% 的节点共享供电电路。 如果使用的磁盘与群集节点安装在同一机柜中,则单锁磁盘将是一个单点故障,因为机柜中拥有锁磁盘的节点一旦掉电同样会导致群集锁不可用。同样,在校园群集(该群集包含的节点在两个独立的数据中心中运行)中,单锁磁盘在它所驻留的数据中心万一出现灾难性故障时,也会成为单点故障。 只有在这两种情况下,才应该使用由两个单独供电的群集磁盘构成的双群集锁,以避免锁磁盘成为单点故障。
对于双群集锁,这两个磁盘一定不能共享供电电路或节点机箱。在这种情况下,如果电源故障影响到一个节点和磁盘,那么另一个节点和磁盘仍然可用,因而就可以在剩下的节点上进行群集重组。对于校园群集,每个数据中心都必须有一个锁磁盘,且所有的节点都必须可以访问这两个锁磁盘。万一其中一个数据中心出现故障,剩下的数据中心中的节点就可以获得它们的本地锁磁盘,从而可以成功地重组新的群集。
Quorum Server 可用于任意大小的群集。Quorum Server 进程运行于获取定额服务的群集之外的机器上。Quorum Server 在已知端口上监听从 Serviceguard 节点发出的连接请求。服务器在内存中为每个群集保留一个特定区域,当某个节点获得群集锁时,此区域将会加上相应标记,从而告诉其他节点此锁已“占用”。如果两个大小相等的节点组之间失去通信,那么从 Quorum Server 获得群集锁的这个组将接管群集,其他节点则会执行系统复位。如果没有群集锁,群集中的任何一个节点出现故障都将导致其他组(即整个群集)暂停。另请注意,如果在试图访问 Quorum Server 时此服务器不可用,则群集将会暂停。 图 3-3 “Quorum Server 操作” 说明了 Quorum Server 的操作。当节点 1 与节点 2 之间的通信失败时,Quorum Server 将选择其中一个节点(在此示例中为节点 2)在群集中继续运行。另一节点将暂停。 Quorum Server 在单独的系统中运行,可为多个群集提供定额服务。 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||