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

 

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

Share If You Care

2 Trackbacks & Pingbacks

  1. OpenStack Community Weekly Newsletter (Mar 27 – Apr 3) | The OpenStack Blog
  2. OpenStack Community Weekly Newsletter (Mar 27 – Apr 3) - GREENSTACK

What do you think about this?