Table of Contents
Advertisement
Shutting Down a Clustered Configuration (CLI)
State
CLUSTERED
-
-
Transitions among these states take place as part of two operations: takeover and failback.
Takeover can occur at any time, and is attempted whenever peer failure is detected. It can also
be triggered manually using the cluster configuration CLI or BUI, which can be useful for
testing purposes. Finally, takeover will occur when a controller boots and detects that its peer is
absent. This allows service to resume normally when one controller has failed permanently or
when both controllers have temporarily lost power.
Failback never occurs automatically. When a failed controller is repaired and booted, it
will rejoin the cluster (resynchronizing its view of all resources, their properties, and their
ownership) and proceed to wait for an administrator to perform a failback operation. Until then,
the original surviving controller will continue to provide all services. This allows for a full
investigation of the problem that originally triggered the takeover, validation of a new software
revision, or other administrative tasks prior to the controller returning to production service.
Because failback is disruptive to clients, it should be scheduled according to business-specific
needs and processes. There is one exception: Suppose that controller A has failed and controller
B has taken over. When controller A rejoins the cluster, it becomes eligible to take over if
it detects that controller B is absent or has failed. The principle is that it is always better to
provide service than not, even if there has not yet been an opportunity to investigate the original
problem. So while failback to a previously-failed controller will never occur automatically, it
may still perform takeover at any time.
210
Oracle ZFS Storage Appliance Administration Guide, Release OS8.6.x • September 2016
Icon
CLI/BUI Expression
Active
Rejoining cluster ...
Unknown (disconnected or
restarting)
Description
executes a fail-back
operation.
Clustering is configured,
and both nodes own shared
resources according to
their resource assignments.
If each node owns a
ZFS pool and is in the
CLUSTERED state, then
the two nodes form what
is commonly called an
active-active cluster.
The appliance has recently
rebooted, or the appliance
management software is
restarting after an internal
failure. Resource state is
being resynchronized.
The peer appliance is
powered off or rebooting,
all its cluster interconnect
links are down, or
clustering has not yet been
configured.
Advertisement
Table of Contents
