Forum Discussion

hytham_fekry's avatar
12 years ago

Is it recommended to configure coordinator DG for failover SG

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 ..

  • 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.

     

    Regards,
    Anthony

    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.

  • 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.

    Mike

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

     

    Gaurav

  • 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.

     

    Regards,
    Anthony

    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.