OpenStack Best Practices and Considerations - terasky tech day
33 likes14,459 views
- 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.
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)
- 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
- 19. Disclaimer OpenStack is an Engine, You build the car based on needs. Lego, if you’re not a car person
- 21. Layout OpenStack Architecture: ● OpenStack services are implemented via several stateless Linux services ● Messaging bus(RabbitMQ) for service intercommunication ● Database for persistent Data
- 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
- 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)
- 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
- 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
- 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