Author: Wido den Hollander

A quick note on running CloudStack with RBD on Ubuntu 12.04

When you want to use Ceph as Primary Storage in Apache CloudStack you need a recent version of libvirt with RBD storage pool support enabled.

If you want to use Ubuntu 12.04 LTS (Precise) you would need to manually compile libvirt since the default libvirt version doesn’t include RBD storage pool support.

But not any more! Ubuntu has their Cloud Archive which is aimed at OpenStack, but that doesn’t matter, we just want a newer version of libvirt with RBD storage pool support.

So, add this PPA and a Apt source for Ceph and you can use RBD with CloudStack without compiling anything!

$ sudo apt-get install ubuntu-cloud-keyring
$ echo deb http://ubuntu-cloud.archive.canonical.com/ubuntu precise-updates/grizzly main | sudo tee /etc/apt/sources.list.d/cloud-archive.list
$ wget -q -O- 'https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/release.asc' | sudo apt-key add -
$ echo deb http://eu.ceph.com/debian-cuttlefish/ $(lsb_release -sc) main | sudo tee /etc/apt/sources.list.d/ceph.list
$ sudo apt-get install cloudstack-agent

Voila, you now have all the packages you need to run a CloudStack agent with RBD support.

How I built my 3-phase Open EVSE

Ever since I posted on my blog that I built my own Open EVSE for my future Tesla Model S I’m getting a lot of e-mails from people asking how I build it.

A couple of notes to everybody who wants to build one:

I’m using a Open EVSE board with a modified firmware
I modified the firmware so that with the Advanced Power Supply it will switch to level 2 charging when it senses 230V on L1.

The source code can be found on my Github account.

I also have two compiled versions (with LCD support) available (both from 01-09-2012):

You can program the EVSE using ‘avrdude’ and the right programmer.

The relais I’m using is a 40A 4p
I’m using a Hager ESL440S relais.

This relais has 4 poles and works on 12V AC or DC.

There is a second relais which switches on my main relais
The main relais (Hager ESL440S) works on 12V DC, but pulls about 1000mA to switch on.

That is a bit to much for the Open EVSE board, so I had to buy a 12V DC transformer and a second smaller relais. When Open EVSE board switches on the small relais, it switches on the main relais by using the external 12V transformer.

If you go to page 8 of the PDF I wrote you can see these components.

In the casing where the Open EVSE board is you can see the small relais on the left.

The external 12V DC power supply is in the distribution panel on the right and is on the left of the main relais. You can see the green and red LED on it.

I limited my EVSE to 30A
I limited the pilot signal to 30A. 32A would stress some fuses in the distribution panel in my house, since that 32A relais also provides power to the TL-lights in my shed. So I turned the EVSE down to 30A instead of 32A. Technically I could use 32A, but 30A was a safe bet in this case.

1-phase of 3-phase doesn’t matter
The EVSE itself doesn’t know anything about 1-phase or 3-phase. When a car connects and talks to the EVSE it requests power, when all the criteria match the EVSE turns on the relais.

The car then senses 3-phases and will use them if the charger supports it. The EVSE has nothing to do with that.

To conclude:

  • Read the PDF I wrote.
  • For the EVSE 3-phase or 1-phase doesn’t matter. It just switches on a relais.
  • Read the Open EVSE website about J1772, programming, etc, etc

Redundant Ceph monitors with Round Robin DNS

One of the unique features of Ceph is that it can be build without any Single Point of Failure. No single machine will take your cluster down when designed properly.

Ceph’s monitors play a crucial part in this. To make them redundant you want a odd number of monitors, where 3 is more then sufficient for most clusters.

When librados (The RADOS client) reads the ceph.conf it can read something like:

[mon.a]
  mon addr = 192.168.0.1:6789

[mon.b]
  mon addr = 192.168.0.2:6789

[mon.c]
  mon addr = 192.168.0.3:6789

The problem is that when working with for example Apache CloudStack you can’t have it read a ceph.conf nor does CloudStack support multiple Ceph monitors.

The reason behind this is that CloudStack passes storage pools in the form or URIs internally, for example: rbd://1.2.3.4:6789/mypool

So you’d be stuck with a single monitor in CloudStack. It’s not a disaster, since when a client successfully connects to the Ceph cluster it will receive a monitor map which tells it which other monitors are available should the one he’s connected to fail. But when you want to connect when that specific monitor is down you have a problem.

A solution to this is to create a Round Robin DNS record with all your monitors in it:

monitor.ceph.lan. A 192.168.0.1
monitor.ceph.lan. A 192.168.0.2
monitor.ceph.lan. A 192.168.0.3

You can have your librados client connect to “monitor.ceph.lan” and it will connect to one of the monitors listed in that A record. Is one of the monitors down? It will connect to another one.

This doesn’t only work with CloudStack, but it works with any RADOS client like Qemu, libvirt, phprados, rados-java, python-rados, etc, etc. Anything that connects via librados.

P.S.: Ceph fully (!) supports IPv6, so you can also create a Round Robin AAAA-record 🙂