In my last blog post I mentioned that the computers that we were using to run Eucalyptus servers were too old to support hardware virtualization, a feature that we absolutely must have. I thought we were doomed, but luckily the IT department was able to give us 9 computers that are much more recent. The computers aren’t new by any means, but the CPUs are dual core and hardware virtualization is supported so I am quite content with them.

On Friday, Prof. Wurst and I set up several of the computers and installed CentOS 6.2 on them. I have already read and written a lot of documentation about how to compile Eucalyptus from source, so it did not take me very long to get the Eucalyptus services running on the new machines. The services, aside from the NCs, are running for the most part on 3 machines now. We decided that it would be best to let the Walrus service have its own server where previously it was on the same server as the CLC. So, the CLC, Walrus, SC, and CC are operational again. I have registered the Walrus, SC, and CC servers (CC and SC are on the same machine, by the way) with the CLC. However, the system is reporting that the SC and Walrus are broken and I have not yet resolved that issue.

In the meantime I decided to set up a couple of NCs, but in trying to set up the ethernet bridge for KVM to use, I managed to lock myself out of one of the servers when I did a `system network restart`. I guess I screwed up the configuration files! It’s not much of an issue because tomorrow I will be going to campus to work in the server room with Mike Iudiciani and I will resolve the issue there.

In doing all of this work, I have found a bug in the `euca_conf` tool. One role of euca_conf is to get credentials for access to the Eucalyptus system via command line. The command line switch for this is –get-credentials. I started the `eucalyptus-cloud` service and tried to get my credentials via euca_conf. However, I just got a “list index out of range” error printed to my terminal. After waiting for some time, the command worked successfully and I got my credentials. The problem appears to be that the cloud services were not fully functional when I tried to get the credentials, and euca_conf did not properly handle the situation and crashed. I will be filing a bug report about this shortly.

In other news, spring break is this week, but since we are running way behind schedule I will be working on this project a lot over the break. Setting up these servers has proven to be much more difficult than anticipated so I will be spending a lot of time trying to catch up to where we should be and hopefully the result of all of this hard work will be a finally functional Eucalyptus cloud.

From the blog David Thompson » WSU CS by davexunit and used with permission of the author. All other rights reserved by the author.

I’ll start with the bad news. On Sunday, March 4th, I tried to SSH into the CLC from home to try to get some more work done. I was greeted with a timeout. Neo, the CLC, was down. It turns out that the CPU fan was dead and the system overheated. We have 8 machines and it was just my luck that the CLC machine had the bad fan. So, either permanently or temporarily, I’m going to be using Morpheus as the CLC. Luckily, I had already rsync’d the Eucalyptus binaries to a few other servers so I could easily continue my work.

As an initial test, I’m using 3 of our servers to make a minimal working configuration. There are a lot of things that have to be done to each machine such as adding repositories, downloading dependencies, initializing PostgreSQL, and finally initializing Eucalyptus. There are 3 init scripts that Eucalyptus provides: eucalyptus-cloud, eucalyptus-cc, and eucalyptus-nc. Walrus, CLC, and SC require eucalyptus-cloud to be running. CC require eucalyptus-cc. Each node requires the eucalyptus-nc service. On the CLC machine, I registered it to be used for Walrus and the SC. We have another server, named Trinity, being used for the CC that needs to be registered with the CLC.

Now that the CLC and CC were operational, it was time to start up a node. This is where I ran into even more trouble. The computers we’re using as servers are older machines with CPUs that do not support hardware virtualization. With the release of RHEL 6, KVM is the supported hypervisor for virtualization. Unfortunately, KVM requires hardware virtualization support in order to function so it is not a possible option for us to use. The Xen hypervisor, on the other hand, doesn’t need to have hardware virtualization in order to function. The problem is that support for it was dropped in RHEL 6 so it is not so trivial to install now. The Xen wiki has a tutorial about installing Xen on a RHEL 6 system, which is quite long. I am slowly working through this tutorial to build the Xen packages that I need. It is an unfortunate situation because it is a very time consuming process. I was really hoping to have this system functional by today so I am a bit disappointed that I once again failed to meet my goals.

