EN ROUTE VERS LE TOUT VIRTUALISÉ route vers le tout virtuAlisé

La virtualisation des serveurs, du stockage et des réseaux, augmentée d’une couche d’automatisation doit permettre aux entreprises d’être aussi réactives que les start-up.

Après une année 2015 finalement plus expérimentale que prévue, les technologies Software Defined devraient être à l’honneur dans les entreprises en 2016. L’appellation Software Defined regroupe tout l’outillage logiciel qui consiste à virtualiser des ressources matérielles, qu’il s’agisse des serveurs, du stockage ou du réseau. L’enjeu technique est double. Il y a d’abord la perspective d’acheter en interne des machines génériques pour constituer un réservoir de ressources, lequel sera disponible à la découpe à chaque fois que les métiers auront un nouveau projet à lancer. Il y a ensuite la promesse qu’une application finale soit si indépendante des spécificités de l’infrastructure sous-jacente qu’on puisse tantôt la tester sur le datacenter interne, tantôt la mettre en production dans un Cloud externe – ou l’inverse – et, ce, sans effectuer aucune modification, sans perdre le temps de s’adapter aux choix techniques de part et d’autre. Pour les entreprises, il s’agit de parvenir en 2016 à mettre le plus rapidement possible de nouvelles applications en production, pour rester compétitives face à des startup extrêmement réactives.

des mAchines virtuelles trAnsportAbles

En ce qui concerne la puissance de calcul, ou Software Defined Datacenter (SDDC) les entreprises vont devoir tester en 2016 deux choses : l’opportunité de remplacer les machines virtuelles par des containers, d’une part, et un environnement d’automatisation dit « DevOps », d’autre part, qui ajoute de l’automatisation aux suites de virtualisation habituelles (vSphere de VMware, Hyper-V de Microsoft, KVM, etc.). Conçus comme des machines virtuelles allégées, sans système d’exploitation propre mais faisant appel à un OS père sur une VM externe, ce qui permet d’en exécuter entre 10 et 100 fois plus sur un même cluster de serveurs x86, les containers sont en train de se standardiser autour du nouveau format OCF, censé agir comme une couche d’abstraction vis-à-vis de l’infrastructure sous-jacente. Avec un container OCF, il deviendrait ainsi possible d’exécuter une application Windows dans un Cloud où les machines virtuelles fonctionnent sous Linux, et vice-versa. L’abstraction entre des applications Windows et un OS Linux, ou l’inverse, sera assurée par la récente mise en Open Source des rouages de .NET par Microsoft. Des solutions commerciales de containers OCF devraient sortir dès le premier trimestre 2016, notamment chez Red Hat, et elles fonctionneront soit par-dessus des solutions de virtualisation classiques, soit directement sur des serveurs physiques. En ce qui concerne les environnements DevOps, en revanche, trop d’options coexistent pour qu’il s’en dégage à coup sûr une seule en 2016. Les solutions d’automatisation historiques de VMware, Microsoft, HP et IBM nécessitent encore d’être manipulées par les équipes de l’IT. OpenStack tarde à murir (lire L’Informaticien n°141). Pivotal, Red Hat ou encore CA lancent des portails clés en main, qui permettent véritablement aux développeurs d’appuyer sur un bouton pour mettre leurs applications en production avec toutes les ressources nécessaires, mais ces solutions doivent encore faire leurs preuves.

l'essor du stockAge objet

Dans le domaine du stockage, ou Software Defined Storage (SDS), deux tendances se dégagent. D’abord, c’est un succès, le principe de simuler une baie de stockage à partir des disques durs présents dans des serveurs x86 s’est popularisé (voir l’article dédié aux infrastructures hyperconvergées de ce même dossier), au point que des baies de stockage dites SDS, deux fois moins chères que des baies SAN conventionnelles, devraient déferler sur le marché dès les premières semaines de 2016. Ce sera très économique à l’achat pour constituer un réservoir de stockage interne, mais cela ne résoudra en rien la problématique de portabilité des applications du datacenter interne à un Cloud externe. D’autant que, en l’état, les baies SDS ne savent pas synchroniser leur contenu entre deux sites distants. L’autre pan du SDS est le stockage objet. C’est la technologie que les entreprises vont devoir adopter sur leurs baies de stockage pour

permettre à leurs applications d’aller chercher leurs données via l’URL d’un domaine, une méthode qui résume la domiciliation en interne ou en externe à une simple reconfiguration de DNS. Problème n°1, encore faut-il que les baies de stockage acceptent le mode objet. Les rares qui le font, comme les HP 3PAR, ne fonctionnent pas en cluster, ce qui limite la quantité de données possibles à la capacité d’une seule baie. Il faut donc passer par un logiciel externe, capable de chapeauter plusieurs baies en mode objet. À date, ViPR d’EMC semble bien plus opérationnel qu’OpenStack, mais bien plus lié aux tarifs et au devenir d’un seul fournisseur aussi. Problème n°2, il existe plusieurs protocoles objet. La communauté OpenStack voudrait que son module Swift fasse office de standard, aussi bien sur les baies internes (ViPR est compatible, ouf !) que chez les hébergeurs de Cloud. Mais ni Amazon S3, ni Windows Azure ne le supportent. Ne pas passer par du SDS de type objet imposerait aux entreprises de fixer les données de leurs applications sur un site unique, accessible en période de test comme de production, ce qui reste une possibilité.

Les compétences en pLace guident Le choix du sdn

Dans le domaine du Software Defined Network (SDN), deux modèles de fonctionnement continueront de batailler en 2016. Dans tous les cas, le but consiste à maintenir des sous-réseaux de machines virtuelles réparties sur plusieurs serveurs physiques, soit pour des questions d’équilibrage des charges en interne, soit parce que les applications hébergées dans les VM sont opérationnelles sur plusieurs sites. Chez VMware, le SDN porté par le logiciel NSX consiste à accoler une table de routage sur chaque hyperviseur. L’intérêt est que l’équipe en charge des serveurs peut administrer des groupes de VM entiers avec des règles d’accès – qui voit qui – définies pour les applications. L’inconvénient est que cela ne fonctionne que sur les sites où NSX est déployé. Chez les fabricants d’équipement réseau, on préfère intégrer cette fonction dans les routeurs et les commutateurs au travers du protocole standard VXLAN. Par rapport à NSX, VXLAN apporte en plus la qualité de service et permet de dépasser la limite standard de 4 000 VLAN. En revanche, une équipe d’administrateurs réseau redevient obligatoire. Et chaque constructeur a sa manière bien à lui d’indiquer à VXLAN comment reconnaître les machines virtuelles. Chez Cisco, par exemple, le SDN ACI a la possibilité de lire les attributs des VM en interrogeant vSphere et sa dernière version présente l’avantage exclusif de savoir reconnaître des containers au format Docker, l’ancêtre d’OCF. Dans les entreprises, le choix d’un SDN particulier ne semble pas se faire sur des aspects techniques mais humain : la solution adoptée in fine est celle que les équipes en place sont le plus susceptibles de savoir administrer.