OpenStack Best Practices and Considerations - terasky tech day

Post on 17-Jul-2015

1.914 views 1 download

Tags:

Transcript of OpenStack Best Practices and Considerations - terasky tech day

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