Implementing Public Clouds based on CC RA Cloud Enabled Data Center (CEDC)

Transcription

1 Jochen Breh Executive Architect, GTS Cloud SSA Implementing Public Clouds based on CC RA Cloud Enabled Data Center (CEDC) 2013 Cloud Lecture, University of Stuttgart

2 Agenda Introduction Cloud Computing Reference Architecture (CCRA) Why do we need that? How do we create a complex Architecture for a Cloud project? Methodology Building a Cloud with Cloud Computing Reference Architecture and the Cloud enabled Data Center Pattern Example of a Cloud Architecture 2

3 CCRA 3.5 Overview Aggregate experience from hundreds of cloud client engagements and IBM-hosted cloud implementations Cloud-enabled data center / building IaaS Platform Services CCRA 3.0 Cloud Service Provider Building SaaS Prescriptive guidance on how to build IaaS, PaaS, SaaS and service provider clouds with IBM technology Cloud Service Consumer Common Reference Architecture Foundation Cloud Service Provider Cloud Service Creator Consists of multiple detailed documents representing best-ofindustry knowledge and insight How to architect, design and implement clouds Cloud Service Integration Tools Cloud Services Existing & 3 rd party services, Partner Ecosystems Business-Processas-a-Service Software-as-a-Service Platform-as-a-Service Common Cloud Platform (CCMP) Operational Support Services (OSS) Business Support Services (BSS) Service Creation Tools Reflected in the design of Consumer In-house IT Infrastructure-as-a-Service Clouds IBM implements for clients IBM-hosted cloud services IBM cloud appliances Infrastructure Security, Resiliency, Performance & Consumability Governance IBM cloud products 3

4 Infrastructure Mgmt Interfaces Platform Mgmt Interfaces Software Mgmt Interfaces BP Mgmt Interfaces IBM Cloud: Think it. Build it. Tap into it. CCRA 3.5 Overview Describes the Operational Services and Business Services needed to implement the different cloud adoption patterns Cloud Service Consumer Cloud Service Provider Cloud Service Creator Consumer End user Cloud Service Integration Tools Cloud Services Existing & 3 rd party services, Partner Ecosystems API BPaaS Common Cloud Platform OSS Operational Support Services Service Delivery Catalog Service Manager BSS Business Support Services Customer Account Service Offering Catalog Business Manager Service Offering Service Component Developer Service Composer Service Integrator Consumer Business Manager Consumer Inhouse IT API API SaaS PaaS Service Consumer Portal & API Service Automation Service Request Provisioning Monitoring & Event Change & Configuration Incident & Problem IT Asset & License Image Lifecycle IT Service Level Capacity & Performance Contracts & Agreement Subscription Service Request Pricing Order Entitlement Metering Rating Billing Service Development Portal & API Offering Manager Service Creation Tools Service Development Tools Business Processes Applications Middleware Infrastructure Service Consumer Administrator API IaaS Platform & Virtualization Deployment Architect Transition Manager Infrastructure Operations Manager Clearing & Settlement Service Provider Portal & API Accounts Payable Security & Risk Manager Accounts Receivable Customer Care Service Runtime Development Tools Software Development Tools Image Creation Tools 4 Security, Resiliency, Performance & Consumability Governance

5 Cloud Computing Reference Architecture CCRA Overview 5 Cloud Enabled Data Center is one of the six «cloud adoption patterns» that are described in the IBM Cloud Computing Reference Architecture (CCRA) that provides an architectural framework for the implementation of cloud solutions The CCRA Cloud Adoption Patterns categorize the cloud computing business models and technical goal and represent the way most of our customers approach cloud computing solutions The cloud adoption patterns identified by the IBM CCRA are: Cloud Enabled Data Center (IaaS) Platform-as-a-Service (PaaS) adoption pattern Cloud Service Providers (CSP2) Software-as-a-Service (SaaS) Mobile Analytics For each cloud adoption patterns, CCRA identifies common architecture patterns that describe the technologies that underlie each type of cloud computing implementation. It also includes common architecture patterns for items that cut across all the adoption patterns including security, resiliency, performance, etc.

