Cloud Service Level protocol review and summary

This article describes the cloud computing use case white paper version from the cloud computing use case Group 4.0--the information warehouse created by more than 1,400 participants in the open web community (900 at version 3.0). It was originally created by a group of supporters of the Open Cloud Manifesto, which later grew to include representatives of large and small companies, government agencies, advisory bodies, and suppliers.

The cloud computing use case White paper is very comprehensive, so we don't need to read the entire document at once. In this review, it is important that we focus on the organization's assessment of service-level management issues in the cloud, as SLAs describes the relationship between cloud providers and cloud customers, essentially defining that trusted cloud service customers are based on the ability to deliver infrastructure services from cloud service providers.

What is an SLA?

The author agrees that the SLA should include:

A list of services provided by the provider, together with a complete description of each service.

Determine the metrics that the provider is providing for the services it commits and the audit mechanism used to monitor the service.

The respective responsibilities of the supplier and the consumer, and the remedial action against the parties if the SLA terms are not met.

A description of how the SLA varies over time.

The author discusses two types of slas--off-the-shelf protocols and their customization, negotiation protocols. Customers with critical data requirements are not suitable for off-the-shelf protocols, so the first step before migrating to the cloud is to determine how important your data and applications are.

The public cloud often provides a non negotiated SLA, which is not acceptable for mission-critical applications or data.

What is SLOs?

SLAs include service level objectives (SLOs), which objectively define the measurable conditions of the service; Some examples include parameters about throughput and the frequency and time of the data flow, the percentage of VMs and other resources and instances available, or the urgency of evaluating SLOs importance ratings (such as " Availability is more important than response time ").

SLOs expectations should vary according to whether the data accessed by application and application is in the same cloud.

Monitoring and measurement

Service level management, based on SLOs, is how to collect and process cloud performance information. It is used in the following ways:

Cloud providers leverage service-level management for infrastructure decisions; For example, if throughput does not consistently meet customer requirements, the provider can reallocate bandwidth or add more hardware. or decide to please the customer by sacrificing other customers. For providers, SLM is designed to assist in optimal decision-making based on business objectives and advanced technologies.

Cloud customers use SLM to decide how to use cloud services, such as whether to add more virtual machines at that price, because prices are too high to be cost-effective. Sometimes it also involves automating these decisions.

What elements should be considered in terms of SLAs?

The authors propose 10 elements to consider when defining SLA terms:

Business-level objectives: Organizations must first determine why cloud services are used before accurately defining which services are needed. This is not a technical issue, but an organizational strategy: Some organizations will cut funding or loosen control of infrastructure.

Responsibilities of both parties: it is important to balance the responsibilities of the provider and the customer. For example, the provider will be responsible for the Software-as-a-service, but customers are primarily responsible for their use of the licensing software and the VM that handles sensitive data.

Business Continuity/Disaster recovery: Customers want to ensure that providers maintain adequate disaster recovery capabilities. There are two related examples: storing valuable data in the cloud for backup and cloud blasting (switching when the in-house data center is unable to handle the process load).

Redundancy: Consider how the provider implements system redundancy.

Maintenance: One of the biggest benefits of using the cloud is maintenance by the provider. However, the customer should know when the provider handles maintenance tasks:

is the service available during this period?

Is the service available, but provides lower throughput?

Does the customer have an opportunity to apply the test to the upgraded service?

Data location: According to the rules, different types of data can only be stored in a specific physical location. Providers can respond to these requirements with a guarantee that the customer's data will be stored only in a specific location and have an audit capability for the situation.

Data acquisition: If the law requires the provider's device to be able to capture data and applications belonging to a particular customer, the gain may affect customers who use the same provider. Consider providing additional backups through a third party.

Provider failure: Take into account the financial position of the provider and develop contingency plans.

Region: Once again, understand the local laws governing suppliers and managing customers.

Agents and Distributors: If the supplier is a cloud service agent or distributor, it is necessary to understand the provider's strategy and the actual provider.

SLA Requirements

The authors propose 14 responsibilities to be concerned when considering SLAs:

Security: Customers must understand their security needs and what control and federated patterns are needed to meet these requirements. Providers must understand what they need to deliver to their customers to ensure appropriate control and federated patterns.

Data encryption: Data must be encrypted when it is active and idle. You must specify the details of the encryption algorithm and the access control policy.

Privacy: Basic privacy issues include data encryption, retention, and deletion. SLAs say how cloud providers isolate data and applications in a multiple enterprise architecture environment.

Data retention, deletion: How do providers adhere to retention rules and delete policies?

Hardware erasure, destruction: With #4. With。

Government regulation: The cloud provider must be able to demonstrate compliance with regulations if, for reasons of data type, regulations must be enforced.

Transparency: For critical data and applications, the provider must proactively notify the customer when the SLA terms are violated. This includes infrastructure issues such as power outages and performance problems, as well as security incidents.

Proof: The provider shall be responsible for the required proof and maintain its current status.

Performance definition: What does running time mean? Are all servers available on each continent or only one available? It is necessary to define these definitions. (The authors of this article recommend standardizing performance terminology for ease of use.) )

Monitoring: For potential breaches, you may want to designate a neutral Third-party organization to detect the supplier's performance.

Auditable: As consumers are responsible for any breach that leads to data or usability deficiencies, it is important that consumers audit the provider's systems and procedures. SLAs should identify how and when to audit. This will bring damage and cost to the provider.

Metrics: These are tangible matters that can be monitored and audited afterwards. SLA metrics must be defined objectively and unambiguously. Next is a list of common metrics.

Provides machine-readable SLAs: This allows automatic, dynamic selection of cloud agents. In other words, SLAs may require agents to use the cheapest available provider for some tasks, and this type of automation is possible for others to choose the safest provider. (This type of service, however, is not really available, but is to be kept in mind when discussing the standardization of Cloud SLAs.) )

Human-Computer Interaction: On-demand self-service is one of the basic features of cloud computing, but SLAs should consider the availability of people when needed.

Some common performance metrics (attention #12) include

Throughput: System response speed.

Reliability: System availability.

Load balancing: Questions about elasticity.

Durability: The likelihood of data loss.

Scalability: How much of a resource can grow.

Linear: System performance grows as the load increases.

Agility: The speed at which providers respond to load changes.

Automation: Percent of request processing without human intervention.

Customer service response time.