Archives pour la catégorie Cloud

Qu’est-ce que le cloud computing ?

Cloud

Le concept du cloud

Le monde moderne de l’internet et du World Wide Web est composé de centaines de milliers de serveurs répartis dans des milliers de data centers dispersés aux quatre coins du monde. Nous faisons appel à ces serveurs en permanence pour discuter avec d’autres personnes, jouer à des jeux, consulter l’actualité, envoyer des mails, etc. Lorsque depuis notre navigateur nous faisons l’une de ces activités quotidiennes, nous accédons à un programme s’exécutant sur un serveur. Mais où ce programme s’exécute-t-il réellement ? Où sont les données ? Où sont les serveurs ? Ils sont quelque part, là-bas, dans un data center, quelque part dans le monde. Nous ne savons pas où, et plus important encore, nous ne nous en soucions pas ; et il n’y a absolument aucune raison pour que nous nous en inquiétions. Ce qui compte pour nous, c’est que nous pouvons utiliser les logiciels et accéder aux données chaque fois que nous en avons besoin.

C’est l’idée fondamentale du cloud : les programmes et les données sont sur un serveur, quelque part, nous ne savons pas où et cela nous importe peu.

Mais pourquoi appeler cet ensemble de ressources « cloud » ? Un nuage est une immense réserve de minuscules gouttelettes d’eau. Certaines de ces gouttelettes tombent dans nos jardins, apportant de l’eau à nos arbres et nos pelouses ; d’autres s’écoulent et s’infiltrent pour venir emplir les nappes phréatiques à partir desquelles nous puisons notre eau potable. Et les nuages eux-mêmes se développent à partir de l’eau évaporée, qui provient de partout. Tout ce que nous voulons, c’est assez d’eau dans nos jardins pour garder nos plantes en vie et assez d’eau dans nos aquifères pour avoir de l’eau potable. Nous ne nous inquiétons pas de savoir quel nuage va nous apporter la pluie ; cela nous est égal. Nous ne nous inquiétons pas non plus de savoir de quelle partie du globe l’eau provenait ; c’est de l’eau. Les gouttelettes sont toutes les mêmes ; d’ailleurs, ne dit-on pas « se ressembler comme deux gouttes d’eau » ? Tant que nous en avons suffisamment, nous sommes heureux.

Ainsi, nous pouvons faire un parallèle avec cette nuée de data centers répartis sur l’ensemble du globe, tels des nuages. Les plus grands acteurs de l’informatique tels que Google, IBM, Microsoft, Amazon ou Yahoo! possèdent des milliers de machines connectées en réseaux qui exécutent toutes sortes de programmes. Chacun de ces centres est un nuage, et chaque processeur, chaque disque dur est une goutte d’eau dans ce nuage. Dans le monde des nuages, lorsque l’on écrit un programme, nous ne savons pas sur quelle machine il va fonctionner. Nous ne savons pas où les disques qui stockent les données sont, et nous n’avons pas besoin de le savoir. Nous avons juste besoin de savoir de combien de gouttelettes nous avons besoin.

L’évolution du cloud computing

Pour comprendre ce que le cloud computing est et n’est pas, il est important de comprendre comment ce modèle de l’informatique a évolué.

À intervalle régulier, les experts et autres futurologues consacrent une technologie en lui inventant un nom qui deviendra le nouveau buzzword . Ainsi, au cours des dix dernières années, nous avons vu émerger des termes tels que : mobile, WYSIWYG, social, ou encore Web 2.0. Certains ont résisté à l’épreuve du temps, mais pour la plupart, ils sont déjà démodés. Une idée a cependant réussi à traverser les vicissitudes de cet océan de buzzwords : le cloud computing.

Comme l’a fait remarquer Alvin Toffler dans son fameux livre The Third Wave il y a déjà presque 35 ans, la civilisation a progressé par vagues (trois à ce jour : la première fut la vague agraire, la deuxième fut la vague industrielle et la troisième est la vague de la connaissance). Chacune de ces grosses vagues comporte par ailleurs son lot de vaguelettes. Dans cette ère de la connaissance post-industrielle, nous sommes à présent au commencement de ce que certains pressentent être l’ère du cloud computing.

Dans son livre The Big Switch, Nicholas G. Carr compare la révolution de l’information à un changement important ayant eu lieu dans l’ère industrielle. Plus précisément, Carr assimile la montée du cloud computing dans l’ère de l’information à la production et la distribution de l’électricité dans l’ère industrielle. Thomas Edison, l’inventeur de l’ampoule électrique avait son laboratoire à Manhattan et y a créé sa compagnie pour vendre ses ampoules. Cette entreprise, qui plus tard deviendra General Electric, proposait aux propriétaires des grands immeubles de Manhattan d’acheter des générateurs pour produire l’énergie qui leur permettrait d’alimenter en électricité les ampoules installées. Tous les soirs, chaque building mettait donc en marche son générateur. Quelques années plus tard, Samuel Insull, l’un de ses collaborateurs, inventa le grid ; au lieu de faire installer à chacun de ses clients un générateur, des centrales électriques ont été construites sur le territoire. Ainsi, l’installation des éclairages était simplifiée, les entreprises n’avaient plus à fournir leur propre énergie, elles se branchaient simplement sur le grid ; le réseau de distribution électrique était né. Les clients ne savaient plus d’où provenait l’électricité et ne s’en souciaient pas. Nicholas Carr soutient que le cloud computing n’est que le début de la même révolution pour la technologie de l’information.

