Red Hat presentatie: Open stack Latest Pure Tech


Published on

Presentatie van Bart van den Heuvel (RedHat) over OpenStack, gegeven op 21 januari 2014 bij Proxy Services.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Red Hat presentatie: Open stack Latest Pure Tech

  1. 1. OpenStack IaaS 1 Bart van den Heuvel EMEA Forward Deployed Engineer - OpenStack
  2. 2. What is OpenStack? ● ● ● ● Fully open source cloud “operating system” Provides all of the tools/building blocks required to build a cloud environment from scratch - mimics public clouds Started by NASA and Rackspace but now has an independent foundation in which key industry members are present, including Red Hat Enormous market hype with investment from all major players, e.g. HP, Dell, IBM... and with 1000's of developers worldwide
  3. 3. OpenStack Organisation
  4. 4. Why does the world need OpenStack? ● Cloud is widely seen as the next-generation IT delivery model ● ● Utility-based on-demand consumption ● ● Agile & flexible Self-service drives down overhead and maintenance Public clouds setting the benchmark, organisations want the same level of functionality but behind the firewall ● ● Not all organisations are ready for public cloud Applications are being built differently today● ● ● More tolerant of failure Make use of scale-out elastic architectures OpenStack enables organisations to achieve this, today... and without lock-in.
  5. 5. Why should I care? ● Servers fail - Deal with it! ● If you were to build an environment from scratch● ● Build with 10,000 machines ● ● Start with extremely reliable (30year MTBF) servers You'll watch one fail every day! We need a new type of application to cope ● Fault-tolerant software is inevitable ● Change to scale-out rather than scale-up!
  6. 6. A different kind of architecture... TRADITIONAL WORKLOADS ● ● ● ● ● Stateful virtual machines Big VMs: vCPU, vRAM, local storage inside VM Application SLA aligned to VM itself Relies on underlying HA technology to meet SLA goals CLOUD WORKLOADS ● ● ● ● VMs scale up: add vCPU, vRAM, etc. ● ● Applications not designed to tolerate failure of VMs ● Stateless VMs, application distributed Small VMs: vCPU, vRAM, storage separate Application SLA not dependent on any one VM Many instances can provide application availability Applications scale out: add more VMs Applications designed to tolerate failure of VMs
  7. 7. Where does OpenStack fit in?
  8. 8. Where does OpenStack fit in? OpenStack provides an elastic cloud platform for these new workloads
  9. 9. Typical OpenStack Use Cases ● Service provider offering ● ● Re-sell compute, networking and storage resources as a new cloud provider to other organisations Internal cloud offering ● ● ● “Infrastructure-on-demand” service for internal customers Test & Development Environments Large-scale web applications or content farms ● Dynamically scale based on load ● e.g. Netflix, PayPal, eBay
  10. 10. OpenStack is not a replacement for enterprise virtualisation
  11. 11. OpenStack Release History ● July 2010 - Initial announcement ● October 2010 - Austin Release ● February 2011 - Bexar Release ● April 2011 - Cactus Release ● October 2011 - Diablo Release ● April 2012 - Essex Release ● October 2012 - Folsom Release ● April 2013 - Grizzly Release ● October 2013 - Havana Release ● April 2014 – Icehouse Release
  12. 12. OpenStack Contribution Leading Contributor to Grizzly and Havana Releases ● Leading in commits and line counts across all projects ● Note: Not including OpenStack dependencies, Linux, KVM, libvirt, etc ● Figures below are for Grizzly. 12
  13. 13. OpenStack Progression ● ● ● ● ● ● Open source, communitydeveloped (upstream) software Founded by Rackspace Hosting and NASA ● ● ● Managed by the OpenStack Foundation Vibrant group of developers collaborating on open source cloud infrastructure Software distributed under the Apache 2.0 license No certifications, no support ● ● ● ● Latest OpenStack software, packaged in a managed open source community ● ● Facilitated by Red Hat Aimed at architects and developers who want to create, test, collaborate ● Freely available, not for sale ● Six-month release cadence mirroring community ● No certification, no support Installs on Red Hat and derivatives ● ● Enterprise-hardened OpenStack software Delivered with an enterprise life cycle Six-month release cadence offset from community releases to allow testing Aimed at long-term production deployments Certified hardware and software through the Red Hat OpenStack Cloud Infrastructure Partner Network Supported by Red Hat Installs on Red Hat Enterprise Linux only
  14. 14. Community → Enterprise
  15. 15. Red Hat OpenStack Offering Red Hat will include the following in its Red Hat OpenStack distribution ● ● All core OpenStack Havana packages including Neutron Support for Open vSwitch via userspace tools in Red Hat OpenStack + kernel support in RHEL 6.5 ● ● A multi-node installer for for both small and large deployments ● Reference architectures for large scale deployments ● 15 Puppet modules for installing all services for OpenStack Bug-fixes and features selectively back-ported from Icehouse
  16. 16. Release Cadence ● Upstream ● ● Releases every 6 months ● 2 to 3 'snapshots' including bug fixes ● ● Source code only No more fixes/snapshots after next release Upstream RDO ● ● 16 Follows upstream cadence Delivers 'binaries' in yum/rpm format for RHEL, Fedora, etc.
  17. 17. Release Cadence ● Red Hat OpenStack ● 6 month release cycle ● Roughly 2 months AFTER upstream ● ● Time to stabilize, certify, back-port etc. Initially 1 year lifecycle ● ● ● Support for Folsom ends after Havana release Support for Grizzly ends after Icehouse release Will increase lifecycle over time ● 17 Based on upstream stability and customer requirements
  18. 18. OpenStack Architecture
  19. 19. OpenStack Components ● Modular architecture ● Vast scale-out design ● Based on a (growing) set of core-components
  20. 20. OpenStack Keystone ● Keystone provides a common authentication and authorisation store for OpenStack ● Users, their roles and the tenant (project) they belong to ● Authentication is based on tokens ● 24-hour expiry by default ● Easily revoked if compromised ● Each OpenStack component uses Keystone to verify a users token ● It also provides a catalogue of all other OpenStack services
  21. 21. OpenStack Nova ● Core responsibility is to schedule and manage instances (think Amazon EC2) ● Supports multiple hypervisors (list below is upstream only, not necessarily Red Hat Supported) ● ● Xen ● KVM ● ● VMware ESX (either direct to ESX or via vCenter) Microsoft Hyper-V Exposes an OpenStack API but also an EC2 compatible API
  22. 22. OpenStack Glance ● Mechanism for storing and retrieving disk images ● Supports many standard image types ● ● raw, qcow2, vmdk, vhd, iso, ami/aki, ovf With various storage options for the images ● Filesystem (Default) ● Swift (OpenStack Object Storage) ● S3 (Amazon's Simple Storage Service)
  23. 23. OpenStack Swift ● Mechanism for storing and retrieving arbitrary unstructured data (as objects) ● Entirely REST-ful HTTP API based, similar to Amazon S3 ● Highly fault tolerant ● ● Self-healing architecture ● Load-balancing with built-in proxy servers ● ● Data replication (including geographically) No single point of failure Doesn't require any specific hardware, purely scale-out.
  24. 24. OpenStack Neutron ● OpenStack's Networking-as-a-Service Component ● Implements Software Defined Networking (SDN) ● Rich plugin architecture which allows Neutron to abstract the underlying technology implementation away. Examples of upstream support include● Cisco UCS ● VMware Nicira ● Open vSwitch (Default in RHEL OSP)
  25. 25. OpenStack Cinder ● Provides block storage for runtime of instances ● Can be used for persistent or tiered storage ● Enables ability to do live migration of instances ● Similar to Amazon Elastic Block Storage (EBS) ● Support for many storage vendors platforms for offload ● Default implementation exposes LVM's over iSCSI
  26. 26. OpenStack Heat ● Facilitates the deployment of 'Application Stacks' and all required dependencies ● Allows portability of applications between clouds in a predictable fashion ● Based on templates written in YAML ● Provides basic high availability and scalability via OpenStack Ceilometer ● Designed after (and compatible with) Amazon's CloudFormations ● Integrated into the OpenStack Dashboard (Horizon)
  27. 27. OpenStack Ceilometer ● Central collection of metering and monitoring data – ultimate goal = billing/chargeback ● Allows identification of bottlenecks and capacity planning ● Based on both agents and message bus listening for statistics ● Exposes an API for consumption of metering data ● Completely extensible – you choose what you want to meter, e.g. CPU time, bandwidth usage
  28. 28. OpenStack Horizon ● Self-service portal exposing end-user OpenStack functionality ● Web-based interface that utilises underlying API's ● Permits the creation and life-cycle management of ● ● Images ● Volumes ● ● Instances (including snapshots) Networks Has different views depending on whether the user is an administrator or not.
  29. 29. OpenStack Horizon - Screenshot
  30. 30. Common OpenStack Architecture ● All data is held in a SQL database ● ● ● Can be made highly-available if replicated Default is MySQL, but others are supported Components have two sub-component types: ● ● ● API Endpoints – The RESTful entry-point into the component One or more 'daemons' – The services that carry out instructions Vast majority of OpenStack is shared-nothing and very fault-tolerant ● Components scale out using shared message bus (qpid, RabbitMQ etc) ● API Endpoints can be load-balanced (virtual IP's) for resilience/throughput ● High level of service location flexibility
  31. 31. Typical Deployment
  32. 32. OpenStack “Global” Deployment ● Keystone Regions ● Used by Keystone to segregate complete environments, ● e.g. deployment in New York vs. London ● ● ● Completely separate nova, cinder, quantum, glance etc Single Keystone instance Availability Zones ● ● ● Used by Nova to isolate groups of compute-hosts within an environment, users can deploy to a particular zone Typically used for tiered systems or for ensuring availability Nova Cells ● Increases scalability by creating smaller Nova clusters ● Each with their own database and message queue but single Nova API ● Are scheduled just like a host would be
  33. 33. Demo