3 Cloud Architecture ITTelkom 11 Agt 2012 by Arief H Gunawan

Cloud Architecture
(half day edition)

An Cloud Computing Course IT Telkom, 11 August 2012 Arief Hamdani Gunawan
Scope
The scope of this Course is to define the functional requirements and reference architecture of cloud computing, which includes the functional architecture, functional layers and blocks.
Contents
Cloud architecture requirements Cloud computing reference architecture - Layering framework
Cloud architecture layering User layer Access layer Services layer Resources and network layer Cross-layer functions
Cloud computing reference architecture Functional blocks

User layer Access layer Services layer Resources and network layer Cross-layer functions
Service architecture for desktop as a service (DaaS)

Main functions of the DaaS service architecture Interaction process between client and functional components of the DaaS
Contents


Cloud architecture requirements

The cloud architecture must meet several requirements to enable sustained innovation and development of cloud services. With multiple stakeholders involved, the cloud architecture must be flexible to fit the needs of infrastructure CSPs, CSPs and service resellers.
Cloud architecture requirements: 1

The following high-level requirements are broadly envisioned for the cloud architecture: 1. Cloud deployments will have to support many standards within the same cloud infrastructure, e.g. in terms of resource allocation, orchestration, or CSU access.
The cloud architecture must allow and support the evolution of these standards, without requiring disruptive infrastructure changes from the CSP perspective.

2. A cloud CSP must be able to support multiple standards within the same architecture and migrate to a newer standard if they so wish, without having to change everything in the CSP network or lose the existing customer base.

3. Broadband access is fundamental in making cloud services viable.
The cloud architecture may benefit from integration with the support of network resource reservation and guaranteed QoS capabilities through the network over which services are delivered. Without the network access guaranteeing bounded delay, jitter, bandwidth, and reliability, the cloud experience for CSUs may be worse than the intranet experience.

4. The cloud architecture must enable multiple deployment models, cloud service categories and use cases, some currently known and others to be envisioned in the future.
Currently known cloud service categories include IaaS, PaaS, SaaS, CaaS, and NaaS, and it is possible that these will also co-exist in the same cloud deployment. The same architecture must allow a CSP to provide either all, or a subset, of these services.

5. For private and hybrid cloud operations, cloud services must appear like intranet services.
This means a user must be able to access resources using the same domain names as on the intranet. Hosts and resources that have been migrated from private to public clouds should be accessed transparently where they are being currently hosted.

6. The cloud architecture must enable early detection, diagnosis and fixing of infrastructure or service-related problems.

7. CSUs must be able to (request) audit CSPs services and get assurance that the agreedupon SLAs are being complied with.
To that end, the cloud architecture must enable, among others, service-level monitoring of resources allocated to a user and generate SLA compliance reports.

8. Cloud resource allocations should be invisible to the CSUs, even though services are visible.
A CSP may choose to expose service-operation details without having to share cloud internal infrastructure allocation and provisioning details. This is important for a CSP for security and business reasons.

9. Users consuming cloud services must be able to control cloud resource access to the CSP transparently, and enable IT procedures to work without compromise in legal or organizational mandates.
This includes, for instance, the ability to dynamically add or remove a user from access to a cloud without CSP intervention.

10. The cloud architecture must enable intranetlevel security on the network.
This may include access records, activity reports, session monitoring, and packet inspections on the network. It must also include firewalling, access control and malicious attack detection and prevention. Prevention of one user disrupting others services is paramount.

11. The cloud architecture must support cloud resource mobility which includes virtual machine mobility within a PerformanceOptimized Data centre (POD) or data centre, between PODs or data centres within the same CSPs infrastructure, or between different CSPs infrastructures, or from a CSU to a CSP.

12. Resource mobility depends upon being able to treat an entire network as a single entity, which implies the need of the cloud architecture to scale.
With a huge number of computing, storage and network resources, and an even greater number of virtualized resources, the cloud architecture must have scalability as a primary requirement.

13. Naming extensions are necessary to meet cloud needs.
Users who move their private resources into the cloud may need to access their resources by the same names as they did prior to those resources being migrated. Since hosts are associated with users domain names, it is necessary to translate the users domain names into cloud names.

14. Cloud-service deployment needs to be automated in order to support scalable resource operations, including configuration, provisioning, charging, etc.
In a typical scenario, a user would want to specify the computing, storage and virtual machine (VM) resources needed, as well as the network resources. This includes how the network resources should be reserved, configured and managed during lifetime for optimized connectivity between the distributed computing, storage and VM resources, and finally retired.
Contents


