Resource management in the Cronus distributed operating system
Authors: Schantz R. , Schroder K. , Neves P. 
Published: October 2004

Cronus [1-7] is an object oriented distributed system which operates in a heterogeneous computer environment of interconnected local area networks. As a distributed system architecture. Cronus faces a number of resource management issues not present in non-distributed architectures. Strategies for effectively controlling the redundancy and reconfigurability inherent in Cronus are needed to take advantage of the distributed system environment. These strategies for resource management are often conveniently separated into policies and mechanisms. A policy is a goal or guideline set by a system administrator or component designer constraining the decisions made by a resource allocator. A mechanism is an internal system structure designed to implement a class of policies.
In the Cronus distributed system model, there are currently two general aspects of resource allocation mechanisms which are particular to the network environment and must be effectively managed. One of these is the binding of a client request to a particular resource manager for those resources which are available redundantly. Redundancy comes in two forms: replicated objects, (e.g., a multi-copy file) and replicated managers (any manager for a type can create a new instance of that object type). For both forms the selection of an object manager to provide the given service is an important resource management policy decision. The other important aspect of resource management mechanism is the ability to reconfigure parts of the system by dynamically migrating objects. Object migration is a powerful tool for matching system resources to tasks in a manner that attempts to maximize some measure of system performance, reliability, or survivability. Both static reconfiguration (e.g., choosing or amending the placement of object managers and their associated objects), and dynamic reconfiguration (e.g., moving an individual object in direct response to demand for its use possible in the Cronus architecture and design.
The general approach to resource management in Cronus is to individually control the management of the classes of objects which make up the system. This approach extends Cronus resource management concepts beyond system resources to the abstract resources developed by applications. Resource management for an individual abstract resource (type) and for groups of related resource types (services) in Cronus is based on combining a number of carefully planned mechanisms which are part of the system architecture. In addition to resource management by resource type, a client specific policy which considers collections of object types used in a specific context can be constructed.
In Cronus we achieve system wide and easily controllable resource management by requiring the object managers to cooperate in enforcing a resource management policy for their resource type. An object manager can redirect operations to a peer manager on another processor on the basis of current resource status. In the case for creation of a file to an alternate file manager which may have more storage available. Part of the basis for decisions to redirect requests are parameters, settable dynamically by system administrators through monitoring and control functions, which control the resource management strategy. The creation of objects and resource management in general thus becomes a responsibility that is decentralized among object managers on each processor based on a global allocation policy, both in terms of sharing current status and possible redirection of operations between managers.

The Cronus resource management model is based on the integration of the following set of primitive mechanisms:

the kernel routes requests for a given type to any available manager of that type, using the Locate mechanism

Cronus managers redirect requests to a more appropriate peer to accomplish resource management objectives

managers periodically collect current status of their peers, via a standard mechanism (ReportStatus), to be used as a basis for selecting a site for redirecting an operation

users and applications optionally indicate specific location preferences with requests

an operator can monitor and regulate the functioning of the resource management policy

applications can use the basic system mechanisms (e.g. broadcast or multicast, ReportStatus operations) to build special-purpose resource management strategies tailored to their need

There is a hierarchy of desirable locations for implementing resource management policies: object managers, shared libraries, and finally client programs or users themselves. Managers are the most desirable because they are readily identifiable with a limited set of object types which are likely to have similar policy goals. Also, managers are addressable as a group for administrative control to regulate the policy parameters, and for peer manager cooperation to implement the policy. Many decisions are negotiated between managers based upon information periodically obtained via the ReportStatus operation. The Cronus Monitoring and Control System uses the same ReportStatus operation to present the operator with a global view of how well the resource management policy is proceeding.
In this paper we elaborate on these approaches to distributed resource management in Cronus, including appropriate background, detailed system design, and experiences with incorporating these ideas into three different resource managers.