How many Fencing disks needed?

[Xentar]

Hi All,

We would like to set up 4 nodes VCS, with host name A, B, C and D.

Host A, B, C and D will be a CFS group and we would like to set up samba failover group on Host A & B, and on Host C & D.
It means that there will be two samba resource groups and failover between Host A & B, and Host C & D.

Question is that if one of host, say, host A, all the heartbeats is disconnected.
All the hosts will try to race the fencing disks and only ONE of the Host will be survived?

If this is correct, how many fencing disks needed for such case?

Also, is it possible to setup Host C & D will not being affect if the heartbeat is being disconnected from either Host A or B?
If yes, how to do so? And how many fencing disks needed for it?

Thanks,
Xentar 

[M__Braun]

> Question is that if one of host, say, host A, all the heartbeats is disconnected.

When a cluster reconfiguration happens, the lowest LLT ID system of any sub-cluster is responsible for racing for coordinator disks on behalf of the remaining nodes. The fencing algorithm will give the larger sub-cluster an advantage in the race for control of the coordinator disk. Therefore it is likely that only Host A will panic.

> If this is correct, how many fencing disks needed for such case?
Fencing should still use the three recommended LUNs.

I wonder why are you already considering the different failure scenarios? Making the interconnect connection truly redundant (e.g. more than two private links, different NICs, different switches, different cabling paths, etc.) should be the better approach.

Regards

Manuel

[Xentar]

HI Manuel,

Does LLT ID system means the number in /etc/llthosts ?

If yes, for example, we have the following:

0 A

1 B

2 C

3 D

If Host A lost heartbeat, only A and B will race for the fencing disk?

For the similiar case happen, if Host D lost heartbeat, and since C with lowest LLT ID between second samba failover resource group, C will be most case to be panic?

And Host A and B will not race for the Fencing disk?

For the redundant network issue, actually we did have it.
However, we need to the test for all the redundant network link is down in order to pass the aduit requirement.

Thanks,
Xentar
 

[TomerG]

 If Host D lost heartbeats, then clusters A-B-C and D would race. A-B-C would likely win since it's larger, and it would likely be node A to race for that cluster... i.e. A vs D

It's all a numbers game. I reckommend 2+ private links, definitely a public link heartbeat (lowpriority), and I/O fencing is there as the last resort when all fail.

[Xentar]

Hi Tomer,

It means that mostly likely only Host D to be panic in such case? And the rest A-B-C still online?

If such case, how does the fencing being imported? A-B-C each imported one fencing disk and D can't race for any fencing disk, therefore, host D got panic in such case? Is it correct?

If yes, then A-B-C each got 33% of the fencing disk only. Does the host need to get more than 50% of Fencing disk in order to survive? i.e., more than 2 disks out of 3 disks in such case?

Regards,
Xentar

[M__Braun]

Hi Xentar,

I highly recommend taking a closer look at the Fencing section of the VCS Users Guide (page 357ff):

http://sfdoccentral.symantec.com/sf/5.0MP3/solaris/pdf/vcs_users.pdf

> If such case, how does the fencing being imported? A-B-C each imported one fencing disk and D can't race for any fencing disk

The coordinator disk group is not even imported. The fencing driver on each system registers SCSI-3 keys with each coordinator disk.

Regards

Manuel