CC Reference Architecture
Layering Framework
Cloud Architecture Layering shows the cloud layering framework that is defining the layers of the cloud functional architecture. These functional layers in the architecture are derived by grouping cloud related functions.
Cloud Layering Framework
User Layer (1/2)

The User Layer performs interaction between the CSU and the cloud infrastructure.
The User Layer is used to
setup secure mechanism with cloud, send cloud service requests to cloud and receive cloud services from cloud, perform cloud service access, administrate and monitor cloud resources.
When the cloud receives service requests, it orchestrates its own resources and/or other clouds resources (in case of other clouds resources via the inter-cloud function) and provides back cloud services through the User Layer.
User Layer (2/2)

The User Layer is where the CSU resides.
The CSU is an essential actor of the cloud ecosystem. It represents the entities that use the services offered by the CSP. A CSU may use a service directory from a CSP and after setting up appropriate contract would use the services accordingly.
CSU
CSUs demand SLAs. SLAs govern the characteristics of the services provided by CSPs.
SLAs govern many aspects of the services provided, for example QoS, governance, security, performance and data portability.
The CSU typically consumes services in five service categories:

CaaS SaaS PaaS IaaS NaaS
Access Layer
The access layer provides a common interface for both manual and automated cloud service capabilities and service consumption. The access layer accepts
CSUs cloud service consumption requests and/or CSNs cloud service consumption requests and/or other CSPs cloud service consumption requests using cloud APIs to access CSPs services and resources.
Service Layer
The Services Layer is where the CSP orchestrates and exposes services of the five cloud service categories. It is the entity responsible for making a service available to interested parties. The Cloud Service Layer manages the cloud infrastructure required for providing the services, runs the software that implements the services, and arranges to deliver the cloud services to the CSU through network access
Service Layer: SaaS and CaaS

For Saas or CaaS, the services layer deploys, configures, maintains and updates the operation of the software or communication applications on a cloud infrastructure so that the services are provisioned at the expected service levels to the layers above.
Service Layer: PaaS

For PaaS, the services layer manages the cloud infrastructure for the platform and runs the software that provides the components of the platform, such as runtime software execution stack, databases, and other middleware components. The CSP of PaaS services typically also supports the development, deployment and management process of the CSUs of PaaS services by providing tools such as integrated development environments (IDEs), software development kits (SDKs), deployment and management tools. The CSUs of PaaS services have control over the applications and possibly some of the hosting environment settings, but has no or limited access to the underlying infrastructure .
Service Layer: IaaS

For IaaS, the services layer controls the resources underlying the service, including the servers, networks, storage and hosting infrastructure. The services layer then runs the software necessary to makes the resources available to the CSUs of IaaS services through a set of service interfaces and resource abstractions, such as virtual machines and virtual network interfaces.
Service Layer: NaaS

For NaaS, the services layer uses the underlying networking and transport facilities to deliver networking services in a cloud environment. Examples are network virtualization services like VPNs (see Ecosystems NaaS definition).
Resources & Network Layer

The Resources and Network layer is where the physical resources reside. This includes equipment typically used in a data center such servers, networking switches, storage, etc. It also represents and houses the cloud core transport network functionality which is required to provide underlying network connectivity between the CSP and the CSUs. CSUs can obtain cloud services through different network access devices, such as desktop computers, laptops, mobile phones, and mobile Internet devices. The connectivity to cloud services is normally provided by CSPs. Note that for a CSP to provide services consistent with the level of SLAs offered to the CSUs, it may require dedicated and/or secure connections between CSUs and CSPs.
Cross-Layer Functions
The Cross-Layer functions perform overall system management (i.e., operations, administration, maintenance and provisioning (OAM&P)) and monitoring, and provide secure mechanisms. Secure mechanisms provide protections from threats to cloud computing services and infrastructure.
Secure mechanisms are required by both CSUs and CSPs to create a secure cloud environment.
Contents


CC Reference Architecture:
Functional Blocks
Based on the layering framework shows the major functional blocks of the Cloud Computing Reference Architecture. It is recognized that CSPs will decide which functional blocks are appropriate to their business, and how the chosen functional blocks are implemented.
CC Functional Reference Architecture

