Le stockage rattrape la révolution DevOps

Les contraintes imposées par les approches DevOps et le besoin croissant d’agilité font basculer la consommation et le déploiement des ressources de stockage vers une approche plus axée sur le Cloud.

Cet article se trouve également dans ce contenu premium en téléchargement : STORAGE: Storage 10 : Stockage et Conteneurs

Contraction de « Développement et Opérations », le terme DevOps désigne un nouveau mode opératoire pour mettre à disposition des applications via des méthodes de développement agile. Ainsi, l’approche DevOps transfère la responsabilité de certaines fonctions opérationnelles de l’informatique à des équipes de développement. Ces dernières peuvent alors rapidement créer, développer, modifier et déployer des applications, généralement sans interagir avec les équipes opérationnelles.

Pour obtenir un environnement agile ou DevOps, les ressources – dont le stockage – doivent être consommées et déployées selon une approche davantage axée sur le Cloud. Pour mettre à disposition les ressources nécessaires pour la création et le déploiement d’applications, l’approche DevOps s’appuie sur l’agilité de l’infrastructure informatique. Aussi le développeur attend-il d’une infrastructure DevOps certaines fonctions qui diffèrent de ce que sa communauté utilisait par le passé. En général, ces différences fonctionnelles sont les suivantes :

  • Disponibilité des ressources à la demande : Des ressources d’infrastructure disponibles et consommables à la demande au cours du processus de développement. Il peut, par exemple, s’agir de créer un environnement de développement à partir duquel le développeur a accès aux données source (« seed data ») et qui repose à la fois sur des composants de type conteneur et machine virtuelle (VM, Virtual Machine).
  • Automatisation et workflow : Des environnements de développement construits à la demande, selon un processus d’élaboration aussi automatisé que possible. Dans la plupart des cas, une infrastructure de développement d’applications s’élabore à partir d’un maître utilisé pour déployer l’application et qui renferme les composants qui lui sont nécessaires (par exemple, un serveur de bases de données, un serveur Web, etc.).
  • Evolutivité et caractère éphémère : Les développements DevOps font souvent appel à plusieurs environnements pour tester en parallèle les nombreux changements intervenant dans les applications. Chaque développeur dispose donc de son propre environnement mais pour un laps de temps réduit. Ainsi, les environnements DevOps doivent permettre de lancer puis de détruire une application à la volée.
  • Prise en charge des VM et des conteneurs : La quasi-totalité des processus DevOps s’appuie sur le développement d’applications soit au sein de VM, soit sous forme d’instances de conteneur. Les plateformes de stockage qui proposent une prise en charge native de VM et de conteneurs facilitent donc l’interaction en termes d’administration et d’intégration.

Le recours à une méthode DevOps permet de mettre en œuvre un processus de développement continu grâce à un panel de nouveaux outils. Il s’agit notamment de systèmes d’administration comme Jenkins, d’outils d’orchestration, tels que Kubernetes et Mesosphere, et, bien sûr, d’infrastructures de virtualisation, telles que Docker, OpenStack et Vagrant. Ces plateformes commencent à intégrer le composant stockage pour offrir le niveau d’automatisation et de sécurité nécessaire à un développement continu. Ainsi, Docker a étendu sa plateforme via un plug-in qui orchestre le stockage externe persistant.

Kubernetes prend en charge la persistance qu’il est possible de mettre à disposition via les interfaces classiques en mode bloc et fichiers (iSCSI, FC, NFS) ou le stockage en Cloud ou de type Open Source.

Il faut en outre reconnaître que le Cloud public occupe une part importante dans l’approche DevOps. En effet, des plateformes telles qu’Amazon AWS permettent de créer et de détruire facilement les environnements de développement instanciées par les entreprises. En général, c’est la plateforme Cloud qui administre le stockage. Ce dernier n’est pas exposé au développeur. Comme nous le verrons par la suite, les problèmes que pose l’usage du Cloud public pour le développement continu tiennent à l’utilisation de données de test.

Mise à disposition

