DR with and without DSDs

In the interest of resource management and to have DR best serve your application needs, you must understand the differences between the DR capabilities applicable to the Starfire and those applicable to the Sun Enterprise 3000-6500 servers.

The Sun Enterprise 3000-6500 DR is simpler in nature because it doesn't support DSDs, and its functionality is limited to bringing brand new system board resources into the Solaris instance or detaching system boards to be serviced or shared with other Sun Enterprise 3000-6500 servers.

In contrast, the Starfire DR is more complex in nature because it includes all of the Sun Enterprise 3000-6500 DR functionality as well as DSD support to allow resource sharing within the same platform.

Resource Sharing

In the Resource Management framework, the Sun Enterprise 3000-6500 platforms are limited to physically sharing system board resources with other Sun Enterprise 3000-6500 platforms. Physical sharing involves the powering down and physical removal of a system board from a system (after having it removed from Solaris operating environment control). After the system board has been removed from the original system, it can then be inserted into an alternate system, powered up, and registered with the active Solaris operating environment instance.

Both the Starfire and Sun Enterprise 3000-6500 platforms share the risk of having bent pins damage the backplane interface and bring down the whole Solaris operating environment instance when exercising physical sharing. The Starfire DR eliminates the danger of having bent pins or worn out connectors by allowing the logical relocation of system boards between DSDs.

Note

Physical removal or installation of system boards might invalidate service contracts if attempted by non-qualified service personnel.


Memory Interleaving

The Starfire and Sun Enterprise 3000-6500 platforms require that memory interleaving be disabled in order to support DR. Memory interleaving helps increase memory subsystem performance by reducing the probability of hot spots or contention in a few memory banks by spreading access to multiple memory banks.

The active Gigaplane-XB™ interconnect on the Starfire provides main memory access through a point-to-point data router, which isolates data traffic between system boards and minimizes any performance degradation when memory interleaving is disabled. The passive Gigaplane bus interconnect on the Sun Enterprise 3000-6500 platforms is shared by all system boards and may introduce performance degradation with memory intensive workloads when memory interleaving is disabled.

System Board Diagnostics

The Sun Enterprise 3000-6500 DR executes POST as soon as the system board is attached to the system. The Sun Enterprise 3000-6500 system boards do not have hardware isolation applicable to DSDs and will expose the server to the possibility of bringing down its active Solaris operating environment instance by registering faulty on-board components. The Starfire DR, in contrast, controls the POST operation from the SSP over the JTAG (Joint Test Action Group, IEEE Std. 1149.1) interface and does not activate a newly attached system board until its full functionality is guaranteed.

Note

The Starfire DR allows an increased test coverage on all system board components by temporarily increasing the POST level through modification of the SSP's postrc(4) file).


User Interfaces

Both the Sun Enterprise 3000-6500 DR and Starfire DR functions have their own private user interfaces that require manual intervention from a system administrator. The Sun Enterprise 3000-6500 DR uses the SyMON framework and the cfgadm(1M)command interface to invoke the required DR functions.

The cfgadm(1M) command provides an interface to build automated DR scripts. Script building for unattended DR operations must be handled with caution when detaching a system board because removing system resources may have a negative impact on applications executing in the machine.

The SSP manages all the resources that are allocated to DSDs and keeps track of their boundaries; thus, it has to initiate all DR operations. The Starfire DR is performed through the following SSP applications:

  • The drview(1M) command, which produces a GUI to be invoked only through the hostview(1M) interface, see FIGURE 8-2.

    Figure 8-2. The SSP Hostview drview Application

  • The dr(1M) command, a Tool Command Language (TCL) application that produces a command line interface monitor that supports a set of commands that integrate all DR functionality, see FIGURE 8-3.

    Figure 8-3. The SSP dr Monitor Application

Currently, the Starfire DR user interface does not provide mechanisms to automate DR operations. The current user interfaces are exclusively interactive.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
13.58.244.216