Presentation from OpenStack Summit in April 2013. Building upon his popular blog posts and diagrams (http://ken.pepple.info), Ken will walk through the architecture of OpenStack Grizzly and describe its key software components and important interactions with a special focus on recent changes. After finishing with the software architecture, he will discuss common physical design patterns available for large scale deployments.

1. Introduction to
OpenStack Architecture
Grizzly Edition

2. About Me
 CTO, Solinea
 Former Director of Cloud
Development, Internap
Public Cloud
 Author of O’Reilly
“Deploying OpenStack”
 Code contributor since
Bexar
 Twitter @ken_pepple
 IRC kpepple
2

3. Conceptual Architecture
Dashboard
Provides
UI for Provides Provides
Provides UI for Provides UI for
UI for UI for
Provides
Network Auth for
Provide
network
connectivity Stores Stores disk Object
for Compute images in files in Storage
Image
Provides
volumes
Block for
Provides
Storage Provides Auth for
Provides
Auth for
Auth for
Provides
Auth for
Provides
Auth for http://www.solinea.com
3
Identity

4. OpenStack Basics
 Everything is written in python
 End users can interact through a common web interface
(Horizon) or directly to each service through their API
 All services authenticate through a common source
 Individual services interact with each other through their
public APIs *
 Most daemons implemented WSGI middleware (Paste)
– Used extensively in OpenStack
– Configured through *-paste.ini files
4

5. Grizzly Logical Architecture
⁃ OpenS ack C
t ommand Line Tools (Novaclient, Swif t client, et c.)
⁃ Cloud M anagement Tools (Right scale, E raius, et c.)
nst
⁃ G t ools (C
UI yberduck, iPhone client, et c.)
Int er net
OpenS ack
t
OpenStack OpenS ack
t Comput e API
Identity Image API H (S)
TTP OpenStack VNC VMRC
/
OpenS ack
t AP I Amazon
Object API Dashboard Web Ser vices O penS ack
t
E 2 API
C Block S orage API
t
Hor izon
OpenS ack
t OpenS ack
t
HTTP(S) Net wor k API Net wor k API
OpenStack O penS ack
t OpenS ack
t
Object API OpenStack Block S orage API
t Net wor k API
Image API OpenStack Compute
OpenStack AP /
I
Identity Admin AP I
AP I
nova-api cinder-api
OpenS ack
t quant um-ser ver
OpenS ack
t Image API
(O E 2, Admin)
S, C nova-console
swif t-proxy Object API
glance-api
OpenS ack
t
Image
API
memcached nova-cert/ cinder-volume
nova-comput e
objectstore AMQP
glance-regist r y
quant um quant um
Queue plugin(s)
agent (s)
account cont ainer object libvirt, XenAPI, et c. volume
provider cinder
(iSC et c)
SI, dat abase
glance nova Queue
dat abase dat abase
hyper visor
account cont ainer object AMQP quant um
net wor k
D B D B st ore dat abase
cinder-scheduler provider
nova-conduct or
OpenS ack O
t bject S ore
t
nova-consoleauth
nova-scheduler OpenStack
OpenStack OpenStack Identity
OpenS ack
t Identity Identity OpenS ack
t AP I O penS ack
t
AP I
Image Ser vice AP I OpenS ack C
t omput e Block S orage
t Net wor k Ser vice
http://www.solinea.com
OpenStack
Identity API OpenStack
Identity
AP I
keyst one
OpenStack
(ser vice & admin APIs) Identity
AP I
O penStack t oken backend cat alog
backend
policy
backend
ident it y
backend
5
Identity
Service

6. Identity (“Keystone”)
 Keystone provides a single point
of integration for OpenStack
policy, catalog, token and
authentication.
 keystone handles API requests as
well as providing configurable keyst one
(ser vice & admin APIs)
catalog, policy, token and
identity services.
 Standard backends include
LDAP or SQL, as well as Key Value O penStack t oken backend cat alog
backend
policy
backend
ident it y
backend
Stores (KVS). Identity
Service
 Most people will use this as a
point of customization for their
current authentication services.
6

7. Dashboard (“Horizon”)
 Django application that
users can access in their
web browser
H (S)
TTP OpenStack
 Communicates with each Dashboard
OpenStack service through
their API (and sometimes
their admin API) Hor izon
7

8. 8

9. Object Storage (“Swift”)
 Stores and serves objects
(files)
swif t-proxy
 Employs object level
replication to safeguard data
memcached
 Accepts client requests via
Objectstore API or HTTP from
account cont ainer object
clients through swift-proxy
 Maintains distributed account
and container databases
account cont ainer object
 Stores objects according the
D B D B st ore ring layout on filesystem with
extended attributes (XFS,
OpenS ack O
t bject S ore
t EXT4, etc.)
9

10. Image Service (“Glance”)
 glance-api accepts Image API
calls for image discovery, image glance-api
retrieval and image storage.
 glance-registry stores,
processes and retrieves glance-regist r y
metadata about images (size,
type, etc.). glance
 Database to store the image
dat abase
metadata.
 A storage repository for the
actual image files. In many
deployments, this is OpenStack
Swift OpenS ack
t
Image Ser vice
10

11. Compute (“Nova”)
 nova-api accepts and responds to
nova-api
(O E 2, Admin)
S, C
end user compute API calls.
nova-console
 Supports OpenStack Compute API,
Amazon's EC2 API and a special
nova-comput e nova-cert/
objectstore
Admin API (for privileged users to
perform administrative actions).
 Initiates most of the orchestration
activities (such as running an
libvirt, XenAPI, et c.
instance)
nova Queue
dat abase
hyper visor
 Enforces some policy (mostly quota
checks)
Authentication is handled through
nova-conduct or

nova-consoleauth
middleware before getting to this
nova-scheduler daemon
OpenS ack C
t omput e
11

12. Nova Compute
 The nova-compute process is
nova-api primarily a worker daemon that
creates and terminates virtual
(O E 2, Admin)
S, C nova-console
machine instances via hypervisor's
nova-comput e nova-cert/ APIs (XenAPI for XenServer/XCP,
objectstore
libvirt for KVM or QEMU, VMwareAPI
for VMware, etc.).
libvirt, XenAPI, et c.
 The process by which it does so is
nova Queue
fairly complex but the basics are
simple: accept actions from the
dat abase
hyper visor
queue and then perform a series of
nova-conduct or system commands (like launching
a KVM instance) to carry them out
while updating state in the
nova-consoleauth
nova-scheduler
database.
OpenS ack C
t omput e
12

13. Nova Scheduler
 The nova-schedule process is conceptually the simplest piece of
code in OpenStack Nova: take a virtual machine instance request
from the queue and determines where it should run (specifically,
which compute server host it should run on).
def _schedule(self, context, topic, request_spec, filter_properties):
"""Picks a host that is up at random."""
elevated = context.elevated()
hosts = self.hosts_up(elevated, topic)
if not hosts:
msg = _("Is the appropriate service running?")
raise exception.NoValidHost(reason=msg)
hosts = self._filter_hosts(request_spec, hosts, filter_properties)
if not hosts:
msg = _("Could not find another compute")
raise exception.NoValidHost(reason=msg)
return hosts[int(random.random() * len(hosts))] 13

14. Block Storage (“Cinder”)
 cinder-api accepts API requests and routes
them to cinder-volume for action. cinder-api
 cinder-volume acts upon the requests by
reading or writing to the Cinder database
to maintain state, interacting with other cinder-volume
processes (like cinder-scheduler) through a
message queue and directly upon block
storage providing hardware or software. It volume provider cinder
dat abase
can interact with a variety of storage
providers through a driver architecture.
Currently, there are drivers for IBM, SolidFire, cinder-scheduler
NetApp, Nexenta, Zadara, linux iSCSI and
other storage providers.
 Much like nova-scheduler, the cinder-
scheduler daemon picks the optimal block OpenS ack
t
storage provider node to create the Block St orage
volume on.
14

15. Networking (“Quantum”)
 quantum-server accepts API requests
quant um-ser ver and then routes them to the
appropriate quantum plugin for action.
 Quantum ships with plugins and agents
for:
quant um Queue
quant um – Cisco virtual and physical switches
plugin(s)
– Nicira NVP product
agent (s)
– NEC OpenFlow products
– Open vSwitch
net wor k
provider
quant um
dat abase – Linux bridging
– Ryu Network Operating System
– Midokua
 The common agents are L3 (layer 3),
O penS ack
t DHCP (dynamic host IP addressing) and
the specific plug-in agent.
Net wor k Ser vice
15

16. Future Projects (Havana Release)
 Ceilometer is a metering  Heat provides a REST API to
project. The project offers orchestrate multiple cloud
metering. Metering lets you applications implementing
know what actions have standards such as AWS
taken place, rating enables CloudFormation.
pricing and line items, and
billing gathers the line items
to create a bill to send to
the consumer and collect
payment.
16

17. Accelerating the adoption of Cloud Computing
Ken Pepple
ken@solinea.com
http://www.solinea.com