Development of performance testing tools for the intensive back-end bare cloud system

What is an intensive back-end bare cloud system? The back-end cloud is the one that has removed all the interfaces used for front-end access and deployment, leaving only the cloud of backend virtualization management platform systems. This is further known as the naked cloud because it does not have any front-end modules for visualizing the business. Compared to the cloud front-end system, the back-end bare cloud system is a compact, intensive kernel system responsible for cloud virtualization implementation. For a public cloud, there can be no front-end system, but no backend system, since the backend brings together all the core operations of the public cloud system based on http://www.aliyun.com/zixun/aggregation/13883.html "> Virtualization Technology, Is the cornerstone of the cloud.

Performance tests that differ from the cloud front-end are designed to reflect the level of foreground interaction, and cloud backend performance is based on purely meaningful evaluation, which is as important as the evaluation of kernel quality. Not only that, based on the performance evaluation of the bare cloud system, that is, "kernel" performance evaluation, is stripped of all the non-kernel factor interference assessment, shielding such as front-end business process module interference, reflecting the cloud system on the pipeline signal-to-noise ratio of the best evaluation results.

This paper takes the virtual machine creation of one of the core operations of the intensive back-end bare cloud system as an example, and expounds how to develop the method of creating the pressure test for the concurrent user virtual machine on the "kernel" platform. On the one hand, it shows you the practical experience of performance testing on the back end of the cloud, on the other hand, it also provides the technical ideas and methodologies of reuse value for the technicians.

The body is divided into six parts to discuss, first of all, a simple description of the intensive back-end of the naked cloud system, and then analyze the performance test requirements, the third part of the development of the overall idea, chapter four introduces the specific implementation process, the fifth part of the test results and analysis, the sixth part of the summary of this article.

Intensive back-end bare cloud system

This paper briefly introduces the intensive back-end bare cloud system. Here is a further simple explanation combined with the legend. As shown in the following illustration, Figure 1 is a more complete picture of the whole cloud system. The red box-selected bss-business Support Services, commonly known as business support systems, is a very complex layer that faces customers directly. If the cloud is compared to a business system, then BSS is the front-end of the system, all the key business operations involving business processes are integrated, such as real-time customization of the cloud resources, customization of the resource payment model, billing process, Bill extraction, user management, and so on. The object to be discussed in this article is precisely to peel off this part. The stripped system has a complete OSS system, the operational Support Services layer, which we can interpret as a backend system and retain all interfaces that interact with BSS. These interfaces are either discarded, or abstracted, stranded. Thus, on the one hand, the intensive back-end bare cloud system can accomplish all the virtualization business logic that a whole cloud system can accomplish, on the other hand, it also ensures compatibility and seamless docking with any front-end module.

Figure 1. All cloud system structure schematic

Test requirements Description

Then the basic meaning of the intensive back-end cloud system, the test demand is simple and clear, namely: in this system to achieve concurrent users simultaneously trigger virtual machine creation, and get the virtual machine to create success rate and the time needed to create.

Further thinking, this requirement can be simplified to deal with a user situation. Because if a single user case is resolved, concurrent users can use multithreading for subsequent implementations. However, unlike a cloud with a front-end system: authorized users can deploy virtual machines at any time and place, simply by connecting to the Internet; a bare cloud platform that contains only the background system requires the user to log in to an authorized TSAM server (see Resources for TSAM), Triggers a virtual machine deployment through a specific command line. Secondly, the process of virtual machine creation needs to judge the health state of the virtual machine, and calculate the related time period, this series of operations in the lifecycle need precise management mechanism.

Based on the above analysis, the requirements can be distilled and summarized into four small targets:

Development of Test tools

The refinement of test requirements lays the framework for developing ideas. This section will develop and design around the four detailed requirements described in the second section, "Test requirements description."

First, about multithreaded startup and related initialization. One idea is directly based on Java multithreading technology, each thread simulates a user. The second idea is to use the Custom Code nesting technology of IBM Rational configured Tester to write the classes that you need. Our conclusion is to adopt the idea of two, because the advantages are three. First, the RPT concurrency characteristics of the company itself has been the internal integration of good features, convenience, security, as developers we need to focus on more business logic, rather than repeat development; second, Custom Code technology does not limit the freedom of developers, developers can write any single Java Applications to implement their own programming intent; third, RPT has been packaged user test classes can be called by developers, greatly saving the developer on the parameters of the design effort. Based on this idea, this work can be broken down into two tasks: first, each user is equipped with a log file handle to record the necessary information rollup during the user lifecycle. Second, to extract the order of appearance of each user. This can be useful when naming a virtual machine independently, so that the virtual machine created by that user can be accurately positioned.

Secondly, how to realize the single User business main program module. That is, the design control process, how to use code to implement the main control logic. This task will be embodied in the next section.

Third, solve the main program to access the TSAM server and implement command interaction. Specifically, because we are dealing with the back-end of the bare cloud system of the TSAM server is a Linux server, so our multithreaded controller first need to connect Linux. Through research, we found Ganymed SSH-2 for Java is a pure Java implementation of the SSH-2 protocol package, you can use it directly in the Java program to connect the SSH server. Ganymed SSH-2 supports SSH dialogs (remote command execution and shell access), local and remote port forwarding, local data flow hair, X11 forwarding, and SCP. None of this relies on any JCE provider, and all of these contain cryptographic features. This is definitely what we need. Our job is to write and encapsulate specific classes that belong to their needs based on the package's API.

Four, how to realize the virtual machine life cycle records and related operation management. In order to trigger the related commands in real time and get the key nodes for each lifecycle, we also need to design a class to facilitate interaction with our main program. such as the starting point of recording trigger creation, judging the end point, effectively capturing the throwing point of health status exception, designing the point of the virtual machine time-out, and so on.