Sie sind auf Seite 1von 74

UNIT - 4

Exploring Cloud Infrastructures :


• Managing the Cloud,
• Understanding Cloud Security,
• Service oriented architecture,
• Service level agreements,
• Licensing models,
• Cloud economics
Managing the
Cloud
Cloud Infrastructure
It refers to the software along with the hardware components such as storage drive, hardware, servers, virtual
software, other cloud management software, and other networking devices; all work together to support the
computing requirement of the cloud computing model. Moreover, the cloud technology holds a software
abstraction layer that virtualizes the cloud resource & presents them to users locally.
Cloud Infrastructure Management Interface (CIMI) is an open standard API that is used to manage the cloud
infrastructure. It enables its users to handle all the cloud infrastructure easily by providing a means to interact
with the provider & their consumer or developer.
 Cloud computing deployments must be monitored and managed in order to be
optimized for best performance.
 Cloud management software provides capabilities for managing faults,
configuration, accounting, performance, and security; this is referred to as FCAPS.
 DMTF's (Distributed Management Task Force) Open Cloud Standards Incubator.
 Cloud management includes managing services on-premises and management of
resources in cloud, on premises management allows vendors to use well
established network management.
 Goal is to develop management tools that work with any cloud type.
 Management responsibilities depend on the particular service model for your
cloud deployment. Cloud management includes not only managing resources in
the cloud, but managing resources on-premises.
 The management of resources in the cloud requires new technology, but
management of resources on-premises allows vendors to use well-established
network management technologies.
Administrating the Clouds
● The explosive growth in cloud computing services has led many vendors to
rename their products and reposition them to get in gold rush in the clouds.
● The fundamental features offered by traditional network management
systems:
 Administration of resources
 Configuring resources
 Enforcing security
 Monitoring operations
 Optimizing performance
 Policy management
 Performing maintenance
 Provisioning of resources
Network management systems acronym FCAPS
Fault
Configuration
Accounting
Performance
Security
What separates a network management package from a cloud computing management package is
the “cloudly” characteristics that cloud management service must have:
● Billing is on a pay-as-you-go basis.
● The management service is extremely scalable.
● The management service is ubiquitous.
● Communication between the cloud and other systems uses cloud networking
standards.
To monitor an entire cloud computing deployment stack, you
monitor six different categories:
• 1. End-user services such as HTTP, TCP, POP3/SMTP, and others
• 2. Browser performance on the client
• 3. Application monitoring in the cloud, such as Apache, MySQL, and so on
• 4. Cloud infrastructure monitoring of services such as Amazon Web Services,
Go Grid, Rackspace and others
• 5. Machine instance monitoring where the service measures processor
utilization, memory usage, disk consumption, queue lengths, and other
important parameters
• 6. Network monitoring and discovery using standard protocols like the
Simple Network Management Protocol (SNMP), Configuration Management
Database (CMDB), Windows Management Instrumentation (WMI)
two aspects to cloud management:
● Managing resources in the cloud
● Using the cloud to manage resources on-premises
Management responsibilities by service model type
Lifecycle management
1. The definition of the service as a template for creating instances
Tasks performed in Phase 1 include the creation, updating, and deletion of service templates.
2. Client interactions with the service, usually through an SLA (Service Level Agreement) contract
This phase manages client relationships and creates and manages service contracts.
3. The deployment of an instance to the cloud and the runtime management of instances
Tasks performed in Phase 3 include the creation, updating, and deletion of service offerings.
4. The definition of the attributes of the service while in operation and performance of modifications
of its properties
The chief task during this management phase is to perform service optimization and customization.
5. Management of the operation of instances and routine maintenance
During Phase 5, you must monitor resources, track and respond to events, and perform reporting and
billing functions.
6. Retirement of the service
End of life tasks include data protection and system migration, archiving, and service contract
termination.
The core management features offered by most cloud management
service products include the following:
o Support of different cloud types
o Creation and provisioning of different types of cloud resources, such as
machine instances, storage, or staged applications
o Performance reporting including availability and uptime, response time,
resource quota usage, and other characteristics
o The creation of dashboards that can be customized for a particular client's needs
o Many existing and emerging standards will be relevant in cloud computing.
Some of these, such as security-related standards, apply generally to distributed
computing environments. Others apply directly to virtualization technologies,
which are currently considered one of the important building blocks in cloud
implementations.
The Open Cloud Standards Incubator
addresses the following aspects of
the lifecycle of a cloud service:
•description of the cloud service in a
template
•deployment of the cloud service into
a cloud
•offering of the service to consumers
•consumer entrance into contracts for
the offering
•provider operation and management
of instances of the service
•removal of the service offering
Service Lifecycle and Use Cases shows the six lifecycle states of a typical cloud service
with the use cases that are most relevant to each state.
Template: A developer defines the service in a template that describes the content of and interfaces to a service.
Offering: A provider applies constraints, costs, and policies to a template to create an offering available for
request by a consumer.
Contract: A consumer and provider enter into a contract for services, including agreements on costs, SLAs,
SLOs, and specific configuration options.
Provision Service: A provider deploys (or modifies) a service instance per the contract with the consumer.
Runtime Maintenance: A provider manages a deployed service and all its resources, including monitoring
resources and notifying the consumer of key situations.
End of Service: A provider halts a service instance, including reclaiming resources for redeployment to support
other service.
Emerging Cloud Management Standards
• DMTF cloud management standards
• DMTF has created a working group
called the Open Cloud Standards
Incubator (OCSI) to help develop
interoperability standards for managing
interactions between and in public,
private, and hybrid cloud systems.
• The group is focused on describing
resource management and security
protocols, packaging methods, and
network management technologies.
The Service Measurement Index (SMI) is based on a set of
measurement technologies forming the SMI

