Introduction to OpenStack Architecture (Grizzly Edition)


Published on

Presentation from OpenStack Summit in April 2013.

Building upon his popular blog posts and diagrams (, 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.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Introduction to OpenStack Architecture (Grizzly Edition)

  1. 1. Introduction toOpenStack Architecture Grizzly Edition
  2. 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. 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 3 Identity
  4. 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. 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 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. 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. 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. 8
  9. 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. 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. 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, Amazons 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. 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 hypervisors 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. 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. 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. 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. 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. 17. Accelerating the adoption of Cloud Computing Ken Pepple