6 Objectives of Cloud enabled Data Center Building a Private IaaS is one of the top priorities of today s IT managers. To build a private cloud is a tremendous shift in how IT services are delivered and defining the valuable services is key. Success requires a proven architecture and guidance how to integrate products and building blocks. CCRA 3.5 Cloud enabled Data Center (CeDC) Adoption Pattern Provides a prescriptive guidance to build Private Clouds for IaaS, starting from a simple entry implementation up to a comprehensive infrastructure that provides fully ITIL managed cloud services. Depicts the most important patterns to select and integrate IBM s Tivoli cloud and system management products. Reuse knowledge of hundreds of successful cloud projects. This presentation describes how to use the IBM methodology and technology to architect, design and implement an advanced and cost-effective cloud infrastructure for the delivery of IaaS services 6

7 CEDC Cloud adoption pattern Overview CEDC «Cloud Adoption Pattern» provides guidance on how to build a private cloud for the delivery of IaaS services CEDC solution is described through four «architectural patterns» called macropatterns Each macro-pattern address a specific «business scenario» and implements all the capabilities at a given level of the CEDC cloud maturity model Each macro-pattern describes the use-cases provided by that specific macropattern and the components that are needed to implement it These are the four macro-patterns identified for the CEDC adoption pattern Simple IaaS services Managed IaaS services Advanced IaaS services ITIL process integrated IaaS services 7

8 Methodology: Team Solution Design 9

9 Phases to Architect an End-to-End cloud adoption pattern Understand Client Define Client Requirements Design Solution Detail Design to Define BOM Define Roadmap & First Project 5. Non-Functional Requirements 10. Component Model Client Specific Design and consider the components of the solution both at a physical and logical level, and their interaction. Client Specific CCRA Supported 11. Operational Model Design and consider the components of the solution both at a physical and logical level, and their interaction. 14. Viability Assessment Assess the viability of the solution to meet the requirements, having the appropriate skills, and stakeholder buy-in of the technical components. 10

10 Understand Client CEDC Maturity Model 5: Monetized Cloud storefront Integration with CRM and billing Business Value 4: Enhanced Monetized Pattern-based provisioning Service orchestration Hybrid cloud integration 3: Optimized Governance Image management Backup and restore Security and patch management Monitoring Enhanced Optimized 2: Deployed Standardized services Simple provisioning automation Service catalog Usage metering Deployed 11 1: Virtualized Virtualized

11 Understand Client CEDC Maturity Model Virtualized (maturity level 1) Many organizations are at this level today, and use virtualization to manage storage, network or compute However at this level there is still very little automation to support virtualization. Deployed (maturity level 2) At the deployed level, the virtualization technologies are augmented with an automation layer. Basic management processes are established to track costs Optimized (maturity level 3) At this level an organization incorporates additional capabilities to manage the infrastructure in order to reduce the operational costs and improves the service level agreements (SLAs) and quality of service. Enhanced (maturity level 4) With level 4 the focus shifts to high value services such as, provisioning of application topologies, disaster recovery of cloud environment, and cloud-based backup services. Level 4 provides organizations with the ability to orchestrate provisioning of services across data centers and provisioning to off-premise public clouds to dynamically scale out and handle peak loads. Monetized (maturity level 5) At this level, IT organization contribute to generate revenue by offering a utility service for obtaining compute and storage to other organizations or companies or to consumers or users At this level there are vigorous processes in place for service inception, development, offering, billing, and retirement and a greater focus on the ease of use and customizability of user interfaces. This level represents the natural evolution toward a Cloud Service Provider business model. 12

12 Define Client Requirements Phase 2: Define Client Requirements Step 4: Actors and Use Cases Define Client Requirements Objective: Define functional requirements. Indentify actors and associated use cases. 5. Non-Functional Requirements Actions: 1. Use the CRRA cloud role definitions to identify client-specific actors for the cloud solution. 2. Use the CCRA cloud use-case packages to define client functional requirements. 3. Extend and modify identified use cases to define specific functional requirements. 4. Add whatever is necessary for the adoption pattern. Results: Cloud actors identified for the adoption pattern. Functional requirements defined for each actor. 13

13 Define Client Requirements CEDC Use-case packages, Micro-patterns and Macro-Patterns concepts Key concepts at the base of the architectural approach used in CCRA Use case packages A collection of related use cases defining interactions between an actor performing a specific activity or task that uses specific CEDC functions or capabilities. E.g. the set of use cases for interaction with virtualized storage or use cases supporting identity and access management. Micropattern A collection of related use case packages. E.g. the micropattern for virtualization is a collection of use case packages for server virtualization, storage virtualization, network virtualization, and hypervisor management. Macropattern A collection of micropatterns that when implemented together the combined functionality is assessed as compliant with all aspects of a maturity level. E.g. the capabilities of pattern-based provisioning, service orchestration, and hybrid cloud integration are implemented by the Advanced IaaS macropattern. A typical characteristic of a macropattern is that it typically stacks (in terms of capabilities and components) on top of the previous macropatterns and provides the base for building the next macropattern. 14

