US20110126197A1 - System and method for controlling cloud and virtualized data centers in an intelligent workload management system - Google Patents

Abstract

The system and method for controlling cloud and virtualized data centers described herein may include a computing environment having a model-driven, service-oriented architecture for creating collaborative threads to manage workloads, and further to creating cloud images having embedded management agents and identity services for validating the cloud images prior to deployment into the cloud and virtualized data centers and controlling, monitoring, and auditing activity associated with the cloud images following deployment into the cloud and virtualized data centers.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application claims the benefit of U.S. Provisional Patent Application Ser. No. 61/264,562, entitled “System and Method for Intelligent Workload Management,” filed on Nov. 25, 2009, the contents of which are hereby incorporated by reference in entirety.
• In addition, this application is further related to co-pending U.S. patent application Ser. No. ______, entitled “System and Method for Intelligent Workload Management,” filed on ______, co-pending U.S. patent application Ser. No. ______, entitled “System and Method for Recording Collaborative Information Technology Processes in an Intelligent Workload Management System,” filed on ______, co-pending U.S. patent application Ser. No. ______, entitled “System and Method for Managing Information Technology Models in an Intelligent Workload Management System,” filed on ______, co-pending U.S. patent application Ser. No. ______, entitled “System and Method for Discovery Enrichment in an Intelligent Workload Management System,” filed on ______, co-pending U.S. patent application Ser. No. ______, entitled “System and Method for Providing Service Layer Blueprints in an Intelligent Workload Management System,” filed on ______, and co-pending U.S. patent application Ser. No. ______, entitled “System and Method for Providing Scorecards to Visualize Services in an Intelligent Workload Management System,” filed on ______, each of which further claim benefit to U.S. Provisional Patent Application Ser. No. 61/264,562, and each of which are hereby further incorporated by reference in entirety.
FIELD OF THE INVENTION
• The invention relates to a system and method for controlling cloud and virtualized data centers in an intelligent workload management, and in particular, to a computing environment having a model-driven, service-oriented architecture for creating collaborative threads to manage workloads, and further to creating cloud images having embedded management agents and identity services for validating the cloud images prior to deployment into the cloud and virtualized data centers and controlling, monitoring, and auditing activity associated with the cloud images following deployment into the cloud and virtualized data centers.
BACKGROUND OF THE INVENTION
• “Cloud computing” generally refers to a computing environment with dynamically scalable and often virtualized resources, which are typically provided as services over the Internet. For example, cloud computing environments often employ the concept of virtualization as a preferred paradigm for hosting workloads on any appropriate hardware. The cloud computing model has become increasingly viable for many enterprises for various reasons, including that the cloud infrastructure may permit information technology resources to be treated as utilities that can be automatically provisioned on demand, while also limiting the cost of services to actual resource consumption. Moreover, consumers of resources provided in cloud computing environments can leverage technologies that might otherwise be unavailable. Thus, as cloud computing and cloud storage become more pervasive, many enterprises will find that moving data center to cloud providers can yield economies of scale, among other advantages.
• However, while much of the information technology industry moves toward cloud computing and virtualization environments, existing systems tend to fall short in adequately addressing concerns relating to managing or controlling workloads and storage in such environments. For example, cloud computing environments are generally designed to support generic business practices, meaning that individuals and organizations typically lack the ability to change many aspects of the platform. Moreover, concerns regarding performance, latency, reliability, and security present significant challenges, as outages and downtime can lead to lost business opportunities and decreased productivity, while the generic platform may present governance, risk, and compliance concerns. In other words, once organizations deploy workloads beyond the boundaries of their data centers, lack of visibility into the computing environment may result in significant management problems.
• While these types of problems tend to be pervasive in cloud computing and virtualization environments due to the lack of transparency, existing systems for managing and controlling workloads that are physically deployed and/or locally deployed in home data centers tend to suffer from many similar problems. In particular, information technology has traditionally been managed in silos of automation, which are often disconnected from one another. For example, help desk systems typically involve a customer submitting a trouble ticket to a remedy system, with a human operator then using various tools to address the problem and close the ticket, while monitoring systems that watch the infrastructure to remediate problems may remain isolated from the interaction between the customer and the help desk despite such interaction being relevant to the monitoring system's function.
• As such, because existing systems for managing infrastructure workloads operate within distinct silos that typically do not communicate with one another, context that has been exchanged between two entities can often be lost when the workload moves to the next step in the chain. When issues surrounding workload management are considered in the context of business objectives, wherein information technology processes and business issues collectively drive transitions from one silo to another, modern business tends to move at a speed that outpaces information technology's ability to serve business needs. Although emerging trends in virtualization, cloud computing, appliances, and other models for delivering services have the potential to allow information technology to catch up with the speed of business, many businesses lack the knowledge needed to intelligently implement these new technologies.
• For example, emerging service delivery models often lead to deployed services being composed and aggregated in new and unexpected ways. In particular, rather than designing and modeling systems from the ground up, new functionality is often generated on-the-fly with complex building blocks that tend to include various services and applications that have traditionally been isolated and stand-alone. As such, even though many emerging service delivery models provide administrators and users with a wider range of information technology choices than have ever before been available, the diversity in technology often compounds business problems and increases the demand for an agile infrastructure. Thus, despite the advantages and promise that new service delivery models can offer businesses, existing systems tend to fall short in providing information technology tools that can inform businesses on how to intelligently implement an information technology infrastructure in a manner that best leverage available technology to suit the particular needs of a business.
SUMMARY OF THE INVENTION
• According to one aspect of the invention, a system and method for intelligent workload management may generally provide a computing environment having a fluid architecture, whereby the computing environment may create common threads to manage workloads that converge information relating to user identities and access credentials, provisioned and requested services, and physical and virtual infrastructure resources, among other things. In one implementation, services provided in the computing environment may generally include various aggregated physical and/or virtual resources, while applications may include various aggregated services and workloads may include various compositions of whole services, separate services, and/or sub-services that work together. For example, in response to a user requesting a service that performs a particular function or application, the intelligent workload management system (or alternatively “the workload management system”) may create a workload to manage provisioning the user with a tuned appliance configured to perform the particular function or application, whereby the tuned appliance may provide the requested service for the user. To manage the workload, the workload management system may create a resource store that points to a storage location for the appliance, declare a service level agreement and any runtime requirements that constrain deployment for the appliance, obtain a certificate that provides attestation tokens for the user and the appliance, and create a profile that provides an audit trail of actual lifecycle behavior for the appliance (e.g., events and performance metrics relating to the appliance). Thus, workflows created in the computing environment may converge various sources of information within a common thread, which the workload management system may use to manage the workload (e.g., actual metrics for a particular workload can be compared to anticipated metrics for the workload to determine whether various services underlying the workload function as intended).
• According to one aspect of the invention, the system and method for intelligent workload management may operate in a model-driven architecture, which may merge information relating to user identities with services that may be running in an information technology infrastructure. As such, the information merged in the model-driven architecture may be referenced to determine specific users or organizational areas within the infrastructure that may be impacted in response to a particular change to the infrastructure model. Thus, whereas information technology has traditionally been managed within disparate silos, where context exchanged between any two entities may be lost at the next step in the chain, the model-driven architecture may track context for information technology workloads from start to finish. As such, tracking context for the information technology workloads may provide audit trails that can then be used to identify a relevant user, application, system, or other entity that can provide assistance with a particular issue. Moreover, in the context of managing workloads for virtualized services, where different users typically have to communicate with one another on-demand, the audit trail that the model-driven architecture enables may track end-to-end workload activities and thereby provide visibility and notice to users, applications, systems, services, or any other suitable entity that may be impacted by the workload.
• According to one aspect of the invention, the system and method for intelligent workload management may enable agile and flexible management for an information technology infrastructure, which may enable the infrastructure to move at the speed of modern business. For example, the system and method for intelligent workload management may further operate in a service-oriented architecture unifying various heterogeneous technologies, which may provide businesses with the capability to deploy information technology resources in a manner that can meet business objectives. For example, the service-oriented architecture may provide adaptable, interoperable, and user-friendly information technology tools to manage the infrastructure in a manner that addresses many typical business challenges that information technology organizations face. For example, while the model-driven architecture may employ virtualization features to provide manageable workloads that can move efficiently through the infrastructure, the service-oriented architecture may merge different technologies to provide various coordinated systems that can cooperate to optimally execute portions of an overall orchestrated workload. As such, the model-driven and service-oriented architectures may collectively derive data from the information technology infrastructure, which may inform intelligent information technology choices that meet the needs of businesses and users.
• According to one aspect of the invention, the system and method for intelligent workload management may be used to manage workloads created in response to service requests. For example, any suitable user, application, system, or other entities may request a service from the workload management system, wherein the request may include a desired performance level (or service level) for the service, any components or criteria required for the service, comments to provision the service in a certain manner, or any other suitable information for the requested service. In response to receiving the service request, human and/or automated approvers (or service delivery managers) may collaboratively manage the service request and determine whether the service can be provisioned as requested. Furthermore, the approvers may provide feedback on the service provisioning decision, which may create an interactive collaborative “conversation” between requesters, approvers, and other entities in the management thread. In one implementation, various security policies may be built into the model to automatically approve or deny certain requests, wherein the security policies may be dynamically updated in response to handling similar requests (e.g., a request for Bit Torrent storage may be automatically denied because a particular security policy indicates that peer-to-peer file sharing violates a company policy).
• According to one aspect of the invention, services provisioned in the workload management system may include any suitable combination of physical infrastructure resources and virtualized infrastructure resources. For example, to provision virtualized services that can abstract underlying physical platforms and share computing resources in a manner that may address many needs for immediacy in business environments, the workload management system may manage physical infrastructure resources and virtualized infrastructure resources to support provisioning virtualized services. Thus, the service-oriented architecture employed in the workload management system may enable management for the physical infrastructure resources (e.g., rack-mounting, configuring, and otherwise physically installing servers, storage resources, and other devices), and may further enable management for the virtualized infrastructure resources (e.g., pre-configuring provisioned services with identity management features, denying, flagging, or auditing service requests from unauthorized entities, etc.). Moreover, the workload management system may be considered a service in that the workload management service may be built dynamically in response to service requests (e.g., because a management infrastructure can introduce computational burdens just as any other resource, limiting the existence of the workload management infrastructure to an on-demand service can free computational resources for other tasks having a greater need for immediacy).
• According to one aspect of the invention, to manage collaborative service provisioning in contexts that combine physical and virtualized resources, the workload management system may store a history of interaction between requesters, approvers, and other entities in service provisioning threads, and may further record, log, and save traffic and activity between such entities in the service provisioning threads. As such, various processes that occur during service provisioning may be recorded and injected into a real-time stream that can subsequently be played back, thereby capturing the service provisioning processes as a whole, including any responses that human and/or automated entities may provide during the collaborative process. During processes for collaboratively managing the information technology infrastructure, the workload management system may expose portions of the infrastructure model to entities involved in the management processes. In one implementation, the workload management system may expose “just enough context” to entities involved in the management processes, whereby the involved entities may view the respective portions of the infrastructure model for which such entities have management responsibility (e.g., prior to implementing any particular change to the infrastructure, the workload management system may query the model and determine an impact of the change, notify impacted entities, etc.).
• According to one aspect of the invention, virtualized services provisioned in the workload management system may further include injection points for adding and/or removing information from the provisioned services. For example, any particular virtualized service may generally include a layered architecture that includes injection points for inserting “zero residue” management agents that can manage the service and ensure that the service functions correctly. Thus, in one implementation, zero residue management agents may be inserted within virtualized services at build time, run time, or any other suitable point in a lifecycle for the virtualized services, wherein the particular management agents inserted within the virtualized services may depend on a type of management required. For example, the workload management system may analyze a configuration of the service, a lifecycle point for the service, or other suitable information for the service to derive a recipe of the management agents to be injected (e.g., the recipe may depend on a required service level for the service, a current operational state for the infrastructure model, services running in the infrastructure, a type of management required for the running services, etc.).
• Other objects and advantages of the invention will be apparent to those skilled in the art based on the following drawings and detailed description.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1A illustrates a block diagram of an exemplary model-driven architecture in a system for intelligent workload management, according to one aspect of the invention.
• FIG. 1B illustrates a block diagram of an exemplary service-oriented architecture in the system for intelligent workload management, according to one aspect of the invention.
• FIG. 2 illustrates a flow diagram of an exemplary method for intelligent workload management, according to one aspect of the invention.
• FIG. 3 illustrates an exemplary system for generating single sign-on workload identities in the workload management system, according to one aspect of the invention.
• FIG. 4 illustrates an exemplary method for generating single sign-on workload identities in the workload management system, according to one aspect of the invention.
• FIG. 5A illustrates a block diagram of an exemplary service distribution that can be managed with zero residue management agents in the intelligent workload management system, whileFIG. 5B illustrates an exemplary lifecycle for a service distribution managed with the zero residue management agents, according to one aspect of the invention.
• FIG. 6 illustrates a flow diagram of an exemplary method for managing different modes of a service distribution lifecycle with the zero residue management agents in the intelligent workload management system, according to one aspect of the invention.
• FIG. 7 illustrates a block diagram of an exemplary system for controlling cloud and virtualized data centers in the intelligent workload management system, according to one aspect of the invention.
• FIG. 8 illustrates a flow diagram of an exemplary method for controlling cloud and virtualized data centers in the intelligent workload management system, according to one aspect of the invention.
DETAILED DESCRIPTION
• According to one aspect of the invention,FIG. 1A illustrates an exemplary model-drivenarchitecture100A in a system for intelligent workload management, whileFIG. 1B illustrates an exemplary service-orientedarchitecture100B in the system for intelligent workload management. In one implementation, the model-drivenarchitecture100A shown inFIG. 1A and the service-orientedarchitecture100B shown inFIG. 1B may include various components that operate in a substantially similar manner to provide the functionality that will be described in further detail herein. Thus, any description provided herein for components having identical reference numerals inFIGS. 1A and 1B will be understood as corresponding to such components in bothFIGS. 1A and 1B, whether or not explicitly described.
• In one implementation, the model-drivenarchitecture100A illustrated inFIG. 1A and the service-orientedarchitecture100B illustrated inFIG. 1B may provide an agile, responsive, reliable, and interoperable information technology environment, which may address various problems associated with managing an information technology infrastructure110 (e.g., growing revenues and cutting costs, managing governance, risk, and compliance, reducing times to innovate and deliver products to markets, enforcing security and access controls, managing heterogeneous technologies and information flows, etc.). To that end, the model-drivenarchitecture100A and the service-orientedarchitecture100B may provide a coordinated design for the intelligent workload management system (or alternatively “the workload management system”), wherein the coordinated design may integrate technologies for managing identities, enforcing policies, assuring compliance, managing computing and storage environments, providing orchestrated virtualization, enabling collaboration, and providing architectural agility, among other things. The model-drivenarchitecture100A and the service-orientedarchitecture100B may therefore provide a flexible framework that may enable the workload management system to allocate various resources114 in theinformation technology infrastructure110 in a manner that balances governance, risk, and compliance with capacities for internal and external resources114. For example, as will be described in further detail herein, the workload management system may operate within the flexible framework that the model-drivenarchitecture100A and the service-orientedarchitecture100B to deliver information technology tools for managing security, performance, availability, and policy objectives for services provisioned in theinformation technology infrastructure110.
• Identity Management
• In one implementation, as noted above, the technologies integrated by the model-drivenarchitecture100A and the service-orientedarchitecture100B may enable managing identities in theinformation technology infrastructure110. In particular, managing identities may present an important concern in the context of managing services in theinformation technology infrastructure110 because security, performance, availability, policy objectives, and other variables may have different importance for different users, customers, applications, systems, or other resources114 that operate in theinformation technology infrastructure110. As such, the model-drivenarchitecture100A and the service-orientedarchitecture100B may include various components that enable identity management in theinformation technology infrastructure110.
• For example, in one implementation, the workload management system may include an access manager120 (e.g., Novell Access Manager), which may communicate with anidentity vault125 and control access to content, applications, services, and other resources114 in theinformation technology infrastructure110. In one implementation, theaccess manager120 may enforce various policy declarations to provide authentication services for any suitable component in theinformation technology infrastructure110. For example, theidentity vault125 may include various directories that organize user accounts, roles, policies, and other identity information that theaccess manager120 can reference to generate authorization decisions. Theaccess manager120 and theidentity vault125 may further support federated user identities, wherein a user at anyparticular client resource115 may submit single sign-on authentication credentials to theaccess manager120, which may then control access to any suitable resource114 in theinformation technology infrastructure110 with the single sign-on authentication credentials (e.g., user names, identifiers, passwords, smart cards, biometrics, etc.). Moreover, the identity information stored in theidentity vault125 may be provided to asynchronization engine150, whereby thesynchronization engine150 may provide interoperable and transportable identity information throughout the architecture (e.g., via an identity fabric within anevent bus140 that manages transport throughout the architecture).
• In one implementation, providing the identity information stored in theidentity vault125 to thesynchronization engine150 may form portable identities that correspond to independent digital representations for various users, applications, systems, or other entities that interact with theinformation technology infrastructure110. In particular, the identities maintained in thesynchronization engine150 may generally include abstractions that can provide access to authoritative attributes, active roles, and valid policies for entities that the identity abstractions represent. Thus, synchronizing the identity information stored in theidentity vault125 with thesynchronization engine150 may provide independent and scalable digital identities that can be transported across heterogeneous applications, services, networks, or other systems, whereby the workload management system may handle and validate the digital identities in a cooperative, interoperable, and federated manner.
• In one implementation, the identities stored in theidentity vault125 and synchronized with thesynchronization engine150 may be customized to define particular attributes and roles that the identities may expose. For example, a user may choose to create one identity that exposes every attribute and role for the user to applications, services, or other systems that reside within organizational boundaries, another identity that limits the attributes and roles exposed to certain service providers outside the organizational boundaries, and another identity that provides complete anonymity in certain contexts. The identities maintained in thesynchronization engine150 may therefore provide awareness over any authentication criteria that may be required to enable communication and collaboration between entities that interact with the workload management system. For example, thesynchronization engine150 may include a service that can enforce policies controlling whether certain information stored in theidentity vault125 can be shared (e.g., through theaccess manager120 or other information technology tools that can manage and customize identities).
• In one implementation, the workload management system may further manage identities in a manner that enables infrastructure workloads to function across organizational boundaries, wherein identities for various users, applications, services, and other resources114 involved in infrastructure workloads may be managed with role aggregation policies and logic that can support federated authentication, authorization, and attribute services. For example, in one implementation, theaccess manager120, theidentity vault125, and thesynchronization engine150 may manage identity services externally to applications, services, and other resources114 that consume the identities, which may enable the workload management system to control access to services for multiple applications using consistent identity interfaces. In particular, theaccess manager120, theidentity vault125, and thesynchronization engine150 may define standard interfaces for managing the identity services, which may include authentication services, push authorization services (e.g., tokens, claims, assertions, etc.), pull authorization services (e.g., requests, queries, etc.), push attribute services (e.g., updates), pull attribute services (e.g., queries), and audit services.
• As such, in one implementation, the workload management system may employ the identity services provided in the model-drivenarchitecture100A and the service-orientedarchitecture100B to apply policies for representing and controlling roles for multiple identities within any particular session that occurs in theinformation technology infrastructure110. For example, in response to a session that includes a user logging into aclient machine115 and invoking a backup service, the workload management system may manage the session with multiple identities that encompass the user, the backup service, and theclient machine115. The workload management system may further determine that the identity for theclient machine115 represents an unsecured machine that resides outside an organizational firewall, which may result in the workload management system retrieving a policy from theidentity vault125 and/or thesynchronization engine150 and applying the policy to the session (e.g., the policy may dynamically prevent themachine115 and the user from being active in the same session). Thus, the workload management system may manage multiple identities that may be involved in any particular service request to control and secure access to applications, services, and other resources114 in theinformation technology infrastructure110.
• In one implementation, the model-drivenarchitecture100A and the service-orientedarchitecture100B may further provide identity services for delegating rights in delegation chains that may involve various different levels of identities. In particular, any particular user may have various roles, attributes, or other identities that define various rights for the user. As such, in one implementation, the rights delegation identity service may enable the user to delegate a time-bounded subset of such rights to a particular service, wherein the service can then make requests to other services on behalf of the user during the delegated time. For example, a user may delegate rights to a backup service that permits the backup service to read a portion of a clusteredfile system195 during a particular time interval (e.g., 2 a.m. to 3 a.m.). In response to thefile system195 receiving the read request from the backup service, the identity services may enable thefile system195 to audit identities for the backup service and the user, and further to constrain read permissions within thefile system195 based on the relevant rights defined by the identities for the backup service for the user.
• In one implementation, the model-drivenarchitecture100A and the service-orientedarchitecture100B may further provide identity services for defining relative roles, wherein relative roles may be defined where a principal user, application, service, or other entity can only assume a particular role for a particular action when a target of the action has a particular set of identities. For example, a user having a doctor role may only assume a doctor-of-record relative role if an identity for a target of the doctor-of-record action refers to one of the user's patients. In another example, applications may request controlled access to information about an identity for a certain user, wherein the application may, retrieve the requested information directly from the access-controlled identity for the user. In particular, the workload management system may determine the information requested by the application and create a workload that indicates to the user the information requested by the application and any action that the application may initiate with the requested information. The user may then make an informed choice about whether to grant the application access to the requested information. Thus, having identities to enable applications may eliminate a need for application-specific data storage or having the application access separate a directory service or another identity information source.
• Thus, in the model-drivenarchitecture100A and the service-oriented architecture1008, the identity management services may create crafted identities combined from various different types of identity information for various users, applications, services, systems, or other information technology resources114. In one implementation, while the identity information may generally be stored and maintained in theidentity vault125, the identity information can be composed and transformed through theaccess manager120 and/or thesynchronization engine150, with the resulting identity information providing authoritative statements for represented entities that span multiple authentication domains within and/or beyond boundaries for theinformation technology infrastructure110. For example, an identity for a user may be encapsulated within a token that masks any underlying credential authentication, identity federation, and attribute attestation. Moreover, in one implementation, the identity services may further support identities that outlive entities that the identities represent and multiple identity subsets within a particular identity domain or across multiple identity domains. As such, the identity services provided in the model-drivenarchitecture100A and the service-orientedarchitecture100B may include various forms of authentication, identifier mapping, token transformation, identity attribute management, and identity relationship mapping.
• Policy Enforcement
• In one implementation, as noted above, the technologies integrated by the model-drivenarchitecture100A and the service-orientedarchitecture100B may enable enforcing policies in theinformation technology infrastructure110. In particular, enforcing policies may present an important concern in the context of managing services in theinformation technology infrastructure110 because policies may be driven from multiple hierarchies and depend on operational, legislative, and organizational requirements that can overlap, contradict, and/or override each other. As such, the model-drivenarchitecture100A and the service-orientedarchitecture100B may include various components for defining policies in standardized languages that can be translated, merged, split, or otherwise unified as needed. To that end, the workload management system may have multiple policy decision points and policy definition services for consistently managing and enforcing policies in theinformation technology infrastructure110
• As such, in one implementation, the model-drivenarchitecture100A and the service-orientedarchitecture100B may provide standard policy languages and service interfaces that enable the workload management system to make consistent decisions based on flexible user needs. In particular, any suitable resource114 (including workloads and computational infrastructure) may be provided with access to standardized instrumentation that provides knowledge regarding information that may be available, desired, or allowed in the workload management system. In one implementation, the workload management system may invoke various cooperating policy services to determine suitablephysical resources114a(e.g., physical servers, hardware devices, etc.),virtualized resources114b(e.g., virtual machine images, virtualized servers, etc.),configuration resources114c(e.g.; management agents, translation services, etc.), storage resources (e.g., the clusteredfile system195, one ormore databases155, etc.), or other resources114 for a particular workload. For example, thesynchronization engine150 may dynamically retrieve various policies stored in thedatabases155, and anevent audit service135bmay then evaluate the policies maintained in thesynchronization engine150 independently from services that subsequently enforce policy decisions (e.g., theevent audit service135bmay determine whether the policies permit access to certain information for a particular application and the application may then enforce the policy determination).
• In one implementation, separating policy evaluation within theevent audit service135bfrom policy enforcement within consuming services may enable the workload management system to access the consuming services and manage policy-based control for the service in an independent and simultaneous manner. Theevent audit service135bmay include a standardized policy definition service that can be used to define policies that span multiple separate application and management domains. For example, in one implementation, the policy definition service may create, manage, translate, and/or process policies separately from other service administration domains and interfaces. As such, the policy definition service may provide interoperability for the separate domains and interfaces, and may further enable compliance services that may be provided in acorrelation system165 and remediation services that may be provided in aworkload service135a.
• In one implementation, to ensure correct and effective policy decisions, the policy definition service provided within theevent audit service135bmay be configured to obtain data relating to a current state and configuration for resources114 managed in theinfrastructure110 in addition to data relating to dependencies or other interactions between the managed resources114. For example, amanagement infrastructure170 may include adiscovery engine180bthat dynamically monitors various events that theinfrastructure110 generates and pushes onto theevent bus140, which may include an event backplane for transporting the events. Moreover, thediscovery engine180bmay query theinfrastructure110 to determine relationships and dependencies among users, applications, services, and other resources114 in theinfrastructure110. As such, thediscovery engine180bmay monitor theevent bus140 to obtain the events generated in theinfrastructure110 and synchronize the events to thesynchronization engine150, and may further synchronize information relating to the relationships and dependencies identified in theinfrastructure110 to thesynchronization engine150. In one implementation, theevent audit service135bmay then evaluate any events, resource relationships, resource dependencies, or other information describing the operational state and the configuration state of theinfrastructure110 in view of any relevant policies and subsequently provide any such policy evaluations to requesting entities.
• In one implementation, the policy definition service may include standard interfaces for defining policies in terms of requirements, controls, and rules. For example, the requirements may generally be expressed in natural language in order to describe permitted functionality, prohibited functionality, desirable functionality, and undesirable functionality, among other things (e.g., theevent audit service135bmay capture legislative regulations, business objectives, best practices, or other policy-based requirements expressed in natural language). The controls may generally associate the requirements to particular objects that may be managed in the workload management system, such as individual users, groups of users,physical resources114a,virtualized resources114b, or any other suitable object or resource114 in theinfrastructure110. In one implementation, the policy definition service may further define types for the controls. For example, the type may include an authorization type that associates an identity with a particular resource114 and action (e.g., for certain identities, authorizing or denying access to a system or a file, permission to alter or deploy a policy, etc.), or the type may include an obligation type that mandates a particular action for an identity.
• Thus, in one implementation, translating requirements into controls may partition the requirements into multiple controls that may define policies for a particular group of objects. Furthermore, rules may apply certain controls to particular resources114, wherein rules may represent concrete policy definitions. For example, the rules may be translated directly into a machine-readable and machine-executable format that information technology staff may handle and that theevent audit service135bmay evaluate in order to manage policies. In one implementation, the rules may be captured and expressed in any suitable domain specific language, wherein the domain specific language may provide a consistent addressing scheme and data model to instrument policies across multiple domains. For example, adefinitive software library190 may include one or more standardized policy libraries for translating between potentially disparate policy implementations, which may enable theevent audit service135bto provide federated policies interoperable across multiple different domains. As such, the rules that represent the policy definitions may include identifiers for an originating policy implementation, which the policy definition service may then map to the controls that the rules enforce and to the domain specific policy language used in the workload management system (e.g., through the definitive software library190).
• Compliance Assurance
• In one implementation, as noted above, the technologies integrated by the model-drivenarchitecture100A and the service-orientedarchitecture100B may enable monitoring for compliance assurances in theinformation technology infrastructure110. In particular, compliance assurance may present an important concern in the context of managing services in theinformation technology infrastructure110 because policy enforcement encompasses issues beyond location, access rights, or other contextual information within the infrastructure (e.g., due to increasing mobility in computing environments). As such, the model-drivenarchitecture100A and the service-orientedarchitecture100B may define metadata that bounds data to characteristics of data. To that end, the workload management system may employ a standard metadata format to provide interoperability between policies from multiple organizations to enable the policies to cooperate with one another and provide policy-based service control. For example, certain infrastructure workloads may execute under multiple constraints defined by users, theinfrastructure110, sponsoring organizations, or other entities, wherein compliance assurance may provide users with certification that the workloads were properly assigned and executed according to the constraints. In another example, sponsoring organizations and governing bodies may define control policies that constrain workloads, wherein compliance assurance in this context may include ensuring that only authorized workloads have been executed against approved resources114.
• As such, in one implementation, the model-drivenarchitecture100A and the service-orientedarchitecture100B may provide preventative compliance assurance through a compliance management service that supports remediation in addition to monitoring and reporting. For example, when workloads move from data centers internal to theinfrastructure110 into third party processing centers, cloud computing environments, or other environments having reusable computing resource pools where services can be relocated, the workload management system may generatecompliance reports145 that indicate whether any constraints defined for the workloads have been satisfied (e.g., that authorized entities perform the correct work in the correct manner, as defined within the workloads). Thus, compliance may generally be defined to include measuring and reporting on whether certain policies effectively ensure confidentiality and availability for information within workloads, wherein the resulting compliance reports145 may describe an entire process flow that encompasses policy definition, relationships between configurations and activities that do or do not comply with the defined policies, and identities of users, applications, services, systems, or other resources114 involved in the process flow.
• In one implementation, the workload management system may provide the compliance management service for workloads having specifications defined by users, and further for workloads having specifications defined by organizations. For example, users may generally define various specifications to identify operational constraints and desired outcomes for workloads that the users create, wherein the compliance management service may certify to the users whether or not the operational constraints and desired outcomes have been correctly implemented. With respect to organizational workloads, organizations may define various specifications identifying operational constraints and desired outcomes for ensuring that workloads comply with governmental regulations, corporate best practices, contracts, laws, and internal codes of conduct. Thus, the compliance management service may integrate the identity management services and the policy definition service described above to provide the workload management system with control over configurations, compliance event coverage, and remediation services in theinformation technology infrastructure110.
• In one implementation, the compliance management service may operate within aworkload engine180aprovided within themanagement infrastructure170 and/or aworkload service135bin communication with thesynchronization engine150. Theworkload engine180aand/or theworkload service135bmay therefore execute the compliance management service to measure and report on whether workloads comply with relevant policies, and further to remediate any non-compliant workloads. For example, the compliance management service may use the integrated identity management services to measure and report on users, applications, services, systems, or other resources114 that may be performing operational activity that occurs in theinformation technology infrastructure110. In particular, the compliance management service may interact with theaccess manager120, theidentity vault125, thesynchronization engine150, or any other suitable source that provides federated identity information to retrieve identities for the entities performing the operational activity, validate the identities, determine relationships between the identities, and otherwise map the identities to the operational activity. For example, in one implementation, thecorrelation system165 may provide analytic services to process audit trails for any suitable resource114 (e.g., correlating the audit trails and then mapping certain activities to identities for resources114 involved in the activities). Furthermore, in response to thecorrelation system165 processing the audit trails and determining that certain policies have been violated, thecorrelation system165 may invoke one or more automated remediation workloads to initiate appropriate action for addressing the policy violations.
• In one implementation, the compliance management service may further use the integrated policy definition service to monitor and report on the operational activity that occurs in theinformation technology infrastructure110 and any policy evaluation determinations that theevent audit service135bgenerates through the policy definition service. For example, in one implementation, theworkload engine180aand/or theworkload service135bmay retrieve information from aconfiguration management database185aorother databases155 that provide federated configuration information for managing the resources114 in theinformation technology infrastructure110. Theworkload engine180aand/or theworkload service135bmay therefore execute the compliance management service to perform scheduled and multi-step compliance processing, wherein the compliance processing may include correlating operational activities with identities and evaluating policies that may span various different policy domains in order to govern theinformation technology infrastructure110. To that end, the model-drivenarchitecture100A and the service-orientedarchitecture100B may provide various compliance management models may be used in the compliance management service.
• In one implementation, the compliance management models may include a wrapped compliance management model that manages resources114 lacking internal awareness over policy-based controls. The compliance management service may augment the resources114 managed in the wrapped compliance model with one or more policy decision points and/or policy enforcement points that reside externally to the managed resources114 (e.g., theevent audit service135b). For example, the policy decision points and/or the policy enforcement points may intercept any requests directed to the resources114 managed in the wrapped compliance model, generate policy decisions that indicate whether the resources114 can properly perform the requests, and then enforce the policy decisions (e.g., forwarding the requests to the resources114 in response to determining that the resources114 can properly perform the requests, denying the requests in response to determining that the resources114 can properly perform the requests, etc.). Thus, because the resources114 managed in the wrapped compliance model generally perform any requests that the resources114 receive without considering policy-based controls or compliance issues, theevent audit service135bmay further execute the compliance management service to wrap, coordinate, and synthesize an audit trail that includes data obtained from the managed resources114 and the wrapping policy definition service.
• In one implementation, the compliance management models may include a delegated compliance management model to manage resources114 that implement a policy enforcement point and reference an external policy decision point, wherein the resources114 managed in the delegated compliance management model may have limited internal awareness over policy-based controls. As such, in one implementation, the compliance management service may interleave policy decisions or other control operations generated by the external policy decision point with the internally implemented policy enforcement point to provide compliance assurance for the resources114 managed in the delegated compliance management model. The delegated compliance management model may therefore represent a hybrid compliance model, which may apply to any suitable service that simultaneously anticipates compliance instrumentation but lacks internal policy control abstractions (e.g., the internally implemented policy enforcement point may anticipate the compliance instrumentation, while the externally referenced policy decision point has the relevant policy control abstractions). Thus, in the delegated compliance management model, the compliance management service may have fewer objects to coordinate than in the wrapped compliance management model, but theevent audit service135bmay nonetheless execute the compliance management service to coordinate and synthesize an audit trail that includes data obtained from the managed resources114 and the delegated external policy decision point.
• In one implementation, the compliance management models may include an embedded compliance management model that manages resources114 that internally implement policy enforcement points and policy decision points, wherein the resources114 managed in the embedded compliance management model may have full internal awareness over policy-based controls. As such, in one implementation, the resources114 managed in the embedded compliance management model may employ the internally implemented policy enforcement points and policy decision points to instrument any service and control operations for requests directed to the resources114. In one implementation, to provide flexible compliance assurance, resources114 managed in the embedded compliance management model may expose configuration or customization options via an externalized policy administration point. Thus, the embedded compliance management model may provide an integrated and effective audit trail for compliance assurance, which may often leave the compliance management service free to perform other compliance assurance processes.
• Accordingly, in one implementation, the compliance management service may obtain information for any resource114 managed in theinformation technology infrastructure110 from theconfiguration management database185aorother databases155 that include a federated namespace for the managed resources114, configurations for the managed resources114, and relationships among the managed resources114. In addition, the compliance management service may reference theconfiguration management database185aor other thedatabases155 to arbitrate configuration management in theinfrastructure110 and record previous configurations histories for the resources114 in theconfiguration management database185aorother databases155. As such, the compliance management service may generally maintain information relating to identities, configurations, and relationships for the managed resources114, which may provide a comparison context for analyzing subsequent requests to change theinfrastructure110 and identifying information technology services that the requested changes may impact.
• Computing and Storage Environments
• In one implementation, as noted above, the technologies integrated by the model-drivenarchitecture100A and the service-orientedarchitecture100B may include managing computing and storage environments that support services in theinfrastructure110. In particular, in one implementation, the computing and storage environments used to support services in theinfrastructure110 may employ Linux operating environments, which may generally include an operating system distribution with a Linux kernel and various open source packages (e.g., gcc, glibc, etc.) that collectively provide the Linux operating environments. In one implementation, the Linux operating environments may generally provide a partitioned distribution model for managing the computing and storage environments employed in the workload management system. Further, in one implementation, a particular Linux distribution may be bundled for operating environments pre-installed in the workload management system (e.g., openSUSE, SUSE Linux Enterprise, etc.), which may enable vendors ofphysical hardware resources114ato support every operating system that the vendors' customers employ without overhead that may introduced with multiple pre-installed operating environment choices.
• In one implementation, the partitioned distribution model may partition the Linux operating environments into a physical hardware distribution (often referred to as a “pDistro”), which may includephysical resources114athat run over hardware to provide a physical hosting environment forvirtual machines114b. For example, in one implementation, the physical hardware distribution may include the Linux kernel and various hypervisor technologies that can run thevirtual machines114bover the underlying physical hosting environment, wherein the physical hardware distribution may be certified for existing and future-developed hardware environments to enable the workload management system to support future advances in the Linux kernel and/or hypervisor technologies. Alternatively (or additionally), the workload management system may release the physical hardware distribution in a full Linux distribution version to provide users with the ability to take advantage of future advances in technologies at a faster release cycle.
• In one implementation, the partitioned distribution model may further partition the Linux operating environments into a virtual software distribution (often referred to as a “vDistro”), which may includevirtual machines114bdeployed for specific applications or services that run, enable, and otherwise support workloads. More particularly, any particular virtual software distribution may generally include one or more Linux package or pattern deployments, whereby thevirtual machines114bmay include virtual machines images with “just enough operating system” (JeOS) to support the package or pattern deployments needed to run the applications or services for the workloads. In one implementation, the virtual software distribution may include a particular Linux product (e.g., SUSE Linux Enterprise Server) bundled with hardware agnostic virtual drivers, which may provideconfiguration resources114cfor tuningvirtualized resources114bfor optimized performance.
• In one implementation, the particular virtual software distribution may be certified for governmental security requirements and for certain application vendors, which may enable the workload management system to update anyphysical resources114ain the physical hardware distribution underlying the virtual software distribution without compromising support contracts with such vendors. In particular, in response to future changes in technology that may improve support for Linux operating environments, resulting improvements may occur in techniques for building and deploying Linux operating environments. Thus, where many application vendors currently tend to only provide support for certain Linux applications that run in certain Linux versions, the workload management system may enable support for any particular Linux application or version, which may drive Linux integration and adoption across theinformation technology infrastructure110. In one implementation, for example, the workload management system may employ Linux applications and distributions created using a build system that enables any suitable application to be built and tested on different versions of Linux distributions (e.g., an openSUSE Build Service, SUSE Studio, etc.). For example, in response to receiving a request that includes unique specifications for a particular Linux application, the workload management system may notify distribution developers to include such specifications in the application, with the specifications then being made available to other application developers.
• Thus, in one implementation, the Linux build system employed in the workload management system may enable distribution engineers and developers to detect whether changes to subsequent application releases conflict with or otherwise break existing applications. In particular, changes in systems, compiler versions, dependent libraries, or other resources114 may cause errors in the subsequent application releases, wherein commonly employing the Linux build system throughout the workload management system may provide standardized application support. For example, in one implementation, the workload management system may employ certified implementations of the Linux Standard Base (LSB), which may enable independent software vendors (ISVs) to verify compliance, and may further provide various support services that can provide policy-based automated remediation for the Linux operating environments through the LSB Open Cluster Framework (OCF).
• In one implementation, the Linux operating environments in the workload management system may provide engines that support orchestrated virtualization, collaboration, and architectural agility, as will be described in greater detail below. Further, to manage identities, enforce policies, and assure compliance, the Linux operating environments may include a “syslog” infrastructure that coordinate and manages various internal auditing requirements, while the workload management system may further provide an audit agent to augment the internal auditing capabilities that the “syslog” infrastructure provides (e.g., the audit agent may operate within theevent audit service135bto uniformly manage the Linux kernel, the identity services, the policy services, and the compliance services across the workload management system). For example, in one implementation, partitioning the monolithic Linux distribution within a multiple layer model that includes physical hardware distributions and virtual software distributions may enable each layer of the operating system to be developed, delivered, and supported at different schedules. In one implementation, ascheduling system180cmay coordinate such development, delivery, and support in a manner that permits dynamic changes to thephysical resources114ain theinfrastructure110, which provide stability and predictability for theinfrastructure110.
• In one implementation, partitioning the Linux operating environments into physical hardware distributions and virtual software distributions may further enable the workload management system to run workloads in computing and storage environments that may not necessarily be co-located or directly connected to physical storage systems that contain persistent data. For example, the workload management system may support various interoperable and standardized protocols that provide communication channels between users, applications, services, and a scalable replicated storage system, such as the clusteredfile system195 illustrated inFIG. 1A, wherein such protocols may provide authorized access between various components at any suitable layer within the storage system.
• In one implementation, the clusteredfile system195 may generally include various block storage devices, each of which may host various different file systems. In one implementation, the workload management system may provide various storage replication and version management services for the clusteredfile system195, wherein the various block storage devices in the clusteredfile system195 may be organized in a hierarchical stack, which may enable the workload management system to separate the clusteredfile system195 from operating systems and collaborative workloads. As such, the storage replication and version management services may enable applications and storage services to run in cloud computing environments located remotely fromclient resources115.
• In one implementation, various access protocols may provide communication channels that enable secure physical and logical distributions between subsystem layers in the clustered file system195 (e.g., a Coherent Remote File System protocol, a Dynamic Storage Technology protocol, which may provide a file system-to-file system protocol that can place a particular file in one of various different file systems based on various policies, or other suitable protocols). Furthermore, traditional protocols for access files from a client resource115 (e.g., HTTP, NCP, AFP, NFS, etc.) may be written to file system specific interfaces defined in thedefinitive software library190. As such, thedefinitive software library190 may provide mappings between authorization and semantic models associated with the access protocols and similar elements of the clusteredfile system195, wherein the mappings may be dynamically modified to handle any new protocols that support cross-device replication, device snapshots, block-level duplication, data transfer, and/or services for managing identities, policies, and compliance.
• As such, the storage replication and version management services may enable users to create workloads that define identity and policy-based storage requirements, wherein team members identities may be used to dynamically modify the team members and any access rights defined for the team members (e.g., new team members may be added to a “write access” group, users that leave the team may be moved to a “read access” group or removed from the group, policies that enforce higher compliance levels for Sarbanes-Oxley may be added in response to an executive user joining the team, etc.). For example, a user that heads a distributed cross-department team developing a new product may define various members for the team and request permission for self-defined access levels for the team members (e.g., to enable the team members to individually specify a storage amount, redundancy level, and bandwidth to allocate). The workload management system may then provide fine grained access control for a dynamic local storage cache, which may move data stored in the in the clusteredfile system195 to a local storage for aclient resource115 that accesses the data (i.e., causing the data to appear local despite being persistently managed in the clusteredfile system195 remotely from the client resource115). As such, individual users may then use information technology tools define for local area networks to access and update the data, wherein the replication and version management services may further enable the individual users to capture consistent snapshots that include a state of the data across various e-mail systems,databases155,file systems195, cloud storage environments, or other storage devices.
• In one implementation, the storage replication and version management services may further enable active data migration and auditing for migrated data. For example, policies or compliance issues may require data to be maintained for a longer lifecycle than hardware and storage systems, wherein the workload management system may actively migrate certain data to long-term hardware or an immutable vault in the clusteredfile system195 to address such policies or compliance issues. Furthermore, identity-based management for the data stored in the clusteredfile system195 may enable the workload management system to control, track, and otherwise audit ownership and access to the data, and the workload management system may further classify and tag the data stored in the clusteredfile system195 to manage the data stored therein (e.g., the data may be classified and tagged to segregate short-term data from long-term data, maintain frequently used data on faster storage systems, provide a content-addressed mechanism for efficiently searching potentially large amounts of data, etc.). Thus, the workload management system may use the storage replication and version management services to generatedetailed reports145 for the data managed in the clustered file system.
• In one implementation, the storage replication and version management services may further provide replication services at a file level, which may enable the workload management system to control a location, an identity, and a replication technique (e.g., block-level versus byte-level) for each file in the clusteredfile system195. In addition, the storage replication and version management services may further enable the workload management system to manage storage costs and energy consumption (e.g., by controlling a number of copies created for any particular file, a storage medium used to store such copies, a storage location used to store such copies, etc.). Thus, integrating federated identities managed in theidentity vault125 with federated policy definition services may enable the workload management system to manage the clusteredfile system195 without synchronizing or otherwise copying every identity with separate identity stores associated with different storage subsystems.
• Orchestrated Virtualization
• In one implementation, as noted above, the technologies integrated by the model-drivenarchitecture100A and the service-orientedarchitecture100B may provide orchestrated virtualization for managing services provided in theinformation technology infrastructure110. In particular, virtualization generally ensures that a machine runs at optimal utilization by allowing services to run anywhere, regardless of requirements or limitations that underlying platforms or operating systems may have. Thus, the workload management system may define standardized partitions that control whether certain portions of the operating system execute over hardware provided in a hosting environment, or insidevirtual machines114bthat decouple applications and services from the hardware on which thevirtual machines114bhave been deployed. The workload management system may further employ a standardized image for thevirtual machines114b, provide metadata wrappers for encapsulating thevirtual machines114b, and provide various tools for managing thevirtual machines114b(e.g., “zero residue” management agents that can patch and update running instances ofvirtual machines114bstored in the clusteredfile system195,databases155, or other repositories).
• In one implementation, the virtualized services provided in the workload management system may simplify processes for developing and deploying applications, which may enable optimal utilization ofphysical resources114ain the infrastructure. Furthermore, virtualization may be used to certify the Linux operating environments employed in theinfrastructure110 for any suitable platform that include variousphysical resources114a. In particular, as described in further detail above, the workload management system may partition the Linux operating environments into a multiple-layer distribution that includes a physical distribution and a virtual distribution, wherein the physical distribution may represent a lower-level interface tophysical resources114athat hostvirtual machines114b, while the virtual distribution may represent any applications or services hosted on thevirtual machines114b.
• For example, in one implementation, the physical distribution may include a minimally functional kernel that bundles various base drivers and/or independent hardware vendor drivers matched to thephysical resources114athat host thevirtual machines114b. In one implementation, the physical distribution may further include a pluggable hypervisor that enables multiple operating systems to run concurrently over the hostingphysical resources114a, a minimal number of software packages that provide core functionality for the physical distribution, and one or more of the zero residue management agents that can manage anyvirtualized resources114bthat may be hosted on thephysical resources114a. As such, in response to any particular request to install a physical distribution, package selections available to the workload management system may include packages for the kernel, the hypervisor, the appropriate drivers, and the management agents that may be needed to support brands or classes of the underlyingphysical resources114a.
• Furthermore, in one implementation, the virtual distribution may include a tuned appliance, which may generally encapsulate an operating system and other data that supports a particular application. In addition, the virtual distribution may further include a workload profile encapsulating various profiles for certifying the appliance with attestation tokens (e.g., profiles for resources114, applications, service level agreements, inventories, cost, compliance, etc.). Thus, the virtual distribution may be neutral with respect to thephysical resources114aincluded in the physical distribution, wherein the virtual distribution may be managed independently from any physical drivers and applications hosted by a kernel for the virtual distribution (e.g., upgrades for the kernels and physical device drivers used in the physical distributions may be managed independently from security patches or other management for the kernels and applications used in the virtual distributions). Thus, partitioning the physical distributions from the virtual distributions may remove requirements for particularphysical resources114aand preserve records for data that may require a specific application running on a specific operating system.
• In one implementation, from a business perspective, the workload management system may secure thevirtualized resources114bin a similar manner as applications deployed on thephysical resources114a. For example, the workload management system may employ any access controls, packet filtering, or other techniques used to secure thephysical resources114ato enforce containment and otherwise secure thevirtualized resources114b, wherein thevirtualized resources114bmay preserve benefits provided by running a single application on a singlephysical server114awhile further enabling consolidation and fluid allocation of thephysical resources114a. Furthermore, the workload management system may include various information technology tools that can be used to determine whether newphysical resources114amay be needed to support new services, deploy newvirtual machines114b, and establish new virtual teams that include various collaborating entities.
• In one implementation, the information technology tools may include a trending tool that indicate maximum and minimum utilizations for thephysical resources114a, which may indicate when newphysical resources114amay be needed. For example, changes to virtual teams, different types of content, changes in visibility, or other trends for thevirtualized resources114bmay cause changes in theinfrastructure110, such as compliance, storage, and fault tolerance obligations, wherein the workload management system may detect such changes and automatically react to intelligently manage that the resources114 in theinfrastructure110. In one implementation, the information technology tools may further include a compliance tool providing a compliance envelope for applications running or services provided within any suitablevirtual machine114b. More particularly, the compliance envelope may save a current state of thevirtual machine114bat any suitable time and then push an updated version of the current state to theinfrastructure110, whereby the workload management system may determine whether the current state of thevirtual machine114bcomplies with any policies that may have been defined for thevirtual machine114b. For example, the workload management system may support deployingvirtual machines114bin demilitarized zones, cloud computing environments, or other data centers that may be remote from theinfrastructure110, wherein the compliance envelope may provide a security wrapping to safely move suchvirtual machines114band ensure that only entities with approved identities can access thevirtual machines114b.
• Thus, from an architectural perspective, thevirtualized resources114bmay enable the workload management system to manage development and deployment for services and applications provisioned in theinfrastructure110. For example, rather than dynamically provisioningphysical resources114ato deal with transient peaks in load and availability on a per-service basis, which may result in under-utilizedphysical resources114a, the workload management system may host multiplevirtual machines114bon onephysical machine114ato optimize utilization levels for thephysical resources114a, which may dynamically provisionedphysical resources114athat enable mobility for services hosted in thevirtual machines114b. Thus, in one implementation, mobile services may enable the workload management system to implement live migration for services that planned maintenance events may impact without adversely affecting an availability of such services, while the workload management system may implement clustering or other availability strategies to address unplanned events, such as hardware or software failures.
• In one implementation, the workload management system may further provide various containers to manage thevirtual machines114b, wherein the containers may include a security container, an application container, a service level agreement container, or other suitable containers. The security container may generally provide hardware-enforced isolation and protection boundaries for variousvirtual machines114bhosted on aphysical resource114aand the hypervisor hosting thevirtual machines114b. In one implementation, the hardware-enforced isolation and protection boundaries may be coupled with a closed management domain to provide a secure model for deploying thevirtual machines114b(e.g., one or more security labels can be assigned to any particularvirtual machine114bto contain viruses or other vulnerabilities within the particularvirtual machine114b). Furthermore, in the context of tuned appliances, wherein onevirtual machine114bhosts one service that supports one particular application, the application container may package the service within a particularvirtual machine image114b. As such, thevirtual machine image114bmay include a kernel and a runtime environment optimally configured and tuned for the hosted service. Similarly, the service level agreement container may dynamically monitor, meter, and allocate resources114 to provide quality of service guarantees on a per-virtual machine114bbasis in a manner transparent to thevirtual machine kernel114b.
• In one implementation, the various containers used to manage thevirtual machines114bmay further provide predictable and custom runtime environments forvirtual machines114b. In particular, the workload management system may embed prioritization schemes within portions of an operating system stack associated with avirtual machine114bthat may adversely impact throughput in the operating system. For example, unbounded priority inversion may arise in response to a low-priority task holding a kernel lock and thereby blocking a high-priority task, resulting in an unbounded latency for the high-priority task. As such, in one implementation, the prioritization schemes may embed a deadline processor scheduler in the hypervisor of thevirtual machine114band build admission control mechanisms into the operating system stack, which may enable the workload management system to distribute loads across differentvirtual machine114band support predictable computing. In addition, the workload management system may decompose kernels and operating systems forvirtual machines114bto provide custom runtime environments. For example, in the context of a typicalvirtual machine114b, an “unprivileged guest”virtual machine114bmay hand off processing to a “helper”virtual machine114bat a device driver level. Thus, to support server-class applications that may depend on having a portable runtime environment, the workload management system may use the decomposed kernels and operating systems to dynamically implement an operating system for a particularvirtual machine114bat runtime (e.g., the dynamically implemented operating system may represent a portable runtime that can provide a kernel for avirtual machine114bthat hosts a service running a server-class application, which may be customized as a runtime environment specific to that service and application).
• In one implementation, the workload management system may further employ different virtualization technologies in different operating environments. For example, in one implementation, the workload management system may implementType 1 hypervisors forvirtualized server resources114bandType 2 hypervisors for virtualized workstation, desktop, orother client resources115. In particular,Type 1 hypervisors generally control and virtualize underlyingphysical resources114ato enable hosting guest operating systems over thephysical resources114a(e.g., providing coarse-level scheduling to partition thephysical resources114ain a manner that can meet quality of service requirements for each of the guest operating systems hosted on thephysical resources114a). Thus, the workload management system may implementType 1 hypervisors forvirtualized server resources114bto leverage performance and fault isolation features that such hypervisors provide. In contrast,Type 2 hypervisors generally include use a host operating system as the hypervisor, which use Linux schedulers to allocate resources114 to guest operating systems hosted on the hypervisor. InType 2 hypervisor architectures, such as the VMware GSX Server, Microsoft Virtual PC, and Linux KVM, hostedvirtual machines114bappear as a process similar to any other hosted process. Thus, because workstations, desktops, andother client resources115 may include hardware that may or may not support virtualization, the workload management system may provide centralized desktop management andprovisioning using Type 2 hypervisors. For example, the workload management system may manage and maintain desktop environments asvirtual appliances114bhosted in theinfrastructure110 and then remotely deliver the desktop environments to remote client resources115 (e.g., in response to authenticating an end user at aparticular client resource115, thevirtual appliance114bcarrying the appropriate desktop environment may be delivered for hosting to theclient resource115, and theclient resource115 may transfer persistent states for the desktop environment to theinfrastructure110 to ensure that theclient resource115 remains stateless).
• In one implementation, orchestrated virtualization may generally refer to implementing automated policy-based controls for virtualized services. For example, an orchestrated data center may ensure compliance with quality of service agreements for particular groups of users, applications, or activities that occur in theinformation technology infrastructure110. The workload management system may therefore provide a policy-based orchestration service to managevirtualized resources114b, wherein the orchestration service may gather correct workload metrics without compromising performance in cloud computing environments or other emerging service delivery models. For example, workloads that users define may be executed using coordinated sets ofvirtual machines114bembedding different application-specific operating systems, wherein the workload management system may provision and de-provision thevirtual machines114bto meet requirements defined in the workload (e.g., using standard image formats and metadata wrappers to encapsulate the workloads, embed standard hypervisors in thevirtual machines114b, physical-to-virtual (P2V) or virtual-to-virtual (V2V) conversion tools to translate between different image formats, etc.). Furthermore, in cloud computing environments that can include unpredictable sets of dynamic resources external to theinfrastructure110, the workload management system coordinate such resources using a closed-loop management infrastructure170 that manages declarative policies, fine-grained access controls, and orchestrated management and monitoring tools.
• In one implementation, the workload management system may further manage the orchestrated data center to manage any suitable resources114 involved in the virtualized workloads, which may span multiple operating systems, applications, and services deployed on variousphysical resources114aand/orvirtualized resources114b(e.g., aphysical server114aand/or avirtualized server114b). Thus, the workload management system may balance resources114 in theinformation technology infrastructure110, which may align management of resources114 in the orchestrated data center with business needs or other constraints defined in the virtualized workloads (e.g., deploying or tuning the resources114 to reduce costs, eliminate risks, etc.). For example, as described in further detail above, theconfiguration management database185amay generally describe every resource114 in theinfrastructure110, relationships among the resources114, and changes, incidents, problems, known errors, and/or known solutions for managing the resources114 in theinfrastructure110.
• As such, the policy-based orchestration service may provide federated information indexing every asset or other resource114 in theinfrastructure110, wherein the workload management system may reference the federated information to automatically implement policy-controlled best practices (e.g., as defined in the Information Technology Infrastructure Library) to manage changes to theinfrastructure110 and the orchestrated data center. For example, theconfiguration management database185amay model dependencies, capacities, bandwidth constraints, interconnections, and other information for the resources114 in theinfrastructure110, which may enable the workload management system to perform impact analysis, “what if” analysis, and other management functions in a policy-controlled manner. Furthermore, as noted above, theconfiguration management database185amay include a federated model of theinfrastructure110, wherein the information stored therein may originate from various different sources. Thus, through the federated model, theconfiguration management database185amay appear as one “virtual” database incorporating information from various sources without introducing overhead otherwise associated with creating one centralized database that potentially includes large amounts of duplicative data.
• In one implementation, the orchestration service may automate workloads across variousphysical resources114aand/orvirtualized resources114busing policies that match the workloads to suitable resources114. For example, deploying an orchestratedvirtual machine114bfor a requested workload may include identifying a suitable hostvirtual machine114bthat satisfies any constraints defined for the workload (e.g., matching tasks to perform in the workload to resources114 that can perform such tasks). In response to identifying allocating and deploying the suitable hostvirtual machine114b, deploying the orchestratedvirtual machine114bfor the workload may include the workload management system positioning an operating system image on the hostvirtual machine114b, defining and running the orchestratedvirtual machine114bon the chosen hostvirtual machine114b, and then monitoring, restarting, or moving thevirtual machine114bas needed to continually satisfy the workload constraints.
• In one implementation, the orchestration service may include various orchestration sub-services that collectively enable management over orchestrated workloads. For example, the orchestration service may be driven by a blueprint sub-service that defines related resources114 provisioned for an orchestrated workload, which the workload management system may manage as a whole service including various different types of resources114. Furthermore, a change management sub-service may enable audited negotiation for service change requests, including the manner and timing for committing the change requests (e.g., within an approval workload130). The sub-services may further include an availability management sub-service that can control and restart services in a policy-controlled manner, a performance management sub-service that enforces runtime service level agreements and policies, a patch management sub-service that automatically patches and updates resources114 in response to static or dynamic constraints, and a capacity management sub-service that can increase or reduce capacities for resources114 in response to current workloads.
• To provide exemplary contexts for some of the orchestration sub-services noted above, the availability management sub-service may automatically migrate avirtual machine114bto anotherphysical host114ain response to a service restart failing on a currentphysical host114amore than a policy-defined threshold number of times. With respect to the performance management sub-service, in response to determining that a service running at eighty percent utilization can be cloned, the service may be cloned to create a new instance of the service and the new instance of the service may be started automatically. Furthermore, to manage a patch for running instances of a service, the patch management sub-service may test the patch against a test instance of the service and subsequently apply the patch to the running service instance in response to the test passing. Regarding the capacity management sub-service, an exemplary service instance may include a service level agreement requiring a certain amount of available storage for the service instance, wherein the capacity management sub-service may allocate additional storage capacity to the service instance in response to determining that the storage capacity currently available to the service instance has fallen below a policy-defined threshold (e.g., twenty percent).
• In one implementation, the orchestration service may incorporate workflow concepts to manageapproval workloads130 or other management workloads, wherein aworkload database185bmay store information that the workload management system can use to manage the workloads. For example, in one implementation, anapproval workload130 may include a request to provision a particular service to a particular user in accordance with particular constraints, wherein theapproval workload130 may include a sequence of activities that includes a suitable management entity reviewing the constraints defined for the service, determining whether any applicable policies permit or prohibit provisioning the service for the user, and deploying the service in response to determining that the service can be provisioned, among other things. Thus, theworkload engine180amay execute the orchestration service to map the sequence of activities defined for any particular workload to passive management operations and active dynamic orchestration operations. For example, theworkload database185bmay stores various declarative service blueprints that provide master plans and patterns for automatically generating service instances, physical distribution images and virtual distribution images that can be shared across the workload management system to automatically generate the service instances, and declarative response files that define packages and configuration settings to automatically apply to the service instances.
• Collaboration
• In one implementation, as noted above, the technologies integrated by the model-drivenarchitecture100A and the service-orientedarchitecture100B may enable collaboration between entities that interact with the services provided in theinformation technology infrastructure110. In particular, collaboration may generally involve dynamic teams that cross traditional security and policy boundaries. For example, where loosely affiliated organizations share data and applications, the workload management system may enable continued collaboration even when some of the participants sharing the data and applications may be temporarily offline (e.g., the workload management system may authorize certain users to allocate portions oflocal client resources115 to support cross-organizational endeavors). Thus, the workload management system may provide astandard interface160 designed to enable dynamic collaboration for end users that simplify interaction with complex systems, which may provide organizations with opportunities for more productive and agile workloads.
• In one implementation, the workload management system may provide a collaboration service that enables workloads to span multiple users; applications, services, systems, or other resources114. For example, multiple users may collaborate and share data and other resources114 throughout the workload management system, both individually and within virtual teams (e.g., via a service bus that transports data relating to services or other resources114 over the event bus140). As such, the workload management system may support virtual team creation that can span organizational and geographic boundaries, wherein affiliations, content, status, and effectiveness may be represented for identities that have membership in any particular virtual team (e.g., to enable online and offline interaction between team members). In one implementation, the workload management system may provide enriched collaboration content (e.g., images, video, text, data feeds), and may efficiently transport the collaboration content between team members (e.g., via the service bus). Furthermore, the workload management system may integrate desktops, laptops, personal digital assistants, smart phones, or othersuitable client resources115 into virtual team collaboration experiences in order to meet emerging demands for mobile, interoperable, and integrated access. Thus, the collaboration enabled in the workload management system may operate in an adaptive collaborative environment, which may unify technologies for online integrated media sharing with offline authoring and editing.
• In one implementation, the collaboration service may generally include a web-based platform that support inter-organization and intra-organization management for virtual teams, interoperability between various different collaboration products, social networking to deliver information that enables the virtual teams to interact efficiently either online or offline, and federated searches against any suitable information source, among other things. For example, in one implementation, the collaboration service may include various collaboration sub-services that collectively enable the adaptive collaborative environment, including a client sub-service, an aggregation sub-service, an information sub-service, a real-time collaboration sub-service, and a metadata sub-service.
• In one implementation, the client sub-service may provide communication interfaces with real-time online systems, offline systems, and user interfaces. In particular, functionality for the client sub-service may be provided in a web-based interface that supports interaction with the real-time online systems in addition to software that can execute locally atclient resources115 to provide offline access to shared data and real-time meetings that may involve shared applications and shared desktops. For example, in one implementation, the client sub-service may communicate with the aggregation sub-service to coordinate the communication and collaboration across various information sources, wherein the aggregation sub-service may route messages to the appropriate information sources in appropriate formats. Furthermore, to ensure that collaborative contexts reference information that may be distributed across theinfrastructure110 rather than hosted within one particular application, the information sub-service may integrate the different information sources within the collaborative environment. As such, the virtual teams may connect and collaborate using information that originates anywhere across theinfrastructure110, and the information sub-service may enable members of the virtual teams to discuss information or other content from the various sources in an interactive manner. The real-time collaboration sub-service may interact with the information sub-service to provide real-time meetings that include audio content, video content, instant message content, and other forms of communication content in real-time collaborative contexts within theinfrastructure110 and with third-parties.
• In one implementation, the metadata sub-service may provide a “helper” service to the aggregation and information sub-services, collecting ancillary metadata generated during interaction between virtual team members and create collaborative threads to maintain contexts that generated the data. Furthermore, the metadata sub-service may evaluate the ancillary metadata to discover new and relevant links between information sources and integrate data that can potentially originate from various disparate information sources. For example, the metadata sub-service may provide a uniform format for classifying data collected during collaborative contexts, which may provide a single source for virtual team members to search and display the data across any suitable collaboration source. Similarly, the metadata sub-service may index and unify data collected from disparate network sources, including various search engines and content aggregation services, to help the virtual team members to locate information that may be interesting or otherwise relevant to the collaborative contexts. As such, the various sub-services integrated within the collaboration service may provide a collaborative environment that supports dynamic interaction across organizational boundaries and different information sources in a manner that can account for any particular virtual team member's personal preferences.
• Architectural Agility
• In one implementation, as noted above, the technologies integrated by the model-drivenarchitecture100A and the service-orientedarchitecture100B may collectively provide various services that the workload management system can use to manage workloads and enable intelligent choices in aninformation technology infrastructure110. Furthermore, various horizontal integration components may be distributed in the workload management system to integrate the various technologies employed in the model-drivenarchitecture100A and the service-orientedarchitecture100B and provide an agile and interoperableinformation technology infrastructure110.
• In particular, the horizontal integration components distributed across the workload management system may provide agility and interoperability to theinformation technology infrastructure110 through support for various emerging service delivery models, including Web 2.0, Software as a Service (SaaS), mashups, hardware, software, and virtual appliances, cloud computing, grid computing, and thin clients, among others. For example, in one implementation, every service, application, or other resource114 in the workload management system may be provided with anapplication programming interface160 that can provide connectivity between different operating systems, programming languages, graphical user interface toolkits, or other suitable services, applications, or resources114.
• In one implementation, theapplication programming interface160 may include a Representational State Transfer (REST)application program interface160, which may use standard methods defined in the Hypertext Transfer Protocol (HTTP), wherein using standardized types to format data may ensure interoperability. In one implementation, theREST interface160 may define a Uniform Resource Identifier (URI) that represents a unique identity for any suitable entity, and may further define relationships between the represented identities with hyperlinks that can be selected to access information for related identities, attribute claims, roles, policies, workloads, collaboration spaces, and workflow processes. Thus, through the use of URIs, hyperlinks, and other standard HTTP methods, theREST interface160 may provide an interface to a data ecosystem that can be navigated in a web-based environment that can be used anywhere in the workload management system. In one implementation, theREST interface160 may declare a namespace having version controls and standard methods to read and write to the data ecosystem, and may include a URI registry containing the URIs that represent the identities in the data ecosystem. Thus, any suitable resource114 may programmatically discover other identities that communicate using the REST interface160 (e.g., theREST interface160 may be implemented in acommunication gateway112atophysical resources114a, acommunication gateway112btovirtualized resources114a, acommunication gateway112ctoconfiguration resources114c, etc.).
• Furthermore, in one implementation, the workload management system may extend an application program interface stack for the suppliedREST interface160, which may enable new services, applications, and other resources114 to be integrated into the workload management system in a manner that automatically inherits the identity-based and policy-controlled services implemented in the workload management system. In particular, the supplied application program interface stack may generally include a unified adapter and a proxy to existing and future technologies using protocols to enable services that communicate through theREST interface160 regardless of whether the services reside in theinfrastructure110, a cloud computing environment, a third party data center, or elsewhere (e.g., web service protocols, lightweight directory protocols, messaging queue protocols, remote procedure call protocols, etc.). To provide support to developers and users that extend the application program interface stack supplied for theREST interface160, a Recipe-based Development Kit (RDK) may provide full source code examples for various operating systems, programming languages, and graphical user interface toolkits.
• Additionally, in one implementation, theworkload engine180amay manage creation of application program interface keys for theREST interface160 stack, whereby auditing and policy-based approvals may be supported for provisioning the application program interface keys. For example, the workload management system may deploy widgets toclient desktops115, wherein the widget may track identities and contexts that include attempts to access theREST interface160 stack. Thus, in response to provisioning or auditing application program interface keys, platform authentication and policy checks may be triggered against the accessing identity and the context that the keys supply. In a similar manner, the application program interface keys may enable the workload management system to meter costs for theinformation technology infrastructure110.
• Thus, the standardized stack supplied for the RESTapplication program interface160 may provide support for industry standard authentication and authorization methods, which may enable identity-managed and policy-controlled auditing for events and access controls. Furthermore, the extensibility of the RESTapplication program interface160 may enable integration with any suitable existing or future-developed system. For example, in one implementation, theREST interface160 may be configured with standards such as the Atom Syndication Format and Atom Publishing Protocol to integrate feed synchronization, JavaScript Object Notation and Extensible. Markup Language (XML) to integrate enterprise portals, mashups, and social networking platforms. Thus, in the context of feed synchronization to provide automatically notifications in response to any changes to a particular resource114, a user may simply enter a URI for the resource114 in an existing web browser feed aggregator (e.g., Firefox bookmarks). Thus, by providing extensible support for any suitable system, application, service, or other resources114, the features of the RESTapplication program interface160 may provide agility and interoperability to theinfrastructure110.
• Having described the model-driven and service-orientedarchitecture100A-B that collectively provide the agile, responsive, reliable, and interoperable environment that enables the features of the workload management system, the description to be provided below will address certain particular features of the workload management system. In addition, further detail relating to the architectural foundation and other features of the workload management system may be provided in “Novell Architectural Foundation: A Technical Vision for Computing and Collaborating with Agility,” “Automation for the New Data Center,” and “A Blueprint for Better Management from the Desktop to the Data Center,” the contents of which are hereby incorporated by reference in their entirety.
• According to one aspect of the invention,FIG. 2 illustrates anexemplary method200 for intelligent workload management. In particular, the intelligentworkload management method200 may be used to manage approval workloads created in response to service requests. In particular, anoperation210 may include creating an approval workload in response to a receiving a request for a service from any suitable user, application, system, or other entity having an identity in the workload management system. For example, in one implementation, the request may generally specify any components needed to configure the service for a particular task (e.g., a raw machine hosting an operating system and storage may be requested to deploy a particular application in the raw machine, an existing service may be requested to specify any suitable combination of components that can deploy the application, etc.). In addition, the request may further specify desired a performance level (or service level) for the service (e.g., availability, release capacity, financial constraints, continuity, etc.), any comments for provisioning the service in a certain manner (e.g., provision the service as soon as possible, according to a particular schedule or policy, to particular members in a virtual team, with a particular configuration, etc.).
• Thus, in one implementation, the request may generally include any suitable criteria that the requesting entity specifies to define constraints for deploying the requested service, wherein the workload management system may create the approval workload inoperation210 to determine whether or not the requested service can be provisioned in a manner that meets the constraints defined in the request. For example, in one implementation, the approval workload may generally define a task that includes various human and/or automated approvers (or service delivery managers) collaboratively managing the service request to determine whether the service can be provisioned as requested. Thus, to manage the approval workload, anoperation220 may include the workload management system querying a configuration management database to obtain an infrastructure model describing any computing resources and storage resources available to run the requested service.
• In one implementation, the model of the computing resources obtained inoperation220 may include various rack-mounted servers and/or blade servers, which may include multi-core processors (e.g., sixty-four bit processors), a multiple gigabyte local memory, a serial-attached Redundant Array of Independent Disks (RAID), Ethernet and Storage Area Network (SAN) interfaces, and embedded hardware that can support virtualization. In addition, the computing resources may further run an appropriate operating system for the underlying physical architecture, including a virtual machine monitor (e.g., a hypervisor), various device drivers, a management kernel, and any suitable management agents. In one implementation, the management kernel and the management agents may collectively provide support for remotely deploying virtual machines to be executed by the hypervisors present on the computing resources, which may enable the workload management system to group and organize the computing resources. For example, a globally unique identifier (e.g., a URI) may be created for each of the computing resources, whereby the computing resources may be grouped or otherwise organized according to any suitable combination of a type (e.g., thin blade, symmetric multiprocessing, etc.), intended purpose (e.g., test, production, etc.), owner, physical location, or other classifying types. Furthermore, the workload management system may configure one or more of the computing resources to function in isolation or cooperatively with other computing resources to create high-availability clusters.
• In one implementation, the model of the storage resources obtained inoperation220 may include various SAN disk-block storage arrays and/or file servers, whereby the storage resources may be collectively pooled and protected with identity-based policy controls. In one implementation, the computing resources described above may access the storage resources on behalf of virtual machines deployed in the infrastructure, wherein the storage resources may be individually managed during lifecycles of the virtual machines in a dynamic manner. Furthermore, the workload management system may group and organize the storage resources in a similar manner as the computing resources, wherein the workload management system may manage the storage resources according to any suitable combination of a type (e.g., available RAID-5 disks), intended purpose (e.g., temporary, protected, remotely replicated, etc.), owner, physical location, or other classifying types.
• In one implementation, the model of the computing resources and the storage resources obtained inoperation220 may further include various relationships between the resources, wherein the relationships may include dependencies, capacities, and bandwidth requirements. For example, any particular virtual, machine deployed in the infrastructure may generally run on physical computing resources, wherein the model may include federated information that links a network address, identities, and other information for the virtual machine with any computing resources and storage resources that have been allocated to the virtual machine, which may enable lifecycle management for the virtual machine. Thus, the configuration management database may generally provide federated knowledge detailing any suitable entity managed in the workload management system and relationships between such managed entities.
• In one implementation, in response to querying the configuration management database inoperation220 to obtain the current model of the infrastructure, anoperation225 may determine whether the workload management system can provision the service requested in the approval workload in a manner that meets any constraints that the request defined for the service. In particular, the workload management system may determine whether the infrastructure model indicates that the infrastructure has available computing resources and storage resources suitable to provision the requested service. Furthermore, the workload management system may employ the identity management and policy enforcement services to determine whether the service can be provisioned to the requesting entity without violating any relevant policies. For example, to authenticate and configure a desktop machine for a chief financial officer, a biometric authorization component (e.g., a fingerprint reader) may be installed in the desktop machine. Thus, the identity management and policy enforcement services may collectively prohibit the workload management system from deploying services to the desktop machine that would add a keystroke logger, remove the biometric authorization component, or violate another policy with respect to the chief financial officer identity. In another example, requests for Bit Torrent storage may be denied regardless of an identity for the requesting identity because a policy prohibits peer-to-peer file sharing.
• Thus, in response to the workload management system determining inoperation225 that the requested service cannot be provisioned in accordance with the constraints defined in the request (e.g., because the infrastructure lacks sufficient computing resources and/or storage resources to support the service, the requested service violates a relevant policy with respect to an identity for the requesting entity, etc.), the workload management system may deny the request and send an appropriate denial notification to the requesting entity in anoperation230. For example, the denial notification may provide a reason for denying the service request, which may provide information that can be referenced to analyze subsequent requests having similar criteria, modify the request based on available resources or relevant policies, audit approval processes in a compliance review, or otherwise referenced.
• On the other hand, in response to determining inoperation225 that the requested service can be provisioned in accordance with the requested constraints (e.g., because the infrastructure has sufficient computing resources and storage resources to support the service, the requested service does not violate any policies with respect to the identity for the requesting entity, etc.), the workload management system may approve the request and then initiate provisioning for the service in anoperation235. In particular, in response to approving the request, the workload management system may reserve appropriate physical computing resources, virtual computing resources, and/or storage resources to run the service, whereinoperation235 may include determining whether such resources can be automatically and/or immediately allocated. For example, certain workloads may be prioritized to ensure that business objectives can be met, wherein the workload management system may defer the approval workload inoperation235 in response to determining that allocating the resources to the approval workload may occupy resources needed for higher priority workloads (e.g., because the reserved resources are currently subject to a “blackout” period for patching or updating the resources).
• As such, in response to determining that the resources reserved to the service cannot be provisioned automatically and/or immediately, the workload management system may manage creation of a provisioning plan for the service in anoperation240. In particular,operation240 may include various automated and/or human entities interacting to create the provisioning plan, wherein the provisioning plan may include pre-empting the approval workload until workloads in a high priority queue have completed, moving the approval workload to the high priority queue, dynamically allocating additional resources to the approval workload (e.g., pre-empting lower priority workloads), or otherwise balancing utilization of the resources in the infrastructure between business processes and system processes that may have, different priorities. Furthermore, in one, implementation, the workload management system may coordinate the interaction between the entities that create the provisioning plan in operation240 (e.g., because the service cannot be provisioned until a certain process has completed, a certain entity provides feedback, etc.). As such,operation240 may generally include various processes and interactions between entities, which the workload management system may manage to create the plan for suitably provisioning the approved service.
• In one implementation, in response to determining that the resources reserved to the service can be provisioned automatically and immediately, or alternatively in response to successfully creating the provisioning plan for the service inoperation240, the workload management system may provision the requested service in anoperation250. In particular,operation250 may include allocating an operating system image, a resource inventory, and software to an orchestrated virtual machine that can run the service and embedding lifecycle control information within the orchestrated virtual machine to enable management for the virtual machine and the computing resources allocated to the service. In one implementation, one or more of the computing resources in the infrastructure may be configured as an image creation server, wherein the image creation servers may be dedicated to creating and installing virtual machines in various ways. For example, in a large information technology infrastructure that frequently creates virtual machine instances, multiple image creation servers may be employed to create and install the virtual machines, or one or more of the image creation servers may be configured to create “in-place” virtual machines, wherein such virtual machines may be incubated on particular computing resources that further execute the virtual machines.
• Thus, in one implementation,operation250 may include invoking an image creation service, which may create a virtual machine image to run the requested service. For example, the image creation service may contact an image repository that contains various ready-to-run virtual machine images, and then appropriately download one or more of the virtual machine images that can run the requested service. The image creation service may then clone and configure the virtual machine image downloaded from the image repository based on any constraints that the request defines for the service. As such,operation250 may generally include creating a new virtual machine having an operating system image, external storage references, and control information particularly configured for the requested service (e.g., based on identities, policies, service level agreements, lifecycle management, etc.), and may further include deploying the newly created virtual machine to computing resources that have been reserved to run the requested service. Alternatively (or additionally), the image creation service may provide a push model for deploying the virtual machine image, wherein the image creation service may instruct the image repository to multi-cast the image to multiple computing resources. Thus, the push model implementation may pre-stage the multi-casted virtual machine image for deployment over various potential deployment targets.
• In one implementation, in response to successfully provisioning the service inoperation250, the workload management system may update the infrastructure model in anoperation260. For example, any resources, identities, policies, or other information associated with the provisioned service may be indexed within a global namespace in the federated configuration management database. As such, the workload management system may reference the updated infrastructure model to track registered virtual machines that have been provisioned and deployed in the infrastructure, hierarchical relationships between the registered virtual machines and the resources, identities, policies, or other information associated with the virtual machines, and otherwise provide lifecycle management for the virtual machines, as will be described in greater detail below. Furthermore, anoperation270 may include the workload management system sending a service provisioning notification to the requesting entity, wherein the notification sent inoperation270 may indicate that the service has been successfully provisioned, provide information that can be referenced to analyze subsequent requests having similar criteria, audit approval processes in a compliance review, or otherwise provide information relevant to the provisioned service.
• In one implementation, the workload management system may manage the provisioned service in anoperation280 in response to successfully provisioning the service inoperation250. In particular, as noted above, updating the infrastructure model inoperation260 may provide information that the workload management system can reference to provide lifecycle management for services provisioned and deployed in the infrastructure. For example, various lifecycle rules and control information may be used to respond to variable computing demands, changes, and unexpected events in the infrastructure, wherein services that run within virtual machines may introspectively monitor and report on health of the hosted services. Thus, the provisioned service may be managed inoperation280 with the lifecycle control information embedded in the host virtual machines (e.g., monitoring real-time execution states and other health conditions, automatically managing identities and policies in response to monitored health conditions, retiring resources reserved or allocated the virtual machine that may no longer be needed, etc.).
• In addition, the workload management system may cooperate with the lifecycle controls embedded in the host virtual machines to manage the provisioned service. In particular, the workload management system may aggregate information relating to the monitored states reported from individual virtual machine instances and record such information within a context describing a current state of the infrastructure model. Thus, physical constraints, dependencies, current performance trends, and other real-time execution states may be monitored to schedule virtual machines that run provisioned services to computing resources for execution in a manner that satisfies any identity constraints, policy controls, service level agreements, or other constraints that have been defined for the services. For example,operation280 may include applying policy-defined thresholds to any status events generated by the monitored computing resources, storage resources, virtual machines, or other resources (e.g., responding to a monitored variable that exceeds or falls below a policy-defined threshold for more than a policy-defined time period). In another example,operation280 may further include managing version controls for virtual machine images, which may provide support for inserting management agents that can tune or patch the virtual machine images as needed, and rolling the virtual machine images back to a “pristine” state, among other things.
• Thus, the techniques described above the intelligentworkload management method200 may generally provide lifecycle management from creating a virtual machine image that can host a requested service through eventual retirement of the virtual machine image. Moreover, in addition to introspective health monitoring and maintenance for individual virtual machine images, the lifecycle management techniques may provide federated information for managing an entire information technology infrastructure, which may be used to assure compliance with legal and contractual obligations for any suitable hardware or software that an organization may use, create detailed plans for implementing or rolling back proposed changes to the infrastructure, detect, resolve, and otherwise remediate, incidents in the infrastructure, reactively and proactively manage problems in the infrastructure with known workarounds, fixes, and permanent infrastructure changes, and ensure that every service in the infrastructure meets or exceeds service level requirements, among other things.
• According to one aspect of the invention,FIG. 3 illustrates an exemplary block diagram of asystem300 for generating single sign-on workload identities, whileFIG. 4 illustrates an exemplary flow diagram of amethod400 that may operate in thesystem300 for generating single sign-on workload identities. Thus, the description to be provided herein forFIG. 3 orFIG. 4 will be understood as corresponding to techniques that can be performed in thesystem300 shown inFIG. 3 or themethod400 shown inFIG. 4, whether or not explicitly described.
• In one implementation, generating single sign-on workload identities may generally include creating an authentication token that defines various credentials or permissions assigned to any suitable user, application, system, service, resource, or other entity having an identity managed in the workload management system. More particularly, an operating system that executes services or other applications on aclient device315 may generally maintain various authentication credentials for any identities managed locally to the operating system, or the operating system may contact anauthentication server320 to obtain authentication credentials for any single sign-on identities that the operating system does not locally manage. In one implementation, theauthentication server320 may therefore provide a single sign-on identity source that contains authentication credentials for every managed entity, wherein single sign-on identity management may be provided for any suitable workload managed in the workload management system.
• For example, in one implementation, the system and method for generating single sign-on workload identities may be used to generate single sign-on authentication tokens, wherein aworkload engine380 may reference the single sign-on authentication tokens to provide identity management for any suitable service request (e.g., to verify that an entity that requests a new service has proper authorization prior to actually provisioning the new service, to verify that an entity that requests access to an existing service has proper authorization prior to granting access to the service, etc.). For example, in one implementation, the authentication server320 (e.g., Novell Access Manager) may communicate with anidentity vault325 that organizes user accounts, roles, policies, and other identity information within various directories. Thus, as shown bycommunication element1 inFIG. 3 (oroperation410 inFIG. 4), any suitable entity may submit an authentication request to theauthentication server320, wherein the authentication request may include single sign-on authentication credentials (e.g., a user name, identifier, password, smart card input, biometric input, etc.).
• In one implementation,communication element2 may then include the authentication server retrieving the authentication credentials for the requesting entity from the federated identity information stored in theidentity vault325. In an operation420 (and communication element3), the authentication server may then generate an authentication token for the requesting entity from the authentication credentials retrieved from theidentity vault325, wherein the authentication token may represent a portable data abstraction that encapsulates any authoritative attribute, active role, valid policy, or other access credential for the entity associated with the authorization token. As such, the authorization token may mask any underlying credential authentication, identity federation, and attribute attestation, wherein the authorization token may be referenced to obtain authoritative statements that indicate whether to authorize or deny any suitable request received from the entity associated with the authorization token. Furthermore, as shown bycommunication element4 inFIG. 3, the authentication token may be returned to theclient device315 that originated the request, whereby any operating systems, applications, services or other resources on theclient device315 that require authentication credentials may use the authentication token to authenticate or deny local requests received from the entity associated with the authorization token.
• In one implementation, the workload management system may include aworkload engine380 that can use authentication tokens generated by theauthentication server320 to manage workloads that include service requests. Furthermore, theworkload engine380 may use authentication tokens for various entities that may be represented in multiple different authentication domains, which may enable workloads to function across different organizational boundaries. In particular, an operation430 (or communication element5) may include receiving a workload that defines a particular service requested by the entity operating theclient device315, wherein the entity may specify various additional entities that may need access to the requested service. As such, an operation440 (or communication element6) may include theworkload engine380 managing the workload to obtain authentication tokens for the requesting entity in addition to authentication tokens for any additional entities specified in the request. Furthermore, as noted above, the entities managed in the workload management system may define various types of customized identities, such that the authentication tokens obtained in operation440 (and communication element6) may represent authentication credentials for any suitable combination of identities that represent the requesting entity and/or the various additional entities (e.g., identities providing limited or complete anonymity, aggregated roles across various federated authentication domains, rights delegated to and/or by other identities, relative roles with respect to other identities, etc.).
• In one implementation, anoperation450 may then include theworkload engine380 analyzing the authentication tokens obtained from theauthentication server320 to identify any authentication credentials that the authentication tokens represent. As such, theworkload engine380 may reference the identified authentication credentials in anoperation460 to determine whether the identities for the requesting entity (and/or the additional entities) have proper authorization for the requested service. Theworkload engine380 may then generate an authentication determination for the workload using the authentication tokens that include federated identity information for the relevant identities in addition to any policies that may be relevant to any identities involved in the workload (e.g., theclient machine315, other services or applications running on theclient machine315, or any other suitable identity involved in a session associated with the workload, as described in further detail above). Thus, in response to determining that the authentication tokens obtained from theauthentication server320 indicate that one or more of the identities involved in the workload lack proper authorization, an operation470 (or communication element7) may include theworkload engine380 notifying the requesting entity that the service request has been denied. Alternatively, in response to determining that every identity involved in the workload has proper authorization, an operation480 (or communication element7) may include notifying the requesting entity that the service request has been approved and subsequently provisioning the requested service.
• Moreover, in response to approving the service request inoperation460,operation480 may further include embedding the authentication tokens obtained in operation440 (and communication element6) within an image created for the approved service. In particular, as described in further detail above, any particular workload may include a request to provision a new service, a request to update identities managed in an existing service, or a another suitable request to manage identities associated with the approved service request. Thus, in one implementation,operation480 may further include theworkload engine380 embedding the authentication tokens within one or more virtual machine images that host the service, whereby any suitable identity associated with the virtual machine images may be managed with the single sign-on authentication tokens obtained from theauthentication server380. For example, to configure a service newly provisioned to a virtual team having various members, authentication tokens for the various team members may be embedded into a virtual machine image that an image creation system creates to host the new service. Similarly, authentication tokens for new members of the team may be embedded within the service image to grant the new members access to the service image, while authentication tokens for any members that leave the team may be removed from the service image to prevent former members of the team from continuing to have access to the service image. In another example, in response to determining that a subset of the team members have proper authorization credentials for the service and that other team members lack proper authorization credentials, the tokens embedded within the image may be limited to the subset having proper credentials, or the workload management system may determine whether members lacking proper credentials have other managed identities with the proper credentials and insert tokens within the image that correspond to the other managed identities.
• Thus, as described in further detail above with reference toFIG. 1A-B, authentication tokens generated at the single sign-onauthentication server380 may be used in various ways to pre-configure or re-configure a virtual machine with embedded authentication credentials for identities managed in the virtual machine. Moreover, any suitable resource in the workload management system may reference the authentication tokens embedded within the virtual machine to manage the identities associated with the virtual machine, whereby the single sign-on authentication tokens may generally provide a portable data abstraction to run identity management services anywhere in the workload management system.
• According to one aspect of the invention,FIG. 5A illustrates a block diagram of anexemplary service distribution500A that can be managed with one or more zeroresidue management agents580 in the workload management system, whileFIG. 5B illustrates anexemplary lifecycle500B for theservice distribution500A managed with the zeroresidue management agents580. In particular, as shown inFIG. 5A, the workload management system may use various orchestrated virtualization services to create and manage a partitioned operating environment for theservice distribution500A, wherein the operating environment may be partitioned into a physical distribution layer and a virtual distribution layer. In one implementation, the physical distribution layer and the virtual distribution layer may collectively define a standard partition model for theservice distribution500A, which may provide control over whether to execute certain portions of theservice distribution500A over physical hardware in a hosting environment or within virtual machines that abstract any physical hardware that hosts the virtual machines. As such, the standard partition model may permit theservice distribution500A to run anywhere in an infrastructure, regardless of any requirements or limitations associated with underlying hardware or software platforms, which may enable optimal utilization for theservice distribution500A.
• In one implementation, the physical distribution layer in theservice distribution500A may provide an interface to physical hardware resources that host components in the virtual distribution layer. For example, the physical distribution layer may include a minimalfunctional kernel550 that bundles various hardware drivers matched to the physical hardware that hosts the components in the virtual distribution layer (e.g., local area network drivers, independent hardware vendor drivers, variable drivers that support certain hardware platforms, etc.). In one implementation, the physical distribution layer may further include apluggable hypervisor560, which may enable theservice distribution500A to concurrently run variousdifferent operating systems520 over the hosting physical hardware, andminimal core packages570 that provide software supporting functionality for the components in the physical distribution layer. In addition, as will be described in further detail below, the physical distribution layer may further include aninjection point580 for dynamically inserting and removing one or more zero residue management agents that can manage thelifecycle500B for theservice distribution500A.
• In one implementation, the virtual distribution layer in theservice distribution500A may provide a tuned appliance, which the physical distribution layer executes over any underlying physical hardware that hosts theservice distribution500A. In particular, the virtual distribution layer may include astorage pointer510 that identifies one or more local or remote storage locations allocated to contain a persistent state for theservice distribution500A (e.g., within a clustered file system organized with storage replication and version management services), in addition to anoperating system520 that includes a minimal number of packages, patterns, or other software components needed to support anyapplications530 in the tuned appliance (e.g., theoperating system520 may include “just enough operating system” (JeOS)520 to support theapplications530 provided in theservice distribution500A). In addition, the virtual distribution layer may include one ormore configurations540 that can be used to configure thestorage pointer510, theoperating system520, and/or theapplications530 in the virtual distribution layer, wherein theconfigurations540 may define a workload profile for theservice distribution500A. For example, the workload profile may include various bundled virtual drivers for tuning components in the virtual distribution layer, attestation tokens defining unique identities and authentication credentials for the components in the virtual distribution layer, a service level declaration that defines any memory, processing, availability, disaster recovery, or other deployment constraints for theservice distribution500A.
• Thus, the components in the virtual distribution layer may be neutral with respect to the components in the physical distribution layer, which may enable the zeroresidue managements580 to independently manage any of the components in the virtual or physical distribution layers. In particular, the workload management system may employ one or more standard formats to create images for the physical distribution layer and/or the virtual distribution layer and encapsulate the physical distribution image and/or the virtual distribution image within one or more metadata wrappers. As such, the zeroresidue management agents580 may be dynamically deployed within theservice distribution500A to manage various different modes during thelifecycle500B of theservice distribution500A. For example, in response to initially creating theservice distribution500A, thelifecycle500B of theservice distribution500A may enter the creation mode, wherein acreation management agent580 may execute a bootstrap process to advertise that theservice distribution500A exists and appropriately download anyadditional management agents580 to manage the different modes of thelifecycle500B for theservice distribution500A.
• For example, in one implementation, in response to thelifecycle500B changing from one mode to another (e.g., from the creation mode through a release mode, a production mode, a test mode, a maintenance mode, an optional re-release mode, and an eventual retirement mode), one or more of themanagement agents580 may be identified based on a current mode in the lifecycle5008 and dynamically inserted into theservice distribution500A. In another example, authentication tokens generated using the techniques shown inFIGS. 3 and 4 and described above may be embedded within theservice distribution500A, wherein therelevant management agents580 may be identified based on the embedded authentication tokens (e.g., in response to a trouble ticket request from a user that describes a problem with aparticular service distribution500A that the user interacts with, theparticular service distribution500A may be located by searching for anservice distributions500A having an embedded authentication token associated with the user, and anappropriate management agent580 may then be deployed to theparticular service distribution500A having the embedded authentication token to diagnose or otherwise provide assistance in resolving the problem with thedistribution500A).
• In one implementation, the identifiedmanagement agent580 may then perform any management tasks associated with the current lifecycle mode, and in response to completing the management tasks, themanagement agent580 may then be removed from theservice distribution500A. In one implementation, removing themanagement agent580 from theservice distribution500A may generally include removing any runtime state associated with themanagement agent580 and rolling back any changes that themanagement agent580 applied to theservice distribution500A in order to perform the management tasks. For example, atest management agent580 that executes during the test mode may disable aYaST configuration tool540 that otherwise controls installation and system management for the virtual distribution layer operating environment, whereby rolling back the changes applied to theservice distribution500A may include re-enabling the YaST configuration tool in response to thetest management agent580 completing the management tasks for the test mode. In another example, apatch management agent580 may be inserted into theservice distribution500A to patch or otherwise update any suitable component in theservice distribution500A during the maintenance mode, wherein runtime states and temporary changes applied by thepatch management agent580 may be removed from theservice distribution500A with thepatch management agent580 in response to the maintenance mode completing.
• Thus, removing the runtime state associated with themanagement agents580 and any temporary changes that themanagement agents580 applies to theservice distribution500A during the various lifecycle modes may ensure that theservice distribution500A has been restored to a “golden” or “pristine” state prior to entering a next lifecycle mode. In particular, the zeroresidue management agents580 may be dynamically inserted into theservice distribution500A to execute appropriate management tasks for a current lifecycle mode, and then appropriately removed in a manner that leaves theservice distribution500A unmodified except for any persistent changes that the management tasks apply to theservice distribution500A. For example, during the maintenance mode, aconfiguration management agent580 may be inserted into theservice distribution500A to modify thestorage pointer510 to point to a new local or remote storage location in response to an original storage location allocated to theservice distribution500A failing or running short on available storage resources, whereby theservice distribution500A may be unchanged except for the modifiedstorage pointer510. In another example, atuning management agent580 may be similarly inserted into theservice distribution500A during the maintenance mode to independently apply any upgrades or other modifications that can tune functionality for theservice distribution500A (e.g., thetuning management agent580 may upgrade thekernel550 and device drivers in the physical distribution layer independently from security patches applied to theoperating system520 orapplications530 in the virtual distribution layer, and in response to completing the upgrades, theservice distribution500A may optionally be re-released to ensure that subsequent versions of theservice distribution500A automatically include the upgrades to thekernel550 and device drivers and the patches applied to theoperating system520 or applications530).
• In one implementation, one or more policies may define themanagement agents580 inserted into theservice distribution500A during the various modes of thelifecycle500B. For example, a required service level defined in theworkload profile540 may define a recipe for one or more of themanagement agents580 to inject into theservice distribution500A to ensure that theservice distribution500A meets or exceeds the required service level (e.g., aconfiguration management agent580 may modify thestorage pointer510 to ensure theservice distribution500A has sufficient storage capacity, atuning management agent580 may modify thehypervisor560 to prepare theservice distribution500A for migration to different physical host resources that provide greater availability or performance, etc.). In other examples, the recipe for themanagement agents580 may be determined automatically (e.g., based on the current mode), based on theapplications530 hosted in theservice distribution500A and any management that may be needed forsuch applications530, or other suitable criteria. Further, in one implementation, one or more of themanagement agents580 may be persistently hosted in theservice distribution500A to capture activity and events that may be relevant to ensuring and auditing compliance with policies, while one or more policies may control whether theservice distribution500A can move from one lifecycle mode to another (e.g., the policies may restrict moving theservice distribution500A from the creation mode to the release mode until the workload management system can ensure that theservice distribution500A meets certain sanity, safety, or policy constraints).
• Thus, as described in further detail above, the zeroresidue management agents580 may provide control for various different modes that occur during thelifecycle500B of theservice distribution500A, including a creation mode for initially creating theservice distribution500A from one or more images stored in a suitable repository, a release mode for delivering theservice distribution500A to suitable entities that will interact with or host theservice distribution500A, a production mode for deploying theservice distribution500A to such entities, a test mode for validating that theservice distribution500A functions correctly, a maintenance mode for debugging, patching, or otherwise updating theservice distribution500A, an optional re-release mode for delivering subsequent versions of theservice distribution500A with any changes applied during the production, test, or maintenance modes, and an eventual retirement mode for de-provisioning any existing versions of theservice distribution500A in response to theservice distribution500A becoming outdated or obsolete.
• According to one aspect of the invention,FIG. 6 illustrates a flow diagram of anexemplary method600 for managing different modes of a service distribution lifecycle with zero residue management agents. In particular, the zero residue management agents shown inFIG. 5A and described in further detail above may be used to manage the different modes of the service distribution lifecycle depending on a current mode of the service distribution. As such, managing the service distribution lifecycle may be initiated in anoperation610, wherein a management workload may be launched to manage the service distribution lifecycle. In particular, anoperation620 may include determining the current mode of the service distribution (e.g., creation, release, production, test, maintenance, etc.), wherein one or more management agents associated with the current mode may be executed in anoperation630. The management agents associated with the current mode may then continually execute any management tasks associated with the current mode until the workload management system determines that the current mode of the service distribution lifecycle has completed in anoperation640. For example, a monitoring management agent may be executed inoperation630 during release, production, test, maintenance, or other appropriate modes to capture events that may be relevant to monitoring the health of the service distribution, compliance with one or more policies, or other suitable information. Thus, the monitoring agent may capture changes that occur to the service distribution during the various lifecycle modes, which may provide a record tracking or otherwise describing an evolution of the service distribution (e.g., for reference to diagnose, audit, or otherwise manage the service distribution).
• As such, the management agents executed duringoperation630 may add, remove, or disable aspects of the service distribution, wherein the management tasks executed duringoperation630 may be controlled based on the current lifecycle mode and any other information relevant to managing identities, policies, compliance, or other aspects of the infrastructure (e.g., certain maintenance tasks may be limiting during well managed modes and restored in other modes). In one implementation,operation640 may determine that the current mode of the service distribution lifecycle has completed based on one or more policies that control whether the service distribution lifecycle can move from one mode to another (e.g., the policies may define approval or rule validation mechanisms). Alternatively (or additionally), the current mode of the lifecycle may complete in response to the management agent executed duringoperation630 completing the relevant management tasks, in response to one or more changes to the service distribution that indicate a change in mode, or other suitable criteria. In any case, in response to determining that the current mode of the service distribution lifecycle has completed inoperation640, the management agent executed duringoperation630 may then be removed from the service distribution in anoperation650, and a pristine or golden state for the service distribution may then be restored in anoperation660. For example, in one implementation, restoring the state for the service distribution may include removing any runtime state associated with the management agent executed duringoperation630 and rolling back any temporary changes that the management agent applied to the service distribution duringoperation630.
• Thus, in response to restoring the state for the service distribution inoperation660, the service distribution may be in the golden or pristine state prior to entering a next mode of the lifecycle (including any persistent changes that the management agents applied to the service distribution during operation630). In particular, anoperation670 may include determining whether or not to retire the service distribution (e.g., in response to the service distribution including outdated or obsolete components), wherein the service distribution may then be retired in anoperation680. For example, retiring the service distribution inoperation680 may include de-provisioning any existing versions of the service distribution, de-allocating any resources associated with the existing versions of the service distribution, migrating information to persistent repositories to enable subsequent auditing of the lifecycles for the de-provisioned service distributions, or other suitable tasks for removing the service distribution from operation in the infrastructure. Alternatively, in response tooperation670 determining that the service distribution will not be retiring, themethod600 may return tooperation620 to identify a next mode of the service distribution lifecycle and initiate execution of one or more management agents for the identified mode. As such, themethod600 may iteratively insert management agents into the service distribution based on the current mode and then remove the management agents from the service distribution until the service distribution eventually retires inoperation680.
• According to one aspect of the invention,FIG. 7 illustrates a block diagram of anexemplary system700 for controlling cloud and virtualized data centers in the intelligent workload management system. In particular, as noted above, cloud and virtualized data centers generally include various dynamically allocated resources that can have unpredictable characteristics. Thus, thesystem700 shown inFIG. 7 and described herein may coordinate such dynamically allocated resources in a closed-loop management infrastructure that can manage declarative policies, fine-grained access controls, and orchestrated management and monitoring tools. For example, thesystem700 may operate in the workload management system described in further detail above, and may provide a mechanism to automatically create images that can be deployed to a public cloud (or cloud data center)790athat may be external to an information technology infrastructure, and which can further be deployed to a private cloud (or virtualized data center)790bthat may be local to the infrastructure. In addition, thesystem700 may be used to install software contained inlicensed software repositories710a,source code repositories710b, or other suitable software sources onto any images that have been deployed to thepublic cloud790aor theprivate cloud790b, control and audit activity that occurs in the images deployed to thepublic cloud790aor theprivate cloud790b, establish and retrieve network addresses (e.g., IP addresses, DHCP addresses, etc.) for cloned images across various operating platforms (e.g., Windows platforms, Linux platforms, etc.), and analyze any impact that the activity occurring in the images deployed to thepublic cloud790aor theprivate cloud790bmay have on other machines or images.
• As such, thesystem700 shown inFIG. 7 and described herein may generally include various features that can provide predictability in controlling images, virtual machines, or other resources that have been deployed to thepublic cloud790aand/or theprivate cloud790b. In particular, in one implementation, thesystem700 may include alicensed software repository710athat contains licensed software, asource code repository710bthat contains software source code, or any other suitable software repository. In one implementation, the licensed software in the licensedsoftware repository710a, the software source code in thesource code repository710b, or other software may then installed over suitable hardware resources to create one ormore hardware installations720a, installed on a virtual machine to create one or morevirtual machine installations720b, and/or built within a suitable build system to create one or moreauto build installations720c. In one implementation, in response to installing or otherwise creating thehardware installations720a, thevirtual machine installations720b, and theauto build installations720c, an appropriate management agent725 may be inserted into the installation720. In particular, the management agent725 may provide functionality for performing various tasks to manage the licensed software, source code, or other software included in the installations720. For example, in one implementation, the tasks performed by the management agents725 may include retrieving DHCP addresses, establishing static IP addresses, providing remote debugging assistance, and inserting one or more personality tools775 (e.g., privileged user management) for the installations720.
• In one implementation, thehardware installations720a,virtual machine installations720b, andauto build installations720cmay each further include a respective identity service727 that provides a unique identity for the respective installations720. For example, in one implementation, the identity services727 may generally include authentication tokens that define one or more federated authorizations or permissions for the respective installations720 (e.g., across a plurality of authentication domains), as described in further detail above. As such, the management agents725 inserted into the various software installations720 may interact with the identity services727 that define the authorizations or permissions for the various software installations720 to uniquely identify and manage the various installations720. For example, in addition to defining the authorizations or permissions for the various installations720, the identity services727 may further identify versions, builds, or other information that can uniquely identify the licensed software, source code, or other software included in the installation, which may enable management for such licensed software, source code, or other software (e.g., in response to detecting updates to the licensed software, source code, or other software in the licensedsoftware repository710aor thesource code repository710b, the integrated identity services727 may be referenced to identify and appropriately update any installations720 that may have been created from the updated software).
• In one implementation, in response to creating the various software installations720 and embedding the suitable management agents725aand identity services727, various operational images may be created from the software installations720. In particular, thevirtual machine installations720band theauto build installations720cmay generally include one or more virtual machine images, as described in further detail above, while thehardware installations720amay generally include software that executes directly over underlying hardware resources. The operational images created from thevirtual machine installations720band theauto build installations720cmay therefore include the virtual machine images included therein, wherein the operational virtual machine images may be provided to animage management system740 that stores the operational virtual machine images in a sharedrepository750a(e.g., an image repository). With respect to thehardware installations720athat include software executing directly over underlying hardware resources rather than virtual machine images, amigration system730 may provide functionality that can create a suitable operational virtual machine image from thehardware installations720a. Themigration system730 may evaluate any licensed software, source code, packages, or other software included in thehardware installations720aand create operational virtual machine images that can run in a virtualized environment. For example, in one implementation, themigration system730 may include a Novell PlateSpin Migratesystem730, a VMwarevCenter Converter system730, or any othersuitable migration system730 that provides conversion or migration services between physical and virtual platforms. The operational virtual machine image created from thehardware installation720amay then be provided to theimage management system740, which may store the operational virtual machine image in the sharedrepository750ain a similar manner as thevirtual machine installations720band theauto build installations720c.
• In one implementation, in response to providing the operational images created from thehardware installations720a, thevirtual machine installations720b, and theauto build installations720cto theimage management system740, theimage management system740 may automatically store the operational images in the sharedrepository750ain response to determining that the operational images do not need to be tested for operational integrity (e.g., because the operational images include an attestation token indicating that the operational images have already passed operational integrity tests). Alternatively, theimage management system740 may optionally invoke atesting engine745athat performs one or more operational integrity tests for the operational images prior to storing the operational images in the sharedrepository750a. For example, the operational integrity tests performed by thetesting engine745amay test the operational images against various test scripts designed to verify integrity for the operational images (e.g., validating checksums, installer functionality, etc.). Thus, in response to thetesting engine745adetermining that one or more of the operational images have passed the operational integrity tests, such operational images may be released to the sharedrepository750a. Alternatively, in response to thetesting engine745adetermining that one or more of the operational images did not pass the operational integrity tests, theimage management system740 may invoke avalidation engine740 that supervises debugging and revalidation for such operational images (e.g., generating a validation workload to coordinate collaborative interaction among various entities that debug and revalidate the operational images until the operational images eventually pass the operational integrity tests). Thevalidation engine745bmay then re-invoke thetesting engine745ato determine whether the operational images have been debugged or otherwise revalidated in a manner that results in the operational images passing the integrity tests, wherein the operational images may be released to the sharedrepository750ain response to passing the integrity tests or prevented from such release in response to not passing the integrity tests.
• In one implementation, thesystem700 may further include adiscovery engine760 that continually monitors the sharedrepository750ato detect whether one or more operational images have been newly added to the sharedrepository750a. Further, in one implementation, theimage management system740, the sharedrepository750a, or another suitable component in thesystem700 may generate an event in response to one or more operational images being added to the sharedrepository750a, wherein the event may notify or otherwise advertise the new operational images to thediscovery engine760. In one implementation, in response to thediscovery engine760 detecting the new operational images in the sharedrepository750aor receiving the event notifying or advertising the new operational images in the sharedrepository750a, thediscovery engine760 may prepare the operational images for deployment to thepublic cloud790aor theprivate cloud790b. In particular, variouspublic clouds790aandprivate clouds790bmay support different image formats, wherein thediscovery engine760 may convert the operational images into the appropriate image format for thepublic cloud790aorprivate cloud790bwhere the operational images will be deployed (e.g., an Amazon Machine Image format for the Amazon Elastic Compute Cloud). Thus, thecloud image repository750bmay contain various cloud images created from the operational images in the sharedrepository750a, wherein the various cloud images may be in various different formats depending on the image format for thepublic cloud790aorprivate cloud790bthat will host the cloud images.
• In one implementation, in response to storing the cloud images in thecloud image repository750b, animage deployment system770 may be invoked to deploy the cloud images to the appropriatepublic cloud790aorprivate cloud790b. In one implementation, prior to deploying the cloud images to the appropriatepublic cloud790aorprivate cloud790b, theimage deployment system770 may invoke animpact analysis engine780 that determines a potential impact of deploying the cloud images to thepublic cloud790aorprivate cloud790b. In particular, deploying the cloud images to thepublic cloud790aorprivate cloud790bmay generally include various deployment processes (e.g., starting, stopping, cloning, or migrating the cloud images). Thus, theimpact analysis engine770 may reference aconfiguration management database785 to validate whether the cloud images can be suitably deployed to thepublic cloud790aor theprivate cloud790b. For example, theimpact analysis engine770 may reference theconfiguration management database785 to verify that other resources detailed in theconfiguration management database785 will not be adversely affected by deploying the cloud images (e.g., because the deployment may require substantial bandwidth during a period of peak network traffic). Furthermore, theimpact analysis engine770 may communicate with anaudit service795, a privilegeduser management service792, or other monitoring services provided in thepublic cloud790aor theprivate cloud790bto enhance the impact analysis (e.g., determining whether conditions in thepublic cloud790aorprivate cloud790bmay have adverse impacts on the deployment, local infrastructure resources, etc.).
• In one implementation, in response to theimpact analysis engine770 determining that deploying the cloud images does not raise potential adverse impacts, or alternatively in response to resolving any such potential adverse impacts, theimage deployment system770 may deploy the cloud images in thecloud image repository750bto the appropriatepublic cloud790aorprivate cloud790b. Further, in one implementation, the operational images in the sharedrepository750amay already be appropriate for deployment into thepublic cloud790aorprivate cloud790bwithout requiring conversion to a cloud image format, in which case theimage deployment system770 may similarly deploy the operational images in the sharedrepository750ato thepublic cloud790aorprivate cloud790b. In one implementation, to deploy the cloud images or operational images to thepublic cloud790aorprivate cloud790b, theimage deployment system770 may clone or modify the cloud images or operational images (e.g., to preserve an original version of the cloud images or operational images prior to the cloud deployment). As such, in response to cloning or modifying the images prior to the cloud deployment, theimage deployment system770 may inject a new or aggregatedidentity service777 into the cloned or modified images, wherein the new or aggregatedidentity service777 may provide a record that identifies a lineage, pedigree, or other relationships for the cloned or modified images. Furthermore, theimage deployment system770 may inject one ormore personality tools775 into the cloned or modified images in response to determining that thepersonality tools775 have not already been injected (e.g., during creation of the original software installations720). For example, as noted above, thepersonality tools775 may generally include tools for privileged user management, remote debugging, or customizing base images (e.g., certain scripts may be applied to a Linux base image in order to customize the base image for particular functions that the image provides).
• In one implementation, theimage deployment system770 may then deploy the cloud images or the operational images to the appropriatepublic cloud790aorprivate cloud790b, wherein the deployed images may be managed in thepublic cloud790aand theprivate cloud790b. For example, as noted above, the images may include embedded management agents725 that can control and track any activity associated with the deployed images through interaction with the embedded identity services727, including verifying that the images comply with any relevant policies or restricting any activity that may not comply with the relevant policies, as described in further detail above. Further, because the management agents725, identity services727 (and/or777), andpersonality tools775 embedded in the images can control, track, and monitor activities for the images that have been deployed to thepublic cloud790aand theprivate cloud790b, the monitored activity may be provided to anaudit service795 that can remediate the activity in response to any problems with the images, provide compliance assurance for the activity associated with the images, or otherwise analyze activity that occurs in the images following deployment to thepublic cloud790aor theprivate cloud790b. Similarly, the embedded identity services727 (and/or777) may interact with a privilegeduser management service792 in thepublic cloud790aor theprivate cloud790b, wherein the privilegeduser management service792 and theaudit service795 may cooperate in various ways to remediate, assure compliance, or otherwise analyze the activity that occurs in the images following deployment to thepublic cloud790aor theprivate cloud790b.
• According to one aspect of the invention,FIG. 8 illustrates a flow diagram of anexemplary method800 for controlling cloud and virtualized data centers in the intelligent workload management system. In particular, themethod800 may generally operate in thesystem700 shown inFIG. 7 and described in further detail above, whereby themethod800 may provide predictability in controlling images, virtual machines, or other resources that have been deployed to public clouds (or cloud data centers) and private clouds (or virtualized data centers). For example, as noted above in connection withFIG. 7, control over the cloud data centers and the virtualized data centers may be provided through various features that can automatically create and deploy images to the public clouds and the private clouds, install software from repositories that contain licensed software, source code, or other software onto the images deployed to the public or private clouds, control and audit activity that occurs in the deployed images, establish and retrieve network addresses or other network configurations for cloned images across various operating platforms, and analyze impacts that activity occurring in the deployed images may have on other machines or images to generate appropriate decisions for managing and controlling the data centers provided in the public and private clouds.
• In particular, in one implementation, themethod800 may retrieve licensed software from a licensed software repository, software source code from a source code repository, or other software from another suitable repository, wherein anoperation810 may include creating a software installation from the licensed software, the software source code, or the other software. In one implementation, the software installation created inoperation810 may include a hardware installation installed over suitable hardware resources, a virtual machine installation installed on a virtual machine, and/or an auto build installation built using a suitable build system. In response to installing or otherwise creating the software installation inoperation810, an appropriate management agent may then be embedded in the software installation in anoperation820. For example, the management agent embedded in the software installation inoperation820 may provide functionality for performing various tasks to manage the licensed software, source code, or other software included in the software installation (e.g., DHCP address retrieval, static IP address assignment, remote debugging, personality or privileged user management insertion, etc.).
• In one implementation,operation820 may further include embedding an identity service within the software installation created inoperation810. In particular, the identity service may generally provide a unique identity for the software installation, and may further include an authentication token that defines one or more federated authorizations or permissions for the software installation across a plurality of authentication domains. As such, the management agent and the identity service embedded in the software installation inoperation820 may interact with one another, whereby the management agent may reference the identity service to determine a unique identity for the software installation, resolve the authorizations or permissions for the software installation from the unique identity, and otherwise manage the software installation. For example, in addition to defining authorizations or permissions that control resources that the software installation can access, the identity service may further identify a version, build, or other information that uniquely identifies the licensed software, source code, or other software included in the installation. As such, the interaction between the management agent and the identity service may be used to manage the licensed software, source code, or other software included in the installation. For example, in one implementation, the embedded management agent may reference the embedded identity service to determine whether the installation was created from licensed software, source code, or other software that has been updated in the licensed software repository or the source code repository and then appropriately update the installation in response to determining that the installation was created from the updated software.
• In one implementation, in response to creating the software installation and embedding the management agent and the identity service, an operational image may be created from the software installation. In particular, anoperation825 may include determining whether the software installation includes a hardware installation, a virtual machine installation, or an auto build installation, wherein virtual machine installations and auto build installations generally include one or more virtual machine images, as described in further detail above. Thus, in response to determining that the software installation includes a virtual machine installation or an auto build installation inoperation825, creating the operational image may include providing the virtual machine images included therein to an image management system that stores the operational virtual machine images in a shared repository (e.g., an image repository). Alternatively, hardware installations may generally include software that executes directly over underlying hardware resources, whereby anoperation830 may include creating a virtual machine from the hardware installation to prepare the hardware installation for migration to a virtualized environment. In particular,operation830 may invoke a migration system providing functionality for creating operational virtual machine images from hardware installations, wherein the migration system may evaluate any licensed software, source code, packages, or other software included in the hardware installation and appropriately create the operational virtual machine image. For example, the migration system may include Novell PlateSpin Migrate, VMware vCenter Converter, or any other migration system that provides conversion or migration services between physical and virtual platforms. The operational virtual machine image created from the hardware installation may then be provided to the image management system, which may store the operational virtual machine image in the shared repository in a similar manner as for virtual machine installations or auto build installations.
• In one implementation, in response to providing the operational image created from the software installation to the image management system, anoperation835 may include determining whether or not to test the operational images for operational integrity. For example, anoperation860 may include the image management system automatically storing the operational image in the shared repository in response to determining that the operational image does not need to be tested (e.g., because the operational image includes an attestation token indicating that the operational image has already passed operational integrity tests). Alternatively, anoperation840 may include the image management system optionally invoking a testing engine that runs one or more operational integrity tests for the operational image prior to storing the operational image in the shared repository. For example, the operational integrity tests run inoperation840, may test the operational image against various test scripts designed to verify integrity for the operational image (e.g., validating checksums, installer functionality, etc.). Thus, anoperation845 may include determining whether the operational image passed the operational integrity tests, wherein the operational image may be released to the shared repository inoperation860 in response to the operational image passing the integrity tests. Alternatively, in response determining that the operational image did not pass the operational integrity tests inoperation845, a validation engine may be invoked in anoperation850, wherein the validation engine may supervise debugging and revalidation for the operational image (e.g., generating a debugging workload to coordinate collaborative interaction among various entities associated with the failed operational image). The validation engine may thenre-invoke operation840 to determine whether the operational image has been debugged or otherwise revalidated in a manner that results in the operational image passing the integrity tests, wherein the operational image may be released to the shared repository inoperation860 in response to passing the integrity tests, whereas the operational image may be iteratively debugged and revalidated inoperations840 through850 until the operational image successfully passes the integrity tests.
• In one implementation, a discovery engine may continually monitor the shared repository to detect whether the operational image has been newly added to the shared repository. Alternatively, the image management system, the shared repository, or another component may generate an event in response to adding the operational image to the shared repository, wherein the event may notify or otherwise advertise the new operational image to the discovery engine. Thus, in response to the discovery engine detecting that the new operational image has been added to the shared repository or receiving the event notifying or advertising the new operational image in the shared repository, anoperation870 may include generating a cloud image to prepare the operational image for deployment to the public cloud or the private cloud. In particular, various public clouds and private clouds may support different image formats, whereinoperation870 may include converting the operational image into the appropriate image format for the public cloud or private cloud where the operational image will be deployed (e.g., an Amazon Machine Image format for the Amazon Elastic Compute Cloud). Thus, the cloud image created inoperation870 may be in a cloud image format that depends on an image format used in the public cloud or private cloud that will host the cloud image created inoperation870.
• In one implementation, in response to generating the cloud image inoperation870, an image deployment system may be invoked to deploy the cloud image to the appropriate public cloud or private cloud. In one implementation, prior to deploying the cloud images to the appropriate public cloud or private cloud, anoperation875amay include determining whether to invoke an impact analysis engine that determines a potential impact of deploying the cloud images to the public cloud or private cloud. In particular, deploying the cloud images to the public cloud or private cloud may generally include various deployment processes (e.g., starting, stopping, cloning, or migrating the cloud images), wherein the impact analysis optionally performed inoperation875amay include referencing a configuration management database to validate whether the cloud images can be suitably deployed to the public cloud or the private cloud. For example, the impact analysis engine may reference the configuration management database to verify that other resources detailed in the configuration management database will not be adversely affected by deploying the cloud images (e.g., because the deployment may require substantial bandwidth during a period of peak network traffic). Furthermore, the impact analysis engine may communicate with an audit service, a privileged user management service, or other monitoring services provided in the public cloud or the private cloud to enhance the impact analysis (e.g., determining whether conditions in the public cloud or private cloud may have adverse impacts on the deployment, local infrastructure resources, etc.). As such, in response to determining that potential adverse impacts may result from deploying the image to the cloud in anoperation875b, the image may be revalidated inoperation850, oroperation850 may include other processes to resolve the adverse impacts.
• In one implementation, in response to determining that deploying the cloud image does not raise potential adverse impacts inoperation875b, or alternatively in response to resolving any such potential adverse impacts, anoperation880 may include deploying the cloud image to the appropriate public cloud or private cloud. Further, in one implementation, the operational image stored in the shared repository inoperation860 may already be appropriate for deployment into the public cloud or private cloud without requiring conversion to a cloud image format inoperation870, in whichcase operation880 may include similarly deploying the operational image stored inoperation860 to the public cloud or private cloud. In one implementation, to deploy the cloud images or operational images to the public cloud or private cloud,operation880 ma include cloning or modifying the cloud image or the operational image (e.g., to preserve an original version of the cloud image or operational image prior to the deployment operation880). As such, in response to cloning or modifying the image prior to the cloud deployment,operation880 may further include injecting a new or aggregated identity service into the cloned or modified image, wherein the new or aggregated identity service may provide a record that identifies a lineage, pedigree, or other relationships for the cloned or modified image. Furthermore,operation880 may include injecting one or more personality tools into the cloned or modified image in response to determining that the personality tools have not already been injected (e.g., during creation of the original software installation inoperations810 and820). For example, as noted above, the personality tools may generally include tools for privileged user management, remote debugging, or customizing base images (e.g., certain scripts may be applied to a Linux base image in order to customize the base image for particular functions that the image provides).
• In one implementation,operation880 may then include deploying the cloud image or the operational image to the appropriate public cloud or private cloud, whereinoperation880 may further include managing the image deployed to the public or private cloud. For example, as noted above, the image may include an embedded management agent that can control and track any activity associated with the deployed image through interaction with the embedded identity service, including verifying that the image complies with any relevant policies or restricting any activity that may not comply with the relevant policies, as described in further detail above. Further, because the management agent, identity service, and personality tools embedded in the image can control, track, and monitor activities for the image deployed to the public or private cloud,operation880 may include providing the monitored activity to an audit service in the cloud that can remediate any problems with the image, provide compliance assurance for the activity associated with the image, or otherwise analyze the activity that occurs in the image following deployment to the cloud. Similarly, the embedded identity service may interact with a privileged user management service in the cloud, wherein the privileged user management service and the audit service in the cloud may cooperate in various ways to remediate, assure compliance, or otherwise analyze the activity that occurs in the image following deployment to the cloud.
• Implementations of the invention may be made in hardware, firmware, software, or various combinations thereof. The invention may also be implemented as instructions stored on a machine-readable medium, which may be read and executed using one or more processing devices. In one implementation, the machine-readable medium may include various mechanisms for storing and/or transmitting information in a form that can be read by a machine (e.g., a computing device). For example, a machine-readable storage medium may include read only memory, random access memory, magnetic disk storage media, optical storage media, flash memory devices, and other media for storing information, and a machine-readable transmission media may include forms of propagated signals, including carrier waves, infrared signals, digital signals, and other media for transmitting information. While firmware, software, routines, or instructions may be described in the above disclosure in terms of specific exemplary aspects and implementations performing certain actions, it will be apparent that such descriptions are merely for the sake of convenience and that such actions in fact result from computing devices, processing devices, processors, controllers, or other devices or machines executing the firmware, software, routines, or instructions.
• Furthermore, aspects and implementations may be described in the above disclosure as including particular features, structures, or characteristics, but it will be apparent that every aspect or implementation may or may not necessarily include the particular features, structures, or characteristics. Further, where particular features, structures, or characteristics have been described in connection with a specific aspect or implementation, it will be understood that such features, structures, or characteristics may be included with other aspects or implementations, whether or not explicitly described. Thus, various changes and modifications may be made to the preceding disclosure without departing from the scope or spirit of the invention, and the specification and drawings should therefore be regarded as exemplary only, with the scope of the invention determined solely by the appended claims.

