[Openstack-operators] expanding to 2nd location

Tim Bell Tim.Bell at cern.ch
Tue May 5 05:29:01 UTC 2015

CERN runs two data centres in Geneva (3.5MW) and Budapest (2.7MW), around
1,200 KMs . We have two 100Gb/s links between the two sites and latency of
around 22ms. 

We run this as a single cloud with 13 cells. Each cell is only in one data

We wanted a single API endpoint from the user perspective and thus, we did
not use regions.

There are things to consider such as

- Availability zone set up so that people can choose which centre to place
work in (such as disaster recovery)
- Scheduling of work for projects and localisation of the volumes for
those Vms (we¹ve not found a good solution for this one)

In an ideal world, we¹d have a high availability API layer for the cells
across two sites. We¹ve not got that far yet.


On 5/5/15, 3:42 AM, "Tom Fifield" <tom at openstack.org> wrote:

>On 05/05/15 04:40, Jonathan Proulx wrote:
>> Hi All,
>> We're about to expand our OpenStack Cloud to a second datacenter.
>> Anyone one have opinions they'd like to share as to what I would and
>> should be worrying about or how to structure this?  Should I be
>> thinking cells or regions (or maybe both)?  Any obvious or not so
>> obvious pitfalls I should try to avoid?
>> Current scale is about 75 hypervisors.  Running juno on Ubuntu 14.04
>> using Ceph for volume storage, ephemeral block devices, and image
>> storage (as well as object store).  Bulk data storage for most (but by
>> no means all) of our workloads is at the current location (not that
>> that matters I suppose).
>> Second location is about 150km away and we'll have 10G (at least)
>> between sites. The expansion will be approximately the same size as
>> the existing cloud maybe slightly larger and given site capacities the
>> new location is also more likely to be where any future grown goes.
>Do you need users to be able to see it as one cloud, with a single API
>OpenStack-operators mailing list
>OpenStack-operators at lists.openstack.org

More information about the OpenStack-operators mailing list