Welcome to OS Installation Management › OS Installation Management Architecture

OS Installation Management Architecture

This chapter describes the architecture of OS Installation Management (OSIM).

The following picture shows the OSIM architecture.

Domain Manager

The domain manager is the central site of the OS Installation Management.
The domain manager contains all information about target computers, boot servers and boot OS images. It initiates and controls all the actions in the OS installation network. The information is kept in a database named MDB. The front ends in the distributed networks are the scalability servers, including the boot servers.

DSM Explorer

The DSM Explorer is the graphical user interface (GUI) for the domain manager. The DSM Explorer offers a comprehensive set of methods to drive and control the entire OS installation management network.

Image Prepare System

The Image Prepare System (IPS) is used to build the images and register them at the domain manager. The OS Installation Management differentiates between OS images and boot images. An OS image includes all OS files needed for the unattended OS installation at the target. A boot image is used to prepare a target for the OS installation and initiate the OS installation. Both types of images can be built on an Image Prepare System, and the images can be customized by adding boot parameters, default values, or procedures.

Boot Server

The OS installation works with so-called boot servers that can be set up in the network.
"Boot servers" are a functionality of scalability servers.
The boot server (BS) stages the images for all the attached PXE targets together with the boot parameters and the installation request for the different target systems. The boot server includes a PXE and a Trivial File Transfer Protocol (TFTP) service, which respond to PXE-boot requests from targets.

Note: The scalability server provides a point of buffering (staging) and resilience between end systems (agents) and a domain manager. The scalability server provides for massive scalability. Rather than having all the individually managed end systems (agents) communicating directly with a single domain manager, the load can be shared across multiple scalability servers.
For example, software packages can be staged on a scalability server before downloading to end systems, and inventory can be stored at the scalability server before being uploaded to the domain manager.