User Layer User Function Partner Function
Administrator Function
Cross-Layer Functions
Access Layer
Endpoint Function
Inter Cloud Function
Operational Management Function
SaaS / CaaS
Services Layer
PaaS IaaS NaaS
Service Orchestration
Cloud Performance Function
Security & Privacy Function
Resource Orchestration
Resources & Network Layer
Pooling & Virtualization Physical Resources
VN
VS
VM
Software & Platform Assets
Virtual Path Virtual Circuit Core Transport Network
Intra Cloud Network
Storage
Computing
Inter Cloud Network
User Layer
The user layer includes the end-user function, the partner function and the administrator function. User function: The user function supports a CSU to access and consume cloud services Partner function: The partner function enables the CSN relationship with CSP Administrator function: The administrator function supports the enterprise administrator to manage and administrate cloud resources and services within business processes
Access Layer
The access layer includes the endpoint function and the inter-cloud function.
Access Layer:
endpoint function (1/3)
The endpoint function controls cloud traffic and improves cloud service delivery.
This function, which has some similarity with the NGN border gateway function (located at the edge of the network), can perform traffic classification, packet marking and firewall.
Access Layer:
This function also provides internet domain names, ports and/or Internet addresses that are published to the user as endpoints from where the user can (a) view and (b) request services.
A published endpoint may internally route or transform the incoming service request to one or more service endpoints, based on CSP policy in effect. For instance, a published endpoint may forward the request to a location nearest to the requestor.
Access Layer:
The endpoint function can include a subscription/publication functionality that is a subscribe-notify feature for publishing, and for obtaining notification of different cloud services and resource information from CSPs. The endpoint function may route the requests to the inter-cloud function to be routed to external CSPs.
Access Layer: Inter-cloud function (1/3)

Cloud services are expected to be offered by CSPs on a global basis. To enable delivery of such services ubiquitously, a CSP will have to establish inter-cloud connections with other CSPs who offer these services in areas that are not within the preview of the original CSP. Within functional view, the inter-cloud function is used to support the inter-cloud role as described in Cloud Ecosystem.

The inter-cloud function addresses different aspects of delivering any cloud service across two or more CSPs, including SLAs, resource management, performance, reliability and security; OAM&P; ordering and charging; service brokering and environmental sustainability.

The scope of the inter-connection is between two cloud domains (operated by two CSPs). The inter-cloud function can be implemented in different manners, including inter-cloud peering, inter-cloud service broker and intercloud federation.
Inter-cloud function:
Inter-Cloud Service Broker (1/3)
The Inter-cloud function can be implemented as inter-cloud service broker (ISB). In this case, it provides brokering service functions to CSPs or CSUs. According to the requirements of the Inter-Cloud Service Broker (ISB) capability, the Inter-Cloud Service Broker (ISB) provides and execute services of three categories:
Service Intermediation Service Aggregation Service Arbitrage
Service Intermediation: The ISB enhances a given service by improving some specific capability and providing value-added services to CSUs. Examples of capability improvements include management of the access to cloud services, identity management, performance reporting, security enhancements, etc. Service Aggregation: The ISB combines and integrates multiple services into one or more new services. The ISB provides data integration and ensures the secure movement of data between the CSUs and CSPs. Service Arbitrage: Service arbitrage is similar to service aggregation except that the services being aggregated are not fixed. In this case, the ISB has the flexibility to choose services from multiple sources. For example, the ISB can use a creditscoring service to measure and select the source with the best score.
When a CSP plays the Inter-cloud Service Broker role, the requesting entity (CSU or CSP) continue to access the brokered services via the Endpoint Function, however the implementation of the Access Layer will decide whether to serve the request locally, or route them to external CSPs via the Inter-cloud function. The Inter-cloud function receives the requests by the Endpoint function, analyses the requests, selects appropriate service logics and function patterns, executes related operations, then invokes the concrete cloud services and resources from external CSPs through cloud service adapters (by sending cloud service adaptation requests to CSPs and receiving cloud service adaptation responses from CSPs).
Inter-Cloud Peering
Inter-cloud peering happens when two CSPs interact with each other using already established interfaces. Each CSP could invoke the interfaces offered by the other CSP, when needed, to perform the functions that the CSP would like to delegate to its peer CSP.
Inter-Cloud Federation (1/3)
Inter-Cloud federation capability provides an alliance among several CSPs in which mutually trusted clouds join together logically thru agreed-upon interfaces.
Inter-Cloud federation allows a CSP to dynamically outsource resources to other CSP in response to demand variations.
Inter-Cloud federation manages the consistency and the access controls when two or more independent CSPs share either authentication, data, computing resources, command and control, or access to storage resources.
Inter-Cloud federation shall provide the identity syndication to support federated authentication across all sources and federated user across the different CSPs.
The Inter-Cloud Function supports federation capability and may include federation initiator which initiates operations within a federation relationship and federation target which processes operations within a federation relationship.
Services Layer
The Services Layer includes the service orchestration function and provides cloud services.
Services Layer:
Services Orchestration Function (1/2)
Cloud Service Orchestration is the process of deploying and managing Cloud Services". Cloud Services are implemented using cloud service interfaces; examples are
Simple Object Access Protocol (SOAP), Representational state transfer (REST), HyperText Markup Language(HTML) rendered pages, etc.
Services Layer:
This function is required to provide mechanisms for:
composing services (services provided by the CSP as well as services from other CSPs) to create new composite services;
Composing services is the process of generation of the service logic (i.e. the logic of the service to be provided by the CSP).
executing composite services.

