1

OpenStack IaaS

Bart van den HeuvelEMEA Forward Deployed Engineer - OpenStack

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

OpenStack Organisation

Why does the world need OpenStack?

● Cloud is widely seen as the next-generation IT delivery model

● Agile & flexible ● Utility-based on-demand consumption● 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.

Why should I care?

● Servers fail - Deal with it!

● If you were to build an environment from scratch-● Start with extremely reliable (30year MTBF) servers● Build with 10,000 machines● 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!

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

● VMs scale up: add vCPU, vRAM, etc.

● Applications not designed to tolerate failure of VMs

CLOUD WORKLOADS

● 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

Where does OpenStack fit in?

Where does OpenStack fit in?

OpenStack provides an elastic cloud platform for these new

workloads

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

OpenStack is not a replacement for enterprise virtualisation

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

http://bitergia.com/public/reports/openstack/2013_04_grizzly/

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.

OpenStack Progression

● 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

● 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

● Open source, community-developed (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

Community → Enterprise

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

● Puppet modules for installing all services for OpenStack

● A multi-node installer for for both small and large deployments

● Reference architectures for large scale deployments

● Bug-fixes and features selectively back-ported from Icehouse

16

Release Cadence

● Upstream OpenStack.org● Source code only● Releases every 6 months● 2 to 3 'snapshots' including bug fixes● No more fixes/snapshots after next release

● Upstream RDO● 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● Based on upstream stability and customer requirements

OpenStack Architecture

OpenStack Components

● Modular architecture

● Vast scale-out design

● Based on a (growing) set of core-components

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

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)

● VMware ESX (either direct to ESX or via vCenter)

● Xen

● KVM

● Microsoft Hyper-V

● Exposes an OpenStack API but also an EC2 compatible API

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)

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

● Data replication (including geographically)

● Self-healing architecture

● Load-balancing with built-in proxy servers

● No single point of failure

● Doesn't require any specific hardware, purely scale-out.

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)

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

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)

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

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

● Instances (including snapshots)

● Images

● Volumes

● Networks

● Has different views depending on whether the user is an administrator or not.

OpenStack Horizon - Screenshot

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

Typical Deployment

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

Demo