HP Reference Architecture for OpenStack on Ubuntu 14.04 LTS

Technical white paper | Product, solution, or service

For example, a cloud administrator might be able to list all instances in the cloud, whereas a user can only see those in their

current group. Resource quotas, such as the number of cores that can be used, disk space, and so on, are associated with a

project.

The OpenStack Identity Service (Keystone) is the point that provides the authentication decisions and user attribute

information, which is then used by the other OpenStack services to perform authorization. Policy is set in the

policy.json file.

The Identity Service supports different plugins for back-end authentication decisions, and storing information. These range

from pure storage choices to external systems and currently include:

• In-memory Key-Value Store

• SQL database

• PAM

• LDAP

Many deployments use the SQL database; however LDAP is also a popular choice for those with existing authentication

infrastructure that needs to be integrated. In organizations that have a centralized LDAP server for authentication, using

LDAP allows synchronizing its use with the HP iLO based credentials used to access the server iLO management controller

so it is a good choice in this case. This reference architecture uses an SQL database for the identity storage instead of

depending on LDAP being present. If LDAP is available, the OpenStack Operations Guide shows how you can configure LDAP

to enable its use with the OpenStack Identity Service.

Network considerations

Because the cloud controller handles so many different services, it must be able to handle the amount of traffic that hits it.

For example, if you choose to host the OpenStack Imaging Service on the cloud controller, the cloud controller should be

able to support the transferring of the images at an acceptable speed. We recommend that you use a fast NIC, such as

10 GbE. This reference architecture specifies 10GbE NICs for all network connections between the server and the network

switch.

MAAS and Juju

MAAS (Metal As A Service) is a tool that helps you manage physical infrastructure with the same ease and flexibility as virtual

machines in the cloud. Specially, MAAS allows you to:

• Discover, commission and deploy physical servers

• Dynamically allocate physical resources to match workload requirements.

• Retire servers when they are no longer needed and make them available for new workloads as required.

MAAS is responsible for hardware discovery and for installing Ubuntu, making basic hardware configurations and allowing

servers to be recognized by network and system management software. When a new node boots up, MAAS steps in,

supplies it with all the required information and provides an OS image install. This is done via PXE and DHCP. MAAS provides

both a web interface and an API to manage bare metal systems under its control.

MAAS works in conjunction with Juju. Juju is a service orchestration tool which allows the administrator to configure,

manage, maintain, deploy and scale cloud services (workloads) quickly and efficiently on public clouds as well as on bare

metal, leveraging MAAS to control the hardware. Juju uses descriptions of services called Charms which understand how to

deploy and scale a variety of complex architectures like OpenStack. Juju can be controlled via a web GUI, the command line,

or API.

Reference architecture

When implementing an OpenStack cloud, you make many choices that influence the resulting implementation. For this

document we have made some decisions that allow for a small- to medium-size cloud installation that scales well. We have

specified a set of compute nodes with a uniform configuration. Adding additional compute capacity is as simple as adding

additional compute nodes. Block storage is allocated on a separate storage node. Object storage is provided by a two node

storage cluster. Both block and object storage can be scaled by adding additional storage nodes. Neutron networking