Conclusion

Between us we spent about 80-90h working on the project, a majority of which at the school in a group. Samu configured Server2 as an experiment on his home computer, and was absent (force majeure) for two weeks mid-project. Joel did plenty of solo work towards the end of the project working on configurations.

It’s safe to say that all of us would be thrilled to finish the project on a later course or at a later time – in any case see the cloud in action in some form. This is only understandable considering the amount of time the group dedicated to the effort. The subject was very interesting to work on and taught us as much about resource analysis before starting a project as about the actual subject itself, even if many of the obstacles we faced didn’t originate from our own incompetence or lack of effort.

Signing off for possibly the last time

The Plowedcloud team

Plowedcloud vs. brick wall

Wednesday, 7th of December. The first snow of the winter covers the ground and (additional) time is running out on our “little” project. We’re at the school having some breakfast and working. In the end, we did run out of time, but came close. As Joel documented in the last post, we did get most of Server 1 up and working, with Nova presenting frustrating issues without clear answers available.

Not being able to solve this prevented us from actually building the remaining parts of the cloud infrastructure, but for the sake of properly documenting our efforts and with the possibility of salvaging some credit towards completing the course, we will document what we would have done after getting Nova up and working.

So here goes:

Firstly we’d want Server1 up and running with all required components configured correctly. These components include the MySQL database, Glance for managing OS images, Nova for managing resources and instances in the cloud, Swift for storage management and the NTP server for synchronizing the time on all nodes in the cloud with that of the frontend’s.

Secondly, we’d install and configure Server2 (which we actually did do – succesfully – on a seperate occasion) with the following: an NTP client for syncing the server’s time with that of Server1, and a component of Nova (nova-compute), since Server2′s task will be mainly to handle the heavy process of cloud resource management.

Lastly, we’d configure a client (a node) to complete our cloud. It would’ve contained, again, the NTP client. Additionally eucatools (euca2ools) and qemu-kvm would be installed. We would download the credentials for localadmin for the client machine. Then, we’d source the novarc file, and find out whether connectivity to the earlier-established api server is functioning.

At this point the infrastructure would be complete for a minimalistic cloud. Next, we’d have to set up image management for handling operating system images in the cloud. We’d create an Ext4 filesystem image of a fresh installation of Ubuntu and upload it to OpenStack Glance on Server1. After this, we’d take a look at running instances in the cloud and managing storage via eucatools. Lastly, network configurations would get done via the component nova-network in order to (for example) gain a public IP for the cloud.

On top of the finalized cloud, security features would of course have to be configured.

We’ll write up a conclusion post with the work hours put into this project and more.

Signing out for a moment

Tatu, Samu

Dealing with challenges

We’ve had some tough times with the project as of late. After switching from Ubuntu to Fedora 16, we discovered that we had inadequate expertise to configure the cloud on Fedora since none of us were experienced enough with the Redhad-based OS. Also, we’ve had one member of our team unavailable to the project for a few weeks now due to personal reasons. All hope is not lost however, as we actually managed to finally find fairly good documentation for implementing OpenStack on Ubuntu 11.10 – the platform we originally started the project on. This OS we are much more familiar with, and will begin work on configuring the system on Friday.

///

Now on monday 28.11.2011 we have now been working on Ubuntu for the second day. Our third team member, Samu, returned from his hiatus today and started helping us with the project again. We’ve been having significant difficulties with setting up the kind of partitions we want, which was an entirely unexpected issue.

Joel on Friday managed to configure our Frontend server number one almost to the finish, but had a few setbacks. One of his partitions got messed up during installation of Nova when creating an LVM partition on top of an old partition. The old, existing partition had Ubuntu 11.04 in it, which for some reason still had configurations involving the new server installation of version 11.10. When the partition with version 11.04 was removed, the 11.10 server installation lost all its users (including root!) so starting all over again was unfortunately the only choice.

Our next issue on Friday was encountered towards the very end of the configuring session when the configurer’s level of focus was beginning to wane, and he ended up messing up the user rights in the MySQL-database including all the Nova configurations so, once again, it was back to square one.

We continued on monday with all three group members present, this time in a different computer lab. This time we ran into more frustrating partitioning issues: we were somehow unable to simultaneously create an ext4 partition, a swap partition and an LVM logical partition, all of which are required for configuring a working frontend server. One of the three always backfired for reasons partly beyond our expertise. With four hours of working on these issues now behind us, we plan to go on for an hour or two more today and then call it a day.

 

///

 

Wednesday: Continuing working on our  server1, CloudStack Nova. Now we’ve reached the point in which we should be able to start our frontend (server1). However we keep on getting following warning: “EC2_ACCESS_KEY enviroment variable must be set”. Euca2ools installations with new Ubuntu 11.10 server combined with OpenStack are so new technologies that older cases are hard to come by in the Internet.

