Jump to: navigation, search

Difference between revisions of "GSoC2014/Rally/BenchmarksVirtualMachinesOpenStack"

(Description and Analysis: Rewrite the description and analysis of the project.)
(Add the Example: Blogbench section.)
 
(4 intermediate revisions by the same user not shown)
Line 2: Line 2:
 
The ability to benchmark a Virtual Machine is an important activity that more and more developers will need to perform as they host their SaaS applications in a cloud. The aim of this project is to integrate into the [[Rally]] project the ability to run easily and in an automated manner various benchmarks for measuring the performance of the deployed Virtual Machines of an OpenStack cloud.
 
The ability to benchmark a Virtual Machine is an important activity that more and more developers will need to perform as they host their SaaS applications in a cloud. The aim of this project is to integrate into the [[Rally]] project the ability to run easily and in an automated manner various benchmarks for measuring the performance of the deployed Virtual Machines of an OpenStack cloud.
  
== Description and Analysis ==
+
== Description ==
 +
The project can be divided in two parts. The first part has to do with the development of an architecture (some kind of framework) that defines a standard and easy way of porting different benchmarks to Rally, and in the second part, with the use of this framework, port existing popular benchmarks that are used to measure the performance of different aspects of a computer system.
  
The goal of this project is twofold. Firstly, develop in Rally the necessary code base for executing commands inside the virtual machines of an OpenStack cloud, and secondly, using this base, to port existing popular benchmarks that are used to measure the performance of a computer system, to the virtual machines.
+
For the first part, a new benchmark context (benchmark_image) is developed that generates an image that has installed all the required programs to run the specified benchmark. The context takes an image, a flavor and some other necessary information from the task configuration file of the benchmark scenario and boots a virtual machine. Then, using the already created users and their keypairs and security groups, it gains access to the virtual machine with SSH and executes the setup script of the specified benchmark. The setup script is a Bash script that installs the benchmark (and its dependencies) in the virtual machine. Finally, the context takes a snapshot of that virtual machine and returns the name of the newly created benchmark-ready image. Now the benchmark scenario uses the image that the context returned, in order to boot the virtual machine. It gains access to the virtual machine with SSH and executes the run script of the specified benchmark. The run script is a Python script that executes the benchmark and returns the results of it in JSON format.  
  
