Overview of Oracle CRS Architecture

This article will quickly cover the Oracle cluster ready services (CRS) architecture in 11gR2.

In 10g, CRS consisted of three major components, as shown in Figure 1. These components manifested themselves as daemons, which ran out of inittab on Linux/Unix, or as services on Windows. The three daemons wer:

• Oracle Cluster Synchronization Services daemon (CSSD)
• Cluster Ready Services daemon (CRSD), which is the main engine for maintaining availability of resources
• Event Manager daemon (EVMD)

Of these three components, CSSD and EVMD ran as user oracle, while CRSD ran as root. The CSSD was responsible for cluster synchronization, cluster membership, and group membership; EVMD handled event messaging for the processes; and CRSD managed the resources. Resource management such as start, stop, and monitor was done using scripts and processes that came under the RACG label. An example would be racgimon, which monitored the status of database instances.

FIGURE1. Oracle 10g and 11g Release 1 CRS processes

In Oracle 11g Release 1, the init-managed stack remained; however, as you see in Figure 2, the Oracle 11g Release 2 startup and process stacks have completely changed. The CRS stack has effectively been split into two stacks, with the Oracle High Availability Services daemon (OHASD) handling the low-level processes and the Cluster Ready Services daemon (CRSD) handling the higher level resources such as database instances. These two stacks no longer use the old RACG framework but have a new agent framework to manage their availability, and now the concept of a local registry (OLR) is managed by OHASD as well as the Cluster Registry (OCR) which is managed by CRSD.