I anyhow can’t figure out what went wrong, all the configs have been checked four times, at least. Damn this technology

 

 

 

 

 

As the lights in the school’s hallways are shutting down, this project manager is coming to a conlcusion that we started working with a way too new technology with too few resources. Combined to time wasted on choosing between techologies and our technical man (Samu) being absent due to surgery and sickness. That we aren’t going to be able to meet the deadlines assinged to our project.

 

Joel, Over and Out

Step 1 (in progress)

It’s good to start by examining the computer infrastructure in the classroom in which we plan to execute our project. The room has 25 student workstations, each of which is comprised of the following:

• Intel Core i5-2400 processor (3,10 GHz, 6 Mb cache, 4 cores)
• Intel Q67 Express -motherboard
• 4Gt DDR3 SDRAM (1333MHz)
• 500Gt SATA hard drive (7200rpm, 3.0Gt/s)
• Integrated Intel display adapter
• Integrated Intel 82579LM Gigabit Ethernet network adapter

The classroom’s computers are connected through a Cisco Catalyst 2960S switch.

We began the project with a slight issue. The Ubuntu 11.10 Server package we thought we wanted to use didn’t include an option to install the Ubuntu Enterprise Cloud with which we would configure our frontend, and we found out that UEC had been dropped from the Server distribution altogether and was now a seperate entity.

We discovered that there exists only minimal – close to none – documentation regarding setting up cloud services on the 11.10 platform. Most credible sources we found instructed to use the 10.04 LTS (Long Term Support) for Ubuntu -based cloud services running on a cluster. It would seem that many professionals are waiting for the next LTS release, 12.04. This would explain the almost complete lack of useful documentation regarding 11.10′s cloud possibilities.

After discussion within the group and after reading extensively on websites reporting on upcoming industry products, we have decided to change the operating system used in our project from Ubuntu 11.10 to Fedora 16, which also uses OpenStack as a cloud platform. There was also far better, up-to-date documentation for Fedora available.

Below are our attempts of trying to get Fedora working

Apache2:

sudo yum install httpd php php-common

PHP:

sudo yum install php-pear php-pdo php-mysql php-pgsql php-pecl-memcache php-gd php-mbstring php-mcrypt php-xml

Restart Apache2:

sudo /etc/init.d/httpd start

CloudStack:

cd CloudStack-oss-2.2.12-1-fedora14/

Installation guide:

http://ke4qqq.fedorapeople.org/qig/

Project Plan

Synopsis

This project is a product of the Järjestelmäprojekti I (System project I) course at HAAGA-HELIA University of Applied Sciences held during the Autumn of 2011.

Goal

Our main goal is to find out if Ubuntu Enterprise Cloud (UEC) v. 11.10 is ready for production usage.

Why

We are interested in studying the practical application of cloud services and, in particular, following up on a previous study on the subject by earlier HAAGA-HELIA students – the SilverCloud project. We feel that a new study is in order since Ubuntu has a new release out (v. 11.10, Oneiric Ocelot) which has received several upgrades in comparison to the version used in the previous study (v. 10.10, Maverick Meerkat).

What

We will establish a cloud within a single classroom, which will consist of about twenty physical workstations. The topology of the cloud will be done according to the recommended specifications for a cloud of at least two physical systems (described in detail at the Ubuntu homepage): one machine will serve as a controller for the cloud, the cluster, Walrus and storage. The rest of the computers in the classroom will serve as nodes (with their own node controllers) in the cloud.

Who

Joel Särkkä serves as Project Manager.

Samu Saarniluoto is the project’s Technical Manager.

Tatu Seppälä works as the AD and Project Coordinator.

Tero Karvinen is the Project Instructor.

When

Work on the project will take place in 2011 between the 28th of October (week 43) and the 1st of December (week 48).

Our five step plan

We plan to execute our project in five logical steps, each of which is founded on successfully executing the previous ones in order to work towards our end goal, a working cloud on a cluster. The steps are described below in more detail:

Step 1: The installation and configuration of a frontend workstation, which will run controllers for the cloud, the cluster, Walrus and storage. Also, the installation and configuration of two nodes which will communicate with the frontend machine. The goal is to establish a working basic infrastructure for our cloud.

Types of cloud testing

Step 2: Registering our Eucalyptus cloud with RightScale and using it to test the cloud’s functionality.

Step 3: Expanding our cluster to include all the workstations in the classroom.

Step 4: Testing the cloud’s performance. Method of testing to be announced.

Step 5: Fooling around with the cloud, extensive stress testing etc.

The team working on the project plan