Title: MODEL-BASED MANAGEMENT OF COMPUTER SYSTEMS AND
DISTRIBUTED APPLICATIONS
CROSS-REFERENCE TO RELATED APPLICATIONS This application is related to the following co-pending U.S. Patent Applications: Serial No. 10/692,216, entitled MODEL-BASED MANAGEMENT OP COMPUTER SYSTEMS AND DISTRIBUTED APPLICATIONS filed on October 23, 2003 Ser. No. 10/693,072, entitled "SCALABLE SYNCHRONOUS AND ASYNCHRONOUS PROCESSING OF RULE MONITORING" filed on October 24, 2003; Ser. No. 10/692,660 entitled "RULES DEFINITION LANGUAGE" filed on October 24, 2003; Ser. No. 10/693,588 entitled "USING URI'S TO IDENTIFY MULTIPLE INSTANCES WITH A COMMON SCHEMA" filed on October 24,2003; and, Ser. No. 10/692,432 (Atty. Diet. No. MSFTP522US) entitled "USE OF ATTRIBUTION TO DESCRIBE MANAGEMENT INFORMATION" filed on October 23, 2003 the entirety of which is incorporated herein by reference.
TECHNICAL FIELD This invention is related to computer systems, and more specifically, to management of computer systems and applications.
BACKGROUND OF THE INVENTION
Traditional systems management is largely ad-hoc. Application developers do not have a structured framework for managing their applications and achieving high reliability. The expected behaviors of applications are largely reverse engineered. Application developers do not have structured guidance and framework for how to think about managing their applications and achieving high reliability. Moreover, operating systems do not provide a holistic system for developers to leverage.
The complexity of systems is becoming too great for operators to understand. Significant time is spent tracking down dependencies and latent errors, Where instrumentation is not available, operators need to take a process dump, since this is the only way to determine what requests are executing and the current slate.
Systems today do a poor job alerting users to potential and actual problems. Users cannot readily tell what applications arc installed, and do not know if the system and applications have the right files and versions, arc configured correctly for how they are used, are configured securely for the environment, and if they arc operating optimally and not running out of resources. Moreover, applications are not

