 |
Description  |
|
|
TABLE OF CONTENTS
1. BACKGROUND OF THE INVENTION
1.1 Environment Overview
1.2 Configuration Management as Illustration of General Problem Class
1.3 Some Prior Approaches
2. SUMMARY OF THE INVENTION
3. BRIEF DESCRIPTION OF THE DRAWINGS
4. DETAILED DESCRIPTION OF SPECIFIC EMBODIMENT
4.1 Overview of Illustrative System
4.2 Central Configuration Database Templates
4.3 Template Hierarchy With Virtual Hosts
4.4 Template Subsystem Components
4.5 Illustrative Structure of a Template
4.5(a) State of Template at Subscription Time
4.5(b) State of Template at Steady-State
4.5(c) Post-Initialization Database Update Operations
4.5(d) Pushing versus Pulling of Information
4.5(e) Support for Heterogeneous Environments
4.6 Format of Template Database Structures
4.7 System Management Policy Considerations
4.7(a) Authorization and Security Delegation Considerations
4.8 Scalability of the Template Model
4.8(a) Some Other Advantages of the Template Model
4.9 Review: Management-by-Subscription
5. CLAIMS
ABSTARCT
1. BACKGROUND OF THE INVENTION
We describe and claim in this specification, an invention relating to a computer system to increase the ease and efficiency of the configuration management task of large, complex, distributed networks of heterogeneous systems.
Microfiche appendix A (2 microfiche sheets with 157 frames) sets out source code for one implementation of the invention. Microfiche appendix B (2 microfiche sheets with 102 frames) sets out copyrighted manuals concerning a commercial software
package, created by the assignee of the application, which incorporates aspects of the invention. (Microfiche appendices A and B contain a total 4 microfiche sheets of 259 frames.) Permission is granted to make copies of the appendices solely in
connection with the making of facsimile copies of this application or any patent issuing therefrom in accordance with applicable law; all other rights are reserved, and all other reproduction, distribution, creation of derivative works based on the
contents, public display, and public performance of the microfiche appendices or any part thereof are prohibited by the copyright laws.
1.1 Environment Overview
FIG. 1 depicts a typical (hypothetical) computer network system 100. A variety of components 105 are connected by a variety of communications links 110. The components 105 usually are programmable machines and might be, for example, a mainframe
computer, a file server, a workstation, a personal computer, a printer, a complete network, or one or more computer programs (i.e., "software," executing on one or more computers). This latter category of network element may include a variety of
software services such as naming services, directory services, and the like. In addition, the components 105 may be from a variety of hardware vendors and may be executing a variety of different operating systems and software. The communications links
110 may be, for example, direct connections, telephone links via modem, or satellite hook-ups. A system 100 such as that shown in FIG. 1 is often referred to as a "distributed system."
Management of a distributed system has many aspects including configuration management (discussed in more detail below), network security management, monitoring of network events and data, analysis of the performance and activity on a network,
management of application software, operations management which includes daily activities such as disk file back-up and restore operations, and network management which is the management of the communications themselves--including monitoring of network
traffic and hardware failures resulting in lack of connectivity.
1.2 Configuration Management as Illustration of General Problem Class
The invention relates to the configuration management of each network element in a distributed system as an illustration of a more general management approach. Here, a "system" may be a host computer, application program, or any other
hardware/software logical entity that maintains a configuration database. The management problem includes, for example, determining from time to time and often on a real-time basis:
1. which users have access to each system;
2. what privileges each user has on each system;
3. what file systems are imported or exported from each system;
4. what networks and/or other machines are addressable from each system; and
5. what printers are available to each system.
FIG. 2 shows an expanded view of a distributed system 100. Each component 105 can be seen to maintain its own local configuration database 200 which may contain the kind of information described earlier, e.g., users, printers, available file
systems, etc. This information describes the configuration of each component 105.
To continue with the problem statement, the configuration databases 200 tend to be similar for similar types of network components 105 within a particular instance of a distributed system. They are not necessarily identical however, and this is
part of the distributed system management problem--maintaining a large amount of similar but not necessarily identical information across a distributed network.
Individual databases 200 are not necessarily identical a) because each component 105 may serve a different purpose in the distributed system and b) by virtue of the fact that the systems 105 can be products from different vendors they may be
heterogenous. Thus, the actual "native" format of stored configuration data in one element 105 may be different from that of another element 105, even though they are describing similar entities. Furthermore, the data storage format of each element may
be defined by the vendor of that element and, therefore, may be out of the control of the network owner or manager.
Configuration management of a system such as that shown in FIGS. 1 and 2 not only involves maintaining the native configuration databases 200, but also entails determining what action to perform when a change is made to an element 105's
configuration. Examples of such actions include: reread a database 200 which has been changed so as to make the changes effective in modifying the element's behavior; to create new files and directories which are independent of the configuration
database but which are in the element's file system; or to start or stop system processes.
As a result of these influences, system configuration information can be widely dispersed, poorly correlated, difficult to maintain, and frequently inconsistent. Adding to this situation is the largely dynamic nature of a network which can grow
as new hardware and software elements are added. Such additions of a single component 105 may cause the configurations of some or all of the other components 105 in the network 100 to need to be changed to reflect the new element.
It is also difficult for a system administrator of such a network because of the inherent difficulty of obtaining and understanding, in a single logical view, what the network is, i.e., what the configuration of every element in the system is.
There seems to be a natural tendency for the configuration of such networks to evolve towards chaos.
This problem is compounded by the fact that there are multiple users, see FIG. 3. Each user 300 that uses the system may have access to change some or all of the network's configuration information. Organizationally, there may be individuals
that are responsible for the overall administration of the network, or parts thereof 305. The combined actions of all of these users contribute to the aforementioned chaos in that their actions may conflict and/or result in inconsistent configuration
information being stored at different locations in the network.
Another aspect of distributed system configuration management is the notion that system administrators 305 need to be able to enforce a consistent set of rules as to how, for example, new users are created and the various configurations that they
are subject to at the time that they are created. Often, one or more central administrators has responsibility for an entire distributed system 100. These central administrators may work with other administrators who may have responsibility for a
subset of the system 100, and users who may desire to make small changes to their own systems 105.
Implementing this kind of control over procedures and rules is usually done through word of mouth, paper and other types of written documentation, and an understanding (by both the system administrators and individual users) of what they are
supposed to do--often, however, there is no enforcement. This ad hoc approach can make it difficult to implement, and enforce, a consistent and coherent configuration management policy.
1.3 Some Prior Approaches
A number of prior approaches have attempted to address the problems discussed above. Our present understanding of pertinent features of some of those prior approaches is summarized in Table 1.
A public domain software package, rdist, is distributed as part of the University of California at Berkeley's UNIX operating system. Rdist implements a simple file distribution mechanism: files located at a central repository are copied to
remote sites of the distributed system, elements 105 in FIGS. 1, 2, and 3. Rdist can do some comparisons of dates and times on the files to determine what files need to be updated from the central repository on the remote systems.
Another prior approach is seen in the Moira system, which was developed at the Massachusetts Institute of Technology as part of Project Athena to manage their distributed network. Moira can distribute files and, in addition, perform some actions
at the remote site after delivering the files. This is done by distributing scripts or programs along with the files. These scripts/programs can then be executed as a post-processing processing action. Moira also contains a feature which allows the
configuration information, which eventually become files at the remote sites, to be maintained in a central configuration database which is built upon a relational database.
Another widely used prior art technique is the network information services (NIS) product from Sun Microsystems. NIS takes a different approach towards configuration management in that it has a central configuration database which is accessed by
the client (remote) systems or components 105 in the distributed system 100. In NIS, configuration information, or at least some portion of it, is no longer to stored locally at each remote site; rather, the remote machines rely upon a central database
to receive their configurations. NIS does allow some limited capability for local overrides at the remote sites to the information that is in the central database. It does not have any form of post-processing at the client sites as does Moira. NIS
requires modification to the operating system of each element 105 in the distributed network and, in fact, in order to be effective, must be part of the component vendor's operating system distribution. For example, Sun Microsystems delivers NIS as part
of their operating system product, as do some of the other major UNIX vendors.
TABLE 1 ______________________________________ Selected Features of Prior Approaches ______________________________________ rdist public domain software (UC Berkeley) simple file distribution can do some date/time comparisons to determine
what files need to be updated Moira developed at MIT as part of Project Athena distributes files and performs actions at a remote site somewhat object-oriented configuration information maintained in a central configuration database Network
Information Services (NIS) commercial product from Sun Microsystems (SunSoft) central configuration database which is accessed by client systems limited local overrides to information in central configuration database no post-processing at the
client (remote) site ______________________________________
NIS+ is a next-generation product from Sun Microsystems. It is similar to NIS but is enhanced in many ways. It has a hierarchical set of configuration databases but still shares the feature that client sites access a central database server
machine to receive their configuration information.
2. SUMMARY OF THE INVENTION
The invention relates to a method executed by a computer system to increase the ease and efficiency of the configuration management task in large, complex, distributed networks of heterogeneous computer systems. In a paradigm referred to as
management-by-subscription, a central configuration database, maintained by a manager machine, is used to store system configuration information.
Individual systems (e.g., computers and other programmable machines) express interest in receiving configuration information from the central configuration database through a process known as subscription. By subscribing to the central
configuration database, a system establishes a persistent relationship (also stored in the central configuration database) through which it becomes eligible for future distributions or updates of the configuration information to which it subscribes.
The illustrative example, described herein, of the management-by-subscription paradigm uses object-oriented programming technology to define a class of template objects. Template objects provide the interface through which system administrators
maintain configuration databases and establish a consistent and coherent set of configuration management policies or operating guidelines. It will be appreciated by those of ordinary skill having the benefit of this disclosure that the invention can be
implemented without the benefit of object-oriented techniques without departing from the inventive concept described herein.
End-point systems (i.e., individual computer systems or other programmable machines within the distributed system itself) can subscribe to individual template objects, to logical collections of template objects--known as a virtual host, or to a
combination of templates and virtual hosts. Virtual hosts give an administrator a means of collecting different configuration data and associated operating policies (expressed as templates) into a single logical entity. By subscribing to a virtual host
a system is, in reality, subscribing to a predetermined set of policies and configuration data.
Management-by-subscription, through the use of template objects, allows distributed system's administrators: (1) to divide management tasks between different individuals while maintaining system security; (2) to provide a consistent means of
propagating configuration data and enforcing management policies; and (3) encourage configuration consistency across different platforms.
3. BRIEF DESCRIPTION OF THE DRAWINGS
FIGS. 1 through 3 are block diagrams of typical (e.g., prior art) heterogeneous and distributed computer networks.
FIG. 4 is a block diagram representing the (high-level) logical structure of a management-by-subscription approach in accordance with the invention.
FIG. 5 is a block diagram representing an implementation of configuration templates.
FIG. 6 is a block diagram representing a possible relationship between templates and user end-points through the invention's virtual host construct.
FIG. 7 shows the class hierarchy of a template object.
FIGS. 8 through 10 show progressively more detailed block diagrams of the use of template objects to create an organized configuration management system.
FIG. 11 shows the structure of a single record of a template object's configuration database.
FIG. 12 is a block diagram representing how a system in accordance with the invention efficiently distributes configuration information between two interconnected local area networks.
4. DETAILED DESCRIPTION OF SPECIFIC EMBODIMENT
One illustrative embodiment of the invention is described below as it might be implemented on a general purpose computer using a suitable high-level language such as C, C++, or Objective-C. In the interest of clarity, not all features of an
actual implementation are described in this specification. It will of course be appreciated that in the development of any such actual implementation (as in any software development project), numerous implementation-specific decisions must be made to
achieve the developers' specific goals and subgoals, such as compliance with system- and business-related constraints, which will vary from one implementation to another. Moreover, it will be appreciated that such a development effort might be complex
and time-consuming, but would nevertheless be a routine undertaking of software engineering for those of ordinary skill having the benefit of this disclosure.
For purposes of further illustration, microfiche appendix A includes source code for one implementation of the invention. Microfiche appendix B includes copyrighted manuals containing general use information concerning a commercial software
package distributed by the assignee of the application program which incorporates the invention.
4.1 Overview of Illustrative System
FIG. 4 illustrates our general approach to the distributed system's management problem, which we call management-by-subscription. In this paradigm, there is a central configuration database 400 is maintained as part of a manager machine 405 and
contains configuration information of various types which may be used by the various components 105 of the distributed system. Such configuration information may include information usable to configure a component 105 to a specified operational use,
e.g., as a "spreadsheet" machine.
Distributed components 105 express interest in receiving configuration information from the central configuration database 400 through a process we call "subscription." By subscribing to the central configuration database or, as we shall see in
FIG. 5, to a particular portion of the central configuration database, the component 105 establishes a persistent relationship which is also stored in the database 400 through which it becomes eligible for future distributions or propagation of the
configuration information to which it subscribes.
A system administrator 305 is able to edit the central configuration database and that is, in fact, part of the invention: an interface for making edits to that database. As can be seen in FIG. 4, however, each vendor component 105 continues to
maintain its own local subscriber database 200. When information from the central configuration database 400 is propagated out to a remote site 105, it is in fact copied into the correct location at the remote site via one or more electronic template
signals.
4.2 Central Configuration Database Templates
An example view of the central configuration database 400 is shown in FIG. 5. The central configuration database is now seen to be organized into a set of templates, for example 500, 505, and 510. A template is defined as a data structure
organized to model an abstraction of some portion of a system or network configuration. Each template logically maintains a database of configuration information.
Information is stored in a template in a platform-independent way. This means the information is not stored in a format specific to any of the specific vendors of the components 105 who may be subscribers (e.g., in the native formats of the
components 105), but rather is kept in an abstracted form, sometimes referred to as a "configuration format." For example, in the case of the user template 505, the user information is typically stored on a UNIX system in a file called /etc/passwd. On
most UNIX systems there are variations to what files are used and what information is in each file, i.e., from one vendor's operating system to the next. The user template 505, however, simply stores the pertinent information that describes a user
account in a manner which is independent of what destination file and format that information may eventually be stored in once it reaches the component 105 at propagation time.
Subscribers, which are the components 105, may pick and choose the configurations to which they subscribe out of a set of templates available in the central configuration database 400. Typically, what is found is not only multiple types of
templates such as shown here (file system templates 500, user templates 510, and group templates 510) but also a number of different instances of each type of template. There may be several instances of user templates 505, each of which may describe one
set of users versus another set of users. For example, a particular system may have accounts for users from templates 505 A, B, and C, while another system may only allow accounts from users of templates A and B.
Up to this point, we have discussed subscribers as if they were hardware entities. This is the common, but not the only, case. Subscribers can be of two types:
1. Template End-Point: A resource in a distributed system that maintains some sort of actual system configuration and thus can be a destination for a template configuration. For example, a host is a template end-point which, in the case of
UNIX, typically will store configuration information in one or more files in the /etc directory. An NIS domain may also be a template end-point, in which case when configuration information is propagated to that type of end-point, it is stored in an NIS
database. The same is true for NIS+.
2. Virtual Host: A mechanism to logically group collections of templates.
The Virtual Host concept is discussed in more detail below.
4.3 Template Hierarchy With Virtual Hosts
FIG. 6 shows a subscription hierarchy including a series of templates T1 through T7, virtual hosts 605, 610, 615, and template end-points 105. Each template, T1 through T7, represents a single template similar to the file system templates 500,
user templates 505, and group templates 510 shown in FIG. 5.
A virtual host is defined as a collection mechanism for templates. It has the feature of multiplexing template-to-template end-point subscription relationships. The potential number of template end-points (e.g., a personal computer or
workstation) can be tremendous in a large distributed network. There may be a large number of templates to describe all the different possible configuration information. The number of arrows--representing subscription relationships in FIG. 6--that
would need to be drawn if there were no virtual hosts could be large. As a result, the complexity of maintaining the subscription relationship would be very large.
One purpose of the virtual host is that it can be used to define an effectively complete host configuration; thus the term "virtual host." A virtual host subscribes to at least one template and, by virtue of this, forms a grouping of templates.
This grouping can be a description of a complete host configuration, for example. By then subscribing individual hosts (end-points 105) to a virtual host, the individual hosts are caused to subscribe to all of the templates which are subscribed to by
the virtual host and, as a consequence, the individual hosts become eligible for distributions of those templates.
A common characteristic of distributed systems is that when there are large numbers of template end-points, e.g., hosts, they tend to be grouped into categories that are often related to specified operation configurations for the hosts. For
example, as shown in FIG. 6, there may be a group of computer systems for computer-aided design (CAD) which are labelled Host CAD I and Host CAD 2. There may be another group of computer systems which are used for desk-top publishing which are labelled
Host Pub1, Host Pub2, and Host Pub3. These two different groups of end-points may have nearly identical configurations. By using the virtual host construct, a system administrator can define a virtual host which describes the typical CAD configuration
605 or the typical desk-top publishing configuration 610. Subscribing the individual hosts or end-points (Host CAD 1, Host CAD 2, Host Pub1, Host Pub2, and Host Pub3) to the appropriate virtual host makes it simpler to maintain, and manage, a consistent
configuration.
Another purpose of the virtual host is to ease the installation of new hosts (end-points) into the network by simply subscribing them to a predefined virtual host. By propagating the templates from that virtual host to the new host, the new host
is immediately configured as it should be. This is as opposed to having to remember that for this type of host, one needs to subscribe to n number of templates. The system administrator simply subscribes a new "physical" host to a single virtual host.
The subscription relationships described in FIG. 6 are such that virtual hosts may subscribe to any number of templates. A template end-point may subscribe to either a single virtual host, to a number of virtual hosts, or to some combination of
virtual hosts and templates. Thus, individual end-points can still subscribe directly to templates. The virtual host is an optional component in this hierarchy.
4.4 Template Subsystem Components
A hierarchical representation of th | | |
