Understand Oracle Clusterware Architecture

Contents

  1. 1 Overview
  2. 2 Disk Storage
  3. 3 Clusterware Stack


Overview

There are several components of the Oracle Clusterware Architecture:

  1. Network architecture of public, interconnect, and storage (if applicable);
  2. Disk storage covers the binaries, OCR, OLR, and voting disks
  3. Clusterware stack

Disk Storage

In Oracle® Clusterware Administration and Deployment Guide 11g Release 2 (11.2) , the section, Oracle Clusterware Software Concepts and Requirements , says that:

  • Voting Disks

    • Oracle Clusterware uses voting disk files to determine which nodes are members of a cluster. You can configure voting disks on Oracle ASM, or you can configure voting disks on shared storage.

    …

    …The maximum number of voting disks that is supported is 15.

  • Oracle Cluster Registry

    • Oracle Clusterware uses the Oracle Cluster Registry (OCR) to store and manage information about the components that Oracle Clusterware controls, such as Oracle RAC databases, listeners, virtual IP addresses (VIPs), and services and any applications. The OCR stores configuration information in a series of key-value pairs in a tree structure.…

    • You can have up to five OCR locations

In Oracle® Clusterware Administration and Deployment Guide 11g Release 2 (11.2) , the section, About Voting Disks, Oracle Cluster Registry, and Oracle Local Registry , says that:

  • Voting disks manage information about node membership. Each voting disk must be accessible by all nodes in the cluster for nodes to be members of the cluster
  • OCR manages Oracle Clusterware and Oracle RAC database configuration information
  • OLR resides on every node in the cluster and manages Oracle Clusterware configuration information for each particular node

Clusterware Stack

In Oracle® Clusterware Administration and Deployment Guide 11g Release 2 (11.2) , the section, Overview of Oracle Clusterware Platform-Specific Software Components , says that:

Oracle Clusterware consists of two separate stacks: an upper stack anchored by the Cluster Ready Services (CRS) daemon ( crsd ) and a lower stack anchored by the Oracle High Availability Services daemon ( ohasd ).

The Cluster Ready Services Stack consists of:

  • Cluster Ready Services (CRS) : The primary program for managing high availability operations in a cluster.

    • The CRS daemon ( crsd ) manages cluster resources based on the configuration information that is stored in OCR for each resource. This includes start, stop, monitor, and failover operations. The crsd process generates events when the status of a resource changes. When you have Oracle RAC installed, the crsd process monitors the Oracle database instance, listener, and so on, and automatically restarts these components when a failure occurs.

  • Cluster Synchronization Services (CSS) : Manages the cluster configuration by controlling which nodes are members of the cluster and by notifying members when a node joins or leaves the cluster. If you are using certified third-party clusterware, then CSS processes interfaces with your clusterware to manage node membership information.

    • The cssdagent process monitors the cluster and provides I/O fencing. This service formerly was provided by Oracle Process Monitor Daemon ( oprocd , also known as OraFenceService on Windows. A cssdagent failure results in Oracle Clusterware restarting the node.

  • Oracle ASM : Provides disk management for Oracle Clusterware.
  • Cluster Time Synchronization Service (CTSS) : Provides time management in a cluster for Oracle Clusterware.
  • Event Management (EVM) : A background process that publishes events that Oracle Clusterware creates.
  • Oracle Notification Service (ONS) : A publish and subscribe service for communicating Fast Application Notification (FAN) events.
  • Oracle Root Agent (orarootagent) : A specialized oraagent process that helps crsd manage resources owned by root, such as the network, and the Grid virtual IP address.

The Oracle High Availability Services Stack consists of:

  • Grid Plug and Play (GPNPD) : GPNPD provides access to the Grid Plug and Play profile, and coordinates updates to the profile among the nodes of the cluster to ensure that all of the nodes node have the most recent profile.
  • Grid Interprocess Communication (GIPC) : A helper daemon for the communications infrastructure. Currently has no functionality; to be activated in a later release.
  • Multicast Domain Name Service (mDNS) : Grid Plug and Play uses the mDNS process to locate profiles in the cluster, as well as by GNS to perform name resolution. The mDNS process is a background process on Linux and UNIX, and a service on Windows.
  • Oracle Grid Naming Service (GNS) : Handles requests sent by external DNS servers, performing name resolution for names defined by the cluster.