Title of Invention	"A DEVICE AND METHOD OF MANAGING COMPUTER RESOURCE"
Abstract	A large distributed enterprise Includes computing resources that are organized Into one or more managed regions, each region being managed by a server machine servicing one or more gateway machines, with each gateway machine servicing a plurality of endpolnt machines. A distributed system management framework is supported on the gateway machines and the one or more r endpoint machines to carry out system management tasks. TO enhance scalability, the endpolnt machines support a low cost, low maintenance client component of the system management framework, and a corresponding server component Is supported on each of the gateway machines, on an as-needed basis, appropriate executable code and system management data Is delivered from a gateway to one or more endpoint machines to facilitate execution of a system management task for the managed region. Typically, the system management data is not stored in the endpoint, and this "dataless" approach reduces the complexity and maintenance costs associated with distributing the functionality of the system management framework. The endpoints are easily extensible to Include new application functionality without requiring the overall framework to be rebuilt or reinstalled.

Title of Invention

"A DEVICE AND METHOD OF MANAGING COMPUTER RESOURCE"

Abstract

A large distributed enterprise Includes computing resources that are organized Into one or more managed regions, each region being managed by a server machine servicing one or more gateway machines, with each gateway machine servicing a plurality of endpolnt machines. A distributed system management framework is supported on the gateway machines and the one or more r endpoint machines to carry out system management tasks. TO enhance scalability, the endpolnt machines support a low cost, low maintenance client component of the system management framework, and a corresponding server component Is supported on each of the gateway machines, on an as-needed basis, appropriate executable code and system management data Is delivered from a gateway to one or more endpoint machines to facilitate execution of a system management task for the managed region. Typically, the system management data is not stored in the endpoint, and this "dataless" approach reduces the complexity and maintenance costs associated with distributing the functionality of the system management framework. The endpoints are easily extensible to Include new application functionality without requiring the overall framework to be rebuilt or reinstalled.