14 CEDC - Use cases overview Define Client Requirements Cloud Enabled Datacenter Overall Use Case Packages and Micro-patterns View Legend: Use relation Optional use relation 15

15 CEDC - Use cases and micro-patterns overview 16 Define Client Requirements Virtualization (P0): This micro pattern includes the compute, storage, network virtualization and hypervisor-mgmt use cases Monitoring and event and capacity management (P1): This micropattern pertains to monitoring the health of the cloud infrastructure, collection and management of exception events, and capacity planning. Data resiliency (P2): This micro-pattern includes the use cases for backup of storage volumes, virtual machines, and recovery from a backup in the event of a failure or disruption. Image management (P3): This micropattern includes use cases for image registration and backup, image capturing, deep image search, drift analysis, version control, and management of image sprawl. Self-service automation (VMs) (P4): This micropattern contains use cases for onboarding, provisioning, and management of virtual machines (VMs) that are made available via the service catalog. Metering and accounting (P5): This micropattern includes use cases for the measurement, reporting, and chargeback of the resources of a Cloud Enabled Data Center. Storage and network virtualization management (P6): Includes use cases concerning advanced management capabilities for virtualized storage and network environments, such as storage and network discovery, provisioning, and monitoring Self-service automation (storage) (P7): This micropattern includes discovery, configuration, provisioning, commissioning, and de-commissioning of storage use cases. Self-service automation (network) (P8): Includes use cases for discovery, configuration, and provisioning of virtual networks and network devices (such as, VLANs, virtual routing and forwarding (VRF), load balancers, and firewalls). Self-service automation (services) (P9): This micropattern includes use cases for provisioning and configuration of complex services that are comprised of more than one VM, storage, and network elements or for production workloads. Hybrid cloud integration (P10): This micropattern includes use cases for deployment of workloads to public clouds, integration of service management, and governance across on-premise Cloud Enabled Data Center and public clouds. IT service management (P11): This micropattern includes use cases for implementing the ITIL processes, such as incident and problem management, change and configuration management, IT asset management, license management, service desk, and release management in a private cloud environment. Security (P12): Includes use cases for securing the different levels of the cloud solution, such as identity and access mgmt, securing the virtual infrastructure, security event mgmt, and automation of security checks for complex services

16 Define Client Requirements CEDC Macro-patterns To further abstract and simplify the design of a CEDC, multiple micropatterns are grouped into macro-patterns Macropatterns provide incremental increases in capabilities and functionality and describe from an architectural perspective the solution to implement. Each macropattern represents a subset of the entire CEDC adoption pattern and addresses a specific business problem through a specific set of capabilities. The following 4 macropatterns have been identified for CEDC Simple IaaS Start to embrace the cloud model by delivering simple VMs via service-catalog Managed IaaS Manage the cloud infrastructure to increase SLA/QoS, security and reliability Advanced IaaS - Deliver more sophisticated and composite cloud services Process integrated IaaS Integrate IaaS with the existing enterprise ITIL processes However, macropatterns are just recommendations, enabling you to consider or not to consider a specific capability based on your operational and business needs and costs considerations. So for each macropattern you may select only the capabilities that you really need 17

17 Increasing Capability Define Client Requirements IBM Cloud: Think it. Build it. Tap into it. CEDC Macro-patterns mapping to Micro-patterns Process integrated IaaS services Problem & Incident IT Asset License Change & Configuration Service Desk Release 4 Advanced IaaS Services Storage Provisioning & Automation Network Provisioning & Automation Service Orchestration Hybrid Cloud Integration Advanced Security (Threat & vulnerability, identity & access, Security info and events mgmt) 3 Managed IaaS Virtualised Infrastructure Monitoring Capacity and Planning Events Backup & Restore Patch Endpoint Compliance & 2 Simple IaaS Services (VMs) 18 VM provisioning & On-boarding Cloud Tenants, Roles & Authentication VM Image Construction Image Usage metering, accounting & chargeback 1