Claims (20)

1. A system for controlling cloud and virtualized data centers in an intelligent workload management system, comprising:

at least one software installation having an embedded management agent;

an authentication server that embeds an identity service in the at least one software installation, wherein the embedded identity service includes an authentication token defining authorizations or permissions for a unique identity assigned to the software installation;

an image management system that stores a virtual machine image created from the software installation in a shared repository;

a cloud image repository that stores a cloud image created from the virtual machine image in the shared repository, wherein the cloud image created from the virtual machine image includes the embedded management agent and the embedded identity service; and

an image deployment system that deploys the cloud image with the embedded management agent and the embedded identity service into a cloud computing environment.

2. The system ofclaim 1, further comprising:

a licensed software repository that stores licensed software; and

a source code repository that stores software source code, wherein the at least one software installation is created from at least one of the licensed software stored in the licensed software repository or the software source code stored in the source code repository.

3. The system ofclaim 1, wherein the at least one software installation includes at least one of a virtual machine installation or an auto build installation that includes the virtual machine image created from the software installation.

4. The system ofclaim 3, wherein the at least one software installation includes a hardware installation that includes software installed directly over one or more physical hardware resources, and wherein the system further comprises a migration system that creates the virtual machine image from the software installed directly over the one or more physical hardware resources.

5. The system ofclaim 1, wherein the image management system includes:

