Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
OpenStack Components
There are currently seven core components of OpenStack: Compute, Object Storage, Identity,
Dashboard, Block Storage, Network and Image Service. Let’s look at each in turn:
Object Store (codenamed “Swift“) allows you to store or retrieve files (but not mount directories
like a fileserver). Several companies provide commercial storage services based on Swift. These
include KT, Rackspace (from which Swift originated) and Hewlett-Packard. Swift is also used
internally at many large companies to store their data.
Image Store (codenamed “Glance“) provides a catalog and repository for virtual disk images.
These disk images are mostly commonly used in OpenStack Compute.
Compute (codenamed “Nova“) provides virtual servers upon
demand. Rackspace and HP provide commercial compute services built on Nova and it is used
internally at companies like Mercado Libre, Comcast, Best Buy and NASA (where it originated).
Dashboard (codenamed “Horizon“) provides a modular web-based user interface for all the
OpenStack services. With this web GUI, you can perform most operations on your cloud like
launching an instance, assigning IP addresses and setting access controls.
Identity (codenamed “Keystone“) provides authentication and authorization for all the
OpenStack services. It also provides a service catalog of services within a particular OpenStack
cloud.
Network (which used to named “Quantum” but is in the process of being renamed due to a
trademark issue) provides “network connectivity as a service” between interface devices
managed by other OpenStack services (most likely Nova). The service works by allowing users to
create their own networks and then attach interfaces to them. Quantum has a pluggable
architecture to support many popular networking vendors and technologies.
Block Storage (codenamed “Cinder“) provides persistent block storage to guest VMs. This
project was born from code originally in Nova (the nova-volume service that has been
depricated). While this was originally a block storage only service, it has been extended to NFS
shares.
In addition to these core projects, there are also a number of non-core projects that will be
included in future OpenStack releases.
Conceptual Architecture
The OpenStack project as a whole is designed to “deliver(ing) a massively scalable cloud
operating system.” To achieve this, each of the constituent services are designed to work together
to provide a complete Infrastructure as a Service (IaaS). This integration is facilitated through
public application programming interfaces (APIs) that each service offers (and in turn can
consume). While these APIs allow each of the services to use another service, it also allows an
implementer to switch out any service as long as they maintain the API. These are (mostly) the
same APIs that are available to end users of the cloud.
Conceptually, you can picture the relationships between the services as so:
Dashboard provides a web front end to the other OpenStack services
Compute stores and retrieves virtual disks (“images”) and associated metadata in the Image
Store (“Glance”)
Network provides virtual networking for Compute.
Block Storage provides storage volumes for Compute.
Image Store can store the actual virtual disk files in the Object Store
All the services authenticate with Identity
This is a stylized and simplified view of the architecture, assuming that the implementer is using
all of the services together in the most common configuration. However, OpenStack does not
mandate an all-or-nothing approach. Many implementers only deploy the pieces that they need.
For example, Swift is a popular object store for cloud service providers, even if they deploy
another cloud compute infrastructure.
The diagram also only shows the “operator” side of the cloud — it does not picture how
consumers of the cloud may actually use it. For example, many users will access object storage
heavily (and directly).
Logical Architecture
As you can imagine, the logical architecture is far more complicated than the conceptual
architecture shown above. As with any service-oriented architecture, diagrams quickly become
“messy” trying to illustrate all the possible combinations of service communications. The
diagram below, illustrates the most common architecture of an OpenStack-based cloud.
However, as OpenStack supports a wide variety of technologies, it does not represent the only
architecture possible.
End users interact through a common web interface or directly to each service through their API
All services authenticate through a common source (facilitated through Keystone)
Individual services interact with each other through their APIs (except where privileged
administrator commands are necessary) — including the user’s web interface
In the sections below, we’ll delve into the architecture for each of the services.
Dashboard
Horizon is a modular Django web application that provides an end user and cloud operator
interface to OpenStack services.
The interface has user screens for:
In addition to the user screens, it also provides an interface for cloud operators. The operator
interface sees across the entire cloud and adds some configuration focused screens such as:
Flavors to define service catalog offerings of CPU, memory and boot disk storage
Projects to provide logical groups of user accounts
Users to administer user accounts
System Info to view services running in the cloud and quotas applied to projects
The Grizzly edition of Horizon adds a few new features as well as significant refactoring to the
user experience:
Networking
Direct image upload to Glance
Support for flavor extra specs
Migrate instances to other compute hosts
User experience improvements
The Horizon architecture is fairly simple. Horizon is usually deployed via mod_wsgi in Apache.
The code itself is separated into a reusable python module with most of the logic (interactions
with various OpenStack APIs) and presentation (to make it easily customizable for different
sites).
From a network architecture point of view, this service will need to be customer accessible as
well as be able to talk to each service’s public APIs. If you wish to use the administrator
functionality (i.e. for other services), it will also need connectivity to their Admin API endpoints
(which should not be customer accessible).
Compute
Nova is the most complicated and distributed component of OpenStack. A large number of
processes cooperate to turn end user API requests into running virtual machines. Among Nova
more prominent features are:
There are several changes to the architecture in this release. These changes include the
depreciation of nova-network and nova-volume as well as the decoupling of nova-computefrom
the database (through the no-compute-db feature). All of these changes are all optional (the old
code is still available to be used), but are slated to disappear soon.
Nova interacts with many other OpenStack services: Keystone for authentication, Glance for
images and Horizon for web interface. The Glance interactions are central. The API process can
upload and query Glance while nova-compute will download images for use in launching
images.
Object Store
OpenStack’s Object Store (“Swift”) is designed to provide large scale storage of data that is
accessible via APIs. Unlike a traditional file server, it is completely distributed, storing multiple
copies of each object to achieve greater availability and scalability. Swift provides the following
user functionality:
The swift architecture is very distributed to prevent any single point of failure as well as to scale
horizontally. It includes the following components:
Proxy server (swift-proxy-server) accepts incoming requests via the OpenStack Object API or just
raw HTTP. It accepts files to upload, modifications to metadata or container creation. In
addition, it will also serve files or container listing to web browsers. The proxy server may utilize
an optional cache (usually deployed with memcache) to improve performance.
Account servers manage accounts defined with the object storage service.
Container servers manage a mapping of containers (i.e folders) within the object store service.
Object servers manage actual objects (i.e. files) on the storage nodes.
There are also a number of periodic process which run to perform housekeeping tasks on the
large data store. The most important of these is the replication services, which ensures
consistency and availability through the cluster. Other periodic processes include auditors,
updaters and reapers. Authentication for the object store service is handled through configurable
WSGI middleware (which will usually be Keystone).
To learn more about Swift, head over to the SwiftStack website and read their OpenStack Swift
Architecture.
Image Store
OpenStack Image Store centralizes virtual images for users and other cloud services:
Stores public and private images that users can utilize to start instances
Users can query and list available images for use
Delivers images to Nova to start instances
Snapshots from running instances can be stored so that virtual machines can be backed
The Glance architecture has stayed relatively stable since the Cactus release.
glance-api accepts Image API calls for image discovery, image retrieval and image storage.
glance-registry stores, processes and retrieves metadata about images (size, type, etc.).
A database to store the image metadata. Like Nova, you can choose your database depending
on your preference (but most people use MySQL or SQlite).
A storage repository for the actual image files. In the diagram above, Swift is shown as the
image repository, but this is configurable. In addition to Swift, Glance supports normal
filesystems, RADOS block devices, Amazon S3 and HTTP. Be aware that some of these choices
are limited to read-only usage.
There are also a number of periodic process which run on Glance to support caching. The most
important of these is the replication services, which ensures consistency and availability through
the cluster. Other periodic processes include auditors, updaters and reapers.
As you can see from the diagram in the Conceptual Architecture section, Glance serves a central
role to the overall IaaS picture. It accepts API requests for images (or image metadata) from end
users or Nova components and can store its disk files in the object storage service, Swift.
Identity
Keystone provides a single point of integration for OpenStack policy, catalog, token and
authentication:
Authenticate users and issue tokens for access to services
Store users and tenants for a role-based access control (RBAC)
Provides a catalog of the services (and their API endpoints) in the cloud
Create policies across users and services
keystone handles API requests as well as providing configurable catalog, policy, token and
identity services.
Each Keystone function has a pluggable backend which allows different ways to use the
particular service. Most support standard backends like LDAP or SQL, as well as Key Value Stores
(KVS).
Most people will use this as a point of customization for their current authentication services.
Network
Users can create their own networks and then attach server interfaces to them
Pluggable backend architecture lets users take advantage of commodity gear or vendor
supported equipment
Extensions allow additional network services like load balancing
Like many of the OpenStack services, Quantum is highly configurable due to it’s
plug-in architecture. These plug-ins accommodate different networking equipment
and software. As such, the architecture and deployment can vary dramatically.
Quantum will interact mainly with Nova, where it will provide networks and
connectivity for its instances. Florian Otel has written very thorough article on implementing
Open vSwitch is you are looking for an example of Quantum in action.
Block Storage
Cinder separates out the persistent block storage functionality that was
previously part of Openstack Compute (in the form of nova-volume) into it’s own
service. The OpenStack Block Storage API allows for manipulation of volumes,
volume types (similar to compute flavors) and volume snapshots:
It’s architecture follows the Quantum model, which provides for a northbound API and vendor
plugins underneath it.
Like Quantum, Cinder will mainly interact with Nova, providing volumes for its
instances.
Future Projects
In the next version of OpenStack (“Havana” which is due in the Fall of 2013), two new projects
will be brought into the fold:
Ceilometer is a metering project. The project offers metering information and the ability to code
more ways to know what has happened on an OpenStack cloud. While it provides metering, it is
not a billing project. A full billing solution requires metering, rating, and billing. Metering lets
you know what actions have taken place, rating enables pricing and line items, and billing
gathers the line items to create a bill to send to the consumer and collect payment. For users
that also want a billing package, BillingStack is another open source project that provides
payment gateway and other billing features. Ceilometer is available as a preview now.
Heat provides a REST API to orchestrate multiple cloud applications implementing standards
such as AWS CloudFormation.
Looking beyond the “Havana” release, OpenStack is slated to see the addition of two more
projects in the Spring of 2014 (for the newly named “Icehouse” release):
Reddwarf is a database as a service offering that provides MySQL databases within OpenVZ
containers upon demand.
Ironic is the aptly named project that uses OpenStack to deploy bare metal servers instead of
virtualized cloud instances.