To the RSM user, OOS provides a means of maintain
ing information about cl ients and RSM servers. Inter
nally, OOS provides the basic user-interface services:
the command-line interface, the menu interface,
32
indirect command file execution, and miscella
neous routines shared by the other components.
RSM takes advantage of the namespace provided by DNS to store information about RSM clients and servers 4 DNS also provides RSM with a powerful abstraction call ed groups, which makes the manage
ment of large numbers of systems more tractable.
Groups in DNS and RSM are collections of object names. In RSM, groups can contain names of RSM clients, RSM servers, and other groups, thus forming a basis for hierarchical group naming schemes. In almost all cases in which a client or server name can be specified in RSM, a group name can be substi
tuted . RSM expands the group to the unique set of names in the group (permitting group memberships to overlap) and filters out objects that would not make sense to the command. (For example, server names are omitted when the context implies client names.) RSM uses the group facility as a shorthand, or macroexpansion, facility; separate commands are i nternally generated from the user's external com
mand so that the operation for each member of the group can fail or succeed on its own merit.
Software Distribution Services
SDS provides system managers the functionality to install applications and operating systems, from a centralized server, onto another system in the net
work . sos supports two of our earlier mentioned goals in that it performs a primary system manage
ment function, and it also scales wel l in a network environment. Installation of an application can con
sume one to two hours of a system manager's time.
An operating system i nstallation can take as long as eight hours. As discussed below, the RSM manager must i nvest a comparable amount of time to install the i nitial copy of the software in the SDS library server, but all subsequent i nstallations require only a fraction of that time.
The server is responsible for initiating and track
ing requests, and the clients are the recipients of these requests. SDS can be further broken down i nto three components: the management server, the library server, and the client. The management server provides the SDS user i nterface and is the stOr
age place for SDS files (such as the SDS databases, SDS executables, and log files) . The second compo
nent, the library server, is a file hierarchy for storing copies of software for subsequent network installa
tions. Before software can be installed using SDS, a copy of the software must exist in the SDS library.
The library server is a passive system and is merely a repository for software. All processes that comrol the copying of files in or out of the library server are initiated on the management server. By default, the
No. 9 june 1989 Digital Tecbnica/]ournal
Remote System Management in Network Environments
management server is also a library server. However, the RSM manager has the option of insta l ling the RSM server software on other VAXjVMS systems to config
ure additional SDS l ibrary servers. This option a l lows the RSM manager to determine which system is best su ited for the centralized initiation of requests and which system is best suited for storing copies of software. Finally, the third component of SDS is the client. To supply management services to another system on the network (an RSM client) , the RSM client software must be insta l led on that client sys
tem . To do this, the system manager can use SDS itself. Once the RSM server kit has been completely installed, the RSM manager can use the SDS compo
nent to initiate the installation of the RSM client kit on the appropriate client systems.
SDS Concepts One of the primary functions of SDS is to duplicate the installation of software on many systems in the network, exactly as the installation was performed on the original (source) system .
To take advantage of cloning, a master copy of some software must exist in the SDS library. First, the RSM system manager must create a copy of the soft
ware. For an operating system , this means using the standard VMS or ULTRIX installation procedures tO create a VMS or LTRIX system . For a layered prod
uct, this means using an RSM procedure called TRIALINSTALL, which will invoke either VMSINSTAL or setld for VMS and ULTRIX systems respectively.
Then this copy must be copied into a sos library server. Once there, it is available to be c loned onto other RSM client systems.
Creating this copy takes as long as a normal instal
lation of the application , mainly because the RSM manager is actually installing the application on the designated system . However, once the appl ication has been copied into an SDS l ibrary server, subse
quent installations only require the RSM manager to initiate the appropriate SDS installation request on the management server. Therefore , although the
RSM manager is required to insta l l the software once before copying it into an SDS library, all subsequent installations only require the manager to initiate the task. SDS assumes the responsibility of install ing the software on one or more c lients and reporting the status back to the manager.
SDS expands on this basic capability by employing groups and appl ication sets . The support for groups is provided by BOS, and the support for application sets is provided by SDS. Similar to a group , applica
tion set members are either other appl ication sets or a single application name . By combining both groups and application sets, the RSM manager can enter a single com mand that represents the installation of many applications on many clients. Figure 1 shows an example of how these set mechanisms are used.
One sos command initiates an i nstallation of all of the applications that are members of the application set Languages to all of the RSM client systems that are members of the group Areal .
SDS Process Row All sos com mands can be clas
sified as either synchronous or asynchronous . The synchronous com mands are specific actions on the SDS databases (such as create, modify, and view) , whereas the asynchronous commands allow the RSM manager to copy software into an SDS li brary or ini
tiate installation requests onto RSM client systems.
To explain the process flow of a typical SDS request, we present an overview of both synchronous and asynchronous requests in this section .
Al l synchronous requests are handled directly on the management server by the SDS user interface . The user interface performs syntax checking, sup
plies any appropriate default va lues and token inter
pretations, and then executes the specified request.
All (successfu l) asynchronous requests go through the same data path as synchronous requests. Addi
tionally, after an asynchronous request is processed by the user interface, a client-system-specific work
D I STR I BUTE > I n s t a l l App l i cat io n Languages Area 1 The app l i ca t i on s e t Language s
con t a i ns : The group Area 1 con ta i n s :
c FORTRAN
PASCAL
Figure 1 Using Set Mechanisms
Node_ 1 Node_2
Node_n
Digital Tecbnical]ounull No. 9 june 1989 33
RSM DATABASE
SERVER RSM
Figure 2 RSM Configured in a Wide Area Network
file is created. If there is no background job cur
rently working on other requestS for the specified RSM client system , t hen a VMS batch job is created to handle the work fi le. Otherwise the work file is updated and the currently running job handles this request. It is the responsibil ity of this batch job to execute the asynchronous request. If the request is to insta ll an operating system, the job uses the DECnet Ethernet boot facil ity to initiate the installation on the RSM client system . For all other asynchronous requests, the job contacts the RSM client software and passes down the appropriate control informa
tion; the client system then executes all appropriate actions. In all instances, once the request has been completed, it contacts the server to report its status along with status i nformation.
Backup and Restore Services
Ensuring the integrity and recoverabiliry of data is a prime responsibility of system managers. Data created by computer system users is an asset for a company and shou ld be protected as such. Since data is often modified on a daily basis, protection of that data requires that the data be conrinually duplicated and stored outside the syste m. In the past this process has typically been done by backing up disks tO local tape drives or floppy disk drives.
DRS provides the abil ity to backup and restore files (file systems) over a DECnet network for both VMS and ULTRI X client systems. The BRS software uses the backup uti l ity on VMS clients and either the dump or tar utilities (depending on the type of backup
34
being performed) for ULTRIX clients . A schedu ling and tracking system located on the RSM manage
ment server supports the actual process of backing up the files.
The design for the BRS subsystem is shown in Figure 2 . BRS has six components: the user inter
face, the database server, the backup sched u l er, the backup initiator, the restore i nitiator, and the com
mand execution agents (CEA) .
The user interface is activated by the DOS subsys
tem and parses DCL commands issued by the user.
Commands are ava ilable to add , modify, and delete schedule entries; display schedule entries, history records, and schedu ler status; and i nitiate ad hoc backup or restore operations.
The user interface communicates with the database server which manages two R.J\1S-indexed sequential fi les: the schedule file and the history fi le.
The schedule file contains basic information the date a backup shou ld occur and what data is to be backed u p . Entries i n the schedule database are organized by client name and a user-specified
" backup type." This organization allows the man
ager to name and schedu le different backups for any one c lient. (For example, one backup entry could be constructed to back up critical project files located on a system on a daily basis; whereas another entry would back up noncritical files over weekends.)
The history file contains an entry for each backup operation attempted by BRS. Within the history record are recorded the status of the backup and pointers
No. 9 june 1989 DigiUll Tecbnicaljournal
Remote System Management in Network Environments
tO the appropriate log, l isting, and save-sets (files where backup data is actually stored) . HistOry records are used by RSM when performing a restore operation. By specifying a particular history entry, RSM knows from where tO retrieve the save-set and where to rescore it.
The DRS scheduler is a process that resides on an RSM management server. The scheduler periodically scans the schedule file and determines if any client system needs to be backed up. When the scheduler determines that a backup should be scheduled, it creates a histOry record for the backup attempt. It then submits a batch job on the target server which wil l actually control the backup process.
A batch job on the target server runs the backup initiatOr program. The backup initiator secures resources for the backup save-sets, which can reside on a local disk or be directed to magnetic tape. I t then initiates a connection t o the RSM CEA o n the client system. The initiator instructs the CEA to run the appropriate backup uti lity and supplies it with the l ist of files/directories to be backed up. The save-set data and logging i nformation generated by the backup utility are passed to the CEA which mul
tiplexes the information over the DECnet connec
tion to the backup initiatOr process on the target server. The initiator, i n turn , unpackages the data and writes it tO the appropriate files or devices. BRS uses checksums tO assure data integrity over the net
work connection .
Once the backup is completed, the associated history record is updated to reflect a successful (or failed) backup. If specified in the schedule record, mail is sent to the appropriate parties indicating the status of the backup .
A similar process is used to restore fi les. However, by using information gleaned from the user-specified history record , the user interface bypasses the sched
uler process and submits a batch job for the restore initiator on the target server. The restore initiator then obtains access to the save-set data by directly accessing the files or requesting that a particular tape be mounted. The i nitiator then contacts the appro
priate client syste m's CEA and constructs a restore command which is executed on the client system .