Cluster Resource Management

The resource manager is responsible for ensuring that the correct set of network interfaces is plumbed up, the correct storage pools are active, and the numerous configuration parameters remain in sync between two clustered controllers. Most of this subsystem's activities are invisible to administrators. However, one important aspect is exposed. Resources are classified into several types that govern when and whether the resource is imported (made active). Note that the definition of active varies by resource class. For example, a network interface belongs to the net class and is active when the interface is brought up.

The three most important resource types are replica, singleton, and private:

Replica resources - Replicas are simplest: They are never exposed to administrators and do not appear on the cluster configuration screen. Replicas always exist and are always active on both controllers. Typically, these resources simply act as containers for service properties that must be synchronized between the two controllers.
Singleton resources - Like replicas, singleton resources provide synchronization of state. However, singletons are always active on exactly one controller. Administrators can choose the controller on which each singleton should normally be active. If that controller has failed, its peer will import the singleton. Singletons are the key to the availability characteristics of clustering. Singletons are the resources one typically imagines moving from a failed controller to its surviving peer. Singletons include network interfaces and storage pools. Because a network interface is a collection of IP addresses used by clients to find a known set of storage services, it is critical that each interface be assigned to the same controller that the storage pool clients will expect to see when accessing that interface's addresses.
Private resources - Private resources are known only to the controller to which they are assigned, and are never taken over upon failure. This is typically useful only for network interfaces. See the following discussion of specific use cases.

Another data type is the symbiote. A symbiote allows one resource to follow another as it is imported and exported. For example, a symbiote is used to represent disks and flash devices in the storage pool.

The following figure shows an example of a clustered configuration, including shared resources.

The following table describes characteristics of different cluster resource types.

Table 2-3 Cluster Resource Types

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. Therefore, either create resources on the controller that should own them normally, or take over before changing resource ownership. In general, it is 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 that 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. 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, the change will be replicated to the other appliance when that appliance rejoins the cluster on next boot, prior to providing any service. There are a small number of exceptions:

Share and LUN definitions and options can be set only on the controller that has control of the underlying pool, regardless of the controller to which that pool is ordinarily assigned.
The configuration of the Identity service (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.
SSH host keys are not replicated and are never shared. Therefore if no private administrative interface has been configured, you can 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 is that common configuration is transparently replicated, and administrators will assign a collection of resources to each appliance controller. Those resource assignments form the binding of network addresses to storage resources that clients expect to see. Regardless of which appliance controls the collection of resources, clients are able to access the storage they require at the network locations they expect.