Strategies for Landing an Oracle DBA Job as a Fresher
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
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
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
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