C H A P T E R 6

DR Internals

This chapter contains information about how DR works, and is not essential for those simply wishing to use DR. It is included here for more technical users who might find it of value.

This chapter covers the following topics:

Software Components on the Domain

Software Components on the SC (High-End Only)

Software Components on the Domain

This section describes the DR-related software components that reside on the domain and make DR operations possible.

Domain Configuration Server (High-End Only)

The domain configuration server (DCS) is a daemon process that runs on a high-end system domain and is started by inetd(1M) when the first remote DR request is received. A single instance of the DCS runs in each domain. The DCS accepts DR requests from the domain configuration agent (DCA) that runs on the SC. After the DCS accepts a DR operation, it performs the request and returns the results to the DCA. See Domain Configuration Agent (DCA).

Note - In domains that run the Solaris 10 OS, the DCS has no entries in the inetd.conf file. In domains running earlier versions of the Solaris software, DCS does have an entry in inetd.conf. In this latter case, if you alter or remove the sun-dr entry in inetd.conf, make the same change to the sun-dr entry in the ipsecinit.conf file.

DR Driver

The DR driver on a high-end system consists of a platform independent driver named dr and a platform-specific module, named drmach. On midrange systems, the driver is sbd and the platform-specific module is sbdp. The DR driver uses standard features of the Solaris software whenever possible to control DR operations, and it calls the platform-specific module as needed. The DR driver is responsible for creating minor nodes in the file system that are used as attachment points for DR operations.

Reconfiguration Coordination Manager

The reconfiguration coordination manager (RCM) is a daemon process that coordinates DR operations on resources that are present in the domain. The RCM daemon uses generic application program interfaces (APIs) to coordinate DR operations between DR initiators and RCM clients.

The RCM consumers consist of DR initiators, which request DR operations, and DR clients, which react to DR requests. Normally, the DR initiator is the configuration administration command, cfgadm(1M). However, it can also be a GUI such as Sun Management Center.

The DR clients can be:

Software layers that export high-level resources comprised of one or more hardware devices (for example, multipathing applications)

Applications that monitor DR operations (for example, Sun Management Center)

Entities on a remote system, such as the system controller on a server

System Events Framework

DR uses the Solaris system events framework to notify other software entities of the occurrence of changes that result from a DR operation. DR accomplishes this by sending DR events to the system event daemon, syseventd, which, in turn, sends the events to the subscribers of DR events. For more information about the system events daemon, see the syseventd(1M) man page.

Software Components on the SC (High-End Only)

This section describes the DR-related software components that reside on a high-end system's SC and make DR operations possible.

DR Administration Models

The available component list controls what administrative tasks can be performed, based on the name and group identification of the user. A brief description of the privileges model for each DR operation is given in SMS DR Procedures - From the SC (High-End Only). For a detailed description of the privileges required for each SMS command, see the System Management Services (SMS) Administrator Guide.

DR Processes and Daemons

Various processes and daemons on the Sun Fire high-end system controller (SC) work together to accomplish DR operations. The processes and/or daemons that are used depends entirely on the point of execution of the DR operation. For instance, if you execute the DR operation from the SC, the system uses several more processes and/or daemons to accomplish the DR operation than it would if you executed the DR operation from the domain.

For more information about the processes and daemons that reside on the domain, see the other chapters in this document. For more information about the processes and daemons that reside in the SMS software on the SC, see the System Management Services (SMS) Administrator Guide for more information.

Domain Configuration Agent (DCA)

The domain configuration agent (DCA) enables applications such as Sun Management Center and SMS to initiate DR operations on a Sun Fire high-end system domain. The DCA runs on the SC and manages the DR communications between software applications running on the SC and the domain configuration server on the domain. An individual instance of the DCA runs on the SC for each domain on the Sun Fire high-end system. For more information about the DCA, see the System Management Services (SMS) Administrator Guide.

Note - If you alter or remove the sun-dr entry in the inetd.conf file, make the same change to the sun-dr entry in the ipsecinit.conf file.

Platform Configuration Daemon (PCD) (High-End Only)

The platform configuration daemon (PCD) manages the configuration of each Sun Fire high-end system through a collection of flat files that comprise the PCD database. All changes to the configuration of the Sun Fire high-end system must go through the PCD. For more information about the PCD, see the System Management Services (SMS) Administrator Guide.

Domain X Server (DXS)

The domain x server (DXS) manages communication between the SC and the DR module (drmach) on the domain. An individual instance of the DXS runs on the SC for each domain on the Sun Fire high-end system. For more information about the DXS, see the System Management Services (SMS) Administrator Guide.