Chinaunix

标题: 我的RHEL 3 HA cluster的两个节点都挂载了共享存储 [打印本页]

作者: chenyajun5 时间: 2005-12-15 10:16
标题: 我的RHEL 3 HA cluster的两个节点都挂载了共享存储
我在vmware中使用redhat 3 的clustermanager 来做2节点ha cluster。两节点的外部地址分别是172.16.1.130(cluster3)和172.16.1.140(cluster4)，心跳地址分别是10.0.0.130和10.0.0.140，开机后使用clustat发现两个都挂载了共享存储。。这应该不正常啊。
在cluster3上，使用clustat -i 5，看到

Cluster Status - Red Hat Clumanager Cluster                         10:15:26
Cluster Quorum Incarnation #9
Shared State: Shared Raw Device Driver v1.2

  Member          Status
  ------------------ ----------
  172.16.1.130    Active    <-- You are here
  172.16.1.140    Active

  Service       Status Owner (Last)    Last Transition Chk Restarts
  -------------- -------- ---------------- --------------- --- --------
  httpd       started  172.16.1.130    10:12:47 Dec 15 2       0
在cluster4上，我看到
Cluster Status - Red Hat Clumanager Cluster                         10:18:57
Cluster Quorum Incarnation #9
Shared State: Shared Raw Device Driver v1.2

  Member          Status
  ------------------ ----------
  172.16.1.130    Active
  172.16.1.140    Active    <-- You are here

  Service       Status Owner (Last)    Last Transition Chk Restarts
  -------------- -------- ---------------- --------------- --- --------
  httpd       started  172.16.1.140    09:58:44 Dec 15 2       0
cluster3是最近一次切换的，外部httpd请求，此时响应的是cluster3。应该两个节点服务的owner一致啊，为什么会不一致呢？？

作者: nntp 时间: 2005-12-15 12:50

原帖由 chenyajun5 于 2005-12-15 10:16 发表
我在vmware中使用redhat 3 的clustermanager 来做2节点ha cluster。两节点的外部地址分别是172.16.1.130(cluster3)和172.16.1.140(cluster4)，心跳地址分别是10.0.0.130和10.0.0.140，开机后使用clustat发现两个都 ...

disable掉httpd服务，然后就是单独看cluster service的状态.

集群启动后，察看你的shared storage的状态，如果2个node都mount上了，配置就有问题了.

作者: chenyajun5 时间: 2005-12-15 13:16
很奇怪的是有时候每个节点的clustat 命令显示的httpd owner是相同的，有时候又不同。
把两个节点的httpd都disable以后，两个节点都没有挂载共享存储。
在cluster3上，
Cluster Status - Red Hat Clumanager Cluster                         13:21:36
Cluster Quorum Incarnation #18
Shared State: Shared Raw Device Driver v1.2

  Member          Status
  ------------------ ----------
  172.16.1.130    Active    <-- You are here
  172.16.1.140    Active

  Service       Status Owner (Last)    Last Transition Chk Restarts
  -------------- -------- ---------------- --------------- --- --------
  httpd       disabled (172.16.1.130) 13:18:34 Dec 15 2       0

在cluster4上，
Cluster Status - Red Hat Clumanager Cluster                         13:22:10
Cluster Quorum Incarnation #18
Shared State: Shared Raw Device Driver v1.2

  Member          Status
  ------------------ ----------
  172.16.1.130    Active
  172.16.1.140    Active    <-- You are here

  Service       Status Owner (Last)    Last Transition Chk Restarts
  -------------- -------- ---------------- --------------- --- --------
  httpd       disabled (172.16.1.140) 13:18:22 Dec 15 2       0
重新enable以后两个节点又挂上去了。

[ 本帖最后由 chenyajun5 于 2005-12-15 13:21 编辑 ]

作者: chenyajun5 时间: 2005-12-15 13:21
我的是两个节点的，是不是我cluquorumd有问题。我不明白Disk Tiebreaker和 network TieBreaker有啥区别，好像两节点的ha cluster需要使用network TieBreaker，那么那个ip该怎么设置呢？

