Red Hat OpenStack - Open Cloud Infrastructure

RED HAT OPENSTACK | 2013DOC144908-20130524r3
OPEN CLOUD INFRASTRUCTURE
BUILT ON RED HAT TECHNOLOGIES
Alex Barreto
Cloud Domain Architect

AGENDA
● Market dynamics
● What is Red Hat OpenStack?
● Red Hat in the OpenStack community
● OpenStack Components
● New in Grizzly release
● Red Hat's upstream focus
● RDO: Community OpenStack from Red Hat
● How OpenStack is released
● Red Hat OpenStack brings Red Hat value to OpenStack
● What's next in OpenStack and Red Hat OpenStack
● Questions

I.T. NEEDS ARE SHIFTING
VIRTUALIZATION
INFRASTRUCTURES
● Greater server utilization
● Less server sprawl
● Minimize space & power
● Higher staff productivity
● Business continuity
● Fault tolerance and HA
● Extended service levels
● Lifecycle management
● CapEx budgeting
PRIVATE & HYBRID CLOUD
INFRASTRUCTURES
● Self service
● Automated provisioning
● Charge-back and quotas
● Workload portability
● Disposable resources
● Heterogeneous management
● OpEx budgeting

WORKLOADS ARE EVOLVING
TRADITIONAL
WORKLOADS
● Stateful VMs, application = VM
● Big VMs: vCPU, vRAM, storage inside
VM
● Application SLA = SLA of VM
● SLA requires enterprise virtualization
features to keep VMs highly available
● Lifecycle measured in years
● VMs scale up: add vCPU, vRAM, etc.
● Applications not designed to tolerate
failure of VMs
CLOUD
WORKLOADS
● Stateless VMs
● Small VMs: vCPU, vRAM, storage separate
● Application SLA <> SLA of any one VM
● SLA requires ability to create and destroy
VMs where needed
● Lifecycle measured in hours to months
● Applications scale out: add more VMs
● Applications tolerate failure of VMs

BUSINESS PAINS DEMAND NEW MODELS
PROPRIETARY
ARCHITECTURES
● High up-front costs, amortized ROI
● Enterprise agreements, inflexible terms
● Proprietary stacks with lock-in
● Single-vendor commitment
● High utilization of existing resources
CLOUD
ARCHITECTURES
● Based on open source, low up front costs
● Pay-as-you-go, metering and chargeback
● Heterogeneous architecture
● Multiple vendors, best of breed
● Grow and shrink resources according to
demand, SLA, cost

RED HAT LEADS THROUGH OPEN INNOVATION

RED HAT OPENSTACK
CLOUD INFRASTRUCTURE FOR
CLOUD-ENABLED WORKLOADS
● Modular architecture
● Designed to easily scale out
● Based on (growing) set of core services

LOCK-IN IS A MAJOR CONCERN
●
Lock-in is a real risk for IT
organizations moving to cloud
●
Fear of lock-in is driving strong interest
in open cloud technologies and
platforms
●
Greatest innovation is occurring in
open source cloud projects – not
proprietary, closed solutions
●
Cloud architecture decisions can
dramatically limit ROI and flexibility
Most hybrid cloud computing
technologies and services seek to
lock in customers to their respective
technologies and services, as there
are no industry standardized
approaches.
GARTNER
Risks of platform lock-in exist at
every tier of the cloud.
-Thomas Bittman, GARTNER

Austin – October 2010
- Initial release
- Object Storage production ready
- Compute in testing
Bexar – February 2011
- Compute production ready
- Initial release of Image Service
- Focus on installation and deployment
Cactus – April 2011
- Focus on scaling enhancement
- Support for KVM/QEMU, XenServer, Xen, ESXi, LXC
Diablo – September 2011
- First “production ready”
release
Essex – April 2012
- Dashboard and Identity added to core
- Quantum incubated
Folsom – October 2012
- Quantum added to core
- Cinder added to core Grizzly – April 2013
- Ceilometer and Heat incubated
- Focus on upgrade support
Havana – October 2013

RED HAT OPENSTACK TIMELINE

#3
OVERALL CODE
CONTRIBUTOR TO
ESSEX
(Apr 2012)

#2
OVERALL CODE
CONTRIBUTOR TO
FOLSOM
(Oct 2012)