Accountability
Agility
Assurance
Financial
Performance
Security and Privacy
Usability
Interaction Patterns : An analysis of various cloud management use cases revealed that each
use case could be decomposed into a combination of interaction patterns. An interaction
pattern consists of a sequence of messages. For any interaction pattern, the specific messages
may vary from use case to use case, but the messages have similar characteristics at an
architectural level, particularly the protocol and security considerations.
Identify: A person or entity that interacts with the cloud service provider establishes their
identity and receives appropriate credentials, such as a session token. An identity token may
also be obtained through an external identity provider that has a trust relationship with the
cloud service provider. Operations and data are made accessible to the connection
authenticated by the credentials or identity token.
•Administer: These patterns work with the data that describe offerings, users, and other
administrative metadata information needed for interactions with the cloud service provider.
For example, an administrator or operator may browse a list of available offerings to select
one, to update its metadata to configure it for a particular purpose, and to retrieve details about
how to access instances of a service that is part of the offering.
•Deploy and Update: These patterns (there are actually two types of Negotiate/Provision Resources) are used
when selecting services and resources, and then making them into services. Included are any needed negotiations
about the amount and type of resource, operations to provision services including the infrastructure that supports
them, and tracking the status of what may be long-running operations.
•Steady State: These patterns are used after services and resources have been provisioned and are in use. They
include client-initiated requests such as a report request and notifications from a provider about situations that are
of interest to a consumer and that may require remediation actions.
Understanding
Cloud Security
Securing the Cloud
● According to the report “assessing the security risks of cloud computing”
the areas of cloud computing that were uniquely troublesome :

