Best Practices and Considerations Deploying OpenStack In Production

Agenda

Introduction To OpenStack
OpenStack Architecture
Best Practices and Considerations In Production
- Topology
- High Availability
- Compute
- Storage
- Networking

OpenStack Best Practices and Considerations – terasky tech day from Arthur Berezin

Transcript

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