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