Actuellement, les entreprises disposent de leurs propres ressources informatiques (générateurs électriques). L’avenir qui se dessine cependant est un futur dans lequel chaque organisation pourra tout simplement se brancher au cloud (le grid) pour ses besoins en ressources informatiques. Car en fin de compte, les économies offertes par les services mutualisés deviendront trop importantes pour être écartées, même pour les plus grandes entreprises.

Comme nous l’avons vu, au sein de chaque vague, il existe de nombreuses vaguelettes, et l’ère de l’information en a déjà connu de nombreuses. Ainsi, nous avons débuté avec les mainframes, et évolué vers les mini-ordinateurs, puis sont venus les ordinateurs personnels, et ainsi de suite ; nous entrons maintenant dans le cloud computing. La figure ci-dessous illustre les vaguelettes de l’ère de l’information :

Les vaguelettes de l'ère de l'information
Les vaguelettes de l’ère de l’information

Au début des années 2000, le PDG d’Oracle a proclamé que l’ensemble des données des utilisateurs serait stocké dans le cloud et que les PC ne seraient guère plus que des terminaux passifs permettant l’accès au web. Bien sûr, la vision de Larry Ellison ne s’est jamais totalement matérialisée, mais certains de ses aspects sont très présents dans nos vies aujourd’hui.

Prenons les mails par exemple, la plupart des utilisateurs possèdent une adresse mail du type Gmail, Hotmail, Yahoo! ou encore La Poste ; ce sont des services de cloud computing. D’autres bons exemples de notre migration vers le cloud sont Google Agenda et Google Docs. Ces deux services stockent nos données dans le cloud pour nous permettre d’y accéder, quel que soit l’ordinateur depuis lequel nous nous connectons au service. Des services tels que DropBox, Google Drive, OneDrive (qui remplace SkyDrive) de Microsoft ou encore hubiC d’OVH nous permettent de stocker et de partager nos fichiers dans le cloud, tandis qu’Office 365 de Microsoft propulse notre suite bureautique dans le cloud.

YouTube, Vimeo et Dailymotion nous permettent de profiter de la vidéo depuis le cloud, tandis que Spotify, Deezer, GrooveShark et autres SoundCloud font de même pour la musique. Google Play Music, iCloud d’Apple et Amazon Cloud Player nous permettent même de stocker nos propres musiques pour les écouter en streaming depuis le cloud partout et tout le temps.

Nous utilisons ainsi au quotidien et souvent sans y prêter attention, de nombreux services hébergés dans le cloud, et ces services facilitent la vie de millions de personnes.
Mais le cloud est loin de n’être réservé qu’aux particuliers. Dans ce Nouveau Monde de l’information, qui requiert une disponibilité permanente, la technologie est devenue la pierre angulaire et joue un rôle critique pour le succès des entreprises. Quelle que soit la taille de l’entreprise, la technologie constitue un avantage économique certain : elle permet d’encourager l’engagement client, d’amplifier la productivité, d’innover et de se différencier de la concurrence. Ainsi, les solutions de cloud computing permettent aux entreprises de réaliser des économies, de simplifier leur structure informatique tout en leur garantissant l’agilité et la flexibilité qui leur est nécessaire pour prospérer.

Le cloud computing défini

La notion de « cloud » a cela de magique que chacun est libre d’y voir ce que bon lui semble. D’ailleurs, comme tout buzzword, il n’avait aucun sens informatique ou scientifique réel et ne s’est imposé que grâce à un matraquage publicitaire. En conséquence, le nuage s’est transformé en brouillard et il était devenu compliqué de savoir de quoi il était question lorsque l’on parlait de cloud. Preuve en est cette étude réalisée en janvier 2009 par Luis M. Vaquero, Luis Rodero-Merino, Juan Caceres et Maik Lindner qui démontre que pas moins de 22 définitions différentes du cloud ont été proposées par des experts.

Par chance, en septembre 2011, le NIST (Institut national des normes et de la technologie) s’en est mêlé et a défini les caractéristiques du cloud computing ; définitions qui ont été depuis largement acceptées.

Côté français, dans son texte n° 42, le Journal officiel n°0129 du 6 juin 2010 page 10453 a émis une définition légale de l’informatique en nuage qui la décrit comme « Mode de traitement des données d’un client, dont l’exploitation s’effectue par l’internet, sous la forme de services fournis par un prestataire. L’informatique en nuage est une forme particulière de gérance de l’informatique, dans laquelle l’emplacement et le fonctionnement du nuage ne sont pas portés à la connaissance des clients. ».

Bien que cette définition soit la seule valable en France juridiquement parlant, elle manque de précision et de spécifications techniques. En conséquence, l’ensemble des caractéristiques et modèles qui seront traités ci-après sont tirés des définitions du cloud computing établies par le NIST dans son document The NIST Definition of Cloud Computing.

