Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Using TOSCA Requirements /Capabilities to Specify Capacity Resources (Primer Considerations) Proposal by CA Technologies, IBM, SAP, Vnomic."— Presentation transcript:

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

2 Resource Types Common (Capacity and Consumption) – 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 2

3 Typical Use Case Typical use case – 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) 3

4 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 4

5 Resources as Capabilities Predefined by TOSCA Max capabilities for Node Multiple properties per Capability Unit is defined in CapabilityType for Memory

6 Resources Requirements 6 Defined by Capability For better matching Multiple property match

7 Remaining Comments and Where we Left Them 7

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

9 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: – Agreed. Needs further discussion 9

10 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 10

11 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, … 11

12 Supplemental Material 12

13 Use Case Description Use Case 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 13

14 Preferred Initial Process Flow Process Flow:Step DescriptionData 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 services 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 Providers TOSCA container deploys the service in accordance with the TOSCA Service Template, including the provisioning of the services required resources 14

15 Preferred Ongoing Process Flow 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 services resources in accordance with the new workload volume forecasts and requirements specified in the TOSCA Service Template. 15

16 Error Flow and Variations Error Flow 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: 16

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

18 SDD Semantics - 1 CapacityConstraint – 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 18

19 SDD Semantics - 2 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 19


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

Similar presentations


Ads by Google