Oracle Solaris Cluster System Hardware and Software Components

This information is directed primarily to hardware service providers. These concepts can help service providers understand the relationships between hardware components before they install, configure, or service cluster hardware. Cluster system administrators might also find this information useful as background information before installing, configuring, and administering cluster software.

A cluster is composed of several hardware components, including the following:

• Cluster nodes with local disks (unshared)

• Multihost storage (disks/LUNs are shared between cluster nodes)

• Removable media (tapes, CD-ROMs, and DVDs)

• Cluster interconnect

• Public network interfaces

• Administrative console

• Console access devices

The following figure illustrates how the hardware components work with each other.

Figure 2-1 Oracle Solaris Cluster Hardware Components

Administrative console and console access devices are used to reach the cluster nodes or the terminal concentrator as needed. The Oracle Solaris Cluster software enables you to combine the hardware components into a variety of configurations. The following sections describe these configurations:

• SPARC: Oracle Solaris Cluster Topologies

• x86: Oracle Solaris Cluster Topologies

Cluster Nodes

An Oracle Solaris host (or simply cluster node) is one of the following hardware or software configurations that runs the Oracle Solaris OS and its own processes:

• A physical machine that is not configured with a virtual machine or as a hardware domain

• Oracle VM Server for SPARC guest domain

• Oracle VM Server for SPARC I/O domain

• A hardware domain

Depending on your platform, Oracle Solaris Cluster software supports the following configurations:

• SPARC: Oracle Solaris Cluster software supports from 1–16 cluster nodes in a cluster. Different hardware configurations impose additional limits on the maximum number of nodes that you can configure in a cluster composed of SPARC based systems. See SPARC: Oracle Solaris Cluster Topologies for the supported configurations.

• x86: Oracle Solaris Cluster software supports from 1–8 cluster nodes in a cluster. Different hardware configurations impose additional limits on the maximum number of nodes that you can configure in a cluster composed of x86 based systems. See x86: Oracle Solaris Cluster Topologies for the supported configurations.

Cluster nodes are generally attached to one or more multihost storage devices. Nodes that are not attached to multihost devices can use a cluster file system to access the data on multihost devices. For example, one scalable services configuration enables nodes to service requests without being directly attached to multihost devices.

In addition, nodes in parallel database configurations share concurrent access to all the disks.

• See Multihost Devices for information about concurrent access to disks.

• See SPARC: Clustered Pair Topology and x86: Clustered Pair Topology for more information about parallel database configurations and scalable topology.

Public network adapters attach nodes to the public networks, providing client access to the cluster.

Cluster members communicate with the other nodes in the cluster through one or more physically independent networks. This set of physically independent networks is referred to as the cluster interconnect.

Every node in the cluster is aware when another node joins or leaves the cluster. Additionally, every node in the cluster is aware of the resources that are running locally as well as the resources that are running on the other cluster nodes.

Nodes in the same cluster should have the same OS and architecture, as well as similar processing, memory, and I/O capability to enable failover to occur without significant degradation in performance. Because of the possibility of failover, every node must have enough excess capacity to support the workload of all nodes for which they are a backup or secondary.

Software Components for Cluster Hardware Members

To function as a cluster member, a cluster node must have the following software installed:

• Oracle Solaris OS

• Oracle Solaris Cluster software

• Data service applications

• Optional: Volume management (for example, Solaris Volume Manager)

  An exception is a configuration that uses hardware redundant array of independent disks (RAID). This configuration might not require a software volume manager such as Solaris Volume Manager.

For more information, see the following:

• The Oracle Solaris Cluster Software Installation Guide for information about how to install the Oracle Solaris OS, Oracle Solaris Cluster, and volume management software.

• The Oracle Solaris Cluster Data Services Planning and Administration Guide for information about how to install and configure data services.

• Chapter 3, Key Concepts for System Administrators and Application Developers for conceptual information about these software components.

The following figure provides a high-level view of the software components that work together to create the Oracle Solaris Cluster environment.

Figure 2-2 High-Level Relationship of Oracle Solaris Cluster Components

The following figure shows a high-level view of the software components that work together to create the Oracle Solaris Cluster software environment.

Figure 2-3 Oracle Solaris Cluster Software Architecture

Multihost Devices

LUNs that can be connected to more than one cluster node at a time are multihost devices. A cluster with more than two nodes does not require quorum devices. A quorum device is a shared storage device or quorum server that is shared by two or more nodes and that contributes votes that are used to establish a quorum. The cluster can operate only when a quorum of votes is available. For more information about quorum, see Quorum and Quorum Devices.

Multihost devices have the following characteristics:

• Ability to store application data, application binaries, and configuration files.

• Protection against host failures. If clients request the data through one node and the node fails, the I/O requests are handled by the surviving node.

A volume manager can provide software RAID protection for the data residing on the multihost devices.