#1
OVERALL CODE
CONTRIBUTOR TO
GRIZZLY
(Apr 2013)

1 OF 8
PLATINUM MEMBER OF
OPENSTACK FOUNDATION

RED HAT'S OPENSTACK LEADERSHIP

WHY ARE WE INVOLVED WITH OPENSTACK?
● Red Hat OpenStack will be to OpenStack what
Red Hat Enterprise Linux is to Linux
● We bring what OpenStack needs
● Supportability
● Stability
● Enterprise grade features (Security, Performance, RAS)
● Certified ecosystem
● Lifecycle
● Killer combination of RHEL, RHEV, and OpenStack

OPENSTACK ARCHITECTURE
● Modular architecture
● Designed to easily scale out
● Based on (growing) set of core services

OPENSTACK CORE PROJECTS
OpenStack Identity (KEYSTONE)
● Identity Service
● Common authorization framework
● Manages users, tenants and roles
● Pluggable backends (SQL, PAM, LDAP, etc)

OpenStack Identity (Keystone)
keystone
Token ServicesToken Identity
ReST API

keystone
...
Load Balancer
keystone keystone
OpenStack Identity (Keystone)
Scaling

OpenStack Compute (NOVA)
● Core compute service comprised of
● Compute Nodes – hypervisors that run virtual machines
● Supports multiple hypervisors KVM, Xen, LXC, Hyper-V and ESX
● Distributed controllers that handle scheduling, API calls, etc
● Native OpenStack API and Amazon EC2 compatible API

OpenStack Compute (Nova)
● Concepts
● Instances / Servers
● Flavors / Instance Types
● Virt drivers
● OpenStack API and EC2 API

OpenStack Compute (Nova)
nova-api
ReST API
AMQP
nova-compute
Libvirt+KVM
DB
nova-scheduler
nova-conductor

nova-api
OpenStack Compute (Nova) Scaling
(Step 1)
AMQP
nova-compute
nova-scheduler
Libvirt+KVM
DB
nova-conductor
nova-scheduler
nova-conductor
nova-scheduler
nova-conductor
Libvirt+KVMLibvirt+KVM
nova-computenova-compute
nova-apinova-api
Load Balancer

(Step 2)
API Cell
Compute Cell Compute Cell Compute Cell
...
AMQP

(Step 2)
AMQP
nova-compute
nova-scheduler
Libvirt+KVM
DB
nova-conductor
nova-scheduler
nova-conductor
nova-scheduler
nova-conductor
Libvirt+KVMLibvirt+KVM
nova-computenova-compute
Compute Cell
nova-cells

(Step 2)
AMQP
DB
API Cell
nova-cells
nova-cellsnova-cellsnova-api
Load Balancer
ReST API

OpenStack Image Service (GLANCE)
● Image service
● Stores and retrieves disk images (virtual machine templates)
● Supports Raw, QCOW, VMDK, VHD, ISO, OVF & AMI/AKI
● Backend storage : Filesystem, Swift, Amazon S3

OpenStack Image Service (Glance)
● Concepts
● Images
● Metadata
● Storage Backends

glance-api
glance-registry
DBImage
Storage
ReST API
ReST

Scaling
glance-api
glance-registry
DBImage
Storage
glance-apiglance-api
...
Load Balancer
* Scales horizontally the
same way as the API

OpenStack Object Storage (SWIFT)
● Object Storage service
● Modeled after Amazon's S3 service
● Provides simple service for storing and retrieving arbitrary data
● Native API and S3 compatible API

OpenStack Object Storage (Swift)
● Concepts
● Accounts
● Containers – Organize Your Data
● Objects – Your Data
● Ring – Internal Data Structure

OpenStack Object Storage (Swift)
Credit: Mark McLoughlin
API
Storage

Proxy Proxy Proxy
...
Load balancer
Storage Storage Storage...
OpenStack Object Storage (Swift) Scaling

OpenStack Networking (formerly QUANTUM, now NEUTRON)
● Network Service
● Provides framework for Software Defined Network (SDN)
● Plugin architecture
● Allows integration of hardware and software based network solutions

OpenStack Networking (...)
● Concepts
● Networks
● Routers
● Subnets
● Ports
● Vendor plugins