作者: lky 时间: 2005-12-15 15:19
2个节点都把共享盘mount上了，这是最可怕啊，做双机最怕这个。同时mount上共享分区，数据基本就毁了。
network TieBreaker 设定的IP地址最好是网络中永远不会down的IP地址，如双核心交换机的vrrp虚拟地址等。

作者: suran007 时间: 2005-12-15 15:28
楼柱说是在vmware中做的实验，那共享存储是怎么做的，我估计就是quorum分区的问题，要是改用实际设备就不会有上面的问题

作者: chenyajun5 时间: 2005-12-15 16:25
谢谢大家。。我是采用七月飞雪的那个文章啊，给两个机器分配一块共享硬盘，

作者: nntp 时间: 2005-12-16 04:52

原帖由 chenyajun5 于 2005-12-15 13:21 发表
我的是两个节点的，是不是我cluquorumd有问题。我不明白Disk Tiebreaker和 network TieBreaker有啥区别，好像两节点的ha cluster需要使用network TieBreaker，那么那个ip该怎么设置呢？

你的问题实际上回答了很多其他急冲冲要装RHCS的人的问题.

我一直说不管RHCS还是 linux-ha 也好，采用的都是不太可靠的 Tiebreaking机制. 为什么RHCS v4你们看到了 PowerSwitch? 其实powerswitch从RHCS v2.1的时候就存在了，只不过在系统配置中一直保留不用而已. 5年前我研究Kimberlite 的时候就发现实际上，如果在2个node的HA集群环境中，如果发生heartbeat出现故障，互相不知对方节点状态的情况下，按照竞选机制，每一个node都要重新以自己为主建立一个新的集群，但是只有50%的票选，在这个时候，所有原本有序控制的共享资源，比如存储，漂移IP之类的，全部会被竞抢，出现了所谓的brain-split. Kimberlite很早就看到了这个问题，和我们熟悉的linux-ha.org的项目一样，因为自身架构上带来的缺陷，只能通过2个手段来尽可能减少这种问题，一个手段就是linux-ha.org很有代表性的heartbeat 子项目，这也是linux-ha.org把heartbeat放在了一个很主要地位的原因，另外一个有代表性的手段就是kimberlite的powerswitch. 市面上其他的低端linux HA产品，比如rose ha之类的产品，在解决brainsplit的道路上，无外乎采用了这两种手段之一。

发生brainsplit的时候, kimberlite 就通过一个后台service, 强行控制一个node的powerswitch 然后poweroff一个node, 即便这个node reboot之后，也不会正常启动cluster service, 这样就保证了出现 50-50的资源竞抢的时候，可以保护共享资源，并且让一个优先节点来重组cluster.

network tiebreaker 是很多高端ha系统广泛采用的方法，通过把一个仲裁单位放在网络的一个设备上(pc, pc server, server, network device)，出现50-50的竞抢之后，让网络上的这个设备来投票参与竞抢，2对1的选择的结果永远不会出现50-50的brain-split.所以也比较可靠。

另外一种稍微差一点的做法是用Quorum LUN/disk, 一般用LUN的会多一点，这样quorum不会出现单点故障. 微软的MSCS用的就是这种方法。相对前面的network tiebreak来说 lun/disk tierbreaker成本相对比较低，可靠性也比较差.

你的这个httpd的问题，我觉得首先要做的就是你要仔细阅读手册，不要有遗漏。第二个是要严格检查httpd service的配置. 不要有任何违反系统要求的配置项存在。看我置顶的帖子，我认为大部分的看似奇怪的问题，都是因为配置和环境与程序本身的要求不一致造成的。软件本身的缺陷也是要考虑的因素之一。

作者: chenyajun5 时间: 2005-12-16 09:24
多谢版主解答。。如果使用network tiebreaker，需要什么要求呢？我能随便指定一个IP么？比如我局域网的网关，是不是需要在专门的网络设备上安装特定的软件来实现？。

作者: q1208c 时间: 2005-12-16 19:22

原帖由 chenyajun5 于 2005-12-15 10:16 发表
我在vmware中使用redhat 3 的clustermanager 来做2节点ha cluster。两节点的外部地址分别是172.16.1.130(cluster3)和172.16.1.140(cluster4)，心跳地址分别是10.0.0.130和10.0.0.140，开机后使用clustat发现两个都 ...

