Tag: cluster

Introduction to Apache Mesos

Service scheduling and task placement within large-scale clusters is receiving a lot of interest in the cloud community at present. Moreover, service scheduling is one of the keystones of our recently kicked off ACeN project and we finally got a chance to experiment with the technology that is currently a frontrunner in this area – Apache Mesos. As Mesos provides much more control of service placement than current available built-in IaaS schedulers it elegantly addresses many problems in data centers such as task data locality, efficient resource utilization or efficient load variation accommodation. This blogpost describes Mesos architecture, its basic workflow and explains why we think it’s a big deal also in the cloud context.

Continue reading

Puppet and OpenStack: Part Two

In our [last article](http://www.cloudcomp.ch/2012/07/puppet-and-openstack-part-one/ ) we setup OpenStack using puppet on one node. In this article we’ll look at setting up OpenStack in a clustered environment. For this we’ll use the following configuration of VMs:

* The hypervisor is [VirtualBox](http://www.virtualbox.org).

* 1 OpenStack **Controller** VM.

This will host all the main services of OpenStack and will not run any virtual machines. This will be running Ubuntu 12.04 and acting as the puppetmaster. It will require 3 adapters:

– `eth0`: Host-only. Assign this an IP that matches the VirtualBox virtual switch.
– `eth1`: Host-only. Leave this unassigned. OpenStack will look after this and place a linux kernel bridge upon in named `br100`.
– `eth2`: NAT. Setup this adapter as [shown in previous articles](http://www.cloudcomp.ch/2012/06/automating-the-icclab-part-one/).

* 2 OpenStack **Compute Node** VMs.

This will only act as a node that that provide virtual machines and storage volumes when requested by the OpenStack controller VM. This will be running Ubuntu 12.04 and acting as a puppet agent (slave). These VMs will require 2 adapters:

– `eth0`: Host-only. Assign this an IP that matches the VirtualBox virtual switch.
– `eth1`: Host-only. Leave this unassigned. OpenStack will look after this.

In both cases above, `eth0` and `eth1` can share the same or different networks. In our case we set them to different virtual networks (`vboxnet0` and `vboxnet1` respectively).

## OpenStack Controller Setup

Once the controller VM is up and running and you have configured `eth2`, the next task at hand is to configure puppet. You can use the same puppet configuration as was shown in [the article on creating an OpenStack all-in-one installation](http://www.cloudcomp.ch/2012/07/puppet-and-openstack-part-one/). The same hostname configuration is also the same, however as there are two other nodes to deal with in the setup you should place these in your `/etc/hosts` file (unless you’re using a setup with a DNS server). With your puppet and hostname resolution configured, install the puppet modules as shown in the previous article. Where things begin to differ is in the configuration of `/etc/puppet/manifests/site.pp`.

In the `site.pp` file we will be using 2 different `node` definitions. One for the controller node and the second for compute nodes. For the controller node we will explicitly set the node name to that of the fully qualified domain name of the controller VM. The definition is then:

[gist id=3029148]

In the second case we are going to set the node name to one that contains a regular expression so that any hostname that is certified by the puppetmaster and matches the regular expression can partake to provide virtual machine capabilities. The definition is then:

[gist id=3029150]

With your nodes defined in `site.pp` you will need to set some particular variables:

* Global:
* set `$public_interface` to `’eth0’`
* set `$private_interface` to `’eth1’`
* Controller-specific:
* set `$controller_node_address` to the IP address that you have set to `eth0`. In our case it’s `’’`
* set `floating_range` to `’’`. This will give you enough floating IP address in this test setup.
* Compute node-specific:
* set `libvirt_type` to `’qemu’`

Now either ensure the puppet agent is running on the controller node or run the puppet agent in the foreground. Once the puppet agent on the controller node contacts the puppetmaster it will install all the necessary services for an OpenStack controller.

## OpenStack Compute Node Setup
There is little here for you to do other than ensure that the puppet agent process is configured properly and can contact the puppetmaster. When each compute node first contacts the puppetmaster they will have issued a new certificate request and will wait until the puppetmaster signs these certificates. In order to sign these you can quickly do this by issuing the command:

[gist id=3029151]

Again as in the case of the all-in-one installation, the `nova-volumes` group is not setup so [follow the previous steps to setup is up](http://www.cloudcomp.ch/2012/07/puppet-and-openstack-part-one/). Once the puppet agent on each of the compute node contacts the puppetmaster it will install all the necessary services for an OpenStack compute node.

## Validating the Install
Once all services on all VMs have been installed you should be able to list that all nodes are operational. To validate this, execute the following:

[gist id=3029153]

You should see the following output:

[gist id=3029145]

You may want to run some VMs at this stage so you will need to import a VM image into glance. This is [detailed here](http://www.cloudcomp.ch/2012/07/puppet-and-openstack-part-one/).

## Next up
We’ve now successfully installed a clustered OpenStack using puppet. In the next article we’ll look at expanding this to combine both Foreman, puppet and OpenStack so that we can go from bare metal to a multi-node, clustered OpenStack installation. Stay tuned!

***Note***: If you want copies of the VMs used in this article ping [@dizz](http://www.twitter.com/dizz)