a testing engine that runs a plurality of operational integrity tests against the virtual machine image created from the software installation and releases the virtual machine image to the shared repository in response to the virtual machine image passing the plurality of operational integrity tests; and

a validation engine that restricts releasing the virtual machine image to the shared repository in response to the virtual machine image failing one or more of the plurality of operational integrity tests, wherein the validation engine restricts releasing the virtual machine image to the shared repository until a validation workload controlled by the embedded management agent and the embedded identity service results in the virtual machine image passing the plurality of operational integrity tests.

6. The system ofclaim 5, further comprising a discovery engine that creates the cloud image from the virtual machine image in response to detecting that the virtual machine image has been released to the shared repository, or in response to receiving an event advertising that the virtual machine image has been released to the shared repository.

7. The system ofclaim 6, wherein the discovery engine converts the virtual machine image into an image format associated with the cloud computing environment to create the cloud image from the virtual machine image.

8. The system ofclaim 1, wherein the image deployment system includes an impact analysis engine that determines whether deploying the cloud image into the cloud computing environment will create one or more potential adverse impacts in an information technology infrastructure, and wherein the image deployment system is configured to:

deploy the cloud image into the cloud computing environment in response to the impact analysis engine determining that deploying the cloud image will not create any potential adverse impacts in the information technology infrastructure; and