不用看后面我就知道, 你的心跳好象没用上, 不信你 disable 一下其中一个网卡试试.

作者: chenyajun5 时间: 2005-12-16 21:49
disable一个机器的网卡，它自己重启了。。重启后我恢复网卡，两个又挂上去了，晕。。

[ 本帖最后由 chenyajun5 于 2005-12-16 21:50 编辑 ]

作者: q1208c 时间: 2005-12-16 22:20

原帖由 chenyajun5 于 2005-12-16 21:49 发表
disable一个机器的网卡，它自己重启了。。重启后我恢复网卡，两个又挂上去了，晕。。

你停的是哪个网卡?

另外, 你那 httpd 配了几次?

作者: chenyajun5 时间: 2005-12-17 10:48
我越来越糊涂了。。我把一个机器的两个网卡都停了。。然后它重启，只停止任何一个网卡不会重启。。请教：心跳如何设置？两个机器的心跳地址分别是10.0.0.130和10.0.0.140，外部地址分别是172.16.1.130和172.16.1.140，那么cluster的成员应该是填写心跳地址(10.0.0.XXX)么？
我现在填写的是他们的外部地址
/etc/hosts文件是这样的。。
127.0.0.1    localhost.localdomain          localhost
172.16.1.140 cluster4
172.16.1.130 cluster3
10.0.0.140    cluster4
10.0.0.130    cluster3

我在一个机器上配置好了以后直接将配置文件复制到另外一个机器上。

[ 本帖最后由 chenyajun5 于 2005-12-17 10:50 编辑 ]

作者: q1208c 时间: 2005-12-17 19:23

原帖由 chenyajun5 于 2005-12-17 10:48 发表
我越来越糊涂了。。我把一个机器的两个网卡都停了。。然后它重启，只停止任何一个网卡不会重启。。请教：心跳如何设置？两个机器的心跳地址分别是10.0.0.130和10.0.0.140，外部地址分别是172.16.1.130和172.16.1. ...

应该是写心跳的网卡的.

作者: chenyajun5 时间: 2005-12-17 20:16
好，我再试试。。

作者: jamesb 时间: 2005-12-21 09:10
标题: 回复 8楼 nntp 的帖子
你不太明白 ha的作用，ha是保证集群中不存在任何单点故障。split brain是任何HA软件也无法避免的，这时候只能通过提高心跳的冗余度来减少split brain的存在。而且在split brain发生后也有很多情况可以避免，比如stonith(powerswith就是一种stonith机制)，scsi reserve，hang check timer(watchdog)等。我没有看到heartbeat和rh clumanager在处理split brain的方式上有啥不同，heartbeat好像更弱一些，再者，他也有heartbeat-stonith的包

作者: jamesb 时间: 2005-12-21 09:13
lz的问题在于 vmware里面的share disk不会在两个节点实时同步，没有办法做quorum盘

作者: nntp 时间: 2005-12-21 14:54

原帖由 jamesb 于 2005-12-21 09:10 发表
你不太明白 ha的作用，ha是保证集群中不存在任何单点故障。split brain是任何HA软件也无法避免的，这时候只能通过提高心跳的冗余度来减少split brain的存在。而且在split brain发生后也有很多情况可以避免，比如s ...

请不要一上来就对我对HA的理解作莫名的评价，我仍旧在长期学习HA,只要ha技术不停顿，我想我会一直处于"不明白"的状态。相信大家都是这样的.

我从来没有说过brain split可以避免的，有这种观点的人显然是很可笑的，brain split是HA集群成员在工作的时候发生异常的一种状态.

最简单的方法就是用你说的提高心跳的冗余度来做，nic bonding 基本上是大多数商业集群的要求. 低端得还会要求加上一根null modem线来做tty上的heartbeat.

但是这种架构并不是好的解决之道，quorum lun/disk/server 是另外一种思路来解决问题.

作者: nntp 时间: 2005-12-21 14:58

