Proposal by CA Technologies, IBM, SAP, Vnomic Using TOSCA Requirements /Capabilities to Specify Capacity Resources (Primer Considerations) Proposal by CA Technologies, IBM, SAP, Vnomic

Resource Types Common (Capacity and Consumption) Other CPU capacity (in portable units such as SPECint2006_rate) Memory (virtual or physical) Storage (local disk, SAN, NAS) Bandwidth (network) Other Workload types, Abstract resources Constraints in environment and other elements

Typical Use Case Typical use case Resources of a Service Specify the resources, capabilities and their characteristics to (re)deploy a service in a cloud environment (see supplemental section) Can be effectively expressed using proposed requirements/capabilities framework Resources of a Service Sum of all included elements in that service (per resource type)

Specifying Resource Requirements Definitions needed CapabilityType(s) for resources such as Memory, CPU, Storage, etc. NodeType(s) and NodeTemplate(s) to express requirements against the hosting resources May be specified as ‘hints’ or requirements Number and types of nodes are implementation dependent Single, multiple locations, availability zones, … Need to define semantics

Resources as Capabilities Predefined by TOSCA <NodeTemplate id="uid-host" nodeType="tcore:Host"> <Capabilities> <Capability is="uid-resources-memory" name="myMemory"> <Properties> <Memory>128</Memory> </Properties> </Capability> <Capability id="uid-resources-compute" name="myCompute"> <SpecInt2006Rate>100</SpecInt2006Rate> <CPU_MHZ>4</CPU_MHZ> <NCPU>64</NCPU> <Capability id="uid-resources-storage-SAN" name="myStorage"> <Storage>5000</Storage> <Luns>10</Luns> </Capabilities> </NodeTemplate> Unit is defined in CapabilityType for Memory Max capabilities for Node Multiple properties per Capability

Resources Requirements Defined by Capability <Requirements> <Requirement ref="uid-resources-memory“ name=“memory1> <Properties> <Memory lowerBound="4" upperBound="16" typical=”8”/> </Properties> </Requirement> <Requirement req="uid-resources-compute“ name=“CPU1”> <SpecInt2006Rate lowerBound="10" /> <Requirement ref="uid-resources-storage-SAN“ name=“storage1> <Storage lowerBound="100" upperBound="200" /> <Luns lowerBound="1" /> </Requirements> For better matching Multiple property match

Remaining Comments and Where we Left Them

Remaining Comments & Suggestions Requirement definitions should support Unit & Type to accommodate capability type of resources such as CPU & memory. Agreed, needs specifics

Remaining Comments & Suggestions 2 Consider requirement phases Initial requirements Needed before a node can be instantiated Operational requirements Needed to satisfy changing demands; scaling up/down Example: <Requirements type=”initiation”> Agreed. Needs further discussion

Remaining Comments & Suggestions 3 The Requirement to Capability matching needs to be further defined or extended How will one express a requirement of Tomcat version 5.0 and above? Need for a SQL92 compliant database Server? Need to define additional semantics Could possibly borrow subset of OASIS SDD A more detailed proposal is needed

Examples of Property Syntax and Matching Requirements Type + Property syntax to match: Exact value: property A must be ‘X’ One of enumerated value: property A must be 1 or 5 In range (min, max): property A must be between 1 and 10 Regex match: property A should match 5.* (* is wild character) or string ‘5.*’ More complex expressions: Composite, hints/recommendations, “relaxed matching”, …

Supplemental Material

Use Case Description Use Case Specification of Resource Requirements TOSCA-00 Specification of Resource Requirements Description: Specify the resources required to (re)deploy a service successfully in a cloud environment. Desired outcome: Any service deployed using the TOSCA specification would be provisioned with sufficient physical and virtual resources to meet its resource demands while avoiding excessive resource cost. Triggering business event(s) Deployment of a new or existing service into a Cloud environment. Actor(s): The service owners and Cloud Providers. Involved components and services Virtual and physical resource management software (e.g., vCenter in a VMware environment), load testing software, resource measurement software, environment-independent resource capacity analysis software, workload forecasting software. Dependencies (pre-conditions): Performance modeling and analysis of the service under anticipated workload volumes, perhaps on a different cloud provider. Related Use Cases Service Monitoring Use Case

Preferred Initial Process Flow Step Description Data and Software Required Service developer or performance analyst load tests the application in a test environment (or for redeployment obtains monitoring information from a monitoring environment) Software: Load test and resource measurement (or monitoring in the case of redeployment) Performance analyst models environment- independent service resource requirements as a function of workload volumes in the service’s TOSCA Service Template. Resource requirements are generated by the tools or by the analyst Data: Load test or production monitoring transaction volumes, resource consumption measurements and resource configurations Software: Environment- independent resource capacity analysis software Service owner deploys application with TOSCA Service Template that includes environment- independent resource requirements to Cloud provider Note: This step is repeated with each new version of the service to be deployed The Cloud Provider’s TOSCA container deploys the service in accordance with the TOSCA Service Template, including the provisioning of the service’s required resources  

Preferred Ongoing Process Flow Service owner periodically forecasts future workload volumes and models changing requirements in updated version of the TOSCA Service Template. The service owner provides updated template to the Cloud Provider. Data: Historical and forecasted business and IT workload data   Software: Workload forecasting software Cloud Provider (or service owner) adjusts the service’s resources in accordance with the new workload volume forecasts and requirements specified in the TOSCA Service Template.

Error Flow and Variations Based on user request and Cloud Provider options, the CP rejects the request if not enough resources are available to satisfy request, or the request is queued until enough resources are available.   Variations: Cloud I(P)aaS provider periodically optimizes the deployment of (or re-deploys) all service components from all cloud tenants according to forecasted workload volumes and as modeled in updated TOSCA Service Templates. Software required: Cloud optimization software that supports TOSCA Additional Information: Determining appropriate resource configurations for service components in new execution environments is difficult because of the wide range and non-linearity of resource capacity and scalability (resource effectiveness as a function of the resources allocated). The process specified above addresses this problem. Design Suggestions:

OASIS SDD (Solution Deployment Descriptor) SDD v1.0 is an OASIS standard (as of 2008) Limited update? Suitability? What can we learn/borrow? Example:

SDD Semantics - 1 CapacityConstraint ConsumptionConstraint Constraints on the available capacity of a particular property of a particular resource. Ex: CPU speed ConsumptionConstraint Constraints on the quantity of a particular property of a specific resource that is available for consumption. Ex: disk space PropertyConstraint A specific resource properties must have a specific value or set of values. Ex: OS=Linux VersionConstraint Constraint on the version of a specific resource. Ex: Version=1.1, MinVersion=1.0 This can be expressed using Capability/Requirement Type + constraints

SDD Semantics - 2 This needs further discussion UniquenessConstraint When two resources defined in topology MUST or MUST NOT resolve to the same resource instance during a particular deployment RelationshipConstraint Constraint on a particular relationship between resources AuthorizationConstraint A required level of authorization required by a resource in order to deploy the content This needs further discussion