Table of Contents
Advertisement
Shutting Down a Clustered Configuration (CLI)
Make all other changes on either controller, but not both. Site policy should specify which
■
controller is to be considered the master for this purpose, and should in turn depend on
which of the controllers is functioning and the number of storage pools that have been
configured. Note that the appliance software does not make this distinction.
The problem of amnesia, in which disjoint configuration changes are made and subsequently
lost on each controller while its peer is not functioning, is largely overstated. This is especially
true of the Oracle ZFS Storage Appliance, in which no mechanism exists for making
independent changes to system configuration on each controller. This simplification largely
alleviates the need for centralized configuration repositories and argues for a simpler approach:
whichever controller is currently operating is assumed to have the correct configuration, and
its peer will be synchronized to it when booting. While future product enhancements may
allow for selection of an alternate policy for resolving configuration divergence, this basic
approach offers simplicity and ease of understanding: the second controller will adopt a set
of configuration parameters that are already in use by an existing production system (and are
therefore highly likely to be correct). To ensure that this remains true, administrators should
ensure that a failed controller rejoins the cluster as soon as it is repaired.
Related Topics
"Shutting Down a Clustered Configuration (CLI)" on page 199
■
Clustering Considerations for Storage
When sizing an Oracle ZFS Storage Appliance for use in a cluster configuration, two
considerations are very important:
Whether all pools are owned by the same controller, or split between the two controllers.
■
Whether you want pools with no single point of failure (NSPF).
■
Assigning storage pool ownership - Perhaps the most important decision is whether all storage
pools will be assigned ownership to the same controller, or split between them. There are
several trade-offs to consider, as shown in
Pools," on page
Generally, pools should be configured on a single controller except when optimizing for
throughput during nominal operation or when failed-over performance is not a consideration.
The exact changes in performance characteristics when in the failed-over state will depend
to a great deal on the nature and size of the workload(s). Generally, the closer a controller
is to providing maximum performance on any particular axis, the greater the performance
degradation along that axis when the workload is taken over by that controller's peer. Of course,
in the multiple pool case, this degradation will apply to both workloads.
Read cache devices are located in the controller or disk shelf, depending on your configuration.
212
Oracle ZFS Storage Appliance Administration Guide, Release OS8.6.x • September 2016
213.
Table 45, "Clustering Considerations for Storage
Advertisement
Table of Contents