原帖由 jamesb 于 2005-12-21 09:13 发表
lz的问题在于 vmware里面的share disk不会在两个节点实时同步，没有办法做quorum盘

lz的问题在于采用RHEL 在vmware里面的quorum 状态不正常。这个问题是软件造成的，不是技术固有的问题.

但是linux cluster 做在vmware里面用shared disk 做quroum lun 是一件很简单和平常的事情。如果你听说过SGLX 的话.
我的大多数用户程序的HA环境的移植评估，都是在我的一台pc上完成的, Althon64 3000+, 2GB, 160G SATA raid. SLES9 SP2, vmware GSX3.1, HP MC/SG for linux, oracle toolkit, apache toolkit, mysql toolkit, sap toolkit, nfs toolkit.

作者: jamesb 时间: 2005-12-21 15:02
这里看到的vmware share disk就不正常能够，你在一段写的数据进去，这边需要过一段时间才能看到，不知道你有什么办法解决。

作者: jamesb 时间: 2005-12-21 15:05
标题: 回复 18楼 nntp 的帖子
我一直说不管RHCS还是 linux-ha 也好，采用的都是不太可靠的 Tiebreaking机制.

我是针对你的这句话所说的，你告诉我，什么叫可靠的tiebreaking机制？

作者: nntp 时间: 2005-12-21 15:12

原帖由 jamesb 于 2005-12-21 15:02 发表
这里看到的vmware share disk就不正常能够，你在一段写的数据进去，这边需要过一段时间才能看到，不知道你有什么办法解决。

RHCS还是SGLX?

察看我以往发的帖关于RHCS的态度，我个人是不推荐RHCS的，即便是现在的v4.

我只能精确的告诉你HP的MC/SG for linux的做法.

共享的share disk 做出来后，首先fdisk ，假设你的shared disk 是 sda.
结果类似这样的，下面是我从我的vmware 环境copy出来的

#fdisk /dev/sda
#fdisk -l /dev/sda

Disk /dev/sda: 10.4 GB, 10486579200 bytes
255 heads, 63 sectors/track, 1274 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start    End Blocks Id  System
/dev/sda1          1       1    8001 83  Linux

HP MC/SG要求 quorum LUN 是一个 start 1 end 1的partition.

如果你不用第三个server 做quorum server 来解决brain-split,  Quorum lun/disk 是第二选择.

这个分区不要创建文件系统,也不要创建raw的操作，切出来后直接让MC/SG for linux 的core system来读写。

无论是在真实的多结点(2, 3, 4, 8, 16)还是在vmware里面(2 node, 3 node) 都是这样操作的，看不到类似RHCS之类的sharedisk上quorum的问题.

作者: jamesb 时间: 2005-12-21 15:21
我说的是通常情况，在vmware 里使用同一个文件作为共享磁盘的时候，数据更新不是实时同步的，你可以测试一下。用作共享存储方数据没有问题，但是用作quorum盘就有问题。

作者: nntp 时间: 2005-12-21 15:40

原帖由 jamesb 于 2005-12-21 15:21 发表
我说的是通常情况，在vmware 里使用同一个文件作为共享磁盘的时候，数据更新不是实时同步的，你可以测试一下。用作共享存储方数据没有问题，但是用作quorum盘就有问题。

我说了，这个和cluster software 怎样实现quorum 有关系的.

从微软的Quorum partition里面那个70多MB的quorum file, 到RHCS(也就是kimberlite)的quorum partition,到其他的商业产品的quorum 机制都是不一样的，所以不存在一个"同常"的情况.

如果我们把问题讨论范围定义在RHCS之内，你的看法我一点意见都没有，的确是那样的.而且RHCS从kimberlite老祖宗开始到v2.1 v3.0 v4.0都没有大的改变.

但是如果是横向比较HA cluster , 我觉得你说的是不对的。一个好的HA集群产品，在怎样实现Quorum,怎样实现Quorum lun/disk/server，差别很大.实际使用效果也差别很大.