● • Auditing
● • Data integrity
● • e-Discovery for legal compliance
● • Privacy
● • Recovery
● • Regulatory compliance
In order to evaluate your risks, you need to
perform the following analysis:
• 1. Determine which resources (data, services, or applications) you are planning to move to
the cloud.
• 2. Determine the sensitivity of the resource to risk. Risks that need to be evaluated are loss
of privacy, unauthorized access by others, loss of data, and interruptions in availability.
• 3. Determine the risk associated with the particular cloud type for a resource. Cloud types
include public, private (both external and internal), hybrid, and shared community types. With
each type, you need to consider where data and functionality will be maintained.
• 4. Take into account the particular cloud service model that you will be using. Different
models such as IaaS, SaaS, and PaaS require their customers to be responsible for security at
different levels of the service stack.
• 5. If you have selected a particular cloud service provider, you need to evaluate its system to
understand how data is transferred, where it is stored, and how to move data both in and out
of the cloud.
The security boundary
● Security service boundary
Securing Data
● These are the key mechanisms for protecting data mechanisms:
• Access control
• Auditing
• Authentication
• Authorization
Brokered cloud storage access
● Under this system, when a client makes a request for data, here's what
happens:
● 1. The request goes to the external service interface (or endpoint) of the
proxy, which has only a partial trust.
● 2. The proxy, using its internal interface, forwards the request to the broker.
● 3. The broker requests the data from the cloud storage system.
● 4. The storage system returns the results to the broker.
● 5. The broker returns the results to the proxy.
● 6. The proxy completes the response by sending the data requested to the
client.
Establishing Identity and Presence

● Cloud computing requires the following:

● • That you establish an identity


● • That the identity be authenticated
● • That the authentication be portable
● • That authentication provide access to cloud resources
Service oriented architecture

34
Recap – Service-Oriented Architecture SOA

■ “A service-oriented architecture (SOA) is an


application framework that takes everyday
business applications and breaks them down
into individual business functions and
processes, called services. An SOA lets you build,
deploy, and integrate these services independent of
applications and the computing platforms on which
they run.” –IBM“
■ Some of the characteristics

Increasing nature of distributed systems
■ Heterogeneity of systems and computing environments
■ Transparency of communication infrastructure details
35
SOA Enabling Technologies
■ Enterprise Service Bus (ESB)
■ Web Services (SOAP, WSDL, UDDI)

40
■ UDDI is an XML-based standard for describing,
publishing, and finding web services. UDDI stands
for Universal Description, Discovery, and Integration.
■ Web Services Description Language; WSDL is
used to describe web services;WSDL is written in
XML.
■ Simple Object Access Protocol. It is an XML-based
messaging protocol for exchanging information
among computers.  SOAP is an application of the
XML specification.
Business Process Modeling (BPM)
■ BPM addresses process flow and service invocations to form useful
works.
■ Two integration methods
■ Orchestration
■ Choreography
■ WS- BPEL (orchestration-like)
■ A language standard for WS interactions
■ View business process as a collection of activity graphs
■ Provides command for defining logic using conditional statements,
loops, variable etc.
■ Web Services Business Process Execution Language (WS-BPEL) is a
standard or language for automating business processes. It
is basically one of the programming language that aims to make to
describe any process possible

42
43
44
Recap (3) - SOA and Cloud

45
Service Models and their risks

Modified from Cloud Computing Impact on future enterprise architectures, 46


Schekkerman, J.
The Enterprise Service Bus

47
Managing and Monitoring SOA
Software for monitoring and managing an SOA infrastructure
plays an important role in large SOA deployments. While SOA
offers a logical design and reusable components, it does not
make the task of network management any easier.

If anything, SOA management requires proactive oversight


because you can't wait for a particular application to fail before
taking corrective action. Therefore, tools for managing SOAs
tend to be multifaceted and run constantly

48
SOA management tools
■ HP Software and Solutions OpenView
SOA Manager

■ IBM Tivoli Framework Composite


Application Manager for SOA

■ Oracle BPEL Process Manager

49
SOA security
■ Security Assertion Markup Language (SAML) is an XML standard that
provides for data authentication and authorization between client and service.
The SAML technology is used as part of Single Sign-on Systems (SSO) and allows
a user logging into a system from a Web browser to have access to distributed SOA
resources.

■ WS-Security (WSS) is an extension of SOA that enforces security by applying


tokens such as Kerberos, SAML, or X.509 to messages. Through the use of
XML Signature and XML Encryption, WSS aims to offer client/service security.

■ WS-SecureConversion is a Web services protocol for creating and sharing


security context. WS-SecureConversion is meant to opeWS-Policy are in use, and
it attaches a security context token to communications such as SOAP used to
transport messages in an SOA enterprise.

50
■ WS-Security Policy provides a set of network policies that extend WS-
Security, WS-Trust, and WS-SecureConversion so messages
complying to a policy must be signed and encrypted. The
SecurityPolicy is part of a general WS-Policy framework.