OpenStack Networking (...)
#201209
Network Nodes
Database
Compute Nodes
Service Nodes
Networking Service
Networking Plug-in
Message Broker
Nova
Metadata
Service
API
Nova
Compute
L2 - Agent
DHCP - Agent
L3 - Agent
L2 - Agent
Meta Data Proxy

OpenStack Block Storage (CINDER)
● Block Storage (Volume) Service
● Provides block storage for virtual machines (persistent disks)
● Similar to Amazon EBS service
● Plugin architecture for vendor extensions
eg. NetApp driver for Cinder

OpenStack Block Storage (Cinder)
● Concepts
● Volumes
● Snapshots
● Storage Backends

cinder-api
ReST API
AMQP
cinder-volume
cinder-scheduler
DB

cinder-schedulercinder-scheduler
Scaling
cinder-api
AMQP
cinder-volume
cinder-scheduler
cinder-volumecinder-volume
cinder-api cinder-api...
Load Balancer

OpenStack Dashboard (HORIZON)
● Dashboard
● Provides simple self service UI for end-users
● Basic cloud administrator functions
● Define users, tenants and quotas
● No infrastructure management

OpenStack APIs
OpenStack Dashboard (Horizon)
● Python WSGI
Application
● Django framework
● Stateless client of
OpenStack APIs
httpd
horizon

OpenStack APIs
OpenStack Dashboard (Horizon)
Scaling
httpd
horizon
httpd
horizon
httpd
horizon
...
Load Balancer
Session Storage

OPENSTACK INCUBATING PROJECTS
OpenStack Orchestration (HEAT)
● Dashboard

OpenStack APIs
OpenStack Orchestration (Heat)
heat-api
ReST API / CFN API
AMQP
heat-engine
DB

OpenStack APIs
OpenStack Orchestration (Heat)
Scaling
heat-api
AMQP
heat-engine
heat-apiheat-api ...
Load Balancer
heat-engineheat-engine ...

OPENSTACK INCUBATING PROJECTS
OpenStack Monitoring and Metering (CEILOMETER)
● Dashboard

OpenStack Metering (Ceilometer)
● The foundation of billing or charge back
systems
● Concepts
● Meters
● Compute Pollsters
● Central Pollster
● Notifications
● Collectors

Credit: Doug Hellman
http://stevedore.readthedocs.org/en/latest/essays/pycon2013.html#requirements-for-ceilometer

Starting up an OpenStack Instance
● Deep breath!
● Now that we've taken the deep dive, let's step
back out
● Performing operations in compute often
requires interacting with multiple services
● Now will go through an example (multiple
slides), start an instance
●
● Start an instance – auth with keystone, request

Boot a Server – Step 1
Compute
Dashboard
Image
Service
Identity
Object
Storage
MeteringOrchestration
Networking
Block
Storage
1

Compute
Dashboard
Image
Service
Identity
Object
Storage
Networking
Block
Storage
1 2

Compute
Dashboard
Image
Service
Identity
Object
Storage
Networking
Block
Storage
1 2
3

Compute
Dashboard
Image
Service
Identity
Object
Storage
Networking
Block
Storage
1 2
3
4

Compute
Dashboard
Image
Service
Identity
Object
Storage
Networking
Block
Storage
1 2
3
4
5

Compute
Dashboard
Image
Service
Identity
Object
Storage
Networking
Block
Storage
1 2
3
4
5
6

WHAT'S NEW IN GRIZZLY
● OpenStack Compute (NOVA)
● Availability Zones Improvement
● Instance Action Tracking
● Quantum Security Groups
● Default Security Group Rules
● libvirt Custom Hardware
● Basic Spice support
● Glance Direct Image File Copy
● Preallocated Images
● Boot from volume without image
● Cells (Experimental)

● OpenStack Compute (Cinder)
● LVM thin provisioning
● Initial Fibre channel support
● Offline Volume backup to Swift
● Multiple volume backends (on a single node)
● LIO iSCSI target support
● GlusterFS driver
● Volume type scheduler infrastructure
● Metadata for snapshots, update volume and snap metadata

● OpenStack Networking (formerly Quantum, now Neutron)
● Security group API
● API for loading multiple plugins for services
● Support for BigSwitch Plugin
● Service type definitions
● Linux bridge support for security groups
● LBaaS Work
● OVS support for security groups
● Brocade Plugin
● HA and sclable for DHCP and L3 agents