作者: boycw 时间: 2005-12-21 16:03
楼主的这个情况我也遇到过了，解决方法如下：
1。删除2个节点的/etc/cluster.conf 文件。
2。关闭一个虚拟机，只配置一台机器，配置好群集，根据你的配置，成员应该是换成10.0.0.130和10.0.0.140。
3。你可以把广播心跳和多址传播心跳两者都启用，但是你必须至少启用其中之一。通过频道接合的以太网接口来发送的多址传播心跳提供了较好的容错性能。推荐你使用它来实现可用性。及选择 Enable Broadcast Heartbeating
4。运行 /usr/sbin/shutil -i 来初始化共享贮存区注意这个命令只在一台节点上运行
5。启动另一个虚拟机，复制/etc/cluster.conf 到这个虚拟机。
6。先启动一个节点的clustermanager ，等服务全起来以后，再启动另一个节点的clustermanager 。
这样应该可以正常了

作者: lky 时间: 2005-12-28 09:55

原帖由 jamesb 于 2005-12-21 15:21 发表
我说的是通常情况，在vmware 里使用同一个文件作为共享磁盘的时候，数据更新不是实时同步的，你可以测试一下。用作共享存储方数据没有问题，但是用作quorum盘就有问题。

Vmware Gsx for Linux 我测试的时候也发现共享盘不同步，但GSX for windows 就没有这个问题。而且在Linux 下 scsi1.sharedBus = "virtual" 这句是不能加的，windows 下就可以加，不知道是不是这个原因。

作者: joyhappy 时间: 2005-12-28 12:57
标题: 回复 9楼 chenyajun5 的帖子
实际上，防止split-brain的方式有很多中，在rhes4中，io-fence设备就是这个目的。

通常，当HA的心跳通路全部故障时，如果不借助一些硬件机制，HA基本处于崩溃状态。轻者中断业务，重者破坏数据。实乃HA之死穴。

一般为规避split-brain，牛的商业HA软件采用如下方式解决（如life-keeper, VCS, failsafe）：
1。多种心跳介质：
如串口，网络，共享磁盘等
2。多条通道：
可以同时配置多条通道，一条坏了，可以使用其他的。降低split-brain的概率。
3。quorum（投票机制）
4。iofence
万一发生split-brain，可以通过硬件来防止数据被破坏。
1）STONITH（简单讲就是重启动另一台机器）
powerswith方式（通过串口重启其他机器），需要额外购买一个powerswith的盒子，好像不便宜，所以这种方式市场上真正用的不多；
也有通过网口重启其他机器的。
2）锁方式
scsi reservation，这种方式较好，因为只要有共享的SCSI盘阵即可。但hp的盘阵cciss驱动的好像不支持；

个人认为，rhes4中的HA是用过的HA中最差的，好像是给个人配置玩一玩还可以。同真正的商业的HA软件相比，无论是易用性、可维护性、稳定性都较差。
不过我觉得rh的HA可能会改进得很快，据说有不少HA的牛人被rh挖过去了。

作者: blue_stone 时间: 2005-12-28 23:41
split brain会对系统造成什么样的为害？

如果使用cluster filesystem是否可以避免磁盘不一致的情况？

作者: nntp 时间: 2005-12-29 01:46

原帖由 blue_stone 于 2005-12-28 23:41 发表
split brain会对系统造成什么样的为害？

如果使用cluster filesystem是否可以避免磁盘不一致的情况？

what's your point?

http://www.google.com brain-split

http://www.google.com cluster filesystem

作者: ljhb 时间: 2005-12-29 09:22
标题: 回复 28楼 blue_stone 的帖子
cluster filesystem只是能保证两边写的时候文件系统不会出错，但是并不能保证数据不会出错，比如数据库，在没有并行机制的保证下，两边同时起的话，很可能造成数据破坏

作者: ljhb 时间: 2005-12-29 09:26
标题: 回复 27楼 joyhappy 的帖子
我觉得还是以提高冗余度和增加仲裁机制比较好。使用quorum盘来仲裁有时候会带来共享存储i/o效率降低（老的rh clumanager就有这个问题），另外fence还有很多方式，比如网络，光纤交换机，存储，openimpi这些都可以做。scsi reservation有很多存储不支持，linux下硬件driver这一块缺陷很多。

作者: nntp 时间: 2005-12-29 23:49