18 Design Solution Phase 3: Design Solution Design Solution Step 7: Start architectural decisions and revisit them when the architecture is complete Objectives: Establish architecture principles for the Cloud Adoption Pattern. Make architectural decisions for the Cloud Adoption Pattern. Actions: 1. Use the CCRA architecture principles to define client-specific principles. 2. Choose and apply architectural decisions for the chosen adoption pattern from CCRA and add others. Results: Document the Cloud Adoption Pattern architectural decisions. 19

19 Design Solution Architectural Decisions Overview Two types of Architectural Decisions Architectural decisions made during the CCRA creation process To capture the CEDC decision process To provide insight to the thought process Architectural decisions that must be made during solution development by the practitioner Templates to guide the practitioner Templates to standardize solution architectures 20

20 Design Solution Architectural Decisions made in CCRA CEDC creation process Architectural Decision Problem Statement Decision / Recommendation Focus on SCO based solution for CEDC architecture At today we have different components (i.e. TSAM, ISDM, SCP and SCO) that implement a Cloud platform with slightly different capabilities. We decided to focus the CEDC architecture on the SCO component. TSAM/ISDM will not be described in the CEDC architecture. Do not explicity include SmartClou Provisioning and SmartCloud Entry in the CEDC architecture We are in the middle of a change in the Tivoli products portfolio with the new Common Cloud Stack strategy where the new SCP 2.3 product will be a subset of the SCO components We decided to not include SCP 2.2 component in the CEDC architecture recommendations because it does not allow to incrementally grow to implement macro-pattern 3 orchestration capabilities (SCP 2.2 is not openstack based and is not easily migratable to SCO). We need to decide which components/solution to recommend now (in this transition phase) when building a CEDC architecture At today the functions of macro-pattern 1 can be implemented by using a subset of the SCO product components. When SCP 2.3 will be available it will be the recommended choice for implementing macropattern 1 since SCP 2.3 will be implemented as a subset of the SCO components and so it will be fully compatible and upgradeable to SCO SmartCloud Entry is not considered in the CEDC architecture since it is limited to IBM-only H/W Scenarios that are not covered by SCO yet The first release of the SCP/SCO components will not address 100% of the cloud requiremetns described and will not cover the whole set of hypersors support For those use-cases, hypervisors, environments, or configurations not yet supported by SCO, we ll provide a timeframe when they will be supported 21

21 Design Solution Architectural Decisions to be taken while designing a CEDC solution Architectural Decision Problem Statement Decision / Recommendation Events capabilities Storage architecture for Power environment s Provide guidelines to understand we really need to include the Events as part of the cloud infrastructure For VM provisioning on Power(*), you need to choose among different integration paths for storage: NPIV, LUN mapping, logical volumes, or distributed VIOS. Events Mgmt is an advanced management capability that is recommende and instrumental to effectively manage high-volume environments with high QoS/SLA requirements For a guidance on this choice see Appendix B: Storage configuration strategies for Power environments Choiches for Storage provisioning and configuraiton scenarios Choices for Network provisioning and configuraiton scenarios Understand when do we need to include SmartCloud Virtual Storage Center component in the cloud management infrastructure Understand when do we need to include Tivoli Network Configuration Manager component in the cloud management infrastructure Storage provisioning/configuration scenarios on NetApp or N Series, are provided out of the box by SCO (by TSAM). SmartCloud Virtual Storage Center should be included only for advanced Storage as a Service scenarios on different type of storage not supported by SCO (TSAM) ITNCM and NSE Extension APIs should be included only if the customer needs to implement advanced network configuration or provisioning scenarios that are not provided by the existing ISML extensions for Juniper Firewall and F5 LoadBalancers (*) Power environments are not currently supported by SCO 2.2 (both as manage-from and manage-to environments). Support for manage-to Power environments «should» be provided by SCO

22 Design Solution Phase 3: Design Solution Step 8: Design the Architecture Overview Design Solution Objective: Design logical components and capabilities for the Cloud Adoption Pattern. Actions: 1. Start by choosing components from the CCRA Architecture Overview diagram. Results: Architecture Overview diagram for Cloud Adoption Pattern. 23

