1 / 19

Using TOSCA Requirements /Capabilities to Specify Capacity Resources (Primer Considerations)

This document discusses the use of TOSCA (Topology and Orchestration Specification for Cloud Applications) to specify and manage resource capacities and requirements for cloud services. It provides a framework for defining various resource types, such as CPU, memory, storage, and bandwidth, as well as their associated capabilities and characteristics. Emphasis is placed on creating effective NodeTemplates and Capabilities to address operational needs, scalability, and constraints. Best practices and examples illustrate how to effectively express and manage resource requirements in a cloud environment.

serena
Télécharger la présentation

Using TOSCA Requirements /Capabilities to Specify Capacity Resources (Primer Considerations)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

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

  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)

  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

  5. 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"> <Properties> <SpecInt2006Rate>100</SpecInt2006Rate> <CPU_MHZ>4</CPU_MHZ> <NCPU>64</NCPU> </Properties> </Capability> <Capability id="uid-resources-storage-SAN" name="myStorage"> <Properties> <Storage>5000</Storage> <Luns>10</Luns> </Properties> </Capability> </Capabilities> </NodeTemplate> Unit is defined in CapabilityType for Memory Max capabilities for Node Multiple properties per Capability

  6. 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”> <Properties> <SpecInt2006Rate lowerBound="10" /> </Properties> </Requirement> <Requirement ref="uid-resources-storage-SAN“ name=“storage1> <Properties> <Storage lowerBound="100" upperBound="200" /> <LunslowerBound="1" /> </Properties> </Requirement> </Requirements> For better matching Multiple property match

  7. Remaining Comments and Where we Left Them

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

  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: • <Requirements type=”initiation”> • Agreed. Needs further discussion

  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

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

  12. Supplemental Material

  13. Use Case Description

  14. Preferred Initial Process Flow

  15. Preferred Ongoing Process Flow

  16. Error Flow and Variations

  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:

  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

  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

More Related