Les difficultés de mise en place d’un système de stockage au sein d’un environnement DevOps vont de pair avec les problèmes constatés lors de la création d’un Cloud privé. Les ressources de stockage doivent être mises à disposition selon un mode bien plus dynamique ; un mode offrant la possibilité de créer et de détruire des ressources à la demande. Il faut donc disposer d’API d’automatisation qui permettent de créer des LUN et des volumes, et de les associer à l’application en fonction des besoins.

Dans le cadre d’infrastructures de déploiement d’applications, telles qu’OpenStack, la consommation du stockage à bas niveau s’effectue via des plug-ins qui permettent à différents fournisseurs d’exposer leurs produits. Le projet Cinder d’OpenStack couvre ainsi la possibilité de créer dynamiquement un stockage en mode bloc et de l’associer à une instance. Des projets similaires portent également sur le stockage de fichiers (Manila) ou objet (Swift). La majorité des fournisseurs d’appliances de stockage et de solutions de SDS (Software-Defined Storage) supporte Cinder en proposant un plug-in intermédiaire qui gère le processus d’orchestration. Le pilote intermédiaire traduit alors les commandes Cinder (comme celles de création et de suppression de volume) en commandes spécifiques de la plateforme de stockage, et assure le suivi des ressources allouées et des instances associées.

Dans un environnement de développement, les modifications sont considérablement plus nombreuses et rythmées qu’en production. Le cycle d’utilisation des ressources sera donc lui aussi plus élevé, et toute plateforme de stockage candidate devra pouvoir soutenir un rythme de changements de configuration accéléré. Ces conditions posent un problème du côté des systèmes de stockage. En effet, leurs configurations étaient censées rester relativement statiques. Les fournisseurs de stockage reconnaissent de plus en plus la nécessité d’une approche « programmatique » de leurs produits. Les API (Application Programming Interface) – deviennent donc une caractéristique attendue par les clients. Et ces API devront pouvoir traiter les requêtes en parallèle, même si les changements internes côté ressources interviennent, eux, en série.

Locataires Multiples

En général, les développeurs ne se soucient pas de la mise à disposition des ressources. Ils veulent savoir si leur environnement est exploitable et conforme aux niveaux de service convenus. Lors de la mise à disposition de ressources de stockage, l’environnement DevOps devra donc aussi se focaliser sur le multi-tenant. Et cette gestion définit la capacité de fournir un accès multi-utilisateur à des ressources partagées sans qu’aucun utilisateur, ou « locataire » (tenant), n’en impacte un autre.

Tout aussi essentiel dans les environnements DevOps, la gestion du multi-tenant doit garantir qu’aucun environnement ne consomme une trop grande part des ressources de stockage, tant en termes de capacités que de performances. Autrement dit, les administrateurs doivent restreindre la quantité de ressources consommées par environnement, particulièrement lorsque le matériel sous-jacent est partagé avec la production.

Rendement

L’optimisation des données influe considérablement sur la mise à disposition d’un environnement de développement performant. L’optimisation des données est incontournable : la majorité des environnements de développement est créée à partir de masters, voire de copies de données de production. Ainsi, certaines fonctions, telles que la déduplication des données, épargneront considérablement la capacité de stockage.

Utilisée conjointement à des fonctions telles que les snapshots, la déduplication permet de créer rapidement et efficacement de nombreux environnements de test. Particulièrement avantageux, ces snapshots permettent de cloner des instances de VM avec un minimum de gestion. Le clonage peut s’avérer bien plus pratique que la création individuelle pure et simple d’instances VM (suivie de leur reconfiguration), particulièrement en cas de personnalisation poussée.

Approvisionnement en données

Un test précis des applications implique de recourir à des données réelles, qui reflètent aussi précisément que possible l’environnement de production. Dans la majorité des scénarii, il est fréquent d’utiliser une copie normale ou un snapshot de données de production en guise de données de test. Bien sûr, les données doivent être anonymisées dans les règles de l’art afin de protéger les informations des clients et préserver la sécurité des données.

Dans un environnement de Cloud privé, créer une copie de ce qui est en production est relativement simple : il suffit d’utiliser des snapshots, des clones ou une réplication. Ces techniques supposent que la plateforme de développement soit compatible avec la production et permette ainsi de déplacer une copie de l’instantané vers une autre plateforme. La production et le développement peuvent aussi s’exécuter sur le même matériel. Ici, c’est la qualité de service qui garantira le niveau adéquat de performances pour les données de production.