23 Design Solution Architecture Overview Diagram This artifact provides an overview of the main conceptual elements and relationships of an architecture, which may include candidate subsystems, components, nodes, connections, data stores, users and external systems. As such, it represents the governing ideas and candidate building blocks of the architecture. Here you can see that for pre-sale solution design the purpose of the Architecture Overview work product is: Communicate to the sponsor and external stakeholders a conceptual understanding of the architectural goals and intended architecture Provide a high-level vision of the architecture and its scope to developers Explore and evaluate alternative architectural options Enable early recognition and validation of the implications of the architectural approach Facilitate effective communication between different communities of stakeholders and developers Facilitate orientation for new people who join the project (Powerpoint versions of the AOD diagrams are available in the Backup section of this presentation) 24

24 Design Solution Architecture Overview Diagram Functional view 25

25 Design Solution Architecture Overview Diagram Implementation view (by macro-pattern) for security & compliance 26 (*) Available from next SCP 2.3 release

26 Detail Design Phase 4: Detail Design Step 10: Design Component Model Detail Design to Define BOM 10. Component Model Design and consider the components of the solution both at a physical and logical level, and their interaction. 11. Operational Model Design and consider the components of the solution both at a physical and logical level, and their interaction. Objectives: Design components specific to the Cloud Adoption Pattern. Describe each component with a focus on cloud specifics (not needed for generic CCRA components). Define how components in the Cloud Adoption Pattern relate to each other. Actions: 1. Use the CCRA component model diagrams to identify the capabilities relevant to the Cloud Adoption Pattern. If CCRA components are missing or do not match your needs, please contact the component model lead. 2. Create component model diagrams showing all components relevant to the adoption pattern. Results: Cloud Adoption Pattern-specific component model. 27

27 Detail Design CEDC Logical Components Model 28 (Powerpoint versions of the Componet model diagrams are available in the Backup section of this presentation)

28 Detail Design CEDC Product Components Model Detailed view SmartCloud Orchestrator 29

29 Phase 4: Detail Design Detail Design Step 11: Design Operational Model Detail Design to Define BOM 10. Component Model Design and consider the components of the solution both at a physical and logical level, and their interaction. 11. Operational Model Objectives: Choose detailed physical components / Bill of Materials (BoM for hardware, software, and services) to be implemented for the Cloud Adoption Pattern. Show how component model capabilities are realized by selected products. Design the physical topology and deployment of the adoption pattern. Start the operational model with a core set of products and extend it gradually by adding products, including their value propositions. Actions: 1. Design (managing and managed) locations and nodes for the locations. 2. Design the deployment topology, including networking, tenant isolation, and security. 3. Optionally, design backup and restore, and disaster recovery. 4. Choose the hardware and software for each node. 5. Design integration of the operational model with existing systems. 6. Define and choose services for integration. 30 Design and consider the components of the solution both at a physical and logical level, and their interaction. Results: Cloud Adoption Pattern-specific component model. Hardware, software, and services BoM.

30 Detail Design CEDC Operational Model concepts Operational Model describes CEDC system at a high level of abstraction, specifying: The major components of the application and how they are connected Where the components will be located and hosted depending on functional and nonfunctional requirements The minimum and recommended H/W infrastructure to host the components. Operational Models provide the following views: Logical view - shows the managed environment, managing environment, possibly cloud consumer, each product is one node (regardless of how it is actually deployed), no reference to networks per se. Integration view shows how the different components are integrated Deployment views - shows recommended nodes and networks into which each component is placed depending on functional and non-functional requirements (e.g. high scalable, HA, DR, multi-site environment, etc..) H/W prequisites and recommendation shows the minimum and recommended H/W infrastructure to host the different components of the CEDC solution 31

31 Detail Design CEDC Operational Model - Logical view Cloud environment SmartCloud Control Desk Node SmartCloud Virtual Storage Center Node Tivoli Network Configuration Manager Node SmartCloud Orchestrator Node Tivoli Storage Manager Node SmartCloud Patch Node Tivoli NetCool Node SmartCloud Monitoring Node SmartCloud Cost Node SmartCloud Provisioning Node (*) Cloud Managed environment 32 Hypervisors and Hypervisors Hypervisors and Hypervisors Managers Nodes Managers Nodes

