分享一下VCS 切换测试经验

本测试是在有两条心跳链路，两个节点的cluster情况下测试的。
　　1.首先研究一下怎样测试system down的情况，这是个极端的情况，例如一个节点突然的断电。一般我们在客户环境中不会做这种测试，所以，我找了一些模拟system down的做法。
　　                                      
　　Failover simulation is an important part of configuration testing. Failover can be tested in several ways:

　　1. Removing the power from the cluster node
　　2. Generating a STOP error or blue screen
　　3. Removing ALL connections to the server to be tested. This means removing all cables from network interface cards (NICs) and host bus adapters (fibre or SCSI). Public and private NICs must be removed simultaneously. All fibre or SCSI cables must be removed simultaneously. This leaves no connectivity to the server to be tested. This will simulate a server leaving a cluster.  注意这里提到的是同时拔掉所有线，这一点很难做到。

　　实际上看到上面官方的说法，在实际情况下也是很难模拟的。
　　那么官方对于system down的情况下，cluster会出现的情况是怎么解释的呢？当正在接管应用的节点A出现system down，并且autofailover参数为true（默认），那么节点B会接管应用。

　　2.  应用在节点a上，将节点A的的所有网卡，HBA卡，拔掉（最后拔心跳）。  节点B会接管应用。
　　     请注意这里提到了最后拔掉心跳，资源先出现故障，由于有心跳在，所以B节点会知道A节点资源的fault，B节点会接管应用。                     
　　                                         
　　3.  应用在节点A上，将一条心跳拔掉，不影响节点A上的应用，  此时如果节点A上某一资源有故障，会发生切换，节点B会接管应用。当心跳拔掉之后， 应用仍然在A机上online。这时VCS处于jeopardy状态，资源故障会切换，但system down不会切换。

　　4.两条心跳同时断掉，这时系统将变成2个互相不知道对方状态的子cluster。这时如果应用在A节点上online，则A节点保持online；B节点会认为A节点宕机，会试图把应用online；这时，会导致存储的split brain。B节点的online操作：B机会在让ip资源online之前去ping一下IP地址，当发现这个IP地址实际上是存在的（应为A节点现在ip资源是online状态），那么B节点放弃对IP资源的online，但是如果是共享存储就不那么幸运了，因为B节点不知道存储是否是被A节点接管，那么就会出现两个节点都争用存储的情况，即发生split brain。为了避免这个情况的发生，VCS提出了IO fencing的方法，但是这个需要底层的VxVM的支持，也就是说共享卷是要由VxVM管理的。
　　                                     
　　5.心跳是好的，任意一个资源有故障，只要这个资源是 critical的，会发生切换。