L’approvisionnement en données dans un contexte de cloud public pose davantage de problèmes : ceux liés au coût du stockage des données et au délai nécessaire à leur réplication dans l’environnement en Cloud. Certains produits, tels que vFXT d’Avere Systems s’exécutent sur des plateformes Cloud et portent les données de l’entreprise installées sur site dans le Cloud. Ces produits sont avantageux par leur accès aux seules données actives, optimisant ainsi les coûts de stockage et de trafic réseau.

Un mot sur la surveillance

Dans un environnement à forte activité cyclique, dans lequel des ressources sont créées puis détruites régulièrement, le risque est toujours élevé de voir les ressources de stockage soit mal utilisées, soit surconsommées. Souvent, les entreprises créent des environnements de développement qu’elles abandonnent ensuite ou, plus généralement, qu’elles oublient. Autre extrême, on se retrouve facilement avec un stockage anarchique, dans lequel sont accumulés de nombreux environnements de développement au lieu de les réutiliser. Une surveillance et une maintenance plafonneront la demande croissante tant en capacités qu’en performances, tout en identifiant les environnements laissés à l’abandon. La surveillance est également importante lorsqu’il s’agit de mettre en œuvre une rétro-facturation. Elle doit, en outre, être suffisamment granulaire pour fonctionner au niveau même des environnements.

Technologie de stockage

La montée en puissance de l’approche DevOps a fait émerger de nouvelles technologies de stockage qui proposent des caractéristiques spécifiques d’un développement agile. Ces caractéristiques sont les suivantes :

  • Hyperconvergence : Le stockage est mis à disposition à partir du matériel physique utilisé également pour exécuter les applications (soit sous l’égide d’un hyperviseur, soit sous forme de conteneurs). Le logiciel cache la complexité liée à la mise à disposition du stockage au niveau des nouvelles instances de VM et des nouveaux conteneurs. Un produit hyperconvergé facilite le processus DevOps car il se focalise sur la création d’objets logiques, comme les instances de VM, et non plus sur l’administration de ressources physiques.
  • Stockage secondaire avec prise en charge des VM : Le terme « stockage secondaire » s’applique à toutes les données stockées par une entreprise à des fins autres que la production, notamment la sauvegarde et l’archivage. Par sa nature flexible, la VM permet de cloner des applications entières à partir d’images de sauvegarde, puis de les exécuter directement depuis une plateforme de stockage secondaire ; une approche qui évite de construire un environnement DevOps séparé.
  • Stockage à définition logicielle (SDS) : Depuis les premières plateformes, le stockage à définition logicielle (SDS) a bien évolué. Aujourd’hui, qu’il s’agisse de blocs, fichiers ou objets, de multiples offres SDS sont capables de monter à l’échelle. Et nombre d’entre elles sont également de type Open Source et peuvent se déployer à moindres frais sur un matériel générique. 
Dans les environnements de développement non focalisés sur de hauts niveaux de performances, cela permettra de réaliser des économies considérables par rapport au classique achat de matériel auprès d’un fournisseur de plates-formes de stockage.

Construire ou acheter

En résumé, la nécessité d’un stockage dédié à l’environnement DevOps est conforme à la voie tracée par le Cloud privé. L’automatisation remplit les tâches jusqu’alors effectuées par l’administrateur du stockage.

Ce dernier perd en visibilité, éliminant au passage le facteur humain de la consommation des ressources.

Le stockage traditionnel est probablement l’option la moins attrayante pour les environnements DevOps, au regard de l’approche évolutive des outils plus modernes. Vous avez la possibilité de construire plutôt que d’acheter, et ainsi de profiter d’économies substantielles sur l’acquisition de matériel. Parallèlement, des produits Open Source diminueront le coût global et — au rythme du développement fonctionnel — resteront en adéquation avec le concept de développement continu que revendique le DevOps.

Approfondir

Soyez le premier à commenter

M'envoyer une notification dès qu'un autre membre commente.

Merci de créer un identifiant pour pouvoir poster votre commentaire.

- ANNONCES GOOGLE

Close