The 4th Open Cloud Day, which we co-organised with The Swiss Open Users Group (/ch/open), took place earlier this week. The event held a gathering of about 120 participants, from industry and academia together. There were in total 17 talks and 3 workshop sessions.
Month: June 2015
Today the ICCLab introduces a new way on how to interact with your notes.
http://icclab.github.io/powdernote/
What is powdernote?
Powdernote is a note-taking, cloud-based application for the terminal.
Why powdernote?
Because we never leave the terminal, not even to read our notes or create new ones.
This tool is for busy engineers, developers, power users, devops, …
Our target is to have an un-cluttered, distraction-free application to solve the simple task of taking notes and having them available everywhere (storage is on the cloud)!
Main functions
- Create, edit, delete, print, tag notes
- Search content
- Browse versions of notes
- Export/import to/from powdernote files
Yesterday for the 4th time the ICCLab organized the SDN workshop at the University of Bern in cooperation with SWITCH. We had around 25 participants and 7 talks that tackled SDN in the world of cloud computing, NFV, IXP, video content delivery, high performance cloud, authentication request routing and access control etc. All these solutions coming from different projects from the academia and the industry.
“The autoscaling cloud monitoring system that requires no manual reconfiguration”
“Nagios OS autoconfigurator” (N_O_conf) is a cloud monitoring system that automatically adapts its monitoring behavior to the current user-initiated VM infrastructure. N_O_conf works by installing a cloud environment change listener daemon which is repeatedly polling the OpenStack API for changes in the VM infrastructure. As soon as a VM destruction is detected, it initiates a reconfiguration of the Nagios monitoring server. Nagios OS autoconfigurator can be installed on top of every OpenStack-based cloud environment without interfering with the cloud providers infrastructure, because it can be installed inside virtual machines so cloud consumers can use it as their own monitoring system. N_O_conf monitoring system monitors all VMs that are owned by the user that installed it.
In the context of the Cloud Native Applications (CNA) Seed Project we are working on migrating an open source CRM application into to the cloud. After enabling horizontal scalabilty of the original application and moving it onto our OpenStack cloud with the help of CoreOS (etcd, fleet) and docker we’ve now just finished adding the monitoring / logging / log-collection functionality – a blog post describing this process in its detail will follow – which is needed for the next part of the project: enabling automatic scaling. As part of this process we’ve learnt some lessons concerning the process management in docker containers which we’d like to share in this post.
“Measure and benchmark reliability of your OpenStack virtual machines.”
“VM Reliability Tester” is a software that tests performance and reliability of virtual machines that are hosted in an OpenStack cloud platform. It evaluates the failure rate of VMs by performing a stress test on them. VM Reliability Tester installs OpenStack virtual machines, uploads a test program to them, runs this test program remotely and then captures program execution times to determine reliability of the virtual machines. If the test program takes a significant amount of time to complete, this is considered to result in a VM failure. Such deviations in execution time are an important benchmark for testing performance and reliability of your OpenStack environment.
Why VM Reliability Tester?
Cloud computing (or to be more precise: virtualization) is providing virtual resources instead of physical ones. The performance of virtual resources is hidden from the user, because virtual resources are abstracting form the physical hardware layer. As a system administrator you still might want to know how your virtual machines react under heavy load and you want true performance measurements – instead of promises by your cloud vendor. Therefore it might be an advantage to test the reaction of virtual machines that you have created in your OpenStack cloud and measuring the VM performance before creating a productive infrastructure and deploy productive applications on them. VM Reliability Tester delivers you estimates on how your VM performs when it is running applications. With the data produced by VM Reliability Tester you will be able to:
- Check if your VM is performing well enough to serve your performance requirements.
- Benchmark VM images in terms of application performance.
- Benchmark OpenStack platforms from different vendors.
- Acquire data that helps you to shape SLAs and underpinning contracts.
How does it work?
VM Reliability Tester uses a “master” VM which serves to create test VMs and upload test programs to them. The master VM first configures the test VMs and then runs the uploaded test programs. Test program runs are repeated in a (configurable) batch of several program runs. The test programs executes for the configured number of times on the test VMs and logs execution time of each test program run. After a batch of test program runs has finished, the master VM captures the logged execution times and calculates the mean and standard deviation of execution times in the batch. If a test program run took longer than the batch mean plus 3 standard deviations, it is considered as a failure and logged by the master VM in a file called “f_rates.csv”.
Based on the numbers of batches and test program runs per batch as well as the number of failures, VM Reliability Tester computes a failure rate sample. This sample is then used to predict failure rate estimates in productive VM infrastructures.
Setup and Installation
Prerequisites for installation of VM Reliability Tester are:
- You must have valid OpenStack authentication credentials and provide them in the setup file “openrc.py”.
- You have to provide a private/public keypair for authentication with the VMs that you own. Local path to your public and private key file must be added to a “config.ini” and “remote_config.ini” file.
- You must own a PC or labtop and have Python and some Python libraries installed on top of it.
Installation of the tool is done easily by cloning the Github repository and changing the contents of the files openrc.py, config.ini and remote_config.ini. Once you have cloned VM Reliability Tester repository and performed the configuration file changes, you must only run vm-reliability-tester.py. The script will create some csv files that contain failure rates of the VMs and the possible distributions of the failure rate.
Github page
VM Reliability Tester is available on the following Github-Page:
Last evening, we had our 10th OpenStack Switzerland User Group Meetup. The nice folks at Puzzle ITC hosted and sponsored the event in their premises. The meetup started with a warm welcome from Mr. Mark Waber, CEO of Puzzle ITC and our own Mr. Andy Edmonds, Senior Researcher in the lab.
We quickly moved on with the presentations, 6 talks in total sandwiched between a 30 mins break for delicious Pizzas, some chilled Beer and delightful networking 🙂 Special thanks again to Puzzle!
Following is the list of presentations we had yesterday and a link to them. There was an interesting round of questions and answers following each talk (which of course couldn’t be recorded) and a round of applause for the presenter.
Talks:
- Snabb NFV: Neutron at 100 Gbps – Luke Gorrie, Snabb.co
- Turning upside down a European telco– Giuseppe Paterno, Garl
- Convergence between oVirt/RHEV and Openstack– Jure Gerber, Puzzle ITC
- Building a cloud storage appliance on ZFS – Vincenzo Pii, ICCLab, ZHAW
- Blue Brain Project’s OpenStack – Ben Morrice, EPFL
- Unternehmen und Service Provider planen private, öffentliche und hybride Clouds für Workload-Portabilität – Oliver Funk, Plumgrid
Follow the meetup group for upcoming CHOSUG events! We’ll be back soon 🙂
The 4th Open Cloud Day is ready and waiting for your participation. This event, which we co-organise with Swiss Open Systems User Group (/ch/open) is running for the 4th time having it’s first outing in 2012. Scheduled on the 16th of June 2015 at the University of Bern (event location plan), the event runs for the entire day with a main track and 2 parallel talk and workshop tracks. The schedule can be seen here. During this event, ICCLab will be presenting demos of the different open-source prototypes we are developing in the lab under our various research initiatives.
We present more talks, workshops and demos this year, showcasing an industrial as well as academic relevance in the topics of Cloud Computing, Open Source, Cloud operational experiences, new technologies and applications, so on and so forth. The detailed information about the talks and workshops can be seen here.
For those who are not early birds, there is still time to join; please register here.
We look forward to seeing you there and hope for a very successful event!
[Note: This blog post was originally published on the XiFi blog here.]
One of the main jobs performed by the Infrastructures in XiFi is to manage quotas: the resources available are not infinite and consequently resource management is necessary. In Openstack this is done through quotas. Here we discuss how we work with them in Openstack.
Subscribe
Subscribe
Recent Comments