A shared disk group provides concurrent read and write access to the volumes that it contains for all nodes in a cluster. A shared disk group can only be created on the master node. This has the following advantages and implications:
The practical implication of this design is that I/O failure on any node results in the configuration of all nodes being changed. This is known as the global detach policy. However, in some cases, it is not desirable to have all nodes react in this way to I/O failure. To address this, an alternate way of responding to I/O failures, known as the local detach policy, was introduced.
The local detach policy is intended for use with shared mirrored volumes in a cluster. This policy prevents I/O failure on any of the nodes in the cluster from causing a plex to be detached .This would require the plex to be resynchronized when it is subsequently reattached. The local detach policy is available for disk groups that have a version number of 120 or greater.
For small mirrored volumes, non-mirrored volumes, volumes that use hardware mirrors, and volumes in private disk groups, there is no benefit in configuring the local detach policy. In most cases, it is recommended that you use the default global detach policy.
The choice between local and global detach polices is one of node availability versus plex availability when an individual node loses access to disks. Select the local detach policy for a diskgroup if you are using mirrored volumes within it, and would prefer a single node to lose write access to a volume rather than a plex of the volume being detached clusterwide. i.e. you consider the availability of your data (retaining mirrors) more important than any one node in the cluster. This will typically only apply in larger clusters, and where a parallel application is being used that can seamlessly provide the same service from the other nodes. For example, this option is not appropriate for fast failover configurations. Select the global detach policy in all other cases.
In the event of the master node losing access to all the disks containing log/config copies, the disk group failure policy is triggered. At this point no plexes can be detached, as this requires access to the log/config copies, no configuration changes to the disk group can be made, and any action requiring the kernel to write to the klog (first open, last close, mark dirty etc) will fail. If this happened in releases prior to 4.1, the master node always disabled the disk group. Release 4.1 introduces the disk group failure policy, which allows you to change this behavior for critical disk groups. This policy is only available for disk groups that have a version number of 120 or greater.