Transcript WWT Corporate Overview

OpenStack and WWT
March 2015
Art Hansen
Consulting Solutions Architect
Copyright © 2013 World Wide Technology, Inc. All rights reserved.
Agenda
• Introductions
• OpenStack Overview
• OpenStack at WWT
Art Hansen- Quick Intro
•
•
•
•
•
•
•
Technical Solutions Architect, focused on Cloud and Big Data
Former IBM developer
Open Source Zealot
Sponsored and Established OpenStack Lab at WWT
OpenStack Conferences: Portland (Grizzly) , Hong Kong (Havana) , Atlanta (Icehouse)
Based in Phoenix
Likes Golf and Backpacking
OpenStack Overview
Copyright © 2013 World Wide Technology, Inc. All rights reserved.
OpenStack Overview
• Emerging open source Cloud Management Platform (CMP)
• Operates at the Control plane, manages the Data plane
• Targeted towards:
• Modern Cloud Applications
• Development/Operations Integration (devops)
• Cloud Enablement/Faster and Easier Consumption of IT
•
•
•
•
Started in 2010 by NASA and Rackspace
Rapid Development
6 Month Release Cycle
Named releases
OpenStack Hype
•
•
•
•
•
OpenStack is a Hypervisor
OpenStack is a VMware Replacement
OpenStack lets me use commodity hardware
OpenStack is SDN, SDN is OpenStack
Anything can run on Openstack
•
•
•
•
OpenStack operates at the Control Plane, not the Data Plane*
OpenStack is not yet well suited for legacy applications (Pets)
OpenStack can use SDN, but is not SDN
Modern cloud applications drive commodity hardware discussion
Traditional Infrastructure & Tool centric SLA’s
OpenStack Responsibilities Shift
Traditional Infrastructure
High Availability
Infrastructure, Application
Backups
Backup Tools
Data Protection
Storage Infrastructure
Performance and Scaling
Infrastructure Tools
Disaster Recovery
Infrastructure and Process
OpenStack
-> Applications
(Cloud Enabled)
* Being adapted for traditional infrastructure, very early in the process
OpenStack Adoption Success
Not Successful
Infrastructure
Statistics
Matched
Deployment
VM
Migration
Production
Failure
Assumption of
replacement,
identify VMs
Deployment based
on VM sizes
VM conversion
without application
and process change
Breakdown in support,
process, and use of
infrastructure
Starter/Small
Deployment
Application
Identification
DevOps
Production Use
Exposure and
training for greater
internal audience
Identify applications
that are/can be
cloud enabled
Adopt DevOps
model and redeploy
applications
Successful
POCs and
Demos
Establish high-level
understanding and
use cases
<- Admin
Traditional Virtualization
vSphere, Hyper-V, RHEV
<- End User
OpenStack Complexity
Target: Simplicity for End User/Developer/DevOps Engineer
Consume Resources through simple web interface, CLI or standard open API
Admin ->
OpenStack
Complex
End User ->
Simple
OpenStack Is Not Simple
•
OpenStack is NOT a single software package, it’s an
open source public cloud “project” comprised of many
modular parts.
•
OpenStack is NOT natively HA. It’s takes deep technical
knowledge and understanding to make an OpenStack
deployment HA.
•
There is no 1-800-OpenStack number to call when your
deployment breaks, you’re on your own. No break / fix
mitigation.
•
There is NO clean upgrade path when a customer wants
to move from an older version of OpenStack to a newer
version of OpenStack.
•
Because OpenStack deployments are highly
customizable, if the technical expert that installed your
OpenStack deployment leaves your company, you are
compromised.
•
Scaling OpenStack is very hard since there are so many
modules that can become a choke point in an
installation
Industry Drivers and Challenges
 IOT and Rapid Business Disruptions Driving Organizations to think like
Software Developers




