VCS中coordinator disk的问题
看到资料上说VCS5.1的coordinator disk必须超过半数才能把集群拉起来。那比如说我有两个阵列，业务数据在这两个阵列之间做volume镜像。阵列A有2个coordinator disk，阵列B上只有1个coordinator disk，如果发生故障导致VCS的所有节点和阵列A都宕掉，节点重启后能否通过阵列B来拉起集群？需要什么其他操作么？刚开始学VCS，不知道是否把我的问题表述清楚了？ 没用过这么高深的玩意儿 出现这种情况,fence这个服务在没有人工干预的情况下一定是起不来,这也意味VCS也一定不能正常启动或者启动资源.如果是我处理这种故障,如果阵列A也暂时无法修复,我会直接在阵列B上建3个coordinator disk先保证fencing能正常工作.
不过阵列B起不来,VCS的服务组中如果有一个牵扯到阵列B的资源就会导致整个服务组也起不来,相应的修改还是会很多的. 出现这种情况,fence这个服务在没有人工干预的情况下一定是起不来,这也意味VCS也一定不能正常启动或者启动资 ...
fenglimian 发表于 2010-10-29 10:34 http://bbs.chinaunix.net/images/common/back.gif
其实场景是这样的：
AB双中心各有1套存储，就叫AB存储好了。A中心有1套VCS，共享存储用了AB这两套存储，通过VxVM volume mirror在AB间实现容灾。B中心部署了1套VCS，但是平时不起来。如果A中心宕掉了，B中心的VCS起来后接管B存储，因为做了VxVM volume mirror，所以业务数据应该不丢失。不过现在有这几个问题：
1，coordinator disks
因为要获得超过半数的coordinator disks才能启动集群。手册上建议的方法是三个中心ABC，其中C中心就是放套小存储。3个coordinator disks放在这3个存储上，不过对我们来说不现实。我想到的可能的解决办法有：
a，在B中心上绕过coordinator disks，强行将VCS拉起来
b，在AB中各部署一套CP Server，AB存储各1个coordinator disks。AB两中心用2个coordinator disks加上自己的CP Server。但是如果CP Server一定要属于VCS的话，这个就又不可行了。
c，A中心有3个coordinator disks，修改B中心VCS的配置，使得它不用IO Fencing
d，AB中心各有3个coordinator disks，并且AB两中心的VCS都用各自的coordinator disks。但这样的话B中心在接管时会发现coordinator disks上没有reserve，但是data disks上有reserve，会不会报错？是否需要预先手工清除data disk上的reserve？
2，从问题1引申来的，如果1个VxVM dg被VCS-A使用了，那么VCS-A宕掉后，能否继续被VCS-B使用？
我的想法是将VCS-A中的所有节点做系统备份，然后到VCS-B恢复。那么应该能欺骗VxVM，让它这两套VCS应该是相同的。
ps 原来还有个想法，就是只建立1套VCS，包括AB中心的4个节点。但是觉得这样就更复杂了，例如一旦AB链路断掉导致split-brain。所以还是优先考虑2套VCS的方案，不过仍然觉得很麻烦 如果B中心平时VCS都不启动,处理起来就只有你说的方案d了,两个中心的VCS各自在各自管理的存储上建立好3个coordinator disk,这种情况下是需要清reservation的,不过这个好处理.
此外cps我没有做过,但是这个是和disk 的i/o fencing应该是独立的另一种机制,好像不可以结合起来组成3个数量这样做, 找机会我可以试试这个东西.
至于symantec文档所说的建立第三个中心的问题,其实和你说的不一样,它的两个中心是需要同时启动的.我没有想到在AIX下面怎么处理coordinator disk的问题,在别的平台上面随便找个iscsi的target,做成独立于前两个中心的独立电源/网络环境的一个lun出来就可以了.而且symantec所说的是那种两个中心.
对问题2，因为所有的软件binary都装在各自的机器上,应用的数据会存放在共享的盘阵,保护好盘阵的数据后,是在没有什么备份的必要,对VCS来说就那些.cf文件需要保护好,以免下次还需要重新配置.VCS的fencing,llt,gab什么的都是独立的,而且基本配置好后不会人工修改也不会变.即便磁盘设备文件名变了,比如宕机后原来的disk1变成名字disk100，对VCS来说都不关心,VCS只管向VxVM要原来的DG名字,VxVM会去读磁盘的私有区去重新导入DG的.按照你的那种情况,你就只需要把a的main.cf拷贝过去,修改一下配置文件里面的主机名,网卡名就好了.
按道理建立一套VCS是比较好的,每个站点各有两个节点,这样某个站点出现问题时能做到自动切换,不过我实在没想到AIX下面怎么弄第3个coordinator disk,对CPS我又还没有弄过,提不出什么建议. 呵呵，问题比较多，我对VCS又不熟悉，可能有些条理不清。
1，听从你的建议，优先测试方案d。如果能搞通的话剩余方案就可以少放些精力了，还要搞其他的东西
2，从install guide上看到cps和coordinator disk可以一起配置的。都作为coordinator point，让node来抢。刚刚又看了guide，cps可以独立于vcs存在。本来我觉得这个方案最有希望，可是还要多维护台机器，这个是第二考虑的方案
3，三中心的问题。我的理解是这样的，如果只有两个中心的话，那肯定有一个中心至少有2个coordinator disk。一旦这个中心宕了，另外一个中心的VCS要起来的话，因为coordinator disk数量不到一半，就会起不来。这就是我最早的问题，如果只有1个coordinator disk，能否强行起VCS？
4，对于用系统备份来构建新节点这个问题，我是这么考虑的。系统层面的软件以及配置文件都好处理。但是当节点在coordinator disk上注册key时，这个key是否会包括某些特定于节点的信息？比如VCS为每个节点生成内部的uid，保存在某个不知名的配置文件中，用这个uid来注册key。如果是这样的话，那么在B中心新建VCS的话节点的uid肯定和原来不同，这种情况下B中心的VCS是否还能拉起B存储上的coordinator disk？更进一步考虑，如果注册的key中用了机器序列号，那该怎么处理？是否和方案d类似，首先清除reserve？
5，建立一套VCS的话，担心太自动了不好控制，客户也不想自动切换。想法是一旦主中心宕了，首先尝试修复，如果在规定时间内不能修复的话再切换。而且切换前预先准备好脚本，减少人工误操作的风险。 刚刚看到key的格式，coordinator point中包括cluster id和system id，data disk中只有system id。那这个问题应该好处理了。 呵呵,没有弄过CPS,等处理了手头的事情先试试看.
所有文档提到的双中心都是默认两个站点同时启动这种情况,这个时候其实VCS是都已经启动起来了,不存在说coordinator disk数量不足无法启动的事情. 如果两个中心的VCS还需要单独启动,就基本可以把它们看成没有关联的两套系统了,差不过就是把盘阵从一个机房换到另一个机房这种事情了.
按照我碰到的情况和看到的文档,没有3个coordiniator disk情况下fencing都起不来,对coordinaotr DG来说,重建一个太简单了,大不了重新创建一个这样的DG就行了.
对key的问题,其实VCS就是使用的SCSI 3的PR那套机制,这个最好处理了,vxfenadm就能清理这些key,呵呵,顶多两条命令,只要盘阵的firmware满足scsi3标准,key就都消失了. 呵呵,没有弄过CPS,等处理了手头的事情先试试看.
所有文档提到的双中心都是默认两个站点同时启动这种情况 ...
fenglimian 发表于 2010-10-29 15:14 http://bbs.chinaunix.net/images/common/back.gif
呵呵，客户的要求是在A中心宕掉的情况下，通过手工操作在B中心上恢复业务。
所以我的想法其实就是建立2套没啥关系的独立的VCS，在第一套VCS不可用的情况由人工控制启动第二套VCS。不过这涉及到VxVM在2套VCS之间的转移，现在就是要找一套有效的方法来实现这个。不过我对此不确定，这就是我上面这些杂七杂八问题的来源了。 呵呵,问题的根源不在VCS, 根源在VxVM怎样处理你说的那些mirror的volume,你可能要关心一下怎样保证两个站点之间数据的一致,你说的需求里面对VCS来说没有什么特别的要求.
页:
[1]
2