RECOMENDACIONES DE CUIDADO CLÍNICO Debe existir un abordaje pluridisciplinar en el

■ “Cluster Terminology” on page 144

■ “Cluster Interconnect I/O” on page 145

■ “Cluster Resource Management” on page 147

■ “Cluster Takeover and Failback” on page 150

■ “Configuration Changes in a Clustered Environment” on page 152

■ “Clustering Considerations for Storage” on page 152 ■ “Clustering Considerations for Networking” on page 154 ■ “Private Local IP Interfaces” on page 155

■ “Clustering Considerations for Infiniband” on page 156

■ “Preventing 'Split-Brain' Conditions” on page 158

■ “Estimating and Reducing Takeover Impact” on page 160

Cluster Advantages and Disadvantages

It is important to understand the scope of the Oracle ZFS Storage Appliance clustering

implementation. The term 'cluster' is used in the industry to refer to many different technologies with a variety of purposes. We use it here to mean a metasystem comprised of two appliance heads and shared storage, used to provide improved availability in the case in which one of the heads succumbs to certain hardware or software failures. A cluster contains exactly two appliances or storage controllers, referred to for brevity throughout this document as heads.

Each head may be assigned a collection of storage, networking, and other resources from the set available to the cluster, which allows the construction of either of two major topologies. Many people use the terms active-active to describe a cluster in which there are two (or more) storage pools, one of which is assigned to each head along with network resources used by clients to reach the data stored in that pool, and active-passive to refer to which a single storage pool is assigned to the head designated as active along with its associated network interfaces. Both topologies are supported by the Oracle ZFS Storage Appliance. The distinction between these is artificial; there is no software or hardware difference between them and one can switch at will simply by adding or destroying a storage pool. In both cases, if a head fails, the other (its peer) will take control of all known resources and provide the services associated with those resources.

As an alternative to incurring hours or days of downtime while the head is repaired, clustering allows a peer appliance to provide service while repair or replacement is performed. In

addition, clusters support rolling upgrade of software, which can reduce the business disruption associated with migrating to newer software. Some clustering technologies have certain additional capabilities beyond availability enhancement; the Oracle ZFS Storage Appliance clustering subsystem was not designed to provide these. In particular, it does not provide for load balancing among multiple heads, improve availability in the face of storage failure, offer clients a unified filesystem namespace across multiple appliances, or divide service responsibility across a wide geographic area for disaster recovery purposes. These functions are likewise outside the scope of this document; however, the Oracle ZFS Storage Appliance and the data protocols it offers support numerous other features and strategies that can improve availability:

■ Replication of data, which can be used for disaster recovery at one or more geographically

remote sites

■ Client-side mirroring of data, which can be done using redundant iSCSI LUNs provided by multiple arbitrarily located storage servers

■ Load balancing, which is built into the NFS protocol and can be provided for some other protocols by external hardware or software (applies to read-only data)

■ Redundant hardware components including power supplies, network devices, and storage

controllers

■ Fault management software that can identify failed components, remove them from service, and guide technicians to repair or replace the correct hardware

■ Network fabric redundancy provided by LACP and IPMP functionality

■ Redundant storage devices (RAID)

Additional information about other availability features can be found in the appropriate sections of this document.

When deciding between a clustered and standalone Oracle ZFS Storage Appliance configuration, it is important to weigh the costs and benefits of clustered operation. It is common practice throughout the IT industry to view clustering as an automatic architectural decision, but this thinking reflects an idealized view of clustering's risks and rewards promulgated by some vendors in this space. In addition to the obvious higher up-front and ongoing hardware and support costs associated with the second head, clustering also imposes

additional technical and operational risks. Some of these risks can be mitigated by ensuring that all personnel are thoroughly trained in cluster operations; others are intrinsic to the concept of clustered operation. Such risks include:

■ The potential for application intolerance of protocol-dependent behaviors during takeover, ■ The possibility that the cluster software itself will fail or induce a failure in another

subsystem that would not have occurred in standalone operation,

■ Increased management complexity and a higher likelihood of operator error when

performing management tasks,

■ The possibility that multiple failures or a severe operator error will induce data loss or corruption that would not have occurred in a standalone configuration, and

■ Increased difficulty of recovering from unanticipated software and/or hardware states.

These costs and risks are fundamental, apply in one form or another to all clustered or cluster- capable products on the market (including the Oracle ZFS Storage Appliance), and cannot be entirely eliminated or mitigated. Storage architects must weigh them against the primary benefit of clustering: the opportunity to reduce periods of unavailability from hours or days to minutes or less in the rare event of catastrophic hardware or software failure. Whether that cost/benefit analysis will favor the use of clustering in an Oracle ZFS Storage Appliance deployment will depend on local factors such as SLA terms, available support personnel and their qualifications, budget constraints, the perceived likelihood of various possible failures, and the appropriateness of alternative strategies for enhancing availability. These factors are highly site-, application-, and business-dependent and must be assessed on a case-by-case basis. Understanding the material in the rest of this section will help you make appropriate choices during the design and implementation of your unified storage infrastructure.