Your SlideShare is downloading. ×
Introduction to OpenStack Architecture
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Introduction to OpenStack Architecture

7,033
views

Published on

Published in: Technology, News & Politics

0 Comments
12 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
7,033
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
810
Comments
0
Likes
12
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Introduction toOpenStack 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, 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. 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. 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