Guide d'un déploiement OpenStack réussi

OpenStack procure maints avantages aux utilisateurs, et il n’est guère difficile de comprendre pourquoi la perspective de créer son propre cloud à l’aide d’outils Open Source gratuits séduit tant d’entreprises. Se lancer dans un projet OpenStack exige néanmoins de faire preuve de lucidité. Durant toutes ces années passées à créer et à déployer des environnements cloud OpenStack, nous avons pu constater, chez Mirantis, que nombreux sont ceux qui prennent leurs désirs pour des réalités – d’où des attentes parfois illusoires. En vous conformant à ces dix principes, vous suivrez la bonne direction.

1. Préparez-vous à délier votre bourse

Bien souvent, le discours est le même : « À quoi bon prévoir un budget ? Il nous suffit d’exploiter le code récupéré du référentiel. Puisqu’il n’y a pas de redevance de licence. »

Exact, du moins pour la dernière partie de l’argumentation. Si l’exécution d’OpenStack ne fait effectivement l’objet d’aucune redevance de licence, les logiciels Open Source, eux, ne jaillissent pas de nulle part, en particulier dans le cas d’un projet aussi volumineux et complexe qu’OpenStack. Plusieurs centaines de développeurs ne ménagent pas leurs efforts et sont payés pour perfectionner un code qui évolue constamment, de sorte que la dernière version d’un simple composant vous oblige à importer la dernière version de tous les autres.

En l’occurrence, le problème réside dans l’instabilité chronique des dernières versions en date du code qui engendre, de la part de la communauté, des correctifs de bugs critiques à un rythme soutenu, aux antipodes du vôtre. Il faudra prévoir, par conséquent, un responsable en charge de la correction de ces bugs ; or, la main-d’œuvre est onéreuse. Même si, à un moment donné, le code Open Source est gratuit, un budget et des ressources dédiées sont donc incontournables.

2. Impliquez les collaborateurs

Si votre cloud est suffisamment compact pour tenir sur votre ordinateur portable, sans doute suffirez-vous à la tâche. Si vous ciblez un cloud de moyenne ou grande envergure, en revanche, sachez que ce projet fédèrera quantité de participants. La plupart des entreprises déploient des clouds pour des raisons complexes ; vous devez prendre la juste mesure de ce dont les autres (et pas uniquement vous) ont besoin pour mener cette opération à bien.

Exposez explicitement vos scénarios d’utilisation afin de déterminer s’il vous faut un cloud public, privé ou hybride. Votre charge de travail est-elle de type multilocataire ? S’inscrit-elle sur une longue ou sur une courte période ? Est-elle dédiée, éphémère, stable ou sporadique, voire épouse-t-elle tous ces qualificatifs à la fois ? Peut-être le cloud n’est-il d’ailleurs pas la solution à votre problème. Analysez les applications en place. Relèvent-elles du cloud, ou doivent-elles perdurer sur l’infrastructure existante ? Aucune décision ne saurait être prise sans en mesurer les conséquences.

3. Soyez précis dans la terminologie employée

Peut-être pensez-vous que chacun est rompu à la terminologie utilisée ; il est pourtant essentiel d’en maîtriser les tenants et aboutissants — collectivement. Quid de la phrase suivante, relevée au cours d’une réunion de planification : « Nous avons créé un service à l’appui de ce service, mais lorsque nous avons rencontré des problèmes de niveau de service, nous avons fait appel aux services ». Surveillez également les échanges sur les forums OpenStack autour de la signification exacte du terme « taper ». Prenez le temps de décrypter ce que vos interlocuteurs veulent dire en reformulant leurs pensées en des termes précis car les interprétations divergent — même si les mots sont les mêmes.

4. Acceptez que les systèmes traditionnels ne disparaissent pas

Si les programmeurs COBOL ont toujours un job, ce n’est pas par hasard. Les applications traditionnelles ne sont pas près de disparaître : telle est la réalité. Récemment, un administrateur système ultra-enthousiaste nous confiait ceci : « Nous sommes sur le point de créer un cloud sur lequel nous transfèrerons la totalité de nos ressources informatiques. » Pourquoi pas ? Mais il faudra du temps avant que cela fonctionne. Certains systèmes en place, dont des applications de stockage de données, transactionnelles, financières et d’assurance, ne sont tout simplement pas prêts à migrer dans le cloud, surtout si des règles de gestion n’ont pas été clairement définies.

5. Évaluez les charges de travail que vous transférez

Certains sont convaincus qu’un simple équilibrage de charge suffit à une migration vers le cloud. Ce sophisme consiste à assimiler le cloud à un routeur géant qui se contenterait de déplacer le trafic sans état (stateless) là où il s’exécutera le plus vite. Songez au type de charges de travail que vous transférez dans le cloud. S’agit-il d’un environnement de développement/test ? Est-il possible de le faire monter ou descendre en capacité ? Peut-il être mis hors service en cas d’urgence ? Vous faut-il un seul composant ou plusieurs ? Dans la plupart des cas, la montée en charge d’une application ne peut être opérée par simple clonage de ses éléments ; tous les services qui la composent seront incapables de préserver une cohérence entre ses répliques à moins que leur architecture ait été prévue pour cela dès le départ.

