Shutting Down a Clustered Configuration (CLI)
TABLE 43
Cluster Resource Management
Resource Icon Omnipresent Taken over on failure
SINGLETON No Yes
REPLICA None Yes N/A
PRIVATE No No
SYMBIOTE None Same as parent type Same as parent type
When a new resource is created, it is initially assigned to the controller on which it is being
created. This ownership cannot be changed unless that controller is in the AKCS_OWNER
state; it is therefore necessary either to create resources on the controller which should own
them normally or to take over before changing resource ownership. It is generally possible to
destroy resources from either controller, although destroying storage pools that are exported
is not possible. Best results will usually be obtained by destroying resources on the controller
which currently controls them, regardless of which controller is the assigned owner.
Most configuration settings, including service properties, users, roles, identity mapping
rules, SMB autohome rules, and iSCSI initiator definitions are replicated on both controllers
automatically. Therefore it is never necessary to configure these settings on both controllers,
regardless of the cluster state. If one appliance is down when the configuration change is made,
it will be replicated to the other when it rejoins the cluster on next boot, prior to providing any
service. There are a small number of exceptions:
■
Share and LUN definitions and options may be set only on the controller which has control
of the underlying pool, regardless of the controller to which that pool is ordinarily assigned.
■
The "Identity" service's configuration (i.e., the appliance name and location) is not
replicated.
■
Names given to chassis are visible only on the controller on which they were assigned.
■
Each network route is bound to a specific interface. If each controller is assigned an
interface with an address in a particular subnet, and that subnet contains a router to which
the appliances should direct traffic, a route must be created for each such interface, even if
the same gateway address is used. This allows each route to become active individually as
control of the underlying network resources shifts between the two controllers. For more
information, see “Clustering Considerations for Networking” on page 214.
■
SSH host keys are not replicated and are never shared. Therefore if no private
administrative interface has been configured, you may expect key mismatches when
attempting to log into the CLI using an address assigned to a node that has failed. The same
limitations apply to the SSL certificates used to access the BUI.
The basic model, then, is that common configuration is transparently replicated, and
administrators will assign a collection of resources to each appliance controller. Those resource
208 Oracle ZFS Storage Appliance Administration Guide, Release OS8.6.x • September 2016
To Next Page
Loading...
Need help?
General