Executing composite services includes parsing and running the service logic.
Services Layer:
This function also provides message routing and message exchange mechanisms within the Cloud architecture and its different components as well as with external components.
Message routing can be based on various criteria, e.g. context, policies. The message exchange mechanisms control the message flows between CSUs, CSP (internally) and externally with other CSPs via the Inter-cloud Function.
Services Layer:
Cloud Services
The Services Layer provides instances of IaaS, PaaS, SaaS, CaaS, NaaS service categories and any composition of these services. Examples of such services are:
The ability for users to request, configure, and execute one or more VMs, The ability for users to invoke a software application from within a web browser, The ability for developers to invoke programming interfaces through a cloud interface.
Resources & Network Layer:

Resource Orchestration
Resource Orchestration is defined as the management, monitoring, scheduling of computing, storage, and network resources into consumable services by the upper layers and users. Resource Orchestration controls the creation, modification, customization and release of virtualized resources. It holds capability directories about what is possible within a cloud segment, based upon the total resource capacity and the incremental allocations that have been done for currently honoured requests.
Resources & Network Layer:

Pooling & Virtualization
Pooling and virtualization of physical resources are essential means to achieve the on-demand and elastic characteristics of cloud computing. Through these processes, physical resources are turned into virtual machines, virtual storages, and virtual networks. These virtual resources are in turn managed and controlled by the Resource Orchestration based on user demand. Software and Platforms assets in Pooling & Virtualization Layer are the runtime environment, applications and other software assets used to orchestrate and implement cloud services. Software & platform assets is the architectural block that represents the use oftraditional software assets to implement the cloud services layer
Resources & Network Layer: Physical Resources

Physical Resources refer to the computing, storage, and network resources that are fundamental to providing cloud services.
These resources may include those that reside inside cloud data centers (e.g., computing servers, storage servers, and intra-cloud networks) and those that reside outside of a data center, typically networking resources such as inter-cloud networks and core transport networks.
Cross-Layer Functions (1/3)

The Cross-Layer functions include
security& privacy, cloud operational management, and cloud performance functions.

This layer caters to a CSPs need for monitoring of resources, and generates a consolidated view of current resource allocations and how efficiently the resources are being utilized.
Resource monitoring allows the CSP to exercise load balance to ensure the performance of cloud services. It also flags network and service related problems such as hardware or software resource failures, missing SLA targets or if a CSPs network is experiencing security violations or other forms of compromised situation.

As the point that collects availability, performance and security information, it is central source of information on a CSPs service excellence.
Cross-Layer Functions:
Security & Privacy (1/3)
This section describes a high-level summary of security and privacy functions with regard to the Reference Architecture. For further details, please refer to the Security output document. Cloud security and privacy refer to the cross-layer functions responsible for applying security related controls to mitigate the potential threats in cloud computing environments. CSPs (CSPs) need to consider applicable privacy requirements and regulations. Security threats can be dived into two areas, threats for CSUs and threats for CSPs.
Threats for CSUs Responsibility Ambiguity Loss of Governance Loss of Trust CSP Lock-in Unsecure Customer Access Lack of Information/Asset Management Data loss and Leakage Threats for CSPs Responsibility Ambiguity Protection Inconsistency Evolutional Risks Business Discontinuity Supplier Lock-in License Risks Bylaw Conflict Bad Integration Unsecure Administration API Shared Environment Hypervisor Isolation Failure Service Unavailability Data unreliability Abuse Right of CSP
Cloud Security and Privacy use a set of requirements to mitigate the above listed threats. These requirements cover actions and technologies that are deployed for both CSUs and CSPs. (Details of the requirements can be found in the Cloud Security output document) Security and Privacy tie closely with SLA and service monitoring which often depend on the user identity. The identity information must be propagated in the cloud computing environment, to enable linking SLA and services with identity. For instance, to regulate the consumed network bandwidth to the total bandwidth the user has requested for, the monitoring point must associate the users IP address with the identity that comes from user authentication.
Cloud Performance Function
The Cloud Performance Function serves the following purposes:
Aggregates or summarizes cloud network information for the management node Used to make service routing decisions by the Published Endpoints Monitors customer SLAs, and flags SLA violations Point of monitoring and control for the management node
Cloud Operational Management Function
Power Management Configuration Function Charging
Cloud Operational Management Function: Power Management