easily debugged across multiple machines-- there is no common application and transaction context.
Operators also cannot easily figure out application dependencies, whether files, components, configuration settings, security settings, or devices like storage area networks and routers, The system can neither warn users that a change may break other applications, nor use this information to help identify root cause.
Reactive monitoring is most common today where alerts let the user know that there was a failure, and not the cause of the problem. Advanced scripts and providers can provide more informative and actionable alerts, but lack an infrastructure for performing root cause analysis. Additional diagnostics are oflen needed for troubleshooting. However, a problem with reactive monitoring is that an alert is often too late—the application is already not available to users. Monitoring can help by triggering faiiover or taking a server offline with a load balancing device. However, the system should be sufficiently intelligent to detect potential problems in an application before the potential problems become failures.
Other problems arc only detected by looking across multiple machines and clients. Examples include distributed intrusion detection and degradations in application performance. If administrators had at their disposal the capability to see a deviation from expected performance, been able to trace root cause to configuration ehnnges as they eapturc snapshots, and solved the problem before users complained, many massive network performance problems and downtime could have been avoided.
Conventionally, problems with distributed applications arc only determined by looking at historical data or trends from a user perspective. Administrators often do not know if their replication backlog is a problem or not, and need to run the service first and log operational metrics to establish a baseline with warning and critical thresholds.
What is needed is tin improved mechanism for management infrastructure.
SUMMARY OF THE INVENTION The following presents a simplified summary of the invention in order to provide a basic understanding of some aspects of the invention. This summary is not an extensive overview of the invention. It is not intended to identity key/critical elements of the invention or to delineate the scope of the invention. Its sole purpose
is to present some concepts of the invention in a bimplified form us a prelude to the more detailed description that is presented later.
The present invention disclosed and claimed herein, in one aspect thereof comprises a model-based management system that provides an innovative framework, that enables a developer to describe an application or service in terms of its components. The developer can describe desired stales of the application or service in terms of functionality, configuration, security, and performance. This description or model is provided with the application and used by the system at installation to configure the management services. A computer system employs the developer's description at installation to configure management services. The management services help ensure availability of the application through automatic management actions, such as configuration management, problem detection, diagnosis, and recovery. The model also describes common tasks that the administrator may perform.
The model-based management architecture comprises the following parts: models, for the components making up an application, e.g., health states and recovery, configuration settings, and admin tasks; attribution within the source code to indicate instrumentation and logic for monitoring; one or more manifests that ships with the application, which manifest(s) that contain information from the models and source code attribution in a machine-readable form for use by the management system services; n management system comprised of multiple services that are configured by information within the application manifest; and, administrative tasks for an application that are defined within the manifest.
The system component of the model-based management architecture consists of the services necessary to ensure availability of an application. The system uses the desired states expressed in the manifest and modified by the administrator to perform the following: installation that verifies dependencies and installs only the necessary files, settings, and security; event subscriptions that subscribe to events and forwards them as specified; polled instrumentation that periodically collects instrumentation and counters; scheduled tasks that perform automatic management tasks; role-based access that restricts access to program functions; a monitoring function that detects problems, diagnoses root causes, takes corrective actions, and notifies the system administrator when intervention is necessary; and, central configuration for customizing policy for the above, and for applying to many machines.
In another aspect thereof, the model-based management system is applied to a distributed network of hardware and software. Components of local and remote applications, as well us local and remote machines and services are described and managed accordingly.
To the accomplishment of the foregoing and related ends, certain illustrative aspects of the invention are described herein in connection with the following description and the annexed drawings. These aspects are indicative, however, of but a few of the various ways in which the principles of the invention may be employed and the present invention is intended to include all such aspects and their equivalents. Other advantages and novel features of the invention may become apparent from the following detailed description of the invention when considered in conjunction with the drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates architecture that facilitates model-based management of applications in accordance with the present invention.
FIO. 2 illustrates a drawing map related to describing principal components of the model-based management architecture.
FIG. 3A illustrates blocks associated with the models component of the model-based management architecture of the present invention.
FIG. 3B illustrates blocks associated with the manifest component of the model-based management architecture of the present invention.
FIG. 3C illustrates a block diagram of core system APIs of the system component utilized for managing an application or service in accordance with the model-based management architecture of the present invention,
FIG. 3D illustrates a block diagram of management-related APIs of the system component of the model-based management architecture of the present invention.
FJG. 3E illustrates subcomponents of the tasks component of tha model-based management architecture of the present invention.
FIG. 4 illustrates a general flow chart of a process of model-based management.
FIG. S illustrates a more detailed How chart of a process of implementing the model-based management.
FIG. 6 illustrates a flow chart of a process of implementing desired states of the model-based management.
FIG. 7 illustrates a block diagram of a computer operable to execute the disclosed architecture,
FIG. 8 illustrates a schematic block diagram of an exemplary computing environment in accordance with the present invention.
DETAILED DESCRIPTION OF THE INVENTION The present invention is now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It may be evident, however, that the present invention may be practiced'without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing the present invention.
As used in this application, the terms component" and "system" are intended to refer to a computer-related entity, cither hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.
As used herein, the term "inference" refers generally to the process of reasoning about or inferring states of the system, environment, and/or user from a set of observations as captured via events and/or data. Inference can be employed to identify a specific context or action, or can generate a probability distribution over states, for example. The inference can be probabilistic—that is, the computation of a probability distribution over states of interest based on a consideration of data and events. Inference can also refer to techniques employed for composing higher-level events from a set of events and/or data. Such inference results in the construction of new events or actions from a set of observed events and/or stored event data, whether
or not the events arc correlated in close temporal proximity, and whether the events and data come from one or several event and data sources.
Referring now to FIG. 1, (here is illustrated architecture 100 that facilitates model-based management of applications or services in accordance with the present invention. The model-based management approach allows a developer to describe an application or service 102 in terms of its constituent components and desired states in terms of functionality, configuration, security, and performance. Thus, an application or service description 104 facilitates describing the application or service 102 in terms of one or more manageable components, including at least a models component 106, manifest component 108, system component 110, and tasks component 112. The model-based management system 100 utilizes an attribution component 114 to facilitate attribution of the source code from the mode! component 106 to the manifest component 108.
A computer system 116 uses the application or service description 104 at installation of the application 102 to configure management services 118 associated with the computer operating system. The management services 118 then help ensure availability of the application or service 102 through automatic management actions such as configuration management, problem detection, diagnosis, and recovery. The model 106 also describes common tasks that the administrator may perform. The model-based management architecture 100 facilitates a lower total cost of ownership, and is used across the application lifecyclc from development, to deployment, operations, and business analysis. Generally, a developer begins by creating one or more models of the application or service in terms of how the application works, its constituent components, the desired health states that the developer defines and chooses to monitor, configuration aspects at least with respect to how it will be installed and what settings the application or service will require and, administrative tasks and the scheduling thereof. The source code of the model is then attributed (or tagged) at specific areas for manifesting.
The models are rolled up into instrumentation manifests. The models tend to be in the form of text documents, spreadsheets documents, etc., structured documents that arc either transformed through codes, scripts, tools, or manually into the manifest that tend to be more XML sehemas, and further machine processed and machine read. That is to say the models documents are more human readable and the manifests are
more machine readable. The manifests arc then u.sed to facilitate system management.
The attribution subcomponent 114 is associated with source code attribution. Attribution is used to express management information along with the code to which it pertains. Without attribution, two separate pieces of code would need to be written—one for normal application processing and one to expose it to management. Attribution within the source code is used to describe which parts of the code (called probes) should be used to determine and/or correct health, as well as specify when to execute monitoring rules. Probes can be exposed from components that access existing operating system APIs (Application Program Interfaces) or from components loaded inside running applications or services. In both cases, the developer adds attribution to indicate what subset of the types within the components should be exposed and how they should be identified. Probes are identified using URIs (Uniform Resource Identifiers) within an administrator namespace. At runtime, a probe is retrieved by identifying it from within a eatalog of all probes on the computer, and following the associated information about the probe.
Source code attribution can also provide instructions to the monitoring service, for example, to attribute functions that should be used as monitoring rules and loaded at startup, polled periodically, run on an event, etc. This attribution can be automatically processed and put in the manifest the same way as the instrumentation. Thus, attribution is not just instrumentation, but for other management purposes as well. Attribution can also be used to support administrative tasks and/or corrective actions.
Referring now to FIG. 2, there is illustrated a drawing map 200 related to describing principal components of the model-based management architecture 100. The architecture includes the models component 106 that is described in relation to FIG. 3A, the manifest component 108 that is described in relation to FIG, 3B, the system component 110 that is described in relation to PIG. 3C and FIG. 3D, and the tasks component 112 that is described in relation to FIG. 3E Attribution has already been described, and will be addressed throughout the specification.
Referring now to FIG. 3A, there are illustrated blocks associated with the models component 106 of the model-based management architecture of the present invention. Models are developed for the components making up an application, health states and recovery, configuration settings, and administrative tasks.
Ip support thereof, there is a component model subcomponent .100 tor modeling any and all components of the system (and relationships, dependencies and service roles associated therewith). The component model 300 describes the files, configuration, different ways the application can be installed, and more.
A health model subcomponent 301 can be developed to describe the various failure states, and the way that the application or service could fail. The health model 301 describes the steps that would need to be taken to automate the health features. The health model 301 represents at least the failure states, detection the states, verification, diagnosis, and resolution of the system states. The health states can be described in terms of what criteria must be met to be considered completely healthy, to completely fail and any intermediate states, e.g., degraded performance, partially working, some of the customer functionality is working, and is the application or service delivering the expected level of service. Health also considers that functionality could be fine, but performance is substandard indicating that the application or service is not healthy.
A configuration model subcomponent 302 is associated with modeling the system configuration. The configuration model 302 is used to describe the application settings, user controls, default values, various restrictions, etc. An administrative task model subcomponent 303 is associated with modeling administrative tasks, and Includes the actions a user can take upon a system, such as start, stop, add user, add database, and corrective actions that can be called from the health model 30). The model 302 enumerates all that can be done with the application or service. An architecture model 304 is used to describe distributed environments and associated deployment, normally associated with, for example, a large network of clients having the same or similar hardware and software settings and configuration, and distributed databases. Thus, a local application may be dependent on a remote disk array. At deployment, the disk array needs to be instanced at the deployment level with a manifest and using URIs. Since the UR1 is machine independent, distributed systems can also obtain the benefits of the model-based management system of the present invention. A performance model 30S ean be developed to describe the way in which the developer wishes to use metrics for monitoring performance of the application or service. This is closely related to health of the system. A security model 306 ean be generated that describes the types of security associated with the application or service.
Note that the number of models provided herein is not exhaustive, since the developer can provide many different models for managing various aspects of the application or service.
The subject invention ean employ various artificial intelligence based schemes for carrying out various aspects thereof. For example, with respect to models, a process for determining what models can be utilized for a given instance or implementation can be facilitated via an automatic classification system and process. Moreover, such elassifiers can be used to build operational profiles of the system that start to detect system patterns, and learn what is a good state, a bad state and, successful and unsuccessful transactions. This information can then be fei\ back into the corresponding model and used as an updated model for a follow-on system. Such classification can employ a probabilistic and/or statistical-based analysis (e.g., factoring into the analysis utilities and costs) to prognose or infer an action that a user desires to be automatically performed. For example, a support vector machine (SVM) classifier eon be employed. Other classification approaches inelude Bayesian networks, decision trees, and probabilistic classification models providing different patterns of independence can be employed. Classification as used herein also is inclusive of statistical regression that is utilized to develop models of priority.
As will be readily appreciated from the subject specification, the subject invention ean employ classifiers that are explicitly trained (