● OpenStack Dashboard (Horizon)
● Improved support for Quantum Networks
● L3 Routers support, Network Topology view,
● 'Direct' image upload to Glance
● Flavor 'extra specs' support for image metadata

RED HAT UPSTREAM FOCUS
● Heavily engaged in community since 2011
● Established leadership position in community
● Both in terms of governance and technology
● Including PTLs on Nova, Keystone, Oslo, Heat and Ceilometer
● Creating and leading stable tree
● 3rd largest contributor to Essex Release
● 2nd largest contributor to Folsom Release
● Largest contributor to Grizzly Release
● Note: These statistics do not include external dependencies
eg. libvirt, kvm, Linux components

http://bitergia.com/public/reports/openstack/2013_04_grizzly/
Leading Contributor to Grizzly Release
● Leading in commits and line counts across all projects

http://bitergia.com/public/reports/openstack/2013_04_grizzly/
Core Projects All Activity

● Why do these statistics matter?
● Proof that Red Hat has the skills and resources to
● Support customers
● Drive new features
● Influence strategy and direction of project
● Important to highlight our leadership in the whole stack
● Linux, KVM, libvirt, etc

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
● Certifed 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 certifcation, 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 certifcations, no support

OPENSTACK RELEASE CADENCE
Folsom
Stable
Branch
Folsom.0
2012.2.0
Folsom.2
Folsom.1
Baseline
drop
Bug fix
merges
Select
backports
RHOS Folsom (2.1)
G
rizzly
Stable
Branch
Grizzly.0
CR Grizzly.2
2013.1.2
CR Grizzly.1
2013.1.1
CR H1
H1
RHOS Grizzly (3.0)
Preview / Beta
CR H1
H1
G
rizzly
Stable
Branch

● Upstream
● Source code Only
● Releases every 6 month
● 2 to 3 'snapshots' including bug fixes
● No more fixes/snapshots after next release
● RDO
● Follows upstream cadence
● Delivers binaries

● Red Hat OpenStack
● 6 Month cadence
● Roughly 2 to 3 months AFTER upstream
● Time to stabilize, certify, backport etc.
● Initially 1 year lifecycle
● e.g., Support for Folsom ends after Havana release
● Support for Grizzly ends after “I” release
● Will increase lifecycle over time
● Likely to move to 2 years after Havana
● Based on upstream stability and resources

RED HAT OPENSTACK VALUE
● Enterprise grade OpenStack deployment with ecosystem, lifecycle,
support that customers expect from Red Hat
● Based on RHEL and includes required fixes in both OpenStack and
RHEL
● Enterprise hardened OpenStack code
● Longer supported lifecycle
● includes bug fixes, security errata, selected backports
● Certified ecosystem (Red Hat Certified OpenStack Partner program and
Red Hat Enterprise Linux ecosystem)
● Full support and Certifications for RHEL and Windows workloads

RED HAT OPENSTACK CLOUD INFRASTRUCTURE
PARTNER NETWORK

CERTIFICATION LEVELS

OPENSTACK: WHAT'S NEXT?
● Upstream focus is on core components
● NOVA, Quantum, etc
● Many companies are productizing on top of the Core
● Adding features to make OpenStack consumable
e.g., Administration, Operations, provisioning,
monitoring, etc
● Typically these don't come back to the core project

● Red Hat is moving the “core” forward
● Features, stability, maturity, supportability
● 3rd
parties are working on Operational aspects
● e.g., How do you provision, configure and administer
● Our current customer base (telcos, OEMS, etc)
have their own infrastructure - will build around RHOS
● Enterprises want a complete product
● Automate & manage deployment, configuration,etc
● In many cases want traditional virtualization features too

Common customer concerns :
● No centralized management or installer
● Limited storage options
● No fiber channel support, no storage migration, backup, DR,etc
● No (or limited) Live Migration
● No workload management (DRS)
● No High Availability
● No monitoring
● No reporting
● Limited configuration options
● Performance concerns

