Zhong Yun Conforming (4): Qualitative and quantitative research on the usability of cloud computing

"China Cloud Net Exclusive" Author: Chen Whilin chief advisor in Cloud Network

2.2 Cloud computing tiered fabric availability

This section examines the intrinsic links between IaaS, PAAs, and SaaS availability in the cloud computing hierarchy. First propose and define the available unit AU (availability http://www.aliyun.com/zixun/aggregation/29926.html ">unit) in cloud computing, available sets (availability set ), Individual availability SA (Standalone availability) and the concept of deploying availability DA (Deployment availability), and then qualitative and quantitative analysis of the availability of various related models.

2.2.1 Definition

According to Berkeley's definition of the cloud computing model, a cloud service can be simply divided into sass, PAAs, and IaaS three-tier structures. In these 3-tier structures, this article defines the following concepts:

Available units AU (availability unit): The Minimum Basic service unit that a layer provides to the previous tier of services. Is the minimum granularity of cloud computing services. The available cells in the same layer are independent of each other, and the expiration of one usable unit does not affect other cells. Common examples of AU are AWS availability ZONE[9] and Windows Azure region[10]. An AU is a logical concept and can be a data center for IaaS; For PAAs, it can be a web, an instance of the database; For SaaS, it can be a software application.

Available collections as (availability set): The Union of one or more au in the same layer, serving as a logically integrated service to the upper layer. As has a functional module for arbitration (arbiter). Arbiter is used to monitor the AU availability in the as in real time and, according to the algorithm, to arbitrate which au offers the best, or most appropriate, service. When an as has more than one AU, the as is considered to have a non single point failure attribute.  The arbiter itself can be a distributed structure, such as load balancing based on the LVS cluster [11], or the LBS service [12] of AWS. This paper assumes that the arbiter itself has sufficient elasticity and therefore does not discuss the arbiter single point failure problem. In addition, in general, this paper assumes that the arbiter algorithm is based on an algorithm that provides maximum availability, that is, in an available set, Arbiter always tries to provide maximum availability to the service requester, referred to as the BA (best availability) algorithm.

The logical topological relationship between AU and as is shown in the following illustration:

For an AU and as, define its individual availability and deployment availability as follows:

Individual Availability SA (Standalone availability): One au/as its own availability in the case where the next layer of as/as for which the service is provided is 100% of the availability. For example, a PAAs service has its own usability in a private environment or in a lab environment before migrating to the public cloud online.

Deploy the availability DA (Deployment availability): The actual availability of a au/as in the context of a dynamic change in the As/as availability of the next layer of service provided to it. For example, a SaaS or PAAs service is deployed in a third party IAAS environment to achieve actual availability; An IaaS is deployed in a third party physical data center, providing the availability that is actually available in computing, storage, and network environment changes.

SA availability of 2.2.2 au and AS

Suppose that an as has m AU and is expressed as As =, each AU is an equivalent service module (software or hardware), and we define the AU and as SA have the following attributes.

Formula 3 Saaui = Saauj = A

Where A is a constant, for example, 99.99%, or 99.99999%.

Because in any as, each AU is equivalent to the design, and based on the same deployment, so common to have an identical individual availability.

Formula 4 SAAS = Max (saaui) = A

The default algorithm for an as arbiter is to provide maximum availability for upper-level service applications. When au in as is satisfied with the same a availability, the maximum availability that it can provide is also a. For example, a SaaS service uses the M PAAs layer of AU, each m au SA is 99.9%, then this M au component as the SA is also 99.9%.

From the above analysis, it can be concluded that the individual availability of AU within an as is equivalent; The individual availability of an as is equal to the individual availability of AU.

Da availability of AU and as 2.2.3

We believe that the actual availability of a cloud computing service relies on the availability of its underlying support services. For example, deploy a PAAs service on the IaaS of a public cloud.  The actual availability of the PAAs service varies with the availability of the IaaS service. If IaaS provides 99.9% availability, although the individual availability of the PAAs service is 99.9%, the service availability of the PAAs to the SaaS tier is 99.9% * 99.9%, down to 99.8%. In extreme cases, if the IaaS service is offline, the PAAs service reduces its deployment availability to 0, regardless of the individual availability size of its design.

The deployment availability relationship of an AU and the As for which it serves can be expressed in the form of:

Formula 5:daau = Saau. DAAS

Among them, Saau is the individual availability of this AU service; Daas deployment availability for the available set as for this AU deployment.

Obviously, when Daas = 100%, Daau = Saau;

Once the DA availability of each au in an as is dependent on the quantitative relationship of its underlying service availability, it is easy to define and deduce an as's Da availability.

Suppose an as has M AU, which can be expressed as As =. According to Formula 4, it can be learned that each au's DA is dependent on the availability of the underlying as, so M au in as may have different da availability. According to Arbiter's maximum availability algorithm, you can export an as external da availability to:

Formula 6:daas = Max (DAAU1, DAAU2, ...) Daaum)

The implication of Formula 6 is that an as deployment availability is equal to the deployment availability of the AU that has the best deployment availability in its collection. For example, an as contains 2 AU, in a sample time period T, AU1 availability is 90%, AU2 availability is 99.99%. If the availability of the pledged SLA is 99.5%, it is clear that as arbiter will provide services through the AU2 to ensure 99.5% availability. The DA, as it can be observed, is 99.99%, not 90%, or any other.

The following is a detailed discussion of cloud Computing's 3-tier model based on SaaS, PAAs, and IaaS, and defines its usability relationships.

Without losing generality, suppose a SaaS as is deployed on a PAAs as;  The PAAs as is deployed on a low-level iaas as. Its logical structure is shown in Figure 8.

From formulas 5 and 6, you can easily draw the following formula:

Formula 7:dasaas au = Sasaas au. Dapaas as

Formula 8:dapaas au = Sapaas au. Daiaas as

which:

SaaS AU: a SaaS service unit;

PAAs AU: a PAAs service unit;

IaaS AU: an IaaS service unit;

PAAs As:saas Service unit set for use by the subunits;

IaaS As:paas The service unit set of IaaS used by AU.

The following shows a transitive relationship between the DA availability of SaaS, PaaS, IaaS as:

* The availability of a SaaS service must be less than the availability of the PAAs service that it relies on.

* The availability of a PAAs service must be less than the availability of the IaaS service that it relies on.

(Responsible editor: The good of the Legacy)