6. Collaborez avec les développeurs

Avec OpenStack, les applications exercent un contrôle plus étroit de leur plate-forme d’exécution que dans un environnement classique. D’où une transformation de la relation entre opérateur et développeur, ces deux fonctions devant travailler en étroite intelligence.

Si les opérateurs d’OpenStack donnent aux développeurs les moyens d’exploiter l’infrastructure en libre-service, cela ne signifie pas pour autant qu’ils cannibalisent leur propre rôle. Il leur faut doter les développeurs d’un éventail de possibilités suffisantes pour leur permettre de réussir ; leur proposer un choix — sans leur donner toute latitude pour autant. Il leur appartient également de consolider l’expertise de ces développeurs pour que l’architecture et l’opérabilité de la solution soient adaptées.

7. Ne partez pas du principe que votre personnel possède les qualifications requises

Très souvent, nous entendons cet argument : « Nos collaborateurs possèdent les compétences requises. Cette technologie n’est guère éloignée de Linux. » Bien entendu, si votre entreprise est dotée de virtuoses du code source spécialisés en réseaux IP, gestion des ressources des hyperviseurs, redondance et optimisation du stockage, gestion, sécurité et cryptage du code source, optimisation de pilotes, architectures applicatives distribuées et autres technologies en jeu dans OpenStack, il se peut que vous ayez raison. Néanmoins, une ou plusieurs de ces compétences risquent de vous manquer, et il faut que vos collaborateurs le sachent.

Si Linux est utilisable par tous, les ingénieurs kernel ne courent pas les rues. Sans doute deviendrez-vous un virtuose omniscient du code source, mais pas du jour au lendemain.

8. Faites une proposition

« Le cloud engendre de formidables gains d’efficacité. Il sera vite rentabilisé. » Allez de l’avant et tentez de faire passer ce message auprès de la direction financière.

Il est plus que probable que vous aurez besoin de nouveaux matériels, et cet aspect ne sera pas le moindre, ni le moins cher d’ailleurs. Par ailleurs, les gens compétents ne travaillent pas pour rien. Il vous faudra former ceux qui ne possèdent pas toutes les qualifications requises. À propos, disposez-vous également à proximité d’un centre de données vacant, équipé d’un circuit de refroidissement ?

Peut-être devrez-vous également changer de modèle économique. Le financement de votre infrastructure existante reposait sur un ensemble d’hypothèses d’utilisation par différents responsables fonctionnels et métiers – hypothèses qui ne sont sans doute plus vraies aujourd’hui. Où vos utilisateurs vont-ils se procurer les fonds nécessaires à l’appui du cloud ?

Il n’est pas rare que des entreprises commencent « en douceur » avant de développer une véritable stratégie avec Mirantis OpenStack Express, outil qui les aide à concrétiser, à gérer et à acquérir une prévisibilité sur leurs budgets. Les plus performantes prennent en compte les caractéristiques économiques des utilisateurs et la valeur de leur cloud, et proposent un plan en conséquence.

9. Ayez un plan en cas de panne

Une idée fausse, et pourtant très répandue, a trait au cloud autoréparable. Moyennant une supervision et une maintenance appropriées, le cloud peut, effectivement, s’autoréparer — parfois. Encore faut-il veiller à disposer des outils de supervision et de redondance appropriés, en particulier pour générer des alertes à l’approche des seuils de capacité. Il est d’ailleurs possible que vous ignoriez l’existence même d’une panne jusqu’à cette absence d’autoréparation ; et c’est alors que votre téléphone vous réveillera à 3 heures du matin. Et cette ingénieure véritablement incollable ? Elle ne sera pas toujours disponible en permanence. Se préparer à l’imprévu, c’est éviter d’être pris au dépourvu.

10. Acceptez l’échec

Enfin, la vieille école pense que la panne n’est pas une possibilité envisageable. Or, lorsqu’il s’agit du cloud, la panne n’est pas une possibilité mais une fatalité : c’est même l’un des principes fondamentaux de sa conception. Il faut alors faire preuve de réactivité. Assurez-vous que vos systèmes et applications sont prêts pour le moment où une défaillance va survenir et où ils devront s’adapter. C’est alors que vous percevez véritablement l’avantage d’OpenStack car vos systèmes continueront à fonctionner même lorsque les choses ne se déroulent pas comme prévu.

OpenStack offre indéniablement aux entreprises une multitude de possibilités applicables à leur infrastructure informatique, via une solution évolutive, souple et économique. En cernant les besoins de votre activité et ce qu’implique un déploiement OpenStack, vous contribuerez à mettre en place le système cloud souple, agile et résilient dont rêve votre entreprise – sans commettre aucune des erreurs les plus fréquentes.

Tribune de Par Rajiv Sodhi, directeur général EMEA chez Mirantis