Le stockage rattrape la révolution DevOps

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.