deploy the cloud image into the cloud computing environment in response to the impact analysis engine determining that deploying the cloud image will create one or more potential adverse impacts in the information technology infrastructure and resolving the one or more potential adverse impacts.

9. The system ofclaim 1, wherein the image deployment system creates a clone of the cloud image deployed into the cloud computing environment and embeds a new or aggregated identity service in the clone of the cloud image, wherein the new or aggregated identity service embedded in the clone of the cloud image records a lineage for the cloud image.

10. The system ofclaim 1, wherein the cloud computing environment includes an audit service and a privileged user management service that interact with the management agent and the identity service embedded in the cloud image to control, monitor, and audit activity that occurs in the cloud image following deployment to the cloud computing environment.

11. A method for controlling cloud and virtualized data centers in an intelligent workload management system, comprising:

creating at least one software installation having an embedded management agent;

embedding, by an authentication server, an identity service in the at least one software installation, wherein the embedded identity service includes an authentication token defining authorizations or permissions for a unique identity assigned to the software installation;

storing, by an image management system, a virtual machine image created from the software installation, wherein the image management system stores the virtual machine image created from the software installation in a shared repository;

storing, in a cloud image repository, a cloud image created from the virtual machine image, wherein the cloud image created from the virtual machine image includes the embedded management agent and the embedded identity service; and

