OpenStack Best Practices and Considerations - terasky tech day

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