- Arthur Berezin presented on best practices for deploying enterprise-grade OpenStack implementations. The presentation covered OpenStack architecture, layout considerations including high availability, and best practices for compute, storage, and networking deployments. It provided guidance on choosing backend drivers, overcommitting resources, and networking designs.

1. 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

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

3. Why does the world need OpenStack?

4. 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

5. 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

6. 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)

7. OpenStack
Architecture

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

9. 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

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

11. 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)

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

13. 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

14. 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

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

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

17. 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

18. Best Practices
and Considerations

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

20. Layout
High Availability
Compute
Storage
Networking

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

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

23. 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

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

25. Layout
High Availability
Compute
Storage
Networking

26. High Availability Architecture
● 3 Controllers

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

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

29. 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)

30. Layout
High Availability
Compute
Storage
Networking

31. 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

32. 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

33. Layout
High Availability
Compute
Storage
Networking

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

35. 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

36. Layout
High Availability
Compute
Storage
Networking

37. 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

38. 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

39. 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

40. Thank you