“小公司，别折腾什么集群了。。” –by 兔大侠
“集群就意味用高额的软硬件投入换来高可靠性”。随便到网上一搜，基本上都是这样的观点。很多系统管理员也理所当然的将集群等同于高可靠性。我一直以来也是这样被洗脑了，直到某个周日的夜里碰到一个严重的集群问题才让我清醒一些。那次差点就酿成核心数据的灾难性事故，也差点让我心脏崩溃。
出现问题的集群是几年前搭建的，硬件基于两台IBM x346服务器（不好用，没法装esx）和一个光纤盘柜。软件平台基于RedHat AS4 + RedHat Cluster Suite，服务为Oracle 10g服务。数据库及核心文件均保存在盘柜上，盘柜上的文件系统格式为GFS。
所谓祸不单行。两台服务器中的一台出现硬盘问题宕机了，而处于active状态的另一台服务器上的Oracle服务也出现了异常，需要重启服务器系统。在正常关闭服务后，系统重新启动了后，可怕的事情发生了：盘阵上的gfs文件系统挂载不上了！！疯狂的查资料得知，启动gfs的前提是正常启动fenced服务。可是无论如何那个fenced的服务就是没法启动。
再疯查资料得知，fenced启动的条件竟然是集群中的节点(Node)数在“法定人数（Quorate）”，即多数节点能正常响应的情况。比如由四个节点组成的集群，只有三个以上节点正常，才能正常启动集群服务。如果集群里只有两个节点，按照西方人选举的规则，是无法定义“多数”的。这就意味这两个节点构成的集群，如果其中的一台宕机了，这时候再重启另一个节点，那集群是无法启动了。建立在集群基础上的gfs文件系统，也就无法挂载了。
知道了这个因果关系，我彻底晕了。集群竟然自己给自己下了个套。这么昂贵的软硬件投入，竟然无法满足让我在集群停止后，把盘柜中的文件系统挂载到linux下来快速做一次全备份这样一个最单纯的需要。当然，不排除靠一些高级命令，硬把gfs盘挂上去。搜了很久，没找到这样的命令。估计购买了redhat的技术支持，也许能获取这样的帮助吧。
看来，能够挂载盘柜的前提就是使两个节点都恢复正常。然而，短时间内重新搭建一个4、5年前别人搭建、细节不详的集群节点，对我来说是不现实的。幸运的是，两台集群用的服务器硬件配置是完全一样的，而且硬盘本省没有坏。 我能立刻想到的就是将正常的服务器的RedHat克隆到宕机的那台服务器上。网上找了一个G4L，火速让同事刻成启动光盘。由于服务器是做的两块硬盘Raid镜像，我就采取对每块硬盘进行完全克隆的方式，逐一导出到一个移动硬盘上，然后再导入到另一台服务器上。不知道是正常还是不正常，整个过程竟然用了接近3个小时。一直到凌晨一点多钟，才将克隆的硬盘镜像完全导入。
接下来的事情完全是老天在帮忙了。原来宕机的那台，居然开机能够正常启动了。启动过程中间Linux发现网卡及Raid卡发生变化，选择接受自动修改。然后修改IP地址、修改主机名、测试网络。尝试启动ccsd，及cman服务，发现它们都正常启动了。
隐约开始觉得出现转机。登录到原来active的那一台，惊喜的发现fenced服务能启动了。把cluster相关的几个服务启动后，我看到了久违的gfs被挂载了。所有的数据安然无恙，oracle服务也正常启动了。差点喜极而泣。。
凌晨3点多，拖着疲惫的身心坐在回家的出租车上，我没有丝毫的成就感，只有被集群愚弄的挫败感。
显然我对集群还是没有吃透。但是我觉得传统的集群有诸多的弊端：
-
如果gfs文件系统的前提是正常启动集群，那对脱机数据备份和恢复都是一个巨大的困难。
-
一般集群刚装好的初期，所有服务器的系统配置都是一样的。但是时间长了，管理员难免在长期active的那台服务器上做些改动。如果忘了在其它服务器上做相同的改动，那么系统的差异化越来越大。
-
即使有多台服务器做集群，是高可用性的，但是后面的共享盘阵，仍是一个巨大的单点风险。常规的数据备份还是一个都不能省，不会因为集群而减少工作量。
-
集群的节点切换的触发条件过于简单化。基本上是要出现主节点宕机，断网，心跳线或心跳盘异常等极端条件下，才会切换。像集群控制的服务变得缓慢、拥堵这些细小事件，并不能导致节点切换。而这些小的事件，恰恰影响前台的Web服务的正常运行，况且发生的概率也远大于节点宕机或断网这类情况。
-
巨大的资源浪费，还要加上复杂化的管理成本，以及学习成本，这些成本对于获得的所谓的高可用性，性价比如何，恐怕要严重依赖于公司和IT系统的规模了。
这次碰到的问题，花了近10个小时。如果没有集群，依靠备份来重新恢复一套数据库系统，也就是两个小时。如果采用虚拟机备份和恢复，应该在一个小时以内。兔哥想说，对中小公司来说，集群其实就是个传说。。。