EasyManuals Logo

Oracle ZFS Storage Appliance User Manual

Oracle ZFS Storage Appliance
650 pages
To Next Page IconTo Next Page
To Next Page IconTo Next Page
To Previous Page IconTo Previous Page
To Previous Page IconTo Previous Page
Page #211 background imageLoading...
Page #211 background image
Shutting Down a Clustered Configuration (CLI)
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.
Configuring the Appliance 211

Table of Contents

Other manuals for Oracle ZFS Storage Appliance

Questions and Answers:

Question and Answer IconNeed help?

Do you have a question about the Oracle ZFS Storage Appliance and is the answer not in the manual?

Oracle ZFS Storage Appliance Specifications

General IconGeneral
Connectivity10GbE, 40GbE, InfiniBand, Fibre Channel
ProtocolsNFS, SMB, iSCSI, Fibre Channel, HTTP
Operating SystemOracle Solaris
Data Protectionsnapshots, clones, remote replication
Data ReductionInline compression, deduplication
High AvailabilityRedundant hardware components (controllers, power supplies, fans). Automatic failover between controllers. Hot-swappable drives and components. Cluster configurations for increased availability and scalability.
Management InterfaceWeb-based GUI, CLI, REST API
Storage TypeHybrid (SSD + HDD), All-Flash
Storage CapacityUp to several petabytes
EncryptionAES-256 encryption at rest

Related product manuals