2. What is OpenStack?
●
●
●
●
Fully open source cloud “operating system”
Provides all of the tools/building blocks required to build a
cloud environment from scratch - mimics public clouds
Started by NASA and Rackspace but now has an
independent foundation in which key industry members are
present, including Red Hat
Enormous market hype with investment from all major
players, e.g. HP, Dell, IBM... and with 1000's of developers
worldwide
4. Why does the world need OpenStack?
●
Cloud is widely seen as the next-generation IT delivery model
●
●
Utility-based on-demand consumption
●
●
Agile & flexible
Self-service drives down overhead and maintenance
Public clouds setting the benchmark, organisations want the same level of
functionality but behind the firewall
●
●
Not all organisations are ready for public cloud
Applications are being built differently today●
●
●
More tolerant of failure
Make use of scale-out elastic architectures
OpenStack enables organisations to achieve this, today... and without
lock-in.
5. Why should I care?
●
Servers fail - Deal with it!
●
If you were to build an environment from scratch●
●
Build with 10,000 machines
●
●
Start with extremely reliable (30year MTBF) servers
You'll watch one fail every day!
We need a new type of application to cope
●
Fault-tolerant software is inevitable
●
Change to scale-out rather than scale-up!
6. A different kind of architecture...
TRADITIONAL WORKLOADS
●
●
●
●
●
Stateful virtual machines
Big VMs: vCPU, vRAM, local storage
inside VM
Application SLA aligned to VM itself
Relies on underlying HA technology to
meet SLA goals
CLOUD WORKLOADS
●
●
●
●
VMs scale up: add vCPU, vRAM, etc.
●
●
Applications not designed to tolerate
failure of VMs
●
Stateless VMs, application distributed
Small VMs: vCPU, vRAM, storage
separate
Application SLA not dependent on any
one VM
Many instances can provide application
availability
Applications scale out: add more VMs
Applications designed to tolerate
failure of VMs
8. Where does OpenStack fit in?
OpenStack provides an elastic
cloud platform for these new
workloads
9. Typical OpenStack Use Cases
●
Service provider offering
●
●
Re-sell compute, networking and storage resources as a new
cloud provider to other organisations
Internal cloud offering
●
●
●
“Infrastructure-on-demand” service for internal customers
Test & Development Environments
Large-scale web applications or content farms
●
Dynamically scale based on load
●
e.g. Netflix, PayPal, eBay
11. OpenStack Release History
●
July 2010 - Initial announcement
●
October 2010 - Austin Release
●
February 2011 - Bexar Release
●
April 2011 - Cactus Release
●
October 2011 - Diablo Release
●
April 2012 - Essex Release
●
October 2012 - Folsom Release
●
April 2013 - Grizzly Release
●
October 2013 - Havana Release
●
April 2014 – Icehouse Release
12. OpenStack Contribution
Leading Contributor to Grizzly and Havana Releases
●
Leading in commits and line counts across all projects
●
Note: Not including OpenStack dependencies, Linux, KVM, libvirt, etc
●
Figures below are for Grizzly.
http://bitergia.com/public/reports/openstack/2013_04_grizzly/
12
13. OpenStack Progression
●
●
●
●
●
●
Open source, communitydeveloped (upstream)
software
Founded by Rackspace
Hosting and NASA
●
●
●
Managed by the OpenStack
Foundation
Vibrant group of developers
collaborating on open source
cloud infrastructure
Software distributed under
the Apache 2.0 license
No certifications, no support
●
●
●
●
Latest OpenStack software,
packaged in a managed
open source community
●
●
Facilitated by Red Hat
Aimed at architects and
developers who want to
create, test, collaborate
●
Freely available, not for sale
●
Six-month release cadence
mirroring community
●
No certification, no support
Installs on Red Hat and
derivatives
●
●
Enterprise-hardened
OpenStack software
Delivered with an
enterprise life cycle
Six-month release cadence
offset from community
releases to allow testing
Aimed at long-term
production deployments
Certified hardware and
software through the Red
Hat OpenStack Cloud
Infrastructure Partner
Network
Supported by Red Hat
Installs on Red Hat
Enterprise Linux only
15. Red Hat OpenStack Offering
Red Hat will include the following in its Red Hat OpenStack distribution
●
●
All core OpenStack Havana packages including Neutron
Support for Open vSwitch via userspace tools in Red Hat OpenStack +
kernel support in RHEL 6.5
●
●
A multi-node installer for for both small and large deployments
●
Reference architectures for large scale deployments
●
15
Puppet modules for installing all services for OpenStack
Bug-fixes and features selectively back-ported from Icehouse
16. Release Cadence
●
Upstream OpenStack.org
●
●
Releases every 6 months
●
2 to 3 'snapshots' including bug fixes
●
●
Source code only
No more fixes/snapshots after next release
Upstream RDO
●
●
16
Follows upstream cadence
Delivers 'binaries' in yum/rpm format for RHEL,
Fedora, etc.
17. Release Cadence
●
Red Hat OpenStack
●
6 month release cycle
●
Roughly 2 months AFTER upstream
●
●
Time to stabilize, certify, back-port etc.
Initially 1 year lifecycle
●
●
●
Support for Folsom ends after Havana release
Support for Grizzly ends after Icehouse release
Will increase lifecycle over time
●
17
Based on upstream stability and customer requirements
20. OpenStack Keystone
●
Keystone provides a common authentication and authorisation store for OpenStack
●
Users, their roles and the tenant (project) they belong to
●
Authentication is based on tokens
●
24-hour expiry by default
●
Easily revoked if compromised
●
Each OpenStack component uses Keystone to verify a users token
●
It also provides a catalogue of all other OpenStack services
21. OpenStack Nova
●
Core responsibility is to schedule and manage instances (think Amazon EC2)
●
Supports multiple hypervisors (list below is upstream only, not necessarily Red Hat Supported)
●
●
Xen
●
KVM
●
●
VMware ESX (either direct to ESX or via vCenter)
Microsoft Hyper-V
Exposes an OpenStack API but also an EC2 compatible API
22. OpenStack Glance
●
Mechanism for storing and retrieving disk images
●
Supports many standard image types
●
●
raw, qcow2, vmdk, vhd, iso, ami/aki, ovf
With various storage options for the images
●
Filesystem (Default)
●
Swift (OpenStack Object Storage)
●
S3 (Amazon's Simple Storage Service)
23. OpenStack Swift
●
Mechanism for storing and retrieving arbitrary unstructured data (as objects)
●
Entirely REST-ful HTTP API based, similar to Amazon S3
●
Highly fault tolerant
●
●
Self-healing architecture
●
Load-balancing with built-in proxy servers
●
●
Data replication (including geographically)
No single point of failure
Doesn't require any specific hardware, purely scale-out.
24. OpenStack Neutron
●
OpenStack's Networking-as-a-Service Component
●
Implements Software Defined Networking (SDN)
●
Rich plugin architecture which allows Neutron to abstract the underlying technology
implementation away. Examples of upstream support include●
Cisco UCS
●
VMware Nicira
●
Open vSwitch (Default in RHEL OSP)
25. OpenStack Cinder
●
Provides block storage for runtime of instances
●
Can be used for persistent or tiered storage
●
Enables ability to do live migration of instances
●
Similar to Amazon Elastic Block Storage (EBS)
●
Support for many storage vendors platforms for offload
●
Default implementation exposes LVM's over iSCSI
26. OpenStack Heat
●
Facilitates the deployment of 'Application Stacks' and all required dependencies
●
Allows portability of applications between clouds in a predictable fashion
●
Based on templates written in YAML
●
Provides basic high availability and scalability via OpenStack Ceilometer
●
Designed after (and compatible with) Amazon's CloudFormations
●
Integrated into the OpenStack Dashboard (Horizon)
27. OpenStack Ceilometer
●
Central collection of metering and monitoring data – ultimate goal = billing/chargeback
●
Allows identification of bottlenecks and capacity planning
●
Based on both agents and message bus listening for statistics
●
Exposes an API for consumption of metering data
●
Completely extensible – you choose what you want to meter, e.g. CPU time, bandwidth usage
28. OpenStack Horizon
●
Self-service portal exposing end-user OpenStack functionality
●
Web-based interface that utilises underlying API's
●
Permits the creation and life-cycle management of
●
●
Images
●
Volumes
●
●
Instances (including snapshots)
Networks
Has different views depending on whether the user is an administrator or not.
30. Common OpenStack Architecture
●
All data is held in a SQL database
●
●
●
Can be made highly-available if replicated
Default is MySQL, but others are supported
Components have two sub-component types:
●
●
●
API Endpoints – The RESTful entry-point into the component
One or more 'daemons' – The services that carry out instructions
Vast majority of OpenStack is shared-nothing and very fault-tolerant
●
Components scale out using shared message bus (qpid, RabbitMQ etc)
●
API Endpoints can be load-balanced (virtual IP's) for resilience/throughput
●
High level of service location flexibility
32. OpenStack “Global” Deployment
●
Keystone Regions
●
Used by Keystone to segregate complete environments,
●
e.g. deployment in New York vs. London
●
●
●
Completely separate nova, cinder, quantum, glance etc
Single Keystone instance
Availability Zones
●
●
●
Used by Nova to isolate groups of compute-hosts within an environment, users
can deploy to a particular zone
Typically used for tiered systems or for ensuring availability
Nova Cells
●
Increases scalability by creating smaller Nova clusters
●
Each with their own database and message queue but single Nova API
●
Are scheduled just like a host would be