Patent Application
20050071350
The rapid pace of computer technology development has spawned a diverse array of hardware and software environments, placing limitations on the ability of information technology (IT) departments to respond to change. Businesses/corporations are increasingly leveraging computing to differentiate themselves from the competition, which in turn requires that IT departments to respond rapidly to requests for new, or changes to existing, information systems. Further, the inability to accurately forecast computing needs often results in a constant stream of migration and deployment methods. These are issues that IT departments must contend with over and above the ongoing methods of running and maintaining the systems and network.
IT departments initially increased staff to keep up with growth, but have realized that hiring alone cannot solve the problems. In particular, IT departments must deal with the problem of finding people with the right expertise, as well as problems associated with ill-defined practices and undocumented procedures used to train them. IT departments must often contend with losing a substantial portion of this accumulated knowledge due to personnel turnover. In addition, many of the current IT management processes are manual as opposed to being automated, which requires long lead times to implement changes.
The downward trend in hardware costs over the years has encouraged IT departments to scale out rather than scale up. Scale-up architecture involves migrating to larger, faster systems to gain more computing power. Scale-out architectures distribute the workload over many different servers, so each individual server need only be powerful enough to handle the load of a smaller percentage of the overall systems. System management tools are only capable of monitoring individual systems and network elements, resulting in a different class of management problems that need to be addressed for a collection of diverse resources.
Systems and methods for managing information technology (IT) resources can include at least one resource definition. The resource definition specifies a location and identity of a corresponding resource, and methods that can be performed on the resource. An instance of the resource that includes information from the at least one resource definition is stored. A package is generated based on at least one execution unit (EU), workflow associated with the EU, and the resource definition, wherein the package causes the resource to perform at least one of the methods.
Embodiments of the present invention may be better understood, and their numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings. The use of the same reference symbols in different drawings indicates similar or identical items.
As used herein, the term “resource” refers to software and hardware components that are accessible locally and/or over a network. The resources can include both elemental resources such as servers, switches, file services, disk drives, printers, application programs, and the like, as well as aggregate resources such as web farms and other resources comprising a plurality of more basic components. Resource management can include methods such as locating, identifying, and characterizing existing resources; identifying the dependencies between the various resources; adding new resources, modifying the attributes of existing resources; re-asking or repositioning existing resources; and removing resources. A resource can have attributes and be associated with operational methods. For example, a disk can be formatted, partitioned, and/or appended to an existing drive. A file service can be moved, split, or merged with other file services.
Referring to
Package designer 230 is coupled to communicate with package repository 202 and can use resource definitions 208 to provide a higher level, abstract view of resources. Packages 220, 222 can include one or more execution units (EUs) 231. EUs 231 can encapsulate logic to execute a specific method. An operator can invoke a package 220, 222 via a user interface (UI), a command line interface (CLI) on operator console 232, or other suitable means. In some instances, the user can provide input to package 220, 222. Invoking package 220, 222 can cause a job to be created that is deposited in job database 212. Job controller 214 can extract jobs from job database 212 and provide the jobs to package loader 216. The jobs can be executed by an appropriate EU loader 218 and the results can be returned and displayed to the job initiator.
EUs 231 can be configured to execute a specific method, and typically do not invoke other EUs 231. EUs 231 can be configured as wrappers for capabilities that are implemented elsewhere, such as in deployment packages for a software or hardware resource. In addition to the logic for executing the method, EUs 231 can include logic to rollback (undo) previously performed operations in the event of a failure. EUs 231 can be used in other packages 220, 222 where the same functionality is desired. EUs 231 can include features such as execution logic; a document that provides information regarding the origin, purpose, and authenticity of EU 231; information for locating and loading EU 231; and parameters that must be set before EU 231 can be executed. The parameters can be initialized using any suitable method, such as retrieving resource properties/attributes from resource instance database 210, supplied interactively via operator console 232, and/or using default values, among others. EUs 231 can be stored in repository 202.
Resource definition utility 234 can be used to define resource types that can be managed via management server 104. Resource types can be represented by properties and/or attributes relevant to management server 104. Properties and attributes can also include logic to obtain a corresponding value for the property or attribute once a resource and its type are identified. Further, resources can be associated with methods that allow an IT administrator to perform any available management method for the resource. For example, for a printer, methods may be available that allow the administrator to move the printer from one node 102 to another node 102, rename the printer, and share the printer with other nodes 102. The methods associated with a resource can be deployed with the resource, or made available by other suitable means.
Resource definitions 208 can include pre-defined resource definitions database 224. New resource definitions may be created and existing defined resources may be extended via definition utility 234 and deposited in resource definition extensions database 226. The resource definition extensions 226 can be configured to be usable across product upgrades. In some embodiments, resource definitions 208 can be Extensible Markup Language (XML) schemas, however other suitable formats can be utilized. The attributes and properties of a resource can be addressed individually through a classification scheme and the values can be accessible from resource instance database 210. The properties and attributes can be used to create a job that executes appropriate logic to provide consistent management features for various types of resources.
Resource discovery controller 206 can be configured to access resource definitions 208 to find resources of interest using a discover method that can be specified in resource definitions 208. A resource type can participate in an inheritance hierarchy and a containment hierarchy. Accordingly, a resource type can include one or more resource types that in turn can include one or more resource types, and so on.
In some embodiments, discovery is conducted in a hierarchical fashion, as indicated by the hierarchy shown
Resource discovery controller 206 can utilize containment hierarchy definitions to facilitate identification and characterization of instantiations of aggregate resources. For example, the containment hierarchy for resources 256-282 in
Resource discovery controller 206 can also utilize discovery modules 204 to extract information from existing asset/inventory databases and/or interface to monitoring products that can provide such information. Discovery modules 204 can be implemented as a plug-in to discovery controller 206. The scope and frequency of discovery for various types of resources can be configured via operator console 232 or other suitable method. The jobs can be scheduled to execute during weekends or off-peak hours, executed in parallel to minimize downtime, asynchronously/synchronously etc. The jobs can also be tracked, suspended or cancelled. In the event of errors, the job execution can be halted and EUs 231 informed so that affected resources can be returned to their original state prior to the start of the job. The discovery process can be initiated/repeated as often as needed based on the requirements of the organization.
Discovery modules 204 can access resource definitions 208 and update resource instance database 210. If the information is being extracted from an existing source such as an asset/inventory database, discovery modules 204 can map and transform the information formats suitable for resource instance database 210. Resource instance database 210 can also be updated manually through a resource instance database update tool (not shown) via operator console 232.
Resource instance database 210 can maintain the identified resource instances, and the properties and attributes associated with the instances along with any relationships discovered. The information in resource instance database 210 can be accessed through queries. The contents of resource instance database 210 can vary depending on the resource types of interest, methods of discovery, and scope of discovery.
Operator console 232 can display symbols representing packages 220, 222 and resources available for selection. Once an operator selects a package 220, 222 and the resource(s) from the operator's console 232, a job can be inserted into job database 212 for dispatching and tracking. The job can be scheduled to run immediately or at a later time. Job database 212 can monitor the state and schedule of jobs to assist job controller 214 in dispatching jobs. Job database 212 can be queried as to the progress of a job and also used to suspend or cancel a job in progress.
Job controller 214 can dispatch and control execution of jobs. Job controller 214 can launch a package loader 216 to execute the package 220, 222 associated with a job. The package loader 216 can facilitate linking input parameters to the executing package 220, 222 along with providing interfaces to job related services such as logging and rollback. The executing package 220, 222 is typically in binary object code format. Additionally, a package 220, 222 can request job controller 214 to execute another of packages 220, 222.
Package loader 216 can dispatch EUs 231 to an appropriate EU loader 218 for execution. The results from the execution of EU 231 can be stored by job controller 214 to facilitate linkage for subsequent EUs 231, as required. Additionally, EU loader 218 can provide an interface to EU 231 to save state information.
If an EU 231 fails, the job execution can be halted and package loader 216 can invoke the executed EUs 231 in reverse order to undo the effects of their previous execution using the stored state information, if necessary. After successful package execution, package loader 216 can invoke an executed EUs' cleanup method and use the save state information for any cleanup that might be required. Job controller 214 can be configured to capture status in job database 212 or other suitable location after EU execution, along with results and output from EU 231. EU loader 218 and package loader 216 can also provide appropriate interfaces to the packages 220, 222 and EUs 231 to store trace/debug output.
EUs 231 and package loader 216 can be configured to run on management server 104 and/or nodes 102.
Roles can be defined for users of management server 104. For example, anyone who wishes to access components of management server 104 may be required to be registered as a user. User authentication can be implemented to require a login name and/or password, or other suitable access control features.
Users authorized to act as administrators can be placed on a list that identifies the users as administrators. Additional users can be explicitly tagged to play an administrative role. Administrators can be given access to fill any role and use any feature of management server 104.
A resource administrator role can be implemented to identify users who are authorized to define new resources or modify existing resources in resource definitions 208, configure the frequency and scope of resource discovery, associate packages 220, 222 with operation methods of a resource, and other suitable functions.
A resource discoverer role can be implemented to identify users who are authorized to explicitly initiate resource discovery.
A process automation EU designer role can be implemented to identify users who are authorized to design new EUs 231 and deposit the EUs 231 in repository 202.
A process automation package designer role can be implemented to identify users who are authorized to design new packages 220, 222 using the available EUs 231 and depositing packages 220, 222 in repository 202 for job creation.
A process automation tester role can be implemented to identify users who are authorized to validate packages 220, 222, job creation, and job execution.
A process automation package approver role can be implemented to identify users who are authorized to approve a package 220, 222 for general availability once it has been tested. Note that only approved packages 220, 222 will show up in the list of operational methods for a resource.
A process automation job creator role can be implemented to identify users who are authorized to create jobs using the approved packages 220, 222 and make them available in job database 212.
A process automation job dispatcher role can be implemented to identify users who are authorized to dispatch jobs available in job database 212 and track the jobs to completion. Other suitable roles can be implemented in addition to, or instead of, the aforementioned roles.
Management server 104 can be configured to conform to the security requirements defined by the operating environment by participating in the appropriate security domain hierarchy. Appropriate impersonation and delegation capabilities can be enabled to ensure that cross-machine operations on nodes 102 perform as expected.
Operations performed by management server 104, such as package creation, package approval, job creation, job submission, and role changes, among others, can be logged for auditing and tracking. The logged information can be stored in any suitable location and can be configured to require appropriate authorization to access.
Table I shows an embodiment of elements and corresponding attributes that can be included in an XML schema for a resource definition 208. Resource definitions 208 can specify one or more method, property, structure, dependency, and/or enumeration elements. One or more attributes can be associated with the elements. Attributes can be specified for the resource to allow components in management server 104 to locate and handle the resource.
A PROPERTY element defined as a resource type implicitly defines a containment relationship between the type being defined and the contained type being defined as a property, and is used by the discovery controller 206 to automatically create relationships in the instance database based on this containment relationship. Resource definitions 208 can be generated manually, with the aid of a graphical user interface, and/or any other suitable method. Note that other elements and attributes can be included in resource definitions 208, in addition to, or instead of, the elements and attributes shown in Table I.
An example of a resource definition 208 that follows the XML schema format outlined in Table I for a Automated Deployment Services (ADS) Controller is shown below:
In the example above, the METHODS, PROPERTIES, and STRUCTURES elements include more than one respective METHOD, PROPERTY, and STRUCTURE sub-elements. Note that other elements, such as DEPENDENCIES and ENUMERATIONS can also include a sequence of more than one corresponding sub-element.
Referring to
Presentation layer 302 can include a front end, stencils/shapes and their associated behaviors, and an extensibility mechanism that allows interfacing with dialog layer 304. Referring to
The example of GUI 400 shown in
When a new package 220, 222 is written for a resource operation that requires user input when invoked, the interface for such input needs to be developed as well. GUI 400 can be implemented with logic instructions that examine the packages 220, 222 and EUs 231 to identify entry points. For each of the entry points, the logic can determine the domain to which the input data belongs and present the user with the option to enter data from that domain. Additionally, different parts of user inputs can be tied together to further narrow the domain that is valid for other inputs.
For each input, package designer 230 can indicate whether the input is constant, user-provided, or available from resource instance database 210. For the first two, the layout format can take into consideration the type information for lengths and appropriate edit masks. If the input is available from resource instance database 210, a listbox can be created and populated with selectable instances of the particular resource type.
GUI 400 can include features such as horizontal and/or vertical scroll bars; drop-down menus; commands such as move, copy, paste, cut, save, print, and resize; and features that allow windows 402 and 404 to be resized. Other suitable features, such as features commonly provided with application software for the WINDOWS® Operating System by Microsoft Corporation, Redmond, Wash., can also be implemented, as desired. Further, other symbols representing other functions can be included in window 402 in addition to, or instead of, the symbols shown in
Functional core layer 306 can encapsulate the flow of package 220, 222 in a collection of in-memory objects that can be manipulated, as well as loaded and saved to disk. By tying the objects together, an execution flow can be created that can be stored as source code, such as C# source code, compiled, and executed. Referring to
Referring to
Referring to
ApplicationController 706 can be placed in a PAC Agents namespace that includes presentation, abstraction and control classes. The abstraction class can include one or more classes from the functional core 306 that make up the data the agent is working on, for example, ModelerAbstractions:Shape 718. The presentation class can be a user interface form that displays abstraction data to the user and allows the user to interact with that data. The control class is responsible for managing the interaction between the abstraction and the presentation class, thereby consistently organizing the responsibilities of ApplicationController 706 into manageable pieces.
DocumentController 720 can be responsible for managing the interaction between the user interface elements that represent a workflow document and the workflow document itself (i.e. the workflow designer object model). PackageController 722 can be responsible for managing the interaction between the package (workflow) document and the user interface elements in the flow diagram that represents the workflow. StatementEditControllerBase 724 can be a base class that provides polymorphic access between PackageController 722 and ExpressionEditController 726. ExpressionEditController 726 can be responsible for editing the details of a workflow statement which is represented visually in the flow diagram as a shape or group of shapes. When editing a workflow statement in UI 400, which can be invoked by clicking a statement shape in the diagram, a modal window can be displayed that allows the user to edit the details of the workflow statement.
A number of Representation objects in functional core layer 306 can be used to create a package flow. The root node of the flow can be a package object that includes the inputs and outputs of the package, along with StatementCollection object 730, Statement object 732, and Expression object 734, and ExpressionCollection object 736 that include the actual flow of the package.
The StatementCollection object 730 can include objects of the Statement type, or any object that derives from that type, such as ResourceBindStatement 738, EUExecuteStatement 740, Declaration 742, ResourcelnvokeStatement (not shown), and ConditionalStatement (not shown). The ResourceBindStatement 738 can be used to bind to a specific instance of a specific resource at runtime. The binding allows the flow to inspect the properties of the resource as well as executing operational methods off of the resource instance.
Operational methods of a resource can be invoked using a ResourcelnvokeStatement (not shown). The inputs from the operational method can be assigned from other objects, including package inputs, outputs from other resources, and outputs from an EUExecuteStatement 740 and Declaration statements 742. EUExecuteStatement 740 can be used to execute an EU 231 (
PrimitiveExpression 746 is an expression that does not involve variables. A Reference 748 can be a reference to a variable that was defined using a Declaration 742, and can be used in cases where a variable must be created to temporarily store a value computed by an expression, but which has not been declared as a variable by the user.
The properties of a resource, and inputs and outputs from EUs 231 can be used as inputs to other objects in the flow. A ForeachStatement (loop) can be used to iterate through a collection of objects, including iterating through contained resources. A ConditionalStatement can be used to drive logic based on the content of one of the outputs. For example, if the flow includes a bound resource WindowsServer, the conditional could take different actions based on whether the VersionMajor was greater than 4.
A Repository abstraction class can include objects such as RepositoryFacade 750, ResourceRepositoryFacade 752, PackageRepositoryFacade 754, and EURepositoryFacade 756 that can be queried by the Representation objects to get the needed information to populate data including the names of the available EUs 231, packages 220, 222, and resources, along with the inputs and outputs for each. Note that the interaction between the Repository abstraction class and the Representation objects can remain unchanged while the underlying mechanism for gathering the required data can be changed.
Note that other suitable classes can be utilized in package 230, in addition to, or instead of, the classes described herein.
Identifying and cataloging aggregated service resources and their dependencies allows organizations to have a flexible environment where the aggregated service resources no longer are tied to physical hardware and can be moved easily using a “drag-drop” metaphor. Once discovered and identified, defined methods can be performed on a resource.
The logic modules, processing systems, and circuitry described herein may be implemented using any suitable combination of hardware, software, and/or firmware, such as Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuit (ASICs), or other suitable devices. The logic modules can be independently implemented or included in one of the other system components. Similarly, other components are disclosed herein as separate and discrete components. These components may, however, be combined to form larger or different software modules, logic modules, integrated circuits, or electrical assemblies, if desired.
While the present disclosure describes various embodiments, these embodiments are to be understood as illustrative and do not limit the claim scope. Many variations, modifications, additions and improvements of the described embodiments are possible. For example, those having ordinary skill in the art will readily implement the processes necessary to provide the structures and methods disclosed herein. Variations and modifications of the embodiments disclosed herein may also be made while remaining within the scope of the following claims. The functionality and combinations of functionality of the individual modules can be any appropriate functionality. In the claims, unless otherwise indicated the article “a” is to refer to “one or more than one”.
| Number | Date | Country | |
|---|---|---|---|
| 60499302 | Aug 2003 | US |
