Sun Cluster工作原理介绍

本章的结构安排是以介绍Sun Cluster中重要的概念为主线。相关的工作原理分布在各个概念的介绍之中。 quorum的概念在分布式系统中经常被用到。原本的概念上，quorum是在具有竞争关系的关键时刻时一个多数成员达成的一致意见，从而得出最好的解决方案。这里可以理解为多数人达成一致的意见的一种机制，或者达成一致意见的这些多数成员。组成可被接收的quorum的实际数量在不同的情况下也不同。或许要求2/3，或许只要超过50％即可。 在分布式计算机系统中，一组有通讯关系的进程由quorum的潜在成员组成。为保证系统有效运行以及对系统行为作出关键决策，该组进程通过交互信息以在一些关键问题上达成一致，直到quorum的最终形成。 在Sun Cluster中，有两种类型的quorum被使用： 群集成员关系监视器CMM（Cluster Membership Monitor）需要获取关于一组群集节点列表的quorum，这些节点具有成为Cluster成员的能力。编者注：这个意思就是CMM需要在具有Cluster节点关系的一组节点中得到一个多数人的同意。所以quorum：“多数人的同意”中的这个“人”的主体并不具体代表是什么东西，仅仅是表明这些东西形成多数同意的关系，那这里肯定是指节点了。这种类型的quorum被称为CMM quorum，或Cluster quorum。 Cluster配置数据库CCD（Cluster Configuration Database）需要获得quorum，以挑选出一个有效一致的CCD拷贝。这里的主体就是CCD了。 4.1 CMM quorum Cluster2.2中，如果使用SSVM或CVM，quorum由Cluster的框架软件决定，如果使用disksuite作为卷管理器，则quorum由disksuite来决定。 CMM quorum这样被决定： ? 如果使用SSVM和CVM作为卷管理器，quorum是在多个具有投票权利的节点和其他的中性设备上达成的多数通过意见。在两节点中，为了产生quorum，一个quorum device提供一个投票的第三方。注意：quorum device和quorum是两个概念。quorum device的概念在后面讲到。 ? 用disksuite作为卷管理器，就不讨论了。 当节点加入、离开Cluster时和Cluster之间的私网连接失败的情况下形成quorum是非常必要的。Cluster2.x努力达到在不要人为干预的情况下，既保证了数据的完整性，也维系Cluster的可用性，所以就使用到了quorum device。在多节点中，甚至用到了TC。Cluster 2.2在Cluster心跳连接失败的情况下决定quorum时，卷管理器起到了主要的因素作用。心跳失败的具体情况请参见后面quorum device章节内容。 4.2 CCD quorum 群集配置数据库CCD（Cluster Configuration Database）需要获得quorum，以挑选出一个有效一致的CCD拷贝。有关CCD的内容参考后面的相关章节。 CCD中保存了Cluster的配置信息。CCD在每个Cluster节点上都有一个，正常情况下，各节点的CCD间应该是保持同步的。CCD间的通信通过私网连接。但由于故障后，可能会导致各CCD不能报错同步，这时就需要用到CCD quorum了。 一个有效的CCD在故障恢复后必须被决定出来，如果一个有效的CCD不能够被决定出来，所有对于CCD的查询和更新操作随着一个CCD错误的告警而失败。 在决定有效CCD拷贝之前需要启动所有节点是一个非常受限制的条件。可以通过对更新操作作一个强制限制来使该限制放松。 如果n是当前Cluster中配置的节点数，对于Cluster重启时，有ceiling（n）个同样的拷贝就足以选出一个有效的CCD拷贝。当n为奇数时，ceiling（n）＝（n＋1）/2；当n为偶数时，ceiling（n）＝（n/2）。对于一个节点，拷贝数为1个时足够；对于2个节点时，1个拷贝足够；对于3个节点时，2个拷贝足够；对于4个节点，2个拷贝足够。所以该ceiling（n）可以理解为大于等于n的一半的最大整数。有效的CCD将被知会到所有没有最新CCD的节点中去。注意：即使CCD是无效的，一个节点依旧被允许加入到Cluster中。但是，在这种情况下，CCD既不能被更新也不能被查询（检验：一个节点启动时，是否有查询CCD的打印消息）。这就意味着所有依赖CCD的Cluster的组件处于功能失常状态。特别的，在这种情况下，逻辑主机不能被掌控，Data Service不能被激活。仅仅当有足够数量的节点加入到Cluster中能够得到一个quorum时，CCD才处于有效状态。 当至少有一个或更多的节点在CCD重配置过程中处于“清醒”状态时，CCD的quorum问题能够被避免。既然这样，这些节点中任意一个节点的有效拷贝将被知会到最近加入Cluster的节点，另一个可供选择的是确保Cluster在具有最新CCD拷贝的节点上启动。然而，恰好在CCD更新过程中，系统崩溃了，在这之后，很有可能的是系统的恢复算法找到一个不一致的CCD拷贝。在这种情况下，系统管理员的就需要用ccdadm带一些参数去重新恢复CCD。CCD也提供检查点操作的工具去备份目前CCD当前的内容。在系统配置有了任何变化以后，对CCD作一个备份是一个非常好的习惯，这个拷贝可能在以后的恢复中有用。CCD的规模和常见的关系型数据库比较起来非常小，备份和恢复只需要几秒钟。 在双机的情况下，推荐先启动具有最新CCD的节点，然后再启动另外一个节点，最新的CCD会被拷贝到另外一个节点上，这样可以大大减少CCD quorum的机会，以及由此引起的故障。 4.3 quorum device 在特定情况下，例如两节点的Cluster中，当节点间的私网连接失败，且节点们仍然是Cluster中的成员。Sun Cluster需要在一个物理设备的帮助下来解决CMM quorum的问题，这个物理设备就是quorum device。 quorum device仅仅是一个在安装过程中指定的磁盘或控制器。quorum device是一个逻辑概念，一个硬件被指定为quorum device与否对于其使用上并没有任何影响。Sun 的官方资料中，SSVM不允许一个磁盘的分区（如c1t1d1s5）作为一个独立的DG－disk group（但实际上可以实现），所以一个完整的磁盘和它的丛（镜像）被要求用作quorum device。 quorum device确保在任何一个时间点，仅仅只能有一个节点可以更新共享磁盘。如果双机间的心跳信号丢失，就无法确保由那个节点访问共享磁盘了，这时就需要用到quorum device。每个节点只有在能够确定它是多数意见quorum中的一员时，才会去试图更新共享磁盘数据。节点们进行一个投票，或quorum，去决定哪些节点留在Cluster中。每一个节点都要确定它能和多少节点进行通信（当然是通过私网连接）。如果它能够和Cluster中超过一半的节点通信，他就成为quorum的一员，并且被同意继续保留Cluster成员的身份。如果不能称为quorum中的一员，则自动退出。 quorum device则作为一个第三方投票去防止投票平局的出现。例如在双机中的心跳信号丢失，每个节点都要去争取quorum device的支持。这样，争取到quorum device的节点和没有争取到quorum device节点的得票数就是2:1，成为quorum中的一员的节点掌控了共享磁盘后，重新启动它的Cluster，而另外一个节点则退出（这种情况下，Cluster中只有一个成员，但Cluster依然存在）。 实际上，在每一个Cluster重新配置（注意，这个配置不是安装时的配置，而是如Cluster中有某个成员加入、退出或逻辑机切换等操作，我们都称为Cluster需要重配置）之前，一组节点和quorum device都会进行一次投票，以确定得到一个新的系统配置。只有quorum成功了，重新配置进程才会进行。Cluster重新配置成功后，仅仅是quorum中的一员的节点才会继续留在Cluster中。 quorum device的失败类似于两节点Cluster中的一个节点失败的情况。虽然quorum device的失败并不会导致服务的切换，但它确实会降低HA的性能，因为系统将不再冗余将来心跳失败的故障。 一个失败的quorum device能够在Cluster处于运行过程中被重配置或更换。在此过程中，只要没有其他部件发生故障，Cluster将保持正常运行状态。 如果双机间心跳信号丢失，两个节点都会试图启动Cluster重配置流程，使自己成为Cluster中唯一一个节点（因为双机均相互失去心跳）。第一个成功保留住quorum device的配置的节点新成只有自己的单节点的群集，而另一个不能保留住quorum device的节点退出。 如果心跳信号还没有恢复，就试图启动一个已经退出的节点上，这个已退出的节点（仍然不能够和Cluster中的节点通信）试图预约quorum device，因为他认为自己才是Cluster中的成员。这个尝试将会失败，因为对quorum的约定权被令外一个节点所保持。这个措施能有效地阻止该节点形成另外一个Cluster。 4.4 逻辑机 在HA的配置中，Cluster支持逻辑机的概念。一个逻辑机是可以在物理节点间作为一个单元移动的一组资源。在Sun Cluster中，这组资源包括一组网络主机名和与之相关的IP地址，加上一个或多个磁盘组。 在Sun Cluster中，一个IP地址被分配给一个逻辑机，并临时与服务器应用运行的主机捆绑。这个IP地址是浮动的，即，它能够从一个节点移到另外一个节点。在Cluster中，客户端程序通过指定访问逻辑机的浮动IP地址访问，而不是访问其固定IP地址。 如图4-1(原图略)，逻辑主机hahost1包括网络主机名hahosts1，浮动IP地址192.9.200.1和磁盘组diskgroup1。逻辑主机名和磁盘组的名字可以不相同。 编者注：可以简单认为，逻辑机＝逻辑主机名＋浮动IP地址＋与之相联系的磁盘组。 图4-1(原图略) 逻辑机hahost1 逻辑主机被物理主机所掌控。仅仅当掌控了逻辑主机后，该物理主机才可以访问逻辑主机的磁盘组。一个物理主机可以掌控多个逻辑主机，但每一个逻辑主机同时仅仅能被一个物理主机掌控。任何一个有能力掌控逻辑主机的物理主机都被称为“潜在掌控者”。 一个Data Service通过公告一个众所周知的逻辑主机名使得网络上的客户端可以访问其服务。 图4-2(原图略)显示了一个多重Data Service位于一个逻辑主机磁盘中。在这个例子中，假设逻辑主机hahosts2当前被物理主机phys-hahost2所掌控。如果物理主机phys-hahost2失败了，所有的Data Service均会被切换到phys-hahost1上。 图4-2(原图略) 逻辑主机和Data Service 后文将会描述到如何在一个逻辑机上配置Data Service。 可以看出，逻辑主机和Data Service的区别有： 逻辑主机具有主机的一切特性，是提供Data Service的基础。如果没有Data Service，逻辑主机照样可以存在。 Data Service重点突出提供一种数据“服务”，而且在Sun当中，它多次提到Data Service必须位于共享磁盘中，目的是为了HA。它一定要通过逻辑机的浮动IP来表现出来，即通过这个浮动IP对外提供服务。尽管它本意上并不突出IP的概念。 在一个逻辑机上可以提供多个Data Service。一旦该逻辑机失败，该逻辑机上的所有Data Service都进行切换。所以如果不希望某个Data Service失败导致逻辑机切换，同时影响到了同逻辑机中其他Data Service的HA，可以考虑单独为这个Data Service建立一个逻辑机。 因为逻辑机同一时刻只能由一个物理主机掌控，相应Data Service也同时只能由一个物理主机提供，而不能由多个物理主机同时提供。 4.5 挂接信息 /etc/vfstab文件包括了本地文件系统的挂接信息。对于逻辑机使用的一个多主机文件系统，所有可能掌控该逻辑机的节点都应当保存该文件系统的挂接信息。 逻辑机的文件系统的挂接信息在每个节点上保存在一个单独的文件中，该文件名为/etc/opt/SUNWCluster/conf/hanfs/vfstab.logichost（即每个逻辑机都对应一个以其名字为后缀的vfstab文件）。该文件的格式和/etc/vfstab的格式是一致的，所以尽管有些域不用，还是非常容易维护的。 同一个文件系统不能同时被挂接在多个节点上，因为只有该文件系统对应的dg被该节点import后，该文件系统才能被挂接在这个节点上。 4.6 Public Network Management（PNM） 一些失败导致在一个节点上所有的逻辑主机都迁移到另一个节点上。但单个网卡和公网之间的线缆失败不会导致节点失败切换。公网管理器（PNM）软件（处于Sun Cluster框架软件中）允许网卡们可以被组成不同的组，一旦组中一个网卡失败了，组中的其他网卡可以接替网络所需的服务。在侦听到失败和在切换的过程中，用户的访问仅仅感觉到一点迟疑而已。 在一个使用PNM的配置中，有多个网卡处于同一个子网中。这些网卡被组成一个“后援组”。在任何时候，一个网卡必须位于一个后援组中，而且在一个后援组中只能有一个网卡处于激活状态（注意，这仅仅是指公网，对于私网网卡，没有这个限制）。当这个激活的公网网卡失败后，PNM软件自动切换网络服务到后援组中的另一块网卡上。所有位于公网的网卡必须处于后援组中。 图4-3(原图略)表示hme0、hme1和hme2组成了一个后援组，其中hme0处于激活状态。 注意：即使不出现同一个节点的网卡间失败切换，后援组也被用于监控公网状态。 图4-3 网卡失败切换配置 4.7 系统失败切换 HA中，一个节点失败，这个节点上运行的Data Service自动转移到另一个节点上继续运行。失败切换软件把逻辑主机的浮动IP从失败节点切换到后备节点。失败节点上的所有运行在逻辑机上的Data Service自动被移除。 系统管理员可以手动切换一个逻辑机。失败导致的切换和手动切换的区别是前者是当一个节点失败时，自动由Sun Cluster软件自动处理，而后者是由系统管理员手动处理。如果作定期的系统维护或升级软件时，可能会用到手动切换。 图4-4表示了一个普通的双机配置。其中，每一个物理主机掌控了一个逻辑主机（如粗线所示）。两个客户端分别访问两个逻辑机上的Data Service。 图4-4(原图略) 切换前的对称配置 如果phys-hahosts1失败了，逻辑主机hahost1将被转移到phys-hahost2上。逻辑主机hahost1浮动IP也将移到phys-hahost2，所访问的Data Service被重定向到phys-hahost2。在Cluster重新配置过程中，访问hahost1的客户端仅仅会感觉到服务一个短暂的延迟，新的配置如图4-5所示。注意，虽然逻辑主机hahost1已经变换了物理主机，但客户感觉到所访问的同一个逻辑主机并没有发生任何变化。而这一些都是由Cluster软件自动完成的。由于phys-hahost2现在掌控了两个逻辑主机，所以相联系的所有共享磁盘都仅能被phys-hahost2访问了。 图4-5(原图略) 失败切换或手动切换后的不对称配置 4.8 部分失败切换 如果一个物理主机上掌控多个逻辑主机，允许各个逻辑主机单独地切换到后备节点上，而互相不影响。例如，物理主机上有3个逻辑主机，而可能只有其中一个逻辑主机切换到后备节点，而并不影响到其他的逻辑主机继续保留在原物理主机上。 4.9 总结 根据应用的需求，运行在双机上的一个或多个用户进程组织在一起构成一个或多个Data Service。系统监视每个Data Service的执行和每个节点的运行状况，在一个节点出现故障时，根据需要将在此节点上运行的Data Service转移到另一个节点上去运行，以避免应用的长时间中断。 可以看出，Sun双机系统提供软件和硬件的侦测、系统管理、系统的切换和故障发生时Data Service的自动重起。目的只有一个，就是竭力避免系统所提供服务的中断。 在理解双机系统的基本工作原理要明确以下几点： 1. 每个节点都是独立的服务器系统。 每个节点拥有自己的SPU、网络接口卡、磁盘等。它可以不依赖于其他系统而独立工作。 2. 双机系统间的切换应该对外界是透明的。 也就是说，用户应该感觉不到所使用的服务从一个节点上迁移到了另一个节点上，尽管在迁移的过程中，服务有可能发生短暂的中断。 为了达到这一个目的，设置了浮动IP地址。 3. 节点间的切换应该是自动完成的。 节点间的切换是在双机软件的根据故障情况而自动完成的，不应该进行人为干预。