Video Screencast Help

Is it recommended to configure coordinator DG for failover SG

Created: 13 Jan 2013 • Updated: 16 Jan 2013 | 4 comments
hytham fekry's picture
This issue has been solved. See solution.

Dears , Is it mandatory or recommended to implment IO fencing using co-ordinator disks if i have only failover service group with non-shared disk groups ?

disk headers will have the info. "on which node it's imported" and DG is  not shared ..

Comments 4 CommentsJump to latest comment

mikebounds's picture

It is optional to use I/O fencing with a cluster that only contains non-shared diskgroups.  If you use CVM then you must use I/O fencing or Coordination Point Servers (CPS).  I think the official line from Symantec is that I/O fencing is recommended for non-CVM clusters, but in practice, as a Symantec Consultant for 10 years, I only saw one customer use I/O fencing for a non-CVM cluster.


UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows

If this post has answered your question then please click on "Mark as solution" link below

Gaurav Sangamnerkar's picture

It is a recommendation for Non CVM clusters .. however it would be good to explain to customer about the implications of not using it .


PS: If you are happy with the answer provided, please mark the post as solution. You can do so by clicking link "Mark as Solution" below the answer provided.

AHerr's picture

I/O Fencing is optional as Mike and Gaurav say, but it is also strongly recommended.  I/O Fencing has 2 components:

1) Data Protection

2) Membership Arbitration

With SCSI3-PR I/O Fencing you have guaranteed Data Protection.  When there is a race condition, only one sub-cluster will survive.  The other node/sub-cluster will lose the race and panic itself.  Even without the panic, the losing nodes would not have the permission to read or write to the disk based on SCSI3 keys.  In this scenario you need SCSI3-PR compliant data disks and at least one as a coordinator disk.  CP Servers can be used in addition to SCSI3 coordinator disks. 

With Non-SCSI3 I/O Fencing you also have Data Protection but because it is not SCSI3-PR based, we rely on judiousous timing to panic the nodes.  This means that we try to ensure the losing nodes panic before the winning nodes attempt to startup the Service Groups to failover.  That way any outstanding data writes occur before the winning nodes startup the application and import the data disk.

With both types of I/O Fencing, you need 3 coordination points to remove single points of failure.  As winning the fencing race requires more than half of the available coordination points, having 3 means that if a node or sub-cluster obtains 2 coordination points that they would win the race.

We are in the process of updating our I/O Fencing Whitepaper that discusses this in further detail but I hope this was the information you were looking for.


In both types of I/O Fencing we supply Membership Arbitration.  When nodes can no longer communicate, we ensure that only one node/sub-cluster of boxes remain online to guarantee we do not have split-brain.