Full Text	TECHNICAL FIELD: The present invention is directed to a device and method of managing computer resources. BACKGROUND OF THE INVENTION: Managing a computer network comprising thousands of nodes can produce 4 serious difficulties for system administrators. Management tasks, such as distribution of system-wide changes, must be carried out quickly and in a dependable manner in order to reduce the probability of catastrophic failure. Distributed computing environments that are known in the art do not scale easily to large size. One of the root causes of this deficiency is that prior art management environments include high overhead applications that, typically, are run on all of the managed machines in the network. In such systems, even machines located at the lowest level of management functionality (so-called "endpoints") often include a full suite of management routines and systems management data. Because the endpoint machine has its own database, it has to be backed-up to accurately back up the overall environment. As the number of such machines gets large, the time to backup all the distributed databases becomes great and the backup storage requirements become unmanageable. When endpoint machines fail, or when users t accidentally remove files, it is an enormous burden on system administrators to have to locate and restore the endpoint's database, especially if the missing database prevents the overall managed architecture from being able to distribute to the failed endpoint. Moreover, adding new application functionality to an endpoint machine typically requires the overall management architecture to be re-built, re-Installed or, at. least, re-lnltlallzed. This Is a time-consuming, complex administrative task that severely limits the flexibility and Increases the cost of system management. As a result of these problems, It has not been possible to Increase the size or "scalability" of such networks to a true "enterprise" level. The present invention addresses and solves these problems. RRH=F SUMMARY OF THE INVENTION it Is a primary object of the Invention touelf^^eqllyfilyjTTanage computing(resources In a large distributed enterprlsfierii^DDBm©nfe~ ^Tt is another object of the Invention to enable an enterprise to place substantially all of Its computing resources on a network that Is managed In a reliable, cost-effective manner. It Is still another object to reduce the complexity and cost of systems management In a large enterprise environment by supporting a low cost, low maintenance management framework on the vast majority of machines (e.g., the personal computers or PC's) In the enterprise. Yet ajnother QSJgctJs jojgnhajice jthescalability of a large distributed computing network by distributing the functionality of a system management framework In accordance with a "client-server paradigm. A more specific object of the Invention Is to Implement a low cost, low maintenance component of a system management framework at the endpoint machines that comprise the largest percentage of computing resources In the enterprise environment. It is another more particular object to support a minimal set of applications on "dataless" endpoint machines of a large, distributed environment to facilitate systems management. It is still another object of the invention to meet the needs of customers with very large and geographically-dispersed networks and, more particularly, to significantly expand the scalability parameters of traditional management tools and techniques. Yet another important object is to enable PC connectivity in a large centrally-managed network enterprise. These and other objects are achieved, according to Claim 1, with a method of managing computing resources in a large distributed enterprise, comprising the steps of: organizing the computing resources into one or more managed regions (12), each region being managed by a server machine servicing one or more gateway machines (16), each gateway machine servicing a plurality of endpoint machines (18); executing system management tasks affecting a managed region by the steps of delivering automatically, on an as-needed basis, executable code and system management data required for a system management task from a gateway machine to one or more endpoint machines serviced by the gateway and using a distributed system management framework supported on the gateway machine and one or more endpoint machines to carry out the system management task using the executable code and system management data, wherein said system management data is used by the one or more endpoint machine to facilitate execution of at least one system management task and is not stored there on a persistent manner; and, maintaining the computer resources by backing up system management data, generally being information collected or distributed as part of a system management task, only from the server and the one or more gateway machines. The objects are also achieved if the method, according to Claim 2, is characterized in that data is used by the one or more endpoint machines to facilitate execution of the system management task and is not cached for subsequent use. It is another more particular object to support a minimal set of applications on "dataless" endpoint machines of a large, distributed environment to facilitate systems management. It is still another object of the invention to meet the needs of customers with very large and geographically-dispersed networks and, more particularly, to significantly expand the scalability parameters of traditional management tools and techniques. Yet another important object is to enable PC connectivity in a large centrally-managed network enterprise. These and other objects are achieved, with a method of managing computing resources in a large distributed enterprise, comprising the steps of: organizing the computing resources into one or more managed regions (12), each region being managed by a server machine servicing one or more gateway machines (16), each gateway machine servicing a plurality of endpoint machines (18); executing system management tasks affecting a managed region by the steps of delivering automatically, on an as-needed basis, executable code and system management data required for a system management task from a gateway machine to one or more endpoint machines serviced by the gateway and using a distributed system management framework supported on the gateway machine and one or more endpoint machines to carry out the system management task using the executable code and system management data, wherein said system management data is used by the one or more endpoint machine to facilitate execution of at least one system management task and is not stored there on a persistent manner; and, maintaining the computer resources by backing up system management data, generally being information collected or distributed as part of a system management task, only from the server and the one or more gateway machines. The objects are also achieved if the method is characterized in that data is used by the one or more endpoint machines to facilitate execution of the system management task and is not cached for subsequent use. The objects are also achieved if the method, is characterized in that it further includes the step of caching the executable code for subsequent use. The objects are also achieved if the method, is characterized in that at least some of the endpoint machines are personal computers. The objects are also achieved if the method, is characterized in that each of the endpoint machines runs a client component of said system management framework and wherein the gateway machine that services the endpoint machines runs a server component of the system management framework. The objects are also achieved if the method, is characterized in that the client component of the system management framework has an operating state that is normally idle. The objects are also achieved if the method, is characterized in that the server component of the system management framework executes in a multi¬threaded fashion. The objects are also achieved with a device, within a large distributed enterprise, said system comprising a server machine (14) servicing a set of gateway machines (16), each of which services a set of endpoint machines (18), the server machine, the gateway machines and the endpoint machines of the system comprising means adapted for executing a method according to anyone of claims 1 to 7. These objects are also achieved if, the device is characterized in that the system management framework means on an endpoint'machine includes a deamon and an application runtime library. These objects are also achieved, if the daemon is responsible for endpoint login to a gateway machine and for spawning an executable downloaded from the gateway machine. Preferably, the system management framework is object-oriented. The foregoing has outlined some of the more pertinent objects of the present invention. These objects should be FIGURE 6 Illustrates the ORB/BOA object-Invocation mechanism used by the present Invention; FIGURE 7 Is a flowchart Illustrating how a gateway machine Invokes a method of an object running on an endpolnt machine to facilitate a management task; » FIGURE 8A Is a flowchart Illustrating how an endpolnt machine Initiates a file pull system management operation; and FIGURE 8B Is a flowchart Illustrating howan endpotnt machine initiates an Inventory system management operation. DETAILED DESCRIPTION Referring now to FIGURE 1, the Invention Is preferably Implemented In a large distributed computer environment 10 comprising up to thousands or even tens of thousands of "nodes." The nodes will typically be geographically dispersed and the overall environment Is "managed" In a distributed manner. Preferably, the managed envlronmeottME) isJoglcally broken down Into a series of loosely-connected managed regions (MR) 12, each with Its own server 14 for managing local resources with the MR. Multiple servers 14 coordinate activities across the enterprise and permit remote site management and operation. Each server 14 serves a number of gateway machines 16, each of which In turn support a plurality of endpotnts 18. The server 14 coordinates all activity within the MR using a terminal node manager 20. Referring now to FIGURE 2, each gateway machine 16 runs a server component 22 of a system management framework. The server component 22 Is multi-threaded runtime process that comprises several components: an object request broker or "ORB" 21, an authorization service 23, object location service 25 and basic object adaptor or "BOA" 27. Server component 22 also Includes an object library 29. Preferably, the ORB 21 runs continuously, separate from the operating system, and It communicates with both server and client processes through separate stubs and skeletons via an Interprocess communication (IPO facility 19. in particular, a secure remote procedure call (RPO is used to invoke operations on rernpte objects. Gateway machines 16 also Includes an operating system 15 and a threads mechanism 17. The system management framework Includes a client component 24 supported on each of the endpotnt machines 18. The client component 24 is a low cost, low maintenance application suite that is preferably "dataless" in the sense that system management data is not cached or stored there in a persistent manner, implementation of the management framework In this "client-server manner has significant advantages over the prior art, and It facilitates the connectivity of personal computers into the managed environment. Using an object-oriented approach, the system management framework facilitates execution of system management tasks required to manage the resources in the MR. Such tasks are quite varied and include, without limitation, file and data distribution, network usage monitoring, user management, printer or other resource configuration management, and the like. System management tasks Involve system management "data", which generally Is the Information collected or distributed as part of a particular system management task. in the large enterprise such as Illustrated In FIGURE 1, there is one server per MR with some number of gateways. For a workgroup-size installation (e.g., a local area network or "LAN") such as Illustrated in FIGURE 3, a single server-class machine may be used as the server and gateway, and the client machines would run the lost cost framework. References herein to a distinct server and one or more gatewayfe) should thus not be taken by way of limitation as these elements may be combined Into a single platform. For Intermediate size Installations, the MR grows breadth-wise, with additional gateways then being used to balance the load of the endpolnts. The server Is the top-level authority over all gateway and endpolnts. The server maintains an endpolnt list, which keeps track of every endpolnt In a managed region. This list contains all Information necessary to uniquely Identify and manage endpolnts Including, without limitation, such Information as name, location, and machine type. The server also maintains the mapping between endpolnt and gateway, and this mapping Is dynamic. Based on site-specific settings, It Is possible to reassign endpolnts when gateways go down or to automatically add new endpolnts as they appear on the network. AS noted above, there are one or more gateways per managed region. A gateway Is a full managed node that has been configured to operate as a gateway, initially, a gateway "knows" nothing about endpolnts. As endpolnts login (discussed below), the gateway builds an endpoint list for Its endpolnts. The gateway's duties Include: listening for endpolnt login requests, listening for endpolnt upcali requests, and (Its main task) acting as a gateway for method Invocations on endpolnts. AS also discussed above, the endpolnt Is a machine running the system management framework client component, which Is referred to herein as thejpjj\/_c^s^ramework (LCF).jrhe LCF has two main parts as Illustrated In FIGURE 2A: the Icf daemon 24a and an application runtime library 24b. The LCF daemon 24a Is responsible for endpolnt login and for spawning application endpolnt executables. once an executable Is spawned, the LCF daemon 24a has no further Interaction with It. Each executable Is linked with the application runtime library 24b, which handles all further communication with the gateway. Preferably, the server and each of the gateways Is a computer o/ "machine.". For example, each computer may be a RISC System/6000® (a reduced Instruction set or so-called RISC-based (workstation) running the AIX (Advanced interactive Executive) 6peratlng system, preferably Version 3.2.5 or greater. The AIX operating system Is compatible at the application interface level with the UNIX operating system, version 5.2. The various models of the RISC-based computers are described In many publications of the IBM corporation, for example, RISC Svstem/6000. 7073 and 7016 POWERstatlon and POWERserver Hardware Technical Reference, order No. SA23-2644-00. The AIX operating system Is described In AIX Operating System Technical Reference, published by IBM corporation, First Edition (November, 1985), and other publications. A detailed description of the design of the UNIX operating system Is found In a book by Maurlcej. Bach, Design of the Unix operating System, published by Prentice-Hall (1986). Suitable alternative machines Include: an IBM-compatible PC 486 or higher running Novell UnixWare 2.0, an AT&T 3000 series running AT&TUNIXSVR4 MP-RAS Release 2.02 or greater, Data General AVIION series running DG/UX version 5.4R3.00 or greater, an HP9000/700 and 800 series running HP/UX 9.00 through HP/UX 9.05. 'Motorola 88K series running SVR4 version R40V4.2, a Sun SPARC series running Solaris 2.3 or 2.4, or a sun SPARC series running SunOS 4.1.2 or 4.1.3. Of course, other machines and/or operating systems may be used as well for the gateway and server machines. Each endpolnt Is also a computer. In one preferred embodiment of the Invention, most of the endpolnts are personal computers (e.g., desktop machines or laptops), in this architecture, the endpolnts need not be high powered or complex machines or workstations, one or more of the endpolnts may be a notebook computer, e.g., the IBM ThinkPad® machine, or some other Intel x86 or Pentlum®-based computer running windows 3.1 or greater operating system. IBM® or IBM-compatible machines running under the OS/2® operating system may also be Implemented as the endpolnts. For more Infprmatlon on the OS/2 operating system, the reader Is directed to OS/2 fr.aTechnical library. Programming Guide volumes 1-5 Version 2.00. order Nos. 10G6261,10C6495 and 40G6494. AS noted-ataoverttre^erver-class framework running on each-gateway machine Is multi-threaded and Is capable of maintaining hundreds of simultaneous network connections to remote machines. A thread of execution may be a separate process (In the UNIX paradigm) or a separate thread In a single process (In the POSIX pthrf ads paradigm). POSIX is a series of standards for applications and user interfaces to open systems, Issued by the institute of Electrical and Electronics Engineers inc. (IEEE). The IEEE POSIX.1C is the emerging standard for user level multi-threaded programming and Is Implemented In the served component of the systems management framework. All objects In this framework exhibit "state." This state may be completely persistent, In which case It Is represented by attributes in the object database associated with a gateway machine, or the state may be non-persistent. An example of the latter might be the current list of machines that are down. in the preferred embodiment, the LCF Is the smallest amount of code that can still do useful endpolnt work. Generally, this means that the LCF code has the following characteristics: single-threaded, limited cascade and upcall capability, no persistent attributes and only a small set of CORBA runtime. Machines that see little management activity In a typical day are those for which the LCF Is particularly advantageous. Machines that need to service a large volume of requests preferably run the server component of the system management framework. The LCF Is always ready to do management tasks, but consumes few resources because It is normally In an Idle state. Preferably, each endpolnt Is "dataless" In the sense that system management data Is not stored therein before or after a particular system management task Is Implemented or carried out. Therefore, unlike the prior art, there Is no need to perform system backup or other conventional maintenance on the endpolnt (at least with respect to the system management framework). Maintenance on the server and gateway machines suffices, similarly, new application functionality may be added to the Icf without rebuilding, reinstalling or re-lnltlallzing the client component Into the system management framework. Since endpolnts are dataless and readily extensible, the architecture Is easily scaleable as Illustrated In FIGURE 1. The client component of the system management framework Is Inexpensive and requires little or no maintenance since much of the system management framework is off-loaded to the gateway machines that run the multi-threaded, server component. This architecture advantageously enables a rational partitioning of the enterprise with 10's of servers, 100's of gateway machines, and 1000's of endpolnts. Each server typically serves up to 200 gateways, each of which services 1000's of endpolnts. At the framework level, all operations to or from an endpolnt pass through a gateway machine, in many operations, the gateway Is transparent; It receives a request, determines the targets, resends the requests, waits for results, then returns results back to the caller. Each gateway handles multiple simultaneous requests, and there may be any number of gateways In an enterprise, with the exact number depending on many factors Including the available resources and the number of endpolnts that need to be serviced. Thus, according to the present Invention, one or more of the endpolnts 18 are "dataless." Except for the LCF executable Itself, preferably there Is no database or other state that must be kept on the endpolnt. Whenever executable code and/or system management data are needed for a particular system management task, such code and/or data are delivered from a particular gateway machine to the affected endpolnts machines automatically. Typically, the executable code and/or data will remain valid for the particular task Invocation; while the executable code may be cached, usually the system management data will not be. If the executable code Is cached, preferably the system management framework may be configured to automatically resend such code without operator Intervention If the cache Is lost or periodically flushed. An endpolnt Is added to the enterprise by first copying the LCF daemon 24a to the endpolnts disk. This may be done automatically through network login scripts, manually by Inserting a diskette, or by preloading the boot disk at the time of purchase or license. The first time the LCF daemon Is Installed, and on each subsequent boot, the LCF daemon attempts to login to Its gateway, if the gateway Is not known or If the gateway does not respond, the daemon Issues a broadcast requesting a gateway. For completely new endpolnts the broadcast Is ultimately forwarded to the server, if a gateway hears a broadcast or a login request from an endpolnt It recognizes, the gateway services the request Itself. When the server receives an endpolnt's gateway request broadcast, the server consults Its endpolnt list to see which gateway the endpolnt belongs to. For new endpolnts, or when migrating between gateways, the server uses a site specific policy to choose the correct gateway (e.g., by subnet). The gateway Is Informed of Its new endpolnt, the gateway Informs the endpolnt, and the login completes. An endpolnt preferably communicates only with Its gateway. Requiring all endpolnt communication to pass through a single gateway greatly simplifies connectivity Issues. After a successful login, both endpolnt and gateway know a working address by whlph to address one another. If a DHCP address lease expires, or anything changes In the network topology, then the next endpolnt login will establish the new endpolnt to gateway addresses. There Is no absolute maximum number of endpolnts that can be supported by a single gateway. The design strategy Is that the gateway Is always in control of Its own workload. The endpolnts are not allowed to send data unless granted permission. When an endpolnt has results to return, or If It wishes to make an upcall, It sends a very small message requesting service. The gateway queues the request and services the queue as time allows. When an endpolnt has large results, It must break the results Into chunks and may only send a chunk when Instructed to do so. This strategy makes It possible for a single gateway to support thousands of endpolnts, albeit somwhat slowly, if a better quality of service is desired, It Is simply a matter of adding more gateways. Endpolnt methods are normal CORBA methods (as discussed below) linked with IDL compiler generated code and the endpolnt application runtime library 24b. This results In a native executable designed to be spawned by the LCF daemon 24a. Any number of methods may be Implemented In a single executable. Preferably, an endpolnt Is Installed without any methods. Method executables are downloaded from the gateway as required. When the LCF daemon receives a method Invocation request, It checks the local disk cache, if there Is a cache miss, or a version mismatch, then a new executable Is downloaded, in this way, an endpolnt can start with nothing and then build a working set of methods for fast execution. Before Illustrating how the framework Is used, the following background Is provided. FIGURE 4 first illustrates how a systems management task Is Implemented. Each authorized administrator 30 has access to a desktop computer 32 containing one or more Icons representing system resources. AS administrators Interact with dialog screens and menus available from these Icons, they are able to change system configurations and manage new resources in the distributed environment, all In a known manner, in particular, when administrator 30 Interacts with the desktop, so-called "callbacks" (I.e. software that responds to the user's actions) are invoked from the user Interface on underlying objects representing some system resource or component. These callbacks are translated Into a series of method Invocations that actually perform the work and return results or status to the administrator. in particular, and with reference to the process flow diagram of FIGURE 4, the Information flow begins when the administrator 30 selects an Icon or Interacts with a dialog. The Information is then sent to the desktop (which may be connected to a server or a gateway) at step 34, at which time the appropriate application callback method Is Invoked at step 36. The callback method then invokes core application methods at step 38, which communicate with the application objectts) to perform some system management operation, as Illustrated at step 39. Any return information or state Is passed back at steps 40 and 41. if an update to the user Interface Is required, the desktop 32 Interprets the output and updates the dialogs on the administrator's desktop at step 42. preferably, the framework includes a task library that enables administrators to create "shell" scripts that can run an any managed node of the enterprise environment. A shell script Integrated with a managed node Is called a "task." When administrators want to create a task, they provide a machine and a path to an executable file. The executable can be a shell script, a specialized script, a compiled program or any other kind of valid executable. When a task is created, the executable Is stored as an attribute In an object database associated with a gateway machine. When the task Is needed, the executable file is retrieved from the attribute and is provided to one or more managed nodes. After a task Is created, It Is added to the task library and displayed as an icon. FIGURE 5 Illustrates howsystems managementapplicatlons are constructed from a set of standard object types that together constitute a general applications architecture for the framework. These standard object types are closely Interrelated and are used to build objects for system management applications. The objects provided by a management application can be divided Into one or more object types 44 that are managed by one or more Instance managers 46. An object type Is a set of objects that share a common Interface. Each object of the same type Is called an instance of the type. Within the systems management framework, object types are associated with a particular Instance manager. The instance managers are registered and stored In a library 48, which provides a central repository for system administration object Information within a managed region. AS referenced above, the systems management provides an implementation of a CORBA 1.1 object Request Broker (ORB), basic object adaptor (BOA), and related object services. CORBA 1.1 is a specification for an object-oriented distributed computer systems management architecture provided by The Object Management Croup (OMG), a non-profit association of more than 300 companies. CORBA describes the use of the Object Request Broker (ORB) and basic object adaptor (BOA) that provide a mechanism for object invocation and return of results. The specification defines interfaces to a set of low-level object services and enables such services to be Integrated in many different language and systems using object encapsulation, service requestor/provider isolation, and interface and Implementation separation. in a CORBA 1.1 Implementation as seen In FIGURE 6, there are three primary components: a client, an object implementation, and the ORB/BOA. The client 50 Is the requestor of a service that Is provided by an object implementation 52. The ORB 21 delivers the request from the client 50 to the object Implementation 52 through the BOA 27. The object Implementation 52 then performs the requested service, and any return data Is delivered back to the client. The client an,d object implementation are isolated from each other, and neither has any knowledge of the other except through their ORB/BOA interfaces. Client requests are Independent of the object Implementation location and the programming language in which they are Implemented. The ORB delivers the request to the BOA, which activates the process under which the object Implementation (e.g., a server) runs. The BOA then Invokes the method associated with the request by way of a server skeleton 61. When the method Is finished, the BOA manages the termination of the method and coordinates the return of any results to the client. Alternatively, If a request Is unknown until runtime, a Dynamic invocation interface (Din 55 Is used to build a request used in place of a client stub 63 linked at compile time. with the above background, several examples of how system management tasks are carried out using the client-server framework are now described. The following discussion Is merely exemplary, as the nature and type of systems management tasks that can be carried out by the framework Is unconstrained. As noted above, the system management framework Includes the server component supported on the gateway machines of the managed region, and the associated client component is supported on the endpoints serviced by the gateway(s). To provide transparent functionality, every method to be run on an endpoint s preferably configured on the gateway. All endpolnt object references (Objrefs) that other methods use to Invoke operations on an endpolnt are Objrefs and each endpolnt Is assigned to a unique object dispatcher number (odnum). The gateway machine then uses true object references to "point" to the actual endpolntts). The routine Illustrated In FIGURE 7 occurs when one method Invokes a method of an object on an endpoint. At step 70, the server 14 resolves the Objref/method to a specific method daemon on a gateway. At step 72, the gateway Is started (if It Is not already running) and passed a method activation record or so-called MAR block. The MAR block contains all Information necessary to Invoke a method Including the target Objref, the target method, "marshalled" input arguments and other fields from the server's method store. AS noted above with respect to FIGURE 6, when a request to run an operation on some object Is made, a client stub Initiates the request, collects the data associated with the request, and converts it from its current format to a common format. This process Is known as "data marshalling" and Is performed In accordance with the ASN.1 Standard. Up to this point, there Is no difference as far as the application Is concerned between this method Invocation and any other method Invocation. At step 74, the gateway looks at the Objref to determine the target endpolnt. A connection to the endpolnt Is then opened at step 76. The method continues at step 78 and queries whether the endpolnt has a copy of the executable for the method, if not, the routine continues at step 80 to retrieve the appropriate executable from the object database (based on the endpolnt's machine type), and the executable Is then sent to the endpolnt. At step 82, or If the endpolnt already had the necessary executable, the gateway sends the still-marshalled Input arguments to the endpolnt. At step 84, the gateway enters Into a wait state, waiting for the marshalled output arguments to be returned. When this occurs, the routine continues at step 86 and closes the connection to the endpolnt. The output arguments are then sent back to the server at step 88 and the routine terminates as though the method had executed locally. Endpolnt-Inltlated operations can now be described, in these types of operations, the endpoint first attempts to establish a connection back to Its gateway. Preferably, this Is done In the same way that the endpolnt client attempts to Identify Itself upon boot. It first tries Its last known gateway host; If It gets no response, the endpolnt then contacts the server's TN Manager routine either directly or, If that falls, via a BOOTP broadcast, once connected, the server component of the gateway Is Invoked and the endpolnt passes a descriptor telling the gateway which endpolnt has connected. Upcalls are method requests originating at the endpolnt. The Tlvoll courier™ pull Interface Is an example of a program making upcalls. Not all applications will need upcalls. An endpolnt makes an upcall by calling an IDL compiler generated stub. Unlike a normal method invocation, an upcall always Invokes a special upcall method on the gateway. An application that supports upcalls must provide both the endpolnt code and the special upcall method. The endpolnt upcall facility Is not a general purpose method Invocation Interface. This design maintains scalability by handling upcalls at the local gateway without management server intervention. An Illustrated "file pull" operation Is shown In FIGURE 8A. in this operation, the endpolnt-resldent code (I.e. the client component) Initiates a file request and the gateway-resident code (I.e. the server component) handles the request. The routine begins at step 96, with the user on the endpolnt Invoking a local program that Is part of the client component of a file distribution application. This step Invokes a method asking for a list of all available fllepacks. A "fllepack" Is a collection of files being distributed In accordance with a system management task. At step 98, the gateway receives the request, Invokes the server component of the file distribution application, passing It the descriptor Identifying the endpolnt. The software distribution program, running as a method on the gateway, Issues a name service lookup at step 100, filters out fllepacks that the endpolnt is allowed to receive at step 102, and then returns the list to the endpoint at step 104. Depending on the actions of the user, the endpolnt may then invoke another method asking for a specific filepack. FIGURE 8B illustrates an Inventory reporting system management task, in this example, assume that an inventory application is designed to collect Inventory Information (e.g., the hardware and software configuration details) from a machine whenever the machine is rebooted, it Is also assumed that an Initialization method has been run on each endpolnt to edit the appropriate boot-time script to run the Inventory report program on boot. The routine starts upon the next boot, in particular, at step 106, the program runs the local inventory report to produce a data file of Inventory results. At step 108, the endpoint connects to the gateway in the manner previously described. The endpolnt then Invokes an "Inventory report" method at step 110 and, at step 112, sends the results to the gateway. At step 114, the server component of the Inventory report method is Invoked and passed a descriptor Identifying the endpolnt. The Inventory results are read by the gateway at step 116 and, at step 118, forwarded to a central Inventory database object. The LCF Is designed with efficient distributions operations in mind. Each gateway is also a repeater for each of the gateway's endpolnts. This relationship is Implicit so It does not need to be set In the repeater configuration. Distributions fan out from the gateway to the endpolnts without further server support. Eliminating the server as a bottleneck makes distributions very scaieable. As can be seen, the endpolnt remains essentially dataless except as needed to carry out the particular system management task. This operation Is facilitated by distributing the system management framework across client components, supported on the endpolnts, and server components, supported on the gateways that service the endpolnts. As noted above, the LCF is extensible and thus new application functionality Is easily added to the system management framework without having to rebuild or reinstall the client component at the endpolnt. The specifics on how the LCF Is Installed and activated vary from OS type to OS type. On some operating systems there Is a background task (e.g., Inted on Unix) that listens for Incoming network connections, on other operating systems, the icf Itself Is configured as a background task that Is dormant until a network request activates It. in all cases, a persistent network listener of the Icf Is relatively small. The etwork listener will fork/spawn/invoke the larger application component (as the case may be) In response to a request from the client. According to the Invention, the code running on each endpolnt Is a small subset of a object-oriented CORBA runtime. This subset has sufficient functionality to Implement methods such as the filepack distribution methods and CCMS profile endpolnt methods (dataiess model). The basic components are ADR encoding routines for argument marshaling, standalone IPC library, bdt (block data transfer) and lorn, message catalogs for 118N, memory management and exception handling. One of the preferred implementations of the client component of the system management framework is as a set of instructions in a code module resident in the random access memory of the endpoint. Until required by the computer, the set of instructions may be stored in another computer memory, for example, In a hard disk drive, or in a removable memory such as an optical disk (for eventual use In a CD ROM) or floppy disk (for eventual use in a floppy disk drive), or even downloaded via the internet, in addition, although the various methods described are conveniently implemented In a general purpose computer selectively activated or reconfigured by software, one of ordinary skill in the art would also recognize that such methods may be carried out In hardware, in firmware, or in more specialized apparatus constructed to perform the required method steps. Further, although the Invention has been described In terms of a preferred embodiment in a specific network environment, those skilled In the art will recognize that the Invention can be practiced, with modification, In other and different network architectures with the spirit and scope of the appended claims. The present Invention, however, Is not to be construed as limited to the particular managed architecture Illustrated and thus In a more general sense the Inventive use of a client-server managed framework should be broadly construed to be useful In any distributed network configuration. Having thus described my invention, what I claim as new and desire to secure by Letters Patent Is set forth in the following claims. We Claim: 1. A method of managing computing resources in a large distributed enterprise, comprising the steps of: organizing the computing resources into one or more managed regions (12), each region being managed by a server machine servicing one or more gateway machines (16), each gateway machine servicing a plurality of endpoint machines (18); executing system management tasks affecting a managed region (12) by the steps of delivering automatically, on an as-needed basis, executable code and system management data required for a system management task from a gateway machine (16) to one or more endpoint machines (18) serviced by the gateway and using a distributed system management framework supported on the gateway machine and one or more endpoint machines to carry out the system management task using the executable code and system management data, wherein said system management data is used by the one or more endpoint machine to facilitate execution of at least one system management task and is not stored there on a persistent manner; and, maintaining the computer resources by backing up system management data, generally being information collected or distributed as part of a system management task, only from the server (14) and the one or more gateway machines. 2. The method as claimed in Claim 1 wherein data is used by the one or more endpoint machines to facilitate execution of the system management task and is not cached for subsequent use. 3. The method as claimed in Claim 1 or 2 comprising the step of caching the executable code for subsequent use. 4. The method as claimed in anyone of Claim 1 to 3 wherein at least some of the endpoint machines are personal computers. 5. The method as claimed in anyone of Claim 1 to 4 wherein each of the endpoint machines runs and client component of said system management framework and wherein the gateway machine that services the endpoint machines runs a server component of the system management framework. 6. The method as claimed in Claim 5 wherein the client component (24) of the system management framework has an operating state that is normally idle. 7. The method as claimed in Claim 5 wherein the server component of the system management framework executes in a multi-threaded fashion. 8. A system within a large distributed enterprise, said system comprising: a server machine (14) servicing a set of gateway machines (16), each of which services a set of endpoint machines (18), the server machine, the gateway machines and the endpoint machines of the system comprising means adapted for executing a method as claimed in anyone of claims 1 to 7. 9. The system as claimed in Claim 8 wherein the system management framework means on an endpoint machine comprises a deamon (24a) and an application runtime library (24b). 10. The system as claimed in Claim 9 wherein the said daemon is responsible for endpoint login to a gateway machine and for spawning an executable downloaded from the gateway machine. 11. A method of managing computing resources in a large distributed enterprise substantially as herein described with reference to and as illustrated by the accompanying drawings. 12. A system within a large distributed enterprise substantially as herein described with reference to and as illustrated by the accompanying drawings.

Full Text

TECHNICAL FIELD:
The present invention is directed to a device and method of managing computer resources.
BACKGROUND OF THE INVENTION:
Managing a computer network comprising thousands of nodes can produce
4
serious difficulties for system administrators. Management tasks, such as distribution of system-wide changes, must be carried out quickly and in a dependable manner in order to reduce the probability of catastrophic failure. Distributed computing environments that are known in the art do not scale easily to large size. One of the root causes of this deficiency is that prior art management environments include high overhead applications that, typically, are run on all of the managed machines in the network. In such systems, even machines located at the lowest level of management functionality (so-called "endpoints") often include a full suite of management routines and systems management data. Because the endpoint machine has its own database, it has to be backed-up to accurately back up the overall environment.
As the number of such machines gets large, the time to backup all the distributed databases becomes great and the backup storage requirements become unmanageable. When endpoint machines fail, or when users
t
accidentally remove files, it is an enormous burden on system administrators to have to locate and restore the endpoint's database, especially if the missing database prevents the overall managed architecture from being able to distribute to the failed endpoint. Moreover, adding new
application functionality to an endpoint machine typically requires the overall management architecture to be re-built, re-Installed or, at. least, re-lnltlallzed. This Is a time-consuming, complex
administrative task that severely limits the flexibility and Increases
the cost of system management. As a result of these problems, It has not been possible to Increase the size or "scalability" of such networks to a true "enterprise" level.
The present invention addresses and solves these problems.
RRH=F SUMMARY OF THE INVENTION
it Is a primary object of the Invention touelf^^eqllyfilyjTTanage computing(resources In a large distributed enterprlsfierii^DDBm©nfe~ ^Tt is another object of the Invention to enable an enterprise to place substantially all of Its computing resources on a network that Is managed In a reliable, cost-effective manner.
It Is still another object to reduce the complexity and cost of systems management In a large enterprise environment by supporting a low cost, low maintenance management framework on the vast majority of machines (e.g., the personal computers or PC's) In the enterprise.
Yet ajnother QSJgctJs jojgnhajice jthescalability of a large distributed computing network by distributing the functionality of a system management framework In accordance with a "client-server paradigm.
A more specific object of the Invention Is to Implement a low cost, low maintenance component of a system management framework at the endpoint machines that comprise the largest percentage of computing resources In the enterprise environment.
It is another more particular object to support a minimal set of applications on "dataless" endpoint machines of a large, distributed environment to facilitate systems management.
It is still another object of the invention to meet the needs of customers with very large and geographically-dispersed networks and, more particularly, to significantly expand the scalability parameters of traditional management tools and techniques.
Yet another important object is to enable PC connectivity in a large centrally-managed network enterprise.
These and other objects are achieved, according to Claim 1, with a method of managing computing resources in a large distributed enterprise, comprising the steps of: organizing the computing resources into one or more managed regions (12), each region being managed by a server machine servicing one or more gateway machines (16), each gateway machine servicing a plurality of endpoint machines (18); executing system management tasks affecting a managed region by the steps of delivering automatically, on an as-needed basis, executable code and system management data required for a system management task from a gateway machine to one or more endpoint machines serviced by the gateway and using a distributed system management framework supported on the gateway machine and one or more endpoint machines to carry out the system management task using the executable code and system management data, wherein said system management data is used by the one or more endpoint machine to facilitate execution of at least one system management task and is not stored there on a persistent manner; and, maintaining the computer resources by backing up system management data, generally being information collected or distributed as part of a system management task, only from the server and the one or more gateway machines.
The objects are also achieved if the method, according to Claim 2, is characterized in that data is used by the one or more endpoint machines to facilitate execution of the system management task and is not cached for subsequent use.

It is another more particular object to support a minimal set of applications on "dataless" endpoint machines of a large, distributed environment to facilitate systems management.
It is still another object of the invention to meet the needs of customers with very large and geographically-dispersed networks and, more particularly, to significantly expand the scalability parameters of traditional management tools and techniques.
Yet another important object is to enable PC connectivity in a large centrally-managed network enterprise.
These and other objects are achieved, with a method of managing computing resources in a large distributed enterprise, comprising the steps of: organizing the computing resources into one or more managed regions (12), each region being managed by a server machine servicing one or more gateway machines (16), each gateway machine servicing a plurality of endpoint machines (18); executing system management tasks affecting a managed region by the steps of delivering automatically, on an as-needed basis, executable code and system management data required for a system management task from a gateway machine to one or more endpoint machines serviced by the gateway and using a distributed system management framework supported on the gateway machine and one or more endpoint machines to carry out the system management task using the executable code and system management data, wherein said system management data is used by the one or more endpoint machine to facilitate execution of at least one system management task and is not stored there on a persistent manner; and, maintaining the computer resources by backing up system management data, generally being information collected or distributed as part of a system management task, only from the server and the one or more gateway machines.
The objects are also achieved if the method is characterized in that data is used by the one or more endpoint machines to facilitate execution of the system management task and is not cached for subsequent use.
The objects are also achieved if the method, is characterized in that it further includes the step of caching the executable code for subsequent use.
The objects are also achieved if the method, is characterized in that at least some of the endpoint machines are personal computers.
The objects are also achieved if the method, is characterized in that each of the endpoint machines runs a client component of said system management framework and wherein the gateway machine that services the endpoint machines runs a server component of the system management framework.
The objects are also achieved if the method, is characterized in that the client component of the system management framework has an operating state that is normally idle.
The objects are also achieved if the method, is characterized in that the server component of the system management framework executes in a multi¬threaded fashion.
The objects are also achieved with a device, within a large distributed enterprise, said system comprising a server machine (14) servicing a set of gateway machines (16), each of which services a set of endpoint machines (18), the server machine, the gateway machines and the endpoint machines of the system comprising means adapted for executing a method according to anyone of claims 1 to 7.
These objects are also achieved if, the device is characterized in that the system management framework means on an endpoint'machine includes a deamon and an application runtime library.
These objects are also achieved, if the daemon is responsible for endpoint login to a gateway machine and for spawning an executable downloaded from the gateway machine.
Preferably, the system management framework is object-oriented.
The foregoing has outlined some of the more pertinent objects of the present invention. These objects should be
FIGURE 6 Illustrates the ORB/BOA object-Invocation mechanism used by the present Invention;
FIGURE 7 Is a flowchart Illustrating how a gateway machine Invokes a method of an object running on an endpolnt machine to facilitate a management task;
»
FIGURE 8A Is a flowchart Illustrating how an endpolnt machine Initiates a file pull system management operation; and
FIGURE 8B Is a flowchart Illustrating howan endpotnt machine initiates an Inventory system management operation.
DETAILED DESCRIPTION
Referring now to FIGURE 1, the Invention Is preferably Implemented In a large distributed computer environment 10 comprising up to thousands or even tens of thousands of "nodes." The nodes will typically be geographically dispersed and the overall environment Is "managed" In a distributed manner. Preferably, the managed envlronmeottME) isJoglcally broken down Into a series of
loosely-connected managed regions (MR) 12, each with Its own server 14 for managing local resources with the MR. Multiple servers 14 coordinate activities across the enterprise and permit remote site management and operation. Each server 14 serves a number of gateway machines 16, each of which In turn support a plurality of endpotnts 18. The server 14 coordinates all activity within the MR using a terminal node manager 20.
Referring now to FIGURE 2, each gateway machine 16 runs a server component 22 of a system management framework. The server component 22 Is multi-threaded runtime process that comprises several components: an object request broker or "ORB" 21, an authorization service 23, object location service 25 and basic object adaptor or "BOA" 27. Server component 22 also Includes an
object library 29. Preferably, the ORB 21 runs continuously, separate from the operating system, and It communicates with both server and client processes through separate stubs and skeletons via an Interprocess communication (IPO facility 19. in particular, a secure remote procedure call (RPO is used to invoke operations on rernpte objects. Gateway machines 16 also Includes an operating system 15 and a threads mechanism 17.
The system management framework Includes a client component 24 supported on each of the endpotnt machines 18. The client component 24 is a low cost, low maintenance application suite that is preferably "dataless" in the sense that system management data is not cached or stored there in a persistent manner, implementation of the management framework In this "client-server manner has significant advantages over the prior art, and It facilitates the connectivity of personal computers into the managed environment. Using an object-oriented approach, the system management framework facilitates execution of system management tasks required to manage the resources in the MR. Such tasks are quite varied and include, without limitation, file and data distribution, network usage monitoring, user management, printer or other resource configuration management, and the like. System management tasks Involve system management "data", which generally Is the Information collected or distributed as part of a particular system management task.
in the large enterprise such as Illustrated In FIGURE 1, there is one server per MR with some number of gateways. For a workgroup-size installation (e.g., a local area network or "LAN") such as Illustrated in FIGURE 3, a single server-class machine may be used as the server and gateway, and the client machines would run the
lost cost framework. References herein to a distinct server and one or more gatewayfe) should thus not be taken by way of limitation as these elements may be combined Into a single platform. For Intermediate size Installations, the MR grows breadth-wise, with additional gateways then being used to balance the load of the endpolnts.
The server Is the top-level authority over all gateway and endpolnts. The server maintains an endpolnt list, which keeps track of every endpolnt In a managed region. This list contains all Information necessary to uniquely Identify and manage endpolnts Including, without limitation, such Information as name, location, and machine type. The server also maintains the mapping between endpolnt and gateway, and this mapping Is dynamic. Based on site-specific settings, It Is possible to reassign endpolnts when gateways go down or to automatically add new endpolnts as they appear on the network.
AS noted above, there are one or more gateways per managed region. A gateway Is a full managed node that has been configured to operate as a gateway, initially, a gateway "knows" nothing about endpolnts. As endpolnts login (discussed below), the gateway builds an endpoint list for Its endpolnts. The gateway's duties Include: listening for endpolnt login requests, listening for endpolnt upcali requests, and (Its main task) acting as a gateway for method Invocations on endpolnts.
AS also discussed above, the endpolnt Is a machine running the system management framework client component, which Is referred to herein as thejpjj\/_c^s^ramework (LCF).jrhe LCF has two main parts as Illustrated In FIGURE 2A: the Icf daemon 24a and an application runtime library 24b. The LCF daemon 24a Is responsible
for endpolnt login and for spawning application endpolnt executables. once an executable Is spawned, the LCF daemon 24a has no further Interaction with It. Each executable Is linked with the application runtime library 24b, which handles all further communication with the gateway.
Preferably, the server and each of the gateways Is a computer o/ "machine.". For example, each computer may be a RISC System/6000® (a reduced Instruction set or so-called RISC-based (workstation) running the AIX (Advanced interactive Executive) 6peratlng system, preferably Version 3.2.5 or greater. The AIX operating system Is compatible at the application interface level with the UNIX operating system, version 5.2.
The various models of the RISC-based computers are described In many publications of the IBM corporation, for example, RISC Svstem/6000. 7073 and 7016 POWERstatlon and POWERserver Hardware Technical Reference, order No. SA23-2644-00. The AIX operating system Is described In AIX Operating System Technical Reference, published by IBM corporation, First Edition (November, 1985), and other publications. A detailed description of the design of the UNIX operating system Is found In a book by Maurlcej. Bach, Design of the Unix operating System, published by Prentice-Hall
(1986). Suitable alternative machines Include: an IBM-compatible PC 486 or higher running Novell UnixWare 2.0, an AT&T 3000 series running AT&TUNIXSVR4 MP-RAS Release 2.02 or greater, Data General AVIION series running DG/UX version 5.4R3.00 or greater, an HP9000/700 and 800 series running HP/UX 9.00 through HP/UX 9.05. 'Motorola 88K series running SVR4 version R40V4.2, a Sun SPARC series running Solaris 2.3 or 2.4, or a sun SPARC series running SunOS 4.1.2
or 4.1.3. Of course, other machines and/or operating systems may be used as well for the gateway and server machines.
Each endpolnt Is also a computer. In one preferred embodiment of the Invention, most of the endpolnts are personal computers (e.g., desktop machines or laptops), in this architecture, the endpolnts need not be high powered or complex machines or workstations, one or more of the endpolnts may be a notebook computer, e.g., the IBM ThinkPad® machine, or some other Intel x86 or Pentlum®-based computer running windows 3.1 or greater operating system. IBM® or IBM-compatible machines running under the OS/2® operating system may also be Implemented as the endpolnts. For more Infprmatlon on the OS/2 operating system, the reader Is directed to OS/2 fr.aTechnical library. Programming Guide volumes 1-5 Version 2.00. order Nos. 10G6261,10C6495 and
40G6494.
AS noted-ataoverttre^erver-class framework running on each-gateway machine Is multi-threaded and Is capable of maintaining hundreds of simultaneous network connections to remote machines. A thread of execution may be a separate process (In the UNIX paradigm) or a separate thread In a single process (In the POSIX pthrf ads paradigm). POSIX is a series of standards for applications and user interfaces to open systems, Issued by the institute of Electrical and Electronics Engineers inc. (IEEE). The IEEE POSIX.1C is the emerging standard for user level multi-threaded programming and Is Implemented In the served component of the systems management framework. All objects In this framework exhibit "state." This state may be completely persistent, In which case It Is represented by attributes in the object database associated with a
gateway machine, or the state may be non-persistent. An example of the latter might be the current list of machines that are down.
in the preferred embodiment, the LCF Is the smallest amount of code that can still do useful endpolnt work. Generally, this means that the LCF code has the following characteristics: single-threaded, limited cascade and upcall capability, no persistent attributes and only a small set of CORBA runtime. Machines that see little management activity In a typical day are those for which the LCF Is particularly advantageous. Machines that need to service a large volume of requests preferably run the server component of the system management framework.
The LCF Is always ready to do management tasks, but consumes few resources because It is normally In an Idle state. Preferably, each endpolnt Is "dataless" In the sense that system management data Is not stored therein before or after a particular system management task Is Implemented or carried out. Therefore, unlike the prior art, there Is no need to perform system backup or other conventional maintenance on the endpolnt (at least with respect to the system management framework). Maintenance on the server and gateway machines suffices, similarly, new application functionality may be added to the Icf without rebuilding, reinstalling or re-lnltlallzing the client component Into the system management framework.
Since endpolnts are dataless and readily extensible, the architecture Is easily scaleable as Illustrated In FIGURE 1. The client component of the system management framework Is Inexpensive and requires little or no maintenance since much of the system management framework is off-loaded to the gateway machines that run the multi-threaded, server component. This architecture
advantageously enables a rational partitioning of the enterprise with 10's of servers, 100's of gateway machines, and 1000's of endpolnts. Each server typically serves up to 200 gateways, each of which services 1000's of endpolnts. At the framework level, all operations to or from an endpolnt pass through a gateway machine, in many operations, the gateway Is transparent; It receives a request, determines the targets, resends the requests, waits for results, then returns results back to the caller. Each gateway handles multiple simultaneous requests, and there may be any number of gateways In an enterprise, with the exact number depending on many factors Including the available resources and the number of endpolnts that need to be serviced.
Thus, according to the present Invention, one or more of the endpolnts 18 are "dataless." Except for the LCF executable Itself, preferably there Is no database or other state that must be kept on the endpolnt. Whenever executable code and/or system management data are needed for a particular system management task, such code and/or data are delivered from a particular gateway machine to the affected endpolnts machines automatically. Typically, the executable code and/or data will remain valid for the particular task Invocation; while the executable code may be cached, usually the system management data will not be. If the executable code Is cached, preferably the system management framework may be configured to automatically resend such code without operator Intervention If the cache Is lost or periodically flushed.
An endpolnt Is added to the enterprise by first copying the LCF daemon 24a to the endpolnts disk. This may be done automatically through network login scripts, manually by Inserting
a diskette, or by preloading the boot disk at the time of purchase or license. The first time the LCF daemon Is Installed, and on each subsequent boot, the LCF daemon attempts to login to Its gateway, if the gateway Is not known or If the gateway does not respond, the daemon Issues a broadcast requesting a gateway. For completely new endpolnts the broadcast Is ultimately forwarded to the server, if a gateway hears a broadcast or a login request from an endpolnt It recognizes, the gateway services the request Itself.
When the server receives an endpolnt's gateway request broadcast, the server consults Its endpolnt list to see which gateway the endpolnt belongs to. For new endpolnts, or when migrating between gateways, the server uses a site specific policy to choose the correct gateway (e.g., by subnet). The gateway Is Informed of Its new endpolnt, the gateway Informs the endpolnt, and the login completes.
An endpolnt preferably communicates only with Its gateway. Requiring all endpolnt communication to pass through a single gateway greatly simplifies connectivity Issues. After a successful login, both endpolnt and gateway know a working address by whlph to address one another. If a DHCP address lease expires, or anything changes In the network topology, then the next endpolnt login will establish the new endpolnt to gateway addresses.
There Is no absolute maximum number of endpolnts that can be supported by a single gateway. The design strategy Is that the gateway Is always in control of Its own workload. The endpolnts are not allowed to send data unless granted permission. When an endpolnt has results to return, or If It wishes to make an upcall, It sends a very small message requesting service. The gateway queues
the request and services the queue as time allows. When an endpolnt has large results, It must break the results Into chunks and may only send a chunk when Instructed to do so. This strategy makes It possible for a single gateway to support thousands of endpolnts, albeit somwhat slowly, if a better quality of service is desired, It Is simply a matter of adding more gateways.
Endpolnt methods are normal CORBA methods (as discussed below) linked with IDL compiler generated code and the endpolnt application runtime library 24b. This results In a native executable designed to be spawned by the LCF daemon 24a. Any number of methods may be Implemented In a single executable.
Preferably, an endpolnt Is Installed without any methods. Method executables are downloaded from the gateway as required. When the LCF daemon receives a method Invocation request, It checks the local disk cache, if there Is a cache miss, or a version mismatch, then a new executable Is downloaded, in this way, an endpolnt can start with nothing and then build a working set of methods for fast execution.
Before Illustrating how the framework Is used, the following background Is provided. FIGURE 4 first illustrates how a systems management task Is Implemented. Each authorized administrator 30 has access to a desktop computer 32 containing one or more Icons representing system resources. AS administrators Interact with dialog screens and menus available from these Icons, they are able to change system configurations and manage new resources in the distributed environment, all In a known manner, in particular, when administrator 30 Interacts with the desktop, so-called "callbacks" (I.e. software that responds to the user's actions) are invoked from the user Interface on underlying objects

representing some system resource or component. These callbacks are translated Into a series of method Invocations that actually perform the work and return results or status to the administrator.
in particular, and with reference to the process flow diagram of FIGURE 4, the Information flow begins when the administrator 30 selects an Icon or Interacts with a dialog. The Information is then sent to the desktop (which may be connected to a server or a gateway) at step 34, at which time the appropriate application callback method Is Invoked at step 36. The callback method then invokes core application methods at step 38, which communicate with the application objectts) to perform some system management operation, as Illustrated at step 39. Any return information or state Is passed back at steps 40 and 41. if an update to the user Interface Is required, the desktop 32 Interprets the output and updates the dialogs on the administrator's desktop at step 42.
preferably, the framework includes a task library that enables administrators to create "shell" scripts that can run an any managed node of the enterprise environment. A shell script Integrated with a managed node Is called a "task." When administrators want to create a task, they provide a machine and a path to an executable file. The executable can be a shell script, a specialized script, a compiled program or any other kind of valid executable. When a task is created, the executable Is stored as an attribute In an object database associated with a gateway machine. When the task Is needed, the executable file is retrieved from the attribute and is provided to one or more managed nodes. After a task Is created, It Is added to the task library and displayed as an icon.
FIGURE 5 Illustrates howsystems managementapplicatlons are constructed from a set of standard object types that together constitute a general applications architecture for the framework. These standard object types are closely Interrelated and are used to build objects for system management applications. The objects provided by a management application can be divided Into one or more object types 44 that are managed by one or more Instance managers 46. An object type Is a set of objects that share a common Interface. Each object of the same type Is called an instance of the type. Within the systems management framework, object types are associated with a particular Instance manager. The instance managers are registered and stored In a library 48, which provides a central repository for system administration object Information within a managed region.
AS referenced above, the systems management provides an implementation of a CORBA 1.1 object Request Broker (ORB), basic object adaptor (BOA), and related object services. CORBA 1.1 is a specification for an object-oriented distributed computer systems management architecture provided by The Object Management Croup (OMG), a non-profit association of more than 300 companies. CORBA describes the use of the Object Request Broker (ORB) and basic object adaptor (BOA) that provide a mechanism for object invocation and return of results. The specification defines interfaces to a set of low-level object services and enables such services to be Integrated in many different language and systems using object encapsulation, service requestor/provider isolation, and interface and Implementation separation.
in a CORBA 1.1 Implementation as seen In FIGURE 6, there are three primary components: a client, an object implementation, and
the ORB/BOA. The client 50 Is the requestor of a service that Is provided by an object implementation 52. The ORB 21 delivers the request from the client 50 to the object Implementation 52 through the BOA 27. The object Implementation 52 then performs the requested service, and any return data Is delivered back to the client. The client an,d object implementation are isolated from each other, and neither has any knowledge of the other except through their ORB/BOA interfaces. Client requests are Independent of the object Implementation location and the programming language in which they are Implemented.
The ORB delivers the request to the BOA, which activates the process under which the object Implementation (e.g., a server) runs. The BOA then Invokes the method associated with the request by way of a server skeleton 61. When the method Is finished, the BOA manages the termination of the method and coordinates the return of any results to the client. Alternatively, If a request Is unknown until runtime, a Dynamic invocation interface (Din 55 Is used to build a request used in place of a client stub 63 linked at compile time.
with the above background, several examples of how system management tasks are carried out using the client-server framework are now described. The following discussion Is merely exemplary, as the nature and type of systems management tasks that can be carried out by the framework Is unconstrained. As noted above, the system management framework Includes the server component supported on the gateway machines of the managed region, and the associated client component is supported on the endpoints serviced by the gateway(s). To provide transparent functionality, every method to be run on an endpoint
s preferably configured on the gateway. All endpolnt object references (Objrefs) that other methods use to Invoke operations on an endpolnt are Objrefs and each endpolnt Is assigned to a unique object dispatcher number (odnum). The gateway machine then uses true object references to "point" to the actual endpolntts).
The routine Illustrated In FIGURE 7 occurs when one method Invokes a method of an object on an endpoint. At step 70, the server 14 resolves the Objref/method to a specific method daemon on a gateway. At step 72, the gateway Is started (if It Is not already running) and passed a method activation record or so-called MAR block. The MAR block contains all Information necessary to Invoke a method Including the target Objref, the target method, "marshalled" input arguments and other fields from the server's method store. AS noted above with respect to FIGURE 6, when a request to run an operation on some object Is made, a client stub Initiates the request, collects the data associated with the request, and converts it from its current format to a common format. This process Is known as "data marshalling" and Is performed In accordance with the ASN.1 Standard. Up to this point, there Is no difference as far as the application Is concerned between this method Invocation and any other method Invocation. At step 74, the gateway looks at the Objref to determine the target endpolnt. A connection to the endpolnt Is then opened at step 76.
The method continues at step 78 and queries whether the endpolnt has a copy of the executable for the method, if not, the routine continues at step 80 to retrieve the appropriate executable from the object database (based on the endpolnt's machine type), and the executable Is then sent to the endpolnt. At step 82, or If
the endpolnt already had the necessary executable, the gateway sends the still-marshalled Input arguments to the endpolnt. At step 84, the gateway enters Into a wait state, waiting for the marshalled output arguments to be returned. When this occurs, the routine continues at step 86 and closes the connection to the endpolnt. The output arguments are then sent back to the server at step 88 and the routine terminates as though the method had executed locally.
Endpolnt-Inltlated operations can now be described, in these types of operations, the endpoint first attempts to establish a connection back to Its gateway. Preferably, this Is done In the same way that the endpolnt client attempts to Identify Itself upon boot. It first tries Its last known gateway host; If It gets no response, the endpolnt then contacts the server's TN Manager routine either directly or, If that falls, via a BOOTP broadcast, once connected, the server component of the gateway Is Invoked and the endpolnt passes a descriptor telling the gateway which endpolnt has connected.
Upcalls are method requests originating at the endpolnt. The Tlvoll courier™ pull Interface Is an example of a program making upcalls. Not all applications will need upcalls. An endpolnt makes an upcall by calling an IDL compiler generated stub. Unlike a normal method invocation, an upcall always Invokes a special upcall method on the gateway. An application that supports upcalls must provide both the endpolnt code and the special upcall method. The endpolnt upcall facility Is not a general purpose method Invocation Interface. This design maintains scalability by handling upcalls at the local gateway without management server intervention.
An Illustrated "file pull" operation Is shown In FIGURE 8A. in this operation, the endpolnt-resldent code (I.e. the client component) Initiates a file request and the gateway-resident code (I.e. the server component) handles the request. The routine begins at step 96, with the user on the endpolnt Invoking a local program that Is part of the client component of a file distribution application. This step Invokes a method asking for a list of all available fllepacks. A "fllepack" Is a collection of files being distributed In accordance with a system management task. At step 98, the gateway receives the request, Invokes the server component of the file distribution application, passing It the descriptor Identifying the endpolnt. The software distribution program, running as a method on the gateway, Issues a name service lookup at step 100, filters out fllepacks that the endpolnt is allowed to receive at step 102, and then returns the list to the endpoint at step 104. Depending on the actions of the user, the endpolnt may then invoke another method asking for a specific filepack.
FIGURE 8B illustrates an Inventory reporting system management task, in this example, assume that an inventory application is designed to collect Inventory Information (e.g., the hardware and software configuration details) from a machine whenever the machine is rebooted, it Is also assumed that an Initialization method has been run on each endpolnt to edit the appropriate boot-time script to run the Inventory report program on boot. The routine starts upon the next boot, in particular, at step 106, the program runs the local inventory report to produce a data file of Inventory results. At step 108, the endpoint connects to the gateway in the manner previously described. The endpolnt
then Invokes an "Inventory report" method at step 110 and, at step 112, sends the results to the gateway. At step 114, the server component of the Inventory report method is Invoked and passed a descriptor Identifying the endpolnt. The Inventory results are read by the gateway at step 116 and, at step 118, forwarded to a central Inventory database object.
The LCF Is designed with efficient distributions operations in mind. Each gateway is also a repeater for each of the gateway's endpolnts. This relationship is Implicit so It does not need to be set In the repeater configuration. Distributions fan out from the gateway to the endpolnts without further server support. Eliminating the server as a bottleneck makes distributions very scaieable.
As can be seen, the endpolnt remains essentially dataless except as needed to carry out the particular system management task. This operation Is facilitated by distributing the system management framework across client components, supported on the endpolnts, and server components, supported on the gateways that service the endpolnts.
As noted above, the LCF is extensible and thus new application functionality Is easily added to the system management framework without having to rebuild or reinstall the client component at the endpolnt. The specifics on how the LCF Is Installed and activated vary from OS type to OS type. On some operating systems there Is a background task (e.g., Inted on Unix) that listens for Incoming network connections, on other operating systems, the icf Itself Is configured as a background task that Is dormant until a network request activates It. in all cases, a persistent network listener of the Icf Is relatively small. The
etwork listener will fork/spawn/invoke the larger application component (as the case may be) In response to a request from the client.
According to the Invention, the code running on each endpolnt Is a small subset of a object-oriented CORBA runtime. This subset has sufficient functionality to Implement methods such as the filepack distribution methods and CCMS profile endpolnt methods (dataiess model). The basic components are ADR encoding routines for argument marshaling, standalone IPC library, bdt (block data transfer) and lorn, message catalogs for 118N, memory management and exception handling.
One of the preferred implementations of the client component of the system management framework is as a set of instructions in a code module resident in the random access memory of the endpoint. Until required by the computer, the set of instructions may be stored in another computer memory, for example, In a hard disk drive, or in a removable memory such as an optical disk (for eventual use In a CD ROM) or floppy disk (for eventual use in a floppy disk drive), or even downloaded via the internet, in addition, although the various methods described are conveniently implemented In a general purpose computer selectively activated or reconfigured by software, one of ordinary skill in the art would also recognize that such methods may be carried out In hardware, in firmware, or in more specialized apparatus constructed to perform the required method steps.
Further, although the Invention has been described In terms of a preferred embodiment in a specific network environment, those skilled In the art will recognize that the Invention can be practiced, with modification, In other and different network
architectures with the spirit and scope of the appended claims. The present Invention, however, Is not to be construed as limited to the particular managed architecture Illustrated and thus In a more general sense the Inventive use of a client-server managed framework should be broadly construed to be useful In any distributed network configuration.
Having thus described my invention, what I claim as new and desire to secure by Letters Patent Is set forth in the following claims.

We Claim:
1. A method of managing computing resources in a large
distributed enterprise, comprising the steps of:
organizing the computing resources into one or more managed regions (12), each region being managed by a server machine servicing one or more gateway machines (16), each gateway machine servicing a plurality of endpoint machines (18);
executing system management tasks affecting a managed region (12) by the steps of delivering automatically, on an as-needed basis, executable code and system management data required for a system management task from a gateway machine (16) to one or more endpoint machines (18) serviced by the gateway and using a distributed system management framework supported on the gateway machine and one or more endpoint machines to carry out the system management task using the executable code and system management data, wherein said system management data is used by the one or more endpoint machine to facilitate execution of at least one system management task and is not stored there on a persistent manner; and,
maintaining the computer resources by backing up system management data, generally being information collected or distributed as part of a system management task, only from the server (14) and the one or more gateway machines.
2. The method as claimed in Claim 1 wherein data is used by the
one or more endpoint machines to facilitate execution of the system
management task and is not cached for subsequent use.
3. The method as claimed in Claim 1 or 2 comprising
the step of caching the executable code for subsequent use.
4. The method as claimed in anyone of Claim 1 to 3 wherein at least
some of the endpoint machines are personal computers.
5. The method as claimed in anyone of Claim 1 to 4 wherein each of
the endpoint machines runs and client component of said system
management framework and wherein the gateway machine that services the
endpoint machines runs a server component of the system management
framework.
6. The method as claimed in Claim 5 wherein the client component
(24) of the system management framework has an operating state that is
normally idle.
7. The method as claimed in Claim 5 wherein the server component
of the system management framework executes in a multi-threaded fashion.
8. A system within a large distributed enterprise, said system
comprising:
a server machine (14) servicing a set of gateway machines (16), each of which services a set of endpoint machines (18), the server machine, the gateway machines and the endpoint machines of the system comprising means adapted for executing a method as claimed in anyone of claims 1 to 7.
9. The system as claimed in Claim 8 wherein the system
management framework means on an endpoint machine comprises a deamon
(24a) and an application runtime library (24b).
10. The system as claimed in Claim 9 wherein the said daemon is
responsible for endpoint login to a gateway machine and for spawning an
executable downloaded from the gateway machine.
11. A method of managing computing resources in a large
distributed enterprise substantially as herein described with reference to and
as illustrated by the accompanying drawings.
12. A system within a large distributed enterprise substantially as
herein described with reference to and as illustrated by the accompanying
drawings.

Documents:

2040-del-1997-abstract.pdf

2040-del-1997-claims.pdf

2040-del-1997-correspondence-others.pdf

2040-del-1997-correspondence-po.pdf

2040-del-1997-description (complete).pdf

2040-del-1997-drawings.pdf

2040-del-1997-form-1.pdf

2040-del-1997-form-19.pdf

2040-del-1997-form-2.pdf

2040-del-1997-form-3.pdf

2040-del-1997-form-4.pdf

2040-del-1997-form-6.pdf

2040-del-1997-gpa.pdf

2040-del-1997-petition-138.pdf

« Previous Patent

Next Patent »

Patent Number

214892

Indian Patent Application Number

2040/DEL/1997

PG Journal Number

10/2008

Publication Date

07-Mar-2008

Grant Date

18-Feb-2008

Date of Filing

22-Jul-1997

Name of Patentee

INTERNATIONAL BUSINESS MACHINES CORPORATION

Applicant Address

ARMONK, NEW YORK 10504, UNITED STATES OF AMERICA

Inventors:

#	Inventor's Name	Inventor's Address
1	THOMAS W. BEREITER	1906 SHARON LANE, AUSTIN, TEXAS 78703, USA

PCT International Classification Number

G06F 9/46

PCT International Application Number

N/A

PCT International Filing date

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1	08/724,663	1996-10-01	U.S.A.