U.S. patent application number 12/645114 was filed with the patent office on 2011-05-26 for system and method for controlling cloud and virtualized data centers in an intelligent workload management system.
This patent application is currently assigned to Novell, Inc.. Invention is credited to Stephen R. Carter, Michael Jorgensen, Nathaniel Brent Kranendonk, Kal A. Larsen.
Application Number | 20110126197 12/645114 |
Document ID | / |
Family ID | 44062913 |
Filed Date | 2011-05-26 |
United States Patent
Application |
20110126197 |
Kind Code |
A1 |
Larsen; Kal A. ; et
al. |
May 26, 2011 |
SYSTEM AND METHOD FOR CONTROLLING CLOUD AND VIRTUALIZED DATA
CENTERS IN AN INTELLIGENT WORKLOAD MANAGEMENT SYSTEM
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.
Inventors: |
Larsen; Kal A.;
(Springville, UT) ; Carter; Stephen R.; (Spanish
Fork, UT) ; Jorgensen; Michael; (Mapleton, UT)
; Kranendonk; Nathaniel Brent; (Springville, UT) |
Assignee: |
Novell, Inc.
Provo
UT
|
Family ID: |
44062913 |
Appl. No.: |
12/645114 |
Filed: |
December 22, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61264562 |
Nov 25, 2009 |
|
|
|
Current U.S.
Class: |
718/1 ; 709/223;
717/176 |
Current CPC
Class: |
G06Q 10/06 20130101;
G06F 9/455 20130101; H04L 9/3213 20130101; H04L 63/0815 20130101;
G06F 21/31 20130101; G06F 9/45533 20130101; G06Q 10/06313 20130101;
G06Q 10/10 20130101; H04L 63/08 20130101; H04L 63/14 20130101; H04L
63/0807 20130101 |
Class at
Publication: |
718/1 ; 709/223;
717/176 |
International
Class: |
G06F 9/455 20060101
G06F009/455; G06F 15/173 20060101 G06F015/173; G06F 9/445 20060101
G06F009/445 |
Claims
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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] 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.
[0002] 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
[0003] 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
[0004] "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.
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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
[0009] 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).
[0010] 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.
[0011] 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.
[0012] 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).
[0013] 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).
[0014] 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.).
[0015] 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.).
[0016] 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
[0017] 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.
[0018] 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.
[0019] FIG. 2 illustrates a flow diagram of an exemplary method for
intelligent workload management, according to one aspect of the
invention.
[0020] 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.
[0021] 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.
[0022] 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, while FIG. 5B
illustrates an exemplary lifecycle for a service distribution
managed with the zero residue management agents, according to one
aspect of the invention.
[0023] 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.
[0024] 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.
[0025] 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
[0026] According to one aspect of the invention, FIG. 1A
illustrates an exemplary model-driven architecture 100A in a system
for intelligent workload management, while FIG. 1B illustrates an
exemplary service-oriented architecture 100B in the system for
intelligent workload management. In one implementation, the
model-driven architecture 100A shown in FIG. 1A and the
service-oriented architecture 100B shown in FIG. 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 in FIGS. 1A and 1B will be
understood as corresponding to such components in both FIGS. 1A and
1B, whether or not explicitly described.
[0027] In one implementation, the model-driven architecture 100A
illustrated in FIG. 1A and the service-oriented architecture 100B
illustrated in FIG. 1B may provide an agile, responsive, reliable,
and interoperable information technology environment, which may
address various problems associated with managing an information
technology infrastructure 110 (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-driven
architecture 100A and the service-oriented architecture 100B 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-driven architecture 100A and
the service-oriented architecture 100B may therefore provide a
flexible framework that may enable the workload management system
to allocate various resources 114 in the information technology
infrastructure 110 in a manner that balances governance, risk, and
compliance with capacities for internal and external resources 114.
For example, as will be described in further detail herein, the
workload management system may operate within the flexible
framework that the model-driven architecture 100A and the
service-oriented architecture 100B to deliver information
technology tools for managing security, performance, availability,
and policy objectives for services provisioned in the information
technology infrastructure 110.
[0028] Identity Management
[0029] In one implementation, as noted above, the technologies
integrated by the model-driven architecture 100A and the
service-oriented architecture 100B may enable managing identities
in the information technology infrastructure 110. In particular,
managing identities may present an important concern in the context
of managing services in the information technology infrastructure
110 because security, performance, availability, policy objectives,
and other variables may have different importance for different
users, customers, applications, systems, or other resources 114
that operate in the information technology infrastructure 110. As
such, the model-driven architecture 100A and the service-oriented
architecture 100B may include various components that enable
identity management in the information technology infrastructure
110.
[0030] For example, in one implementation, the workload management
system may include an access manager 120 (e.g., Novell Access
Manager), which may communicate with an identity vault 125 and
control access to content, applications, services, and other
resources 114 in the information technology infrastructure 110. In
one implementation, the access manager 120 may enforce various
policy declarations to provide authentication services for any
suitable component in the information technology infrastructure
110. For example, the identity vault 125 may include various
directories that organize user accounts, roles, policies, and other
identity information that the access manager 120 can reference to
generate authorization decisions. The access manager 120 and the
identity vault 125 may further support federated user identities,
wherein a user at any particular client resource 115 may submit
single sign-on authentication credentials to the access manager
120, which may then control access to any suitable resource 114 in
the information technology infrastructure 110 with the single
sign-on authentication credentials (e.g., user names, identifiers,
passwords, smart cards, biometrics, etc.). Moreover, the identity
information stored in the identity vault 125 may be provided to a
synchronization engine 150, whereby the synchronization engine 150
may provide interoperable and transportable identity information
throughout the architecture (e.g., via an identity fabric within an
event bus 140 that manages transport throughout the
architecture).
[0031] In one implementation, providing the identity information
stored in the identity vault 125 to the synchronization engine 150
may form portable identities that correspond to independent digital
representations for various users, applications, systems, or other
entities that interact with the information technology
infrastructure 110. In particular, the identities maintained in the
synchronization engine 150 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
the identity vault 125 with the synchronization engine 150 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.
[0032] In one implementation, the identities stored in the identity
vault 125 and synchronized with the synchronization engine 150 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 the synchronization engine 150 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, the synchronization
engine 150 may include a service that can enforce policies
controlling whether certain information stored in the identity
vault 125 can be shared (e.g., through the access manager 120 or
other information technology tools that can manage and customize
identities).
[0033] 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
resources 114 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, the access manager 120, the identity vault
125, and the synchronization engine 150 may manage identity
services externally to applications, services, and other resources
114 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,
the access manager 120, the identity vault 125, and the
synchronization engine 150 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.
[0034] As such, in one implementation, the workload management
system may employ the identity services provided in the
model-driven architecture 100A and the service-oriented
architecture 100B to apply policies for representing and
controlling roles for multiple identities within any particular
session that occurs in the information technology infrastructure
110. For example, in response to a session that includes a user
logging into a client machine 115 and invoking a backup service,
the workload management system may manage the session with multiple
identities that encompass the user, the backup service, and the
client machine 115. The workload management system may further
determine that the identity for the client machine 115 represents
an unsecured machine that resides outside an organizational
firewall, which may result in the workload management system
retrieving a policy from the identity vault 125 and/or the
synchronization engine 150 and applying the policy to the session
(e.g., the policy may dynamically prevent the machine 115 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 resources 114 in the
information technology infrastructure 110.
[0035] In one implementation, the model-driven architecture 100A
and the service-oriented architecture 100B 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 clustered file
system 195 during a particular time interval (e.g., 2 a.m. to 3
a.m.). In response to the file system 195 receiving the read
request from the backup service, the identity services may enable
the file system 195 to audit identities for the backup service and
the user, and further to constrain read permissions within the file
system 195 based on the relevant rights defined by the identities
for the backup service for the user.
[0036] In one implementation, the model-driven architecture 100A
and the service-oriented architecture 100B 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.
[0037] Thus, in the model-driven architecture 100A and the
service-oriented architecture 1008, 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
resources 114. In one implementation, while the identity
information may generally be stored and maintained in the identity
vault 125, the identity information can be composed and transformed
through the access manager 120 and/or the synchronization engine
150, with the resulting identity information providing
authoritative statements for represented entities that span
multiple authentication domains within and/or beyond boundaries for
the information technology infrastructure 110. 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-driven architecture 100A and the service-oriented
architecture 100B may include various forms of authentication,
identifier mapping, token transformation, identity attribute
management, and identity relationship mapping.
[0038] Policy Enforcement
[0039] In one implementation, as noted above, the technologies
integrated by the model-driven architecture 100A and the
service-oriented architecture 100B may enable enforcing policies in
the information technology infrastructure 110. In particular,
enforcing policies may present an important concern in the context
of managing services in the information technology infrastructure
110 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-driven architecture 100A and the service-oriented
architecture 100B 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 the information technology infrastructure 110
[0040] As such, in one implementation, the model-driven
architecture 100A and the service-oriented architecture 100B 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 resource
114 (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 suitable physical resources 114a
(e.g., physical servers, hardware devices, etc.), virtualized
resources 114b (e.g., virtual machine images, virtualized servers,
etc.), configuration resources 114c (e.g.; management agents,
translation services, etc.), storage resources (e.g., the clustered
file system 195, one or more databases 155, etc.), or other
resources 114 for a particular workload. For example, the
synchronization engine 150 may dynamically retrieve various
policies stored in the databases 155, and an event audit service
135b may then evaluate the policies maintained in the
synchronization engine 150 independently from services that
subsequently enforce policy decisions (e.g., the event audit
service 135b may determine whether the policies permit access to
certain information for a particular application and the
application may then enforce the policy determination).
[0041] In one implementation, separating policy evaluation within
the event audit service 135b from 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. The event
audit service 135b may 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 a correlation system 165 and remediation
services that may be provided in a workload service 135a.
[0042] In one implementation, to ensure correct and effective
policy decisions, the policy definition service provided within the
event audit service 135b may be configured to obtain data relating
to a current state and configuration for resources 114 managed in
the infrastructure 110 in addition to data relating to dependencies
or other interactions between the managed resources 114. For
example, a management infrastructure 170 may include a discovery
engine 180b that dynamically monitors various events that the
infrastructure 110 generates and pushes onto the event bus 140,
which may include an event backplane for transporting the events.
Moreover, the discovery engine 180b may query the infrastructure
110 to determine relationships and dependencies among users,
applications, services, and other resources 114 in the
infrastructure 110. As such, the discovery engine 180b may monitor
the event bus 140 to obtain the events generated in the
infrastructure 110 and synchronize the events to the
synchronization engine 150, and may further synchronize information
relating to the relationships and dependencies identified in the
infrastructure 110 to the synchronization engine 150. In one
implementation, the event audit service 135b may then evaluate any
events, resource relationships, resource dependencies, or other
information describing the operational state and the configuration
state of the infrastructure 110 in view of any relevant policies
and subsequently provide any such policy evaluations to requesting
entities.
[0043] 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., the event audit service 135b may 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 resources 114a,
virtualized resources 114b, or any other suitable object or
resource 114 in the infrastructure 110. 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 resource 114 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.
[0044] 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 resources 114,
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 the event audit service 135b
may 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, a definitive
software library 190 may include one or more standardized policy
libraries for translating between potentially disparate policy
implementations, which may enable the event audit service 135b to
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 library 190).
[0045] Compliance Assurance
[0046] In one implementation, as noted above, the technologies
integrated by the model-driven architecture 100A and the
service-oriented architecture 100B may enable monitoring for
compliance assurances in the information technology infrastructure
110. In particular, compliance assurance may present an important
concern in the context of managing services in the information
technology infrastructure 110 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-driven architecture 100A and the service-oriented
architecture 100B 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,
the infrastructure 110, 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 resources 114.
[0047] As such, in one implementation, the model-driven
architecture 100A and the service-oriented architecture 100B 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 the infrastructure 110 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
generate compliance reports 145 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 reports 145 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 resources 114 involved in the process flow.
[0048] 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 the information
technology infrastructure 110.
[0049] In one implementation, the compliance management service may
operate within a workload engine 180a provided within the
management infrastructure 170 and/or a workload service 135b in
communication with the synchronization engine 150. The workload
engine 180a and/or the workload service 135b may 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 resources 114 that may be performing operational activity
that occurs in the information technology infrastructure 110. In
particular, the compliance management service may interact with the
access manager 120, the identity vault 125, the synchronization
engine 150, 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, the correlation system 165 may provide analytic
services to process audit trails for any suitable resource 114
(e.g., correlating the audit trails and then mapping certain
activities to identities for resources 114 involved in the
activities). Furthermore, in response to the correlation system 165
processing the audit trails and determining that certain policies
have been violated, the correlation system 165 may invoke one or
more automated remediation workloads to initiate appropriate action
for addressing the policy violations.
[0050] 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 the information
technology infrastructure 110 and any policy evaluation
determinations that the event audit service 135b generates through
the policy definition service. For example, in one implementation,
the workload engine 180a and/or the workload service 135b may
retrieve information from a configuration management database 185a
or other databases 155 that provide federated configuration
information for managing the resources 114 in the information
technology infrastructure 110. The workload engine 180a and/or the
workload service 135b may 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 the information technology infrastructure 110. To that end,
the model-driven architecture 100A and the service-oriented
architecture 100B may provide various compliance management models
may be used in the compliance management service.
[0051] In one implementation, the compliance management models may
include a wrapped compliance management model that manages
resources 114 lacking internal awareness over policy-based
controls. The compliance management service may augment the
resources 114 managed in the wrapped compliance model with one or
more policy decision points and/or policy enforcement points that
reside externally to the managed resources 114 (e.g., the event
audit service 135b). For example, the policy decision points and/or
the policy enforcement points may intercept any requests directed
to the resources 114 managed in the wrapped compliance model,
generate policy decisions that indicate whether the resources 114
can properly perform the requests, and then enforce the policy
decisions (e.g., forwarding the requests to the resources 114 in
response to determining that the resources 114 can properly perform
the requests, denying the requests in response to determining that
the resources 114 can properly perform the requests, etc.). Thus,
because the resources 114 managed in the wrapped compliance model
generally perform any requests that the resources 114 receive
without considering policy-based controls or compliance issues, the
event audit service 135b may further execute the compliance
management service to wrap, coordinate, and synthesize an audit
trail that includes data obtained from the managed resources 114
and the wrapping policy definition service.
[0052] In one implementation, the compliance management models may
include a delegated compliance management model to manage resources
114 that implement a policy enforcement point and reference an
external policy decision point, wherein the resources 114 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
resources 114 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 the event audit service 135b may
nonetheless execute the compliance management service to coordinate
and synthesize an audit trail that includes data obtained from the
managed resources 114 and the delegated external policy decision
point.
[0053] In one implementation, the compliance management models may
include an embedded compliance management model that manages
resources 114 that internally implement policy enforcement points
and policy decision points, wherein the resources 114 managed in
the embedded compliance management model may have full internal
awareness over policy-based controls. As such, in one
implementation, the resources 114 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
resources 114. In one implementation, to provide flexible
compliance assurance, resources 114 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.
[0054] Accordingly, in one implementation, the compliance
management service may obtain information for any resource 114
managed in the information technology infrastructure 110 from the
configuration management database 185a or other databases 155 that
include a federated namespace for the managed resources 114,
configurations for the managed resources 114, and relationships
among the managed resources 114. In addition, the compliance
management service may reference the configuration management
database 185a or other the databases 155 to arbitrate configuration
management in the infrastructure 110 and record previous
configurations histories for the resources 114 in the configuration
management database 185a or other databases 155. As such, the
compliance management service may generally maintain information
relating to identities, configurations, and relationships for the
managed resources 114, which may provide a comparison context for
analyzing subsequent requests to change the infrastructure 110 and
identifying information technology services that the requested
changes may impact.
[0055] Computing and Storage Environments
[0056] In one implementation, as noted above, the technologies
integrated by the model-driven architecture 100A and the
service-oriented architecture 100B may include managing computing
and storage environments that support services in the
infrastructure 110. In particular, in one implementation, the
computing and storage environments used to support services in the
infrastructure 110 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 of physical
hardware resources 114a to support every operating system that the
vendors' customers employ without overhead that may introduced with
multiple pre-installed operating environment choices.
[0057] 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
include physical resources 114a that run over hardware to provide a
physical hosting environment for virtual machines 114b. For
example, in one implementation, the physical hardware distribution
may include the Linux kernel and various hypervisor technologies
that can run the virtual machines 114b over 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.
[0058] 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 include virtual machines 114b deployed 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 the virtual machines 114b may 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 provide configuration resources
114c for tuning virtualized resources 114b for optimized
performance.
[0059] 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 any physical resources
114a in 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 the information technology infrastructure 110. 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.
[0060] 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 resources 114 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).
[0061] 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 the event audit service 135b to 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, a scheduling system 180c may coordinate such
development, delivery, and support in a manner that permits dynamic
changes to the physical resources 114a in the infrastructure 110,
which provide stability and predictability for the infrastructure
110.
[0062] 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 clustered file system 195 illustrated in FIG.
1A, wherein such protocols may provide authorized access between
various components at any suitable layer within the storage
system.
[0063] In one implementation, the clustered file system 195 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 clustered file system 195,
wherein the various block storage devices in the clustered file
system 195 may be organized in a hierarchical stack, which may
enable the workload management system to separate the clustered
file system 195 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 from client resources
115.
[0064] In one implementation, various access protocols may provide
communication channels that enable secure physical and logical
distributions between subsystem layers in the clustered file system
195 (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 resource 115 (e.g., HTTP, NCP, AFP, NFS,
etc.) may be written to file system specific interfaces defined in
the definitive software library 190. As such, the definitive
software library 190 may provide mappings between authorization and
semantic models associated with the access protocols and similar
elements of the clustered file system 195, 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.
[0065] 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 clustered file system 195 to a local storage for a client
resource 115 that accesses the data (i.e., causing the data to
appear local despite being persistently managed in the clustered
file system 195 remotely from the client resource 115). 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, databases 155,
file systems 195, cloud storage environments, or other storage
devices.
[0066] 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 clustered file system 195 to address such
policies or compliance issues. Furthermore, identity-based
management for the data stored in the clustered file system 195 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 clustered file system 195 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 generate detailed
reports 145 for the data managed in the clustered file system.
[0067] 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 clustered file
system 195. 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 the identity vault 125 with federated policy definition
services may enable the workload management system to manage the
clustered file system 195 without synchronizing or otherwise
copying every identity with separate identity stores associated
with different storage subsystems.
[0068] Orchestrated Virtualization
[0069] In one implementation, as noted above, the technologies
integrated by the model-driven architecture 100A and the
service-oriented architecture 100B may provide orchestrated
virtualization for managing services provided in the information
technology infrastructure 110. 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
inside virtual machines 114b that decouple applications and
services from the hardware on which the virtual machines 114b have
been deployed. The workload management system may further employ a
standardized image for the virtual machines 114b, provide metadata
wrappers for encapsulating the virtual machines 114b, and provide
various tools for managing the virtual machines 114b (e.g., "zero
residue" management agents that can patch and update running
instances of virtual machines 114b stored in the clustered file
system 195, databases 155, or other repositories).
[0070] 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 of physical resources 114a in the infrastructure.
Furthermore, virtualization may be used to certify the Linux
operating environments employed in the infrastructure 110 for any
suitable platform that include various physical resources 114a. 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 to physical
resources 114a that host virtual machines 114b, while the virtual
distribution may represent any applications or services hosted on
the virtual machines 114b.
[0071] 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 the physical resources 114a that host the virtual
machines 114b. In one implementation, the physical distribution may
further include a pluggable hypervisor that enables multiple
operating systems to run concurrently over the hosting physical
resources 114a, 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 any
virtualized resources 114b that may be hosted on the physical
resources 114a. 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 underlying
physical resources 114a.
[0072] 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 resources 114, applications, service level agreements,
inventories, cost, compliance, etc.). Thus, the virtual
distribution may be neutral with respect to the physical resources
114a included 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 particular physical resources 114a and
preserve records for data that may require a specific application
running on a specific operating system.
[0073] In one implementation, from a business perspective, the
workload management system may secure the virtualized resources
114b in a similar manner as applications deployed on the physical
resources 114a. For example, the workload management system may
employ any access controls, packet filtering, or other techniques
used to secure the physical resources 114a to enforce containment
and otherwise secure the virtualized resources 114b, wherein the
virtualized resources 114b may preserve benefits provided by
running a single application on a single physical server 114a while
further enabling consolidation and fluid allocation of the physical
resources 114a. Furthermore, the workload management system may
include various information technology tools that can be used to
determine whether new physical resources 114a may be needed to
support new services, deploy new virtual machines 114b, and
establish new virtual teams that include various collaborating
entities.
[0074] In one implementation, the information technology tools may
include a trending tool that indicate maximum and minimum
utilizations for the physical resources 114a, which may indicate
when new physical resources 114a may be needed. For example,
changes to virtual teams, different types of content, changes in
visibility, or other trends for the virtualized resources 114b may
cause changes in the infrastructure 110, 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 resources 114 in the
infrastructure 110. 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 suitable virtual machine 114b. More particularly, the
compliance envelope may save a current state of the virtual machine
114b at any suitable time and then push an updated version of the
current state to the infrastructure 110, whereby the workload
management system may determine whether the current state of the
virtual machine 114b complies with any policies that may have been
defined for the virtual machine 114b. For example, the workload
management system may support deploying virtual machines 114b in
demilitarized zones, cloud computing environments, or other data
centers that may be remote from the infrastructure 110, wherein the
compliance envelope may provide a security wrapping to safely move
such virtual machines 114b and ensure that only entities with
approved identities can access the virtual machines 114b.
[0075] Thus, from an architectural perspective, the virtualized
resources 114b may enable the workload management system to manage
development and deployment for services and applications
provisioned in the infrastructure 110. For example, rather than
dynamically provisioning physical resources 114a to deal with
transient peaks in load and availability on a per-service basis,
which may result in under-utilized physical resources 114a, the
workload management system may host multiple virtual machines 114b
on one physical machine 114a to optimize utilization levels for the
physical resources 114a, which may dynamically provisioned physical
resources 114a that enable mobility for services hosted in the
virtual machines 114b. 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.
[0076] In one implementation, the workload management system may
further provide various containers to manage the virtual machines
114b, 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
various virtual machines 114b hosted on a physical resource 114a
and the hypervisor hosting the virtual machines 114b. 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 the virtual machines 114b
(e.g., one or more security labels can be assigned to any
particular virtual machine 114b to contain viruses or other
vulnerabilities within the particular virtual machine 114b).
Furthermore, in the context of tuned appliances, wherein one
virtual machine 114b hosts one service that supports one particular
application, the application container may package the service
within a particular virtual machine image 114b. As such, the
virtual machine image 114b may 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 resources 114 to provide quality of
service guarantees on a per-virtual machine 114b basis in a manner
transparent to the virtual machine kernel 114b.
[0077] In one implementation, the various containers used to manage
the virtual machines 114b may further provide predictable and
custom runtime environments for virtual machines 114b. In
particular, the workload management system may embed prioritization
schemes within portions of an operating system stack associated
with a virtual machine 114b that 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 the virtual machine 114b and build admission
control mechanisms into the operating system stack, which may
enable the workload management system to distribute loads across
different virtual machine 114b and support predictable computing.
In addition, the workload management system may decompose kernels
and operating systems for virtual machines 114b to provide custom
runtime environments. For example, in the context of a typical
virtual machine 114b, an "unprivileged guest" virtual machine 114b
may hand off processing to a "helper" virtual machine 114b at 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 particular virtual machine 114b at runtime (e.g., the dynamically
implemented operating system may represent a portable runtime that
can provide a kernel for a virtual machine 114b that hosts a
service running a server-class application, which may be customized
as a runtime environment specific to that service and
application).
[0078] 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 implement Type 1 hypervisors for
virtualized server resources 114b and Type 2 hypervisors for
virtualized workstation, desktop, or other client resources 115. In
particular, Type 1 hypervisors generally control and virtualize
underlying physical resources 114a to enable hosting guest
operating systems over the physical resources 114a (e.g., providing
coarse-level scheduling to partition the physical resources 114a in
a manner that can meet quality of service requirements for each of
the guest operating systems hosted on the physical resources 114a).
Thus, the workload management system may implement Type 1
hypervisors for virtualized server resources 114b to 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 resources 114 to guest operating systems hosted on the
hypervisor. In Type 2 hypervisor architectures, such as the VMware
GSX Server, Microsoft Virtual PC, and Linux KVM, hosted virtual
machines 114b appear as a process similar to any other hosted
process. Thus, because workstations, desktops, and other client
resources 115 may include hardware that may or may not support
virtualization, the workload management system may provide
centralized desktop management and provisioning using Type 2
hypervisors. For example, the workload management system may manage
and maintain desktop environments as virtual appliances 114b hosted
in the infrastructure 110 and then remotely deliver the desktop
environments to remote client resources 115 (e.g., in response to
authenticating an end user at a particular client resource 115, the
virtual appliance 114b carrying the appropriate desktop environment
may be delivered for hosting to the client resource 115, and the
client resource 115 may transfer persistent states for the desktop
environment to the infrastructure 110 to ensure that the client
resource 115 remains stateless).
[0079] 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 the
information technology infrastructure 110. The workload management
system may therefore provide a policy-based orchestration service
to manage virtualized resources 114b, 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 of virtual machines 114b
embedding different application-specific operating systems, wherein
the workload management system may provision and de-provision the
virtual machines 114b to meet requirements defined in the workload
(e.g., using standard image formats and metadata wrappers to
encapsulate the workloads, embed standard hypervisors in the
virtual machines 114b, 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 the infrastructure 110, the workload
management system coordinate such resources using a closed-loop
management infrastructure 170 that manages declarative policies,
fine-grained access controls, and orchestrated management and
monitoring tools.
[0080] In one implementation, the workload management system may
further manage the orchestrated data center to manage any suitable
resources 114 involved in the virtualized workloads, which may span
multiple operating systems, applications, and services deployed on
various physical resources 114a and/or virtualized resources 114b
(e.g., a physical server 114a and/or a virtualized server 114b).
Thus, the workload management system may balance resources 114 in
the information technology infrastructure 110, which may align
management of resources 114 in the orchestrated data center with
business needs or other constraints defined in the virtualized
workloads (e.g., deploying or tuning the resources 114 to reduce
costs, eliminate risks, etc.). For example, as described in further
detail above, the configuration management database 185a may
generally describe every resource 114 in the infrastructure 110,
relationships among the resources 114, and changes, incidents,
problems, known errors, and/or known solutions for managing the
resources 114 in the infrastructure 110.
[0081] As such, the policy-based orchestration service may provide
federated information indexing every asset or other resource 114 in
the infrastructure 110, 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
the infrastructure 110 and the orchestrated data center. For
example, the configuration management database 185a may model
dependencies, capacities, bandwidth constraints, interconnections,
and other information for the resources 114 in the infrastructure
110, 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, the
configuration management database 185a may include a federated
model of the infrastructure 110, wherein the information stored
therein may originate from various different sources. Thus, through
the federated model, the configuration management database 185a may
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.
[0082] In one implementation, the orchestration service may
automate workloads across various physical resources 114a and/or
virtualized resources 114b using policies that match the workloads
to suitable resources 114. For example, deploying an orchestrated
virtual machine 114b for a requested workload may include
identifying a suitable host virtual machine 114b that satisfies any
constraints defined for the workload (e.g., matching tasks to
perform in the workload to resources 114 that can perform such
tasks). In response to identifying allocating and deploying the
suitable host virtual machine 114b, deploying the orchestrated
virtual machine 114b for the workload may include the workload
management system positioning an operating system image on the host
virtual machine 114b, defining and running the orchestrated virtual
machine 114b on the chosen host virtual machine 114b, and then
monitoring, restarting, or moving the virtual machine 114b as
needed to continually satisfy the workload constraints.
[0083] 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 resources 114 provisioned for an orchestrated
workload, which the workload management system may manage as a
whole service including various different types of resources 114.
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
workload 130). 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
resources 114 in response to static or dynamic constraints, and a
capacity management sub-service that can increase or reduce
capacities for resources 114 in response to current workloads.
[0084] To provide exemplary contexts for some of the orchestration
sub-services noted above, the availability management sub-service
may automatically migrate a virtual machine 114b to another
physical host 114a in response to a service restart failing on a
current physical host 114a more 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).
[0085] In one implementation, the orchestration service may
incorporate workflow concepts to manage approval workloads 130 or
other management workloads, wherein a workload database 185b may
store information that the workload management system can use to
manage the workloads. For example, in one implementation, an
approval workload 130 may include a request to provision a
particular service to a particular user in accordance with
particular constraints, wherein the approval workload 130 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, the workload engine 180a may
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, the workload database 185b may 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.
[0086] Collaboration
[0087] In one implementation, as noted above, the technologies
integrated by the model-driven architecture 100A and the
service-oriented architecture 100B may enable collaboration between
entities that interact with the services provided in the
information technology infrastructure 110. 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 of local client
resources 115 to support cross-organizational endeavors). Thus, the
workload management system may provide a standard interface 160
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.
[0088] In one implementation, the workload management system may
provide a collaboration service that enables workloads to span
multiple users; applications, services, systems, or other resources
114. For example, multiple users may collaborate and share data and
other resources 114 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 resources 114 over
the event bus 140). 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 other suitable client resources 115
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.
[0089] 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.
[0090] 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 at client resources 115 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 the infrastructure 110 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
the infrastructure 110, 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 the infrastructure 110 and with third-parties.
[0091] 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.
[0092] Architectural Agility
[0093] In one implementation, as noted above, the technologies
integrated by the model-driven architecture 100A and the
service-oriented architecture 100B may collectively provide various
services that the workload management system can use to manage
workloads and enable intelligent choices in an information
technology infrastructure 110. Furthermore, various horizontal
integration components may be distributed in the workload
management system to integrate the various technologies employed in
the model-driven architecture 100A and the service-oriented
architecture 100B and provide an agile and interoperable
information technology infrastructure 110.
[0094] In particular, the horizontal integration components
distributed across the workload management system may provide
agility and interoperability to the information technology
infrastructure 110 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 resource 114 in the workload management system may be
provided with an application programming interface 160 that can
provide connectivity between different operating systems,
programming languages, graphical user interface toolkits, or other
suitable services, applications, or resources 114.
[0095] In one implementation, the application programming interface
160 may include a Representational State Transfer (REST)
application program interface 160, 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, the REST interface 160 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, the REST interface 160 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, the REST interface 160 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 resource 114 may programmatically discover other
identities that communicate using the REST interface 160 (e.g., the
REST interface 160 may be implemented in a communication gateway
112a to physical resources 114a, a communication gateway 112b to
virtualized resources 114a, a communication gateway 112c to
configuration resources 114c, etc.).
[0096] Furthermore, in one implementation, the workload management
system may extend an application program interface stack for the
supplied REST interface 160, which may enable new services,
applications, and other resources 114 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 the REST
interface 160 regardless of whether the services reside in the
infrastructure 110, 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
the REST interface 160, a Recipe-based Development Kit (RDK) may
provide full source code examples for various operating systems,
programming languages, and graphical user interface toolkits.
[0097] Additionally, in one implementation, the workload engine
180a may manage creation of application program interface keys for
the REST interface 160 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 to client desktops 115, wherein the widget may track
identities and contexts that include attempts to access the REST
interface 160 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 the information technology
infrastructure 110.
[0098] Thus, the standardized stack supplied for the REST
application program interface 160 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 REST
application program interface 160 may enable integration with any
suitable existing or future-developed system. For example, in one
implementation, the REST interface 160 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 resource
114, a user may simply enter a URI for the resource 114 in an
existing web browser feed aggregator (e.g., Firefox bookmarks).
Thus, by providing extensible support for any suitable system,
application, service, or other resources 114, the features of the
REST application program interface 160 may provide agility and
interoperability to the infrastructure 110.
[0099] Having described the model-driven and service-oriented
architecture 100A-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.
[0100] According to one aspect of the invention, FIG. 2 illustrates
an exemplary method 200 for intelligent workload management. In
particular, the intelligent workload management method 200 may be
used to manage approval workloads created in response to service
requests. In particular, an operation 210 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.).
[0101] 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 in
operation 210 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, an operation 220 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.
[0102] In one implementation, the model of the computing resources
obtained in operation 220 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.
[0103] In one implementation, the model of the storage resources
obtained in operation 220 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.
[0104] In one implementation, the model of the computing resources
and the storage resources obtained in operation 220 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.
[0105] In one implementation, in response to querying the
configuration management database in operation 220 to obtain the
current model of the infrastructure, an operation 225 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.
[0106] Thus, in response to the workload management system
determining in operation 225 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 an
operation 230. 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.
[0107] On the other hand, in response to determining in operation
225 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 an operation 235. 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, wherein operation 235 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 in operation 235
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).
[0108] 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 an operation 240. In
particular, operation 240 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 operation 240 (e.g., because the service
cannot be provisioned until a certain process has completed, a
certain entity provides feedback, etc.). As such, operation 240 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.
[0109] 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 in operation 240,
the workload management system may provision the requested service
in an operation 250. In particular, operation 250 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.
[0110] Thus, in one implementation, operation 250 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, operation 250 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.
[0111] In one implementation, in response to successfully
provisioning the service in operation 250, the workload management
system may update the infrastructure model in an operation 260. 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, an operation 270 may include
the workload management system sending a service provisioning
notification to the requesting entity, wherein the notification
sent in operation 270 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.
[0112] In one implementation, the workload management system may
manage the provisioned service in an operation 280 in response to
successfully provisioning the service in operation 250. In
particular, as noted above, updating the infrastructure model in
operation 260 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 in operation 280 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.).
[0113] 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, operation 280 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,
operation 280 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.
[0114] Thus, the techniques described above the intelligent
workload management method 200 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.
[0115] According to one aspect of the invention, FIG. 3 illustrates
an exemplary block diagram of a system 300 for generating single
sign-on workload identities, while FIG. 4 illustrates an exemplary
flow diagram of a method 400 that may operate in the system 300 for
generating single sign-on workload identities. Thus, the
description to be provided herein for FIG. 3 or FIG. 4 will be
understood as corresponding to techniques that can be performed in
the system 300 shown in FIG. 3 or the method 400 shown in FIG. 4,
whether or not explicitly described.
[0116] 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 a client device 315 may generally
maintain various authentication credentials for any identities
managed locally to the operating system, or the operating system
may contact an authentication server 320 to obtain authentication
credentials for any single sign-on identities that the operating
system does not locally manage. In one implementation, the
authentication server 320 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.
[0117] 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 a workload
engine 380 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 server 320 (e.g., Novell Access Manager) may
communicate with an identity vault 325 that organizes user
accounts, roles, policies, and other identity information within
various directories. Thus, as shown by communication element 1 in
FIG. 3 (or operation 410 in FIG. 4), any suitable entity may submit
an authentication request to the authentication server 320, wherein
the authentication request may include single sign-on
authentication credentials (e.g., a user name, identifier,
password, smart card input, biometric input, etc.).
[0118] In one implementation, communication element 2 may then
include the authentication server retrieving the authentication
credentials for the requesting entity from the federated identity
information stored in the identity vault 325. In an operation 420
(and communication element 3), the authentication server may then
generate an authentication token for the requesting entity from the
authentication credentials retrieved from the identity vault 325,
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 by communication element 4 in FIG. 3, the
authentication token may be returned to the client device 315 that
originated the request, whereby any operating systems,
applications, services or other resources on the client device 315
that require authentication credentials may use the authentication
token to authenticate or deny local requests received from the
entity associated with the authorization token.
[0119] In one implementation, the workload management system may
include a workload engine 380 that can use authentication tokens
generated by the authentication server 320 to manage workloads that
include service requests. Furthermore, the workload engine 380 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 operation 430 (or communication
element 5) may include receiving a workload that defines a
particular service requested by the entity operating the client
device 315, wherein the entity may specify various additional
entities that may need access to the requested service. As such, an
operation 440 (or communication element 6) may include the workload
engine 380 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 operation 440 (and communication
element 6) 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.).
[0120] In one implementation, an operation 450 may then include the
workload engine 380 analyzing the authentication tokens obtained
from the authentication server 320 to identify any authentication
credentials that the authentication tokens represent. As such, the
workload engine 380 may reference the identified authentication
credentials in an operation 460 to determine whether the identities
for the requesting entity (and/or the additional entities) have
proper authorization for the requested service. The workload engine
380 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., the client machine 315, other services or
applications running on the client machine 315, 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 the
authentication server 320 indicate that one or more of the
identities involved in the workload lack proper authorization, an
operation 470 (or communication element 7) may include the workload
engine 380 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 operation 480 (or communication element 7) may include notifying
the requesting entity that the service request has been approved
and subsequently provisioning the requested service.
[0121] Moreover, in response to approving the service request in
operation 460, operation 480 may further include embedding the
authentication tokens obtained in operation 440 (and communication
element 6) 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, operation
480 may further include the workload engine 380 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 the authentication
server 380. 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.
[0122] Thus, as described in further detail above with reference to
FIG. 1A-B, authentication tokens generated at the single sign-on
authentication server 380 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.
[0123] According to one aspect of the invention, FIG. 5A
illustrates a block diagram of an exemplary service distribution
500A that can be managed with one or more zero residue management
agents 580 in the workload management system, while FIG. 5B
illustrates an exemplary lifecycle 500B for the service
distribution 500A managed with the zero residue management agents
580. In particular, as shown in FIG. 5A, the workload management
system may use various orchestrated virtualization services to
create and manage a partitioned operating environment for the
service distribution 500A, 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 the service
distribution 500A, which may provide control over whether to
execute certain portions of the service distribution 500A 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 the
service distribution 500A 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 the service distribution 500A.
[0124] In one implementation, the physical distribution layer in
the service distribution 500A 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
minimal functional kernel 550 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 a pluggable
hypervisor 560, which may enable the service distribution 500A to
concurrently run various different operating systems 520 over the
hosting physical hardware, and minimal core packages 570 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 an injection point 580 for dynamically inserting and
removing one or more zero residue management agents that can manage
the lifecycle 500B for the service distribution 500A.
[0125] In one implementation, the virtual distribution layer in the
service distribution 500A may provide a tuned appliance, which the
physical distribution layer executes over any underlying physical
hardware that hosts the service distribution 500A. In particular,
the virtual distribution layer may include a storage pointer 510
that identifies one or more local or remote storage locations
allocated to contain a persistent state for the service
distribution 500A (e.g., within a clustered file system organized
with storage replication and version management services), in
addition to an operating system 520 that includes a minimal number
of packages, patterns, or other software components needed to
support any applications 530 in the tuned appliance (e.g., the
operating system 520 may include "just enough operating system"
(JeOS) 520 to support the applications 530 provided in the service
distribution 500A). In addition, the virtual distribution layer may
include one or more configurations 540 that can be used to
configure the storage pointer 510, the operating system 520, and/or
the applications 530 in the virtual distribution layer, wherein the
configurations 540 may define a workload profile for the service
distribution 500A. 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 the service distribution 500A.
[0126] 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 zero residue managements
580 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 zero residue management agents 580 may be
dynamically deployed within the service distribution 500A to manage
various different modes during the lifecycle 500B of the service
distribution 500A. For example, in response to initially creating
the service distribution 500A, the lifecycle 500B of the service
distribution 500A may enter the creation mode, wherein a creation
management agent 580 may execute a bootstrap process to advertise
that the service distribution 500A exists and appropriately
download any additional management agents 580 to manage the
different modes of the lifecycle 500B for the service distribution
500A.
[0127] For example, in one implementation, in response to the
lifecycle 500B 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 the management agents 580
may be identified based on a current mode in the lifecycle 5008 and
dynamically inserted into the service distribution 500A. In another
example, authentication tokens generated using the techniques shown
in FIGS. 3 and 4 and described above may be embedded within the
service distribution 500A, wherein the relevant management agents
580 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 a particular service distribution 500A
that the user interacts with, the particular service distribution
500A may be located by searching for an service distributions 500A
having an embedded authentication token associated with the user,
and an appropriate management agent 580 may then be deployed to the
particular service distribution 500A having the embedded
authentication token to diagnose or otherwise provide assistance in
resolving the problem with the distribution 500A).
[0128] In one implementation, the identified management agent 580
may then perform any management tasks associated with the current
lifecycle mode, and in response to completing the management tasks,
the management agent 580 may then be removed from the service
distribution 500A. In one implementation, removing the management
agent 580 from the service distribution 500A may generally include
removing any runtime state associated with the management agent 580
and rolling back any changes that the management agent 580 applied
to the service distribution 500A in order to perform the management
tasks. For example, a test management agent 580 that executes
during the test mode may disable a YaST configuration tool 540 that
otherwise controls installation and system management for the
virtual distribution layer operating environment, whereby rolling
back the changes applied to the service distribution 500A may
include re-enabling the YaST configuration tool in response to the
test management agent 580 completing the management tasks for the
test mode. In another example, a patch management agent 580 may be
inserted into the service distribution 500A to patch or otherwise
update any suitable component in the service distribution 500A
during the maintenance mode, wherein runtime states and temporary
changes applied by the patch management agent 580 may be removed
from the service distribution 500A with the patch management agent
580 in response to the maintenance mode completing.
[0129] Thus, removing the runtime state associated with the
management agents 580 and any temporary changes that the management
agents 580 applies to the service distribution 500A during the
various lifecycle modes may ensure that the service distribution
500A has been restored to a "golden" or "pristine" state prior to
entering a next lifecycle mode. In particular, the zero residue
management agents 580 may be dynamically inserted into the service
distribution 500A to execute appropriate management tasks for a
current lifecycle mode, and then appropriately removed in a manner
that leaves the service distribution 500A unmodified except for any
persistent changes that the management tasks apply to the service
distribution 500A. For example, during the maintenance mode, a
configuration management agent 580 may be inserted into the service
distribution 500A to modify the storage pointer 510 to point to a
new local or remote storage location in response to an original
storage location allocated to the service distribution 500A failing
or running short on available storage resources, whereby the
service distribution 500A may be unchanged except for the modified
storage pointer 510. In another example, a tuning management agent
580 may be similarly inserted into the service distribution 500A
during the maintenance mode to independently apply any upgrades or
other modifications that can tune functionality for the service
distribution 500A (e.g., the tuning management agent 580 may
upgrade the kernel 550 and device drivers in the physical
distribution layer independently from security patches applied to
the operating system 520 or applications 530 in the virtual
distribution layer, and in response to completing the upgrades, the
service distribution 500A may optionally be re-released to ensure
that subsequent versions of the service distribution 500A
automatically include the upgrades to the kernel 550 and device
drivers and the patches applied to the operating system 520 or
applications 530).
[0130] In one implementation, one or more policies may define the
management agents 580 inserted into the service distribution 500A
during the various modes of the lifecycle 500B. For example, a
required service level defined in the workload profile 540 may
define a recipe for one or more of the management agents 580 to
inject into the service distribution 500A to ensure that the
service distribution 500A meets or exceeds the required service
level (e.g., a configuration management agent 580 may modify the
storage pointer 510 to ensure the service distribution 500A has
sufficient storage capacity, a tuning management agent 580 may
modify the hypervisor 560 to prepare the service distribution 500A
for migration to different physical host resources that provide
greater availability or performance, etc.). In other examples, the
recipe for the management agents 580 may be determined
automatically (e.g., based on the current mode), based on the
applications 530 hosted in the service distribution 500A and any
management that may be needed for such applications 530, or other
suitable criteria. Further, in one implementation, one or more of
the management agents 580 may be persistently hosted in the service
distribution 500A to capture activity and events that may be
relevant to ensuring and auditing compliance with policies, while
one or more policies may control whether the service distribution
500A can move from one lifecycle mode to another (e.g., the
policies may restrict moving the service distribution 500A from the
creation mode to the release mode until the workload management
system can ensure that the service distribution 500A meets certain
sanity, safety, or policy constraints).
[0131] Thus, as described in further detail above, the zero residue
management agents 580 may provide control for various different
modes that occur during the lifecycle 500B of the service
distribution 500A, including a creation mode for initially creating
the service distribution 500A from one or more images stored in a
suitable repository, a release mode for delivering the service
distribution 500A to suitable entities that will interact with or
host the service distribution 500A, a production mode for deploying
the service distribution 500A to such entities, a test mode for
validating that the service distribution 500A functions correctly,
a maintenance mode for debugging, patching, or otherwise updating
the service distribution 500A, an optional re-release mode for
delivering subsequent versions of the service distribution 500A
with any changes applied during the production, test, or
maintenance modes, and an eventual retirement mode for
de-provisioning any existing versions of the service distribution
500A in response to the service distribution 500A becoming outdated
or obsolete.
[0132] According to one aspect of the invention, FIG. 6 illustrates
a flow diagram of an exemplary method 600 for managing different
modes of a service distribution lifecycle with zero residue
management agents. In particular, the zero residue management
agents shown in FIG. 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 an operation 610, wherein a management workload may be
launched to manage the service distribution lifecycle. In
particular, an operation 620 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 an operation 630. 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 an operation 640. For example, a
monitoring management agent may be executed in operation 630 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).
[0133] As such, the management agents executed during operation 630
may add, remove, or disable aspects of the service distribution,
wherein the management tasks executed during operation 630 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, operation 640 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 during operation 630 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 in
operation 640, the management agent executed during operation 630
may then be removed from the service distribution in an operation
650, and a pristine or golden state for the service distribution
may then be restored in an operation 660. For example, in one
implementation, restoring the state for the service distribution
may include removing any runtime state associated with the
management agent executed during operation 630 and rolling back any
temporary changes that the management agent applied to the service
distribution during operation 630.
[0134] Thus, in response to restoring the state for the service
distribution in operation 660, 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 operation 630).
In particular, an operation 670 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 an
operation 680. For example, retiring the service distribution in
operation 680 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 to operation 670 determining that the service
distribution will not be retiring, the method 600 may return to
operation 620 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, the method 600 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 in
operation 680.
[0135] According to one aspect of the invention, FIG. 7 illustrates
a block diagram of an exemplary system 700 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, the system 700
shown in FIG. 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, the system 700 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) 790a that may be external to an
information technology infrastructure, and which can further be
deployed to a private cloud (or virtualized data center) 790b that
may be local to the infrastructure. In addition, the system 700 may
be used to install software contained in licensed software
repositories 710a, source code repositories 710b, or other suitable
software sources onto any images that have been deployed to the
public cloud 790a or the private cloud 790b, control and audit
activity that occurs in the images deployed to the public cloud
790a or the private cloud 790b, 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 the public cloud 790a or the
private cloud 790b may have on other machines or images.
[0136] As such, the system 700 shown in FIG. 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 the public cloud 790a and/or
the private cloud 790b. In particular, in one implementation, the
system 700 may include a licensed software repository 710a that
contains licensed software, a source code repository 710b that
contains software source code, or any other suitable software
repository. In one implementation, the licensed software in the
licensed software repository 710a, the software source code in the
source code repository 710b, or other software may then installed
over suitable hardware resources to create one or more hardware
installations 720a, installed on a virtual machine to create one or
more virtual machine installations 720b, and/or built within a
suitable build system to create one or more auto build
installations 720c. In one implementation, in response to
installing or otherwise creating the hardware installations 720a,
the virtual machine installations 720b, and the auto build
installations 720c, an appropriate management agent 725 may be
inserted into the installation 720. In particular, the management
agent 725 may provide functionality for performing various tasks to
manage the licensed software, source code, or other software
included in the installations 720. For example, in one
implementation, the tasks performed by the management agents 725
may include retrieving DHCP addresses, establishing static IP
addresses, providing remote debugging assistance, and inserting one
or more personality tools 775 (e.g., privileged user management)
for the installations 720.
[0137] In one implementation, the hardware installations 720a,
virtual machine installations 720b, and auto build installations
720c may each further include a respective identity service 727
that provides a unique identity for the respective installations
720. For example, in one implementation, the identity services 727
may generally include authentication tokens that define one or more
federated authorizations or permissions for the respective
installations 720 (e.g., across a plurality of authentication
domains), as described in further detail above. As such, the
management agents 725 inserted into the various software
installations 720 may interact with the identity services 727 that
define the authorizations or permissions for the various software
installations 720 to uniquely identify and manage the various
installations 720. For example, in addition to defining the
authorizations or permissions for the various installations 720,
the identity services 727 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 licensed
software repository 710a or the source code repository 710b, the
integrated identity services 727 may be referenced to identify and
appropriately update any installations 720 that may have been
created from the updated software).
[0138] In one implementation, in response to creating the various
software installations 720 and embedding the suitable management
agents 725a and identity services 727, various operational images
may be created from the software installations 720. In particular,
the virtual machine installations 720b and the auto build
installations 720c may generally include one or more virtual
machine images, as described in further detail above, while the
hardware installations 720a may generally include software that
executes directly over underlying hardware resources. The
operational images created from the virtual machine installations
720b and the auto build installations 720c may therefore include
the virtual machine images included therein, wherein the
operational virtual machine images may be provided to an image
management system 740 that stores the operational virtual machine
images in a shared repository 750a (e.g., an image repository).
With respect to the hardware installations 720a that include
software executing directly over underlying hardware resources
rather than virtual machine images, a migration system 730 may
provide functionality that can create a suitable operational
virtual machine image from the hardware installations 720a. The
migration system 730 may evaluate any licensed software, source
code, packages, or other software included in the hardware
installations 720a and create operational virtual machine images
that can run in a virtualized environment. For example, in one
implementation, the migration system 730 may include a Novell
PlateSpin Migrate system 730, a VMware vCenter Converter system
730, or any other suitable migration system 730 that provides
conversion or migration services between physical and virtual
platforms. The operational virtual machine image created from the
hardware installation 720a may then be provided to the image
management system 740, which may store the operational virtual
machine image in the shared repository 750a in a similar manner as
the virtual machine installations 720b and the auto build
installations 720c.
[0139] In one implementation, in response to providing the
operational images created from the hardware installations 720a,
the virtual machine installations 720b, and the auto build
installations 720c to the image management system 740, the image
management system 740 may automatically store the operational
images in the shared repository 750a in 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, the
image management system 740 may optionally invoke a testing engine
745a that performs one or more operational integrity tests for the
operational images prior to storing the operational images in the
shared repository 750a. For example, the operational integrity
tests performed by the testing engine 745a may 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 the testing engine 745a
determining that one or more of the operational images have passed
the operational integrity tests, such operational images may be
released to the shared repository 750a. Alternatively, in response
to the testing engine 745a determining that one or more of the
operational images did not pass the operational integrity tests,
the image management system 740 may invoke a validation engine 740
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). The validation
engine 745b may then re-invoke the testing engine 745a to 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 shared repository 750a in response to passing the
integrity tests or prevented from such release in response to not
passing the integrity tests.
[0140] In one implementation, the system 700 may further include a
discovery engine 760 that continually monitors the shared
repository 750a to detect whether one or more operational images
have been newly added to the shared repository 750a. Further, in
one implementation, the image management system 740, the shared
repository 750a, or another suitable component in the system 700
may generate an event in response to one or more operational images
being added to the shared repository 750a, wherein the event may
notify or otherwise advertise the new operational images to the
discovery engine 760. In one implementation, in response to the
discovery engine 760 detecting the new operational images in the
shared repository 750a or receiving the event notifying or
advertising the new operational images in the shared repository
750a, the discovery engine 760 may prepare the operational images
for deployment to the public cloud 790a or the private cloud 790b.
In particular, various public clouds 790a and private clouds 790b
may support different image formats, wherein the discovery engine
760 may convert the operational images into the appropriate image
format for the public cloud 790a or private cloud 790b where the
operational images will be deployed (e.g., an Amazon Machine Image
format for the Amazon Elastic Compute Cloud). Thus, the cloud image
repository 750b may contain various cloud images created from the
operational images in the shared repository 750a, wherein the
various cloud images may be in various different formats depending
on the image format for the public cloud 790a or private cloud 790b
that will host the cloud images.
[0141] In one implementation, in response to storing the cloud
images in the cloud image repository 750b, an image deployment
system 770 may be invoked to deploy the cloud images to the
appropriate public cloud 790a or private cloud 790b. In one
implementation, prior to deploying the cloud images to the
appropriate public cloud 790a or private cloud 790b, the image
deployment system 770 may invoke an impact analysis engine 780 that
determines a potential impact of deploying the cloud images to the
public cloud 790a or private cloud 790b. In particular, deploying
the cloud images to the public cloud 790a or private cloud 790b may
generally include various deployment processes (e.g., starting,
stopping, cloning, or migrating the cloud images). Thus, the impact
analysis engine 770 may reference a configuration management
database 785 to validate whether the cloud images can be suitably
deployed to the public cloud 790a or the private cloud 790b. For
example, the impact analysis engine 770 may reference the
configuration management database 785 to verify that other
resources detailed in the configuration management database 785
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 770 may communicate with an audit service 795, a privileged
user management service 792, or other monitoring services provided
in the public cloud 790a or the private cloud 790b to enhance the
impact analysis (e.g., determining whether conditions in the public
cloud 790a or private cloud 790b may have adverse impacts on the
deployment, local infrastructure resources, etc.).
[0142] In one implementation, in response to the impact analysis
engine 770 determining that deploying the cloud images does not
raise potential adverse impacts, or alternatively in response to
resolving any such potential adverse impacts, the image deployment
system 770 may deploy the cloud images in the cloud image
repository 750b to the appropriate public cloud 790a or private
cloud 790b. Further, in one implementation, the operational images
in the shared repository 750a may already be appropriate for
deployment into the public cloud 790a or private cloud 790b without
requiring conversion to a cloud image format, in which case the
image deployment system 770 may similarly deploy the operational
images in the shared repository 750a to the public cloud 790a or
private cloud 790b. In one implementation, to deploy the cloud
images or operational images to the public cloud 790a or private
cloud 790b, the image deployment system 770 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, the image deployment system
770 may inject a new or aggregated identity service 777 into the
cloned or modified images, wherein the new or aggregated identity
service 777 may provide a record that identifies a lineage,
pedigree, or other relationships for the cloned or modified images.
Furthermore, the image deployment system 770 may inject one or more
personality tools 775 into the cloned or modified images in
response to determining that the personality tools 775 have not
already been injected (e.g., during creation of the original
software installations 720). For example, as noted above, the
personality tools 775 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).
[0143] In one implementation, the image deployment system 770 may
then deploy the cloud images or the operational images to the
appropriate public cloud 790a or private cloud 790b, wherein the
deployed images may be managed in the public cloud 790a and the
private cloud 790b. For example, as noted above, the images may
include embedded management agents 725 that can control and track
any activity associated with the deployed images through
interaction with the embedded identity services 727, 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 agents 725, identity services 727 (and/or 777), and
personality tools 775 embedded in the images can control, track,
and monitor activities for the images that have been deployed to
the public cloud 790a and the private cloud 790b, the monitored
activity may be provided to an audit service 795 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 the public cloud 790a or the private cloud 790b.
Similarly, the embedded identity services 727 (and/or 777) may
interact with a privileged user management service 792 in the
public cloud 790a or the private cloud 790b, wherein the privileged
user management service 792 and the audit service 795 may cooperate
in various ways to remediate, assure compliance, or otherwise
analyze the activity that occurs in the images following deployment
to the public cloud 790a or the private cloud 790b.
[0144] According to one aspect of the invention, FIG. 8 illustrates
a flow diagram of an exemplary method 800 for controlling cloud and
virtualized data centers in the intelligent workload management
system. In particular, the method 800 may generally operate in the
system 700 shown in FIG. 7 and described in further detail above,
whereby the method 800 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 with FIG. 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.
[0145] In particular, in one implementation, the method 800 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 an operation 810
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 in operation 810
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 in operation 810, an appropriate
management agent may then be embedded in the software installation
in an operation 820. For example, the management agent embedded in
the software installation in operation 820 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.).
[0146] In one implementation, operation 820 may further include
embedding an identity service within the software installation
created in operation 810. 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 in operation 820 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.
[0147] 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, an operation 825 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 in operation
825, 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 an operation
830 may include creating a virtual machine from the hardware
installation to prepare the hardware installation for migration to
a virtualized environment. In particular, operation 830 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.
[0148] In one implementation, in response to providing the
operational image created from the software installation to the
image management system, an operation 835 may include determining
whether or not to test the operational images for operational
integrity. For example, an operation 860 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, an operation 840 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 in operation 840, 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, an operation 845
may include determining whether the operational image passed the
operational integrity tests, wherein the operational image may be
released to the shared repository in operation 860 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 in operation 845, a validation engine
may be invoked in an operation 850, 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 then re-invoke
operation 840 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 in
operation 860 in response to passing the integrity tests, whereas
the operational image may be iteratively debugged and revalidated
in operations 840 through 850 until the operational image
successfully passes the integrity tests.
[0149] 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, an operation
870 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, wherein operation 870 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 in
operation 870 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 in operation 870.
[0150] In one implementation, in response to generating the cloud
image in operation 870, 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, an
operation 875a may 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 in operation 875a may 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 an operation 875b, the image
may be revalidated in operation 850, or operation 850 may include
other processes to resolve the adverse impacts.
[0151] In one implementation, in response to determining that
deploying the cloud image does not raise potential adverse impacts
in operation 875b, or alternatively in response to resolving any
such potential adverse impacts, an operation 880 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 in operation 860 may already
be appropriate for deployment into the public cloud or private
cloud without requiring conversion to a cloud image format in
operation 870, in which case operation 880 may include similarly
deploying the operational image stored in operation 860 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, operation 880 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 operation 880). As such, in response to cloning or
modifying the image prior to the cloud deployment, operation 880
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, operation 880 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 in operations 810 and 820). 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).
[0152] In one implementation, operation 880 may then include
deploying the cloud image or the operational image to the
appropriate public cloud or private cloud, wherein operation 880
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, operation 880 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.
[0153] 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.
[0154] 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.
* * * * *