Combining multihost devices with disk mirroring protects against individual disk failure.

Local Disks

Local disks are the disks that are connected only to a single cluster node. Local disks are therefore not protected against node failure (they are not highly available). However, all disks, including local disks, are included in the global namespace and are configured as global devices. Therefore, the disks themselves are visible from all cluster nodes.

See Global Devices for more information about global devices.

Removable Media

Removable media, such as tape drives and CD-ROM drives, are supported in a cluster. You install, configure, and service these devices in the same way as in a nonclustered environment. Refer to Oracle Solaris Cluster 3.3 3/13 Hardware Administration Manual for information about installing and configuring removable media.

See the Global Devices section for more information about global devices.

Cluster Interconnect

The cluster interconnect is the physical configuration of devices that is used to transfer cluster-private communications and data service communications between cluster nodes in the cluster.

Only nodes in the cluster can be connected to the cluster interconnect. The Oracle Solaris Cluster security model assumes that only cluster nodes have physical access to the cluster interconnect.

You can set up from one to six cluster interconnects in a cluster. While a single cluster interconnect reduces the number of adapter ports that are used for the private interconnect, it provides no redundancy and less availability. If a single interconnect fails, moreover, the cluster is at a higher risk of having to perform automatic recovery. Whenever possible, install two or more cluster interconnects to provide redundancy and scalability, and therefore higher availability, by avoiding a single point of failure.

The cluster interconnect consists of three hardware components: adapters, junctions, and cables. The following list describes each of these hardware components.

• Adapters – The network interface cards that are located in each cluster node. Their names are constructed from a device name immediately followed by a physical-unit number, for example, qfe2. Some adapters have only one physical network connection, but others, like the qfe card, have multiple physical connections. Some adapters combine both the functions of a NIC and an HBA.

  A network adapter with multiple interfaces could become a single point of failure if the entire adapter fails. For maximum availability, plan your cluster so that the paths between two nodes do not depend on a single network adapter.

• Junctions – The switches that are located outside of the cluster nodes. In a two-node cluster, junctions are not mandatory. In that case, the nodes can be connected to each other through back-to-back network cable connections. Configurations of more than two nodes generally require junctions.

• Cables – The physical connections that you install either between two network adapters or between an adapter and a junction.

Figure 2-4 shows how the two nodes are connected by a transport adapter, cables, and a transport switch.

Figure 2-4 Cluster Interconnect

Public Network Interfaces

Clients connect to the cluster through the public network interfaces.

You can set up cluster nodes in the cluster to include multiple public network interface cards that perform the following functions:

• Enable a cluster node to be connected to multiple subnets

• Provide public network availability by having interfaces acting as backups for one another (through IPMP)

If one of the adapters fails, IP network multipathing software is called to fail over the defective interface to another adapter in the group. For more information about IPMP, see Chapter 27, Introducing IPMP (Overview), in Oracle Solaris Administration: IP Services.

No special hardware considerations relate to clustering for the public network interfaces.

Logging Into the Cluster Remotely

You must have console access to all nodes in the cluster.

To gain console access, use one of the following methods:

• The cconsole utility can be used from the command line to log into the cluster remotely. For more information, see the cconsole(1M) man page.

• The terminal concentrator that you purchased with your cluster hardware.

• The system controller on Oracle servers, such as Sun Fire servers (also for SPARC based clusters).

• Another device that can access ttya on each node.

Only one supported terminal concentrator is available from Oracle and use of the supported Sun terminal concentrator is optional. The terminal concentrator enables access to /dev/console on each node by using a TCP/IP network. The result is console-level access for each node from a remote machine anywhere on the network.

Other console access methods include other terminal concentrators, tip serial port access from another node, and dumb terminals.

---

Caution - You can attach a keyboard or monitor to a cluster node provided that the keyboard and monitor are supported by the base server platform. However, you cannot use that keyboard or monitor as a console device. You must redirect the console to a serial port and Remote System Control (RSC) by setting the appropriate OpenBoot PROM parameter.

---

Administrative Console

You can use a dedicated workstation or administrative console to reach the cluster nodes or the terminal concentrator as needed to administer the active cluster. Usually, you install and run administrative tool software, such as the Cluster Control Panel (CCP), on the administrative console. Using cconsole under the CCP enables you to connect to more than one node console at a time. For more information about how to use the CCP, see the Chapter 1, Introduction to Administering Oracle Solaris Cluster, in Oracle Solaris Cluster System Administration Guide.

You use the administrative console for remote access to the cluster nodes, either over the public network or, optionally, through a network-based terminal concentrator.

Oracle Solaris Cluster does not require a dedicated administrative console, but using one provides these benefits:

• Enables centralized cluster management by grouping console and management tools on the same machine

• Provides potentially quicker problem resolution by your hardware service provider