RED HAT OPENSTACK: MOVING FORWARD
● Continued focus on OpenStack core
● Management tools for RHOS
● Deliver in stages
● Tooling for installation and configuration management (Based around
Foreman)
● Centralized Management Platform
● Focus on delivering common infrastructure
● Leverage OpenStack Services within RHEV
● Allow customers to deploy a single platform
● Deploy cloud and traditional workloads
● Provide on-ramp to OpenStack

RED HAT OPENSTACK | 2013

TRADEMARK STATEMENTS
Copyright © 2013 Red Hat, Inc. Red Hat, Red Hat Enterprise Linux, the Shadowman
logo, JBoss, MetaMatrix, and RHCE are trademarks of Red Hat, Inc., registered in the
U.S. and other countries. Linux® is the registered trademark of Linus Torvalds in the U.S.
and other countries.
The OpenStack™ Word Mark and OpenStack Logo are either registered trademarks /
service marks or trademarks / service marks of the OpenStack Foundation, in the United
States and other countries and are used with the OpenStack Foundation's permission.
We are not affiliated with, endorsed or sponsored by the OpenStack Foundation or the
OpenStack community.

THANK YOU

APPENDIX
● EARLY ADOPTER PROGRAM (April 2013)

RHOS-EAP – Purpose & Description
● Purpose: provide our most important customers with coordinated
support for a Red Hat OpenStack proof-of-concept evaluation.
● RHOS Early Adopter is offered in three levels:
● Level 1: Free RHOS subscriptions with self-support and access to a no-SLA
mailing list monitored by RHOS engineering.
● Level 2: (Level 1 plus) standard-level support provided by Red Hat’s award-
winning Global Support Services organization.
● Level 3: (Levels 1 & 2 plus) direct interaction with the Red Hat OpenStack
engineering team as warranted.
● In order to provide the best experience for Early Adopter customers,
the number who can participate at each level is capped. RHOS-EAP
team approval is required.

RHOS-EAP - Qualification
General criteria for approval:
● Customer should be a technology leader in their industry.
● Customer should be willing to be a public or private reference
upon successful completion of the PoC.
● Customer’s timetable should be to deploy a production OpenStack-
based private-cloud by mid-2014.
● Customer should already be testing OpenStack and building out a
dedicated development staff and environment.

RHOS-EAP – Qualification (cont)
● To be eligible for the standard-level support offered at program
levels 2 and 3, the customer must be willing to purchase a 5-day Red
Hat Professional Services engagement or a Cloud TAM.
● We find that most complications occur at the time of initial installation and
configuration. In order to provide the best possible support experience, we
must ensure that RHOS has been installed and configured correctly.
● Option 1 - Customer purchases a 5-day services engagement to accomplish the
installation & configuration.
● Option 2 - Customer purchases a Cloud TAM to oversee and validate the
customer-led installation & configuration.

RHOS-EAP – Post Approval (levels 2 & 3)
● Once approved, the Account and RHOS-EAP teams meet with the customer
to confirm our understanding of their goals and expectations.
● Red Hat Services (or the customer under the direction of their cloud TAM)
then installs and configures Red Hat OpenStack.
● The Account and RHOS-EAP teams meet with the customer to verify that
the installation was completed to standards – and to explain how support
issues will be handled.
● The customer will have the option of bi-weekly checkpoint meetings with
the RHOS-EAP team in order to:
● Provide feedback and discuss issues.
● Update Red Hat on the progress of their PoC and how it is tracking to their
goals and expectations.

RHOS-EAP – Post Approval (level 3)
● The customer will have a dedicated contact for interaction with RHOS
engineering. This contact will help the customer navigate resources needed
for a successful implementation.
● Level 3 of the program will provide additional resources:
● Weekly conference calls to gather feedback, track issues, and synch on activities.
● Dedicated mailing list for exchange with engineering.
● Pointer for download of latest builds & associated software.
● Best practices & documentation for capabilities & features not yet in the standard build.
● Architecture review for more complex configuration.
● Patch / fix review (if applicable).

Red Hat OpenStack - Open Cloud Infrastructure

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Red Hat OpenStack - Open Cloud Infrastructure

Similar to Red Hat OpenStack - Open Cloud Infrastructure (20)

More from Alex Baretto

More from Alex Baretto (6)

Recently uploaded

Recently uploaded (20)

Red Hat OpenStack - Open Cloud Infrastructure