openstack best practices and considerations - terasky tech day
TRANSCRIPT
Arthur Berezin,Sr. Technical Product Manager,Red Hat
OpenStack In The EnterpriseBest practices for deploying enterprise-grade OpenStack implementations
TeraSky Tech Day 24/3/2015
● Introduction to OpenStack● OpenStack Architecture● Best Practices and Considerations for Production
environments:- Layout- High Availability- Compute- Storage- Network
Agenda
Why does the world need OpenStack?
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
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
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)
OpenStack Architecture
OpenStack Architecture
● Made up of individual autonomous components● A framework, relies on drivers and plugins● Heavily dependant on Linux
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
OpenStack Compute (Nova)
● Responsible for the lifecycle of running instances ● Manages multiple hypervisor types via drivers
○ e.g., Red Hat Enterprise Linux with KVM
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)
OpenStack Object Store (Swift)
● Storage and retrieval of arbitrary unstructured data ● Provides object based interface via REST API● Replication, self-healing and load-balancing
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
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
OpenStack Orchestration (Heat)
● Facilitates the creation of ‘application stacks’● Stacks are imported as descriptive template language ● Allows for dynamic scaling based on configurable metrics
OpenStack Telemetry (Ceilometer)
● Central collection of metering and monitoring data● Consume data from the other components● Primarily used for chargeback of resource usage
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
Best Practices and Considerations
Disclaimer
OpenStack is an Engine, You build the car based on needs.
Lego, if you’re not a car person
LayoutHigh Availability
ComputeStorage
Networking
Layout
OpenStack Architecture:● OpenStack services are implemented
via several stateless Linux services● Messaging bus(RabbitMQ) for service
intercommunication● Database for persistent Data
Layout
Cinder Services:Cinder-APICinder-SchedulerCinder-VolumeCinder-backup
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
Layout
API/ Horizon Dashboard
GlanceCinder Nova-ComputeDatabase
MQ Messaging Nova-ComputeNova-Compute
StorageInternet
APIStorageTenantInternet Service Internal
Neutron Networking
LayoutHigh Availability
ComputeStorage
Networking
High Availability Architecture
● 3 Controllers
High Availability Architecture
● 3 Controllers● Database
○ Galera Multi-Master replication
○ MariaDB A/P Cluster● Message Bus
○ RabbitMQ MirroredQueues
High Availability Architecture
Cinder ServiceArchitecture:● Cinder-API● Cinder-Scheduler● Cinder-Volume● Cinder-backup
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)
LayoutHigh Availability
ComputeStorage
Networking
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
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
LayoutHigh Availability
ComputeStorage
Networking
Storage
Glance● Backends:
● Local, NFS, Ceph RBD, Swift● Glance Supports Multiple backends● Stick to those that you already know● Use Image Caching
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
LayoutHigh Availability
ComputeStorage
Networking
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
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
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
Thank you