Ainsi, pour être qualifiée de cloud, une technologie doit satisfaire aux cinq caractéristiques suivantes :

  • Libre-service à la demande
  • Accès universel
  • Mutualisation des ressources
  • Adaptabilité rapide
  • Paiement à l’usage

Les caractéristiques essentielles du cloud

Le libre-service à la demande

La notion de libre-service à la demande est primordiale pour les utilisateurs de service cloud. Le libre-service à la demande permet à l’utilisateur d’être en mesure de provisionner, mais également de libérer des ressources distantes en temps réel en fonction des besoins, et sans nécessiter d’intervention humaine.

L’accès universel

L’ensemble des ressources doit être accessible et à disposition de l’utilisateur universellement et simplement à travers le réseau, quels que soient les clients utilisés (serveur, PC, client mobile, etc.). Ceci implique trois prédispositions :

  • Accès utilisateur – afin de garantir que l’accès à une solution de cloud soit perçu comme stable et fiable, il est nécessaire que celle-ci dispose d’un accès haut débit
  • Accès applicatif – en vue de s’assurer que la solution soit en mesure de mettre à disposition de l’utilisateur les autres fonctionnalités du cloud, l’accès au réseau doit être disponible au sein même de la solution
  • Accès opérateur – dans le but de pouvoir maintenir et administrer un système cloud correctement, le fournisseur de service cloud doit pouvoir accéder à celui-ci via le réseau

Ainsi, s’assurer qu’un accès total au réseau est disponible dans tous les aspects d’une solution de cloud est essentiel pour offrir l’ensemble des autres caractéristiques.

Mutualisation des ressources

Les ressources matérielles du fournisseur sont partagées entre les différents utilisateurs du service. Ce partage rend l’emplacement exact des données des utilisateurs impossible à déterminer, ce qui peut poser un véritable problème aux entreprises qui sont soumises à de nombreuses contraintes réglementaires concernant la localisation et le contrôle des données. En contrepartie, les économies d’échelle réalisées permettent de réduire les coûts du fournisseur et donc les dépenses des utilisateurs.

Adaptabilité rapide

L’une des caractéristiques du cloud computing est l’élasticité des ressources. Cette caractéristique permet aux utilisateurs de provisionner rapidement de nouvelles ressources de manière à être en mesure de répondre à une montée ou à une descente en charge soudaine. Il n’est jamais évident de prévoir les ressources qui seront nécessaires à la mise en place d’un service informatique quelconque, en particulier lorsque ce besoin est en constante évolution. Le cloud computing offre ainsi un moyen de fournir les ressources informatiques nécessaires à une évolution ou à un pic d’utilisation de ce service.

Paiement à l’usage

Les systèmes cloud doivent être capables de s’autocontrôler et de se gérer pour permettre l’optimisation interne du système. Pour cela, ils s’appuient sur des mesures de référence obtenues grâce à divers mécanismes de supervision. Ces mesures précises permettent une juste facturation des utilisateurs ; ceux-ci ne payeront ainsi que pour les ressources qu’ils ont utilisées et seulement pour la durée qu’ils les ont utilisées.

Les modèles de service

Lorsqu’il est question de cloud computing, il est souvent fait référence aux termes SaaS, PaaS et IaaS. Souvent désignés comme les principales composantes du cloud, ils permettent de déterminer divers degrés d’externalisation. Détaillons.

Software as a Service

Les méthodes traditionnelles de vente de logiciels nécessitaient que le client paye une licence qui lui permettait d’installer et d’utiliser le logiciel sur son propre matériel. Le client avait également la possibilité d’acheter un contrat de maintenance qui lui permettait de recevoir les correctifs pour le logiciel ou d’autres services de support. Le client était préoccupé par la compatibilité des systèmes d’exploitation, l’installation des mises à jour de sécurité ainsi que par les contrats de licence.

Dans le modèle SaaS, le client n’achète pas un logiciel, mais paye un droit d’utilisation. Ce droit d’utilisation peut être facturé grâce à un abonnement, selon l’utilisation du client, ou même gratuitement (souvent avec des fonctionnalités limitées ou une utilisation commerciale des données). En règle générale, le fournisseur délivre un service complet, que ce soit d’un point de vue matériel, logiciel ou support. L’utilisateur accède au service par l’intermédiaire d’une interface web ou d’un périphérique autorisé. Le client n’a ainsi plus à se soucier de la gestion des licences, de l’installation, de la maintenance des machines, des mises à jour logicielles, ni même des recrutements de personnels compétents dans ces domaines.

En termes d’architecture, la différence la plus importante entre le modèle traditionnel et le modèle SaaS est le nombre d’entités que l’application servira. Le modèle traditionnel est un modèle isolé et mono-utilisateur, ce qui signifie qu’un client achète l’application et l’installe sur un serveur. Le serveur n’héberge que cette application spécifique et seul le groupe d’utilisateur du client y a accès. Le modèle SaaS est un modèle multitenant, cela signifie que l’infrastructure matérielle est partagée entre de nombreux clients différents. Cette architecture maximise le partage des ressources matérielles, mais permet tout de même d’être en mesure d’assurer la distinction des données appartenant à chaque client.

Platform as a Service

Dans le modèle PaaS, le fournisseur de service cloud offre un environnement de développement aux développeurs d’applications qui auront également la possibilité de distribuer leurs services à travers la plateforme du fournisseur. Le fournisseur met à disposition des APIs permettant d’instancier une plateforme adaptée aux besoins du client et propose souvent des canaux de distribution et de paiement. Cela permet au client de profiter de canaux de distribution efficaces pour un faible coût d’entrée.

Le Platform as a Service peut être vu comme une variante du Software as a Service dans lequel l’environnement de développement serait proposé en tant que service. Les développeurs utilisent les outils du fournisseur pour créer leurs propres applications, ils peuvent souvent créer des applications web sans avoir à installer le moindre outil sur leur poste de travail. Ensuite, ils ont la possibilité de déployer leurs applications sans pour autant avoir besoin de disposer de compétences en administration système ; cela permet aux développeurs et aux petites entreprises de déployer des applications web sans pour autant devoir supporter la complexité et les coûts engendrés par l’achat et la configuration de serveurs.

En résumé, les solutions de PaaS sont des plateformes de développement pour lesquelles l’outil de développement lui-même est hébergé dans le cloud et accessible via un navigateur. Elles offrent la possibilité aux développeurs de concevoir des applications web sans requérir une expertise spécialisée.

Infrastructure as a Service

Dans le modèle traditionnel des applications hébergées, le vendeur fournit au client toute l’infrastructure nécessaire à l’exécution de ses applications. Souvent, cela implique d’acheter ou de louer des serveurs dédiés à une seule application spécifique.

Le modèle IaaS fournit également l’infrastructure nécessaire à l’exécution des applications, mais l’approche du cloud computing permet d’offrir un modèle du type paiement à l’usage ainsi que la possibilité de redimensionner son instance en fonction du besoin actuel.

Du point de vue du fournisseur d’IaaS, ce modèle lui permet de construire une infrastructure qui gère les pics et les creux de la demande de ses clients et d’ajouter de nouvelles capacités au fur et à mesure que la demande globale augmente. Il facturera ensuite le client pour les ressources qu’il a réellement consommées.

Le client, lui, loue une ressource, il choisit le nombre de cœurs CPU, la quantité de mémoire vive et l’espace disque de cette dernière. Cette instance qu’il loue ne lui appartient pas, savoir comment celle-ci est gérée en interne n’est pas non plus de son ressort, elle est peut-être sur un serveur de dernière génération, ou sur une machine en fin de vie, peut-être a-t-elle même été migrée de serveur en serveur pour finalement changer de data center ? En réalité, la seule chose dont le client veut être certain, c’est qu’il profitera des ressources et de la disponibilité que le fournisseur d’IaaS lui a garanties ; car en fin de compte, toutes ces problématiques techniques, il a choisi de les sous-traiter à un professionnel.

En résumé

Dans le modèle classique, l’utilisation de logiciels d’entreprise classiques nécessite des investissements matériels (coût des locaux, des serveurs, du matériel de sauvegardes, des équipements réseau), logiciels (coût d’achat des licences, coûts annuels de l’assistance, des mises à jour, des changements de versions) et humains conséquents. En contrepartie, l’entreprise garde son indépendance et une totale maitrise de son infrastructure.

Avec le modèle IaaS, le prestataire héberge l’infrastructure informatique de l’utilisateur ou plus généralement de l’entreprise. Cette dernière peut gérer à distance son infrastructure comme si celle-ci se trouvait dans ses propres locaux, les contraintes matérielles en moins. Le prestataire s’occupe ici de la virtualisation, du stockage, des réseaux, du matériel, et de la continuité de service.

Le PaaS désigne de manière générale l’environnement fourni par le prestataire au client. C’est un socle fonctionnel et prêt à l’emploi qui lui est mis à disposition. L’utilisateur aura donc la possibilité de gérer ses applications au sein de celui-ci.

Enfin, le SaaS consiste à fournir des applications hébergées et accessibles en ligne par le biais d’un navigateur web. Les logiciels se présentent sous la forme de services. Une inscription et le paiement d’un droit d’accès permettent généralement à l’utilisateur d’exploiter ces derniers.

La figure suivante illustre les principaux composants de ces quatre modèles, ainsi que les niveaux de responsabilités qui incombent à l’entreprise et au fournisseur de cloud sur chacun des composants.

L’impact du cloud computing sur la structure de gouvernance des organisations informatiques
L’impact du cloud computing sur la structure de gouvernance des organisations informatiques

Les modèles de déploiement

Le terme cloud est une métaphore de l’internet et en est une représentation simplifiée. Le réseau des réseaux, cette galaxie communicante, génère, transmet et reçoit par l’intermédiaire de périphériques interconnectés et de liens entremêlés une constellation de données d’une complexité indescriptible. Les clouds privés et publics en sont des sous-ensembles.

Ces modèles de déploiement, au nombre de quatre, sont définis en fonction de leur relation à l’entreprise.

Cloud public

Dans un cloud public, l’environnement est entièrement détenu par la société qui met à disposition ses services cloud. Les utilisateurs et clients d’un cloud public n’ont de droit ni sur l’infrastructure, ni sur le matériel, ni sur les logiciels, ni sur quoi que ce soit d’autre. Le fournisseur de cloud met à disposition des utilisateurs des ressources. Il conçoit, gère, maintient et fait évoluer ces ressources en fonction des besoins des clients au fil du temps. Dans le domaine du cloud, et du cloud public en particulier, la sécurité est la clé de voute. L’infrastructure étant partagée avec de nombreux clients la sécurité est de la responsabilité du fournisseur qui en assure la gestion. Ce point est d’autant plus crucial que le client n’a qu’un degré de contrôle et de surveillance très faible des aspects physiques et logiques de sécurité sur les ressources qui sont mises à sa disposition. Le fournisseur doit donc tout mettre en œuvre pour garder la confiance de ses utilisateurs.

Modèle de déploiement d'un cloud public
Modèle de déploiement d’un cloud public

Cloud privé

Le terme cloud privé est utilisé pour décrire l’infrastructure qui émule le cloud computing sur un réseau privé. Le cloud privé a pour ambition d’offrir certains avantages du cloud computing tout en en limitant ses inconvénients. Un cloud privé est détenu par l’entreprise utilisatrice, cela nécessite d’acheter, de construire et de maintenir l’ensemble de ses constituants, ce qui implique de supporter un investissement initial très important.

Les clouds privés diffèrent des clouds publics en ce que les réseaux, serveurs, et infrastructures de stockage qui lui sont associés sont dédiés à une seule entreprise et ne sont pas partagés avec d’autres. Puisque le cloud est entièrement contrôlé par l’entreprise elle-même, les risques de sécurité associés à un cloud privé sont minimisés. Ce haut degré de contrôle et de transparence permet au propriétaire d’un cloud privé de se conformer plus facilement à des normes, politiques de sécurités ou conformités réglementaires qui peuvent être requises dans certains domaines.

Modèle de déploiement d'un cloud privé
Modèle de déploiement d’un cloud privé

Cloud communautaire

Le cloud de type communautaire est un modèle de déploiement multitenant partagé entre plusieurs entreprises ou organisations et qui est régi, géré, et sécurisé par l’ensemble des participants ou par un fournisseur de service.

Un cloud communautaire est une forme hybride de cloud privé construit et exploité spécifiquement pour un groupe restreint et ciblé. Ces communautés ont des exigences semblables et réunissent leurs moyens humains et financiers pour atteindre leurs objectifs communs.

L’infrastructure commune est spécifiquement conçue pour répondre aux exigences d’une communauté ; à titre d’exemple, des organismes gouvernementaux, des hôpitaux ou des entreprises de télécommunication qui auraient des contraintes de réseau, de sécurité, de stockage, de calcul ou d’automatisation similaires pourraient trouver des intérêts communs à déployer collectivement un cloud communautaire.

Modèle de déploiement d'un cloud communautaire
Modèle de déploiement d’un cloud communautaire

Cloud hybride

Comme son nom l’indique, un cloud hybride est la combinaison de plusieurs modèles de déploiement de clouds. Avec un cloud hybride, une entreprise peut tirer parti de la simplicité et du faible coût d’un cloud public — pour héberger des services classiques ne requérants pas de précautions particulières — tout en créant son propre cloud privé — pour des applications étroitement intégrées aux systèmes existants ou pour le stockage de données sensibles. Elle a également la possibilité de privilégier l’utilisation de son cloud privé tout en gardant la possibilité de déborder sur une offre de cloud public en cas de besoin temporaire.

Dans un cloud hybride, les clouds public, privé ou communautaire restent des entités uniques, mais sont reliés entre eux par une technologie normalisée ou propriétaire qui permet la portabilité des données et des applications. En raison de la complexité que la combinaison de plusieurs types de clouds engendre, la conception, la gestion et le maintien d’un cloud hybride peuvent être un véritable défi.

Modèle de déploiement d'un cloud hybride
Modèle de déploiement d’un cloud hybride

En résumé

Grâce au cloud computing, de nombreuses ressources peuvent être connectées via des réseaux privés ou publics. Cette technologie simplifie le déploiement d’infrastructures en offrant un support dynamique et évolutif pour héberger des services dont il est souvent compliqué de prévoir l’évolution temporelle.

Les entreprises peuvent choisir de déployer leur infrastructure de cloud en interne, en collaboration avec des partenaires partageant une vision commune, en utilisant les services d’un prestataire de service cloud public, ou bien en alliant plusieurs de ces solutions.

La figure suivante illustre les quatre modèles de déploiement, ainsi que leurs principales caractéristiques.

Les différents types d'environnements de déploiement des services de cloud
Les différents types d’environnements de déploiement des services de cloud

Upgrading OpenStack Havana to Icehouse

openstack-logo
This article describe the way I updated (with Raphaël Walter !) from Havana to OpenStack Icehouse.

We will perform the update service by service in live such a way that we can upgrade the controller independently from the compute nodes, minimizing service disruption.

For each service, the process is as follows:

  • Take down the service
  • Upgrade the packages
  • Upgrade the database
  • Start up the service

All of the below as been tested for an Ubuntu installation.

Let’s go!

Preparing to upgrade OpenStack

First and foremost, we will make backups!

Backup the configuration files

Save the configuration files on all nodes, as shown here:

for service in keystone glance nova cinder openstack-dashboard
do mkdir $service-havana
done

for service in keystone glance nova cinder openstack-dashboard
do cp -r /etc/$service/* $service-havana/
done

Backup databases

Backup all databases on the controller:

mysqldump -u root -p --opt --add-drop-database --all-databases > havana-db-backup.sql

Update systems

On all nodes, we ensure that our systems are up to date:

apt-get update
apt-get upgrade

Update repositories

On all nodes, remove the repository for Havana packages and add the repository for Icehouse packages:

apt-add-repository -r cloud-archive:havana
apt-add-repository cloud-archive:icehouse
apt-get update

Keystone

We stop the keystone service:

service keystone stop

We install some dependencies and the new version of Keystone:

apt-get install python-six python-babel keystone
If you want to know why we need to install the python-six ans python-babel paquets, check in the troubleshooting section.

We upgrade the database schema:

keystone-manage db_sync

We can start the Keystone service:

service keystone start

Glance

We stop the glance and glance-registry services:

service glance-api stop
service glance-registry stop

We install some dependencies and the new version of Glance:

apt-get install python-iso8601 python-keystoneclient python-stevedore glance glance-api

If your tables are not in utf-8, you need to convert them:

mysql -u root -p
mysql> use glance
mysql> ALTER DATABASE glance DEFAULT CHARACTER SET utf8;
mysql> SET FOREIGN_KEY_CHECKS=0;
mysql> ALTER TABLE images CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci; # To do with every tables
mysql> SET FOREIGN_KEY_CHECKS=1;

We upgrade the database schema:

glance-manage db_sync

We can start the Glance service:

service glance start
service glance-registry start

Cinder

We stop the cinder-scheduler, cinder-volume and cinder-api services:

service cinder-scheduler stop
service cinder-volume stop
service cinder-api stop

We install some dependencies and the new version of Cinder:

apt-get install cinder-volume python-cinderclient cinder-scheduler cinder-api

We upgrade the database schema:

cinder-manage db sync

We can start the Cinder services:

service cinder-scheduler start
service cinder-volume start

Nova controller

We stop the nova services:

service nova-consoleauth stop
service nova-novncproxy stop
service nova-cert stop
service nova-conductor stop
service nova-scheduler stop
service nova-api stop

We install some dependencies and the new version of Nova:

apt-get install nova-api nova-cert nova-conductor nova-consoleauth nova-novncproxy nova-scheduler python-novaclient

To enable Icehouse controller services to talk to Havana compute services, we need to set the compute=icehouse-compat option.
Find the [upgrade_levels] section and key in /etc/nova/nova.conf and make sure the version is set to icehouse-compat:

[upgrade_levels]
# Set a version cap for messages sent to compute services. If
# you plan to do a live upgrade from havana to icehouse, you
# should set this option to "icehouse-compat" before beginning
# the live upgrade procedure. (string value)
compute=icehouse-compat

The following configuration options are marked as deprecated in this release. See nova.conf.sample for their replacements. [GROUP]/option :

[DEFAULT]/rabbit_durable_queues
[rpc_notifier2]/topics
[DEFAULT]/log_config
[DEFAULT]/logfile
[DEFAULT]/logdir
[DEFAULT]/base_dir_name
[DEFAULT]/instance_type_extra_specs
[DEFAULT]/db_backend
[DEFAULT]/sql_connection
[DATABASE]/sql_connection
[sql][/sql]/connection
[DEFAULT]/sql_idle_timeout
[DATABASE]/sql_idle_timeout
[sql][/sql]/idle_timeout
[DEFAULT]/sql_min_pool_size
[DATABASE]/sql_min_pool_size
[DEFAULT]/sql_max_pool_size
[DATABASE]/sql_max_pool_size
[DEFAULT]/sql_max_retries
[DATABASE]/sql_max_retries
[DEFAULT]/sql_retry_interval
[DATABASE]/reconnect_interval
[DEFAULT]/sql_max_overflow
[DATABASE]/sqlalchemy_max_overflow
[DEFAULT]/sql_connection_debug
[DEFAULT]/sql_connection_trace
[DATABASE]/sqlalchemy_pool_timeout
[DEFAULT]/memcache_servers
[DEFAULT]/libvirt_type
[DEFAULT]/libvirt_uri
[DEFAULT]/libvirt_inject_password
[DEFAULT]/libvirt_inject_key
[DEFAULT]/libvirt_inject_partition
[DEFAULT]/libvirt_vif_driver
[DEFAULT]/libvirt_volume_drivers
[DEFAULT]/libvirt_disk_prefix
[DEFAULT]/libvirt_wait_soft_reboot_seconds
[DEFAULT]/libvirt_cpu_mode
[DEFAULT]/libvirt_cpu_model
[DEFAULT]/libvirt_snapshots_directory
[DEFAULT]/libvirt_images_type
[DEFAULT]/libvirt_images_volume_group
[DEFAULT]/libvirt_sparse_logical_volumes
[DEFAULT]/libvirt_images_rbd_pool
[DEFAULT]/libvirt_images_rbd_ceph_conf
[DEFAULT]/libvirt_snapshot_compression
[DEFAULT]/libvirt_use_virtio_for_bridges
[DEFAULT]/libvirt_iscsi_use_multipath
[DEFAULT]/libvirt_iser_use_multipath
[DEFAULT]/matchmaker_ringfile
[DEFAULT]/agent_timeout
[DEFAULT]/agent_version_timeout
[DEFAULT]/agent_resetnetwork_timeout
[DEFAULT]/xenapi_agent_path
[DEFAULT]/xenapi_disable_agent
[DEFAULT]/xenapi_use_agent_default
[DEFAULT]/xenapi_login_timeout
[DEFAULT]/xenapi_connection_concurrent
[DEFAULT]/xenapi_connection_url
[DEFAULT]/xenapi_connection_username
[DEFAULT]/xenapi_connection_password
[DEFAULT]/xenapi_vhd_coalesce_poll_interval
[DEFAULT]/xenapi_check_host
[DEFAULT]/xenapi_vhd_coalesce_max_attempts
[DEFAULT]/xenapi_sr_base_path
[DEFAULT]/target_host
[DEFAULT]/target_port
[DEFAULT]/iqn_prefix
[DEFAULT]/xenapi_remap_vbd_dev
[DEFAULT]/xenapi_remap_vbd_dev_prefix
[DEFAULT]/xenapi_torrent_base_url
[DEFAULT]/xenapi_torrent_seed_chance
[DEFAULT]/xenapi_torrent_seed_duration
[DEFAULT]/xenapi_torrent_max_last_accessed
[DEFAULT]/xenapi_torrent_listen_port_start
[DEFAULT]/xenapi_torrent_listen_port_end
[DEFAULT]/xenapi_torrent_download_stall_cutoff
[DEFAULT]/xenapi_torrent_max_seeder_processes_per_host
[DEFAULT]/use_join_force
[DEFAULT]/xenapi_ovs_integration_bridge
[DEFAULT]/cache_images
[DEFAULT]/xenapi_image_compression_level
[DEFAULT]/default_os_type
[DEFAULT]/block_device_creation_timeout
[DEFAULT]/max_kernel_ramdisk_size
[DEFAULT]/sr_matching_filter
[DEFAULT]/xenapi_sparse_copy
[DEFAULT]/xenapi_num_vbd_unplug_retries
[DEFAULT]/xenapi_torrent_images
[DEFAULT]/xenapi_ipxe_network_name
[DEFAULT]/xenapi_ipxe_boot_menu_url
[DEFAULT]/xenapi_ipxe_mkisofs_cmd
[DEFAULT]/xenapi_running_timeout
[DEFAULT]/xenapi_vif_driver
[DEFAULT]/xenapi_image_upload_handler

You need to edit /etc/nova/nova.conf and set the good options. In my case, I have had to replace the logdir option by log_dir:

sed -i -e "s/logdir/log_dir/g" /etc/nova/nova.conf

We upgrade the database schema:

nova-manage db sync

We can start the Nova services:

service nova-consoleauth start
service nova-novncproxy start
service nova-cert start
service nova-conductor start
service nova-scheduler start
service nova-api start

Nova compute

We stop the nova services:

service nova-compute stop
service nova-api-metadata stop
service nova-network stop

We install some dependencies and the new version of Nova:

apt-get install python-six nova-compute-kvm

We upgrade the database schema:

nova-manage db_sync

Because Icehouse brings libguestfs as a requirement. Installing Icehouse dependencies on a system currently running Havana may cause the Havana node to begin using libguestfs and break unexpectedly. It is recommended that libvirt_inject_partition=-2 be set on Havana nodes prior to starting an upgrade of packages on the system.
On the Compute nodes, edit /etc/nova/nova.conf and add:

libvirt_inject_partition=-2

As we have seen, many options are marked as deprecated in this release. See nova.conf.sample for their replacements. You need to edit /etc/nova/nova.conf and set the good options. In my case, I have had to replace the libvirt_cpu_mode, libvirt_cpu_model, libvirt_type, libvirt_use_virtio_for_bridges and logdir options:

sed -i -e "s/libvirt_cpu_mode/cpu_mode/g" /etc/nova/nova.conf
sed -i -e "s/libvirt_cpu_model/cpu_model/g" /etc/nova/nova.conf
sed -i -e "s/libvirt_type/virt_type/g" /etc/nova/nova.conf
sed -i -e "s/libvirt_use_virtio_for_bridges/use_virtio_for_bridges/g" /etc/nova/nova.conf
sed -i -e "s/logdir/log_dir /g" /etc/nova/nova.conf

We can start the Nova services:

service nova-compute start
service nova-api-metadata start
service nova-network start

We must not forget to unset the compute=icehouse-compat option that we set previously.
Find the [upgrade_levels] section and key in /etc/nova/nova.conf and unset icehouse-compat:

[upgrade_levels]
# Set a version cap for messages sent to compute services. If
# you plan to do a live upgrade from havana to icehouse, you
# should set this option to "icehouse-compat" before beginning
# the live upgrade procedure. (string value)
#compute=icehouse-compat

Horizon

There is nothing special to do to upgrade the Horizon service. You only have to upgrade it and restart the Apache HTTP Server:

apt-get install openstack-dashboard
service apache2 restart

OpenStack Icehouse

Troubleshooting

#1

Problem:

root@controller:~/backup-havana/keystone-havana# apt-get install keystone
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
keystone est déjà la plus récente version disponible.
0 mis à jour, 0 nouvellement installés, 0 à enlever et 102 non mis à jour.
1 partiellement installés ou enlevés.
Après cette opération, 0 o d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer [O/n] ? O
Paramétrage de keystone (1:2014.1-0ubuntu1~cloud1) ...
Traceback (most recent call last):
  File "/usr/bin/keystone-manage", line 37, in 
    from keystone import cli
  File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 23, in 
    from keystone.common import sql
  File "/usr/lib/python2.7/dist-packages/keystone/common/sql/__init__.py", line 17, in 
    from keystone.common.sql.core import *
  File "/usr/lib/python2.7/dist-packages/keystone/common/sql/core.py", line 35, in 
    from keystone.openstack.common.db.sqlalchemy import models
  File "/usr/lib/python2.7/dist-packages/keystone/openstack/common/db/sqlalchemy/models.py", line 32, in 
    class ModelBase(six.Iterator):
AttributeError: 'module' object has no attribute 'Iterator'
dpkg : erreur de traitement de keystone (--configure) :
 le sous-processus script post-installation installé a retourné une erreur de sortie d'état 1
Des erreurs ont été rencontrées pendant l'exécution :
 keystone
E: Sub-process /usr/bin/dpkg returned an error code (1)

Solution:

apt-get install python-six

#2

Problem:

2014-04-29 10:52:37.210 22541 ERROR stevedore.extension [-] Could not load 'rabbit': (Babel 0.9.6 (/usr/lib/python2.7/dist-packages), Requirement.parse('Babel>=1.3'))
2014-04-29 10:52:37.210 22541 ERROR stevedore.extension [-] (Babel 0.9.6 (/usr/lib/python2.7/dist-packages), Requirement.parse('Babel>=1.3'))

Solution:

apt-get install python-babel 

#3

Problem:

root@controller:/etc/glance# glance-manage db_sync
2014-04-29 11:01:16.081 23930 CRITICAL glance [-] ValueError: Tables "image_locations,image_members,image_properties,image_tags,images,migrate_version" have non utf8 collation, please make sure all tables are CHARSET=utf8

Solution:
For each tables:

mysql -u root -p
mysql> use glance
mysql> ALTER DATABASE glance DEFAULT CHARACTER SET utf8;
mysql> SET FOREIGN_KEY_CHECKS=0;
mysql> ALTER TABLE images CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;

#4

Problem:
In /var/log/glance/registry.log:

2014-04-29 11:00:06.360 23667 TRACE stevedore.extension   File "/usr/lib/python2.7/dist-packages/stevedore/extension.py", line 101, in _load_one_plugin
2014-04-29 11:00:06.360 23667 TRACE stevedore.extension     plugin = ep.load()
2014-04-29 11:00:06.360 23667 TRACE stevedore.extension   File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 1988, in load
2014-04-29 11:00:06.360 23667 TRACE stevedore.extension     if require: self.require(env, installer)
2014-04-29 11:00:06.360 23667 TRACE stevedore.extension   File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2001, in require
2014-04-29 11:00:06.360 23667 TRACE stevedore.extension     working_set.resolve(self.dist.requires(self.extras),env,installer))
2014-04-29 11:00:06.360 23667 TRACE stevedore.extension   File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 588, in resolve
2014-04-29 11:00:06.360 23667 TRACE stevedore.extension     raise VersionConflict(dist,req) # XXX put more info here
2014-04-29 11:00:06.360 23667 TRACE stevedore.extension VersionConflict: (python-keystoneclient 0.3.2 (/usr/lib/python2.7/dist-packages), Requirement.parse('python-keystoneclient>=0.7.0'))

Solution:

apt-get install python-keystoneclient

#5

Problem:

2014-04-29 11:38:38.390 26395 WARNING glance.notifier [-] notifier_strategy was deprecated in favor of `notification_driver`
2014-04-29 11:38:38.428 26395 WARNING glance.notifier [-] notifier_strategy was deprecated in favor of `notification_driver`
2014-04-29 11:38:38.430 26395 WARNING glance.notifier [-] notifier_strategy was deprecated in favor of `notification_driver`
2014-04-29 11:38:38.432 26395 WARNING glance.notifier [-] notifier_strategy was deprecated in favor of `notification_driver`
2014-04-29 11:38:38.437 26395 WARNING glance.notifier [-] notifier_strategy was deprecated in favor of `notification_driver`
2014-04-29 11:38:38.440 26395 WARNING glance.notifier [-] notifier_strategy was deprecated in favor of `notification_driver`
2014-04-29 11:38:38.441 26395 WARNING glance.notifier [-] notifier_strategy was deprecated in favor of `notification_driver`

Solution:
In /etc/glance/glance-api.conf:

notification_driver = noop