For the first part, a context is developed (https://review.openstack.org/#/c/104564/) that produces an image that has installed the required programs to run a specific benchmark. This context takes an image, a flavor and some other necessary information from the task configuration file of the benchmark scenario (https://review.openstack.org/#/c/98172/) and boots a virtual machine, using a new keypair and security group access the virtual machine, and then using SSH it executes the setup script (https://review.openstack.org/#/c/97030/) of the specified benchmark.
+
For the second part, because of the architecture that was defined in the first part, there is only need to develop the setup script that installs the benchmark, and the run script that executes the benchmark and returns the result in JSON format. This will be done for every possible benchmark that needs to be ported to Rally in order to be executed in a virtual machine of an OpenStack cloud.
This context is used by the benchmark scenario "boot_benchmark_delete" in order to avoid the setup part every time that the benchmark scenario will be run. The benchmark scenario boots a virtual machine using the image produced by the context "benchmark_image", and by generating a keypair and security group, it accesses the virtual machine via SSH and executes now the run script (https://review.openstack.org/#/c/97030/) of the specified benchmark. If the execution of the run script is successful, it returns some of the results of the benchmark in JSON format.
 
 
 
For the second part, the ported benchmarks for now is only Blogbench (https://review.openstack.org/#/c/97030/). However, as soon as the base is stable enough, it will be quite easy to port new benchmarks because with the current architecture it will only be needed to create a setup script and a run script for the benchmark that needs to be ported and nothing more.
 
 
 
== Status ==
 
 
 
Week 01 (May 19 - May 25)
 
Implement the developing/testing environment. Testing environment: Single node architecture (services: keystone, glance, nova, nova-network) on a separate physical machine. Developing environment: Vim with appropriate plugins for Python development, on a FreeBSD desktop, with Rally installed on it (https://review.openstack.org/#/c/95341/).
 
Research available benchmarks; selected primary source of information: Phoronix Test Suite, OpenBenchmarking.org. Tried the PTS Desktop Live.
 
 
 
Week 02 (May 26 - June 01)
 
Design an initial architecture for the project with modularity and extensibility in mind. What is written in the "Description and Analysis" section is a product of this.
 
Search for a good (in respect of popularity and reliable results) disk/io benchmark. Tried locally bonnie++, dbench, blogbench. Implement and test the setup script for blogbench (https://review.openstack.org/#/c/97030/).
 
 
 
Week 03 (June 02 - June 08)
 
Developing (patch set 1) the base of the project; a new Rally benchmark scenario that will be used when a user wants to use one of the ported VM benchmarks (https://review.openstack.org/#/c/98172/).
 
Updates (patch sets 3 and 4) for "Add benchmark 'Blogbench' for VMs".
 
Working on an "in-house" script 'deploy-rally' to help in the testing of the changes that I make.
 
Start writing the project's (this one) wiki page.
 
 
 
Week 04 (June 09 - June 15)
 
Updates (patch sets 5 and 6) for "Add benchmark 'Blogbench' in VMs". These changes reflect the decision for using Python instead of Bash for the run part of the benchmarks.
 
 
 
Week 05 (June 16 - June 22)
 
Under construction :-)
 
 
 
Week 06 (June 23 - 29)
 
Under construction :-)
 
 
 
Week 07 (June 30 - July 06)
 
Updates (patch sets 10, 11 and 12) for "Add the benchmark 'Blogbench' for the Virtual Machines" (https://review.openstack.org/#/c/97030/). These are mainly Unit tests and replacement of subprocess.check_output function with utilities from subprocess.Popen class because I didn't want to pull Python 2.7 as requirement for the benchmark. Two small, not directly related, commits that merged into master (https://review.openstack.org/#/c/104180/ and https://review.openstack.org/#/c/104924/). Start developing (patch set 1) for "Add the context 'benchmark_image'" (https://review.openstack.org/#/c/104564/).
 
 
 
Week 08 (July 07 - July 13)
 
Under construction :-)
 
  
 
== Source Code ==
 
== Source Code ==
  
Any code written in the development of this project.
+
All the code that was written during the official GSoC period for the development of this project.
  
=== Work In Progress ===
+
=== Under Review ===
 
* Add the benchmark 'Blogbench' for the Virtual Machines (https://review.openstack.org/#/c/97030/)
 
* Add the benchmark 'Blogbench' for the Virtual Machines (https://review.openstack.org/#/c/97030/)
 
* Add the VM scenario 'boot_benchmark_delete' (https://review.openstack.org/#/c/98172/)
 
* Add the VM scenario 'boot_benchmark_delete' (https://review.openstack.org/#/c/98172/)
Line 53: Line 20:
 
=== Merged ===
 
=== Merged ===
 
* Modify install_rally.sh to install under BSDs (https://review.openstack.org/#/c/95341/)
 
* Modify install_rally.sh to install under BSDs (https://review.openstack.org/#/c/95341/)
 +
* Add error handling to install_rally.sh (https://review.openstack.org/#/c/98399/)
 +
* Change the default value of scenario_output (https://review.openstack.org/#/c/104180/)
 +
* Change the default value of use_public_urls (https://review.openstack.org/#/c/104924/)
 +
* Modify config semantic validation of benchmark engine (https://review.openstack.org/#/c/112981/)
 +
* Add required_contexts validator (https://review.openstack.org/#/c/111603/)
 +
* Decrease jobs time in gates (https://review.openstack.org/#/c/114839/)
 +
* Fix semantic validation of context images (https://review.openstack.org/#/c/113904/)
 +
 +
== Example: Blogbench ==
 +
This example demonstrates the execution of the benchmark Blogbench in a virtual machine of an OpenStack (version: Icehouse) cloud using Rally. Below you can find the output of the whole procedure with the logging level set to warning, and with the logging level set to debug.
 +
 +
[http://aetos.it.teithe.gr/~tzabal/files/rally/blogbench-log-warning.txt blogbench-warning]
 +
 +
[http://aetos.it.teithe.gr/~tzabal/files/rally/blogbench-log-debug.txt blogbench-debug]
 +
 +
In the end of both outputs, there is a table called "Scenario Specific Results" that shows the results of the benchmark that run in the virtual machine(s). In this example, it was set to execute the benchmark only once in a virtual machine, for this reason the maximum, average, minimum, 90 percentile, and 95 percentile share the same value. The Blogbench benchmark outputs one value that corresponds to the final score of reads from the disk, and to the final score of writes to the disk, that have been done during 5 minutes of running the benchmark (bigger the number, better the score).
 +
 +
Note: the `rally-tool -r` command that is executed in the beginning is not part of Rally but a helper script that I used during the development to test faster my work. What it actually does is to automate (with hard-coded values) the steps that are needed to run any Rally benchmark scenario on my test environment. You may find it [https://github.com/tzabal/rally-tool here].
  
 
== Links ==
 
== Links ==
[1] Blogbench, http://www.pureftpd.org/project/blogbench
+
* Blogbench, http://www.pureftpd.org/project/blogbench

Latest revision as of 12:35, 30 September 2014

Introduction

The ability to benchmark a Virtual Machine is an important activity that more and more developers will need to perform as they host their SaaS applications in a cloud. The aim of this project is to integrate into the Rally project the ability to run easily and in an automated manner various benchmarks for measuring the performance of the deployed Virtual Machines of an OpenStack cloud.

Description

The project can be divided in two parts. The first part has to do with the development of an architecture (some kind of framework) that defines a standard and easy way of porting different benchmarks to Rally, and in the second part, with the use of this framework, port existing popular benchmarks that are used to measure the performance of different aspects of a computer system.

For the first part, a new benchmark context (benchmark_image) is developed that generates an image that has installed all the required programs to run the specified benchmark. The context takes an image, a flavor and some other necessary information from the task configuration file of the benchmark scenario and boots a virtual machine. Then, using the already created users and their keypairs and security groups, it gains access to the virtual machine with SSH and executes the setup script of the specified benchmark. The setup script is a Bash script that installs the benchmark (and its dependencies) in the virtual machine. Finally, the context takes a snapshot of that virtual machine and returns the name of the newly created benchmark-ready image. Now the benchmark scenario uses the image that the context returned, in order to boot the virtual machine. It gains access to the virtual machine with SSH and executes the run script of the specified benchmark. The run script is a Python script that executes the benchmark and returns the results of it in JSON format.

For the second part, because of the architecture that was defined in the first part, there is only need to develop the setup script that installs the benchmark, and the run script that executes the benchmark and returns the result in JSON format. This will be done for every possible benchmark that needs to be ported to Rally in order to be executed in a virtual machine of an OpenStack cloud.

Source Code

All the code that was written during the official GSoC period for the development of this project.

Under Review

Merged

Example: Blogbench

This example demonstrates the execution of the benchmark Blogbench in a virtual machine of an OpenStack (version: Icehouse) cloud using Rally. Below you can find the output of the whole procedure with the logging level set to warning, and with the logging level set to debug.

blogbench-warning

blogbench-debug

In the end of both outputs, there is a table called "Scenario Specific Results" that shows the results of the benchmark that run in the virtual machine(s). In this example, it was set to execute the benchmark only once in a virtual machine, for this reason the maximum, average, minimum, 90 percentile, and 95 percentile share the same value. The Blogbench benchmark outputs one value that corresponds to the final score of reads from the disk, and to the final score of writes to the disk, that have been done during 5 minutes of running the benchmark (bigger the number, better the score).

Note: the `rally-tool -r` command that is executed in the beginning is not part of Rally but a helper script that I used during the development to test faster my work. What it actually does is to automate (with hard-coded values) the steps that are needed to run any Rally benchmark scenario on my test environment. You may find it here.

Links