Inconsistent Access to Storage by Cluster



Result: Downtime

The signature
Inconsistent access to storage volumes by cluster nodes

The impact
In the event of a cluster failover to the passive node, data will not be available.

This will lead to downtime, since any applications relying on databases or files stored on these un-mapped storage volumes will not be available to the passive node.

Technical details
In this example, a production database is stored on three storage volumes. In a typical cluster configuration, these three storage volumes should be shared by all nodes, such that in case of failover to a secondary node, data will be immediately available. However, one of the storage volumes is not mapped to the passive cluster node. To resolve this issue, the administrator will have to manually identify the missing storage volume and map it to the passive node (process which involves masking and zoning).

Can it happen to me?
This is a very common gap found on production environments. The initial configuration of a cluster is typically correct. However, when maintenance changes are required to production data on the cluster (such as adding a new storage volume), many times these changes are performed only on the currently active node, leaving any other nodes with obsolete configuration.