Table of Contents
Advertisement
After you set up a cluster, the initial state consists of the node that initiated the setup in the
OWNER state and the other node in the STRIPPED state. After performing an initial failback
operation to hand the STRIPPED node its portion of the shared resources, both nodes are
CLUSTERED. If both cluster nodes fail or are powered off, then upon simultaneous startup
they will arbitrate and one of them will become the OWNER and the other STRIPPED.
During failback all foreign resources (those assigned to the peer) are exported, then imported
by the peer. A pool that cannot be imported because it is faulted will trigger reboot of the
STRIPPED node. An attempt to failback with a faulted pool can reboot the STRIPPED node as
a result of the import failure.
To minimize service downtime, statistics and datasets are not available during failback and
takeover operations. Data is not collected, and any attempt to suspend or resume statistics is
delayed until failback and takeover operations have completed and data collection automatically
resumes.
Related Topics
"Shutting Down a Clustered Configuration (CLI)" on page 199
■
Configuration Changes in a Clustered
Environment
The vast majority of appliance configuration is represented as either service properties or share/
LUN properties. While share and LUN properties are stored with the user data on the storage
pool itself (and thus are always accessible to the current owner of that storage resource), service
configuration is stored within each controller. To ensure that both controllers provide coherent
service, all service properties must be synchronized when a change occurs or a controller
that was previously down rejoins with its peer. Since all services are represented by replica
resources, this synchronization is performed automatically by the appliance software any time a
property is changed on either controller.
It is therefore unnecessary and redundant for administrators to replicate configuration changes.
Standard operating procedures should reflect this attribute and call for making changes to only
one of the two controllers once initial cluster configuration has been completed. Note as well
that the process of initial cluster configuration will replicate all existing configuration onto the
newly-configured peer. Generally, then, we derive two best practices for clustered configuration
changes:
Make all storage- and network-related configuration changes on the controller that currently
■
controls (or will control, if a new resource is being created) the underlying storage or
network interface resources.
Shutting Down a Clustered Configuration (CLI)
Configuring the Appliance
211
Advertisement
Table of Contents
