|Full name:||Building service testbeds on FIRE|
|Start date:||2012. 01. 09.|
|End date:||2013. 01. 09.|
Our video presenting the project results in 4 minutes:
BonFIRE designed, built and operates a multi-site Cloud prototype FIRE facility to support research across applications, services and systems at all stages of the R&D lifecycle, targeting the services research community on Future Internet.
The BonFIRE vision is to give researchers in these areas access to a facility that supports large scale multi-disciplinary experimentation of their systems and applications addressing all aspects of research across all layers. We develop and support a framework which allows service-based computing practitioners to experiment with their latest ideas in service orientation and distributed computing. Our overall goal is to encourage new communities of experimenters to take advantage of the opportunities offered by the FIRE infrastructure to guide the development of the Future Internet from a service-based applications standpoint.
The basis of our KOPFire experiment is the KOPI Plagiarism Search Portal. KOPI is a nationwide plagiarism service in Hungary. KOPI works asynchronously: it accepts requests in the form of uploaded documents, which is checked for copied content over various databases. After this, a report is sent to the user containing the copied parts and their original sources. KOPI service is implemented as a multi-layer infrastructure which means an interconnected set of virtual hosts with different capabilities. KOPI typically suffers from bursts of incoming requests, and therefore would benefit from automatic, elastic scaling of its service infrastructure.
The experiment investigated the costs and effects of various scaling operations in a cloud federation and their possible combinations in an elasticity strategy. The final goal of the elasticity strategy was to stabilize end-to-end QoS (the quality of experience) around desired values for the processing of incoming plagiarism search requests while keeping resource usage at a minimum.
We created a scripting solutions for elastic scaling where scaling strategies can be plugged in. We implemented 4 scaling strategies and compared them regarding throughput (speed of processing documents) and cost (CPU cores used). At maximal load, more than 100 virtual machines and 170 cores worked in our experiment. It was shown that our service implementation (adapted to cloud environment) scaled linearly in the examined load range, which means that the throughput was proportional to the number of cores used in our setup. Our experience was that such scaling solutions also helps to increase availability and fault tolerance of the service.
During the experiments service components ran in 4 separate clouds (also geographically distant) at the same time. This shows that our scaling solution is also capable for cloud bursting. The scaling environment was implemented in Ruby and used REST-based APIs to control clouds and collect monitoring data. Zabbix was used as monitoring environment with our own performance metrics added. We also tested handling large VM images, remote access to data partitions via NFS and other data related issues of IaaS clouds.