FORMATION OPENSTACK OP��RATEUR
1 ABOUT THESE TRAINING MATERIALS
2 . 1 TRAINING MATERIALS WRITTEN BY PARTICULE
ex Osones/Alterway Cloud Native experts Devops experts Our training offers: https://particule.io/en/trainings/ Sources: https://github.com/particuleio/formations/ HTML/PDF: https://particule.io/formations/
2 . 2 COPYRIGHT License: Creative Commons BY-SA 4.0 Copyright © 2014-2019 alter way Cloud Consulting Copyright © 2020 particule. Since 2020, all commits are the property of their owners
2 . 3 INTRODUCTION
3 . 1 GOALS OF THE TRAINING: OPENSTACK Discover OpenStack and use its different services Know how the project works and its capabilities Understand the internals of each OpenStack component Be able to make the right configuration choices Be capable of manually deploying an OpenStack cloud providing IaaS Know the best practices for deploying OpenStack Be able to track down the cause of an error in OpenStack Be able how to react in front of a bug and know the fix process
3 . 2 REQUIREMENTS Advanced sys admin skills for Linux such as Ubuntu, Red Hat or Debian, including: Package management Configuration files and services handling LVM (Logical Volume Management) and filesystems Notions: Virtualization: KVM (Kernel-based Virtual Machine), libvirt Network: iptables, namespaces SQL Optional: Comfortable in a Python environment
3 . 3 OPENSTACK: THE PROJECT
4 . 1 OVERVIEW
4 . 2 HIGH LEVEL
Simple version
4 . 3 HISTORY Started in 2010 Goal: the Free Open Source Cloud Operating System Merge of two projects from Rackspace (Storage) and NASA (Compute) Free software distributed under Apache 2.0 license Birth of the Foundation in 2012
4 . 4 MISSION STATEMENT To produce a ubiquitous Open Source Cloud Computing platform that is easy to use, simple to implement, interoperable between deployments, works well at all scales, and meets the needs of users and operators of both public and private clouds.
4 . 5 RELEASES Austin (2010.1) Bexar (2011.1), Cactus (2011.2), Diablo (2011.3) Essex (2012.1), Folsom (2012.2) Grizzly (2013.1), Havana (2013.2) Icehouse (2014.1), Juno (2014.2) Kilo (2015.1), Liberty (2015.2) Mitaka (2016.1), Newton (2016.2) Ocata (2017.1), Pike (2017.2) Queens (2018.1), Rocky (2018.2) Stein (2019.1), Train (2019.2) Early 2020: Ussuri
4 . 6 SOME OF THE SUPPORTERS/CONTRIBUTORS ... Editors: Red Hat, Suse, Canonical, Vmware, ... Hardware makers: IBM, HP, Dell, ... Hardware makers/network: Juniper, Cisco, ... Hardware makers/storage: NetApp, Hitachi, ... Also: NASA, Rackspace, Yahoo, OVH, Citrix, SAP, ... Google! (since July 2015) https://www.openstack.org/foundation/companies/
4 . 7 ... AND USERS All the previously mentioned contributors In France: Cloudwatt and Numergy Wikimedia CERN Paypal Comcast BMW Etc. Not counting confidential deployments https://www.openstack.org/user-stories/
4 . 8 THE DIFFERENT SUB-PROJECTS https://www.openstack.org/software/project-navigator/ OpenStack Compute - Nova OpenStack (Object) Storage - Swift OpenStack Block Storage - Cinder OpenStack Networking - Neutron OpenStack Image Service - Glance OpenStack Identity Service - Keystone OpenStack Dashboard - Horizon OpenStack Telemetry - Ceilometer OpenStack Orchestration - Heat
4 . 9 THE DIFFERENT SUB-PROJECTS (2) But also: Bare metal (Ironic) Queue service (Zaqar) Database service (Trove) Data processing (Sahara) DNS service (Designate) Shared File Systems (Manila) Key management (Barbican) Container (Magnum) Others Client CLI and libraries OpenStack deployment tools Libraries used by OpenStack Tools used to develop OpenStack 4 . 10 APIS Each project supports its OpenStack API Some projects support the corresponding AWS API (Nova/EC2, Swift/S3)
4 . 11 THE 4 OPENS Open Source Open Design Open Development Open Community https://governance.openstack.org/tc/reference/opens.html https://www.openstack.org/four-opens/
4 . 12 THE OPENSTACK FOUNDATION Main governance entity and legal representation of the project Board members are part of the sponsoring companies and elected by individual members Everyone can (freely) become an individual member Human resources: marketing, event managemement, release management, a few developers (mainly on infrastructure) 600 organizations across the world 80000 individual members in 170 countries
4 . 13 THE OPENSTACK FOUNDATION
Main entities of the Foundation
4 . 14 OPEN INFRASTRUCTURE Lately, the OpenStack Foundation expands to Open Infrastructure Beyond OpenStack, new projects: Kata Containers Zuul Airship StarlingX
4 . 15 RESOURCES Announcements (new versions, security advisories): [email protected] Documentation portal: https://docs.openstack.org/ API/SDK: https://developer.openstack.org/ Project governance: https://governance.openstack.org/ Releases: https://releases.openstack.org/ Support: https://ask.openstack.org/ [email protected] #openstack@Freenode
4 . 16 RESOURCES News: Official blog: https://www.openstack.org/blog/ Planet: http://planet.openstack.org/ Superuser: http://superuser.openstack.org/ Commercial resources: https://www.openstack.org/marketplace/ among others Job board: https://www.openstack.org/community/jobs/
4 . 17 USER SURVEY Regular survey done by the Foundation (every 6 months) Targets deployers and users Usable data: https://www.openstack.org/analytics
4 . 18 CERTIFIED OPENSTACK ADMINISTRATOR (COA) The only certification: Approved by the OpenStack Foundation Not linked to a specific company Content: Mainly OpenStack cloud user oriented https://www.openstack.org/coa/requirements/ Practical aspects: Practical exam, remote, duration: 2.5 hours Cost: $300 (one re-take possible) Ressources https://www.openstack.org/coa/ Tips: https://www.openstack.org/coa/tips/ Handbook: http://www.openstack.org/coa/handbook (unofficial) Exercises: https://github.com/AJNOURI/COA 4 . 19 RESOURCES - FRENCH COMMUNITY AND ASSOCIATION
Logo OpenStack-fr https://openstack.fr/ - https://asso.openstack.fr/ Meetups: Paris, Lyon, Toulouse, Montréal, etc. OpenStack Days France (Paris): https://openstackdayfrance.fr Attending events such as Paris Open Source Summit Communication channels: [email protected] #openstack-fr@Freenode
4 . 20 INTERNALS
4 . 21 ARCHITECTURE
Detailed view of the services 4 . 22 IMPLEMENTATION Everything is written in Python (Django for the web part) Each project is split in multiple services (example: API, scheduler, etc.) Re-use of existing components and existing libraries Usage of oslo.* libraries (developed by and for OpenStack): logs, config, etc. Usage of rootwrap to call underlying programs as root
4 . 23 IMPLEMENTATION - DEPENDENCIES Database: relational SQL (MySQL/MariaDB) Communication between services: AMQP (RabbitMQ) Caching: Memcached Distributed storage of configuration (to come): etcd
4 . 24 DEVELOPMENT MODEL
4 . 25 STATS (2017) 2344 developers 65823 changes (commits) https://www.openstack.org/assets/reports/OpenStack- AnnualReport2017.pdf
4 . 26 DEVELOPMENT: IN DETAILS Open to all (individuals and companies) 6 months release cycle Each cycle starts with a Project Team Gathering (PTG) During each cycle, an OpenStack Summit takes place
4 . 27 TOOLS AND COMMUNICATION Code: Git (GitHub is used as a mirror) Peer review for code: Gerrit Continous Integration (CI): Zuul Blueprints/specifications and bugs: Launchpad StoryBoard Communication: IRC and mailing-lists Translation: Zanata
4 . 28 DEVELOPMENT: IN DETAILS
Change workflow in OpenStack
4 . 29 RELEASE CYLE: 6 MONTHS The schedule is published, example: https://releases.openstack.org/stein/schedule.html Milestone releases Freezes: Feature, Requirements, String RC releases Stable releases Special case for some projects: https://releases.openstack.org/reference/release_models.html
4 . 30 PROJECTS Project Teams: https://governance.openstack.org/reference/projects/index.html Each deliverable has its own versioning - Semantic versioning https://releases.openstack.org/
4 . 31 WHO CONTRIBUTES? Active Technical Contributor (ATC) Person with at least one recent contribution in a recognized OpenStack project Voting rights (TC and PTL) Core reviewer: ATC with permissions to approve patches in a project Project Team Lead (PTL): elected by the ATC of each project Stackalytics provides stats on contributions http://stackalytics.com/
4 . 32 WHERE TO FIND INFORMATIONS ABOUT THE OPENSTACK DEVELOPMENT How to contribute https://docs.openstack.org/project-team-guide/ https://docs.openstack.org/infra/manual/ Various informations, on the wiki https://wiki.openstack.org/ Blueprints and bugs on Launchpad/StoryBoard https://launchpad.net/openstack/ https://storyboard.openstack.org/ https://specs.openstack.org/
4 . 33 WHERE TO FIND INFORMATIONS ABOUT THE OPENSTACK DEVELOPMENT Proposed patches and their reviews on Gerrit https://review.openstack.org/ CI state (among others) http://status.openstack.org/ Code (Git) and tarballs are available https://git.openstack.org/ https://tarballs.openstack.org/ IRC Freenode network Logs and meetings informations: http://eavesdrop.openstack.org/ Mailing-lists http://lists.openstack.org/
4 . 34 UPSTREAM TRAINING 2 days training Learn how to become an OpenStack contributor Tools Processes Work and collaborate in an open way
4 . 35 OPENSTACK INFRA Team in charge of the OpenStack development infrastructure Works like the OpenStack developement teams and uses the same tools Result: Infrastructure as code open source https://opensourceinfra.org/ Uses (hybrid) cloud Develops some tools: Zuul yaml2ical
4 . 36 OPENSTACK SUMMIT Every 6 months at the middle of the development cycle In the USA until 2013, now between North America and Asia/Europe A few dozens at the beginning to thousands attendees today At the same time: conference (users, decision makers)and Forum (developers/operators, replaces part of the previous Design Summit) Defines the name of the next release: place/city near the Summit
4 . 37 EXAMPLE OF THE APRIL 2013 SUMMIT IN PORTLAND Photo: Adrien Cunin
4 . 38 EXAMPLE OF THE OCTOBER 2015 SUMMIT IN TOKYO
Photo: Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2 4 . 39 EXAMPLE OF THE OCTOBER 2015 SUMMIT IN TOKYO
Photo: Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2 4 . 40 EXAMPLE OF THE OCTOBER 2015 SUMMIT IN TOKYO
Photo: Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2 4 . 41 EXAMPLE OF THE OCTOBER 2015 SUMMIT IN TOKYO Photo: Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2
4 . 42 PROJECT TEAM GATHERING (PTG) Since 2017 At the beginning of each cycle Replaces part of the previous Design Summit Dedicated to developers
4 . 43 TRANSLATION Official i18n team Only some parts are translated, like Horizon The French translation is one of the most complete today Use of a web platform based on Zanata: https://translate.openstack.org/
4 . 44 DEVSTACK: QUICKLY RUN OPENSTACK
4 . 45 DEVSTACK USE CASES Quickly deploy OpenStack Used by developers to test their changes Used for demos Used to the the APIs without bothering about a deployment Must NOT be used for production
4 . 46 DEVSTACK INTERNALS Support for Ubuntu 16.04/17.04, Fedora 24/25, CentOS/RHEL 7, Debian, OpenSUSE A shell script is responsible for everything: stack.sh A config file: local.conf Installs all the required dependencies (packages) Clones all the git repositories (master branch by défaut) Launches all the components
4 . 47 CONFIGURATION: LOCAL.CONF Example
[[local|localrc]] ADMIN_PASSWORD=secrete DATABASE_PASSWORD=$ADMIN_PASSWORD RABBIT_PASSWORD=$ADMIN_PASSWORD SERVICE_PASSWORD=$ADMIN_PASSWORD SERVICE_TOKEN=a682f596-76f3-11e3-b3b2-e716f9080d50 #FIXED_RANGE=172.31.1.0/24 #FLOATING_RANGE=192.168.20.0/25 #HOST_IP=10.3.4.5
4 . 48 USAGE TIPS DevStack installs a lot on the machine It is recommended to work inside a VM To test all the OpenStack components in good conditions, multiple Go of RAM are necessary Use of Vagrant is recommended
4 . 49 DEPLOY OPENSTACK
5 . 1 WHAT WE ARE GOING TO SEE Install OpenStack manually https://docs.openstack.org/install-guide/ Understand its internals Go through each component in more details Overview of deployment solutions
5 . 2 DETAILED ARCHITECTURE
Vue détaillée des services
5 . 3 SERVICES ARCHITECTURE Machines "physiques" et services
5 . 4 A FEW GLOBAL CONFIGURATION ITEMS All the components must be configured to talk with Keystone Most must be configured to talk with MySQL/MariaDB and RabbitMQ Components split in multiple services sometimes have one configuration file per service The policy.json configuraton file specify the required permissions for each API call
5 . 5 OPERATING SYSTEM Linux OS with Python Ubuntu Red Hat SUSE Debian, Fedora, CentOS, etc.
5 . 6 PYTHON
Python logo
OpenStack is Python 2.7 compatible Python 3 comptability almost complete So as not to reinvent the wheel, a lot of dependencies are necessary
5 . 7 MYSQL/MARIADB DATABASE Stores most of the data managed by OpenStack Each component has it own database OpenStack uses the SQLAlchemy Python ORM Theoretical support of what SQLAlchemy supports (and migrations support) MySQL/MariaDB is the most tested and used implementation SQLite is mainly used for tests and demos Some deployments work with PostgreSQL
5 . 8 MESSAGE BUS AMQP: Advanced Message Queuing Protocol Messages, queues, routing OpenStack processes interact through AMQP Multiple possible implementations: Qpid, 0MQ, etc. RabbitMQ by default
5 . 9 RABBITMQ
RabbitMQ logo
RabbitMQ is written in Erlang An Erlang virtual machine is therefore required
5 . 10 “HELLO WORLD” RABBITMQ
Simple example of RabbitMQ operation
5 . 11 MEMCACHED CACHE Multiple services make use of a caching mechanism Memcached is the default implementation
5 . 12 KEYSTONE: AUTHENTICATION, AUTHORIZATION AND SERVICE CATALOG
5 . 13 INSTALL AND CONFIGURATION APT package: keystone WSGI web server integration (Apache by default) Configuration file: /etc/keystone/keystone.conf Users/groups backends: SQL, LDAP (or Active Directory) Projects/roles/services/endpoints backends: SQL Tokens backends: SQL, Memcache, none (depending on the token type)
5 . 14 TOKENS DRIVERS Uuid PKI Fernet
5 . 15 BOOTSTRAP Services and endpoints creation (starting with Keystone) Users, groups and domains creation Bootstrap feature
5 . 16 NOVA: COMPUTE
5 . 17 NOVA API Two jobs API to manage instances for the utilisateur API for the instances: metadata API The metadata API must be available at http://169.254.169.254/ The metadata API provides personalized configuration informations to each instance
5 . 18 NOVA COMPUTE Manages instances (virtual or bare metal machines) Takes advantage of libvirt or other APIs such as XenAPI Drivers: libvirt (KVM, LXC, etc.), XenAPI, VMWare vSphere, Ironic Ability to retrieve console logs and VNC console
5 . 19 NOVA SCHEDULER Service in charge of scheduling instance requests to compute nodes Filter, Chance, Multi Scheduler Filters, by default: AvailabilityZoneFilter,RamFilter,ComputeFilter Sort by weigh, by default: RamWeigher
5 . 20 NOVA SCHEDULER IN ACTION
nova-scheduler operation
5 . 21 NOVA CONDUCTOR Optional service which improves security Act as a proxy between compute nodes and DB Compute nodes, at risk, therefore don't have DB access anymore
5 . 22 GLANCE: IMAGE REGISTRY
5 . 23 BACKENDS Swift or S3 Ceph HTTP Local directory
5 . 24 INSTALL APT package: glance-api
5 . 25 NEUTRON: NETWORK AS A SERVICE
5 . 26 PRINCIPLES Software Defined Networking (SDN) Was Quantum and nova-network neutron-server: provides the API DHCP agent: provides DHCP service to instances L3 agent: manages network layer 3, routing Plugin: LinuxBridge by default, other open source / proprietary, software/hardware implementations exist
5 . 27 ADDITIONAL FEATURES Beyonce basic layer 2 and 3 networking features, Neutron can provide other services: Load Balancing (HAProxy, ...) Firewall (vArmour, ...): different from security groups VPN (Openswan, ...): to reach a private network without floating IPs These features are also based on plugins
5 . 28 PLUGINS ML2 Modular Layer 2 LinuxBridge OpenVSwitch OpenDaylight Contrail, OpenContrail Nuage Networks VMWare NSX cf. OpenFlow
5 . 29 IMPLEMENTATION Each network is a bridge Bridges are expanded across hosts using tunnels (VXLAN type) if necessary Neutron takes advantage of Linux kernel network namespaces to allow IP overlapping Metadata proxy is a component that allows instances isolated in their network to reach the metadata API provided by Nova
5 . 30 DIAGRAM User view of the network
5 . 31 DIAGRAM 5 . 32 CINDER: BLOCK STORAGE
5 . 33 PRINCIPLES Was nova-volume Provides volumes Volume attachement through iSCSI by default
5 . 34 INSTALL Package cinder-api: provides the API Package cinder-volume: creation and management of volumes Package cinder-scheduler: scheduling of volume creation requests Package cinder-backup (optional): backup to an object store
5 . 35 BACKENDS Use of multiple backends in parallel possible LVM (by default) GlusterFS Ceph Proprietary storage systems such as NetApp DRBD
5 . 36 HORIZON: WEB DASHBOARD
5 . 37 PRINCIPLES Horizon is a Django module OpenStack Dashboard is the official implementation of this module
Python Django web framework logo
5 . 38 CONFIGURATION local_settings.py Services appear in Horizon if they exist in Keystone service catalog
5 . 39 SWIFT: OBJECT STORAGE
5 . 40 PRINCIPLES SDS: Software Defined Storage Use of commodity hardware CAP theorem: choosing two Completly decentralized architecture No central database
5 . 41 IMPLEMENTATION Proxy: API server for all the requests Object server: storage server Container server: maintains list of objects in containers Account server: maintains list of containers in accounts Each object is replicated n times (3 by default)
5 . 42 THE RING Problem: how to decide which data is going onto which object server The ring is split in partitions Each data is located in the ring to find out the partition A partition is associated to multiple servers
5 . 43 DIAGRAM
Swift architecture
5 . 44 CEILOMETER: METRICS COLLECTION
5 . 45 MONITOR USAGE OF INFRASTRUCTURE WITH CEILOMETER Stores different metrics regarding usage of cloud services Provides APIs to retrieve these data Base to build billing tools (example: CloudKitty)
5 . 46 CEILOMETER Retrieves data and stores them Used to be stored in MongoDB Now stored in Gnocchi
5 . 47 GNOCCHI: TIME-SERIES DATABASE Why Gnocchi? To solve Ceilometer + MongoDB scaling issues Initiated by Ceilometer developers and integrated in the Ceilometer project team Provides an API to read and write data Uses a relational DB and an object storage system
5 . 48 HEAT: RESOURCES ORCHESTRATION
5 . 49 ARCHITECTURE heat-api heat-engine
5 . 50 SOME OTHER INTERESTING COMPONENTS
5 . 51 TROVE: DATABASE AS A SERVICE trove-api: API trove-taskmanager: manages DB instances trove-guestagent: internal agent in instances
5 . 52 DESIGNATE: DNS AS A SERVICE Manages different backends: BIND, PowerDNS, etc.
5 . 53 BARBICAN: KEY MANAGEMENT AS A SERVICE Possible backends: Encrypted files PKCS#11 KMIP Dogtag
5 . 54 MAGNUM: CONTAINER INFRASTRUCTURE AS A SERVICE Backends: Swarm, Kubernetes
5 . 55 OPENSTACK IN PRODUCTION AND OPERATIONS
6 . 1 BEST PRACTICES FOR A PRODUCTION DEPLOYMENT
6 . 2 WHICH COMPONENTS SHOUD I INSTALL? Keystone is mandatory Use of Nova goes with Glance and Neutron Cinder and Swift usefulness depends on storage needs Swift can be used separately from other components Heat doesn't cost much Higher level services need to be evaluated case by case https://docs.openstack.org/arch-design/
6 . 3 THINK ABOUT FUNDAMENTAL CHOICES AT THE BEGINNING Distribution and deployment method Update and upgrade policy Drivers/backends: hypervisor, block storage, etc. Network: what architecture and what drivers
6 . 4 DIFFERENT INSTALLATION METHODS Forget about DevStack for production Manual deployment as seen previously is not recommended by unmaintainable Packaged and ready to use OpenStack distributions Classical distributions and configuration management Continuous deployment
6 . 5 MAJOR UPGRADES OpenStack supports N → N+1 upgrades Swift: very good rolling upgrade support Other components: test with you data first Read release notes Cf. CERN blog posts https://techblog.web.cern.ch/techblog/
6 . 6 STABLE UPDATES Major bug and security fixes are provided OpenStack includes these fixes as patches in the stable branch Point releases are published and includes fixes from the stable branch Stable version support timeframe is variable, depending on integrators' interest
6 . 7 ASSIGN ROLES TO MACHINES Lots of documentations mention these roles: Controller node: APIs, DB, AMQP Network node: DHCP, router, floating IPs Compute node: Hypervisor/instances management This simplified model is not HA.
6 . 8 HIGH AVAILABILITY IaaS High Availability MySQL/MariaDB, RabbitMQ: classical HA (Galera, Clustering) API services Are stateless and HTTP: scale out and load balancers Most other OpenStack services are able to scale out as well HA guide: https://docs.openstack.org/ha-guide/ Talks by Florian Haas, Hastexo: https://www.openstack.org/community/speakers/profile/398/florian- haas
6 . 9 HIGH AVAILABILITY OF THE NEUTRON L3 AGENT Distributed Virtual Router (DVR) L3 agent HA (VRRP)
6 . 10 APIS CONCERNS Uniform URLs for all the APIs: Use a reverse proxy Don't forget to update the service catalog Apache/mod_wsgi to serve APIs when possible (Keystone, etc.) Operations guide: https://docs.openstack.org/openstack- ops/content/
6 . 11 NETWORKS Management network: administrative network Data/instances network: network for inter instances traffic External network: external network, in the existing network infrastructure Storage network: network for Cinder/Swift storage API network: network containing API endpoints
6 . 12 SECURITY RELATED CONCERNS Must-have: HTTPS for external API access Securing MySQL/MariaDB and RabbitMQ traffic One MySQL/MariaDB access per database and per service One Keystone user per service Limit read permissions to configuration files (passwords, token) Security vulnerabilities: OSSA (OpenStack Security Advisory), OSSN (... Notes) Security guide: https://docs.openstack.org/security-guide/
6 . 13 SEGMENT A CLOUD Host aggregates: physical hosts with similar features Availability zones: hosts depending on the same electrical supply, same switch, same DC, etc. Regions: each region has its own API Cells: gather multiple clouds within a unique API https://docs.openstack.org/openstack- ops/content/scaling.html#segregate_cloud
6 . 14 HOST AGGREGATES Nova specific Admin defines host aggregates through the API Admin associates flavors and aggregates through common key/values 1 aggregate ≡ 1 similarity, ex: GPU User chooses an aggregate through their flavor choice when creating an instance
6 . 15 AVAILABILITY ZONES Nova and Cinder specific Hosts groups Split in terms of availability: Rack, Datacenter, etc. User chooses an availability zone when creating an instance Use can request instances to be started in the same zone, or on the contrary in different zones
6 . 16 REGIONS Generic in OpenStack AWS regions counterpart A service can have different endpoints in different regions Each region is autonomous Use case: very large cloud (such as some public clouds)
6 . 17 CELLS Nova specific Only one nova-api in front of mutiple cells Each cell has its own DB and message bus Adds a scheduling layer (cell choice)
6 . 18 OPENSTACK PACKAGING - UBUNTU Packaging is done in multiples distributions, RPM, DEB and others Ubuntu historically is the reference platform for OpenStack developement Packaging in Ubuntu closely follows OpenStack development, and automated tests are performed Canonical provides the Ubuntu Cloud Archive, which includes the latest OpenStack version for the latest Ubuntu LTS
6 . 19 UBUNTU CLOUD ARCHIVE (UCA)
OpenStack support in Ubuntu through UCA
6 . 20 OPENSTACK PACKAGING IN OTHER DISTRIBUTIONS OpenStack is integrated in Debian's official repository Red Hat provides RHOS/RDO (deployment based on TripleO) Like Ubuntu, Fedora's release cycle is synchronized with OpenStack's
6 . 21 OPENSTACK DISTRIBUTIONS StackOps: history Mirantis: Fuel HP Helion: Ansible custom etc.
6 . 22 TRIPLEO OpenStack On OpenStack Goal: ability to deploy an OpenStack cloud (overcloud) from an OpenStack cloud (undercloud) Autoscaling of the cloud itself: deployment of new compute nodes when necessary Works jointly with Ironic for bare metal deployment
6 . 23 BARE METAL DEPLOYMENT OpenStack bare metal hosts deployment can be managed with the help of dedicated tools MaaS (Metal as a Service), by Ubuntu/Canonical: works with Juju Crowbar / OpenCrowbar (initially Dell): uses Chef eDeploy (eNovance): image based deployment Ironic through TripleO
6 . 24 TEMPEST Test suite of an OpenStack cloud Makes API calls and checks the result Used a lot by developers through continuous integration Deployers can use Tempest to check their cloud's compliance See also Rally
6 . 25 CONFIGURATION MANAGEMENT Puppet, Chef, CFEngine, Saltstack, Ansible, etc. These tools can help deploying an OpenStack cloud ... but also to manage instances (next section)
6 . 26 MODULES PUPPET, PLAYBOOKS ANSIBLE Puppet OpenStack and OpenStack Ansible: Puppet modules and Ansible playbooks Developed as part of the OpenStack project https://wiki.openstack.org/wiki/Puppet https://docs.openstack.org/developer/openstack- ansible/install-guide/
6 . 27 CONTINUOUS DEPLOYMENT OpenStack maintains an always stable master (trunk) Possible to deploy master on a daily basis (CD: Continous Delivery) Requires setting up an important infrastructure Eases upgrades between major versions
6 . 28 FACING ISSUES
6 . 29 TIPS IN CASE OF ERROR OR FAULTY BEHAVIOR Are we working on the appropriate project? Is the API responding with an error? (the dashboard may hide some informations) If going further is required: Look into logs on thje cloud controller (/var/log/
6 . 30 IS IT A BUG? If the CLI client crashes, it's a bug If the web dashboard or the API responds with an error 500, it might be a bug If the logs show a Python stacktrace, it's a bug Otherwise, you decide
6 . 31 OPERATIONS
6 . 32 LOGS MANAGEMENT Centralize logs API logs Other OpenStack components logs DB, AMQP, etc. logs
6 . 33 BACKUP Databases Deployment mechanism, rather than configuration files
6 . 34 MONITORING API response Checking OpenStack services and dependencies
6 . 35 QUOTAS USAGE Limit the number of allocable resources Per user or per tenant Support in Nova Support in Cinder Support in Neutron
6 . 36 CONCLUSION
7 . 1 TO CONCLUDE Cloud is a revolution for IT OpenStack is the open source flagship project for the IaaS part Deploying OpenStack is not an easy task Using an IaaS cloud implies changes of practice Software and infrastructure architecture jobs are changing
7 . 2