To end on a positive note, I am starting to become familiar with the Eucalyptus software. The more I start/restart the services and register/deregister components, the less confused I become about how the Eucalyptus system functions. I have written quite lengthy documentation on the CS401 wiki about all of my progress that another classmate has been using to help setup other machines that will later be used as nodes.

From the blog David Thompson » WSU CS by davexunit and used with permission of the author. All other rights reserved by the author.

My homework assignment (besides continuing my ongoing struggle with installing Eucalyptus) was to take a look at Tom “Spot” Callaway‘s “How to tell if a FLOSS project is doomed to FAIL” and see how many points of fail that the Eucalyptus project has. I had the pleasure of meeting Spot and hearing him give this talk at Western New England College and it was very entertaining.

Now, how badly does Eucalyptus fail? By my calculations they had 55 points of fail which means that “Babies cry when your code is downloaded”. I think I may have been a bit too rough with my analysis. I really do like the Eucalyptus project, but as a new user that is also completely new to the cloud computing concept, it’s hard to figure out exactly what to do and how to do it. There is documentation but there is not enough of it. From my understanding the Eucalyptus team acknowledges that and one of our goals this semester is to improve documentation for users, and who better to write documentation for new users than… new users!

In addition to the documentation fails (I forgive you, Eucalyptus devs, I hate writing documentation as well 😉, as far as I can tell there are no unit tests for the source code to check for bugs that may have creeped in. That alone earned Eucalyptus +25 points of fail and pushed the project into the crying babies category.

Once again, from what I have seen, the Eucalyptus project is great. Their developers have been supportive and responsive when I’ve had issues. As a FOSS advocate, the freedom of using a free and open source cloud computing platform far outweighs the convenience of a proprietary system that is easier for newcomers. Eucalyptus is much more win than fail, and I hope that my class can help the developers improve the usability of the software.

From the blog David Thompson » WSU CS by davexunit and used with permission of the author. All other rights reserved by the author.

I consider myself an amateur system administrator. I know my way around a Linux machine. I know how to use basic command line utilities. I know how to use Vim. I work on servers at my internship. I maintain about 4. Now, here I am in CS 401… with 8 machines that I need to not only install an OS on and configure, but make them talk to each other as a full Eucalyptus cluster. It’s taking far longer to set this up than expected, but I feel accomplished because it took a lot of work to get to where I am today.

Understanding Eucalyptus

I came into this project knowing literally nothing about cloud computing. But from reading the Eucalyptus documentation, I have a vague understanding of what the various components do.

The first component is the Cloud Controller (CLC). The CLC is the gateway for access to a cluster. It basically runs the show. Note that I said clusters, plural. The CLC make high-level decisions and talks to the cluster controllers. Next, is Walrus, a persistent storage system for the users virtual machine images. The data is organized into buckets (get it?). Walrus can be installed on the same server as the CLC. The Cluster Controller (CC) is in charge of managing several Node Controllers (NCs). The CC also handles access to the Storage Controller (SC) which interfaces with different storage methods. The NCs are servers that run a virtual machine hypervisor (such as KVM or Xen).  The hypervisor manages all the virtual machines (VMs) that are running on the server. Put it all together and you have yourself a cloud!

Preparing Servers

My class has 8 machines running CentOS 6.1. One server will be the CLC, running Walrus as well. One server will be the CC/SC. The remaining 6 will be our nodes. If combining tasks on the servers becomes a problem, it shouldn’t be too difficult to move them to other servers, the only downside being that we will have less NCs.

I was confused about which VM hypervisor was going to be installed on the machines. All of the Eucalyptus 2.0 guides were giving instructions to install Xen. However, when I tried to install the Xen packages, they were not found. After some googling, I learned that with CentOS 6, support for Xen was dropped in favor of KVM.

Compiling from Source

I grabbed the latest and greatest code from the Eucalyptus Launchpad page. I found 3 helpful documents that allowed me to successfully build Eucalyptus. one two three. I’ve been documenting the process as I go on the CS 401 Wiki. It took A LOT of reading and some help from the #eucalyptus IRC channel, but I did it! CS 401 is now in possession of some fresh 3.1 binaries.

Installing Eucalyptus

Now that I have Eucalyptus 3.1 built, I need to install it on all of our machines. I have been using rsync to copy the binaries to the other servers. The CLC, CC, SC,  Walrus, and NC require different Eucalyptus services to be running in order for them to function. As of this writing I am currently having some trouble initializing the databases on the NCs.

I’ve made more progress this past week than any other week so far. Hopefully we can have a functional system in a week’s time.

From the blog David Thompson » WSU CS by davexunit and used with permission of the author. All other rights reserved by the author.

This week’s (actually last week now, 2/13) class was all about Git. Git is a wonderful version control system that I already use frequently for my own personal projects. Git is a distributed version control system rather than a centralized version control system like Subversion or CVS. This means that everyone that works in a code repository has a full copy of the source code history. There is often a central storage place for the “official” source code but in theory there is no central hub that is relied upon by others.

What did we learn how to do? Well, Karl Wurst made us some test repositories on the CS git server. This included a few example files that we would edit. My team “cloned” the repository and made the changes, and when some of us tried to “push” the changes back… CONFLICT! Prof. Wurst had designed the exercise in such a way that we would see a merge conflict occur. When a merge conflict happens, git alters the conflicted files by putting in both your version and the conflicts marked by special characters. I simply deleted what was unnecessary to resolve the conflict, and “committed” the changes to my repository. Now I was able to push successfully.

In System Administrator land, Mike Iudiciani and I have been working to put together a small cluster on which we will install the Eucalyptus software. We’ve run into a lot of annoying problems with OS installation and the networking configuration. We were first plagued with bad install media, and then we had trouble getting the machines online. Once we finally had good install CDs, I talked to IT about how to configure our machines network interfaces and voila, we were online. Now begins the process of installing the Eucalyptus software.

From the blog David Thompson » WSU CS by davexunit and used with permission of the author. All other rights reserved by the author.

Alright, things are starting to pick up!

The class voted on which project we would be working on for the semester by ranking the projects by preference. Among the possibilities were Irrlicht, Eucalyptus, Firefox, LibreOffice, and VLC. We kept the top 2 for consideration: Eucalyptus and Irrlicht,

Eucalyptus is cloud computing platform that bears many similarities to Amazon’s proprietary EC2 platform. Cloud computing is a huge industry buzz word lately that means a different thing depending on who you ask, so maybe as this semester goes on I will know to define it properly. The big advantage this project has is that our instuctor, Karl Wurst, knows 2 of the developers and they really want us to work on Eucalyptus and will offer us as much assistance as possible. There is an open source and a commercial version of Eucalyptus. Being the FOSS advocate that I am, it concerns me a bit that certain features are witheld and appear only in the commercial product. Maybe it’s because I have nightmares about Oracle and what they are doing to MySQL with open core. On the other hand, it’s great that a company is releasing a (mostly) fully featured product under the GPL 3 license. To work on this project we will be installing some flavor of Red Hat style OS (likely CentOS 6) onto 8 machines and making a cluster out of them. I have never made a cluster before so my inner system administrator is excited to get it up and running. Our goal will be to get a functional “cloud” environment set up running the latest and greatest Eucalyptus 3.0 code, which has not been released into the wild yet. The class will be writing installation documentation and bug reporting, but I’m keeping my fingers crossed that I will be getting some real commits into the code repository by the end of the semester.

The great Karl Wurst (can I have an A, please?) may let some students work on the Irrlicht project as well.  Irrlicht is a cross platform 3D library written in C++. The Irrlicht developers are interested in creating a test suite for benchmarking purposes, and they want my class to help write it. As far as resume material goes, I think Eucalyptus will be the more fruitful project. On the other hand, I do dabble in game development and have used a similar library before called OGRE, as well as used the OpenGL C API directly, so I am interested in this project as well. I don’t see myself actually being able to work on this, even if we are given the option as my time will surely be focused on Eucalyptus.

This class is making do all of the good things that I have been too lazy to learn how to use effectively on my own, like writing these blog posts and subscribing to listservs. Listservs are a great resource for project discussion that I never found convenient enough to actually use. Time to change that.

From the blog David Thompson » WSU CS by davexunit and used with permission of the author. All other rights reserved by the author.