Arthur Berezin,
Sr. Technical Product Manager,
Red Hat
OpenStack In The Enterprise
Best practices for deploying enterprise-grade
OpenStack implementations
TeraSky Tech Day
24/3/2015

● Introduction to OpenStack
● OpenStack Architecture
● Best Practices and Considerations for Production
environments:
- Layout
- High Availability
- Compute
- Storage
- Network
Agenda

Why does the world need OpenStack?

Why does the world need OpenStack?
● Cloud is widely seen as the next-generation IT model
○ Agile and flexible
○ On demand consumption
○ Self service
● Applications are being written differently
○ More tolerant of a failure
○ Making use of scale-out architecture
● Not all organizations are ready for public clouds

What is OpenStack?
● Fully open-source cloud “operating system”
● Comprised of several open source sub-projects
● Provides building blocks to create an IaaS cloud
● Governed by the vendor agnostic OpenStack Foundation
● Enormous market momentum

How does OpenStack fit in?
● A cloud-like IaaS platform
○ Internal private cloud
○ Test and Dev environments
○ Cloud Service Provider for compute, storage, and network
● Scale-out platform for cloud-enabled workloads
○ Web-scale applications (e.g., NetFlix)
○ Academic, research or pharma workloads
● Platform of choice for Network Functions Virtualization (NFV)

OpenStack
Architecture

OpenStack Architecture
● Made up of individual autonomous components
● A framework, relies on drivers and plugins
● Heavily dependant on Linux

OpenStack Identity (Keystone)
● Common authentication and authorization store
● Responsible for users and to which projects they belong to
● All OpenStack services rely on Keystone to verify user requests

OpenStack Compute (Nova)
● Responsible for the lifecycle of running instances
● Manages multiple hypervisor types via drivers
○ e.g., Red Hat Enterprise Linux with KVM

OpenStack Image (Glance)
● Storage and retrieval of disk images/templates
● Supports a large variety of image formats (e.g., qcow2, vmdk)
● Different backend storage options (e.g., NFS, Ceph)

OpenStack Object Store (Swift)
● Storage and retrieval of arbitrary unstructured data
● Provides object based interface via REST API
● Replication, self-healing and load-balancing

OpenStack Networking (Neutron)
● Everything networking to instances running within OpenStack
● API for defining, configuring, and using networks
● Relies on a plugin/driver architecture for implementation

OpenStack Volume (Cinder)
● Block storage to instances running within OpenStack
● Used for providing persistent and/or additional storage
● Relies on a plugin/driver architecture for implementation

OpenStack Orchestration (Heat)
● Facilitates the creation of ‘application stacks’
● Stacks are imported as descriptive template language
● Allows for dynamic scaling based on configurable metrics

OpenStack Telemetry (Ceilometer)
● Central collection of metering and monitoring data
● Consume data from the other components
● Primarily used for chargeback of resource usage

OpenStack Dashboard (Horizon)
● OpenStack’s web-based self service portal
● Sits on top of all other components via API interaction
● Provides a subset of underlying functionality

Best Practices
and Considerations

Disclaimer
OpenStack is an Engine,
You build the car based on needs.
Lego, if you’re not a car person

Layout
High Availability
Compute
Storage
Networking

Layout
OpenStack Architecture:
● OpenStack services are implemented
via several stateless Linux services
● Messaging bus(RabbitMQ) for service
intercommunication
● Database for persistent Data

Layout
Cinder Services:
Cinder-API
Cinder-Scheduler
Cinder-Volume
Cinder-backup

Layout
● This design allows building custom layouts
● Separating or Segregating
○ Controller Node
○ API/Horizon Dashboard
○ Networking Control Plane
○ Cinder and Glance Storage
● Co-locating Ceph OSD with nova-compute
○ Is this a good idea? Depends on workloads

Layout
API/ Horizon
Dashboard
Glance
Cinder
Nova-Compute
Database
MQ Messaging Nova-Compute
Nova-Compute
StorageInternet
API
Storage
Tenant
Internet
Service Internal
Neutron
Networking

Layout
High Availability
Compute
Storage
Networking

High Availability Architecture
● 3 Controllers

High Availability Architecture
● 3 Controllers
● Database
○ Galera Multi-Master
replication
○ MariaDB A/P Cluster
● Message Bus
○ RabbitMQ Mirrored
Queues

High Availability Architecture
Cinder Service
Architecture:
● Cinder-API
● Cinder-Scheduler
● Cinder-Volume
● Cinder-backup

High Availability Architecture
● LoadBalance
Incoming Traffic
With HAProxy
● Clustered
Services With
Pacemaker
● Some services
are still A/P(cinder-volume)
● Other implement A/A HA
Internally(Neutron VRRP, DVR)

Layout
High Availability
Compute
Storage
Networking

Compute
● Backend Virtualization Driver Choice
○ KVM
○ VMWare (Limited to NSX)
○ Others (HyperV, Xen)
● Ephemeral Disks
○ Local or Shared
○ Live Migration
● Co-Locating Ceph OSD with nova-compute

Compute
● Overcommitting CPU / Memory
○ Default CPU overcommit ratio - 16
○ Default memory overcommit ratio - 1.5
● Docker Docker Docker
○ Can live within VM Instances
○ nova-docker driver is still out-of-tree in Kilo release
○ Project Magnum was just introduced
■ Docker and Kubernetes -aaS

Layout
High Availability
Compute
Storage
Networking

Storage
Glance
● Backends:
● Local, NFS, Ceph RBD, Swift
● Glance Supports Multiple backends
● Stick to those that you already know
● Use Image Caching

Cinder
● Backends:
○ Local LVM with iscsi, but no High Availability
○ Ceph RADOS Block Device
○ NetApp, EMC, SolidFire and many others
● Cinder Supports Multiple backends
● Periodic Cinder snapshots
● Optionally Boot from Cinder Volumes
Storage

Layout
High Availability
Compute
Storage
Networking

Networking
● Various design choices:
○ Neutron or nova-network
○ Provider network or Tenant network
○ Overlays(VXLAN, GRE) or VLANs
○ SDN, dedicated network controller
○ Open source or commercial solution

Networking
● A lot of FUD out there...
● But also some great innovation, especially in
open source communities
● Define your business needs
● Analyze your application requirements
○ East/west vs south/north traffic
● Plan for future growth

Networking Neutron plugins
● Default ML2/Open vSwitch
● Other open source solutions
○ e.g., OpenContrail, OpenDaylight, MidoNet
● Commercial hardware agnostic
○ e.g., PLUMgrid, NSX
● Commercial hardware specific
○ e.g., Nuage, Cisco ACI
Try the Default
First

Thank you