]> This section contains a small selection of use cases from the community with more technical detail than usual. Further examples can be found on the OpenStack Website (https://www.openstack.org/user-stories/)

Who uses it: Researchers from the Australian publicly funded research sector. Use is across a wide variety of disciplines, with the purpose of instances being from running simple web servers to using hundreds of cores for high throughput computing.

Using OpenStack Compute Cells, the NeCTAR Cloud spans eight sites with approximately 4,000 cores per site. Each site runs a different configuration, as resource cells in an OpenStack Compute cells setup. Some sites span multiple data centers, some use off compute node storage with a shared file system and some use on compute node storage with a non-shared file system. Each site deploys the Image Service with an Object Storage back-end. A central Identity Service, Dashboard and Compute API Service is used. Login to the Dashboard triggers a SAML login with Shibboleth, that creates an account in the Identity Service with an SQL back-end. Compute nodes have 24 to 48 cores, with at least 4 GB of RAM per core and approximately 40 GB of ephemeral storage per core. All sites are based on Ubuntu 12.04 with KVM as the hypervisor. The OpenStack version in use is typically the current stable version, with 5 to 10% back ported code from trunk and modifications.

OpenStack.org Case Study (https://www.openstack.org/user-stories/nectar/) NeCTAR-RC GitHub (https://github.com/NeCTAR-RC/) NeCTAR Website (https://www.nectar.org.au/)

Who uses it: Researchers from the MIT Computer Science and Artificial Intelligence Lab.

The CSAIL cloud is currently 64 physical nodes with a total of 768 physical cores and 3,456 GB of RAM. Persistent data storage is largely outside of the cloud on NFS with cloud resources focused on compute resources. There are more than 130 users in more than 40 projects with typically running 2,000 - 2,500 vCPUs in 300 to 400 instances. We initially deployed on Ubuntu 12.04 with the Essex release of OpenStack using FlatDHCP multi host networking. The software stack is still Ubuntu 12.04 LTS but now with OpenStack Havana from the Ubuntu Cloud Archive. KVM is the hypervisor, deployed using FAI (http://fai-project.org/) and Puppet for configuration management. The FAI and Puppet combination is used lab wide, not only for OpenStack. There is a single cloud controller node, which also acts as network controller, the remainder of the server hardware dedicated to compute nodes. Host aggregates and instance type extra specs are used to provide two different resource allocation ratios. The default resource allocation ratios we use are 4:1 CPU and 1.5:1 RAM. Compute intensive workload use instance types that require non-oversubscribed hosts where cpu_ratio and ram_ration are both set to 1.0. Since we have HyperThreading enabled on our compute nodes this provides one vCPU per CPU thread, or two vCPU per physical core. With our upgrade to Grizzly in August 2013 we moved to OpenStack Networking Service, Neutron (Quantum at the time). Compute nodes have two gigabit network interfaces and a separate management card for IPMI management. One network interface is used for node to node communications. The other is used as a trunk port for OpenStack managed VLANs. The controller node uses two bonded 10g network interfaces for it's public IP communications. Big pipes are used here because images are served over this port and it is also used to connect to iSCSI storage back-ending the image storage and database. The controller node also has a gigabit interface that is used in trunk mode for OpenStack managed VLAN traffic, this port handles traffic to the dhcp-agent and metadata-proxy. We approximate the older nova-networking multi-host HA setup by using 'provider vlan networks' that connect instances directly to existing publicly addressable networks and use existing physical routers as their default gateway. This means that if our network controller goes down running instances will still have their network available and no single Linux host becomes a traffic bottleneck. We are able to do this because we have a sufficient supply of IPv4 addresses to cover all of our instances and thus don't need NAT and don't use floating IP addresses. We provide a single generic public network to all projects and additional existing VLANs on a project by project basis as needed. Individual projects are also allowed to create their own private GRE based networks.

CSAIL Homepage (http://www.csail.mit.edu)

Who uses it: DAIR is an integrated virtual environment that leverages the CANARIE network to develop and test new information communication technology (ICT) and other digital technologies. It combines such digital infrastructure as advanced networking, and cloud computing and storage to create an environment for develop and test of innovative ICT applications, protocols and services, perform at-scale experimentation for deployment, and facilitate a faster time to market.

DAIR is hosted at two different data centers across Canada: one in Alberta and the other in Quebec. It consists of a cloud controller at each location, however, one is designated as the "master" controller that is in charge of central authentication and quotas. This is done through custom scripts and light modifications to OpenStack. DAIR is currently running Grizzly. For Object Storage, each region has a Swift environment. A NetApp appliance is used in each region for both block storage and instance storage. There are future plans to move the instances off of the NetApp appliance and onto a distributed file system such as Ceph or GlusterFS. VlanManager is used extensively for network management. All servers have two bonded 10gb NICs that are connected to two redundant switches. DAIR is set up to use single-node networking where the cloud controller is the gateway for all instances on all compute nodes. Internal OpenStack traffic (for example, storage traffic) does not go through the cloud controller.

DAIR Homepage (http://www.canarie.ca/en/dair-program/about)

Who uses it: Researchers at CERN (European Organization for Nuclear Research) conducting high-energy physics research.

The environment is largely based on Scientific Linux 6, which is Red Hat compatible. We use KVM as our primary hypervisor although tests are ongoing with Hyper-V on Windows Server 2008. We use the Puppet Labs OpenStack modules to configure Compute, Image Service, Identity Service and Dashboard. Puppet is used widely for instance configuration and Foreman as a GUI for reporting and instance provisioning. Users and Groups are managed through Active Directory and imported into the Identity Service using LDAP. CLIs are available for Nova and Euca2ools to do this. There are 3 clouds currently running at CERN, totaling around 3400 Nova Compute nodes, with approximately 60,000 cores. The CERN IT cloud aims to expand to 300,000 cores by 2015.

OpenStack in Production: A tale of 3 OpenStack Clouds (openstack-in-production.blogspot.com/2013/09/a-tale-of-3-openstack-clouds-50000.html) Review of CERN Data Centre Infrastructure (http://cern.ch/go/N8wp) CERN Cloud Infrastructure User Guide (http://information-technology.web.cern.ch/book/cern-private-cloud-user-guide)