原帖由 ljhb 于 2005-12-29 09:26 发表
我觉得还是以提高冗余度和增加仲裁机制比较好。使用quorum盘来仲裁有时候会带来共享存储i/o效率降低（老的rh clumanager就有这个问题），另外fence还有很多方式，比如网络，光纤交换机，存储，openimpi这些都可以 ...

非常同意, MC/SG很久前要是strech到DT/DR的应用范围上，没有lock lun的说法的，移植到linux上，quroum server可以省掉了，用一个lock lun就可以,当然需要shared hardware storage上也许要对locklun有相应的保护.

不过有时候为了管理成本，有时候为了看上去并不呢么高的"可用性要求" 嘿嘿，厂商更加喜欢考虑一种折衷的方案.

作者: lky 时间: 2005-12-30 16:45
标题: MC/SG
HP MC/SG FOR linux 在卖了没有，有没有试用版？

作者: nntp 时间: 2006-01-02 18:55

原帖由 lky 于 2005-12-30 16:45 发表
HP MC/SG FOR linux 在卖了没有，有没有试用版？

卖了很久很久了. trail 版需要和hp sales联系.

作者: lky 时间: 2006-01-02 23:14
标题: 回复 34楼 nntp 的帖子
可以这么说吗？ SLES ＋ HP MC/SG 应该比REHDAT AS + RHCL可可靠性要好很多。

作者: lky 时间: 2006-01-02 23:15

原帖由 nntp 于 2006-1-2 18:55 发表

卖了很久很久了. trail 版需要和hp sales联系.

请问是找卖小机的销售还是PC服务器的？

作者: nntp 时间: 2006-01-03 21:29

原帖由 lky 于 2006-1-2 23:15 发表

请问是找卖小机的销售还是PC服务器的？

如果你是买x86版本的，找pc server 的sales,他们都有订货号的，可以下单. 服务部门的都已经ready了.

如果你准备用IA64(integrity server) + IA64 linux + MC/SG for linux, 直接问小机的sales.

作者: nntp 时间: 2006-01-03 21:35

原帖由 lky 于 2006-1-2 23:14 发表
可以这么说吗？ SLES ＋ HP MC/SG 应该比REHDAT AS + RHCL可可靠性要好很多。

精确的说: 如果你这里有熟悉linux企业级部署的人，无论是用SLES或者RHEL 都应该一样的，这两种发行没有绝对的高低之分，各有特色.

模糊的说: 在默认安装的情况下，不考虑你其他上层应用对两种发行的区别，就HA这点上，我个人推荐 SLES.

实际上基本上在我们工作的高端平台上，大多数HA环境都建议你用SLES, Oracle美国的consulting service部门的人告诉我，Oracle Cosnulting Service 建议linux RAC构建在SLES上. 原因有好多，我就不罗列了.

作者: lky 时间: 2006-01-04 08:48
谢谢了，主要是装过Redhat cluster 感觉不是很好，共享存储被同时挂上去过，数据丢了一次。现在运行看起来还正常，但还是有点怕怕的。共享存储被同时挂上去只在前几年做NT下的rose ha碰到过，后来换MSCS就从来没碰到过，IBM的HACMP也从来不会出这种事情的，就算配置错误也好，共享存储是不可能被2边同时挂上的。

作者: nntp 时间: 2006-01-04 21:55

原帖由 lky 于 2006-1-4 08:48 发表
谢谢了，主要是装过Redhat cluster 感觉不是很好，共享存储被同时挂上去过，数据丢了一次。现在运行看起来还正常，但还是有点怕怕的。共享存储被同时挂上去只在前几年做NT下的rose ha碰到过，后来换MSCS就从来没碰 ...

你可以和深圳的skybility HA联系一下，拿一份评估版在你的测试环境测试一下.

如果你的2个节点的ha 预算在 30k以内，并且保护的是常规应用，我建议 HP MCSG for linux -> Steeleye Lifekeeper -> Skybility -> RHCS

作者: desert969 时间: 2007-12-19 21:54
为什么说：使用quorum盘来仲裁有时候会带来共享存储i/o效率降低?

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)