Introduction and Architecture Overview IBM Cloud Computing Reference Architecture 2.0
Authors:
Michael Behrendt
Bernard Glasner
Petra Kopp
Robert Dieckmann
Gerd Breiter
Stefan Pappe
Heather Kreger
Ali Arsanjani
Document History
Document Location
This is a snapshot of an on-line document. Paper copies are valid only on the day they are printed. Refer to the author if you are in any doubt about the currency of this document.
Revision History
Date of this revision: 02-28-11 Date of next revision: to be defined
Revision Number Revision
Date
Summary of Changes Changes
marked
1.0 02-28-11 1.0 Submission to Open Group N
Contents
Document History (2)
Document Location (2)
Revision History (2)
1.Introduction (5)
1.1.Description (5)
1.2.Purpose (5)
1.3.How to use this work product? (6)
1.4.SOA and Cloud (6)
https://www.doczj.com/doc/0c13653555.html,ing the SOA RA with the CCRA (8)
2.IBM Cloud Computing Reference Architecture (CC RA) Overview (11)
2.1.Introduction (11)
2.2.Roles (12)
2.2.1.1.Cloud Service Consumer (12)
2.2.1.2.Cloud Service Provider (12)
2.2.1.3.Cloud Service Creator (12)
2.3.Architectural Elements (13)
2.3.1.Cloud Service Consumer (13)
2.3.1.1.Cloud Service Integration Tools (13)
2.3.1.2.Consumer In-house IT (14)
2.3.2.Cloud Service Provider (15)
2.3.2.1.Cloud Services (15)
2.3.2.1.1.Cloud service models (16)
2.3.2.1.1.1.Infrastructure-as-a-Service (17)
2.3.2.1.1.2.Platform-as-a-Service (17)
2.3.2.1.1.3.Software-as-a-Service (17)
2.3.2.1.1.4.Business-Process-as-a-Service (17)
2.3.2.1.2.Cloud service creation & ecosystem aspects (17)
2.3.2.2.Infrastructure (19)
https://www.doczj.com/doc/0c13653555.html,mon Cloud Management Platform (CCMP) (21)
2.3.2.3.1.BSS – Business Support Services (24)
2.3.2.3.2.OSS – Operational Support Services (26)
2.3.2.4.Security, Resiliency, Performance & Consumability (27)
2.3.3.Cloud Service Creator (28)
2.3.3.1.Service Development Tools (28)
https://www.doczj.com/doc/0c13653555.html, Reference Architecture: Architectural Principles and Related Guidance (29)
https://www.doczj.com/doc/0c13653555.html, RA-Specific Architectural Principles (29)
3.1.1.Origins of the Term Architectural Principle (29)
3.1.2.Principle 1: Design for Cloud-Scale Efficiencies (30)
3.1.3.Principle 2: Support Lean Service Management (31)
3.1.4.Principle 3: Identify and Leverage Commonalities (33)
3.1.5.Principle 4: Define and Manage Cloud Services generically along their Lifecycle (34)
4.References (36)
1. Introduction
This document serves as the definition of the IBM Cloud Computing Reference Architecture (CC RA).
A Reference Architecture (RA) provides a blueprint of a to-be-model with a well-defined scope, requirements it satisfies, and architectural decisions it realizes. By delivering best practices in a standardized, methodical way, an RA ensures consistency and quality across development and delivery projects.
The mission of the CC RA is defined as follows:
Definition of a single Cloud Computing Reference Architecture, enabling cloud-scale economics in delivering cloud services while optimizing resource and labor utilization and delivering a design blueprint for ?Cloud services, which are offered to customers
?Private, public or hybrid cloud projects
?Workload-optimized systems
?Enabling the management of multiple cloud services (across I/P/S/BPaaS) based on the same, common management platform for enabling economies of scale.
1.1. Description
The CC RA is based on real-world input from many cloud implementations across IBM. The
Architecture Overview Diagram (AOD) provides overview of the fundamental architectural building blocks making up the CC RA. It also defines architectural principles serving as a guideline for
creating any cloud environment.
1.2. Purpose
The Cloud Computing Reference Architecture is intended to be used as a blueprint / guide for architecting cloud implementations, driven by functional and non-functional requirements of the respective cloud implementation. Consequently, the CC RA should not be viewed as fine-granular deployment specification of just a single specific cloud implementation (and its management platform
This document serves the following purposes:
1. This document defines the basic architectural elements and relationships which make up the IBM
Cloud Computing Reference Architecture.
2. This document defines the basic architectural principles which are fundamental for delivering &
managing cloud services.
The audience of the CC Reference Architecture is:
?Development teams implementing cloud services exploiting CCMP capabilities
?Development teams implementing the CCMP delivery & management capabilities for cloud services
Practitioners implementing private clouds for customers
1.3. How to use this work product?
The architecture overview is intended to provide a common, coherent architectural structure which should be used as a basis for any cloud computing project. This allows representing the architecture of any cloud project in a consistent fashion. Existing “legacy” products and tech nologies as well as new cloud technologies can be mapped on the AOD to show integration points amongst the new cloud technologies and integration points between the cloud technologies and already existing ones.
The architectural principles define the fundamental principles which need to be followed when realizing a cloud. These principles need to be followed on all implementation stages (architecture, design, and implementation) and have implications across all work products.
1.4. SOA and Cloud
In order to understand the IBM CCRA it is important to understand the relationship between SOA and Cloud, not only at an architectural level, but also at a solution and service level.
Service oriented architecture (SOA) is defined by The Open Group
(https://www.doczj.com/doc/0c13653555.html,/soa/soa/def.htm) to be “an architectural style that supports service orientation. Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services.”
According to NIST (https://www.doczj.com/doc/0c13653555.html,/groups/SNS/cloud-computing/cloud-def-v15.doc), “Cloud Computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models.”
The Service models are Cloud Infrastructure as a Service, Cloud Platform as a Service, and Cloud Software as a Service. The service models, and the fact that cloud computing is discussed in terms of the creation, delivery and consumption of cloud services, means cloud computing supports service orientation. Enterprises expose infrastructure, platforms and software as services as part of SOA solutions today. Certainly Software as a Service is not new and has been a popular topic for years.
The cloud Deployment models are Private, Community, Public, and Hybrid. These deployment models define the scope of the cloud architecture and solution, does the cloud solution exist strictly within the organization boundaries (private), across organization boundaries (public), or a combination (Hybrid). Certainly these scopes have been seen in SOA solutions before Cloud (while there was not a well known architectural model for them as there is in cloud computing), there are SOA solutions that exist strictly within an enterprise, or between businesses across enterprise boundaries (B2B). In fact one of the key values of SOA was to develop SOA solutions with services that are integrate between business partners, enabling outsourcing, simplifying integration and increasing agility, much like the Hybrid model. Cloud computing enables this paradigm by adding cloud-characteristics to the services being delivered & consumed.
The essential characteristics for Cloud Computing are on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured Service. These characteristics can be found in
requirements and SOA solutions in various organizations today, although these characteristics are optional for SOA and mandatory for cloud.
Usually, a single SOA solution does not have all of these are characteristics simultaneously, unless it is a very mature organization leveraging SOA. For these organizations, each of these solutions had to be built in its entirety for that organization. The SOA solution and management of it must be built from scratch, and is not generally shared amongst organizations. Reuse is generally within an organization or an industry, not between organizations and entire communities. Service delivery and consumption aspects are a small part of the requirements for the SOA solution.
What is new about cloud is that instead of supporting these requirements per solution, the industry is trying to …standardize? how these requirements are being met to enable cloud computing. Cloud architectures require a set of capabilities and ABBs to meet the NIST essential characteristics that are optional in SOA. In addition, these ABBs may be implemented in Cloud specific ways to handle scale, cost optimization and automation.
This discussion shows that Cloud computing architectures are Service Oriented architectures and adhere to architectural style that supports service orientation. Cloud solutions are SOA solutions.
The Open Group defines a service:
“ A service:
?Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data, consolidate drilling reports)
?Is self-contained
?May be composed of other services
?Is a “black box” to consumers of the service “
Cloud services, according to The Open Group definition, are SOA services. However, not all SOA services are Cloud service because they require automated deployment and management as well as offering support in order to support the Cloud characteristics.
On the architecture continuum (see TOGAF at
https://www.doczj.com/doc/0c13653555.html,/architecture/togaf9-doc/arch/chap39.html), Cloud architectures are more concrete than The Open Group?s SOA reference architecture
(https://www.doczj.com/doc/0c13653555.html,/projects/soa-ref-arch/uploads/40/19713/soa-ra-public-050609.pdf), a domain architecture scoped to service delivery and management. Principles and architectural decisions have been premade already to enable the Cloud computing architecture to be self service, network accessible, and scalable. Architectural building blocks have already been identified for Cloud solution architects to use for operational and business support. In some cases, Cloud service providers may provide well defined, maybe even standardized, management and security support and services.
For cloud, some service identification has been done (reusable, utility services, for example, to control VMs and deploy/undeploy applications or services) and implementations of services may be available from an existing services ecosystem. The existence of this services ecosystem and concrete architecture makes SOA via cloud simpler for service consumers to adopt because the designs and implementations have been provided.
The benefit of recognizing the heritage of Cloud from SOA is that the existing experience over the last 5 years and standards already available for SOA and SOA solutions can be applied to Cloud Computing and Cloud solutions.
SOA standards in The Open Group that can be applied to Cloud include:
?The Open Service Integration Maturity Model – this model helps determine the level of service use in an organization, these levels apply to the use of cloud services. Cloud computing can be seen as the …Virtualized” and “Dynamically reconfigurable” levels.
?The SOA Ontology defines service and SOA concepts which can be used as a basis for describing cloud services, though extension Ontologies should be developed for cloud..
?The SOA Reference Architecture defines the functional and cross cutting concerns and ABBs for SOA, which also applies to Cloud. This standard has been used as a basis for the IBM CCRA.
?The SOA Governance Framework defines a governance reference model and method that applies to the development of cloud services and solution portfolio and lifecycle management. Best
practices for governance of Cloud solutions will need to be developed in addition to this standard.
?Security for Cloud and SOA, a joint workgroup between SOA and Cloud Workgroups in The Open Group, defines security considerations and ABBs for both Cloud and SOA.
?SOCCI, another joint SOA and Cloud Workgroup in The Open Group defines the architecture for exposing infrastructure as a service for both SOA and Cloud solutions.
Certainly functions that were optional for SOA solutions are now required for Cloud solutions, like virtualization, security across business boundaries, and service management automation. New functions and requirements are getting in focus with cloud driving experiences from the SOA world to the next level.
1.5. Using the SOA RA with the CCRA
The SOA RA
(https://www.doczj.com/doc/0c13653555.html,/projects/soa-ref-arch/uploads/40/19713/soa-ra-public-050609.pdf),), as being standardized by The Open Group, applies to Cloud architectures and is the underlying architecture for the IBM CCRA.
The functional concerns: operational systems, service components, services, business processes and consumer interfaces; all exist in and are relevant to functional concerns for cloud architecture?s
For the Cloud architecture, there has been special focus on the:
?Operational Layer: Infrastructure is part of the operational systems layer, but often highlighted in Cloud architectures because Cloud imposes new requirements on infrastructure to enable broad network access, resource pooling, rapid elasticity, virtualization and scalability.
?Service Layer: The common cloud service types, *aaS, are identified in the services layer. These cloud service types, like other services, use and sometimes expose assets in the Operational
systems layer. For cloud services, which assets are exposed is often the focus of the service type, ie within operational systems, hardware infrastructure is exposed as IaaS, and middleware is
exposed as PaaS, and business process as BPaaS.
?Business Process: Business processes participate in a Cloud solution much like they do in SOA solutions, they can be provided as a service (BPaaS) or be the consumer of services (whether they care cloud services or not). Additionally, business processes within a cloud provider organization need to be restructured and streamlined in novel ways to meet much faster time-to-deliver,
time-to-change and cost objectives..
?Consumer Layer: The consumer layer is more strictly and carefully separated from the services and service provider to allow pooling and substitution of cloud services or providers.
The cross cutting concerns in the SOA RA: integration, quality of service, information and governance: are important concerns for all cloud architectures and solutions, just like they are for SOA. The fact that they are cross cutting means that each of the functional layers may have interactions with capabilities in the cross cutting layers.
For the Cloud architecture, there has been special focus on the:
?Quality of Service (QOS) layer: The Quality of Service cross cutting concern has additional significant requirements for Cloud for management and security in order enable NISTs on-demand self-service and measured service requirements as well as IBM?s requirements for resiliency,
security, performance, automated management, operational, and business support. The
management support can be represented as a Common Cloud Management Platform in the SOA RA QOS layer, which includes support for operational and business support services, aka OSS and BSS. This is critical for driving economies-of-scale by delivering many cloud services based on the same foundation.
?Governance for cloud solutions will also have some unique patterns of requirements needed to support governance across organizational boundaries.
For the cloud ecosystem, they cloud service consumers, providers and creators are the common high level roles identified in the cloud architectures.
It is important to look at Cloud in the context of SOA, and Cloud solutions in the context of the larger SOA solutions underpinning them. This diagram shows the QOS layer details that are essential to understand for
Cloud, as well as the *aaS and Infrastructure layers
The cross cutting concerns for integration and information are still important and must be considered in the development of any Cloud architecture and solution architecture. However, cloud does not introduce any new principles or concerns to these cross cutting layers.
To make it easier to focus on the Cloud concerns rather than the SOA concerns, we can lift the Cloud concerns into its own diagram, as we show in the remainder of this document.
The concepts and architectural elements not depicted in the CCRA are still implied and present via its SOA RA heritage.
The cross cutting concerns for integration and information are still important and must be considered in the development of any Cloud architecture and solution architecture. However, cloud does not introduce any new principles or concerns to these cross cutting layers.
To make it easier to focus on the Cloud concerns rather than the SOA concerns, we can lift the Cloud
concerns into its own diagram, as we show in the remainder of this document.
2. IBM Cloud Computing Reference Architecture (CC RA) Overview
2.1.
Introduction
The IBM Cloud Computing Reference Architecture (CC RA, see figure 2) defines the fundamental
architectural elements constituting a cloud computing environment. The CC RA is structured in a modular fashion in a sense that on its highest level of abstraction, the main roles and the corresponding architectural elements are defined allowing to drill down for each of these elements as needed. Later sections of this document will describe detailed versions of this IBM Cloud Computing Reference Architecture Overview diagram, which provide a more fine-grain view of the high-level architectural elements of the overall CC RA. As a result of specifying the CC RA, a base terminology is established, which should be used as a reference for any other cloud computing related effort.
The following sections will describe each architectural element of the CC RA depicted in figure 3 in detail.
Governance
Security, Resiliency, Performance & Consumability
Cloud Service Creator
Cloud Service Consumer
Cloud Service Provider
Common Cloud
Management Platform (CCMP)
Operational Support Services (OSS)
Cloud Services
Infrastructure-as-a-Service
Platform-as-a-Service
Software-as-a-Service
Business-Process-as-a-Service
Business Support Services (BSS)
Cloud Service Integration Tools
Consumer In-house IT
Service Creation Tools
Infrastructure
Existing & 3rd party services, Partner Ecosystems
Figure 1: IBM Cloud Computing Reference Architecture Overview
2.2. Roles
The IBM Cloud Computing Reference Architecture defines three main roles: Cloud Service Consumer, Cloud Service Provider and Cloud Service Creator. Each role can be fulfilled by a single person or can be fulfilled by a group of people or an organization. The roles defined here intend to capture the common set of roles typically encountered in any cloud computing environment. Therefore it is important to note that depending on a particular cloud computing scenario or specific cloud implementation, there may be project-specific sub-roles defined.
2.2.1.1. Cloud Service Consumer
A cloud service consumer is an organization, a human being or an IT system that consumes (i.e., requests, uses and manages, e.g. changes quotas for users, changes CPU capacity assigned to a VM, increases maximum number of seats for a web conferencing cloud service) service instances delivered by a particular cloud service. The service consumer may be billed for all (or a subset of) its interactions with cloud service and the provisioned service instance(s).
A service consumer can also be viewed as a kind of super-role representing the party consuming services. For example, in case a credit card company is using some cloud services, the company as a whole is a service consumer relative to the provider. Within the service consumer role more specific roles may exist, such as a technical role responsible for making service consumption work from a technical perspective; and there might be a business person on the consumer side who is responsible for the financial aspects. Of course, in more simplified public cloud scenarios all of these consumer-centric roles could be collapsed into a single person, but the roles still exist.
The cloud service consumer browses the service offering catalog and triggers service instantiation and management from there. There may be cases where the interaction with the service delivery catalog is tightly embedded within the actual cloud service. In particular this is pretty common for SaaS and BPaaS cloud services where application-level virtualization is implemented, e.g. LotusLive.
2.2.1.2. Cloud Service Provider
The Cloud Service Provider has the responsibility of providing cloud services to Cloud Service Consumers.
A cloud service provider is defined by the ownership of a common cloud management platform (CCMP). This ownership can either be realized by truly running a CCMP by himself or consuming one as a service. People acting in the role of a Cloud Service Provider and a Cloud Service Consumer at the same time would be a partner of another cloud service provider reselling cloud services or consuming cloud services and adding value add functionality on top, which would in turn be provided as a cloud service.
Although defined as a separate role, it would also be possible that a Cloud Service Provider has Cloud Service Creators in the same organization, i.e. it is not necessary that Cloud Service Provider and Cloud Service Creator are in separate organizations.
2.2.1.
3. Cloud Service Creator
The Cloud Service Creator is responsible for creating a cloud service, which can be run by a Cloud Service Provider and by that exposed to Cloud Service Consumers. Typically, Cloud Service Creators build their cloud services by leveraging functionality which is exposed by a Cloud Service Provider. Management functionality which is commonly needed by Cloud Service Creators is defined by the CCMP architecture. A Cloud Service Creator designs, implements and maintains runtime and management artifacts specific to a cloud service.
Just like the Cloud Service Consumer and the Cloud Service Provider, the Cloud Service Creator can be an organization or a human being. For example, an ISV company developing a cloud service is a Cloud
Service Creator , whereas obviously there could be 100?s of employees within that particular Cloud Service Creator incarnation, each of them taking on a specific business or technically focused sub-role.
It is also typical that that operations staff responsible for operating a cloud service is closely integrated with the development organization developing the service (this integration is commonly referred to as “DevOps”). This is an important aspect to achieve the delivery efficiency expected from cloud services as it allows a very short feedback loop to implement changes in the cloud service which benefit the operational efficiency of the cloud service.
2.3. Architectural Elements 2.3.1. C loud Service Consumer
Governance
Security, Resiliency, Performance & Governance
Cloud Service Creator
Cloud Service
Consumer
Cloud Service Provider
Common Cloud
Management Platform (CCMP)
Operational Support Services (OSS)
Cloud Services
Infrastructure-as-a-Service
Platform-as-a-Service
Software-as-a-Service
Business-Process-as-a-Service
Business Support Services (BSS)
Service Creation Tools
Infrastructure
Existing & 3rd party services, Partner Ecosystems
Cloud Service Integration Tools
Consumer In-house IT
Infrastructure
Middleware Applications Business Processes Consumer Administrator
Consumer Business Manager
Consumer End user
Service Integrator
Service Management
Figure 2: IBM CC RA – Cloud Service Integration Tools & Consumer In-house IT
2.3.1.1. Cloud Service Integration Tools
From the perspective of a Cloud Service Consumer, it is important to be able to integrate cloud services with their on-premise IT. The functionality of Cloud Service Integration Tools is specifically relevant in the context of hybrid clouds, where seamless integrated management, usage and interoperability of cloud services in integration with on-premise IT is critical.
2.3.1.2. Consumer In-house IT
Besides IT capabilities consumed as cloud services, consumers of such IT may continue to have in-house IT, which can be managed in a traditional non-cloud fashion. In case functionality of the existing in-house IT should be integrated with cloud services consumed from a cloud service provider, the aforementioned cloud service integration tools are required. Consumer in-house IT exists across all layers of the technology stack (infrastructure, middleware, applications, business processes, service management), therefore integration with cloud services can take place on each of these layers.
2.3.2. C loud Service Provider
2.3.2.1. Cloud Services
Governance
Security, Resiliency, Performance & Consumability
Cloud Service Creator
Cloud Service
Consumer
Cloud Service Provider
Common Cloud
Management Platform (CCMP)
Operational Support Services (OSS)Cloud Services
Infrastructure-as-a-Service
Platform-as-a-Service
Software-as-a-Service
Business-Process-as-a-Service
Business Support Services (BSS)
Cloud Service Integration Tools
Consumer In-house IT
Service Creation Tools
Infrastructure
Existing & 3rd party services, Partner Ecosystems
I n f r a s t r u c t u r e M g m t I n t e r f a c e s
P l a t f o r m M g m t I n t e r f a c e s
S o f t w a r e M g m t I n t e r f a c e s B P M g m t I n t e r f a c e s
API
API
API
API
Figure 3: IBM CC RA – Cloud Service Details
Cloud Services can represent any type of (IT) capability which is provided by the Cloud Service Provider to Cloud Service Consumers, implementing all cloud characteristics (self-service access, network-based access, served out of a resource pool, elastic, pay-per-use). There are four categories of Cloud Services: Infrastructure, Platform, Software or Business Process Services. In contrast to traditional (IT) services, cloud services have attributes associated with cloud computing, such as a pay-per-use model, self-service usage, flexible scaling & shared of underlying IT resources.
The management functions defined as part of the CCMP architecture are responsible for delivering
instances of Cloud Services of any category to Cloud Service Consumers, the ongoing management of all Cloud service instances from a provider perspective and allowing Cloud Service Consumers to manage their Cloud Service instances in a self-service fashion.
For all cloud services there is software required implementing cloud service specifics: For IaaS, there are typically hypervisors installed on the managed hardware infrastructure, for PaaS there would a
multi-tenancy enabled middleware platform, for SaaS a (multi-tenancy enabled) end-user application and for BPaaS there typically is a multi-tenancy enabled business process engine.
Depending on the nature of the respective cloud service, there are cloud service specific management interfaces exposed, which are typically used by the management services as defined in the CCMP architecture.
Each cloud service also typically exposes APIs towards the cloud service consumer for programmatic use. Cloud Services can be built on top of each other, e.g. a software service could consume a platform or infrastructure service as its basis, a platform service could consume an infrastructure service as its foundation. However, this is not required, i.e. a software service could also directly be built on top of bare metal infrastructure, clearly inheriting all constraints associated with such an infrastructure. In general, architectural principle #3 postulates to share as much as possible across cloud services with respect to management platform and underlying infrastructure. However, it does not require just one single, fully homogeneous infrastructure – of course, this would be the ideal goal, but given different infrastructure requirements this is not always possible. For example, if a particular cloud service has very specific infrastructure needs (with respect to reliability, latency, throughput, computational performance, hardware platform, etc.) it is clearly allowed to run this cloud service on a dedicated infrastructure (e.g. HPC cloud services would generally run on a purpose-built physical infrastructure for performance and efficiency reasons, they wouldn?t run on virtualized compute cloud service).
In the context of building cloud services on top of each other, it is important to distinguish the sharing of a common OSS/BSS (aka CCMP) structure across multiple cloud services and the usage of the actual cloud service capability by another one. An example for the first aspect would be LotusLive and Compute Cloud exploiting / getting managed by the same OSS/BSS construct. An example for the latter aspect would be LotusLive (SaaS) using the compute capacity of a compute cloud service (IaaS) vs. purchasing their own servers.
In any case, each Cloud Service offered by a Cloud Service Provider is “known” to the BSS & OSS of the Common Cloud Management Platform (otherwise the cloud service wouldn?t be visible via the servic e catalog and ready to be consumed). A cloud service provider offers cloud services as a result of very conscious business decisions, since taking a cloud service to market must be supported by a corresponding solid business model and investments for the development and operations (software & operations staff) of the cloud service.
2.3.2.1.1. Cloud service models
There are four cloud service models within the context of the IBM Cloud Computing Reference Architecture – Infrastructure-, Platform, Software- and Business-Process-as-a-Service.
IaaS, PaaS and SaaS are defined according to the “NIST Definition of Cloud Computing” [7]. There is an IBM-specific definition of BPaaS since that is not defined by the NIST.
Since this is often a point of confusion it is important to note that across all cloud service models the definition is determined by the management scope covered by the provider.
For example, in IaaS “t he consumer does not manage or control the underlying cloud infrastructure […]”, in PaaS “the consumer does not manage or control the underlying cloud infrastructure, network, servers, operating systems, or storage […]”, etc.. So this essentially about the tasks the operations staff of the provider takes on, it is not about the virtualiz ation technology being used. For example, it?s possible to use hypervisor-level virtualization to realize PaaS, SaaS or BPaaS.
2.3.2.1.1.1. Infrastructure-as-a-Service
“The capability provided to the consumer is to rent processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly select networking components (e.g., firewalls, load balancers).”[7]
2.3.2.1.1.2. Platform-as-a-Service
“The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created applications using programming languages and tools supported by the provider (e.g., java, python, .Net). The consumer does not manage or control the underlying cloud infrastructure, network, servers, operating systems, or storage, but the consumer has control over the deployed applications and possibly application hosting environment configurations.” [7]
2.3.2.1.1.3. Software-as-a-Service
“The capability provided to the consumer is to use the provider's applications running on a cloud infrastructure and accessible from various client devices through a thin client interface such as a Web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.” [7]
Software-as-a-Service is also referred to as Applications-as-a-Service since SaaS is essentially about providing applications as a service (vs. software in general). This also includes content services (e.g. video-on-demand) and higher value network services (e.g. VoIP) as typically encountered in communication service provider scenarios.
2.3.2.1.1.4. Business-Process-as-a-Service
“Business process services are any business process (horizontal or vertical) delivered through the Cloud service model (Multi-tenant, self-service provisioning, elastic scaling and usage metering or pricing) via the Internet with access via Web-centric interfaces and exploiting Web-oriented cloud architecture. The BPaaS provider is responsible for the related business function(s).” [Source: IBM MI and IPR definition bridge between Gartner and IDC, Aug 19, 2010]
Examples are processes for employee benefit management, business travel, procurement or also
IT-centric processes such as software testing (where the entire testing process including testing staff is provided as an externally hosted cloud service).
2.3.2.1.2. Cloud service creation & ecosystem aspects
It is very important to understand the relationship between a cloud service and the artifacts which can be developed based on and within the boundaries of an ecosystem-focused IaaS or PaaS cloud service. Bringing any cloud service to market requires corresponding pre-investment, along with respective
metering & charging models in support of the corresponding business model. For example, Amazon EC2 is an eco-system focused IaaS cloud service. The eco-system artifacts in EC2 are VM images. EC2 allows uploading newly created VM images and charging for these VM images. However, each VM instance inherits almost all technical and business decisions already made by Amazon when they decided to take EC2 to market for a specific price-point: Each VM on EC2 is running based on the availability & performance SLAs as defined by EC2, the metrics which can be used to charge for VMs are the ones defined by EC2, the management actions (start, stop, reboot, etc.) consumers can perform on the image are the ones pre-defined by EC2, etc. The fact that Amazon nails down all these characteristics has a very good reason as each characteristic has implications on the costs for offering EC2 – therefore making the characteristics flexible to artifact developers is not possible as it would be very hard to make the corresponding costs flexible and by that very hard to predict.
This illustrates that defining and delivering a cloud service requires nailing down all corresponding functional and non-functional requirements. The artifacts developed on top of an ecosystem-focused cloud service have then only very minimal room to change how these functional and non-functional requirements are addressed. Note that this is not to be viewed as something negative, but rather as something very positive from an eco-system perspective – it is a core value proposition of eco-system focused cloud services to provide pretty strict guidelines with respect to how they can be exploited as this is the main factor driving a reduction in cost of artifact development. The easier it is to develop artifacts for such a cloud service, the more likely the cloud service is successful.
As a summary, it is important to note that there is a difference between developing cloud services as a very conscious technical and business decision vs. developing artifacts on top of eco-system focused cloud services prescribing the boundaries for how these artifacts can run.
Note that sometimes the concept of a “Cloud Service” is also referred to as a “Cloud Service Product”.
2.3.2.2. Infrastructure
Governance
Security, Resiliency, Performance & Consumability
Cloud Service Creator
Cloud Service Consumer
Cloud Service Provider
Common Cloud Management Platform
Operational Support Services
(OSS)
Cloud Services
Infrastructure-as-a-Service
Platform-as-a-Service
Software-as-a-Service
Business-Process-as-a-Service
Business Support Services (BSS)
Cloud Service Integration Tools
Consumer In-house IT
Service Creation Tools
Infrastructure
Server Storage Network Facilities Processor
Memory Nodes Drives
Ephemeral Persistent Internal
External Inter-site
Location
Power
Existing & 3rd party services, Partner Ecosystems
Figure 4: IBM CC RA – Infrastructure Details
“I nfrastructure ” represents all infrastructure elements needed on the cloud service provider side, which are needed to provide cloud services. This includes facilities, server, storage, and network resources, how these resources are wired up, placed within a data center, etc. The infrastructure element is purely scoped to the hardware infrastructure, therefore it does not include software running on top of it such as hypervisors (hypervisors are generally specific to an IaaS offering and therefore belong to that particular cloud service). Consequently it also does not include any virtualization management software.
The decision whether the infrastructure is virtualized or not depends on the actual workload characteristics to be run on the respective infrastructures: For many workloads (e.g. compute & storage as-a-Service) it is very convenient to virtualize the underlying infrastructure, especially since virtualization enables some use cases which can basically not be realized with a physical infrastructure (e.g. all use cases related to image management or dynamic scaling of CPU capacity as needed). For other workloads (e.g. analytics/search) it is required to have maximum compute capacity and use 100?s or 1000?s of nodes to run a single specialized workload. In such cases a non-virtualized infrastructure is more appropriate. As mentioned in 2.3.2.1, this is not a violation of the architectural principles postulating as much as possible commonality across cloud services: While maximum commonality is a core architectural principle, it is allowed to have different infrastructure architectures per workload category. For example, a collaboration, web and infrastructure workload requires a different underlying infrastructure than an HPC or highly transactional workload. However, a requirement in any case is that all of these infrastructure components get managed from a single, central CCMP and CCMP has the ability to place instances of each cloud service on the
corresponding infrastructure (or IaaS service instance, in case a SaaS instance is not directly running on an infrastructure but leverages a IaaS cloud service as an alternative sourcing model).
The less variance the infrastructure has, the more it caters to the standardization needs of a cloud environment. Minimal variance on the infrastructure side is critical for enabling the high degrees of automation and economies of scale which are base characteristics of any cloud environment. However, it has to be acknowledged that in many installed cloud computing environments (specifically private clouds) there are different workloads to be provided as a cloud service and each of these workloads might have special infrastructure needs and might need to support different SLAs. So although the ideal case is total homogeneity on the infrastructure side, it is important to note that there will cloud installations with a few variants in the infrastructure elements (e.g. different HW platforms).
The infrastructure is managed by the OSS as part of the CCMP, whereas the CCMP by itself is also running on the infrastructure.
Note: The physical existence of a virtualized infrastructure on the cloud service provider side is not mandatory, since it is also possible for a cloud service provider to consume infrastructure as a service (and the required CCMP) from a different cloud service provider and put higher value cloud services on top. Clearly, the consuming service provider inherits all SLA constraints defined for the consumed cloud service. So depending on the capability to implement SLAs in software or by using other means, improving SLAs beyond what is provided by the underlying cloud service might be hard (admittedly, there are exceptions to this statement, specifically for cloud workloads which have QoS totally realized in software).
2015国内十大云计算解决方案案例 2015-08-26 eNet&Ciweek/云创 如果你不知道什么是云计算，下面这些案例或许能够给出一个易懂的答案，如果你知道什么是云计算，并且正在试图寻找解决企业当前所遇IT问题的办法，或许以下案例可以给你以思考和启发。 1、金融云案例 ——吴江农村商业银行 背景介绍： “在金融市场竞争十分激烈的吴江，要赢得竞争优势和市场优势，逼得我们要么第一，要么唯一。”吴江农商行董事长陆玉根曾深有感触地说。吴江农村商业银行是中国银监会成立以来全国第一家改制组建的股份制农村商业银行。吴江农村商业银行近年来专注“三农”、服务“三农”，以总资产超560亿元居全市15家银行之首，被称为“吴江人自己的银行”；在苏北、安徽、湖北等地的13家分支机构正成为助推欠发达地区经济发展的生力军，因而也被誉为农村金融的“吴江现象”。 像吴江农村商业银行这样的区域银行在中国不在少数。作为与实体经济接触最为紧密的金融触角，他们担负着将资金血液输送到小微企业部门的重要职责。这些中小银行运营成本高的问题很突出，其中，IT成本居高不下是重要原因。这也制约了金融支持实体经济的能力。有测算指出，在某些银行贷款类业务中，包括IT在内的操作成本已经达到中小金融机构资金成本的10倍以上，这客观上造成了小微企业客户的融资难、融资贵。
建设方案： 通过阿里云的解决方案，吴江农商行构建了一个资源共享、集中管理、动态管控的智慧IT 基础架构。 在架构上，通过专线接入服务实现支付宝、阿里云、吴江农商行的互连互通，使金融业务运行在相对安全封闭的网络环境中，在业务连续性上，通过在青岛建立灾备中心，实现与杭州生产中心应用级灾备，底层数据实时同步，一旦发生故障，随时可以接管业务。 为保障本中心的高可用，还通过SLB构建应用池，将流量分发到不同VM上，在业务高峰期，弹性拓展和升级应用池。另外，阿里云的云盾附加服务可以进行应用、数据库、系统、网络安全护航。 价值所在： 据银监会统计，目前我国拥有2000多家区域银行，持卡用户在2-3亿间，由于规模、成本、技术等因素，多数银行尚未提供互联网相关业务。 2012年中国网络零售市场规模达到1.3万亿，用户消费购买习惯发生了巨大变化，需要银行拥抱互联网进行转型。阿里云具备快速交付、灵活扩展、成本极低、安全可靠等优势，可以帮助吴江农商行实现与支付宝的快速对接，为其卡用户增加便利的网络支付渠道，增强了持卡用户活跃度和粘性。 作为第一批使用阿里云的银行，吴江农商行不仅在业务模式上有所创新，而且在IT技术上也保持与时俱进。通过推出快捷支付，向用户提供了更加优质的服务，使用户有了更好的消费和支付体验，同时，开发和IT成本也有了极大的降低，避免了硬件重复建设和运维难度，而且云计算的弹性优势可以帮银行从容应对IT架构的挑战。
云计算平台设计参考架构 在私有云当中，主要包含以下几个组件：物理基础架构、虚拟化层、服务自动化层、服务门户、安全体系、云API和可集成的其它功能。（如图私有云参考架构） 图3.4 私有云参考架构 a) 物理基础架构 物理架构的定义是组成私有云的各种计算资源，包括存储、计算服务器、网络，无论是云还是传统的数据中心，都必须基于一定的物理架构才能运行。
在私有云参考架构中的物理基础架构其表现形式应当是以资源池模式出现，也就是说，所有的物理基础架构应当是统一被管，且任一设备可以看成是无状态，或者说并不与其它的资源，或者是上层应用存在紧耦合关系，可以被私有云根据最终用户的需求，和预先定制好的策略，对其进行改变。 b) 虚拟化层 虚拟化是实现私有云的前提条件，通过虚拟化的方式，可以让计算资源运行超过以前更多的负载，提升资源利用率。虚拟化让应用和物理设备之间采用松耦合部署，物理资源状态的变更不影响到虚拟化的逻辑计算资源。且可以根据物力基础资源变化而动态调整，提升整体的灵活性。 c) 服务自动化层 服务自动化层实现了对计算资源操作的自动化处理。它可以集中的监控目前整体计算资源的状态，比如性能、可用性、故障、事件汇总等等，并通过预先定义的自动化工作流进行
相关的处理。 服务自动化层是计算资源与云计算服务门户相关联的重要部件，服务自动化层拥有自动化配置和部署功能，可以进行服务模板的制定，并将服务内容和选择方式在云计算服务门户上注册，用户可以通过服务门户上的服务目录来选择相应的计算资源请求，由服务自动化层实现服务交付。 d) 云API 云应用开发接口提供了一组方法，让云服务门户和不同的服务自动化层进行联系，通过云API，可以在一个私有云当中接入多个不同地方的计算资源池，包括不同架构的计算资源，并通过各自的服务自动化体系去进行服务交互。 e) 云服务门户 云服务门户是用户使用私有云计算资源的接口，云服务门户上提供了所有可用服务的目录，并提供了完善的服务申请流程，用户可以执行申请、变更、退回等计算资源使用服务。
智慧交通云计算解决方案
目录 1智慧交通云方案 (4) 1.1背景 (4) 1.1.1 交通拥堵带来的技术挑战 (4) 1.1.2 智能交通研究现状 (5) 1.1.3 云计算技术及发展现状 (6) 1.2构想 (7) 1.2.1智能交通云构思 (7) 1.2.2智能交通云的用途 (8) 1.2.2.1 交通信息实时发布 (8) 1.2.2.2 智能公交 (8) 1.2.2.3 智能信号控制 (9) 1.2.2.4 应对突急事件 (9) 1.2.2.5 车辆运营调度 (10) 1.2.3智能交通云与智慧 (10) 1.2.4 建设智能交通云的意义 (11) 1.3总体方案 (12) 1.3.1 总体架构 (12) 1.3.1.1 总体设计 (12) 1.3.1.2系统联网拓扑结构 (13) 1.3.1.3 系统层次图 (14) 1.3.2 感知层 (15) 1.3.2.1 RFID (15) 1.3.2.2交通卡口系统 (17) 1.3.2.3 道路监控视频智能识别 (20) 1.3.2.3.4 车辆跟踪模块 (23) 1.3.3 存储层 (26) 1.3.3.1 云存储概述 (27) 1.3.3.2 分布式云存储构架 (27) 1.3.3.3 智能交通云存储建议 (28) 1.3.4 处理层 (31) 1.3.4.1 数据量激增带来的处理挑战 (31) 1.3.4.2 cProc云处理平台架构 (31) 1.3.4.3 cProc云处理平台优势 (33) 1.3.5 认知层 (34) 1.3.5.1实时视频智能识别 (34) 1.3.5.2行为识别 (37) 1.3.5.3语义分析 (38) 1.3.6 应用层 (41) 1.3.6.1 交通规划 (41)
一、业务挑战 无锡华夏计算机技术有限公司于2000年1月成立，是无锡软件出口外包骨干企业。公司主要以面向日本的软件外包开发为中心，致力于不断开拓国内市场、为客户提供优质的系统集成等业务。随着企业的发展，IT投入不断加大，随之而来的PC管理问题也越来越突出。 华夏目前PC总拥有数1000台，主要用于研发和测试，由于项目多、任务紧，一台PC经常要用于不同的项目开发，而每次更换都要对PC系统进行重新安装和环境搭建。根据实际统计，华夏一个员工平均每年参与4个项目的开发，也就是每年要重新搭建四次开发环境，对测试人员来说这个数量还要更多；平均每次更换环境花费时间10个小时，华夏每年大约花费4万小时用于PC系统和环境搭建，按照人均工资15元/小时，每年花费在60万左右。 除此之外，由于PC的使用寿命较短，更新升级频繁，大量的PC就意味着每年都要有很多PC需要淘汰和更新，现在这个数字大约是10台/月，而随着华夏的发展壮大，这个数字会进一步增加，这就意味着华夏每年花在PC升级和更新的费用最少在50~60万。与此同时，大量的PC也是的企业的能源消耗巨大，电力花费居高不下；按照平均180W/台，一台PC工作8小时/天，工业用电0.9元/度，华夏每年的电费就将近15万元。 与巨大的IT投入相对应的就是IT资源利用率较低，PC分布在企业各个项目小组的开发人员手中，很难进行统一的管理调度，也无从得知PC的使用情况。软件开发的各个阶段对IT的需求都是不同的，我们无法得知某个正在进行的项目使用的PC资源是否有多余，无法将项目完成用不到的PC资源及时收回，以便给下一个项目小组使用，造成大量的IT资源浪费。
方案简介 随着互联网技术的发展，越来越多的应用面向云计算。云计算是网络计算、分布式计算、并行计算、效用计算、网络存储、虚拟化、负载均衡等传统计算机和网络技术发展融合的产物。云计算的核心思想，是将大量用网络连接的计算资源统一管理和调度，构成一个计算资源池为用户按需服务。云计算是IT服务提供方式的一种改变，它在对数据中心呈几何倍数增长的情况下，有望显著提高效率和灵活性。许多云计算部署依赖于计算机集群，包括计算、网络互联、存储等，如图1-3。图1-4为具体一个云计算应用的拓扑部署。 图1-3 图 1-4 上述图1-4，描述了一个云计算应用，其主要业务应用在经分系统中支持Oracle Rac，和分布式话单分析等，其中配置的集群服务器节点共有32台刀片服务器，每个结点内置40Gb InfiniBand QDR HCA 卡网卡，连接到MIS5030 IB交换机中。多台业务应用服务器连接到核心GE万兆交换机中。以
太网与IB网的连接通过MBX 5020 完成。MBX 5020有4个IB口，每个IB 可连接3个GE口，从而实现了计算结点与以太网服务器的通讯。 VSA 服务器：VSA为存储加速软件，配置了2个服务器，每个服务器内置一块HCA（IB）卡和两块HBA（FC）卡，以及一块512GB SSD固态盘。VSA服务器作为网关设备，实现了IB到FC的转换。 HCA卡：40Gb InfiniBand QDR HCA 网卡。 HBA卡：8Gb FC卡。 SSD固态盘：采用CFD-SATAE电子盘产品，持续读写能力达200MB/s，用于加载VSA软件做缓存用。 VSA连接着FC交换机与后端的FC存储。 上述拓扑图中，实现了IB、Ethernet、FC网络的整合互通，应用在不同的云计算需求网络部署中。 在当今企业中80%的数据都是非结构化数据，这些数据每年都按指数增长60%。大数据将挑战企业的存储架构、数据中心的基础设施等，也会引发数据仓库、数据挖掘、商业智能、云计算等应用的连锁反应。未来企业会将更多的TB级数据集用于商务智能和商务分析。到2020年，全球数据使用量预计将暴增44倍，达到35.2ZB（1ZB=10亿TB）。 如何去分析这些数据，挖掘其内在价值，就需要分布式计算来支撑海量数据的分析工作。 早先那种多线程，多任务分解的日志分析设计，是分布式计算的一个单机版缩略，如何将这种单机的工作进行分拆，变成协同工作的集群，就是分布式计算框架设计所涉及的。 分布式计算运用在多场景，大数据量的分布式处理，是云计算服务中其业务内容必须用到的。 InfiniBand是针对对带宽延迟要求比较高的领域设计的一种网络，现阶段主流带宽是40Gb/s，网络中端到端延迟可以控制在us级别，InfiniBand 网络采用集中管理，支持网络划分，QOS等功能，扩展方便，可达数千个节点，经验证，适用于MPI， ORACLE RAC，HADOOP等的应用。 1.2 节点系统 云计算核心是计算能力的集中和规模性突破，云计算中心对外提供的计算类型决定了云计算中心的硬件基础架构。从云端客户需求看，云计算中心通常需要规模化的提供以下几种类型的计算能力： 大型服务器 一是高性能的、稳定可靠的高端计算，主要处理紧耦合计算任务，这类计算不仅包括对外的数据库、商务智能数据挖掘等关键服务，也包括自身账户、计费等核心系统，通常由8路以上的大服务器提供。 上述图1-4，描述了这种情况的一个云计算应用的拓扑； 高密度服务器 二是面向众多普通应用的通用型计算，用于提供低成本计算解决方案，这种计算对硬件要求较低，一般采用高密度、低成本的超密度集成服务器，以有效降低数据中心运营商的运营成本和终端用户的使用成本； 高性能计算HPC 三是面向科学计算、生物工程等业务，提供百万亿、千万亿次计算能力的高性能计算，其硬件基础是高性能集群。 1.3 网络系统 网络互联技术是云计算中的关键因素，需要满足5个关键因素对网络的需求： ?高带宽/低延迟 ?整合型以太网 ?支持多种类作业任务 ?扩展性和可管理性
由于云计算分为IaaS、PaaS和SaaS三种类型，不同的厂家又提供了不同的解决方案，目前还没有一个统一的技术体系结构，对读者了解云计算的原理构成了障碍。为此，本文综合不同厂家的方案，构造了一个供商榷的云计算体系结构。这个体系结构如图3所示，它概括了不同解决方案的主要特征，每一种方案或许只实现了其中部分功能，或许也还有部分相对次要功能尚未概括进来。 图3 云计算技术体系结构 云计算技术体系结构分为4层：物理资源层、资源池层、管理中间件层和SOA构建层，如图3所示。物理资源层包括计算机、存储器、网络设施、数据库和软件等；资源池层是将大量相同类型的资源构成同构或接近同构的资源池，如计算资源池、数据资源池等。构建资源池更多是物理资源的集成和管理工作，例如研究在一个标准集装箱的空间如何装下2000个服务器、解决散热和故障节点替换的问题并降低能耗；管理中间件负责对云计算的资源进行管理，并对众多应用任务进行调度，使资源能够高效、安全地为应用提供服务；SOA构建层将云计算能力封装成标准的Web Services服务，并纳入到SOA体系进行管理和使用，包括服务注册、查找、访问和构建服务工作流等。管理中间件和资源池层是云计算技术的最关键部分，SOA构建层的功能更多依靠外部设施提供。 云计算的管理中间件负责资源管理、任务管理、用户管理和安全管理等工作。资源管理负责均衡地使用云资源节点，检测节点的故障并试图恢复或屏蔽之，并对资源的使用情况进行监视统计；任务管理负责执行用户或应用提交的任务，包括完成用户任务映象(Image)的部署和管理、任务调度、任务执行、任务生命期管理等等；用户管理是实现云计算商业模式的一个必不可少的环节，包括提供用户交互接口、管理和识别用户身份、创建用户程序的执行环境、对用户的使用进行计费等；安全管理保障云计算设施的整体安全，包括身份认证、访问授权、综合防护和安全审计等。 基于上述体系结构，本文以IaaS云计算为例，简述云计算的实现机制，如图4所示。 用户交互接口向应用以Web Services方式提供访问接口，获取用户需求。服务目录是用户可以访问的服务清单。系统管理模块负责管理和分配所有可用的资源，其核心是负载均衡。配
云计算安全解决方案 目录 云计算安全解决方案 0 1.云计算的特点 (3) 2?云计算的安全体系架构 (4)
3?云计算面临的安全隐患 (5)
3.1云平台的安全隐患 (5) 3.2应用服务层的安全隐患 (6) 3.3基础设施层的安全隐患 (6) 4?云计算的安全解决方案 (7) 4.1确保云平台的安全 (7) 4.2确保应用服务层的安全 (8) 4.3确保基础设施层的安全 (9) 5.云计算安全的未来展望 (11)
1. 云计算的特点 超大规模。“云计算管理系统”具有相当的规模，Google的云计算已经拥有 100多万台服务器，Amazon、IBM、微软、Yahoo等的“云”均拥有几十万台服务 器。“云”能赋予用户前所未有的计算能力。 虚拟化。云计算支持用户在任意位置、使用各种终端获取应用服务。所请求的资源来自“云”，而不是固定的有形的实体。应用在“云”中某处运行，但实际上用户无需了解、也不用担心应用运行的具体位置。 高可靠性。“云”使用了数据多副本容错、计算节点同构可互换等措施来保障服务的高可靠性，使用云计算比使用本地计算机可靠。 通用性。云计算不针对特定的应用，在“云”的支撑下可以构造出千变万化的应用，同一个“云”可以同时支撑不同的应用运行。 高可扩展性。“云”的规模可以动态伸缩，满足应用和用户规模增长的需要。廉价。 由于“云”的特殊容错措施可以采用极其廉价的节点来构成云，因此用户可以充分享受“云”的低成本优势。 目前各家所提的云安全解决方案，大都根据自己企业对云平台安全的理解，结合本企业专长，专注于某一方面的安全。然而，对于用户来说云平台是一个整体，急需一套针对云平台的整体保护技术方案。针对云平台的信息安全整体保护技术的研究的是大势所趋，整体保护技术体系的建立，必将使云计算得以更加健康、有序的发展。 2. 云计算的安全体系架构 云计算平台和传统计算平台的最大区别在于计算环境，云平台的计算环境是
戴尔自从三年前启动了战略2.0转型以来，启动一系列创新研发和并购动作，尤其在云计算方面取得了骄人的成绩，包括架构即服务、平台即服务和软件即服务方面。在今年4月戴尔宣布IT进入“虚拟时代”（Virtual Era），发布了全新解决方案、系统和服务，以帮助更多客户构建高效、高性价比的云计算和超大规模数据中心基础设施。 通过简化（Simplify）、标准化（Standardize）和自动化（Automate），戴尔交付开放的（Open）、经济的（Affordable）和可靠的（Capable）的价值。戴尔基于工业标准的开放式的解决方案和服务，使各种规模的客户在不付出性能、可靠性代价或浪费现有投资的基础上整合新兴技术，释放了客户的潜力，使他们可以充分拥抱高科技的“虚拟时代”，达到更高的效率水平，提高业务服务水平。目标是帮助客户组织把数据管理成本从70%降低到50%，让组织投资更多地应用到战略决策。 戴尔高效企业生态系统云战略（Efficient Enterprise Ecosystem，简称E3） 戴尔公司今年4月在北京宣布了高效企业生态系统（Efficient Enterprise Ecosystem，简称E3）的云计算企业战略，旨在通过高效企业生态系统实现高效企业，提高企业核心竞争力。E3有四个基本组成部分： 智能基础设施（Intelligent Infrastructure） 提供智能化的带嵌入式管理功能的客户机、服务器、存储和网络设备，如PowerEdge C云服务器和支持弹性扩展的Equallogic存储等。用户可以自动化实现经常而复杂的任务，减少总拥有成本。通过全新的动态管理模式在分钟级别响应变更请求。 简化基础设施管理（Simplified Infrastructure Management） 简化端到端基础设施管理，提供开放的设施管理解决方案，如戴尔的Scalent （Advanced Infrastructure Management，简称AIM）、VMware vCenter和微软System Center 等，实现单一管理员配置资源和一键式按需添加新功能。 简化应用和工作负载管理（Streamlined Applications and Workload Management） 简化客户机和服务器工作负载管理，利用诸如Quest、VizionCore虚拟架构管理方案。最终用户自助为新项目创建并分配工作负载，实现应用级别的监控，从而帮助主动发现潜在问题。 智能数据管理（Intelligent Data Management） 智能化信息数据管理解决方案，比如戴尔DX6000对象存储、重复数据删除产品 Dell|EMC DD、DL2100等。降低数据存储的管理成本、占地空间和机房功率的要求，方便客户挖掘数据价值，并且制定管理和保留策略。 戴尔高效企业生态系统
云计算不仅是技术，更是服务模式的创新。云计算之所以能够为用户带来更高的效率、灵活性和可扩展性，是基于对整个IT领域的变革，其技术和应用涉及硬件系统、软件系统、应用系统、运维管理、服务模式等各个方面。 IaaS(基础架构即服务)作为云计算的三大部分之一，将基础架构进行云化，从而更好的为应用系统的上线、部署和运维提供支撑，提升效率，降低TCO。同时，由于IaaS包含各种类型的硬件和软件系统，因此在向云迁移过程中也面临前所未有的复杂性和挑战。那么，云基础架构包含哪些组件?主要面临哪些问题?有哪些主要的解决方法呢? 一、云基础架构 如图1所示，传统的IT部署架构是“烟囱式”的，或者叫做“专机专用”系统。 图1传统IT“烟囱”模式部署架构 在这种架构中，新的应用系统上线的时候需要分析该应用系统的资源需求，确定基础架构所需的计算、存储、网络等设备规格和数量，这种部署模式主要存在的问题有以下两点： l硬件高配低用。考虑到应用系统未来3～5年的业务发展，以及业务突发的需求，为满足应用系统的性能、容量承载需求，往往在选择计算、存储和网络等硬件设备的配置时会留有一定比例的余量。但硬件资源上线后，应用系统在一定时间内的负载并不会太高，使得较高配置的硬件设备利用率不高。 l整合困难。用户在实际使用中也注意到了资源利用率不高的情形，当需要上线新的应用系统时，会优先考虑部署在既有的基础架构上。但因为不同的应用系统所需的运行环境、对资源的抢占会有很大的差异，更重要的是考虑到可靠性、
稳定性、运维管理问题，将新、旧应用系统整合在一套基础架构上的难度非常大，更多的用户往往选择新增与应用系统配套的计算、存储和网络等硬件设备。 这种部署模式，造成了每套硬件与所承载应用系统的“专机专用”，多套硬件和应用系统构成了“烟囱式”部署架构，使得整体资源利用率不高，占用过多的机房空间和能源，随着应用系统的增多，IT资源的效率、扩展性、可管理性都面临很大的挑战。 云基础架构的引入有效解决了传统基础架构的问题(如图2所示)。 图2云计算融合模式部署架构 云基础架构在传统基础架构计算、存储、网络硬件层的基础上，增加了虚拟化层、云层： 虚拟化层：大多数云基础架构都广泛采用虚拟化技术，包括计算虚拟化、存储虚拟化、网络虚拟化等。通过虚拟化层，屏蔽了硬件层自身的差异和复杂度，向上呈现为标准化、可灵活扩展和收缩、弹性的虚拟化资源池; 云层：对资源池进行调配、组合，根据应用系统的需要自动生成、扩展所需的硬件资源，将更多的应用系统通过流程化、自动化部署和管理，提升IT效率。 相对于传统基础架构，云基础架构通过虚拟化整合与自动化，应用系统共享基础架构资源池，实现高利用率、高可用性、低成本、低能耗，并且通过云平台层的自动化管理，实现快速部署、易于扩展、智能管理，帮助用户构建IaaS(基础架构即服务)云业务模式。
dell 的云计算解决方案| dell 自从三年前启动了战略2.0 转型以来，启动一系列创新研发和并购动作，尤其在云计算方面取得了骄人的成绩，包括架构即服务、平台即服务和软件即服务方面。在今年4 月戴尔宣布IT 进入“虚拟时代” (Virtual Era)，发布了全新解决方案、系统和服务，以帮助更多客户构建高效、高性价比的云计算和超大规模数据中心基础设施。通过简化( Simplify )、标准化( Standardize )和自动化( Automate )，戴尔交付开放的(Open)、经济的(Affordable )和可靠的(Capable)的价值。戴尔基于工业标准的开放式的解决方案和服务，使各种规模的客户在不付出性能、可靠性代价或浪费现有投资的基础上整合新兴技术，释放了客户的潜力，使他们可以充分拥抱高科技的“虚拟时代”，达到更高的效率水平，提高业务服务水平。目标是帮助客户组织把数据管理成本从70%降低到50%，让组织投资更多地应用到战略决策。 戴尔高效企业生态系统云战略( Efficient Enterprise Ecosystem ，简称E3) 戴尔公司今年4 月在北京宣布了高效企业生态系统( Efficient Enterprise Ecosystem ，简称 E3)的云计算企业战略，旨在通过高效企业生态系统实现高效企业，提高企业核心竞争力。E3有四个基本组成部分： 智能基础设施( Intelligent Infrastructure ) 提供智能化的带嵌入式管理功能的客户机、服务器、存储和网络设备，女口PowerEdge C云服务器和支持弹性扩展的Equallogic 存储等。用户可以自动化实现经常而复杂的任务，减少总拥有成本。通过全新的动态管理模式在分钟级别响应变更请求。 简化基础设施管理( Simplified Infrastructure Management ) 简化端到端基础设施管理，提供开放的设施管理解决方案，如戴尔的Scalent (Advanced Infrastructure Management ，简称AIM)、VMware vCenter 和微软System Center 等，实现单一管理员配置资源和一键式按需添加新功能。 简化应用和工作负载管理( Streamlined Applications and Workload Management ) 简化客户机和服务器工作负载管理，利用诸如Quest 、VizionCore 虚拟架构管理方案。最终用户自助为新项目创建并分配工作负载，实现应用级别的监控，从而帮助主动发现潜在问题。 智能数据管理( Intelligent Data Management ) 智能化信息数据管理解决方案，比如戴尔DX6000对象存储、重复数据删除产品Dell|EMC DD DL2100等。降低数据存储的管理成本、占地空间和机房功率的要求，方便客户挖掘数据价值，并且制定管理和保留策略。 跟其他专有厂商打造的专有性解决方案不同，戴尔 E 3是一个开放的平台，将包括英特尔、VMware微软、EMC博科等众多合作伙伴的标准化产品技术集成在一起。 戴尔的云计算策略非常清晰，在E3的总体战略，分为laaS (基础架构即服务)、SaaS (软 件即服务)、PaaS (平台即服务)三个方面不同的解决方案，让我们一一介绍。
云计算平台解决方案 ——软件开发测试云平台
一、业务挑战 (1) 二、云计算软件开发平台解决方案 (2) 2.1 云计算整合架构 (2) 2.1.1 虚拟化平台 (2) 2.1.2 云服务管理平台 (3) 2.2 云计算网络结构 (4) 2.2.1 网络设计原则 (4) 2.2.2 核心网络设计 (4) 2.3 存储与备份 (5) 三、用户价值分析 (6) 四、设备清单 (10) 4.1 基础设施及网络部分 (10) 4.2 服务器 (10) 4.3 云计算软件 (11)
一、业务挑战 无锡华夏计算机技术有限公司于2000年1月成立，是无锡软件出口外包骨干企业。公司主要以面向日本的软件外包开发为中心，致力于不断开拓国内市场、为客户提供优质的系统集成等业务。随着企业的发展，IT投入不断加大，随之而来的PC管理问题也越来越突出。 华夏目前PC总拥有数1000台，主要用于研发和测试，由于项目多、任务紧，一台PC经常要用于不同的项目开发，而每次更换都要对PC系统进行重新安装和环境搭建。根据实际统计，华夏一个员工平均每年参与4个项目的开发，也就是每年要重新搭建四次开发环境，对测试人员来说这个数量还要更多；平均每次更换环境花费时间10个小时，华夏每年大约花费4万小时用于PC系统和环境搭建，按照人均工资15元/小时，每年花费在60万左右。 除此之外，由于PC的使用寿命较短，更新升级频繁，大量的PC就意味着每年都要有很多PC需要淘汰和更新，现在这个数字大约是10台/月，而随着华夏的发展壮大，这个数字会进一步增加，这就意味着华夏每年花在PC升级和更新的费用最少在50~60万。与此同时，大量的PC也是的企业的能源消耗巨大，电力花费居高不下；按照平均180W/台，一台PC工作8小时/天，工业用电0.9元/度，华夏每年的电费就将近15万元。 与巨大的IT投入相对应的就是IT资源利用率较低，PC分布在企业各个项目小组的开发人员手中，很难进行统一的管理调度，也无从得知PC的使用情况。软件开发的各个阶段对IT的需求都是不同的，我们无法得知某个正在进行的项目使用的PC资源是否有多余，无法将项目完成用不到的PC资源及时收回，以便给下一个项目小组使用，造成大量的IT资源浪费。
云平台建设方案简介 2015年11月
目录
云平台总体设计 总体设计方案 设计原则 ?先进性 云中心的建设采用业界主流的云计算理念，广泛采用虚拟化、分布式存储、分布式计算等先进技术与应用模式，并与银行具体业务相结合，确保先进技术与模式应用的有效与适用。 ?可扩展性 云中心的计算、存储、网络等基础资源需要根据业务应用工作负荷的需求进行伸缩。在系统进行容量扩展时，只需增加相应数量的硬件设备，并在其上部署、配置相应的资源调度管理软件和业务应用软件，即可实现系统扩展。 ?成熟性 云中心建设，要考虑采用成熟各种技术手段，实现各种功能，保证云计算中心的良好运行，满足业务需要。 ?开放性与兼容性 云平台采用开放性架构体系，能够兼容业界通用的设备及主流的操作系统、虚拟化软件、应用程序，从而使得云平台大大降低开发、运营、维护等成本。 ?可靠性 云平台需提供可靠的计算、存储、网络等资源。系统需要在硬件、网络、软件等方面考虑适当冗余，避免单点故障，保证云平台的可靠运行。 ?安全性 云平台根据业务需求与多个网络分别连接，必须防范网络入侵攻击、病毒感染；同时，云平台资源共享给不同的系统使用，必须保证它们之间不会发生数据泄漏。因此，云平台应该在各个层面进行完善的安全防护，确保信息的安全和私密性。 ?多业务性 云平台在最初的规划设计中，充分考虑了需要支撑多用户、多业务的特征，保证基础资源在不同的应用和用户间根据需求自动动态调度的同时，使得不同的业务能够彼此隔离，保证多种业务的同时良好运行。 ?自主可控 云平台建设在产品选型中，优先选择自主可控的软硬件产品，一方面保证整个云计算中心的安全，另一方面也能够促进本地信息化产业链的发展。 支撑平台技术架构设计 图支撑平台技术架构 支撑平台总体技术架构设计如上，整个架构从下往上包括云计算基础设施层、云计算平台资源层、云计算业务数据层、云计算管理层和云计算服务层。其中： ?云计算基础设施层：主要包括云计算中心的物理机房环境； ?云计算平台资源层：在云计算中心安全的物理环境基础上，采用虚拟化、分布 式存储等云计算技术，实现服务器、网络、存储的虚拟化，构建计算资源池、 存储资源池和网络资源池，实现基础设施即服务。
云计算体系结构 云计算基本原理 云计算是对分布式处理（Distributed Computing）、并行处理（Parallel Computing）和网格计算（Grid Computing）及分布式数据库的改进处理，其前身是利用并行计算解决大型问题的网格计算和将计算资源作为可计量的服务提供的公用计算，在互联网宽带技术和虚拟化技术高速发展后萌生出云计算。 许多云计算公司和研究人员对云计算采用各种方式进行描述和定义，基于云计算的发展和我们对云计算的理解，概括性给出云计算的基本原理为：利用非本地或远程服务器（集群）的分布式计算机为互联网用户提供服务（计算、存储、软硬件等服务）。这使得用户可以将资源切换到需要的应用 上，根据需求访问计算机和存储系统。云计算可以把普通的服务器或者PC 连接起来以获得超级计算机计算机的计算和存储等功能，但是成本更低。云计算真正实现了按需计算，从而有效地提高了对软硬件资源的利用效率。云计算的出现使高性并行计算不再是科学家和专业人士的专利，普通的用户也能通过云计算享受高性能并行计算所带来的便利，使人人都有机会使用并行机，从而大大提高了工作效率和计算资源的利用率。云计算模式中用户不需要了解服务器在哪里，不用关心内部如何运作，通过高速互联网就可以透明地使用各种资源。 云计算体系结构
云计算是全新的基于互联网的超级计算理念和模式，实现云计算需要多种技术结合，并且需要用软件实现将硬件资源进行虚拟化管理和调度，形成一个巨大的虚拟化资源池，把存储于个人电脑、移动设备和其他设备上的大量信息和处理器资源集中在一起，协同工作。 按照最大众化、最通俗理解云计算就是把计算资源都放到互联网上，互联网即是云计算时代的云。计算资源则包括了计算机硬件资源（如计算机设备、存储设备、服务器集群、硬件服务等）和软件资源（如应用软件、集成开发环境、软件服务）。 云计算体系结构 云计算平台是一个强大的“云”网络，连接了大量并发的网络计算和 服务，可利用虚拟化技术扩展每一个服务器的能力，将各自的资源通过云计算平台结合起来，提供超级计算和存储能力。通用的云计算体系结构如下图所示： 云计算体系结构 云用户端：提供云用户请求服务的交互界面，也是用户使用云的入口，用户通过Web浏览器可以注册、登录及定制服务、配置和管理用户。打开应用 实例与本地操作桌面系统一样。 服务目录：云用户在取得相应权限（付费或其他限制）后可以选择或定制的服务列表，也可以对已有服务进行退订的操作，在云用户端界面生成相应的图标或列表的形式展示相关的服务。 云计算体系结构 管理系统和部署工具：提供管理和服务，能管理云用户，能对用户授权、认证、登录进行管理，并可以管理可用计算资源和服务，接收用户发送的请求，根据用户请求并转发到相应的相应程序，调度资源智能地部署资源和应用，动态地部署、配置和回收资源。 监控：监控和计量云系统资源的使用情况，以便做出迅速反应，完成节点同步配置、负载均衡配置和资源监控，确保资源能顺利分配给合适的用户。 服务器集群：虚拟的或物理的服务器，由管理系统管理，负责高并发量的用户请求处理、大运算量计算处理、用户Web应用服务，云数据存储时采用
云计算架构介绍
白皮书 第 1 版，2009 年 6 月
摘要
云计算可望提高应用程序部署速度、促进创新和降低成本，同时还增强经营敏捷 性。Sun 抱持一种全面的云计算观点，因而可以支持各个层面，其中包括服务器、 存储、网络和虚拟化技术，这些技术将云计算环境扩展到虚拟设备中运行的软件， 而这些虚拟设备可用来在极少时间内成功汇编应用程序。本白皮书探讨云计算如何 变革我们的设计、构建和提供应用程序的方式，以及企业在采纳并应用云计算技术 时必须考虑的架构问题。
本页故意留空。
Sun 公司
目录
引言............................................................... 1 Sun 公司观点. ....................................................... 1 云计算的性质....................................................... 2 扩大已形成的趋势................................................... 2 将虚拟机作为标准部署对象......................................... 2 按需、自助、以使用情况付费的模式................................. 2 通过网络提供服务................................................. 5 开放源软件的作用................................................. 5 云计算基础设施模式................................................. 6 公用云、专用云和混合云........................................... 6 云计算的架构层................................................... 9 云应用程序设计接口.............................................. 11 云计算效益........................................................ 11 缩短运行时间和响应时间.......................................... 11 最大限度地减轻基础设施风险...................................... 12 降低入市成本.................................................... 12 加快创新步伐.................................................... 12 实现 IaaS 必须考虑的架构问题. ....................................... 13 不断发展的应用程序架构............................................ 变革架构的途径.................................................. 变革应用程序设计................................................ 目标仍然相同...................................................... 一致而稳定的抽象层................................................ 标准有助于解决复杂问题.......................................... 松散耦合、无状态、原地失败 (Fail-in-Place) 计算. ........................ 水平扩展.......................................................... 并行化............................................................ 分割并征服...................................................... 数据物理.......................................................... 数据与处理之间的关系............................................ 编程策略........................................................ 合规与数据物理.................................................. 安全性与数据物理................................................ 网络安全做法...................................................... 13 13 13 14 16 16 18 18 19 20 21 21 21 22 22 23
Sun 公司与云计算. .................................................. 24 来自 Sun 社区的创新................................................ 社区与开放式标准.................................................. 选择的重要性...................................................... 选择云计算提供商.................................................. 感谢.............................................................. 24 25 25 25 26
1品高云操作系统产品方案 本项目采用的云操作系统BingoCloud OS产品实现对云资源管理和云业务管理，实现异构虚拟化支持和统一的云业务管理门户。 1.1功能架构图 BingoCloud功能架构图如下所示，从底向上分别包括云控制器&虚拟化层、各类云服务&接口、云管控中心（运维管理功能）和自助服务界面。 品高云操作系统整体包括以下模块，分别是： （1）数据中心硬件 充分利用品高云操作系统内部的高性能计算资源、最大限度地避免重复建设与资源浪费，品高云操作系统需要对数据中心的服务器、存储设备、网络设备进行统一调度管理，以实现资源的优化配置、充分共享。 （2）资源池系统 利用品高云操作系统的虚拟化技术，将底层IT基础硬件设备进行虚拟化处理，借助品高云操作系统控制器对虚拟资源进行统一纳管，屏蔽底层各类硬件环境的复杂性，构建统一的虚拟化云资源池，为上层的业务管理系统和公共服务平
台的运行、HPC高性能计算提供必须的计算、存储和网络资源。 （3）自助化云服务系统 在虚拟化层基础上，品高云操作系统对虚拟资源进行能力封装，提供了多项自动化的云服务，包括基础能力（虚拟机、存储卷、网络资源等）、应用支撑能力（应用自动化部署、数据库服务、负载均衡服务等）、辅助能力（HPC、大数据处理、3D渲染等）等，品高云操作系统用户可以通过这些服务满足各种场景下的IT需求。该层是整个品高云操作系统的核心部分，直接决定着云数据中心的能力大小。 （4）自助服务平台 品高云操作系统为业务部门各用户提供了自助服务门户。品高云操作系统管理员只需要为每个用户分配一定的资源配额（例如10VCPU、20G内存、200G 存储空间等），用户就可以自助登录到品高云操作系统界面，使用品高云操作系统提供的各项功能进行应用部署、HPC计算等工作。 （5）API 品高云操作系统的构建需要遵循标准化的原则，目前界面云计算公认的成熟标准的AWS标准化接口，品高云操作系统平台兼容AWS超过200个API，并且所有的API均对外开放，品高云操作系统用户可以利用这些API进行能力扩展开发。 （6）云管控中心 云管控中心提供运维管理门户供管理人员通过界面的方式实现对品高云操作系统各类资源进行高效调配、全面监控、日常维护、用户管理，并能够将品高云操作系统资源的使用情况形成报表导出。 1.2资源池系统 资源池系统是品高云操作系统的核心层相当于云操作系统的底层，其主要负责将硬件资源转化为可编程的逻辑单元，可被上层服务系统灵活调度与使用。资源池中的资源通过云控制器、集群控制器和节点控制自上向下的三层架构进行调度。而针对资源池中具体资源则通过计算、存储和网络三个子系统进行管理和控制。
云计算：体系架构与关键技术 罗军舟金嘉晖宋爱波东方 东南大学计算机科学与工程学院，江苏南京２１１１８９ 摘要：系统地分析和总结云计算的研究现状，划分云计算体系架构为核心服务、服务管理、用户访问接口等３ 个层次。围绕低成本、高可靠、高可用、规模可伸缩等研究目标，深入全面地介绍了云计算的关键技术及最新研 究进展。在云计算基础设施方面，介绍了云计算数据中心设计与管理及资源虚拟化技术；在大规模数据处理方面， 分析了海量数据处理平台及其资源管理与调度技术；在云计算服务保障方面，讨论了服务质量保证和安全与隐私 保护技术。针对新型的云计算应用和云计算存在的局限性，又探讨并展望了今后的研究方向。最后，介绍了东南 大学云计算平台以及云计算研究与应用方面的相关成果。 云计算；虚拟化；数据中心；海量数据处理；服务质量；安全与隐私 ＴＰ３９３Ａ１０００－４３６Ｘ（２０１１）０７－０００３－１９ Ｃｌｏｕｄ ｃｏｍｐｕｔｉｎｇ： ａｒｃｈｉｔｅｃｔｕｒｅ ａｎｄ ｋｅｙ ｔｅｃｈｎｏｌｏｇｉｅｓ ＬＵＯ Ｊｕｎ－ｚｈｏｕＪＩＮ Ｊｉａ－ｈｕｉＳＯＮＧ Ａｉ－ｂｏＤＯＮＧ Ｆａｎｇ ２０１１－０５－２０２０１１－０６－３０ 基金项目：国家自然科学基金资助项目（６１０７０１６１， ６１０７０１５８，６１００３２５７，６０７７３１０３，９０９１２００２）；国家重点基础研究发展计划（“９７３”计划）基金资助项目（２０１０ＣＢ３２８１０４）；国家科技支撑计划课题基金资助项目（２０１０ＢＡＩ８８Ｂ０３）；教育部博士点基金课题基金资助项目（２００８０２８６００３１）；江苏省自然科学基金资助项目（ＢＫ２００８０３０）；国家科技重大专项课题基金资助项目（２００９ＺＸ０３００４－００４－０４）：江苏省“网络与信息安全”重点实验室基金资助项目（ＢＭ２００３２０１）；“计算机网络与信息集成” 教育部重点实验室项目（９３Ｋ－９） 万方数据