Power Management is to be seen as a part of the Management function and as such it is a cross layer function. Power management represents a collection of IT processes and supporting technologies geared toward optimizing data center performance against cost and structural constraints. This includes increasing the deployable number of servers per rack when racks are subject to power or thermal limitations and making power consumption more predictable and easier to plan for.
Cloud Operational Management Function:

Configuration Function
This function comprises of databases and provisioning information using which cloud services can be customized. It will include user databases for authentication and authorization, policy servers for defining end-user SLAs, geographical or legal customizations on services, name servers for describing virtual and physical hosts along with cloud domain names, automatic configuration servers for devices that can be auto configured when they are powered on and TFTP or HTTP based software servers from where prior loaded images can be downloaded. Cloud Configuration Databases comprise of configuration information that is necessary to coordinate cloud services.
Cloud Operational Management Function: Charging (1/2)

Charging is critical for an operational cloud service platform. Detailed logs of the users resource consumption should be correctly collected and retained. The charging records should carry comprehensive information about how customers use the infrastructure resources
Cloud Operational Management Function: Charging (2/2)

Specifically, the resource management system should collect the following charging data:
Computation consumption usage. This should reflect how much computation resources have been used by the customers. Data of computation consumption include the number of CPUs and the corresponding using time. Storage consumption usage. This should show how much storage resources have been used by the customers. Network bandwidth usage. This should keep the information of how much bandwidth has been used by the customers. Other information that may affect charging, such as delivered QoS. Other information for statistics.
Contents


Service Architecture for DaaS:

Main functions of the DaaS service architecture:
Connection Brokering (CB) function
The main functions in the DaaS service architecture are given as follows: Connection Brokering (CB) function
A connection broker is a software program that allows a CSU to connect to an available virtualized desktop. The connection broker performs tasks which include: user authentication and license verification to validate the user and users software; management of a virtual machine (VM) for user assignment; server monitoring to measure the activity level of a given VM, and protocol coordination to coordinate on the protocol to be used between user and server. The connection broker can also support the connection between a backup storage and virtualized desktop servers.

Main functions of the DaaS service architecture:
Resource Pooling function
Resource Pooling function
In order to provide on-demand virtualized desktop services, a resource pool can manage three different types of high-capacity software resources such as operating systems (OS), applications and user profiles. These software resources are transferred to a certain VM in streaming form timely and run on the VM. A resource pool can offer provisioning information regarding the software resources on request by a CB. A user profile contains individual information about hardware configuration (i.e. CPU, RAM, I/O), used OS, selected applications, and users computing environment information (i.e. display resolution, Internet access way).

Main functions of the DaaS service architecture
VM Infrastructure function
VM Infrastructure function
The main role of the VM infrastructure is to support hardware resources and create VMs. In a virtualized desktop server, a virtualization functionality called hypervisor is highly necessary to employ hardware resources efficiently. A hypervisor can abstract physical hardware resources and assign them to higher level of software dynamically. Consequently, the VM infrastructure provides VMs the virtualized desktops- on which users software is operated. It is recommended that the VM Infrastructure consists of a cluster environment with high availability features, and within which many running VM instances are created from the same VM template with pre-defined configuration parameters.

Main functions of the DaaS service architecture
Virtual desktop delivery function
Virtual desktop delivery function
This function involves encapsulating and delivering either access to an entire information system environment or the environment itself to a remote client device through the network. The virtual desktop delivery protocol (VDDP) is the core component to realize this function and provides the communication channels between user terminals and servers for DaaS in order to transfer all the interaction information. This information includes display information, control and configuration information, monitoring information etc.
Conceptual diagram of the DaaS service architecture

