Post on 07-May-2018
OpenStack: The Mission
"To produce the ubiquitous Open Source cloud computing platform that will meet the needs of public and private cloud providers regardless of size, by being simple to implement and massively
scalable."
OpenStack Founding Principles
l Apache 2.0 license (OSI), open development processl Open design process, 2x year public Design Summitsl Publicly available open source code repositoryl Open community processes documented and transparentl Commitment to drive and adopt open standardsl Modular design for deployment flexibility via APIs
Software to provision virtual machines on standard hardware at massive scale
Software to reliably store billions of objects distributed across standard hardware
OpenStack Compute
OpenStack Object Storage
creating open source software to build public and private clouds
OpenStack Release Schedule
Diablo:September 22
Cactus: April 15, 2011
Bexar:February 3, 2011
l OpenStack Compute ready for enterprise private cloud deployments and mid-size service provider deployments
l Enhanced documentationl Easier to install and deploy
l Followed by conference and design summit in Boston in early October
l OpenStack Compute ready for large service provider scale deployments
l This is the ‘Rackspace-ready’ release; need to communicate Rackspace support and plans for deployment
Asynchronous eventually consistent
communication
ReST-based API
Horizontally and massively scalable
Hypervisor agnostic: support for Xen ,XenServer, Hyper-V,
KVM, UML and ESX is coming Hardware agnostic: standard hardware, RAID not required
OpenStack Compute Key Features
Server GroupsDual Quad CoreRAID 10 Drives1 GigE Public1 GigE Private1 GigE Management
Public Network
Private Network(intra data center)
Management
Example OpenStack Compute Hardware
(other models possible)
API: Receives HTTP requests, converts commands to/from API format, and sends requests to cloud controller
Cloud Controllers: Global state of system, talks to LDAP, OpenStack Object Storage, and compute/storage/network workers through a queue
User Manager
ATAoE / iSCSI
Host Machines: workers that spawn instances
Glance: HTTP + OpenStack Object Storage for server imagesOpenStack Compute
System Componentsl API Server: Interface module for command and control requestsl Designed to be modular to support multiple APIsl In current release: OpenStack API, EC2 Compatibility Modulel Approved blueprint: Open Cloud Computing Interface (OCCI)l Message Queue: Broker to handle interactions between servicesl Currently based on RabbitMQl Metadata Storage: ORM Layer using SQLAlchemy for datastore
abstractionl In current release: MySQLl In Diablo: PostgreSQLl User Manager: Directory service to store user identitiesl In current release: OpenLDAP, FakeLDAP (with Redis), Databasel Scheduler: Determines the placement of a new resource requested
via the APIl Modular architecture to allow for optimizationl Base schedulers included in Bexar: Round-robin, Least busy
System Components (Cont.)
l Compute Worker: Manage compute hosts through commands received on the Message Queue via the API
l Base features: Run, Terminate, Reboot, Attach/Detach Volume, Get Console Output
l Network Controller: Manage networking resources on compute hosts through commands received on the Message Queue via the API
l Support for multiple network modelsl Fixed (Static) IP addresses, VLAN with NAT, DHCPl Volume Worker: Interact with iSCSI Targets to manage volumesl Base features: Create, Delete, Establishl Image Store: Manage and deploy VM images to host machines
New Features in Diablo and Beyondl Quantum: Networking as a Servicel Developed in the open by Cisco, Nicira, othersl Burrow: HTTP-based message queuel Red Dwarf: Database as a Servicel Keystone: Integrated, pluggable auth for all OpenStack componentsl Lunr: Volumes as a Servicel Dashboard: Control nova and other OpenStack components via web
5 Zones2 Proxies per 25Storage Nodes10 GigE to Proxies1 GigE to Storage Nodes24 x 2TB Drives
per Storage Node
To Load Balancers
Proxies
Example Large Scale Deployment -- Many Configs Possible
Example OpenStack Object Storage Hardware
ReST-based API Data distributed evenly throughout system
Hardware agnostic: standard hardware, RAID not required
Object Storage Key Features
No centraldatabase
Scalable to multiple petabytes, billions of objects
Account/Container/Object structure (not file system, no nesting) plus Replication (N copies of accounts, containers, objects)
System Components
l The Ring: Mapping of names to entities (accounts, containers, objects) on disk.
l Stores data based on zones, devices, partitions, and replicasl Weights can be used to balance the distribution of partitionsl Used by the Proxy Server for many background processesl Proxy Server: Request routing, exposes the public APIl Replication: Keep the system consistent, handle failuresl Updaters: Process failed or queued updatesl Auditors: Verify integrity of objects, containers, and accounts
System Components (Cont.)
l Account Server: Handles listing of containers, stores as SQLite DBl Container Server: Handles listing of objects, stores as SQLite DBl Object Server: Blob storage server, metadata kept in xattrs, data in
binary formatl Recommended to run on XFSl Object location based on hash of name & timestamp
Evolution of Object Storage ArchitectureVersion 1: Central DB
(Rackspace Cloud Files 2008)Version 2: Fully Distributed
(OpenStack Object Storage 2010)
lIRC (freenode)l #openstackl #openstack-devl #openstack-meetingl #lunr
lDocslhttp://wiki.openstack.orglhttp://docs.openstack.orglhttp://swift.openstack.orglhttp://nova.openstack.org
lTwitterl@openstack
OpenStack Community