Take a sneak peek at the new NIST.gov and let us know what you think!
(Please note: some content may not be complete on the beta site.).
6.1 Cloud Management Broker
Actors: cloud-subscriber, cloud-user, cloud-provider-1…cloud-provider-n, cloud-management-broker
Goals: Provide a cloud-user a unified and enhanced management interface to multiple cloud-providers. The essential features of a cloud-management-broker are a unified interface, federated cloud-subscriber credentials for multiple cloud-providers and federated access to multiple cloud-provider programming interfaces.
Assumptions: Cloud-management-broker services can be delivered in many forms, including as a standalone service, or a set of capabilities within a cloud-provider. In cases where a cloud-provider business entity also functions as a cloud-management-broker, its cloud-management-broker aspect is regarded as an entirely separate use case actor. Cloud-management-broker services can be also executed by agency custom code. The modal case is assumed to be a third-party service provider independent of and capable of addressing multiple cloud-providers.
Success Scenario 1 (generic base, IaaS, PaaS, SaaS): A cloud-user wishes to carry out an action on cloud-provider-1 using a federated interface, with no direct knowledge of cloud-provider-1 commands or interfaces. A cloud-management-broker offers the cloud-user a federated interface to multiple cloud-providers through a human user interface, an application programming interface or both. The cloud-user selects desired cloud-provider-1 resources, action and action parameters using the cloud-management-broker interface. The cloud-management-broker collects and marshals the selected action and parameters from the cloud-user's selection and issues the desired command to cloud-provider-1 using cloud-provider-1 native interface.
Failure Conditions 1: (1) The cloud-user command fails at the cloud-management-broker because of mis-configuration or incorrect cloud-management-broker operation; (2) The cloud-user command fails at the target cloud-provider due to improper API call or incorrect cloud-provider operation.
Failure Handling 1: Cloud-management-broker notifies cloud-user of event with diagnostic information and offers retry opportunity. Cloud-management-broker notifies its own operational staff and monitoring services to update its own and cloud-provider availability information.
Note that the base scenario failure conditions and handling apply to all scenarios in this use case.
Success Scenario 2 (extended management case – Open An Account, IaaS, PaaS, SaaS): A cloud-subscriber has opened an account with a cloud-provider-1 as detailed in the extended management use case and now wishes to manage cloud-provider-1 using the cloud-management-broker. The cloud-user registers the cloud-provider-1 account with the cloud-management-broker programming or human interface, and provides sufficient cloud-provider-1 credentials for the cloud-management-broker to address the cloud-provider-1 native interface. The cloud-subscriber may optionally enter descriptive information, spending or other usage limits and metrics to the cloud-management-broker to place management limitations on cloud-provider-1 usage. The cloud-management-broker uses cloud-provider-1's native interface to validate account and credential information, notifies the cloud-subscriber and includes cloud-provider-1 in its action and metrics interfaces.
Failure Conditions 2 (Base Plus): The cloud-provider-1 credentials provided by the cloud-user are rejected by cloud-provider-1.
Failure Handling 2 (Base Plus): Cloud-management-broker notifies cloud-user of event with diagnostic information and offers opportunity to retry or replace credentials.
Success Scenario 3 (manage-cloud-user, IaaS, PaaS, SaaS). A cloud-subscriber has registered a cloud-provider-1 account with a cloud-management-broker and wishes to selectively grant and manage their cloud-users access to cloud-provider-1 information, resources and operations. The cloud-subscriber uses the cloud-management-broker interface to define cloud-users and aggregate groupings of cloud-users with related resource utilization limits. The cloud-subscriber uses the cloud–management-broker interface to selectively grant the appropriate cloud-users access to specified cloud-provider-1 information, resources and operations by means of a cloud-management-broker access control framework. The cloud-user authenticates with the cloud-management-broker, accesses an interface presenting permitted information, operations and resources for cloud-provider-1, and executes tasks within their scope of permission. The cloud-management-broker tracks and reports on cloud-provider-1 resource utilization for users and aggregates of users, effectively multiplexing the cloud-subscriber account over multiple cloud-users.
Failure Conditions 3 (Base Plus): Cloud-management-broker is unable to access cloud-provider-1 utilization information for a period of time.
Failure Handling 3 (Base Plus): Cloud-management-broker notifies cloud-user of event with diagnostic information detailing the period of utilization information outage.
Success Scenario 4 (included management case – Close an Account, IaaS, PaaS, SaaS): A cloud –subscriber has previously registered a cloud-provider-1 account with cloud-management-broker as detailed in Success Scenario 2 (extended management case – "Open An Account") and now wishes to close the account with cloud-provider-1. The cloud-subscriber uses the cloud-management-broker interface to issue cloud-provider-1 a close account command. The cloud-management-broker accesses cloud-provider-1 using cloud-subscriber credentials, marshals parameters from the cloud-subscriber, and issues cloud-provider-1 commands implementing the management use case "Close An Account". The cloud-management-broker delivers cloud-subscriber all consequent cloud-provider-1 messages including non-repudiation information.
Failure Conditions 4 (Base Plus): Cloud-provider-1 does not offer an account close interface.
Failure Handling 4 (Base Plus): Cloud-management-broker does not make close account command available to cloud-user.
Success Scenario 5 (included management case – Terminate an Account, IaaS, PaaS, SaaS): A cloud–subscriber has previously registered a cloud-provider-1 account with cloud-management-broker as detailed in Success Scenario 2 (extended management case – "Open An Account"). Cloud-provider-1 now wishes to terminate an account as detailed in included management Use case "Terminate an Account." The cloud-management-broker regularly polls all registered cloud-providers for status events, detects the account freeze or termination notification per included management use case and conveys the notification to the cloud-subscriber through the cloud-management-broker interface. The cloud-subscriber optionally communicates directly with cloud-provider-1 to reinstate the terminated account if desired.
Failure Conditions 5 (Base Plus): The cloud-provider-1 freeze or notification is not provided by cloud-provider-1 programming interface and is not seen by cloud-management-broker.
Failure Handling 5 (Base Plus): Cloud-subscriber receives cloud-provider-1 freeze or termination notification directly from cloud-provider-1 and proceeds per included management case.
Success Scenario 6 (included management cases – Copy Data Objects into a Cloud/Network , Copy Data Objects out of a Cloud/Network to Cloud User, Erase Data Objects In a Cloud, IaaS): A cloud-user wishes to copy data objects into, out of, or erase objects on a cloud-provider-1 cloud as detailed in the included management cases. The cloud-user accesses a cloud-management-broker interface to view their cloud-provider-1 storage structures and issues cloud-management-broker commands to copy data objects into cloud-provider-1, copy out of cloud-provider-1 or erase objects from cloud-provider-1. The cloud-management-broker uses cloud-provider-1's native interface to issue commands to effect the operation specified in the included use case and notifies cloud-user of the result. Note that the "copy" management scenarios for unidentified users or transport-agent data transfer are not covered by the cloud-management-broker, as unauthenticated access and physical transport are inappropriate for brokerage.
Failure Conditions 6 (Base Plus): No conditions for scenario beyond base
Failure Handling 6 (Base Plus): TBD
Success Scenario 7 (included management cases VM Control: Allocate VM Instance, VM Control: Manage Virtual Machine Instance, IaaS): A cloud-user wishes to allocate or manage virtual machine instances as detailed in the included management cases. The cloud-user accesses a cloud-management-broker interface to view cloud-provider-1 virtual machine images and instances, and issues cloud-management-broker commands to allocate or manage selected instances as specified in the included use case. The cloud-management-broker uses cloud-provider-1's native interface to issue commands to effect the operation specified in the included use case and notifies cloud-user of the result.
Failure Conditions 7 (Base Plus): No conditions for scenario beyond base.
Failure Handling 7 (Base Plus): TBD
Success Scenario 8 (included management case Monitor Infrastructure [DOES NOT EXIST IN MGT SECTION YET], IaaS): A cloud-user wishes to monitor and respond to changes in infrastructure services provided by cloud-provider-1. Cloud-provider-1 is previously registered by cloud-subscriber with the cloud-management-broker per Success Scenario 2 (extended management case – Open An Account). Cloud-user has sufficient permissions to set thresholds, view reports and receive alerts per Success Scenario 3 (manage-cloud-user). The cloud-management-broker assembles cloud-provider-1 performance and availability information using native cloud-provider-1 interfaces, and aggregates the information in its internal reporting and alerting framework. The cloud-user uses the cloud-management-broker's interface to set alerting thresholds on cloud-provider-1 infrastructure components, view reports on cloud-provider-1 infrastructure component performance and availability, and receive alerts on cloud-provider-1 infrastructure components when performance triggers the alerting thresholds.
Failure Conditions 8 (Base Plus): (1) Cloud-management-broker is unable to access cloud-provider-1 monitoring information for a period of time; (2) Cloud-management-broker's internal monitoring processes are unavailable for a period of time
Failure Handling 8 (Base Plus): (1) The cloud-management-broker treats unavailable cloud-provider-1 monitoring information as an alert and transmitted to cloud-users registered for alerts on cloud-provider-1; (2) Unavailable cloud-management-broker monitoring services are treated as an alert and transmitted to cloud-subscriber and cloud-users registered for alerts, either through cloud-management-broker alerting system if functional, by email if alerting is not functional, or after the fact if entire cloud-management-broker is inoperative.
Success Scenario 9: (Migrate Data Objects Between Clouds, IaaS): A cloud-user wishes copy or move a data object from cloud-provider-1 to cloud-provider-2. The cloud-user accesses a cloud-management-broker interface to access both cloud-provider-1 and cloud-provider-2 data objects and containers in order to select source data objects from cloud-provider-1, destination data objects from cloud-provider-2 and the desired mode of migration. The copy mode leaves the source object intact after migration; the move operation provides transactional erasure of the source object. For each selected cloud-provider-1 data object, the cloud-management-broker uses cloud-provider-1's native interface to issue commands to access the object, and cloud-provider-2's native interface to create a new object with identical content in the location indicated in the copy or move command, verifies the integrity of the new object, and notifies cloud-user of the result. In the move mode the cloud-management-broker then issues a native cloud-provider-1 command to erase the source object.
Failure Conditions 9 (Base Plus): (1) A namespace collision between the desired destination location on cloud-provider-2 and the specified destination identifier occurs; (2) One or several of a series of copy or move operations fail but some succeed; (3) The transfer portion of a move transaction succeeds, but the erasure portion fails.
Failure Handling 9 (Base Plus): (1) The cloud-management-broker detects the namespace collision before initiating the copy operation and notifies the cloud-user with option to overwrite, skip or, in the case of a series of commands, skip all. (2) On first fail the cloud-management-broker notifies the cloud-user of the failure and offers the option to retry, skip or abort. (3) On failed erasure the cloud-management-broker notifies the cloud-user and offers the option to roll back the transaction, which erases the destination object, or to retry.
Success Scenario 10: (included interoperability cases – Cloud Burst From Cloud to Cloud, IaaS): A cloud-user configures rules with the cloud-management-broker governing how service requests are allocated over a pool of registered providers, cloud-provider-1 thru cloud-provider-n. The rules establish a precedence of providers, a way to query and respond to reported provider load, and metrics to allocate load over providers in the pool. Cloud-user issues a command to cloud-management-broker to perform a Virtual Machine operation per Success Scenario 7 (included management cases VM Control), but without identifying a target cloud-provider. Cloud-management-broker evaluates the command against allocation rules, dynamically selects optimal cloud-provider(s) from the cloud-subscriber's registered pool, and apportions requests among the cloud-provider-1 to cloud-provider-n using native cloud-provider interface to address each involved cloud-provider.
Failure Conditions 10 (Base Plus): (1) Cloud-management-broker unable to locate an operating cloud-provider based on rules; (2) Command failure on individual cloud-provider.
Failure Handling 10 (Base Plus): (1) Cloud-management-broker notifies cloud-subscriber of event with diagnostic information and offers retry opportunity; (2) Cloud-management-broker accesses allocation rules to select fallback cloud-provider to replace failing provider, and notifies cloud-subscriber. In cases where no fallback is available, cloud-management-broker notifies subscriber.
Success Scenario 11: (included interoperability cases – Cloud Burst From Data Center to Cloud, IaaS):
Additional Assumptions: Cloud-management-broker has mechanisms for registering and monitoring Data Center load metrics as if the Data Center were a cloud provider. This can be generically implemented with Data Center private cloud software or could be an additional feature of the cloud-management-broker programming interface.
Extends Success Scenario 10: (Cloud Burst From Cloud to Cloud) by configuring rules to designate agency Data Center as a member of the pool of cloud providers, and bursting to be allocated over data center and cloud-provider-1 thru cloud-provider-n based on load and rule priority settings.
Failure Conditions (Base Plus Scenario 10): Data center becomes unavailable to cloud-management-broker interface
Failure Handling (Base Plus Scenario 10): The cloud-management-broker notifies the cloud-subscriber of the unavailable data center as if it were an unavailable cloud-provider. See Failure Handling (1) for Success Scenario 8 (Monitor Infrastructure)
Success Scenario 12 (included interoperability case Migrate a Queuing-Based Application, IaaS):
Additional Assumptions: An industry agreed minimum set of agreed attributes for queues and messages, and minimum set of queue operations. Java message service (JMS) is an example of an existing cross-implementation specification for queues, topics and messages.
A cloud-user wishes to migrate a queue and its current contents from cloud-provider-1 to cloud-provider-2 as detailed in the included management case. The cloud-user views cloud-provider-1 queues and messages using the cloud-management-broker interface, and issues the cloud-management-broker commands to stop and then to migrate queues and messages to cloud-provider-2 as specified in the included use case. The cloud-management-broker uses both cloud-provider-1 and cloud provider 2's native interface to issue commands to effect the migration as detailed in the included use case, and notifies cloud-user of the result.
Failure Conditions (Base Plus): (1) Queue stop operation fails on cloud-provider-1; (2) Queue creation and/or message transfer fails on cloud-provider-2
Failure Handling (Base Plus): (1) Cloud-management-broker aborts entire queue migration and notifies cloud-user with error message; (2) Cloud-management-broker restarts queue on cloud-provider-1, aborts queue migration and notifies cloud-user with error message.
Success Scenario 13 (included management case Migrate Fully-Stopped) VMs from one provider to another, IaaS)
Additional Assumptions: Cloud-provider-1 supports and exposes an interface to prepare instances and/or machine images for migration. Cloud-provider-2 supports and exposes an interface to receive prepared instances and convert them to a native operating instance.
A cloud-user wishes to migrate a fully-stopped VM instance or machine image from cloud-provider-1 to cloud-provider-2 as detailed in the included management case. The cloud-user accesses a cloud-management-broker interface and views cloud-provider-1 instances and/or machine images, then issues cloud-management-broker commands to stop and then to migrate the selected instances or images as specified in the included use case. The cloud-management-broker uses both cloud-provider-1 and cloud provider 2's native interface to issue commands to effect the migration, and notifies cloud-user of the result. The cloud-management-broker may be responsible for transferring the prepared static representation of the cloud-provider-1 image to cloud-provider-2, but the mechanics of preparing the static representation and subsequently translating it into cloud-provider-2 format are delegated to the respective cloud provider interfaces per included use case.
Failure Conditions 13 (Base Plus): Cloud-management-broker unable to transfer prepared static representation of cloud-provider-1 image to cloud-provider-2 because of internal or communication failure.
Failure Handling 13 (Base Plus): Cloud-management-broker offers cloud-user opportunity to retry or abort migration.
Extended Management Scenarios
Success Scenario 14 (Extend Infrastructure Instance Management Capabilities, IaaS): A cloud-user wishes to perform virtual machine instance management tasks that are not supported by one or all of cloud-provider-1 through cloud-provider-n. Tasks include installing applications or services, creating or managing users, starting and stopping instance services or any other operation that can be performed on a running virtual machine instance but is not supported by the cloud-provider's native interface. The cloud-management-broker provides the cloud-user a management agent to install in each cloud-provider-1-n instances, and an interface to issue the cloud-management-broker extended commands. Cloud-user selects a task, for example installing an application or creating a user, and a collection of instances to receive the task. The cloud-management-broker communicates with each instance management agent and issues commands to affect the task that is carried out on the target instances by the locally running agent installed on each virtual machine instance for cloud-provider. The cloud-management-broker interface represents the state of each command to the cloud-user.
Failure Conditions 14 (Base Plus): Cloud-management-broker agent fails to execute or reports an error on target instance.
Failure Handling 14 (Base Plus): Cloud-management-broker notifies cloud-user with error specifics or inability to contact. Transient errors can be retried.
Success Scenario 15 (Assemble and Manage Infrastructure Components as a Platform – IaaS, PaaS): A cloud-user wishes to define, assemble and manage a collection of infrastructure components as a coherent multi-tiered platform, including but not limited to virtual machine instances or images, storage, load balancers, and databases. Using a cloud-management-broker interface, the cloud-user selects cloud-provider instances or images and assembles them into tiers, such as application tiers which implement an application layer, load balancing tiers which implement load balancers, or database tiers which implement replicated or clustered databases. The cloud-user accesses a cloud-management-broker interface and assembles the tiers into a logical platform, specifying scaling metrics for each tier, connections between tiers, data load processes and sources, backup processes and all required interdependencies. The cloud-user starts the unified platform using the cloud-management-broker interface, views metrics on its various components, receives alerts and alarms on failure or scaling events, views backups, and stops components of the platform or platform as a whole. The cloud-management-broker uses native interfaces to cloud-provider-1 thru n implementing the platform components, and issues the native commands corresponding to cloud-user requests, monitors the cloud-provider components, and issues scaling commands and alerts according to cloud-provider metrics. Components within a platform assembly may initially be constrained to resources from a single cloud-provider, but future cross-provider platform assembly and operation scenarios are possible.
Failure Conditions 15 (Base Plus): (1) Cloud-management-broker is unable to fully start or stop the assembled platform because of a processing tier failure; (2) Processing failure within an application tier renders tier inoperative or degraded.
Failure Handling 15 (Base Plus): (1) Cloud-management-broker notifies cloud-user with error specifics from failing tier component. Transient errors can be retried; (2) Cloud-management-broker detects failure of component or tier and restarts tier components according to tier scaling rules.
Credit: RightScale, Enstratus