Virtual Desktop
VM Infrastructure Vir tual Desktop Ser ver User B

User B
VM VM VM visor Hyper VM
Hyper visor Hardware Hardware Virtual Desktop Deliver y Protocol (VDDP)
VM VM VM VM VM VM
Resource Pool Client Connection Broker

Resource Provision
User Profile Pool
User A User B User C User D
User Authentication License Verification VM M onitoring/ M anagement
Application Pool
User B
Protocol Coordination
OS Pool
Windows 7
Service User
Service Provider
Interaction process for DaaS (1/2)

The various steps of the interaction process for DaaS are as follows: A user accesses a CB through a security protocol (such as SSH or TLS) and the CB validates the user with a user-ID and associated password. The CB identifies a corresponding user profile and, in order to assign a VM, a provisioning function helps the CB to search the VM that satisfies users hardware configuration and is optimal to computing environment. In case there is no proper VM, the CB requests the VM infrastructure to create a VM by sending information of hardware configuration. After a VM is assigned or created, the CB applies the user profile to the VM including installation of OS and applications to construct a virtualized desktop.
Interaction process for DaaS (2/2)

A connection to deliver a corresponding virtualized desktop is created in the VM infrastructure and the information of the connection is dispatched to the CB. The CB sends the connection information to the user and the user connects to the desktop in the VM infrastructure. The user communicates with the virtualized desktop through the network using the virtualized desktop delivery protocol (VDDP). The user does execute a log-off operation to prevent the elimination of user data when he or she terminates a virtualized desktop service. During the log-off operation, the CB updates the modified user profile in a user profile pool to keep the most recent information and returns the VM whose state becomes available.
Cloud Computing Courses

Fundamental Cloud Ecosystem Cloud Architecture Cloud Infrastructure Cloud Resource Management Cloud Security Specialization Saas and Web Applications Virtualization Platform and Storage Management Cloud Profiles Inter-cloud
Thank You
hamdani2@telkom.co.id

3 Cloud Architecture ITTelkom 11 Agt 2012 by Arief H Gunawan

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

3 Cloud Architecture ITTelkom 11 Agt 2012 by Arief H Gunawan

Hochgeladen von

Copyright:

Verfügbare Formate

Cloud Architecture

(half day edition)

Cloud computing reference architecture Functional blocks

Service architecture for desktop as a service (DaaS)

Cloud computing reference architecture Functional blocks

Service architecture for desktop as a service (DaaS)

Cloud architecture requirements

Cloud architecture requirements: 1

Cloud architecture requirements: 2

Cloud architecture requirements: 3

Cloud architecture requirements: 4

Cloud architecture requirements: 5

Cloud architecture requirements: 6

Cloud architecture requirements: 7

Cloud architecture requirements: 8

Cloud architecture requirements: 9

Cloud architecture requirements: 10

Cloud architecture requirements: 11

Cloud architecture requirements: 12

Cloud architecture requirements: 13

Cloud architecture requirements: 14

Cloud computing reference architecture Functional blocks

Service architecture for desktop as a service (DaaS)

Cloud Layering Framework

User Layer (1/2)

User Layer (2/2)

The CSU typically consumes services in five service categories:

Service Layer: SaaS and CaaS

Service Layer: PaaS

Service Layer: IaaS

Service Layer: NaaS

Resources & Network Layer

Cloud computing reference architecture Functional blocks

Service architecture for desktop as a service (DaaS)

CC Functional Reference Architecture

Inter Cloud Function

Operational Management Function

PaaS IaaS NaaS

Cloud Performance Function

Security & Privacy Function

Resources & Network Layer

Pooling & Virtualization Physical Resources

Software & Platform Assets

Virtual Path Virtual Circuit Core Transport Network

Intra Cloud Network

Inter Cloud Network

Access Layer: Inter-cloud function (1/3)

Access Layer: Inter-cloud function (2/3)

Access Layer: Inter-cloud function (3/3)

executing composite services.

Resources & Network Layer:

Resources & Network Layer:

Resources & Network Layer: Physical Resources

Cross-Layer Functions (1/3)

Cross-Layer Functions (2/3)

Cross-Layer Functions (3/3)

Cloud Operational Management Function: Power Management

Cloud Operational Management Function:

Cloud Operational Management Function: Charging (1/2)

Cloud Operational Management Function: Charging (2/2)

Cloud computing reference architecture Functional blocks

Service architecture for desktop as a service (DaaS)

Service Architecture for DaaS: