Composants Openstack – Qui fait quoi? – Comment d'utiliser

View Github Repository Open presentation in a new window

chriscowley

See all presentation from chriscowley

Composants Openstack – Qui fait quoi? – Comment d'utiliser

0 0

dejtech-openstack

On Github chriscowley / dejtech-openstack

Openstack pour les nulls

Un introduction a Openstack

Created by Chris Cowley / @chriscowleyunix

Agenda

Qu'est que c'est?

Éléments

Chaque éléments fait quoi?

Comments utiliser?

What I will cover.

Qu'est que c'est (pas)?

Il n'est pas un hypervisorIl n'est pas un platform de stockageIl n'est pas un alternative a VMwareIl n'est même pas un seul projet.

gmmm

- The hypervisor is just one part of it - Not even an essential part - Once again, only part of it. - Several types of storage in Openstack (more later) - VMware can be part of an Openstack cloud

Donc, qu'est que c'est?

Un group des projets pour gerer les service cloud Supporter par le Openstack Foundation Aujourd'hui concentrer sur IaaS Les elements de PaaS commence a venir

Openstack Foundation

Et beaucoup plus ... même Orange

Et Moi

IaaS/PaaS?

Composants Openstack

  • Nova
  • Swift
  • Glance
  • Keystone
  • Horizon
  • Neutron
  • Cinder
  • Ceilometer
  • Heat
  • Trove <- New in Icehouse
  • Oslo

Projets en Incubation

  • Ironic
  • Triple-O
  • Zaqar
  • Sahara
  • Barbican
  • Designate
  • Manila
  • d'autre?
Just the ones listed in the current `programs.yaml`. Not guaranteed to be up to date.

Toutes les composants communique avec les API public

Ce n'etait pas tout

J'avais pas mis:

  • Trove
  • Oslo
  • Toutes les projet en "incubation"

Qui fait quoi?

Keystone

Indentification et autorisation

Utiliser par touts les autres modules.

Glance

Gerer les templates

Accepter les requettes des utilisateurs pour les images et metadata

Templates stocker dans Swift/S3, FS ou HTTP

Nova

Gerer tout les instance (openstack-lish pour VM)

Decider quelle neud d'utiliser pour un instance

Plugins pout plussier hypervisor:

  • KVM/Libvirt
  • vSphere (pas ESX)
  • Xen/XenServer
  • LXC
  • Bare metal
  • Même Hyper-V

Un instance est "stateless"

http://docs.openstack.org/juno/install-guide/install/yum/content/ch_nova.html

Cinder

Provisionner du stockage persistant pour les instances

On peut utiliser pour /, mais c'est pas le default

Plugins existes pour tout entre LVM et EMC VMAX

The root FS for each instance exists on Ephermeral storage (by default)

Swift

Stockage Objet

Utiliser par d'autre service (Glance par example)

Aussi utiliser en direct

Neutron

Software Defined Networking (SDN)

Mon preféré

Les tennants peut gerer le propre reseau avec les FWs, LBs et VPNs

Possiblité d'ajouter les IP externe pour les instance qui a besoin

Plugins pour Openvswitch, Cisco Nexus, VMware NSX, Brocade, BigSwitch, et d'autre

Un plugin L2 modular

Heat

Orchestration basé sur les templates

Avec une fichier on peut créer toute une infrastructure

  • Instances
  • Reseaux
  • Stockage
  • Accès externe

Horizon

Interface web pour gere Openstack

Utiliser par l'admin et utilisateur

Pas essential - les API sont des citoyens de première classe

Horizon utilise ces API

Ceilometer

Trove

Comment d'utiliser

1 node?

Ca scale pas, mais pour lab/dev/PoC oui

2 node cluster

Maintenant le même config peut etre utiliser a scale

Trystack

Le plus simple - c'est dans le cloud

Il faut avoir un compte Facebook

trystack.org

Red Hat RDO

Un projet Redat pour creer les lab et PoC

openstack.redhat.com

Limiter a RHEL, CentOS et Fedora

Puppet

Sur le Forge, il y a des modules pour installer/gerer Openstack

Compatible avec RHEL/CentOS et Ubuntu LTS

Utiliser par RDO

Plus souple de RDO

Openstack n'est pas vSphere!

Pas de HA - il faut faire dans l'application

Soir pessimist: un instance est disponible

Séparez les données (les instance sont stateless)

Be a pessimist: Assume everything fails and design backwards. Love your chaos monkey. Put your eggs in multiple baskets: Leverage multiple providers, geographic regions and availability zones to accommodate for local availability issues. Design for portability. Think efficiency: Inefficient designs will not scale. Efficient designs become cheaper as they scale. Kill off unneeded components or capacity. Be paranoid: Design for defense in depth and zero tolerance by building in security at every level and between every component. Trust no one. But not too paranoid: Not every application needs the platinum solution. Architect for different SLA’s, service tiers and security levels. Manage the data: Data is usually the most inflexible and complex area of a cloud and cloud integration architecture. Don’t short change the effort in analyzing and addressing data needs. Hands off: Leverage automation to increase consistency and quality and reduce response times. Divide and conquer: Pursue partitioning and parallel layering wherever possible. Make components as small and portable as possible. Use load balancing between layers. Think elasticity: Increasing resources should result in a proportional increase in performance and scalability. Decreasing resources should have the opposite effect. Be dynamic: Enable dynamic configuration changes such as auto scaling, failure recovery and resource discovery to adapt to changing environments, faults and workload volumes. Stay close: Reduce latency by moving highly interactive components and data near each other. Keep it loose: Loose coupling, service interfaces, separation of concerns, abstraction and well defined API’s deliver flexibility. Be cost aware: Autoscaling, data transmission, virtual software licenses, reserved instances, and so on can rapidly increase monthly usage charges. Monitor usage closely.