deploying, by an image deployment system, the cloud image with the embedded management agent and the embedded identity service into a cloud computing environment.

12. The method ofclaim 11, further comprising:

storing licensed software in a licensed software repository; and

storing software source code in a source code repository, wherein the at least one software installation is created from at least one of the licensed software stored in the licensed software repository or the software source code stored in the source code repository.

13. The method ofclaim 11, wherein the at least one software installation includes at least one of a virtual machine installation or an auto build installation that includes the virtual machine image created from the software installation.

14. The method ofclaim 13, wherein the at least one software installation includes a hardware installation that includes software installed directly over one or more physical hardware resources, and wherein the method further comprises creating, by a migration system, the virtual machine image from the software installed directly over the one or more physical hardware resources.

15. The method ofclaim 11, further comprising:

running, by a testing engine, a plurality of operational integrity tests against the virtual machine image created from the software installation;

releasing the virtual machine image to the shared repository in response to the virtual machine image passing the plurality of operational integrity tests, wherein a validation engine restricts releasing the virtual machine image to the shared repository in response to the virtual machine image failing one or more of the plurality of operational integrity tests; and

releasing the virtual machine image to the shared repository in response to a validation workload controlled by the embedded management agent and the embedded identity service resulting in the virtual machine image passing the plurality of operational integrity tests.

16. The method ofclaim 15, further comprising:

creating the cloud image from the virtual machine image in response to a discovery engine detecting the release of the virtual machine image to the shared repository; and

creating the cloud image from the virtual machine image in response to the discovery engine receiving an event advertising the release of the virtual machine image to the shared repository.

17. The method ofclaim 16, wherein creating the cloud image from the virtual machine image includes converting the virtual machine image into an image format associated with the cloud computing environment.

18. The method ofclaim 11, further comprising determining, by an impact analysis engine, whether deploying the cloud image into the cloud computing environment will create one or more potential adverse impacts in an information technology infrastructure, wherein deploying the cloud image into the cloud computing environment includes:

deploying the cloud image into the cloud computing environment in response to the impact analysis engine determining that deploying the cloud image will not create any potential adverse impacts in the information technology infrastructure; and

deploying the cloud image into the cloud computing environment in response to the impact analysis engine determining that deploying the cloud image will create one or more potential adverse impacts in the information technology infrastructure and resolving the one or more potential adverse impacts.

19. The method ofclaim 11, further comprising:

creating, by the image deployment system, a clone of the cloud image deployed into the cloud computing environment; and

embedding, by the image deployment system, a new or aggregated identity service in the clone of the cloud image, wherein the new or aggregated identity service embedded in the clone of the cloud image records a lineage for the cloud image.

20. The method ofclaim 11, wherein the cloud computing environment includes an audit service and a privileged user management service that interact with the management agent and the identity service embedded in the cloud image to control, monitor, and audit activity that occurs in the cloud image following deployment to the cloud computing environment.

Images