OpenStack, vous connaissez ? Virtualisation et nuage/cloud, ça vous dit quelque chose ? Si vous n’êtes pas un expert, vous voulez sans doute en savoir un peu plus. Cet article est fait pour vous.
Nous allons rappeler ce qu’est un cloud, les différents types de clouds, et où se situe OpenStack. Ensuite, nous ferons une présentation d’OpenStack et de ses différents services.
La version d’OpenStack baptisée Kilo est sortie le 30 avril 2015. Elle incluait à cette date un nouveau service : Ironic. Le 16 octobre 2015, ce fut le tour de la version Liberty. D’autres sont à venir, à commencer par Mitaka, annoncé pour le 7 avril 2016. Pour mémoire, la première lettre du nom de version suit l’alphabet latin.
Cet article a pour but de faire une présentation assez rapide d’OpenStack et de servir de référence aux prochains articles, en particulier lors de la sortie de Mitaka en avril.
NdM. : Cette dépêche est incomplète, elle a longtemps traîné en rédaction. Elle a cependant le mérite de proposer un rare tour d’horizon. Les modérateurs la publient en comptant sur l’excellence de vos commentaires pour nous raconter les évolutions depuis la version Kilo.
Sommaire
Les différents clouds
Qu’est‐ce que le Cloud computing ?
Le Cloud computing est un concept fourre‐tout. C’est le fait d’utiliser de la puissance de calcul ou de stockage de serveurs informatiques distants par l’intermédiaire d’un réseau, avec certaines caractéristiques comme la disponibilité, l’élasticité, la mutualisation et le paiement à l’usage.
Le plus souvent il s'agit d'un service informatique extérieur à l'entreprise. Cela est donc une façon d'économiser des moyens humains en informaticiens et de les remplacer par un service externe qui peut gérer au besoin une demande importante.
Prenons un exemple pour bien comprendre : le cas d'une suite bureautique. Pour l'entreprise, il y a 2 manières de gérer l'utilisation d'un traitement de texte :
- Installer sur les postes clients un traitement de texte et payer éventuellement les licences qui vont avec (Microsoft Office 2013, LibreOffice).
- Utiliser un traitement de texte via un navigateur web (exemple : Microsoft Office 365, Google Doc, Etherpad instancié sur le Framapad).
La première méthode est moins souple, car l'entreprise paie les licences même si le logiciel n'est pas utilisé ; alors qu'avec la seconde, le paiement est à la demande. Par ailleurs, il n'y a pas la phase d'installation du logiciel qui permet d'économiser du temps. Par contre les données sont externalisées, ce qui peut poser des problèmes de sécurité et de confidentialité.
L'exemple qui vient d'être évoqué est un SaaS : Software as a Service/logiciel en tant que service
Mais il y a différents degrés d'informatique en nuage.
On peut faire l'analogie pour manger une pizza :
- La méthode "à la maison" : on achète les ingrédients, on les cuisine et on met la table. C'est la méthode traditionnelle. L'acheteur (entreprise ou particulier) contrôle tout et en a les compétences.
- La méthode "à emporter puis cuisiner" : on te fournit les ingrédients. C'est à toi de les cuisiner à ta manière et de s'occuper du reste. L'entreprise en tant qu'utilisateur n'a pas à s'occuper des matières premières mais elle a le contrôle du reste. En cloud, c'est IaaS : Infrastructure as a Service/infrastructure en tant que service, avec les compétences afférentes
- La méthode "pizza 30 minutes" : on appelle un vendeur de pizza. Il ne reste plus qu'à s'occuper de l'accompagnement et de la table. Dans le nuage, c'est PaaS : Platform as a Service/ plate-forme en tant que service
- La méthode "pizzeria" : on entre dans une pizzeria et on n'a rien à prendre en charge (ou presque). En cloud, c'est SaaS : Software as a Service/logiciel en tant que service.
OpenStack est un ensemble de logiciels libres permettant de déployer un cloud orienté IaaS, mais il est de plus en plus possible de faire un PaaS.
Cloud privé vs public
Le cloud public est un cloud qui permet à l'entreprise d'externaliser ses moyens. Il y a donc moins d'informaticiens à embaucher. L'entreprise doit par contre payer une autre entreprise et perd le contrôle de l'infrastructure et les données.
Exemple IaaS public connu : Amazon EC2, Windows Azure, RackSpace et CloudWatt.
Le cloud privé est un cloud qui permet de ne pas perdre le contrôle de l'infrastructure et des données tout en améliorant la qualité de service. Ce type de cloud est de plus en plus utilisé dans les grandes entreprises. Cela demande des compétences en interne.
Exemple IaaS privé connu : OpenStack, OpenNebula.
Il y a aussi le cloud hybride qui permet d'utiliser les avantages du cloud privé et du cloud public.
Avec un cloud hybride, une possibilité est de mettre les données sensibles et importantes dans le cloud privé et le reste dans le cloud public. Une autre possibilité dans l'optique de réduire ses coûts d'exploitation est de dimensionner son cloud privé pour une charge moyenne et d'utiliser le cloud public afin d'absorber les surcharges ponctuelles.
OpenStack
Présentation
GNU/Linux est né entre deux projets : le noyau Linux créé par Linus Torvalds et des outils systèmes du projet GNU. De la même manière, l'entreprise Rackspace a créé un service de stockage (Swift) et a besoin d'un système pour la gestion de la virtualisation automatique. Des employés de la NASA créent une solution toute trouvée : Nova. Ainsi, en 2010, OpenStack est né de 2 services : Nova et Swift.
OpenStack est sous licence Apache 2.0, licence de logiciel libre. Elle n'est pas Copyleft.
Historique des versions
Avec un rythme de quatre mois puis de six mois, les versions d'OpenStack sont sorties.
En 2011, le service Nova s'est séparé du service de gestion d'image de machine virtuelle pour créer un nouveau service : Glance.
En avril 2012, un nouveau service apparaît : Horizon. C'est l'interface web qui permet de visualiser les différents services d'OpenStack. Par ailleurs Nova se sépare du service d'identification pour créer un nouveau service : Keystone.
En septembre 2012, la gestion réseau de Nova (nova network) commence à prendre beaucoup trop de place. Un nouveau service apparaît : Quantum. Il sera appelé par la suite Neutron. Par ailleurs, la gestion du stockage bloc de Nova explose et un nouveau service naît : Cinder.
En 2013, deux nouveaux services apparaissent : Heat et Ceilometer. Heat est un service de gestion de l'orchestration. Ceilometer est un service de calcul de consommation de chaque client.
En avril 2014, le service Trove apparaît. C'est un service de gestion d'instance de base de données.
En octobre 2014, le service Sahara apparaît. C'est un service dédié au Big Data.
Technologies communes
Tous les services utilisent Python 2.7. Il y a un projet pour porter vers Python 3.
Chaque service utilise une base de données relationnelle. Par défaut, il utilise MySQL mais il est possible d'utiliser une autre base de données. OpenStack utilise comme ORM : SQLAlchemy.
Pour accéder, modifier une ressource, OpenStack utilise l'API REST qui est basée sur HTTP.
Pour la communication entre les services et à l'intérieur des services, OpenStack utilise AMQP. Par défaut, il utilise l'implémentation en Erlang : RabbitMQ.
Les différents composants
Nova
Développé à l'origine par la NASA, c'est le cœur d'OpenStack. Il s'occupe principalement de la gestion des hyperviseurs (ordonnanceur et gestion des machines virtuelles) et du contrôle des ressources (CPU, RAM, réseaux et stockages).
Glance
Glance a été extrait rapidement de Nova pour en faire un composant à entière. Il permet la gestion des images de machine virtuelles (découverte, enregistrement, récupération et états des images).
Keystone
Keystone permet la gestion de l'identification. L'utilisation d'un autre composant dépend de Keystone (accréditation).
Neutron
À l'origine ce composant s'appelait Quantum, il permet la gestion du réseau dans OpenStack. Il a des fonctionnalités réseaux avancées (tunneling, QoS, Réseaux virtuels et équilibrage de charge, etc.).
Avec Nova, Neutron est l'élément où le développement est le plus important (voir les statistiques de stackalystics grâce notamment à l'arrivé de Cisco dans le projet.
Swift
Ce composant permet la gestion du stockage objet. Il a été développé avant OpenStack par Rackspace. Il est ainsi indépendant d'OpenStack et est considéré comme le composant le plus stable. Il peut s'utiliser comme frontend avec le composant Glance.
Le stockage objet est une notion bien différente d'un stockage classique qu'on connaît sur les ordinateurs de bureau. Il n'y a pas de notion de montage de partition par exemple. Mais l'avantage principale de ce type de stockage est la disponibilité, la tolérance aux pannes et un agrandissement du stockage à l'infini. En contre-partie, il est considéré moins performant et beaucoup plus compliqué à paramétrer qu'un stockage classique. Un concurrent à Swift que vous connaissez certainement est Ceph.
Cinder
Ce composant permet la gestion du stockage de type bloc.
Ironic
Ironic est un nouveau composant du projet OpenStack. Il permet la gestion du Bare Metal c'est à dire des véritables ordinateurs et non des machines virtuelles. Il s'occupe ainsi le démarrage et l'extinction des ordinateurs. Il va utiliser des technologies comme PXE, TFTP ou IPMI par exemple.
Horizon
Horizon est une interface web pour la gestion d'OpenStack. Il utilise comme framework Django. Il permet ainsi de visualiser les différents composants d'OpenStack et d'agir dessus.
Heat
Heat est le composant d'orchestration d'OpenStack. Il permet par exemple de demander à Nova de démarrer une machine virtuelle supplémentaire en cas de charge importante de façon automatique.
Ceilometer
Ceilometer est le composant de facturation d'OpenStack. Il permet de calculer la consommation (CPU, RAM, données, etc) de chaque client (utile pour créer un cloud public)
Trove
Trove est le composant de provisionnement de bases de données d'OpenStack. Il prend en charge MySQL, PostgreSQL, MongoDB. Depuis kilo, il prend par ailleurs en charge Vertica et Vertica Cluster, DB2 et CouchDB.
Sahara
Sahara est le composant pour le Big Data d'OpenStack. Il permet d'utiliser Hadoop avec OpenStack.
Aller plus loin
- Openstack le site officiel (1260 clics)
- La documentation officielle (555 clics)
- OpenStack : Havana est sortie (918 clics)
- OpenStack et le bazar des API (648 clics)
- Release Notes de Kilo (203 clics)
# Et Designate ?
Posté par M.Poil (site web personnel) . Évalué à 2.
Et Designate ? http://docs.openstack.org/developer/designate/ :)
Is it a Bird? Is it a Plane?? No, it's Super Poil !!!
[^] # Re: Et Designate ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Ne sont pas évoqués dans la dépêche :
# Gouvernance ?
Posté par Robert VISEUR (site web personnel) . Évalué à 6.
Qqn a-t-il des retours sur la gouvernance du projet et la facilité pour les contributeurs à s'y intégrer ?
Il y avait aussi une inquiétude de certains quant à une divergence des implémentations (inquiétude en partie due au caractère permissif de la licence) chez les grands acteurs utilisant OpenStack. Des retours là dessus ?
# Contribuer à OpenStack bénévolement est devenu impossible.
Posté par MaxPower . Évalué à 10.
Bonjour à toutes et à tous,
C'est mon premier post sur LinuxFr, j'arpente pourtant ces colonne depuis fort longtemps, mais ce sujet m'a décider à franchir le pas sous la forme d'un coup de gueule. (drôle d'entrée en matière :)
J'ai contribué à OpenStack sur les projets Nova et Cinder sur les versions Folsom, Grizzly et Havana.
A cette époque, la communauté était plus petite et surtout plus fournie en "vrai" contributeurs individuels.
Non pas que je déplore l'engouement des grands groupes pour ce projet magnifique, OpenStack ne serait pas ce qu'il est sans eux, mais il est extrèmement difficile aujourd'hui de faire entrer quoique ce soit en son sein.
Je vais prendre l'exemple de Cinder (mais c'est pareil dans les autres projets).
Aujourd'hui, un driver cinder se résume (pour faire simple) à interfacer l'API d'un système de stockage (quel qu'il soit) avec Cinder. Créer un binding, en gros, entre ces deux monde.
1) Avant même de commencer à écrire la moinde ligne, il faut créer un blueprint (proposition de votre fonctionnnalité auprès de la communauté). C'est très compliqué aujourd'hui de créer ce blueprint, c'est extrèment structuré, il faut passer un temps monstre à discuter avec les CoreDev pour etre certain de ne rien oublier et de faire ça dans les formes.
2) Il faut de votre blueprint soit accepté par les CoreDev. Il faut donc passer encore du temps à faire du lobbying auprès des CoreDev (payer des bières peut aider ;). Mais vous n'avez toujours pas commencé à coder.
3) Votre blueprint est accepté, super, vous avez maintenant le droit de pousser du code.
Ici, c'est du classique au niveau des choses requises pour que votre code soit mergé:
4) La revue de code (c'est là une des raisons qui m'a décidé à arrêter de contribuer sur ce projet)
Pour rappel, je suis un contributeur individuel et bénévole, c'est à dire que je ne suis pas payé (par un grand groupe) pour contribuer à OpenStack, je le fait simplement parce que j'aime ce projet, que j'ai l'envie de le faire et je le fais sur mon temps libre.
Le suivi de votre revue de code est très importante, tout contributeur peu participer à la revue du code de n'importe qui.
Vous aller être questionner sur la pertinance d'un bout de code, on va peut-être vous apprendre des choses ou vous dire que telle fonction existe déja dans cinder.common
Il faut répondre aux questions, expliquer, accepter de changer etc … du classique.
Sauf qu'il m'a été reprocher de ne pas répondre suffisamant vite (dans la journée). Excusez moi de bosser …
5) Infrastructure de tests d'intégration (CI)
C'est relativement récent, je ne sais plus exactement sur quelle release c'est arrivé.
Dorénavant, chaque driver doit fournir une infrastructure de tests d'intégration pour son driver.
Encore une fois, pour des grands groupes, aucun problème pour payer quelques dizaines d'instances sur AWS ou bien monter une infrastructure en propre.
Mais quand est-il des "petits" projets ? Quand est-il des drivers déja présents dans OpenStack ?
Et bien pour les petits projets, c'est très dur, voir impossible.
Pour les drivers déja présents dans OpenStack qui n'ont pas mis en place cette infrastructure de tests, il ont purement et simplement étés supprimés !
Qu'OpenStack décide d'avoir une polique visant à fournir des drivers de qualité, peux se comprendre.
Mais qu'on laisse les petits projets exister, pourquoi ne pas avoir créer un répertoire 3th-party-drivers contenant les drivers qui ne couvrent pas entièrement les pré-requis ?
Qu'est ce qu'il reste aux vrai contributeurs individuel ? Bug Triage ? Bug Fixing ? Mais aucune nouvelle features ? Ecoeurant …
Aujourd'hui, je suis toujours utilisateur d'OpenStack, je le modifie, je l'améliore mais tout ça dans mon coin et ne commit plus rien … c'est moche.
[^] # Re: Contribuer à OpenStack bénévolement est devenu impossible.
Posté par Joris Dedieu (site web personnel) . Évalué à 6.
Sans remettre en cause ce que tu dis, lorsque j'avais évalué OpenStack pour mon taff (il y a trois ans environ) la qualité des drivers était vraiment un gros point noir. Mettre ça en prod sans avoir les ressources pour faire la QA en interne me semblait même irréaliste.
[^] # Re: Contribuer à OpenStack bénévolement est devenu impossible.
Posté par MaxPower . Évalué à 5.
Ca varie d'un driver à l'autre. Ca peut aussi venir d'un problème de configuration.
Dans certains cas on pouvait se retrouver avec des volumes en état "error" avec une impossibilité de les supprimer. On était donc obligé de faire le ménage en base de données directement mais fort heureusement ça à bien évolué depuis.
Il reste néanmoins qu'il faut une équipe solide pour faire de l'OpenStack en prod, bien tester, et ne pas sauter sur la dernière version dès qu'elle sort ;)
# Le gros point noir d'OpenStack
Posté par Le Gab . Évalué à 4.
La nomenclature des differents composants OpenStack, j'ai vraiment eu du mal à entrer dans le projet et je ne comprend toujours le délired dans ces choix.
Et le commentaire de Sibaud plus haut, en rajoute une couche:
C'est d'une complexité ridicule. C'est dommage pour un projet de cet envergure
[^] # Re: Le gros point noir d'OpenStack
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Seuls SearchLight, Designate, Zaqar, Barbican et Manila font partie de la version Liberty parmi ceux que j'ai rajoutés.
Et sinon le fait de donner un nom à chaque composant ne me semble pas différent de donner un nom à chaque bibliothèque, à chaque utilitaire, etc. OpenStack fournit des composants pour un ensemble de services (et souvent de serveurs) distincts, c'est plus compliqué qu'une simple application ou qu'un service web classique. Du coup la complexité du tout se retrouve dans cette complexité de nommage.
Un environnement de bureau complet comporte des tas de noms aussi : la liste de toutes les applications de GNOME est longue et avant qu'elles ne soient renommées avec un nom correspondant à leur fonction, c'était compliqué aussi de savoir qui sert à quoi. La liste des applications de KDE n'est pas plus limpide/courte. Etc.
Mais oui ça reste compliqué de savoir quel nom dans OpenStack correspond à quelle fonction, et en plus certains ont des noms utilisés ailleurs, comme Swift (qui correspond à au moins 5 projets logiciels différents selon wikipédia).
[^] # Re: Le gros point noir d'OpenStack
Posté par MaxPower . Évalué à 3.
Ce qu'il faut comprendre c'est qu'OpenStack à énormément évolué depuis ses débuts.
Il suffit de jeter un oeil à la liste des projets intégrés en fonction des versions. [1]
Bien au contraire, c'est justement ce qui fait sa force et sa modularité !
Tous les projets fonctionnent sur la même base :
Et quelques daemons :
Exemple avec Cinder :
L'intérêt de ce découpage, c'est de pouvoir faire grossir l'infrastructure facilement.
Ces daemons peuvent être placés sur différents serveurs, il n'ont pas besoin d'être l'un à coté de l'autre sur une même machine.
Si un daemon devient un goulet d'étranglement, il suffit d'en lancer un autre sur un autre serveur.
La communication entre les daemons s'effectue à travers un bus AMQP [2]
Tous les projets qui composent OpenStack ne sont pas forcément indispensables. C'est à vous de savoir lesquels vous seront utiles.
Parmis les briques indispensables, celles qui composent le tronc commun à toute infra OpenStack sont les suivantes :
Je ne cite pas Horizon parmis les briques indispensables parce qu'il ne s'agit pas d'un service OpenStack comme les cinq cités précédement.
C'est une application qui utilise les API REST des differents projets et présente un portail web permettant de gérer (plus ou moins) votre infrastructure. On ne peut pas tout faire avec Horizon, d'où le "plus ou moins".
Pour moi, ce qui peut en rebuter plus d'un, c'est la documentation.
Je me souviens à la version Essex, on pouvait trouver pas mal de tuto accompagnés d'explications, de schemas, c'était vraiment plus simple d'entrer dans le projet. (c'était moins touffu aussi, ça aide)
Aujourd'hui, la documentation [3] n'est pas du tout adapter à un publique de débutant, c'est plus un pense-bête pour des gens qui connaissent déja.
Je n'ai pas trouvé de tuto simple qui ne recopiait pas la documentation officiel.
Un simple exemple avec la configuration de Keystone. La plupart des docs, vous invites à saisir des lignes de commandes à ralonge comme celles-ci :
$ openstack service create --name keystone --description "OpenStack Identity" identity
$ openstack endpoint create \
--publicurl http://controller:5000/v2.0 \
--internalurl http://controller:5000/v2.0 \
--adminurl http://controller:35357/v2.0 \
--region RegionOne identity
Et ceci pour chaque brique ! Ca ne donne pas franchement envie n'est-ce pas ?
Alors qu'il existe un script [4] qui est disponible dans l'arborescence du projet.
Est-ce qu'il y en a, parmis vous, qui ont essayé OpenStack et qui ont trouvé que la documentation n'était pas adapté/suffisante/complète ?
Références :
[1] https://fr.wikipedia.org/wiki/OpenStack
[2] https://fr.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol
[3] http://docs.openstack.org/kilo/install-guide/install/apt/content/
[4] https://github.com/openstack/keystone/blob/master/tools/sample_data.sh
[^] # Re: Le gros point noir d'OpenStack
Posté par Wawet76 . Évalué à 7.
Il ne critiquait pas la complexité, mais la nomenclature.
Par exemple, ils auraient pu appeler Keystone "Openstack Identity" :)
[^] # Re: Le gros point noir d'OpenStack
Posté par MaxPower . Évalué à 2.
Dans ce cas, il semble que le problème soit corrigé dans la dernière version de la documentaton (Liberty)
http://docs.openstack.org/liberty/install-guide-ubuntu/
[^] # Re: Le gros point noir d'OpenStack
Posté par liced . Évalué à 0.
Sur la documentation, je suis complètement d'accord avec toi. Elle n'est pas suffisante surtout lorsqu'on commence à développer des choses dans OpenStack.
# Gestion des licences
Posté par fortytwo . Évalué à 2.
Très intéressant article. Un raccourci toutefois :
Bien que ce ne soit pas le modèle le plus courant, bon nombre d'applications reposent sur des serveurs de licence permettant de fédérer un pool de licence en entreprise. Par exemple Flexlm.
C'est encore mieux quand l'application supporte l'abandon automatique du jeton après un certain délai d'inactivité. C'est (ou était) le cas de FrameMaker.
# Formation
Posté par pizaninja . Évalué à 2.
Petites questions…
Le contexte: dans ma boite, on est passé d'une petite 10aine de VMs (builds, tests, supervision, stockage, etc) construites à la main il y a moins de 2 ans à une 50aines de VMs montables dynamiquement (vagrant + ansible), réparties sur 3 ou 4 serveurs (locaux ou externalisés). Et là, je commence à me dire qu'on va se faire déborder…
Question 1: Openstack peut-il m'aider?
Question 2: Comment puis-je me former?
[^] # Re: Formation
Posté par MaxPower . Évalué à 2.
Quelles sont vos problématiques aujourd'hui ? Le contexte c'est bien, mais qu'entendez-vous pas "se faire déborder" ?
Il y a tout d'abord la documentation officielle, qui, sans être parfaite, à tout de même le mérite d'exister.
Pour bien débuter, je dirais que l'objectif c'est de réussir à monter une infrastructure à 3 noeuds :
- Cloud Controller
- Network Controller
- Compute Node (hyperviseur)
La communauté peut vous aidez à atteindre cet objectif, il existe un chan irc "#openstack-101" [1] si vous voulez poser vos questions et obtenir de l'aide.
Vous pouvez aussi rejoindre l'association OpenStackFr [2] qui organise réguliairement des rencontres [3] avec les utilisateurs d'OpenStack. Il est possible de discuter avec les développeurs et les Projects Leaders.
Il existe aussi des formations certifiantes (payantes) [4]
Références:
[1] https://wiki.openstack.org/wiki/IRC
[2] http://openstack.fr
[3] http://www.meetup.com/OpenStack-France/
[4] https://www.openstack.org/marketplace/training/
[^] # Re: Formation
Posté par pizaninja . Évalué à 3.
Par "se faire déborder", j'entends: passer de plus en plus de temps dans mes journées à créer et maintenir de plus en plus de VMs en ligne de commande.
D'où le besoin d'avoir un outil de gestion de plus haut niveau pour gagner du temps, et pouvoir passer le relai si besoin (maintenance, évolution).
J'entends parler de ansible tower, openstack, puppetlabs, etc… Pas facile de choisir sans tester avant de manière un minimum approfondie…
J'utilise packer, ansible, vagrant, virtualbox, ça m'est devenu indispensable à chaque fois que j'ai mis les mains dedans. Mais là, openstack, ça m'a l'air assez difficile de tester à moindre frais pour se rendre compte si le service rendu en vaut la peine…
Voilà pour clarifier mon besoin…
[^] # Re: Formation
Posté par MaxPower . Évalué à 5.
Personnellement, j'utilise SaltStack [1] et SaltCloud [2]
Le premier me permet d'industrialiser le déploiment logiciel à l'intérieur de mes instances. Ansible, Puppet, Chef, etc… remplissent la même fonction.
SaltCloud quand à lui me permet de définir des architectures complète a déployer.
Pour prendre un exemple simple, imaginons une infrastructure à 3 noeuds :
- Un load-balancer (HAProxy)
- Un server web nginx + php
- Une base de données
Dans SaltStack je commence par créer les 3 cookbooks pour installer et configurer chacun de ces rôles.
Dans SaltCloud, je vais configurer mon CloudProvider (AWS, Azure, OpenStack, etc …)
Ensuite, je vais créer la "Map" de mon architecture à 3 noeud :
Puis lance la construction:
1) Dans la map, on remarque que le load-balancer requière un webserver, et que le webserver requière une base de données.
2) La première instance qui sera provisionnée sera donc la base de données, salt-cloud va parler à mon CloudProvider et demander l'installation de cette première instance.
3) Une fois l'instance en ligne, l'agent salt (le salt-minion) sera installé dessus et configuré pour parler à mon salt-master.
4) Le salt-master est configuré pour accepter les nouveaux minion et lancer immédiatement un highstate (mise à jour)
5) Dans la configuration de la map, j'ai spécifié le 'role: database', le highstate va donc déclancher le cookbook correspondant.
6) J'ai aussi spécifier le 'site: www.exemple.com', mon cookbook injectera alors le schéma (vierge ou la restauration d'un backup) de la base de données correspondant au site www.exemple.com
7) L'installation de l'instance 'db01' est maintenant terminée, le pré-requis pour installer le webserver est donc satisfait, l'installation du webserver peut commencer.
Instancer une nouvelle infrastructure comme celle-ci se résumera alors à copier la map et à changer quelques variables (role, site, etc …)
Voilà en gros ce qu'il est possible de faire avec OpenStack + SaltStack.
Mais ça n'est qu'un bref aperçu ! On peut faire bien plus, comme ajouter ou détruire des webservers du pool du load-balancer en fonction du nombre de connexions et ce sans aucune intervention humaine. Quand on est facturé à la minute dans le cloud, ce genre de fonctionnalité prend tout son sens.
Donc à vous de voir si ce genre de gourmandise peut vous servir ou s'il n'est pas plus intéressant pour vous de perfectionner votre industrialisation voir de changer d'outils.
[1] https://docs.saltstack.com/en/latest/topics/index.html
[2] https://docs.saltstack.com/en/develop/topics/cloud/index.html
[^] # Re: Formation
Posté par zebul0n (site web personnel) . Évalué à 1.
Merci d'avoir glissé packer dans ton commentaire, je ne connaissais pas, ça m'a l'air d’être exactement ce que je recherchais sans le savoir.
[^] # Re: Formation
Posté par ghusson (site web personnel) . Évalué à 5.
Personnellement, j'ai l'impression que beaucoup de grosses sociétés se mettent à OpenStack pour leur besoin interne par "effet de mode". Malheureusement, j'entends dire que cela coûte cher et que les échecs sont non rares et le ROI pas évident.
Ça demande pas mal de ressources (humaines et donc financières) pour aller sur OpenStack. Je regarde le projet depuis pas mal d'années et ça ne change pas…
Exemple : si on veut un cloud sans SPOF (point individuel de défaillance), il faut commencer par installer un serveur de base de données en cluster pour OpenStack… Bref, pour moi OpenStack devient intéressant quand on a de gros besoins (> 200 machines physiques par exemple).
Pour des besoins moins importants, je fonctionne depuis 2009 avec Proxmox VE. Et c'est que du bonheur. La dernière version remplace OpenVZ par LXC (j'attendais ça avec impatience). Et leur roadmap (feuille de route) est toujours cohérente. Bref, avant de regarder OpenStack, regardez Proxmox VE. Parce que quitte à faire plusieurs clusters Proxmox VE, si vous pouvez éviter OpenStack tant mieux… oh, OpenStack… "fuyez pauvres fous" ;p Bien sur ce n'est que mon avis personnel. Et je m'y mettrai certainement un jour parce que c'est "à la mode".
Et d'un point de vue professionnel, ce n'est pas pour rien que j'ai signé un partenariat avec Proxmox (pour le support professionnel). Martin MAURER et son frère sont techniquement très au point. Et leur société ne fait que grandir. J'aime beaucoup travailler avec eux et avec leurs produits (Proxmox Mail Gateway c'est du bonheur aussi en passant).
En conclusion, si besoin ~ < 200 serveurs,
- Proxmox VE pour le côté cluster et hyperviseur
- Ansible pour l'industrialisation (facile à apprendre mais limité en fonctionnalités, comparer avec SaltStack)
- Cobbler pour gérer l'installation des serveurs physiques ? (pas testé, pas forcément nécessaire avec l'installateur Proxmox)
- Sheepdog pour du stockage répartit (pas testé, a l'air plus simple que Ceph, mais à voir), sinon DRBD (qui propose de la répartition dans les dernières versions (j'ai bossé avec le "RAID 1" réseau de DRBD, j'ai bien aimé) - sinon Synology est ton ami…
Et une petite URL pour Proxmox :
http://www.proxmox.com/en/proxmox-ve/features
# Trop NASA par assez Métier.
Posté par Kwiknclean . Évalué à 5.
Hello,
Chouette article.
Je bosse plus ou moins dans ces sujets là, mais je n'ai jamais eu à faire a OpenStack.
Je ne commenterai pas le besoin réel de migration, qui est souvent discutable.
Mais j'ai eu plusieurs présentations par des commerciaux (et nous sommes en train d'intégrer une solution) propriétaire … qui "fait" plus ou moins la même chose, cad du cloud (comme l'explique l'article qui est un bon concept marketing fourre-tout, tellement fourre-tout qu'il refroidit tout les DSI sur son interêt réel).
Je préfére parler d'architecture hyperconvergées dans la plupart des cas. Bref on s'est vu présenter des solutions propriétaires, qui "virtualisent" presque toutes les couches, qui font converger toutes les couches d'Infra dans une seule boite.
Déploiement facile avoir au moins 2 noeuds physiques (souvent des Appliances ou des OVA Wmware), raccordé en salle, installer quelques minutes ensuite vous avez accès à une interface intuitive, ou qu'un qui n'est pas "expert" dans tous les domaines peut sans trop de mal administrer toute l"infra.
Ce n'est pas "parfait" mais ça semble plutôt bien fonctionner et l'implémentation et intelligente, il y a un support éditeur au cas ou vous vous retrouveriez dans un cas complexe ou un incident de prod, bref quelque chose de pensé/packagé entreprise. Lorsque tu utilises ce genre de produit tu as clairement la nette impression de gagner du temps.
OpenStack c'est tout l'inverse, ce n'est pas pensée du tout entreprise, mais 100% Ingénieuring / NASA.
Il manque clairement une phase d'intégration au produit pour le rendre plus "digeste".
Non pas que le produit soit moins "puissant" et propose moins de feature, mais alors rien que tous ces noms d'objets … Si j'étais DSI par exemple, j'aurais déjà des doutes sur la capacité de mes équipes déjà surchargées de taf à assimiler et à devenir assez "Expert" sur les N Features utilisées … y a un moment il faut toujours de l'expertise, surtout lorsque vous commencez à partir sur du full opensource et clairement tout ça m'a l'air d'être une belle usine à gaz.
Et tout ceux qui ont assez d'expériences dans les Infra IT, savent bien que les usines à gaz ça peut devenir très très vite mal implémentées incontrôlables donc vous coûter une somme folle en UP/UO à maintenir, développer, administrer l'outil … (qui n'en est pas un mince là puisqu'il s'agit pour le coup toute une infra IT)
[^] # Re: Trop NASA par assez Métier.
Posté par ondex2 . Évalué à 5.
(c'est pas très structuré, mais là j'ai la flemme, dsl)
Je lis dans les commentaires que les gens ont le sentiment que OpenStack est difficile à déployer/maintenir/…
Etant sysadmin sur de l'OpenStack de "grande envergure", je vais donner mon point de vu. Petite remarque, je fais de l'object storage (Swift) avec les briques qui tournent autour (Keystone, Ceilometer).
Malgré ce que vous diront les formateurs et les vendeurs, OpenStack n'est pas adapté pour les petits déploiements. Il est clair que les gros providers ont pris le pouvoir sur la roadmap. Il suffit d'aller aux OpenStack Summit (et particulièrement les Dev Summit) pour s'en rendre compte. C'est normal, tout l'ensemble est pensé pour être déployé et pour "scaler" sur de grosse infrastructure. Bien sur, vous pouvez faire un déploiement sur 3 hosts, mais l'ensemble sera quasi impossible à faire évoluer. La moindre mise à jour sera une plaie et se finira en échec. Si vous avez les ressources hardware nécessaire, vous pourrez faire "danser" les services d'une machine à l'autre et faire vos mises à jour sereinement (enfin, presque :D).
Pour parler de ce que je connais mieux, côté Swift, le système n'a quasiment pas de limite… A condition de savoir ce qu'on fait. Il est facile de monter une infra Swift qui va "s'écrouler" passer quelques centaines de TB. Si on comprend et on maitrise le produit, on l'emmène à plusieurs dizaine de PB sans soucis, et probablement plus. Mais la barrière d'entrée est élevée, il faut passer du temps à comprendre les rouages, je ne compte plus le nombre de fois ou j'ai été lire le code pour comprendre la raison d'un comportement, il ne faut pas compter sur la doc pour ça. Le logiciel, comme tout OpenStack, est très souple. On peut l'adapter à ses besoins ou lui tordre le bras à volonté, très simplement.
Bref, il est clair que OpenStack a du sens pour les sociétés qui ont le besoin de grosse infra et qui peuvent se permettre d'investir du temps humain. Sinon, prenez du VMWare et/ou de l'EMC.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.