45% of CIO’s have “Bi-modal” IT Strategy
Traditional Mode (“Reliability Mode”)
Non Traditional Mode (“Agility Mode”)
Eighty Percent of Private Cloud Projects Fail



IT Builds “Cloud” and Developers Don’t Come
Time to Value to Users
Skill Set Gap
•Source: Lydia Leong, Gartner
Pets vs Cattle
< Virtual “Machines”
< Instances
The slide comes from a presentation titled “CERN Data Centre Evolution”
OpenStack Future
• Plugins, Plugins, Plugins
• Broad integration and OEM product compatibility
• OEM Bundles
• Cisco UCS + Redhat Cloud Infrastructure + Cisco ACI
• First UCSO Bundle January ‘15
• Continued Rapid Development
•
•
•
•
HA Integration
Cloud Federation
Advanced Security
Containers
• Half of the Fortune 500 will deploy by 4Q15
Related Projects
•
•
•
•
•
•
•
•
•
RedHat Inktank/CEPH – Object and Block Storage on Compute Hardware
RedHat Storage/Gluster – Object, Block, File Storage on Compute HW
RedHat CloudForms – Multi-Cloud, Multi-Infrastructure A&O
RedHat OpenShift – Platform as a Service
RedHat Enterprise Virtualization – Mainstream Hypervisor and Infrastructure
for classic Virtualization
RedHat Cloud Infrastructure – Bundled offering of RH OSP, CloudForms,
RHEV
Puppet
Chef
Docker
OpenStack Key Concepts
Copyright © 2013 World Wide Technology, Inc. All rights reserved.
OpenStack Key Concepts - Plugins
• OpenStack operates only at the Control plane
• OpenStack did not create anything new in the Data plane, it uses tools and systems that
already exist*
• Swift is the exception – object based storage
• OpenStack interacts with tools and systems for controlling the Data plane by way of Plugins
• Plugins are created to allow Openstack to interact with:
•
•
•
•
Hypervisors: KVM, vSphere, Xen, Hyper-V, LXC, Docker
Storage: NetApp, CEPH, Gluster, Solidfire, etc
Network: NXOS, ACI/APIC, Arrista, OpenFlow, OpenvSwitch, etc
Services: Load Balancers, Firewalls, VPNs
OpenStack Key Concepts - Projects
•
•
•
•
•
Projects are virtually isolated private tenant environments
Multiple users can access multiple projects
Projects cannot directly interact with each other
Depending on the underlying plugins, projects can overlap IP space
Every virtual resource in OpenStack belongs to a Project
• Including certain routers, load balancers, firewalls, images, volumes
• Usage quotas are set on projects
OpenStack Key Concepts - Storage
•
•
•
•
Images are bootable disk images ready for live use
Images are not installation media
Images are served and maintained by the Glance component
Images are created:
• Retrieved from a vendor/application source (like AWS images)
• Created as the result of the snapshot of an Instance
• Created manually based on a Virtual Machine
• Upon use, the selected image is copied onto the target instance persistent or nonpersistent storage
• Volumes are persistent storage usually stored on an array, accessed via iSCSI, RBD, NFS, FC,
etc. Volumes are managed by the Cinder component.
• Disk data from instances without volumes will be lost when the instance is terminated
• Instances run without attached volumes are non-persistent and typically use compute-local
file-backed storage
OpenStack Key Concepts - Instances
• Instances are similar to VMs but are treated more like processes on a server than a server
itself
• Instances with Volumes attached are generally persistent
• Instances without Volumes attached are generally non-persistent
• Instances can be launched from an image or from a volume
• For an instance to boot from a volume, an image must be deployed to that volume
• An instance can be turned into an image by creating a snapshot
• Upon launch, instances typically run cloud-init scripts
OpenStack Key Concepts - Networks
• Networking is a broad and complex subject in OpenStack
• Two networking component options exist:
• Nova-network – original network control component offering flat VLAN bridging capability
• Neutron – originally named Quantum, Neutron is a more advanced and functional network control
component in OpenStack
• Nova-network will be deprecated, Neutron is the focus for all continued development
• Many plugins and valid designs exist for Neutron
• For the purposes of this session, we will use default Neutron Plugins:
• OpenvSwitch+OpenFlow, with VXLAN Overlay
• Linux haproxy for LBaaS
• Linux kernel packet forwarding and namespaces for routers and NAT
OpenStack Key Concepts - Interaction
• All Components allow for interaction three ways:
• Python CLI Client
• Horizon Dashboard
• OpenStack REST APIs
• This allows for flexible and easy integration with 3rd party and custom tools
Example Instance Launch Workflow
Process flow
1.
2.
3.
4.
5.
6.
7.
8.
New instance is requested
API server sends request to controller
Controller checks for available hosts
Compute worker instantiates new instance
Compute worker completes task
Network is configured
Controller is notified
New instance creation is complete
Scheduler
3
2
Nova API
1
4
Compute
5
Controller
6
8
7
Network
OpenStack at WWT
Copyright © 2013 World Wide Technology, Inc. All rights reserved.
OpenStack at WWT
GO TO MARKET
•
•
•
•
•
OpenStack Participation since 2011
Dedicated Architect Resources
Open Cloud Working Group
Multi-Year OpenStack Staff Aug Contracts
Continuing Involvement in OEM Integration (ATC)
•
•
•
•
Cisco and Red Hat Primary Focus for Enterprise
ATC Live Demo, POC and Training Capabilities
Implementation Services (PS)
Rack Build and Integration Services (ITC)
ATC OpenStack Pod
OPENSTACK POD
ATC Network
10GE L3
Nexus 5596UP
w/ L3
UCS 6248 FI
NetApp FAS 25xx
UCS C22 PXE/Control/Mgmt Server
17x UCS C220 Rack Servers
Multi-purpose, Multi-boot nodes
4x Nodes SAS Connected
NetApp E5600s
•
•
•
•
•
•
•
•
•
CVD Based, close to UCSO
2x Nexus 5596 switches w/ L3
17x UCS C220 Compute Nodes
4x UCS C240 Storage Nodes
1x UCS C22 Control Node (RHEV-Hypervisor)
Control Functions Virtualized on RHEV
NetApp FAS2552 with dual controllers
2x NetApp E5600s with SAS dual controllers*
FC Connected EMC VNX Storage
OpenStack Storage
OPENSTACK POD
Non-Persistent Instances
Persistent Instance Volumes
No Volumes, No Cinder
Volumes and Cinder
Compute
Nodes
Compute
Nodes
Compute
Nodes
Compute
Nodes
FAS
CEPH
Nodes
[local storage]
VNX
FAS
eSeries
eSeries
OpenStack Networking
OPENSTACK POD
Infrastructure Routing and
Switching
External Network: VLAN or Untagged
Tenant A LB
Tenant A Router
Shared Network: VLAN or Untagged
Tenant A
DHCP, MetaData
Agents
Shared
DHCP, MetaData
Agents
Tenant A Networks
VXLAN, GRE, or VLAN
Tenant A
Instance
Tenant A
Instance
Tenant A
Instance
Tenant B
Instance
Tenant B
Instance
Tenant LBs
ATC OpenStack Workshops + Demos
GO TO MARKET
•
•
•
•
•
•
•
•
OpenStack General Demo
Rapid Web Scaling Demo
Heat Orchestration Demo
1-Day OpenStack Intro Training (24 Students)
Design/Configuration/Troubleshooting Workshop
Neutron Deep Dive
Storage Deep Dive
Red Hat CloudForms Demo
ATC OpenStack Workshops + Demos
GO TO MARKET
Coming Soon/Current Projects:
• AWS Migration Demo
• OpenShift on OpenStack + Scaling Demo
• Cisco ACI and OpenStack Integration Demo
• RH Foreman OpenStack Deployment Demo
• CEPH Deep-Dive
WWT OpenStack Training
GO TO MARKET
•
•
•
•
•
Full Day
14 Live Labs (web based/bring laptop)
Up to 24 Concurrent Students
Customer Office/Remote/WWT Office
Agenda:
• OpenStack Overview
• OpenStack at WWT
• OpenStack Key Concepts
• Administration Labs
• End User Labs
• Optional Demos
• Component Deep Dives
• Q&A
OpenStack Key Concepts
Copyright © 2013 World Wide Technology, Inc. All rights reserved.
OpenStack Key Concepts - Plugins
• OpenStack operates only at the Control plane
• OpenStack did not create anything new in the Data plane, it uses tools and systems that
already exist*
• Swift is the exception – object based storage
• OpenStack interacts with tools and systems for controlling the Data plane by way of Plugins
• Plugins are created to allow Openstack to interact with:
•
•
•
•
Hypervisors: KVM, vSphere, Xen, Hyper-V, LXC, Docker
Storage: NetApp, CEPH, Gluster, Solidfire, etc
Network: NXOS, ACI/APIC, Arrista, OpenFlow, OpenvSwitch, etc
Services: Load Balancers, Firewalls, VPNs
OpenStack Key Concepts - Projects
•
•
•
•
•
Projects are virtually isolated private tenant environments
Multiple users can access multiple projects
Projects cannot directly interact with each other
Depending on the underlying plugins, projects can overlap IP space
Every virtual resource in OpenStack belongs to a Project
• Including certain routers, load balancers, firewalls, images, volumes
• Usage quotas are set on projects
OpenStack Key Concepts - Storage
•
•
•
•
Images are bootable disk images ready for live use
Images are not installation media
Images are served and maintained by the Glance component
Images are created:
• Retrieved from a vendor/application source (like AWS images)
• Created as the result of the snapshot of an Instance
• Created manually based on a Virtual Machine
• Upon use, the selected image is copied onto the target instance persistent or nonpersistent storage
• Volumes are persistent storage usually stored on an array, accessed via iSCSI, RBD, NFS, FC,
etc. Volumes are managed by the Cinder component.
• Disk data from instances without volumes will be lost when the instance is terminated
• Instances run without attached volumes are non-persistent and typically use compute-local
file-backed storage
OpenStack Key Concepts - Instances
• Instances are similar to VMs but are treated more like processes on a server than a server
itself
• Instances with Volumes attached are generally persistent
• Instances without Volumes attached are generally non-persistent
• Instances can be launched from an image or from a volume
• For an instance to boot from a volume, an image must be deployed to that volume
• An instance can be turned into an image by creating a snapshot
• Upon launch, instances typically run cloud-init scripts
OpenStack Key Concepts - Networks
• Networking is a broad and complex subject in OpenStack
• Two networking component options exist:
• Nova-network – original network control component offering flat VLAN bridging capability
• Neutron – originally named Quantum, Neutron is a more advanced and functional network control
component in OpenStack
• Nova-network will be deprecated, Neutron is the focus for all continued development
• Many plugins and valid designs exist for Neutron
• For the purposes of this session, we will use default Neutron Plugins:
• OpenvSwitch+OpenFlow, with VXLAN Overlay
• Linux haproxy for LBaaS
• Linux kernel packet forwarding and namespaces for routers and NAT
OpenStack Key Concepts - Interaction
• All Components allow for interaction three ways:
• Python CLI Client
• Horizon Dashboard
• OpenStack REST APIs
• This allows for flexible and easy integration with 3rd party and custom tools
Example Instance Launch Workflow
Process flow
1.
2.
3.
4.
5.
6.
7.
8.
New instance is requested
API server sends request to controller
Controller checks for available hosts
Compute worker instantiates new instance
Compute worker completes task
Network is configured
Controller is notified
New instance creation is complete
Scheduler
3
2
Nova API
1
4
Compute
5
Controller
6
8
7
Network