■ WS-Trust extends WS-Security to provide a mechanism to issue, renew,


and validate security tokens. A Web service using WS-Trust can
implement this system through the use of a Security Token Service (STS),
a mechanism for attaching security tokens to messages and a set of
mechanisms for key exchanges that are used to validate tokens and
messages. rate in systems where WS-Security, WS-Trust, and

51
The Open Cloud Consortium
OCC working groups perform these functions:

■They develop benchmarks for measuring cloud computing performance. Their benchmark and data
generator for measuring large data clouds is called MalStone

■They provide testbeds that vendors can use to test their applications, including the Open Cloud
Testbed and the Intercloud Testbed that are part of the work of the Open Cloud Testbed and Intercloud
working groups.

■They support the development of open-source reference implementations for cloud computing. The
Working Group on Standards and Interoperability For Large Data Clouds extends the architecture for
data storage with a distributed file system, table services, and computing using MapReduce following the
model that is part of Google's offering.

■MapReduce is Google's patented software framework that supports distributed large data sets
organized by the Google File System (GFS) accessed by clusters of computers. The Apache Hadoop
(http://hadoop.apache.org/) open-source system is based on MapReduce and GFS.

■They support the management of cloud computing infrastructure for scientific research as part of
the Open Science Data Cloud (OSDCP) Working Group's initiative 52
Relating SOA and Cloud Computing
■ Cloud computing is still in its infancy, and although Web services can implement a
Service Oriented Architecture, it is not a requirement. Most of the large
implementations of cloud computing described in this book are single-purpose
applications that have been optimized on a grand scale: Carbonite's backup,
Google's Gmail e-mail, and Twitter's Instant Messaging (IM) are several examples

■ SOA is loosely coupled because the service is separated from the messaging. If a
component doesn't provide the capabilities required, it is an easy task to switch to a
different component, and switching requires almost no programming

■ SOA components are often best-of-breed service providers that can provide a
measured service level and can play a role in Business Process Management
(BPM) systems. The separation of services from their design allows for much
easier system upgrades and maintenance.

53
A service-level agreement (SLA) is a commitment
between a service provider and a client. Particular
aspects of the service – quality, availability,
responsibilities – are agreed between the service
provider and the service user.[1] The most common
component of an SLA is that the services should be
provided to the customer as agreed upon in the
contract.
A Service Level Agreement (SLA) is the bond for performance negotiated between the cloud

services provider and the client. Earlier, in cloud computing all Service Level Agreements were

negotiated between a client and the service consumer. Nowadays, with the initiation of large

utility-like cloud computing providers, most Service Level Agreements are standardized until a

client becomes a large consumer of cloud services. Service level agreements are also defined

at different levels which are mentioned below:

• Customer-based SLA

• Service-based SLA

• Multilevel SLA
Service level agreements are also defined at different levels:

• Customer-based SLA: An agreement with an individual customer group, covering all the services they use. For

example, an SLA between a supplier (IT service provider) and the finance department of a large organization for

the services such as finance system, payroll system, billing system, procurement/purchase system, etc.

• Service-based SLA: An agreement for all customers using the services being delivered by the service

provider. For example:

◦ A mobile service provider offers a routine service to all the customers and offers certain maintenance as a

part of an offer with the universal charging.

◦ An email system for the entire organization. There are chances of difficulties arising in this type of SLA as

level of the services being offered may vary for different customers (for example, head office staff may use

high-speed LAN connections while local offices may have to use a lower speed leased line).

• Multilevel SLA: The SLA is split into the different levels, each addressing different set of customers for the same

services, in the same SLA.


◦ Corporate-level SLA: Covering all the generic service level management (often abbreviated as SLM)

issues appropriate to every customer throughout the organization. These issues are likely to be less

volatile and so updates (SLA reviews) are less frequently required.

◦ Customer-level SLA: covering all SLM issues relevant to the particular customer group, regardless of the

services being used.

◦ Service-level SLA: covering all SLM issue relevant to the specific services, in relation to this specific

customer group.
A well defined and typical SLA will contain the following components:[5]

• Type of service to be provided: It specifies the type of service and any additional details of type of service to be

provided. In case of an IP network connectivity, type of service will describe functions such as operation and

maintenance of networking equipment, connection bandwidth to be provided, etc.

• The service's desired performance level, especially its reliability and responsiveness: A reliable service will

be the one which suffers minimum disruptions in a specific amount of time and is available at almost all times. A

service with good responsiveness will perform the desired action promptly after the customer requests for it.

• Monitoring process and service level reporting: This component describes how the performance levels are

supervised and monitored. This process involves gathering of different type of statistics, how frequently this

statistics will be collected and how this statistics will be accessed by the customers.
• The steps for reporting issues with the service: This component will specify the contact details to report the

problem to and the order in which details about the issue have to be reported. The contract will also include a

time range in which the problem will be looked upon and also till when the issue will be resolved.

• Response and issue resolution time-frame: Response time-frame is the time period by which the service

provider will start the investigation of the issue. Issue resolution time-frame is the time period by which the

current service issue will be resolved and fixed.

• Repercussions for service provider not meeting its commitment: If the provider is not able to meet the

requirements as stated in SLA then service provider will have to face consequences for the same. These

consequences may include customer's right to terminate the contract or ask for a refund for losses incurred by

the customer due to failure of service.


Service Level Agreements usually specify some parameters which are

mentioned below:

1. Availability of the Service (uptime)

2. Latency or the response time

3. Service components reliability

4. Each party accountability

5. Warranties
What is cloud economics?

In the simplest term,economics of cloud computing deal with the knowledge concerning the

principles, costs, and benefits of cloud computing. For any organization to derive the greatest

value for the business, it must specifically determine how cloud services can affect IT budget,

security and IT infrastructure. There is no hard and fast formula to determine that, it all depends on

the assessing the costs pertaining to infrastructure, management, staffing need, research and

development (R&D), security and support All these factors are analyzed to determine if moving to

the cloud makes logical next step forward as per organization’s specific circumstances and needs.
How to calculate the cost of moving to the cloud?

Total cost of ownership

To put the cost of a cloud solution into perspective, you need to calculate the total cost of

ownership (TCO) for the on-premises first. You can calculate that by figuring out the cost of the

equipment you need, cost of the capital and the project lifespan of the equipment. You can also

include the installation and maintenance cost as well.


Cost of your current data center

To precisely calculate the cost of your current data center, make sure to include all aspects. For

example, IT infrastructure consisting of hardware and software that can include physical

servers, software licenses, maintenance contracts, warranties, supplies, material, spare parts,

and anything else that you directly pay for.  You need the cost of all these to correctly estimate

how much your current IT infrastructure cost. Then there are operational costs as well that

include labor, facilities used to house IT hardware, internet connectivity. These operational costs

are the part of the cost of your data center as well


Cost of estimated cloud infrastructure

Once the cost of your current data center is determined, you now need to calculate the estimated

cost of cloud infrastructure. While cloud pricing can vary depending on the number of factors and

can be quite complicated, it depends on your cloud provider to provide the simplified pricing

structure that is easier to understand. Alternatively, you can contact your cloud provider of choice

for a quote

.
Cost of cloud migration execution

The next step is accounting for the costs involved in executing the migration of the IT

operations to the cloud. It is determined by the scope of your current IT infrastructure and

how much of it you plan on moving to the cloud will be. Moreover, there is a cost involved of

integrating and testing of apps or even consultation fees


Cloudonomics Law #1: Utility services cost less even though they cost more.

An on-demand service provider typically charges a utility premium — a higher cost per unit time for a resource

than if it were owned, financed or leased. However, although utilities cost more when they are used, they cost

nothing when they are not. Consequently, customers save money by replacing fixed infrastructure with clouds

when workloads are spiky, specifically when the peak-to-average ratio is greater than the utility premium.
Cloudonomics Law #2: On-demand trumps forecasting.

The ability to rapidly provision capacity means that any unexpected demand can be serviced, and the revenue associated

with it captured. The ability to rapidly de-provision capacity means that companies don’t need to pay good money for

non-productive assets. Forecasting is often wrong, especially for black swans, so the ability to react instantaneously

means higher revenues, and lower costs.


Cloudonomics Law #3: The peak of the sum is never greater than the sum of the peaks.

Enterprises deploy capacity to handle their peak demands – a tax firm worries about April 15th, a retailer about Black

Friday, an online sports broadcaster about Super Sunday. Under this strategy, the total capacity deployed is the sum of

these individual peaks. However, since clouds can reallocate resources across many enterprises with different peak

periods, a cloud needs to deploy less capacity.

Cloudonomics Law #4: Aggregate demand is smoother than individual.

Aggregating demand from multiple customers tends to smooth out variation. Specifically, the “coefficient of variation” of

a sum of random variables is always less than or equal to that of any of the individual variables. Therefore, clouds get

higher utilization, enabling better economics.


Cloudonomics Law #5: Average unit costs are reduced by distributing fixed costs over more units of output.

While large enterprises benefit from economies of scale, larger cloud service providers can benefit from even greater

economies of scale, such as volume purchasing, network bandwidth, operations, administration and maintenance tooling.
Cloudonomics Law #6: Superiority in numbers is the most important factor in the result of a combat (Clausewitz).

The classic military strategist Carl von Clausewitz argued that, above all, numerical superiority was key to winning

battles. In the cloud theater, battles are waged between botnets and DDoS defenses. A botnet of 100,000 servers, each with

a megabit per second of uplink bandwidth, can launch 100 gigabits per second of attack bandwidth. An enterprise IT shop

would be overwhelmed by such an attack, whereas a large cloud service provider — especially one that is also an

integrated network service provider — has the scale to repel it.


Cloudonomics Law #7: Space-time is a continuum (Einstein/Minkowski)

A real-time enterprise derives competitive advantage from responding to changing business conditions and opportunities

faster than the competition. Often, decision-making depends on computing, e.g., business intelligence, risk analysis, portfolio

optimization and so forth. Assuming that the compute job is amenable to parallel processing, such computing tasks can often

trade off space and time, for example a batch job may run on one server for a thousand hours, or a thousand servers for one

hour, and a query on Google is fast because its processing is divided among numerous CPUs. Since an ideal cloud provides

effectively unbounded on-demand scalability, for the same cost, a business can accelerate its decision-making.
Cloudonomics Law #8: Dispersion is the inverse square of latency.

Reduced latency — the delay between making a request and getting a response — is increasingly essential to delivering a range

of services, among them rich Internet applications, online gaming, remote virtualized desktops, and interactive collaboration

such as video conferencing. However, to cut latency in half requires not twice as many nodes, but four times. For example,

growing from one service node to dozens can cut global latency (e.g., New York to Hong Kong) from 150 milliseconds to

below 20. However, shaving the next 15 milliseconds requires a thousand more nodes. There is thus a natural sweet spot for

dispersion aimed at latency reduction, that of a few dozen nodes — more than an enterprise would want to deploy, especially

given the lower utilization described above.


Cloudonomics Law #9: Don’t put all your eggs in one basket.

The reliability of a system with n redundant components, each with reliability r, is 1-(1-r)n. So if the reliability of a single

data center is 99 percent, two data centers provide four nines (99.99 percent) and three data centers provide six nines

(99.9999 percent). While no finite quantity of data centers will ever provide 100 percent reliability, we can come very

close to an extremely high reliability architecture with only a few data centers. If a cloud provider wants to provide high

availability services globally for latency-sensitive applications, there must be a few data centers in each region.
Cloudonomics Law #10: An object at rest tends to stay at rest (Newton).

A data center is a very, very large object. While theoretically, any company can site data centers in globally optimal locations

that are located on a core network backbone with cheap access to power, cooling and acreage, few do. Instead, they remain in

locations for reasons such as where the company or an acquired unit was founded, or where they got a good deal on distressed

but conditioned space. A cloud service provider can locate greenfield sites optimally.

Das könnte Ihnen auch gefallen