32 CEDC Operational Model Integrations view Cloud exploting applications Cloud Operator Cloud UIs Cloud end-user End-users self-service portal Access layer Cloud Administrator Cloud Administration UI Detail Design Cloud Services Develoepr Cloud Services Development UI 14 Interfaces layer Cloud APIs Cloud Service interaction APIs Cloud Administration APIs Cloud Services Modeling API SmartCloud ITIL Services Control Desk Accounting & chargeback SmartCloud Cost Mgmt Service Governance Layer Users & Customer Mgmt Entitlement 19 Service layer 9 20 Threat & VSP vulnerability ISNIPS mgmt Security Information QRadar Log mgmt Mgr Service Orchestration Layer SmartCloud Orchestration Orchestrator VMs Patterns Provision ing Service Delivery Layer Metering 18 IBM Security Endpoint Manager Patches Compliance Tivoli Backup Storage & Restore Manager Monitoring SmartCloud Monitoring Capacity Mgmt Tivoli NetCool OMNIBus VMs (Windows, AIX, Linux) Users authentication TFIM & 17 authorization 7 8 Storage SmartCloud provision & Virtual configuration Storage Center 5 Network Tivoli Network provision & Configuration configuration Manager Infrastructure Layer Users and tenants Administration Public clouds adapter Virtualization Environment (VMWare, KVM, HyperV, Xen, Power, zvm) VMs provision & configuration Compute (X86, pseries, zseries) Storage (IBM, NetApp, EMC, Hitachi,,..) Network (CISCO, IBM,...) Cloud resources Administration Images Mgmt Public Clouds (EC2, SCE,..) Images creation LDAP

33 Design Solution CEDC Operational Model Integrations Overview (1 of 2) ID From To Maturity Level Comments CDC- PIS-01 SmartCloud Orchestrator Virtualization environments GA level Support the following hypervisors VMWare (only via Vcenter), KVM Following hypervisors are not currently supported and will be supported in future releases Power, HyperV, Xen, zvm CDC- PIS-02 SmartCloud Orchestrator External public clouds GA level Support the following public clouds Amazon EC2 Following public clouds are not currently supported and will be supported in future releases IBM SCE CDC- PIS-03 SmartCloud Orchestrator Storage infrastructure Content Pack SCO content pack for «Network Attached Storage» available on ISM Library ( 304.ibm.com/software/brandcatalog/ismlibrary/details?catalog.label=1TW10SO09) Provisioning storage from NetApp or SONAS managed storage devices Provision VM additional disks CDC- PIS-04 SmartCloud Orchestrator Network infrastructure Content Pack SCO content pack available on ISM Library for: - provision and configure a Juniper Networks SRX Firewall device - provision and configure an F5 Load Balancer device CDC- PIS-05 SmartCloud Virtual Storage Center Storage infrastructure GA level See product documentation CDC- PIS-06 IBM Tivoli Network Configuration Manager Network infrastructure GA level See product documentation CDC- PIS-07 SmartCloud Orchestrator SmartCloud Virtual Storage Center Not Available Out-of-the-box integration is not available Advanced storage provisioning/configuration scenarios from SCO via TPC can be developed invoking the TPC Storage APIs for Cloud (SMAC APIs) from a BPM workflow SMAC APIs are already available for file-based storage (Storwize v7000 Unified and SONAS) SMAC APIS are not yet available for block-based storage,. CDC- PIS SmartCloud Orchestrator IBM Tivoli Network Configuration Manager Content Pack SCO content packs from TNCM is available on ISM Library (SCO/TNCM) (firewall via TNCM) (balancer IBM via Corporation TNCM)

34 Detail Design CEDC Operational Model The following slides provides and overview of how the components of each macro-pattern are deployed in one of the following configurations POC deployment Detailed views of how the components in each macropattern are deployed in a POC configuration that is the simplest configuration that allows to run a POC in a small environment without HA/DR capabilities Production deployment Detailed views of how the components in each macro-pattern are deployed in a Production configuration that allows to manage high volumes environments and includes high-availability for both cloud management and managed environments 35

35 Example of a multi-site managed Cloud 36

36 Architectural Overview Diagram 37

37 System Context 38

38 Key Takeaways The Cloud enabled Data Center Adoption Pattern describes the architecture of a IaaS Cloud on different levels follows a methodology that structures a customer project... is based on many successful customer projects 39

39 Reference Resources (References, Links, etc.) Link to CeDC Material Key Contacts For questions on CeDC please contact Pietro Iannucci & Jochen Breh 40

40 41

41 Trademarks and notes IBM Corporation 2013 IBM, the IBM logo, ibm.com, the planet icon, and IBM SmartCloud are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with the appropriate symbol ( or ), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at Copyright and trademark information at Other company, product, and service names may be trademarks or service marks of others. References in this publication to IBM products or services do not imply that IBM intends to make them available in all countries in which IBM operates. 42