Use service level agreements and other forward-looking tools to avoid cloud downtime

One day, the weather was clear, and all the citizens (users, developers, and infrastructure experts) on the land (a small island) were happy. The system works all right. Users use Remote Desktop control to connect their virtual desktops. Once the connection is successful, they can access the software as a service (SaaS) application and receive a quick response. All virtual desktops are created using a physical desktop image that is deployed to the server that is running the hypervisor.

Developers have all the resources they need to develop a platform, a service (PaaS) application. They use the virtual desktop Access platform. Infrastructure experts access the infrastructure as a service (IaaS) to manage the virtual machines through the same physical host.

Then one day, the islanders saw dark clouds on the distant horizon. The slowly moving clouds are getting bigger and larger as they approach the island. When the dark clouds reached the island, they completely covered the sky above the island. The next thing a sad island dweller sees is that cloud downtime consumes 1.1 of all cloud service resources until there is no more resources for the islanders to use. After the dark clouds left the island, residents of the island continued to complain about their failure to prepare for a cloud service outage. Cloud services can be significantly lower than the service availability assurance level set out in service level agreements (SLAs).

Cloud Downtime Risk

The risk of cloud downtime is most likely to occur when a threat agent exploits cloud vulnerabilities. Due to resource depletion, all organizations are vulnerable to cloud downtime. The types of failures that trigger downtime include:

leap year fault numerical instability algorithm resource optimization failure threshold strategy to implement fault virtual machine management program fault virtual desktop fault

Leap year failure

The security certificate Publisher in the Microsoft Azure cloud has neither implemented a leap nor recognized the date of February 29, 2012, resulting in cloud downtime. The virtual machine could not start because the Certificate Server could not publish the appropriate certificate. The server's host agent interprets it as a possible hardware problem and reports it to the cloud's cluster controller to move the virtual machine to other hardware. Then, the resiliency moves the virtual machine that cannot be started to other health hardware, the host sends the same faulty hardware failure report again, and expands the drawbacks that may have been qualified and corrected before the cloud service outage.

An algorithm for numerical instability

The numerical instability algorithm, when attempting to solve numerical problems, will result in an infinite cycle of resource consumption until there is no more resources to consume. As resources are reduced, cloud performance continues to degrade until cloud downtime is generated.

In a simplistic scenario, it is an appropriate problem to compute the square root of 2 (about 1.41421). Many algorithms solve this problem by setting the initial approximation X1 to 1.4 (sometimes setting the X1 to 1.42), and then calculating the improved conjecture x2, x3, etc. The set numerical method can influence the result of the method to converge quickly. The first algorithm produces an iterative convergence result faster than the second algorithm.

If the result of the iterative method can quickly converge to the initial approximation, then it is stable in numerical value. If the second iteration converges slowly to the initial approximation and deviates significantly from another initial approximation, it is unstable numerically and consumes additional resources.

Consider two iterative methods: Babylonian and Method X, as shown in table 1.

Table 1. Two kinds of iterative methods

Babylonian Babylonian method x method x x1 = 1.4 X1 = 1.42 x1 = 1.4 X1 = 1.42 x2 = 1.4142857 ... x2 = 1.41422535 ... x2 = 1.4016 x2 = 1.42026896 x3 = 1.414213564 ... x3 = 1.41421356242 ... x3 = 1.4028614 ...     x3 = 1.42056 ... ... x1000000 = 1.41421 ... x28 = 7280.2284 ...

The Babylonian method stipulates xk+1 = Xk/2 + 1/xk. Method X Methods Specify XK + 1 = (xk2-2) 2 + xk. I use the initial guess x1 = 1.4 and X1 = 1.42 to compute some iterations for each scenario in the table.

We note that the Babylonian method can converge quickly, regardless of the initial guess, while approach X converges very slowly to the initial guess 1.4 and deviates from the initial guess 1.42 (i.e., 7280.2284 ...). Therefore, the Babylonian method is stable numerically, and approach X is unstable numerically.